acceptance-criteria

Generar criterios de aceptación

Resumen

Este skill genera criterios de aceptación en formato Gherkin (Given/When/Then) a partir de una historia de usuario o requisito. Los criterios producidos deben ser lo bastante precisos como para convertirse directamente en tests automatizados, eliminando ambigüedad entre lo que producto espera y lo que desarrollo implementa.

El valor de unos buenos criterios de aceptación es doble: sirven como especificación ejecutable y como contrato entre producto y desarrollo. Si un criterio no se puede automatizar, probablemente es demasiado vago.

Proceso

1. Obtener la historia de usuario o requisito. Si viene de un PRD o de una lista de historias existente, leerlo. Si no, pedir al usuario que describa la funcionalidad.

2. Identificar los escenarios principales:

   • Escenario positivo (happy path): el flujo normal cuando todo va bien. Es el caso de uso principal que justifica la existencia de la historia.
   • Escenarios alternativos: caminos válidos pero menos frecuentes. Por ejemplo, un usuario que cancela a mitad de un flujo.
   • Escenarios negativos: qué ocurre cuando la entrada es inválida, falta información o el sistema está en un estado inesperado.
   • Edge cases: límites del sistema, valores extremos, condiciones de carrera, timeout, datos vacíos.

3. Redactar cada escenario en formato Gherkin:

   Escenario: [Nombre descriptivo del escenario]
     Dado [contexto o estado previo del sistema]
     Cuando [acción que realiza el usuario o el sistema]
     Entonces [resultado esperado observable]
   

   Para escenarios con múltiples condiciones, usar Y (And) para encadenar pasos:

   Escenario: Login con credenciales válidas
     Dado que el usuario tiene una cuenta activa
     Y que está en la página de login
     Cuando introduce su email y contraseña correctos
     Y pulsa el botón "Entrar"
     Entonces es redirigido al dashboard
     Y ve su nombre de usuario en la cabecera
   

4. Verificar que cada criterio es automatizable. Si un paso usa lenguaje ambiguo ("el sistema responde rápido", "la interfaz es intuitiva"), reescribirlo con métricas concretas ("el tiempo de respuesta es inferior a 200ms", "el formulario muestra etiquetas visibles en todos los campos").

5. Cubrir el manejo de errores. Para cada escenario positivo, pensar en al menos un escenario de error correspondiente. Documentar qué mensaje ve el usuario, qué estado queda el sistema y si se registra el error.

6. Agrupar por historia de usuario. Presentar los criterios organizados bajo la historia a la que pertenecen, facilitando la trazabilidad.

7. Revisar con el usuario. Los criterios de aceptación son un acuerdo: producto dice qué espera y desarrollo confirma que es viable. No se dan por finales sin validación.

Criterios de éxito

• Cada historia tiene al menos un escenario positivo, uno negativo y un edge case.
• Todos los escenarios siguen el formato Given/When/Then sin ambigüedades.
• Los criterios son directamente convertibles en tests automatizados.
• Se ha cubierto el manejo de errores para los flujos críticos.
• El usuario ha validado que los criterios reflejan sus expectativas.

Que NO hacer

• No escribir criterios ambiguos que no se puedan automatizar. Si un criterio usa términos como "rápido", "bonito" o "intuitivo" sin métricas concretas, no es verificable.
• No cubrir solo el camino feliz. Cada historia necesita al menos un escenario negativo y un edge case para ser robusta.
• No dar los criterios por finales sin validación del usuario. Los criterios de aceptación son un contrato entre producto y desarrollo; ambas partes deben estar de acuerdo.