Las pruebas en el ciclo de vida
En resumen: El modelo de desarrollo cambia cuándo pruebas, no si pruebas. En cascada las pruebas son una fase al final, en el desarrollo ágil están en cada historia, en DevOps están en el pipeline con cada cambio. Shift-left acerca la comprobación al requisito. La pirámide dice cuántas pruebas hay en cada nivel, y los cuadrantes de qué tipos.
Problema
Los testers recibieron la tienda en el último mes
El proyecto de la nueva tienda va según el plan: 3 meses de requisitos, 6 meses de programación, luego las pruebas. En el último mes los testers encuentran 140 defectos. 30 de ellos no están en el código sino en los requisitos: «dentro de 14 días» sin decir desde cuándo, «más de 50 €» sin decir si es inclusive.
Corregir un requisito en el mes 10 significa tocar código escrito en el mes 4. El lanzamiento se retrasa 3 meses.
La idea
El modelo cambia cuándo, no si
Todo modelo de ciclo de vida del desarrollo de software tiene pruebas. Lo que difiere es cuándo y cómo:
| Modelo | Dónde están las pruebas |
|---|---|
| Cascada | Una fase aparte al final, después de todo el código. |
| Modelo en V | Cada fase tiene su propio nivel de prueba, planificado desde el principio: requisitos → aceptación, arquitectura → integración. |
| Iterativo, incremental | En cada iteración se prueba la parte nueva, y todo lo viejo con pruebas de regresión. |
| Ágil (Scrum, Kanban) | En cada historia. QA está en el equipo, y «hecho» significa también probado (Definition of Done). |
| DevOps | En el pipeline (CI/CD): cada cambio pasa automáticamente por las pruebas antes de llegar a los clientes. |
Una regla vale para todos: para cada actividad de desarrollo hay una actividad de prueba correspondiente. Un requisito tiene una revisión, el código tiene una prueba, una historia tiene criterios de aceptación.
Más precisamente, para curiosos
Esto es CTFL v4.0.1, sección 2.1. El plan de estudios enumera buenas prácticas que valen para todos los modelos: cada actividad de desarrollo tiene una actividad de prueba correspondiente; cada nivel de prueba tiene sus propios objetivos; el análisis y el diseño de pruebas empiezan durante la fase de desarrollo correspondiente; los testers revisan los productos de trabajo en cuanto hay borradores. DevOps está en 2.1.4, y shift-left en 2.1.5.
Pruébalo
¿Qué modelo?
La idea
Shift-left: hacia la izquierda en el tiempo
Dibuja el proyecto como una línea: requisito, diseño, código, prueba, lanzamiento. Shift-left significa mover la comprobación hacia la izquierda, hacia el principio.
En la tienda son cosas que ya has visto en el curso:
- revisar el requisito «envío gratis desde 50 €» antes del código: ¿incluye 50,00 €?
- Example Mapping y ejemplos para cada regla, antes de que la historia entre en trabajo;
- escenarios escritos antes del código, que luego se convierten en pruebas automáticas;
- pruebas de componente que el programador ejecuta con cada cambio.
Shift-left no significa menos pruebas al final. Significa que al final encuentras menos, porque la mayoría de los defectos se atraparon donde cuestan menos.
Más precisamente, para curiosos
Shift-left tiene un precio: formación, tiempo al principio, automatización. CTFL v4.0.1 también lo dice: el enfoque requiere esfuerzo al comienzo, y el ahorro llega después. La idea contraria, shift-right, son las pruebas y la monitorización después del lanzamiento: medir con clientes reales, desplegar funciones nuevas poco a poco. De eso trata el módulo «Validar con el cliente».
La idea
La pirámide: cuántas pruebas en cada nivel
La pirámide de pruebas dice cuántas pruebas tener en cada nivel:
- La base: muchas pruebas de componente. Miles, que se ejecutan en segundos y señalan exactamente el error.
- El medio: menos pruebas de integración y de servicios. Comprueban los contratos entre las partes.
- La cima: unas pocas pruebas de punta a punta a través de toda la tienda y el navegador. Son lentas, se rompen cuando cambia un botón, y cuando fallan todavía no sabes dónde está el error.
Cuanto más arriba, más lentas, caras y frágiles son las pruebas, y menos deberían ser. La pirámide al revés, con miles de pruebas de navegador y unas pocas de componente, se llama el cono de helado.
Más precisamente, para curiosos
La pirámide es de Mike Cohn («Succeeding with Agile», 2009). No es una ley: el número de niveles y sus nombres varían. CTFL v4.0.1 la describe en la sección 5.1.6 como un modelo que muestra que las pruebas de los niveles bajos son más pequeñas, más rápidas y más numerosas, y las de los niveles altos más lentas, más grandes y menos.
La idea
Los cuadrantes: qué tipos
La pirámide cuenta. Los cuadrantes de pruebas ordenan los tipos con dos preguntas: ¿la prueba está orientada al negocio o a la tecnología?, y ¿apoya al equipo mientras construye o critica el producto terminado?
| Apoyan al equipo | Critican el producto | |
|---|---|---|
| Negocio | Q2: escenarios y ejemplos, prototipos, pruebas funcionales | Q3: pruebas exploratorias, usabilidad, UAT, demos |
| Tecnología | Q1: pruebas de componente y de integración | Q4: desempeño, carga, seguridad |
Q1 y Q2 suelen automatizarse. Q3 es manual: una persona mira el producto. Q4 se hace con herramientas. Un equipo que solo tiene Q1 tiene código rápido, pero no sabe si es el producto correcto.
Más precisamente, para curiosos
Los cuadrantes son de Brian Marick (2003), popularizados por los libros de Lisa Crispin y Janet Gregory sobre pruebas ágiles. En CTFL v4.0.1 están en la sección 5.1.7.
Ejercicio
Los cuadrantes en la tienda
1. ¿Qué cuadrante? Clasifica las pruebas de la tienda.
Test