Criterios de aceptación

Los criterios de aceptación son las condiciones que definen cuándo una historia de usuario está terminada desde el punto de vista del negocio. Cada criterio es una afirmación clara y verificable cuyo resultado es “pasa” o “falla”. Se acuerdan durante el refinamiento, antes de que empiece el desarrollo, y se convierten en el punto de partida de los escenarios de prueba y de las verificaciones automatizadas.

Ejemplo

Historia: Como comprador, quiero aplicar un código de descuento al pagar para pagar el precio promocional.

Formato basado en reglas:

• Un código válido y no vencido reduce el total del pedido en el porcentaje del código.
• Un código vencido muestra “This code has expired” y no cambia el total.
• Solo se puede aplicar un código por pedido; aplicar un segundo reemplaza al primero.
• Los códigos no distinguen mayúsculas de minúsculas (SAVE10 y save10 son equivalentes).

El mismo criterio del código vencido en formato Given/When/Then (Dado/Cuando/Entonces):

Scenario: Expired discount code is rejected
  Given my cart total is $50.00
  And the code "SPRING10" expired yesterday
  When I apply the code "SPRING10"
  Then I see the message "This code has expired"
  And my cart total is still $50.00

Criterios de aceptación vs. Definition of Done

Los criterios de aceptación son específicos de una historia: lo que esta funcionalidad debe hacer. La Definition of Done (definición de terminado) se aplica a todas las historias: código revisado, pruebas automatizadas, documentación actualizada, desplegado en staging. Una historia solo está completa cuando cumple ambas cosas.

Cómo escribir buenos criterios

• Verificables. “La página carga rápido” no es verificable; “la página de resultados se renderiza en menos de 2 segundos con 1.000 productos en el dataset de staging” sí lo es.
• Comportamiento, no implementación. Describe resultados, no qué tabla de la base de datos cambia.
• Incluye casos negativos. Las entradas inválidas, los permisos y los mensajes de error forman parte de la funcionalidad.
• Acordados por los three amigos. Producto, desarrollo y testing los revisan juntos. Aquí es donde los testers aportan más valor, preguntando “¿qué pasa si…?” antes de que se escriba el código.