El plan y las pruebas basadas en riesgos
En resumen: Siempre hay menos tiempo para probar del necesario. El plan dice qué, cómo, quién y cuándo; los criterios de entrada y de salida dicen cuándo empezar y cuándo parar. El riesgo, probabilidad por impacto, ordena qué probar primero y con qué profundidad.
Problema
Cuatro días para dos semanas de trabajo
La nueva versión de la tienda tiene un código promocional nuevo, un umbral de envío cambiado y correcciones en el pago. Los testers dicen: necesitamos dos semanas para todo. El lanzamiento es en cuatro días, y no se moverá, porque la publicidad de la oferta ya está en marcha.
¿Qué vas a probar? Si empiezas por lo primero de la lista, el cuarto día seguirás comprobando la página «Quiénes somos», y el código promocional saldrá sin probar.
La idea
El plan: qué, cómo, quién, cuándo
El plan de pruebas es el acuerdo del equipo sobre las pruebas. No es un formulario, sino respuestas a preguntas:
- Qué se prueba y qué no (alcance), y por qué;
- cómo: los niveles, los tipos, las técnicas, qué se automatiza;
- quién y con qué: las personas, el entorno, los datos, las herramientas;
- cuándo: el calendario y los criterios de entrada y de salida;
- los riesgos y qué se hace con ellos;
- cómo se informa: quién ve qué, y cuándo.
En un proyecto en cascada el plan es un documento. En un equipo ágil es media página y una conversación al principio de la iteración. Las preguntas son las mismas.
Más precisamente, para curiosos
El plan de pruebas es CTFL v4.0.1, sección 5.1.1. Un documento de plan de pruebas según ISO/IEC/IEEE 29119-3 tiene más campos (contexto, comunicación, registro de riesgos, estrategia, personal, calendario). El examen pregunta por el propósito del plan y su contenido típico, no por una plantilla exacta.
La idea
¿Cuánto va a tardar?
Estimar las pruebas no es adivinar. Hay unas cuantas técnicas sencillas:
- Basada en ratios: en versiones pasadas las pruebas fueron el 30 % del tiempo de programación. Ahora la programación son 20 días, así que las pruebas son unos 6.
- De tres puntos: pides el mejor caso (a), el más probable (m) y el peor (b). La estimación es (a + 4m + b) / 6. El peor caso la sube, y eso es honesto.
- Con el equipo: cada uno estima por su cuenta, luego se comparan y se discute la diferencia. Las cartas de Planning Poker en el desarrollo ágil funcionan así.
Una estimación es una estimación. Se dice con su supuesto: «5 días, si el entorno está listo el lunes».
Más precisamente, para curiosos
CTFL v4.0.1, sección 5.1.4, enumera cuatro técnicas: estimación basada en ratios, extrapolación, Wideband Delphi (de la que Planning Poker es una variante) y estimación de tres puntos. Para los tres puntos el plan de estudios da también la desviación típica: (b − a) / 6.
Pruébalo
Estima
La idea
Cuándo empiezas y cuándo paras
Las pruebas no tienen un final natural: siempre hay más defectos. Por eso se acuerdan los criterios de entrada y de salida:
- Entrada: cuándo tiene sentido empezar. La versión está en el entorno de pruebas, las pruebas de componente pasan, los datos de prueba están cargados, las historias tienen criterios de aceptación.
- Salida: cuándo paras. Todas las pruebas de riesgo alto pasan; no hay ningún defecto abierto de gravedad crítica; el conjunto de regresión está en verde; los riesgos restantes están anotados y aceptados.
Un criterio se comprueba, no se siente. «Estamos listos» es una opinión, «0 defectos críticos abiertos» es un hecho.
En un equipo ágil los criterios de salida de una historia están en la Definition of Done, y los de entrada en la Definition of Ready.
Pruébalo
¿Podemos empezar? ¿Podemos parar?
La idea
El riesgo dice qué va primero
Probarlo todo es imposible, y no hay tiempo suficiente. La pregunta es qué probar primero y con más profundidad. La respuesta es el riesgo.
Un riesgo es algo que puede ocurrir y hará daño. Tiene dos medidas:
- probabilidad: ¿qué tan probable es un defecto aquí? Código nuevo, código complejo, código cambiado con prisa, partes con muchos defectos hasta ahora;
- impacto: ¿cuánto daño habría si lo hay? Dinero, muchos clientes, la ley, la reputación.
El nivel de riesgo es probabilidad por impacto. El código promocional, reescrito desde cero (probabilidad 5), que puede regalar dinero (impacto 4), es 20. La página «Quiénes somos» con un teléfono nuevo es 1.
Las pruebas basadas en riesgos ordenan las pruebas por este número: el riesgo alto se prueba primero, con más técnicas y más casos; el riesgo bajo al final, o solo con un vistazo rápido. Si el tiempo se acaba, lo que queda sin probar es lo menos peligroso.
Más precisamente, para curiosos
El riesgo es CTFL v4.0.1, sección 5.2. El plan de estudios distingue los riesgos del producto (que el producto no haga lo que debe: un total equivocado, un carrito lento) de los riesgos del proyecto (algo que estorba al trabajo: un entorno que llega tarde, una persona de baja). El análisis de riesgos del producto tiene dos partes, identificación y evaluación, y los riesgos se controlan con mitigación (pruebas) y seguimiento. Las escalas de 1 a 5 de aquí son un ejemplo: en la práctica también hay escalas como baja, media, alta.
Ejercicio
Pruebas basadas en riesgos
1. Ordena por riesgo. Los cuatro días del principio. Ordena las partes de la tienda en el orden en que las vas a probar: el riesgo más alto (probabilidad por impacto) arriba.
Ordena del riesgo más alto al más bajo.
Devoluciones: intactas (probabilidad 1, impacto 3)Código promocional: reescrito en esta versión (probabilidad 5, impacto 4)Envío: se cambió el umbral (probabilidad 4, impacto 3)Página «Quiénes somos»: se cambió el teléfono (probabilidad 1, impacto 1)Pago con tarjeta: intacto, pero todo pasa por él (probabilidad 2, impacto 5)Límite del carrito: intacto (probabilidad 2, impacto 2)
El código promocional es 5 · 4 = 20, el envío 4 · 3 = 12, el pago 2 · 5 = 10, el límite 2 · 2 = 4, las devoluciones 1 · 3 = 3, «Quiénes somos» 1 · 1 = 1. El pago es tercero aunque sea lo más dañino: nadie lo tocó. Pero no sale del plan: sus pruebas de regresión están automatizadas y se ejecutan con cada cambio.
Test