Early-Game

Entender los requerimientos: el análisis del Epic y el de cada Story ocurren ANTES del sprint, y de ahí sale el ATP de la historia, que pre-sprint vive SOLO en el campo `acceptance_test_plan` (todavía sin ítem Test Plan). El ítem FTP no nace acá: se crea o se refina dentro de /sprint-testing, al cargar el contexto del Epic, ya en sprint. El FTP es un documento vivo: se escribe una vez por épica y se refina a lo largo de ella, porque el equipo aprende con cada historia que entrega. Y la historia no se analiza sola: se analizan también sus hermanas de la misma épica —las ya desarrolladas, las que están en desarrollo y las que solo están definidas— porque ese panorama completo de la feature es lo que hace que los ATPs salgan mejores.

Construir y desplegar la US en un entorno de staging mientras QA prepara la estrategia

Validar la US en dos movimientos y en este orden: primero el smoke test de Go/No-Go, que valida el ENTORNO, y recién después la exploración por Trifuerza (UI · API · DB), que valida la FEATURE ejecutando lo planificado en el ATP y en el FTP. Saltarse el smoke es el anti-patrón clásico. Los hallazgos se reportan en el momento: el reporte de defectos no es un step aparte, vive dentro de la exploración. Antes de filear hay que CLASIFICAR el hallazgo — Bug, Defect o Improvement — y la clasificación sigue la etapa de vida de la FEATURE, no el entorno donde apareció. Cada hallazgo se documenta con información clara y reproducible.

Decidir qué escenarios del ATP merecen un Test Case (TC) persistente en el TMS y cuáles se quedan como exploratorios. La decisión corre DESPUÉS de ejecutar y reportar: el set de regresión persistente se decide por ROI, nunca se asume al planificar.