Objetivos de Aprendizaje – Cap 1 – ISTQB CTFL v3.1

  • Autor de la entrada:
  • Categoría de la entrada:ISTQB

Introducción

Para estudiar cada uno de los capítulos del Programa de Estudios del ISTQB CTFL v3.1.  y no sólo comprender su alcance sino además las relaciones existentes entre sus conceptos se pueden aplicar varios métodos, uno de ellos es conociendo y comprendiendo los objetivos de aprendizaje de cada uno de los principales ítems de cada capítulo.

Aquí te comparto el alcance de los objetivos de aprendizaje del Capítulo I – Fundamentos del Proceso de Prueba.

Objetivos

¿Por qué es Necesario Probar?
NB-1.2.1 (K2) Dar ejemplos de por qué es necesario probar.
NB-1.2.2 (K2) Describir la relación entre la prueba y el aseguramiento de la calidad y dar ejemplos de cómo probar contribuye a obtener un mayor nivel de calidad.
NB-1.2.3 (K2) Distinguir entre error, defecto y fallo.
NB-1.2.4 (K2) Distinguir entre la causa raíz de un defecto y sus efectos.

Siete Principios de la Prueba
NB-1.3.1 (K2) Explicar los siete principios del proceso de prueba.

Proceso de Prueba
NB-1.4.1 (K2) Explicar el impacto del contexto en el proceso de prueba.
NB-1.4.2 (K2) Describir las actividades de prueba y las tareas correspondientes dentro del proceso de prueba.
NB-1.4.3 (K2) Diferenciar los productos de trabajo que dan soporte al proceso de prueba.
NB-1.4.4 (K2) Explicar el valor de mantener la trazabilidad entre la base de prueba y los productos de trabajo de la prueba.

La Psicología de la Prueba
NB-1.5.1 (K1) Identificar los factores psicológicos que influyen en el éxito de la prueba.
NB-1.5.2 (K2) Explicar la diferencia entre la forma de pensar requerida para las actividades de prueba y la forma de pensar requerida para las actividades de desarrollo.

¿Qué es Probar?

Identificar los objetivos característicos de la prueba.

Los objetivos característicos de la prueba pueden incluir:

  • Evaluar productos de trabajo tales como requisitos, historias de usuario, diseño y código.
  • Verificar el cumplimiento de todos los requisitos especificados.
  • Validar si el objeto de prueba está completo y funciona como los usuarios y otros implicados esperan.
  • Generar confianza en el nivel de calidad del objeto de prueba.
  • Prevenir defectos.
  • Encontrar fallos y defectos.
  • Proporcionar suficiente información a los implicados para que puedan tomar decisiones informadas, especialmente en relación con el nivel de calidad del objeto de prueba.

Diferenciar la prueba de la depuración.

La prueba y la depuración son actividades diferentes en el proceso de desarrollo de software. La prueba es la actividad de evaluar un producto de trabajo para encontrar fallos y defectos, mientras que la depuración es la actividad de desarrollo que encuentra, analiza y corrige dichos defectos. En otras palabras, la prueba se enfoca en identificar problemas en el software, mientras que la depuración se enfoca en corregir esos problemas. La prueba de confirmación posterior comprueba si las correcciones han resuelto los defectos. En algunos casos, los testeres son responsables de la prueba inicial y la prueba de confirmación final, mientras que los desarrolladores realizan la depuración y la prueba de componente asociada. Sin embargo, en el desarrollo Ágil y en algunos otros ciclos de vida, los testeres pueden estar involucrados en la depuración y la prueba de componente.

¿Por qué es Necesario Probar?

Dar ejemplos de por qué es necesario probar.

  • La prueba rigurosa de componentes y sistemas, y su documentación asociada, pueden ayudar a reducir el riesgo de que se produzcan fallos durante la operación.
  • La prueba puede ayudar a garantizar que el software cumpla con los requisitos especificados y que funcione como se espera.
  • La prueba puede ayudar a identificar problemas de rendimiento, seguridad y usabilidad en el software.
  • La prueba puede ayudar a mejorar la calidad del software y reducir los costos asociados con la corrección de errores y defectos después de la liberación.
  • La prueba puede ayudar a generar confianza en el software y en la organización que lo produce.

Describir la relación entre la prueba y el aseguramiento de la calidad y dar ejemplos de cómo probar contribuye a obtener un mayor nivel de calidad.

La prueba y el aseguramiento de la calidad están relacionados, pero son actividades diferentes. El aseguramiento de la calidad se enfoca en garantizar que se sigan los procesos adecuados para producir un producto de trabajo de alta calidad, mientras que la prueba se enfoca en evaluar el producto de trabajo para encontrar fallos y defectos. Sin embargo, la prueba es una parte importante del aseguramiento de la calidad, ya que puede ayudar a garantizar que se cumplan los requisitos y que el software funcione como se espera. Además, la prueba puede ayudar a identificar problemas de rendimiento, seguridad y usabilidad en el software, lo que puede contribuir a mejorar la calidad del producto final.

Algunos ejemplos de cómo la prueba contribuye a obtener un mayor nivel de calidad incluyen:

  • La prueba de componentes y sistemas puede ayudar a identificar problemas antes de que se produzcan fallos en la operación, lo que puede contribuir a mejorar la calidad del software y reducir los costos asociados con la corrección de errores y defectos después de la liberación.
  • La prueba puede ayudar a garantizar que el software cumpla con los requisitos especificados y que funcione como se espera, lo que puede contribuir a mejorar la calidad del producto final.
  • La prueba puede ayudar a identificar problemas de rendimiento, seguridad y usabilidad en el software, lo que puede contribuir a mejorar la calidad del producto final y la satisfacción del usuario.
  • La prueba puede ayudar a generar confianza en el software y en la organización que lo produce, lo que puede contribuir a mejorar la calidad del producto final y la reputación de la organización. 

Distinguir entre error, defecto y fallo.

  • Un error es una equivocación cometida por una persona, que puede llevar a la introducción de un defecto en el código software o en algún otro producto de trabajo relacionado.
  • Un defecto (también conocido como falta o bug) es una falla en el software que causa que no funcione como se espera. Un defecto puede ser causado por un error humano o por otros factores, como problemas de diseño o problemas de implementación.
  • Un fallo es la ocurrencia de un comportamiento incorrecto o inesperado del software en un entorno de ejecución específico. Un fallo puede ser causado por un defecto o por otros factores, como problemas de configuración o problemas de hardware.

En resumen, un error es la causa de un defecto, que a su vez puede causar un fallo en el software. La identificación y corrección de errores y defectos durante la prueba puede ayudar a reducir la probabilidad de fallos en el software.

Distinguir entre la causa raíz de un defecto y sus efectos.

  • La causa raíz de un defecto es la acción o condición más temprana que contribuyó a crear el defecto. Identificar la causa raíz de un defecto puede ayudar a prevenir la introducción de defectos similares en el futuro.
  • Los efectos de un defecto son las consecuencias de su presencia en el software. Los efectos pueden incluir fallos en el software, problemas de rendimiento, problemas de seguridad, problemas de usabilidad, etc.

En resumen, la causa raíz de un defecto es la razón por la cual se introdujo el defecto en primer lugar, mientras que los efectos son las consecuencias de la presencia del defecto en el software. Identificar la causa raíz de un defecto puede ayudar a prevenir la introducción de defectos similares en el futuro y mejorar la calidad del software.

Siete Principios de la Prueba

Explicar los siete principios del proceso de prueba.

1. La prueba muestra la presencia de defectos, no su ausencia: La prueba puede mostrar la presencia de defectos, pero no puede probar que no hay defectos. La prueba reduce la probabilidad de que queden defectos no descubiertos en el software pero, incluso si no se encuentran defectos, el proceso de prueba no es una demostración de la corrección.

2. La prueba exhaustiva es imposible: No es posible probar todo (todas las combinaciones de entradas y precondiciones) excepto en casos triviales. En lugar de intentar realizar pruebas exhaustivas se deberían utilizar el análisis de riesgos, las técnicas de prueba y las prioridades para centrar los esfuerzos de prueba.

3. La detección temprana de defectos es importante: Cuanto antes se detecte un defecto, más fácil será corregirlo y menos costoso será hacerlo. Por lo tanto, es importante comenzar a probar lo antes posible en el ciclo de vida del software.

4. La agrupación de defectos similares ayuda a su comprensión: Agrupar los defectos similares puede ayudar a comprender mejor las causas subyacentes y a tomar medidas para prevenir la introducción de defectos similares en el futuro.

5. La prueba depende del contexto: El proceso de prueba debe adaptarse al contexto del software que se está probando, incluyendo los requisitos, la complejidad, el riesgo y las restricciones del proyecto.

6. La ausencia de errores no garantiza la calidad: La ausencia de errores conocidos no garantiza que el software sea de alta calidad. La calidad del software también depende de otros factores, como la usabilidad, el rendimiento, la seguridad y la satisfacción del usuario.

7. La prueba es un proceso de aprendizaje continuo: La prueba es un proceso de aprendizaje continuo que puede ayudar a mejorar la calidad del software y el proceso de desarrollo en general. La retroalimentación de las pruebas puede ayudar a identificar áreas de mejora y a guiar la toma de decisiones en el futuro. [

Proceso de Prueba

Explicar el impacto del contexto en el proceso de prueba.

El contexto del software que se está probando tiene un impacto significativo en el proceso de prueba. El contexto incluye factores como los requisitos del software, la complejidad del software, el riesgo del proyecto, las restricciones del proyecto y las expectativas del usuario. Estos factores pueden influir en las decisiones que se toman sobre qué pruebas realizar, cómo realizarlas y cuándo realizarlas.

Por ejemplo, si el software es crítico para la seguridad, se pueden requerir pruebas más rigurosas y exhaustivas para garantizar que el software sea seguro y confiable. Si el software es muy complejo, se pueden requerir pruebas más detalladas y exhaustivas para garantizar que todas las funcionalidades se hayan probado adecuadamente. Si el software tiene requisitos de rendimiento estrictos, se pueden requerir pruebas de carga y estrés para garantizar que el software pueda manejar la carga esperada.

En resumen, el contexto del software que se está probando tiene un impacto significativo en el proceso de prueba. Los factores del contexto pueden influir en las decisiones que se toman sobre qué pruebas realizar, cómo realizarlas y cuándo realizarlas. Es importante adaptar el proceso de prueba al contexto del software para garantizar que se realicen las pruebas adecuadas y se logren los objetivos de calidad del software.

Describir las actividades de prueba y las tareas correspondientes dentro del proceso de prueba.

1. Planificación de la prueba: Esta actividad implica la definición de los objetivos de la prueba, la identificación de los riesgos y la selección de las técnicas de prueba adecuadas. Las tareas correspondientes incluyen la elaboración del plan de prueba, la estimación de los recursos necesarios y la definición de los criterios de salida.

2. Diseño de la prueba: Esta actividad implica la creación de casos de prueba y la definición de los datos de prueba necesarios. Las tareas correspondientes incluyen la elaboración de los casos de prueba, la selección de los datos de prueba y la definición de los procedimientos de prueba.

3. Implementación de la prueba: Esta actividad implica la ejecución de los casos de prueba y la recopilación de los resultados de la prueba. Las tareas correspondientes incluyen la preparación del entorno de prueba, la ejecución de los casos de prueba y la documentación de los resultados de la prueba.

4. Evaluación de la prueba: Esta actividad implica la revisión de los resultados de la prueba y la identificación de los defectos. Las tareas correspondientes incluyen la revisión de los resultados de la prueba, la identificación de los defectos y la documentación de los defectos.

5. Informe de la prueba: Esta actividad implica la comunicación de los resultados de la prueba a los interesados. Las tareas correspondientes incluyen la elaboración del informe de la prueba, la presentación de los resultados de la prueba y la documentación de los resultados de la prueba.

En resumen, las actividades de prueba incluyen la planificación de la prueba, el diseño de la prueba, la implementación de la prueba, la evaluación de la prueba y el informe de la prueba. Cada actividad incluye tareas específicas que deben realizarse para lograr los objetivos de calidad del software.

Diferenciar los productos de trabajo que dan soporte al proceso de prueba.

Los productos de trabajo que dan soporte al proceso de prueba se pueden dividir en dos categorías: productos de trabajo de la planificación de la prueba y productos de trabajo de la ejecución de la prueba.

Los productos de trabajo de la planificación de la prueba incluyen el plan de prueba, la estrategia de prueba, la especificación de requisitos de prueba, la especificación de diseño de prueba y la especificación de casos de prueba. Estos productos de trabajo se crean durante la planificación de la prueba y se utilizan para guiar la ejecución de la prueba.

Los productos de trabajo de la ejecución de la prueba incluyen los casos de prueba, los resultados de la prueba, los informes de defectos y los informes de progreso de la prueba. Estos productos de trabajo se crean durante la ejecución de la prueba y se utilizan para evaluar la calidad del software y para informar a los interesados sobre el progreso de la prueba.

Además de estos productos de trabajo, también se pueden crear otros productos de trabajo durante el proceso de prueba, como los informes de revisión de la prueba, los informes de seguimiento de la prueba y los informes de cierre de la prueba. Estos productos de trabajo se utilizan para documentar y comunicar los resultados de la prueba y para mejorar el proceso de prueba en el futuro.

En resumen, los productos de trabajo que dan soporte al proceso de prueba se pueden dividir en productos de trabajo de la planificación de la prueba y productos de trabajo de la ejecución de la prueba. Cada uno de estos productos de trabajo se utiliza para guiar y evaluar el proceso de prueba y para informar a los interesados sobre el progreso y los resultados de la prueba.

Explicar el valor de mantener la trazabilidad entre la base de prueba y los productos de trabajo de la prueba.

La trazabilidad entre la base de prueba y los productos de trabajo de la prueba es importante porque permite rastrear la relación entre los requisitos, los casos de prueba y los resultados de la prueba. Esto significa que se puede determinar si todos los requisitos se han probado adecuadamente y si se han identificado todos los defectos relacionados con los requisitos.

Además, la trazabilidad permite analizar el impacto de los cambios en los requisitos en el proceso de prueba. Si se realiza un cambio en un requisito, se puede determinar qué casos de prueba se ven afectados por el cambio y se pueden actualizar los casos de prueba correspondientes. Esto ayuda a garantizar que se prueben todas las funcionalidades del software y que se identifiquen todos los defectos relacionados con los cambios en los requisitos.

La trazabilidad también permite que la prueba sea auditada y que se cumplan los criterios de gobernanza de TI. Al mantener la trazabilidad, se puede demostrar que se han realizado todas las pruebas necesarias y que se han identificado todos los defectos relacionados con los requisitos. Esto ayuda a garantizar que el software sea de alta calidad y que cumpla con los estándares de gobernanza de TI.

Además, la trazabilidad mejora la comprensión de los informes de avance de la prueba y de los informes resumen de prueba. Al relacionar los aspectos técnicos de la prueba con los implicados en términos que éstos puedan entender, se puede comunicar de manera efectiva el progreso de la prueba y los resultados de la prueba a los interesados.

En resumen, mantener la trazabilidad entre la base de prueba y los productos de trabajo de la prueba es importante porque permite rastrear la relación entre los requisitos, los casos de prueba y los resultados de la prueba, analizar el impacto de los cambios en los requisitos, auditar la prueba y cumplir con los criterios de gobernanza de TI, y mejorar la comprensión de los informes de avance de la prueba y de los informes resumen de prueba.

La Psicología de la Prueba

Identificar los factores psicológicos que influyen en el éxito de la prueba.

La psicología humana tiene efectos importantes en la prueba de software. Algunos de los factores psicológicos que influyen en el éxito de la prueba son:

1. Sesgo de confirmación: Este es un elemento de la psicología humana que hace difícil aceptar información que esté en desacuerdo con las creencias actuales. Por ejemplo, los desarrolladores pueden tener un sesgo de confirmación que hace difícil aceptar que su código sea incorrecto.

2. Resistencia al cambio: Los seres humanos tienen una tendencia natural a resistirse al cambio. Esto puede hacer que los desarrolladores sean reacios a realizar cambios en el software que puedan afectar la calidad de la prueba.

3. Fatiga mental: La fatiga mental puede afectar la capacidad de los testeres para identificar defectos y realizar pruebas de manera efectiva. Es importante que los testeres tomen descansos regulares y eviten trabajar durante largos períodos de tiempo sin descanso.

4. Presión de tiempo: La presión de tiempo puede hacer que los testeres se salten pasos importantes en el proceso de prueba o que no realicen pruebas exhaustivas. Es importante que los testeres tengan suficiente tiempo para realizar pruebas adecuadas y que se les proporcione un calendario realista para completar las pruebas.

5. Comunicación ineficaz: La comunicación ineficaz entre los miembros del equipo de prueba puede llevar a malentendidos y errores en el proceso de prueba. Es importante que los miembros del equipo de prueba se comuniquen de manera efectiva y que se establezcan canales claros de comunicación.

En resumen, algunos de los factores psicológicos que influyen en el éxito de la prueba son el sesgo de confirmación, la resistencia al cambio, la fatiga mental, la presión de tiempo y la comunicación ineficaz. Es importante que los testeres y los miembros del equipo de prueba sean conscientes de estos factores y trabajen juntos para minimizar su impacto en el proceso de prueba.

Explicar la diferencia entre la forma de pensar requerida para las actividades de prueba y la forma de pensar requerida para las actividades de desarrollo.

La forma de pensar requerida para las actividades de prueba y la forma de pensar requerida para las actividades de desarrollo son diferentes debido a los diferentes objetivos y enfoques de cada actividad.

La forma de pensar requerida para las actividades de desarrollo se centra en el diseño y la construcción de soluciones. Los desarrolladores están más interesados en crear soluciones que en contemplar lo que podría estar mal en esas soluciones. Su objetivo principal es diseñar y construir un producto que cumpla con los requisitos del cliente y que sea fácil de mantener y extender en el futuro.

Por otro lado, la forma de pensar requerida para las actividades de prueba se centra en la verificación y validación del producto, la detección de defectos antes de liberarlo y la mejora de la calidad del software. Los testeres están más interesados en encontrar errores y defectos en el software que en diseñar y construir soluciones. Su objetivo principal es asegurarse de que el software cumpla con los requisitos del cliente y que sea de alta calidad.

La forma de pensar requerida para las actividades de prueba también requiere una mentalidad que incluya curiosidad, pesimismo profesional, sentido crítico, atención al detalle y motivación para una comunicación y relaciones buenas y positivas. Los testeres deben ser curiosos y estar dispuestos a explorar el software en busca de defectos. También deben ser críticos y estar dispuestos a cuestionar el software y el proceso de prueba. Además, deben ser detallistas y estar dispuestos a revisar minuciosamente el software en busca de defectos.

En resumen, la forma de pensar requerida para las actividades de prueba y la forma de pensar requerida para las actividades de desarrollo son diferentes debido a los diferentes objetivos y enfoques de cada actividad. Los desarrolladores se centran en el diseño y la construcción de soluciones, mientras que los testeres se centran en la verificación y validación del producto y la detección de defectos. La forma de pensar requerida para las actividades de prueba también requiere una mentalidad que incluya curiosidad, pesimismo profesional, sentido crítico, atención al detalle y motivación.

Comentario final

¿Te ha sido útil el contenido? Me ayudarías y mucho si consideras que vale compartir este artículo entre tus amigos y  poder así enterarte cuando publique contenidos relacionados con las certificaciones, con las buenas prácticas, con herramientas y con testing aplicado en inteligencia artificial.

Buscame y seguime en LinkedIn para conocer las opiniones de colegas respecto de los contenidos que publico y por supuesto me ayudarías y mucho si consideras que vale dejar un like, dejar comentarios, compartirlo con tus amigos.

Gus Terrera

Apasionado por el agile testing y la ia.