Criterios de Aceptación

Dos formatos son dominantes en los equipos de producto SaaS. Given-When-Then (sintaxis Gherkin) es altamente estructurado y se mapea directamente a casos de prueba automatizados: "DADO un usuario conectado en el panel de control, CUANDO hace clic en 'Exportar', ENTONCES se descarga un archivo CSV en 5 segundos que contiene todas las columnas de la vista de filtro actual." Este formato se prefiere para interacciones de usuario complejas. El formato de Lista de Verificación (Checklist) es más simple y rápido: una lista de condiciones con viñetas (por ejemplo, "El botón aparece solo para usuarios administradores", "Las exportaciones respetan el filtro de fecha activo", "Aparece una notificación 'toast' al finalizar"). Las listas de verificación son mejores para historias más pequeñas. Product Ops establece el estándar sobre qué formato usar y proporciona plantillas en la herramienta de gestión de proyectos del equipo.

Los criterios de aceptación de alta calidad comparten cinco propiedades: Específicos — describen un comportamiento exacto, no un objetivo vago ("Carga en menos de 2 segundos" vs. "Carga rápidamente"). Comprobables — cualquier ingeniero o ingeniero de QA puede verificarlos de forma independiente sin interpretación. Completos — cubren el camino feliz, los estados de error, los casos límite y las consideraciones de control de acceso. Acordados — son revisados y aprobados por Ingeniería antes de que una historia entre en el sprint (no escritos unilateralmente por el PM). Concisos — son lo más cortos posible sin dejar de ser inequívocos; los criterios de aceptación largos a menudo indican que la historia es demasiado grande y debe dividirse. Product Ops audita las historias para verificar la completitud de los criterios de aceptación como parte de la verificación del backlog "listo para el sprint" antes de cada ceremonia de planificación.

Los criterios de aceptación sirven como fuente de verdad para el aseguramiento de la calidad. Cada criterio debe corresponder al menos a un caso de prueba en la suite de QA, ya sea automatizado (unitario, de integración o de extremo a extremo) o manual (documentado en el plan de pruebas). Cuando los criterios de aceptación se escriben en formato Gherkin, pueden implementarse directamente como pruebas automatizadas utilizando frameworks como Cucumber o Cypress. Esta práctica — Desarrollo Guiado por Comportamiento (BDD) — asegura que los criterios de aceptación escritos durante la planificación realmente impulsen la verificación automatizada, cerrando el ciclo entre la especificación y las pruebas. Product Ops trabaja con Ingeniería y QA para establecer la práctica BDD y asegura que cada historia que llega a "done" tenga un caso de prueba adjunto para cada criterio de aceptación.