Por qué y qué automatizar
En resumen: Una prueba automática es un programa que ejecuta el sistema y compara el resultado, sin que intervenga una persona. Compensa para reglas que cambian poco, se comprueban con cada cambio y cuestan dinero cuando se rompen. No compensa para una comprobación única, para una pantalla que aún cambia, ni para nada que necesite criterio humano. Su coste real es el mantenimiento.
Problema
Dos días de pruebas manuales cada semana
La tienda lanza una versión nueva cada viernes. Antes de cada lanzamiento QA pasa a mano 120 casos de prueba: envío, carrito, códigos promocionales, devoluciones. Lleva dos días.
La semana pasada hubo un festivo, y hubo tiempo para 80. Los 40 que se saltaron eran «los viejos, esos no se rompen». El lunes un cliente pagó envío en un pedido de exactamente 50,00 €. El cambio estaba en la lógica del código promocional, y rompió el límite del envío.
La idea
Automatización de pruebas
La automatización de pruebas es un programa que ejecuta el sistema, le da la entrada del caso de prueba y compara el resultado con el esperado. Sin que intervenga una persona, e igual en cada ejecución.
Lo que te da:
- la regresión se vuelve barata. 120 casos se ejecutan en minutos, con cada cambio, no durante dos días una vez a la semana;
- igual cada vez. Un programa no se cansa en el caso 80 y no se salta «los viejos»;
- respuesta rápida. El programador se entera cinco minutos después de que el límite está roto, cuando aún recuerda lo que tocó;
- la documentación viva se ejecuta. Los escenarios del módulo de Gherkin dejan de ser texto en una carpeta: se convierten en una comprobación que pasa o falla.
La automatización no inventa pruebas. Una persona sigue escribiendo el caso de prueba. La automatización lo repite.
La idea
Qué compensa y qué no
Una prueba automática se paga una vez al escribirla y luego con cada cambio. Así que compensa cuando se ejecuta muchas veces y cambia pocas.
Compensa para:
- reglas que no cambian cada semana: envío, límite del carrito, descuentos;
- comprobaciones antes de cada lanzamiento (regresión);
- muchos ejemplos de la misma regla: diez importes alrededor del límite;
- lugares donde un error cuesta dinero o confianza.
No compensa (o todavía no) para:
- una comprobación única: una migración de datos que ocurre una vez;
- una pantalla que el diseñador aún cambia todos los días;
- todo lo que necesita criterio: si el formulario es claro, si se ve bien, si es cómodo. Eso es usabilidad, y lo miran las personas;
- pruebas exploratorias: ahí la pregunta se inventa mientras pruebas.
Pruébalo
¿Automatizar o no?
La idea
Los riesgos
La automatización suele fallar no por la herramienta sino por las expectativas:
- «Encontrará todos los defectos». Una prueba comprueba solo lo que alguien pensó. Si nadie pensó en el carrito vacío, la automatización no lo comprobará, por muchas veces que se ejecute. Los mutantes del módulo de Gherkin se escaparon justo así.
- Mantenimiento subestimado. Las pruebas son código. Cuando el umbral pasa a 60 €, cambian los escenarios, los pasos y las pruebas. Si nadie los mantiene, un mes después la mitad están en rojo y el equipo deja de mirar.
- Una prueba en la que nadie confía. Si una prueba falla «a veces», la gente la vuelve a ejecutar hasta que pasa. Entonces se cuela también un fallo real.
- Todo a través de la pantalla. Las pruebas a través del navegador son lentas y se rompen cuando se mueve un botón. La mayoría de las comprobaciones van más abajo.
- La herramienta como objetivo. «Compramos una herramienta» no es una estrategia. Primero va qué hay que comprobar, luego con qué comprobarlo.
Más precisamente, para curiosos
ISTQB CTFL v4.0.1 trata las herramientas en el capítulo 6. La sección 6.2 enumera los beneficios, entre ellos menos trabajo manual repetitivo, más consistencia, respuesta más rápida y más tiempo para pruebas nuevas, y los riesgos, entre ellos expectativas poco realistas, estimaciones inexactas de tiempo y coste (incluido el mantenimiento), usar una herramienta donde las pruebas manuales son más adecuadas, depender demasiado de una herramienta e ignorar el pensamiento crítico humano, y la dependencia del proveedor de la herramienta o de un software de código abierto que puede abandonarse.
Para quienes van a escribir automatización como profesión, ISTQB tiene una certificación avanzada aparte: CTAL-TAE (Test Automation Engineering). Trata de la arquitectura de la automatización y no forma parte de este curso.
La idea
Qué nivel para qué comprobación
La pirámide del módulo de niveles dice cuántas pruebas hay en cada nivel. En la automatización se vuelve concreta:
- los escenarios (la siguiente lección) comprueban la regla con las palabras del negocio. Son la documentación viva;
- las pruebas de componente comprueban un trozo de código, rápido y con muchos ejemplos: diez importes alrededor del límite en milisegundos;
- las pruebas de API envían peticiones reales al servidor de la tienda, sin navegador;
- las pruebas de interfaz abren un navegador y hacen clic como el cliente. Solo unas pocas, para los caminos que no pueden romperse.
En este módulo la regla se mantiene igual todo el tiempo: el envío es gratis desde 50,00 € inclusive, si no es de 4,90 €, y un carrito vacío se rechaza. La verás automatizada en cada nivel, en Java, C#, Python y JavaScript, y verás qué prueba atrapa qué error.
Aquí necesitas saber leer código en uno de los cuatro lenguajes. Lo que necesitas está en el curso de programación, hasta el módulo «Programas en el mundo real»: clases, excepciones y pruebas de componente.
Pruébalo
El camino de una regla
Ordena el camino de la regla del envío, desde el acuerdo hasta el informe.
El informe dice qué falló y por quéLa regla se comprueba también con pruebas de componenteLa regla se acuerda y se escribe como un escenarioLas pruebas se ejecutan con cada cambio del códigoEl escenario se conecta con el código mediante pasos
Este es también el plan del módulo: los pasos, las pruebas de componente, la API y la pantalla, luego CI y el informe. El escenario va primero porque es la regla acordada. El código de las pruebas viene después.
Ejercicio
Un plan de automatización
1. Qué primero y por qué. La tienda está empezando con la automatización.
Test