Pruebas ágiles: cuadrantes
Como en el caso de las pruebas tradicionales, las pruebas ágiles también deben cubrir todos los niveles de prueba.
- Examen de la unidad
- Pruebas de integración
- Prueba del sistema
- Pruebas de aceptación del usuario
Examen de la unidad
- Hecho junto con la codificación, por el desarrollador
- Apoyado por Tester que escribe casos de prueba asegurando una cobertura de diseño del 100%
- Los casos de prueba unitaria y los resultados de las pruebas unitarias deben revisarse
- Los defectos importantes no resueltos (según la prioridad y la gravedad) no se dejan
- Todas las pruebas unitarias están automatizadas
Pruebas de integración
- Se realiza junto con la integración continua a medida que avanzan los Sprints
- Hecho al final después de que se completen todos los Sprints
- Todos los requisitos funcionales se prueban
- Todas las interfaces entre unidades se prueban
- Se informan todos los defectos
- Las pruebas se automatizan siempre que sea posible
Prueba del sistema
- Hecho a medida que avanza el desarrollo
- Se prueban las historias, características y funciones de los usuarios
- Pruebas realizadas en entorno de producción
- Se realizan pruebas de calidad (rendimiento, fiabilidad, etc.)
- Se informan los defectos
- Las pruebas se automatizan siempre que sea posible
Pruebas de aceptación del usuario
Realizado al final de cada Sprint y al final del proyecto
Realizado por el Cliente. El equipo recibe comentarios
La retroalimentación será una entrada para Sprints posteriores
Las historias de usuario en un Sprint se verifican previamente para que se puedan probar y tienen criterios de aceptación definidos
Tipos de prueba
- Pruebas de componentes (pruebas unitarias)
- Pruebas funcionales (pruebas de historias de usuario)
- Pruebas no funcionales (rendimiento, carga, estrés, etc.)
- Prueba de aceptacion
Las pruebas pueden ser totalmente manuales, totalmente automatizadas, una combinación de manual y automatizada o manuales compatibles con herramientas.
Programación de soporte y pruebas de productos críticos
Las pruebas pueden ser para:
Supporting Development (Support Programming) - Los programadores utilizan las pruebas de programación de soporte.
Para decidir qué código necesitan escribir para lograr un cierto comportamiento de un sistema
Qué pruebas deben ejecutarse después de la codificación para garantizar que el nuevo código no obstaculice el resto de los comportamientos del sistema
Verification only (Critique Product) - Las pruebas de producto crítico se utilizan para descubrir deficiencias en el producto terminado
Pruebas de orientación empresarial y tecnológica
Para decidir qué pruebas se realizarán y cuándo, debe determinar si una prueba es:
- Orientación empresarial, o
- Frente a la tecnología
Pruebas de cara al negocio
Una prueba es una prueba orientada a los negocios si responde a las preguntas enmarcadas con palabras del dominio empresarial. Estos son entendidos por los expertos en negocios y les interesarían para que el comportamiento del sistema se pueda explicar en el escenario en tiempo real.
Pruebas de tecnología
Una prueba es una prueba orientada a la tecnología si responde a las preguntas enmarcadas con palabras del dominio de la tecnología. Los programadores entienden lo que debe implementarse en función de las aclaraciones sobre tecnología.
Estos dos aspectos de los tipos de prueba se pueden ver utilizando los Cuadrantes de prueba ágiles definidos por Brian Marick.
Cuadrantes de pruebas ágiles
Combinando los dos aspectos de los tipos de prueba, Brian Marick deriva los siguientes cuadrantes de prueba ágiles:
Los cuadrantes de pruebas ágiles proporcionan una taxonomía útil para ayudar a los equipos a identificar, planificar y ejecutar las pruebas necesarias.
Quadrant Q1- Unit Level, Technology Facing y apoya a los desarrolladores. Las pruebas unitarias pertenecen a este cuadrante. Estas pruebas pueden ser pruebas automatizadas.
Quadrant Q2- Nivel de sistema, orientación empresarial y comportamiento del producto conforme. Las pruebas funcionales pertenecen a este cuadrante. Estas pruebas son manuales o automatizadas.
Quadrant Q3- Nivel de aceptación del sistema o usuario, Business Facing y enfoque en escenarios en tiempo real. Las pruebas de aceptación del usuario pertenecen a este cuadrante. Estas pruebas son manuales.
Quadrant Q4- Nivel de aceptación operativa o del sistema, tecnología frente y enfoque en rendimiento, carga, estrés, mantenibilidad, pruebas de escalabilidad. Se pueden utilizar herramientas especiales para estas pruebas junto con las pruebas de automatización.
Combinando estos, los cuadrantes de pruebas ágiles que reflejan What-Testing-When se puede visualizar de la siguiente manera:
