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 II.
Objetivos
2.1. Modelos de Ciclo de Vida del Desarrollo de Software
- NB-2.1.1 (K2) Explicar las relaciones entre las actividades de desarrollo de software y las actividades de prueba en el ciclo de vida de desarrollo de software.
- NB-2.1.2 (K1) Identificar las razones por las que los modelos de ciclo de vida de desarrollo de software deben adaptarse al contexto de las características del proyecto y del producto.
2.2. Niveles de Prueba
- NB-2.2.1 (K2) Comparar los diferentes niveles de prueba desde la perspectiva de los objetivos, bases de prueba, objetos de prueba, defectos y fallos característicos, y enfoques y responsabilidades.
2.3. Tipos de Prueba
- NB-2.3.1 (K2) Comparar los tipos de prueba funcional, no funcional y de caja blanca.
- NB-2.3.2 (K1) Reconocer que los tipos de prueba funcional, no funcional y de caja blanca tienen lugar en cualquier nivel de prueba.
- NB-2.3.3 (K2) Comparar los objetivos de la prueba de confirmación y la prueba de regresión.
2.4. Prueba de Mantenimiento
- NB-2.4.1 (K2) Recapitular los desencadenantes de la prueba de mantenimiento.
- NB-2.4.2 (K2) Describir el papel del análisis de impacto en la prueba de mantenimiento.
Desarrollo de los objetivos de aprendizaje
2.1. Modelos de Ciclo de Vida del Desarrollo de Software
NB-2.1.1 (K2) Explicar las relaciones entre las actividades de desarrollo de software y las actividades de prueba en el ciclo de vida de desarrollo de software.
En cualquier modelo de ciclo de vida de desarrollo de software, las actividades de desarrollo y las actividades de prueba están estrechamente relacionadas y se llevan a cabo de manera iterativa e incremental. Cada actividad de desarrollo tiene una actividad de prueba asociada y cada nivel de prueba tiene objetivos de prueba específicos para ese nivel. (Nota: Recordar el gráfico de la pirámide y los debates que hay si debe o no estar invertida para aplicar mejores prácticas).
En el modelo de ciclo de vida en cascada (Nota: también denominado modelo tradicional o waterfall), las actividades de desarrollo se llevan a cabo en una secuencia lógica escalonada, lo que significa que cada actividad de desarrollo se completa antes de pasar a la siguiente actividad. Las actividades de prueba se llevan a cabo después de que se haya completado cada actividad de desarrollo. Por ejemplo, las pruebas unitarias se llevan a cabo después de que se haya completado la codificación y las pruebas de integración se llevan a cabo después de que se hayan completado las pruebas unitarias.
En el modelo de ciclo de vida en espiral, las actividades de desarrollo y las actividades de prueba se llevan a cabo de manera iterativa e incremental. Cada iteración incluye actividades de desarrollo y actividades de prueba que se llevan a cabo en paralelo. Las pruebas se llevan a cabo en cada iteración para verificar que el software cumpla con los requisitos del cliente y para detectar defectos antes de pasar a la siguiente iteración.
En el modelo de ciclo de vida ágil (Nota: desde hace algunos años es el modelo que más se ha profundizado en las empresas y que lo han adoptado), las actividades de desarrollo y las actividades de prueba se llevan a cabo de manera iterativa e incremental en pequeñas iteraciones (Nota: a estas iteraciones se las entiende como Sprints). Las actividades de desarrollo incluyen el diseño, la construcción y la prueba de software que se realizan de forma continua (Nota: el concepto de desarrollo tiene embebida la actividad de testing), con el apoyo de una planificación continua. Las actividades de prueba también se llevan a cabo de forma iterativa y continua dentro de este enfoque de desarrollo.
En cualquier modelo de ciclo de vida de desarrollo de software, los testers participan en discusiones para definir y refinar los requisitos y el diseño (Nota: todo dependerá del grado de madurez que tenga el tester por supuesto), y están involucrados en la revisión de los productos de trabajo (por ejemplo, requisitos, diseño, historias de usuario, etc.) tan pronto como las versiones borrador estén disponibles. Esto ayuda a garantizar que se prueben todas las funcionalidades del software.
NB-2.1.2 (K1) Identificar las razones por las que los modelos de ciclo de vida de desarrollo de software deben adaptarse al contexto de las características del proyecto y del producto.
Los modelos de ciclo de vida de desarrollo de software deben seleccionarse y adaptarse al contexto de las características del proyecto y del producto porque cada proyecto y producto es único y tiene requisitos y objetivos específicos. Se debe seleccionar y adaptar un modelo apropiado del ciclo de vida del desarrollo de software en función del objetivo del proyecto, el tipo de producto que se está desarrollando, las prioridades del negocio (por ejemplo, el tiempo de comercialización), y los riesgos de producto y de proyecto identificados.
Por ejemplo, el desarrollo y la prueba de un sistema de gestión interna debe diferir del desarrollo y la prueba de un sistema crítico para la seguridad física, como el sistema de control de frenos de un automóvil. Como otro ejemplo, en algunos casos las cuestiones relativas a la organización y de índole cultural pueden inhibir la comunicación entre los miembros del equipo, lo que puede impedir el desarrollo iterativo.
Dependiendo del contexto del proyecto, puede ser necesario combinar o reorganizar los niveles de prueba y/o las actividades de prueba. Por lo tanto, es importante adaptar el modelo de ciclo de vida de desarrollo de software para satisfacer las necesidades específicas del proyecto y del producto.
2.2. Niveles de Prueba
NB-2.2.1 (K2) Comparar los diferentes niveles de prueba desde la perspectiva de los objetivos, bases de prueba, objetos de prueba, defectos y fallos característicos, y enfoques y responsabilidades.
Los diferentes niveles de prueba son la prueba de componente, la prueba de integración, la prueba de sistema y la prueba de aceptación.
– Objetivos: Cada nivel de prueba tiene objetivos específicos.
- La prueba de componente se centra en la verificación de la funcionalidad de los componentes individuales.
- La prueba de integración se centra en la verificación de la interacción entre los componentes.
- La prueba de sistema se centra en la verificación de que el sistema completo cumple con los requisitos.
- La prueba de aceptación se centra en la validación de que el sistema cumple con las expectativas del usuario y otros interesados.
– Bases de prueba: Las bases de prueba son diferentes para cada nivel de prueba.
- La prueba de componente se basa en las especificaciones de los componentes individuales.
- La prueba de integración se basa en las especificaciones de los componentes y en la arquitectura del sistema.
- La prueba de sistema se basa en las especificaciones del sistema completo y en los requisitos del usuario.
- La prueba de aceptación se basa en los requisitos del usuario y en los casos de uso.
– Objetos de prueba: Los objetos de prueba son diferentes para cada nivel de prueba.
- La prueba de componente se centra en los componentes individuales.
- La prueba de integración se centra en la interacción entre los componentes.
- La prueba de sistema se centra en el sistema completo.
- La prueba de aceptación se centra en el sistema completo y en los casos de uso.
– Defectos y fallos característicos: Los defectos y fallos característicos son diferentes para cada nivel de prueba.
- La prueba de componente se centra en los defectos de los componentes individuales.
- La prueba de integración se centra en los defectos de la interacción entre los componentes.
- La prueba de sistema se centra en los defectos del sistema completo.
- La prueba de aceptación se centra en los defectos que afectan a la satisfacción del usuario.
– Enfoques y responsabilidades:
Te lo explico para los diferentes niveles de prueba:
1. Prueba de componente:
Esta prueba se enfoca en verificar que los componentes individuales del software funcionen correctamente.
El enfoque de esta prueba es de caja blanca, lo que significa que se prueban la estructura interna y el código fuente del componente.
La responsabilidad de realizar esta prueba suele recaer en los desarrolladores.
2. Prueba de integración:
Esta prueba se enfoca en verificar que los componentes individuales del software funcionen correctamente cuando se integran entre sí.
El enfoque de esta prueba puede ser de caja blanca o de caja negra, dependiendo de la complejidad de la integración.
La responsabilidad de realizar esta prueba suele recaer en los desarrolladores y en los probadores.
3. Prueba de sistema:
Esta prueba se enfoca en verificar que el sistema completo funcione correctamente.
El enfoque de esta prueba es de caja negra, lo que significa que se prueban las entradas y salidas del sistema sin conocer su estructura interna.
La responsabilidad de realizar esta prueba suele recaer en los probadores.
4. Prueba de aceptación:
Esta prueba se enfoca en verificar que el software cumpla con los requisitos del cliente y que sea aceptable para su uso.
El enfoque de esta prueba puede ser de caja blanca o de caja negra, dependiendo de los requisitos del cliente.
La responsabilidad de realizar esta prueba suele recaer en los probadores y en los representantes del cliente.
En cuanto a las responsabilidades, los desarrolladores suelen ser responsables de realizar las pruebas de componente, mientras que los probadores suelen ser responsables de realizar las pruebas de integración, sistema y aceptación. Sin embargo, esto puede variar dependiendo de la organización y del proyecto en particular.
2.3. Tipos de Prueba
NB-2.3.1 (K2) Comparar los tipos de prueba funcional, no funcional y de caja blanca.
Los aspectos a compararar son los siguientes: Objetivos, Bases de Prueba, Enfoque, Responsabilidades, Tipos de Prueba.
– Objetivos:
- Los objetivos de las pruebas funcionales son verificar que el software cumpla con los requisitos funcionales y que se comporte de acuerdo a lo esperado.
- Los objetivos de las pruebas no funcionales son verificar que el software cumpla con los requisitos no funcionales, como la usabilidad, la seguridad, el rendimiento, entre otros.
- Los objetivos de las pruebas de caja blanca son verificar que el software cumpla con los requisitos funcionales y no funcionales, y que el código fuente esté bien estructurado y sea fácil de mantener.
– Bases de prueba:
Las bases de prueba para las pruebas funcionales y no funcionales son los requisitos del software, mientras que para las pruebas de caja blanca es el código fuente.
– Enfoque:
- El enfoque de las pruebas funcionales y no funcionales es de caja negra, es decir, se prueban las entradas y salidas del software sin conocer su estructura interna.
- El enfoque de las pruebas de caja blanca es de caja blanca, es decir, se prueban la estructura interna y el código fuente del software.
– Responsabilidades:
Las pruebas funcionales y no funcionales son responsabilidad del equipo de pruebas, mientras que las pruebas de caja blanca son responsabilidad del equipo de desarrollo.
– Tipos de pruebas:
- Los tipos de pruebas que se realizan en las pruebas funcionales incluyen pruebas de unidad, pruebas de integración, pruebas de sistema y pruebas de aceptación.
- Los tipos de pruebas que se realizan en las pruebas no funcionales incluyen pruebas de rendimiento, pruebas de seguridad, pruebas de usabilidad, entre otras.
- Los tipos de pruebas que se realizan en las pruebas de caja blanca incluyen pruebas de cobertura de código, pruebas de flujo de control, pruebas de flujo de datos, entre otras.
NB-2.3.2 (K1) Reconocer que los tipos de prueba funcional, no funcional y de caja blanca tienen lugar en cualquier nivel de prueba.
Los tipos de prueba funcional, no funcional y de caja blanca pueden tener lugar en cualquier nivel de prueba porque cada nivel de prueba se enfoca en diferentes aspectos del software y tiene diferentes objetivos. Por ejemplo, las pruebas funcionales se enfocan en verificar que el software cumpla con los requisitos funcionales, mientras que las pruebas no funcionales se enfocan en verificar que el software cumpla con los requisitos no funcionales, como la usabilidad, la seguridad y el rendimiento. Las pruebas de caja blanca se enfocan en verificar la estructura interna y el código fuente del software.
Cada nivel de prueba, como la prueba de componente, la prueba de integración, la prueba de sistema y la prueba de aceptación, tiene diferentes objetivos y se enfoca en diferentes aspectos del software. Por lo tanto, es posible realizar cualquiera de los tipos de prueba mencionados anteriormente en cualquier nivel de prueba.
Por ejemplo, en la prueba de componente, se pueden realizar pruebas funcionales y de caja blanca para verificar que los componentes individuales cumplan con los requisitos funcionales y que el código fuente esté bien estructurado. En la prueba de sistema, se pueden realizar pruebas funcionales y no funcionales para verificar que el sistema completo cumpla con los requisitos funcionales y no funcionales.
En resumen, los diferentes tipos de prueba pueden tener lugar en cualquier nivel de prueba porque cada nivel de prueba se enfoca en diferentes aspectos del software y tiene diferentes objetivos.
NB-2.3.3 (K2) Comparar los objetivos de la prueba de confirmación y la prueba de regresión.
La prueba de confirmación tiene como objetivo verificar que un defecto que ha sido corregido se ha solucionado de forma satisfactoria. Para ello, se ejecutan los casos de prueba que fallaron debido al defecto, y se verifica que el software se comporta de acuerdo a lo esperado. El enfoque de esta prueba es de caja negra, es decir, se prueban las entradas y salidas del software sin conocer su estructura interna.
Por otro lado, la prueba de regresión tiene como objetivo verificar que un cambio realizado en el software no ha afectado negativamente a otras partes del software que funcionaban correctamente anteriormente. Para ello, se ejecutan los casos de prueba que cubren las áreas afectadas por el cambio, así como otras áreas del software que podrían haber sido afectadas de forma indirecta. El enfoque de esta prueba puede ser de caja negra o de caja blanca, dependiendo de la naturaleza del cambio.
En cuanto a los aspectos en común, tanto la prueba de confirmación como la prueba de regresión se enfocan en verificar que el software funcione correctamente después de un cambio. Además, ambas pruebas pueden ser necesarias después de una corrección de defectos o después de un cambio en el software, para asegurarse de que el software sigue funcionando correctamente.
2.4. Prueba de Mantenimiento
NB-2.4.1 (K2) Recapitular los desencadenantes de la prueba de mantenimiento.
Los desencadenantes de la prueba de mantenimiento son los factores que motivan la realización de pruebas de mantenimiento en el software. Estos desencadenantes pueden ser planificados o no planificados, y pueden incluir los siguientes:
1. Modificaciones planificadas: Estos desencadenantes incluyen mejoras planificadas en el software, cambios correctivos y de emergencia, cambios en el entorno operativo (como actualizaciones previstas del sistema operativo o de la base de datos), actualizaciones del software comercial de distribución masiva («COTS» por sus siglas en inglés), y parches para los defectos y las vulnerabilidades.
2. Introducción de cosas nuevas o modificadas: Estos desencadenantes incluyen la introducción de cosas completamente nuevas o modificadas, como dispositivos de hardware y servicios de software, en el sistema global.
En cuanto a las diferencias, los desencadenantes planificados son aquellos que se han previsto y se han planificado con anticipación, mientras que los desencadenantes no planificados son aquellos que surgen de forma inesperada y requieren una respuesta rápida. Además, los desencadenantes planificados pueden ser parte de un plan de mantenimiento más amplio, mientras que los desencadenantes no planificados pueden requerir una respuesta inmediata para solucionar un problema.
En cuanto a los aspectos en común, tanto los desencadenantes planificados como los no planificados pueden requerir pruebas de mantenimiento para asegurarse de que el software sigue funcionando correctamente después de un cambio. Además, ambos tipos de desencadenantes pueden requerir un análisis de impacto para evaluar los cambios que se han realizado y para identificar las áreas del sistema que se verán afectadas por el cambio.
NB-2.4.2 (K2) Describir el papel del análisis de impacto en la prueba de mantenimiento.
El análisis de impacto es una técnica utilizada en la prueba de mantenimiento para evaluar los cambios que se han realizado en el software y para identificar las áreas del sistema que se verán afectadas por el cambio. El objetivo del análisis de impacto es identificar las consecuencias previstas, así como los efectos secundarios esperados y posibles de un cambio.
En la prueba de mantenimiento, el análisis de impacto es importante porque los cambios en el software pueden tener efectos secundarios no deseados en otras partes del sistema. Por lo tanto, es importante identificar estas áreas afectadas y realizar pruebas adicionales para asegurarse de que el software sigue funcionando correctamente después del cambio.
El análisis de impacto también puede ayudar a identificar el impacto de un cambio en las pruebas existentes. Si un cambio afecta a una parte del software que ya ha sido probada, es posible que sea necesario actualizar las pruebas existentes para asegurarse de que siguen siendo efectivas.
En resumen, el análisis de impacto es una técnica importante en la prueba de mantenimiento porque ayuda a identificar las áreas del sistema que se verán afectadas por un cambio y a asegurarse de que el software sigue funcionando correctamente después del cambio. Además, el análisis de impacto puede ayudar a identificar la necesidad de actualizar las pruebas existentes para asegurarse de que siguen siendo efectivas.
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.
