Guía de "Feature - New End-to-End"

Esta guía está pensada para entender qué hace el asistente de IA cuando ejecuta este playbook. La idea es que puedas leerla, entender qué pasa en cada paso, y saber qué información tenés que darle al asistente para que el trabajo salga bien.

1. ¿Qué es un "playbook"?

Pensalo como una receta de cocina para el asistente de IA. El playbook es la receta que debes seguir e interactuar con el asistente paso a paso, en orden, sin saltarte nada, para que el resultado sea siempre el mismo sin importar quién lo pida.

Cada paso de la receta usa una herramienta puntual (en la jerga técnica se las llama "skills"), algo así como un utensilio de cocina: uno sirve para pelar, otro para cortar, otro para hornear. Vos no necesitás saber cómo funciona cada utensilio por dentro — solo necesitás saber qué ingrediente hay que poner en cada paso (por ejemplo, la historia de usuario, o la URL de la aplicación) para que el plato final salga bien.

En resumen: un playbook = una guía ordenada de pasos. Una skill = la herramienta puntual que ejecuta cada paso. Interactuás con el playbook — el asistente se encarga de usar la herramienta correcta en cada momento.

2. ¿Qué hace el playbook "Feature - New End-to-End"?

Es el playbook que usás cuando llega una funcionalidad nueva al proyecto y hay que dejarla probada de punta a punta, desde cero: desde los criterios de aceptación hasta un reporte final y un pull request (propuesta de cambios que el equipo de desarrollo revisa antes de aceptarla) con toda la evidencia.

A diferencia de otros playbooks pensados para correr todo de una sola vez sin pausas, este se detiene dos veces para que una persona revise y apruebe antes de seguir:

Después de armar el plan de pruebas (para confirmar que se va a probar lo correcto).
Después de reparar las pruebas que fallaron (para confirmar que la reparación fue real y no un maquillaje).

Esas dos pausas son la razón principal para elegir este playbook por sobre otro: te da visibilidad y control sobre los resultados intermedios, algo clave cuando el equipo necesita esa evidencia antes de aprobar el merge (integración) del código.

Al terminar, la funcionalidad nueva queda con:

Un plan de pruebas completo, ya revisado y aprobado por una persona.
Una suite de pruebas automáticas generada y funcionando.
Un reporte final con el resultado.
Un pull request con todos esos artefactos, listo para que el equipo lo revise.

3. ¿Cuándo tengo que usar este playbook?

Usalo cuando estés frente a alguna de estas situaciones:

Situación	Ejemplo de negocio
Entra una historia de usuario nueva al sprint y no existe ninguna prueba previa para esa funcionalidad	El equipo agrega la posibilidad de aplicar un cupón de descuento en el carrito de compras, algo que nunca se probó antes
Se quiere pasar de "criterios de aceptación" a "pruebas automáticas funcionando" en una sola sesión de trabajo	El Product Owner (PO) define 3 criterios de aceptación para el cupón de descuento y se necesita, en el mismo día, tener pruebas automáticas cubriéndolos
Se necesita evidencia completa antes de aprobar el pase a producción (plan + pruebas + reporte, como parte de la Definición de Terminado)	El equipo no puede dar por cerrada la funcionalidad del cupón de descuento sin adjuntar el plan de pruebas y el reporte al pull request

¡IMPORTANTE!

Este playbook asume que el proyecto ya tiene el QA automatizado configurado (ya existe el archivo con la configuración técnica del proyecto (qa-stack.yaml) y el pipeline de pruebas). Si el proyecto es totalmente nuevo y todavía no tiene nada de eso armado, primero hay que correr el playbook "New Project Bootstrap" — este playbook es para sumar una funcionalidad nueva, no para dejar listo un proyecto desde cero.

4. Ejemplo guía: "TechStore" suma una funcionalidad nueva

Seguimos con el mismo caso de negocio: TechStore, la tienda online de electrónica con carrito de compras. TechStore ya pasó por el playbook de bootstrap — ya tiene su QA automatizado funcionando para lo que existía hasta ahora.

Ahora el equipo de desarrollo agrega una funcionalidad nueva: la posibilidad de aplicar un cupón de descuento en el carrito de compras. Nadie probó todavía esta funcionalidad — recién se terminó de programar. Ese es exactamente el escenario para el que se usa este playbook.

A lo largo de los pasos siguientes vamos a ver qué le responderías al asistente en cada momento, usando el cupón de descuento como ejemplo.

5. Antes de arrancar: lo que necesitás tener a mano

No hace falta saber programar, pero sí tener a mano estos datos:

Dato	Ejemplo con TechStore
Una historia de usuario en un archivo o url de Jira/Confluence donde se encuentre, con sus criterios de aceptación, la URL de la app y las credenciales para entrar	"Como cliente quiero poder aplicar un cupón de descuento en el carrito de compras", guardada en `user-stories/US-045.md` o donde hayas definido en el archivo que contiene la configuración técnica del proyecto "qa-stack.yaml"
La URL de la aplicación donde se va a probar la funcionalidad	`https://techstore-staging.com`

Antes de arrancar, contale al asistente qué historia vas a trabajar y en qué ambiente, algo así:

"Quiero correr el flujo completo para la historia del cupón de descuento (user-stories/US-045.md). La app está en https://techstore-staging.com."

El asistente va a recordar ese contexto durante todos los pasos siguientes — no hace falta repetirlo cada vez.

6. Paso a paso

¡Aclaración! Este es un ejemplo, vos debes seguir el playbook original.

Paso 1 — "Leer la historia de usuario"

Qué pasa: el asistente abre el archivo de la historia y saca de ahí el resumen, los criterios de aceptación, la URL de la app y las credenciales necesarias para entrar. Con eso arma el contexto base que van a usar todos los pasos siguientes.

Ejemplo con el cupón de descuento: el asistente identifica criterios de aceptación como "un cupón válido descuenta el 10% del total", "un cupón vencido muestra un mensaje de error" y "un cupón inexistente no se aplica".

Qué revisar en este paso: que los criterios que el asistente extrajo estén completos y realmente correspondan a la historia. Si algo quedó ambiguo o incompleto, es mejor resolverlo con el Product Owner antes de seguir.

Paso 2 — "Armar el plan de pruebas"

Qué pasa: el asistente convierte cada criterio de aceptación en escenarios de prueba concretos — no solo el "camino feliz" (que el cupón funcione bien), sino también los casos límite (cupón vencido, cupón inexistente, cupón ya usado, carrito vacío, etc.). Todo esto queda guardado en un plan de pruebas.

⏸ Pausa para control humano 1 — Validar el plan de pruebas

Acción requerida antes de continuar al Paso 3.

Antes de que el asistente siga de largo, alguien tiene que revisar el plan y confirmar:

[ ] Hay al menos un caso de prueba por cada criterio de aceptación
[ ] Los casos más importantes y los casos límite más críticos están cubiertos
[ ] Los casos de prueba son realmente posibles de hacer en el ambiente de pruebas
[ ] No hay casos de prueba repetidos o que se contradigan entre sí

Si encontrás algo raro, se lo pedís corregir al asistente directamente, por ejemplo:

"Ajustar el plan: el caso 04 asume un cupón que no existe en el ambiente de staging, reemplazarlo por uno que sí exista."

Recién cuando el plan queda aprobado, se continúa con el Paso 3.

Paso 3 — "Exploración manual de la funcionalidad guiada por el plan de pruebas del paso previo"

Qué pasa: el asistente ejecuta los escenarios del plan navegando de verdad la aplicación (si es una app con pantallas) o enviando pedidos directos (si es una API) — o ambas cosas, si la funcionalidad combina las dos. Mientras lo hace, va guardando capturas de pantalla como evidencia y documentando cualquier comportamiento raro que encuentre como un posible defecto.

Con el cupón de descuento: el asistente entra al carrito de TechStore, escribe un cupón válido y confirma que el descuento se aplica correctamente; después prueba con uno vencido y confirma que aparece el mensaje de error esperado — y así con cada caso del plan.

Qué revisar en este paso: que la exploración haya quedado bien documentada, con evidencia clara de cada caso probado — es el insumo que se usa para armar las pruebas automáticas del paso siguiente.

Paso 4 — "Generar la suite de pruebas automáticas"

Qué pasa: con el plan del Paso 2 y lo que se descubrió navegando la app en el Paso 3, el asistente genera los archivos de prueba automática correspondientes, usando la herramienta de testing que ya tiene configurada el proyecto y fue especificada en el con la configuración técnica del proyecto "qa-stack.yaml".

Qué te queda al final: un archivo de prueba automática por cada caso del plan (por ejemplo, uno para "cupón válido", otro para "cupón vencido", otro para "cupón inexistente").

Qué revisar en este paso: que exista un archivo generado por cada caso de prueba del plan — si falta alguno, algo quedó sin cubrir.

Paso 5 — "Ejecutar y reparar las pruebas"

Qué pasa: el asistente corre toda la suite de pruebas generada. Si alguna falla, analiza por qué y trata de arreglarla sola — repite este intento hasta 3 veces o hasta que todas las pruebas pasen, lo que ocurra primero. Al final, deja un resumen de qué se reparó y cuántos intentos usó.

⏸ Pausa para control humano humano 2 — Revisar la reparación

Acción requerida antes de continuar al Paso 6.

Antes de dar por buena la reparación, alguien tiene que confirmar:

[ ] Las pruebas que fallaron al principio ahora pasan por el motivo correcto (se corrigió el problema real, no se "apagó" la validación para que deje de fallar)
[ ] Ninguna prueba quedó desactivada sin una razón documentada
[ ] Si alguna prueba sigue fallando: quedó documentado si es un defecto real de la app o una limitación del ambiente de pruebas

Si alguna reparación no te convence, se lo decís al asistente:

"El caso del cupón vencido fue reparado cambiando el selector, pero el comportamiento esperado no es el correcto — revertir el arreglo y marcarlo como defecto conocido."

Recién cuando la reparación queda aprobada, se continúa con el Paso 6.

Paso 6 — "Generar el reporte final"

Qué pasa: el asistente junta todo lo que pasó en la exploración manual (Paso 3) y en la reparación (Paso 5) en un solo reporte final. Cada vez que se corre este paso se genera un reporte nuevo — nunca se pisa un reporte anterior, así queda el historial completo.

Qué revisar en este paso: que el reporte incluya un resumen del resultado final, el listado de defectos encontrados, el detalle de qué se reparó, y qué criterios de aceptación quedaron efectivamente validados.

Paso 7 — "Crear el pull request con la evidencia"

Este es el único paso completamente manual: el asistente puede ayudarte a redactar el texto, pero la persona es quien sube los cambios y abre el pull request.

Qué hay que hacer:

Crear una rama nueva para los archivos de prueba (por ejemplo, qa/US-045-tests), en caso de no saber como preguntale al equipo de desarrollo para seguir la forma estandar que hayan definido como equipo.
Subir el plan de pruebas, la suite generada y el reporte final.
Abrir el pull request, con la descripción enlazada a la historia de usuario original.

Antes de dar por cerrado el trabajo, verificar:

[ ] El plan de pruebas está subido
[ ] La suite de pruebas quedó en verde (o los casos en rojo están documentados como defectos conocidos)
[ ] El reporte final está subido
[ ] El pull request está abierto y enlazado a la historia de usuario

7. ¿Qué me queda al finalizar los siete pasos?

Qué obtenés	Para qué te sirve
Un plan de pruebas revisado y aprobado	Evidencia de qué se decidió probar y por qué
Un registro de la exploración guiada por el plan con capturas	Evidencia visual de cómo se comportó la funcionalidad nueva
Una suite de pruebas automáticas	Para que la funcionalidad se siga probando sola de ahora en más
Un resumen de la reparación de pruebas	Registro de qué se arregló y cómo
Un reporte final	Evidencia consolidada para adjuntar a la Definición de Terminado
Un pull request con todo lo anterior	El paquete completo, listo para que el equipo lo revise y apruebe

A partir de acá, la funcionalidad del cupón de descuento en TechStore queda con cobertura de pruebas automáticas — lista para sumarse al conjunto de pruebas que corren solas cada vez que se sube código nuevo.

8. Problemas comunes (y qué hacer)

Lo que ves	Por qué puede pasar	Qué hacer
El plan de pruebas queda con casos incompletos o muy genéricos	Los criterios de aceptación de la historia son ambiguos	Completar la historia con el Product Owner y repetir el Paso 2
La exploración manual falla al navegar la app	La URL está mal, o el ambiente de pruebas está caído	Verificar que la URL de TechStore esté accesible
Se generan pruebas automáticas "vacías" o que no sirven	La exploración manual del Paso 3 no quedó bien documentada	Repetir el Paso 3 poniendo foco en documentar bien cada pantalla y botón usado
La reparación de pruebas no converge después de 3 intentos	Las pruebas dependen de datos que cambian entre corridas (por ejemplo, un cupón que ya se usó)	Pedir que se agreguen datos de prueba fijos y repetir desde el Paso 5
El pull request no pasa la revisión del equipo	Las pruebas quedaron muy frágiles (por ejemplo, tiempos de espera fijos que no se ajustan a la realidad)	Revisar los archivos de prueba generados y ajustarlos junto al equipo técnico

9. Resumen visual del flujo

[Historia de usuario nueva: "cupón de descuento"]
            │
            ▼
Paso 1 — Leer la historia de usuario
            │
            ▼
Paso 2 — Armar el plan de pruebas
            │
            ▼
⏸ Pausa para control humano 1  ← Validar el plan antes de seguir
            │  (aprobado)
            ▼
Paso 3 — Exploración de la funcionalidad
            │
            ▼
Paso 4 — Generar la suite de pruebas automáticas
            │
            ▼
Paso 5 — Ejecutar y reparar las pruebas
            │
            ▼
⏸ Pausa para control humano 2  ← Revisar la reparación antes de reportar
            │  (aprobado)
            ▼
Paso 6 — Generar el reporte final
            │
            ▼
Paso 7 — Crear el pull request con la evidencia
            │
            ▼
[Funcionalidad nueva con cobertura de pruebas automáticas]