Si una historia de usuario es una "promesa de conversación", los Criterios de Aceptación son el resultado de esa conversación. Definen los límites de la historia y proporcionan una descripción clara de lo que se debe implementar para que la historia se considere completa y correcta.
3.1. Qué son y cómo se formulan
Los Criterios de Aceptación son un conjunto de condiciones que una funcionalidad debe cumplir para ser aceptada por un usuario, un cliente o el Product Owner. Son una lista de verificación que determina si la historia de usuario ha sido implementada satisfactoriamente. Su propósito es eliminar la ambigüedad y asegurar que todos tengan la misma comprensión de lo que se va a construir.
Se formulan durante la conversación de refinamiento de la historia y se escriben en un lenguaje claro y conciso, sin tecnicismos. Existen dos formatos comunes para escribirlos:
- Basado en reglas (lista de verificación): Este es el formato más simple. Se crea una lista de las condiciones que se deben cumplir. Por ejemplo: "El sistema debe...", "El usuario puede...", "La contraseña debe...".
- Basado en escenarios (Given/When/Then): Este formato, popularizado por el Desarrollo Guiado por el Comportamiento (BDD), describe el comportamiento del sistema en un escenario específico. Sigue la estructura:
- Given (Dado): El contexto o la precondición.
- When (Cuando): La acción que realiza el usuario.
- Then (Entonces): El resultado o la consecuencia observable.
3.2. Ejemplos de criterios claros y medibles
Veamos la historia de usuario de inicio de sesión y cómo se le pueden añadir criterios de aceptación claros.
Historia de Usuario: Inicio de Sesión
Como usuario registrado,
quiero iniciar sesión en el sistema,
para acceder a mi panel de control personalizado.
Ejemplo con formato de lista de verificación:
- El campo de correo electrónico solo acepta direcciones de correo válidas.
- El campo de contraseña debe tener un mínimo de 8 caracteres.
- El sistema muestra un mensaje de error si el correo o la contraseña son incorrectos.
- El usuario es redirigido al panel de control después de 3 intentos fallidos.
- El botón "Iniciar Sesión" está deshabilitado hasta que ambos campos estén rellenos.
Ejemplo con formato Given/When/Then (BDD):
Escenario: Inicio de sesión exitoso
Dado que soy un usuario registrado y estoy en la página de inicio de sesión,
Cuando introduzco mi correo electrónico y contraseña correctos,
Entonces soy redirigido a mi panel de control.
Escenario: Inicio de sesión fallido
Dado que estoy en la página de inicio de sesión,
Cuando introduzco un correo electrónico o contraseña incorrectos,
Entonces veo un mensaje de error que dice "Correo electrónico o contraseña no válidos".
3.3. Relación con las pruebas de validación y QA
Los Criterios de Aceptación son la base para las pruebas de validación y el trabajo del equipo de Calidad (QA). Su relación es directa y fundamental para asegurar la calidad del producto:
- Guía para las pruebas: Cada criterio de aceptación se puede transformar en uno o más casos de prueba. El equipo de QA utiliza estos criterios para verificar que la funcionalidad se comporta como se esperaba. Si todos los criterios se cumplen, la historia pasa las pruebas.
- Definición de "Hecho" (Definition of Done): Los criterios de aceptación son una parte clave de la Definición de "Hecho". Una historia no se puede considerar "hecha" hasta que no solo esté codificada, sino que también cumpla con todos sus criterios de aceptación.
- Automatización de pruebas: El formato Given/When/Then es especialmente útil porque se puede utilizar para escribir pruebas automatizadas con herramientas como Cucumber o SpecFlow. Esto permite crear una suite de pruebas que verifica continuamente el comportamiento del sistema, reduciendo regresiones y mejorando la confianza en el código.
En definitiva, los Criterios de Aceptación cierran el ciclo de la historia de usuario. Mientras que la historia abre la conversación sobre una necesidad, los criterios confirman que esa necesidad ha sido satisfecha de manera tangible y medible.