Criterios de aceptación
En resumen: Los criterios de aceptación dicen cuándo una historia está terminada, antes de que empiece el trabajo. Funcionan mejor como una regla con ejemplos concretos: «gratis desde 50,00 €» más «49,99 € → 4,90 €, 50,00 € → 0,00 €». La Definición de Terminado es la medida común para todas las historias; la Definición de Listo es una práctica de los equipos y no forma parte de la Guía de Scrum.
Problema
La cancelación que siempre funciona
La historia es «Como cliente quiero cancelar mi pedido para no pagar algo que ya no quiero». El programador pone un botón «Cancelar» en cada pedido. QA comprueba: lo pulsas, el pedido pasa a cancelado. Pasa.
Una semana después, un cliente cancela un pedido que ya está con la mensajería. Le devuelven el dinero, y el paquete llega a su puerta. El almacén pregunta quién decidió que un pedido enviado se puede cancelar.
Nadie lo decidió. Nadie escribió cuándo se permite cancelar. La historia tenía tarjeta y un poco de conversación, pero no confirmación.
La idea
Cuándo está terminada la historia
Los criterios de aceptación son las condiciones que una historia tiene que cumplir para ser aceptada. Son la tercera C, la confirmación, puesta por escrito.
Para cancelar un pedido:
- Un pedido nuevo se puede cancelar.
- Un pedido pagado se puede cancelar antes de enviarse. El dinero vuelve al cliente.
- Un pedido enviado, entregado o devuelto no se puede cancelar. El cliente ve por qué y cómo devolver el producto.
Tres líneas, y el error del principio no habría ocurrido. El programador habría sabido qué construir, QA qué comprobar y el dueño qué acepta.
Los criterios son para una historia. Se escriben antes del trabajo, juntos: el negocio, QA y el programador. Escritos después, describen lo que se construyó, no lo que hacía falta.
La idea
Regla y ejemplo
Una regla sola no basta. Dos personas leen «El envío es gratis desde 50 €» de dos maneras. Por eso junto a cada regla van ejemplos con números concretos:
Regla: el envío es gratis para un pedido desde 50,00 € inclusive, y en otro caso cuesta 4,90 €.
- Un carrito de 49,99 €: el envío cuesta 4,90 €.
- Un carrito de 50,00 €: el envío es gratis.
Regla: el código promocional no se aplica a los productos rebajados.
- Una camiseta de 20,00 € y unos vaqueros rebajados de 40,00 €. Con OTONO10 el descuento es de 2,00 €, no de 6,00 €.
Un ejemplo se lee de una manera. Nadie puede malentenderlo, y si la regla está mal, el ejemplo lo muestra: el dueño mira 49,99 € y dice «no, quiero que ese también sea gratis».
Recuerda la forma regla y ejemplo. En el módulo siguiente se convierte en un escenario de Gherkin: hay una palabra clave «Regla» (Rule), y debajo los ejemplos vienen como escenarios. Aquí todavía no hay sintaxis, solo el hábito.
Más precisamente, para curiosos
ISTQB CTFL v4.0.1 (sección 4.5.2) describe dos formatos principales para los criterios: orientado a escenarios, con «Given / When / Then» como en BDD, y orientado a reglas: una lista de verificación o una tabla de entrada → salida. Una regla con ejemplos es el puente entre los dos.
La idea de que los ejemplos son la especificación más clara está en el corazón del libro de Gojko Adzic «Specification by Example» (2011). En la mayoría de las fuentes, los ejemplos que muestran una regla se llaman ejemplos clave: no todos los posibles, sino los que marcan la diferencia.
Los otros temarios que sigue este curso dicen lo mismo con sus palabras. ISTQB CT-AcT v1.0 (pruebas de aceptación) se escribió junto con la junta de análisis de negocio IQBBA y trata de cómo el analista y el tester pasan juntos de un requisito a los criterios y a las pruebas de aceptación. En el BABOK v3 de IIBA, las historias de usuario (User Stories) y los criterios (Acceptance and Evaluation Criteria) son técnicas separadas, y la Agile Extension to BABOK trata el análisis de negocio en equipos ágiles.
Pruébalo
¿Qué criterio funciona?
La idea
El buen criterio
Un criterio de aceptación es un requisito pequeño, así que las cualidades de la lección «El buen requisito» valen también aquí. Las más importantes:
- Comprobable. Puede fallar una prueba. «Correctamente», «rápido» y «cómodo» no pueden.
- Sobre el comportamiento, no sobre una pantalla. «El código da un 10 %», no «un botón verde bajo el importe». Cómo se ve lo decide el equipo.
- Con los casos negativos. Lo que no está permitido, y lo que ve entonces el cliente. Cancelar después del envío es justo eso.
- Con el límite. 49,99 y 50,00 €. El día 14 y el día 15. Los errores viven alrededor de los límites.
Y una regla sobre la cantidad. Si los criterios crecen hasta quince, la historia es demasiado grande. Muchos criterios son muchas reglas, y muchas reglas son la señal para dividir.
La idea
Definición de Terminado y Definición de Listo
Los criterios son para una historia. Hay también medidas que valen para todas las historias.
La Definición de Terminado (Definition of Done) es la lista que el equipo cumple en cada cambio, sea cual sea. Por ejemplo:
- todos los criterios de aceptación están comprobados;
- las pruebas pasan;
- otra persona del equipo ha revisado el cambio;
- la página de ayuda está actualizada si ha cambiado algo visible.
Una historia está terminada cuando cumple tanto sus propios criterios como la Definición de Terminado.
La Definición de Listo (Definition of Ready) es la comprobación contraria, antes del trabajo: la historia tiene un rol y un beneficio, criterios con ejemplos, ninguna pregunta abierta, y cabe en unos pocos días.
Aquí está la confusión habitual. La Guía de Scrum define solo la Definición de Terminado, como un compromiso para cada parte terminada del producto. La Definición de Listo no está en la Guía de Scrum. Es una práctica que muchos equipos han adoptado por su cuenta. Es útil mientras sea una lista de comprobación para una conversación. Si se convierte en una barrera que una historia no puede pasar sin una firma, el trabajo vuelve a empezar despacio.
Más precisamente, para curiosos
La Guía de Scrum (edición de 2020) describe la Definición de Terminado como la descripción formal del estado del Incremento cuando cumple las medidas de calidad exigidas para el producto. Sobre estar listo, solo dice que los elementos del Product Backlog que el equipo puede hacer dentro de un Sprint se consideran listos para su selección. No hay una lista aparte llamada Definición de Listo.
Pruébalo
¿Cuál es cuál?
Ejercicio
Los criterios en acción
1. De la necesidad a la aceptación. Ordena el camino de una historia.
Ordena los pasos desde la necesidad hasta la historia aceptada.
Escribes los criterios de aceptaciónEscribes la historia: rol, objetivo, beneficioConversan: reglas, ejemplos, preguntasEl dueño acepta la historiaEl dueño expresa la necesidadEl equipo construye la historiaCompruebas contra los criterios
Los criterios se escriben después de la conversación y antes del trabajo. La comprobación es contra ellos, y solo entonces acepta el dueño. Si los criterios llegan después del trabajo, describen lo que se construyó, no lo que hacía falta.
2. El ejemplo que falta. Cada regla tiene ejemplos, pero no los que marcan la diferencia.
Test