Criterios de aceptación y Definition of Done

Las dos herramientas que ordenan la calidad

La mayoría de los conflictos "esto no es lo que pedí" y "¿ya está listo?" se resuelven con dos herramientas simples: los criterios de aceptación (por historia) y la Definition of Done (global). Un QA que las domina ahorra semanas de retrabajo.

Criterios de aceptación: qué debe cumplir esta historia

Son las condiciones específicas y verificables que debe cumplir una historia para aceptarse. La mejor forma de escribirlos es el formato Given-When-Then (Dado-Cuando-Entonces):

Escenario: reservar un horario disponible
  Dado un horario libre el 20-07 a las 15:30
  Cuando la clienta lo selecciona y confirma con datos válidos
  Entonces la reserva se crea
    Y se muestra un mensaje de confirmación

Escenario: rechazar un horario ya tomado
  Dado un horario ocupado el 20-07 a las 15:30
  Cuando la clienta intenta reservarlo
  Entonces se rechaza con un mensaje claro
    Y no se crea ninguna reserva

Definition of Done: qué es "terminado" para el equipo

Los criterios cambian por historia. La Definition of Done es una lista global que toda historia debe cumplir para cerrarse, sin importar cuál sea. Un ejemplo típico:

• El código fue revisado por otra persona.
• Los criterios de aceptación fueron probados y pasan.
• La regresión relevante está verde.
• No hay bugs críticos ni mayores abiertos.
• La documentación y las pruebas están actualizadas.

Por qué esto le importa al QA

Sin criterios claros, el QA no sabe contra qué probar y termina discutiendo interpretaciones. Sin una DoD, "terminado" significa cosas distintas para cada persona y los bugs se cuelan a producción. El QA es quien más empuja por que ambos existan y se respeten: son su red de seguridad y la del equipo.

Comprueba lo aprendido en el quiz y escribe tus criterios y DoD en el reto.