Niveles de prueba
En resumen: Probar no es una sola cosa. En el nivel de componente se comprueba una regla por sí sola, en la integración si las partes se entienden entre sí, en el sistema todo el comportamiento, y en la aceptación si es lo que quiere el negocio. Cada nivel atrapa errores que los demás se pierden.
Problema
Todo pasa, y el dinero no cuadra
Los programadores de la tienda tienen 400 pruebas para el envío y el código promocional. Todas pasan. El tester ha recorrido todo el camino del pedido: carrito, envío, pago. Todo bien.
El primer día después del lanzamiento, el banco transfiere 0,50 € por un pedido de 50,00 €. El carrito envía el total en euros, y el servicio de pago lo lee en céntimos. Cada parte está bien por sí sola. El error está entre ellas, y ninguna prueba mira ahí.
La idea
Cuatro niveles, cuatro preguntas
Las pruebas se hacen en varios niveles de prueba. Cada uno hace una pregunta distinta y atrapa errores distintos:
| Nivel | La pregunta | En la tienda |
|---|---|---|
| Componente | ¿Está bien una regla por sí sola? | La función del envío con 49,99 €, 50,00 € y 50,01 € |
| Integración | ¿Se entienden bien las partes? | El carrito y el servicio de pago: ¿euros o céntimos? |
| Sistema | ¿Hace el conjunto lo que se describe? | Todo el camino: carrito, código promocional, envío, pago, correo |
| Aceptación | ¿Es esto lo que quiere el negocio? ¿Se puede usar? | Contabilidad comprueba el informe de códigos promocionales |
Los niveles no son mejores ni peores. Son redes distintas con agujeros distintos.
Más precisamente, para curiosos
ISTQB CTFL v4.0.1 describe los niveles en la sección 2.2.1 y los divide en cinco: pruebas de componente (también llamadas pruebas unitarias), pruebas de integración de componentes, pruebas de sistema, pruebas de integración de sistemas (la tienda con la mensajería, con el banco) y pruebas de aceptación. Para cada nivel el plan de estudios da el objeto de prueba, los objetivos, la base de prueba (de dónde salen los casos de prueba), los defectos típicos y quién es responsable.
La idea
Cuanto más abajo, con más precisión señala
Una prueba de componente llama a una función con 50,00 € y ve 4,90 €. Sabes exactamente dónde está el error. Se ejecuta en milisegundos y no necesita base de datos, navegador ni banco.
Una prueba de sistema ve el mismo error, pero a través de toda la tienda. Cuando falla, todavía no sabes si es el envío, el código promocional o la página. Y algunos casos son difíciles de alcanzar allí: para comprobar 49,99 € hay que llenar un carrito con exactamente esa cantidad.
Lo contrario también es cierto. Una prueba de componente no ve que el carrito y el banco cuentan en unidades distintas. Por eso hacen falta los dos niveles.
Más precisamente, para curiosos
Las pruebas de componente las suelen escribir los programadores, a menudo antes del código (TDD). Si has hecho alguno de los cursos de programación, las viste allí como pruebas con JUnit, xUnit, pytest o node:test. Aquí no escribimos código: en el módulo de automatización verás las mismas reglas como pruebas de componente en los cuatro lenguajes.
Pruébalo
¿Qué nivel lo atrapa?
La idea
La aceptación no es una sola cosa
Las pruebas de aceptación preguntan «¿se puede usar?», pero «usar» significa cosas distintas para personas distintas. Por eso hay varios tipos:
- Pruebas de aceptación de usuario (UAT): las personas que van a usar el sistema hacen con él su trabajo real. La contadora ejecuta el informe mensual.
- Pruebas de aceptación operativa: las personas que mantendrán el sistema en marcha comprueban la copia de seguridad, la restauración, la monitorización y las actualizaciones.
- Contractuales y regulatorias: la vara de medir es el contrato con el cliente o la ley. ¿Se guardan los consentimientos de cookies? ¿Está todo lo que enumera el contrato?
- Alfa y beta: personas ajenas al equipo prueban el producto. La alfa es en el entorno del desarrollador, la beta del lado de los clientes, en sus teléfonos y sus redes.
La vara de medir de la aceptación son los criterios de aceptación de las historias. Por eso los escribimos junto con el negocio, antes del código.
Pruébalo
¿Qué tipo de aceptación?
La idea
El nivel es el objetivo, no el momento
Es fácil imaginar los niveles como escalones: primero componente, luego integración, aceptación al final. En el modelo en cascada a menudo es así. Pero en un equipo ágil los cuatro pueden ocurrir para una historia en una semana: el programador escribe una prueba de componente, QA ejecuta el escenario en el sistema, y el dueño del producto lo acepta en la demo.
Un nivel se reconoce por su objetivo: qué compruebas y contra qué. No por cuándo, ni por quién.
Más precisamente, para curiosos
Los niveles van junto con los tipos de prueba (la siguiente lección). Hay pruebas funcionales y no funcionales en cada nivel: el desempeño de una función es del nivel de componente, y el desempeño de toda la tienda con 200 clientes es del nivel de sistema.
Ejercicio
Niveles en la tienda
1. ¿Qué nivel atrapa el error? Para cada error, elige el nivel más bajo en el que se ve.
Test