Guía de "Regression on Module"

Esta guía está pensada para personas sin conocimientos técnicos que necesitan 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 — sin necesidad de saber programar ni de entender cómo está armado el código por dentro.

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 leer, otro para planificar, otro para probar, otro para reportar. 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, qué parte de la app querés probar, o en qué historia de usuario basarte) 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 "Regression on Module"?

Es la "revisión rápida" de una sola parte de la aplicación, en vez de revisar todo de punta a punta.

Pensalo así: si una tienda online le hace un cambio al método de pago, no tiene sentido volver a revisar el catálogo de productos, el buscador y el panel de administración enteros — alcanza con concentrarse en la parte de "pago" y confirmar que ese cambio no rompió nada ahí (ni en lo que depende directamente de ella).

Este playbook hace exactamente eso: toma un módulo puntual de la aplicación (por ejemplo, "carrito de compras", "login" o "checkout") y corre todo el circuito de QA —leer la historia, armar el plan, probarlo, automatizarlo y reportarlo— pero acotado solo a esa parte, ignorando el resto de la aplicación.

¿Qué es un "módulo"? Es simplemente el nombre con el que el equipo de desarrollo identifica una parte de la aplicación. En una tienda online, ejemplos típicos de módulos serían: login, catálogo, carrito, checkout (pago) o panel de administración. No hace falta que sepas programar para usar este playbook, pero sí necesitás saber qué módulo querés revisar — y si no estás segura/o de cómo se llama esa parte técnicamente, se puede (y conviene) preguntarle al equipo de desarrollo antes de arrancar (más sobre esto en la sección 5).

Diferencia clave con una regresión completa: este playbook no reemplaza una prueba de punta a punta de toda la aplicación. Es una versión enfocada, pensada para ser rápida, y para usarse después de un cambio chico o acotado. Si lo que necesitás es probar toda la aplicación de una, se usa otro playbook (la regresión completa).

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

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

Situación	Ejemplo de negocio
Se hizo un cambio chico o acotado en una sola parte de la app	El equipo de desarrollo agregó un nuevo método de pago (ej. Mercado Pago) solo en el checkout de la tienda online.
Se corrigió un bug puntual y hay que confirmar que quedó resuelto sin romper nada alrededor	Los clientes reportaban que el carrito no actualizaba bien la cantidad de un producto; se corrigió y hay que validar el carrito de nuevo.
Antes de subir un cambio a producción (merge) y no hay tiempo de correr toda la regresión	Se quiere aprobar rápido un ajuste visual en el login antes de un lanzamiento, sin frenar todo el equipo a esperar la regresión completa.
Solo cambió una historia de usuario puntual en el último sprint	De las 10 historias del sprint, solo una tocó el módulo de "mis pedidos"; no hace falta re-probar las otras 9.

¡IMPORTANTE! - Si lo que cambió afecta a varias partes de la aplicación a la vez, o no estás seguro/a de cuánto impacto tuvo el cambio, este no es el playbook indicado — ahí conviene una regresión completa de la aplicación. - Este playbook necesita que el proyecto ya tenga el archivo con el stack tecnológico (qa-stack.yaml) armado de antes. Si es la primera vez que se hace QA automatizado sobre esta aplicación, primero hay que correr el playbook de puesta en marcha del proyecto "new-project-boostrap".

4. Ejemplo guía: "TechStore", una tienda online con carrito de compras

Vamos a seguir el mismo caso de negocio de ejemplo que usan otras guías: TechStore, una tienda online de electrónica con las partes típicas de cualquier tienda que reconocerías por haber comprado online alguna vez:

Login — iniciar sesión con usuario y contraseña.
Catálogo — ver y buscar productos.
Carrito de compras — agregar, quitar y modificar cantidades de productos.
Checkout — pagar y confirmar la compra.

Supongamos que el equipo de desarrollo hizo un cambio puntual: agregaron la opción de aplicar un cupón de descuento dentro del carrito de compras. Te piden: "necesitamos confirmar que el carrito sigue funcionando bien después de este cambio, no hace falta que reprueben toda la tienda". Ese es exactamente el escenario para el que se usa este playbook — el módulo a revisar acá es "carrito".

A lo largo de los pasos siguientes vamos a ver qué le responderías al asistente en cada momento, usando este caso 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
El nombre del módulo a revisar, tal como lo conoce el equipo de desarrollo	`carrito` (o su nombre técnico equivalente, ej. `cart`)
La(s) historia(s) de usuario que describen ese módulo	"Como cliente quiero poder aplicar un cupón de descuento en el carrito de compras"
La URL de la aplicación donde se va a probar	`https://techstore-staging.com`

¿No sabés cómo se llama el módulo técnicamente? No es un problema — es normal que quien hace QA no conozca la estructura interna del código. Antes de arrancar, preguntale al equipo de desarrollo o al tech lead algo así:

"Voy a correr una regresión focalizada sobre el cambio del cupón de descuento. ¿Cuál es el nombre del módulo en el repositorio y qué partes de la app abarca? Lo necesito para acotar bien la prueba."

Si nombrás mal el módulo, el asistente puede armar el plan y las pruebas sobre la parte equivocada de la aplicación. Si no hay nadie del equipo técnico disponible en el momento, también podés pedirle directamente al asistente que revise el proyecto y te sugiera una lista de módulos candidatos a partir de los archivos del código y del cambio reciente — y validar esa lista después con el equipo.

6. Cómo arrancar

Antes de pedirle el primer paso, contale al asistente qué vas a testear, todo junto en un solo mensaje. Siguiendo el ejemplo de TechStore:

Quiero correr una regresión del módulo carrito usando la historia
user-stories/PA-US-08.md (cupón de descuento en el carrito).
La app está en https://techstore-staging.com.

Solo registrá este contexto. No leas archivos, no ejecutes ningún paso,
no llames ninguna skill, no registres en memoria.
Confirmame en una línea si lograste localizar los artefactos dados
para su futuro uso.

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

De dónde sale cada dato: - El módulo y la(s) historia(s) → los decís vos en ese mensaje inicial. - La URL de la app → si no la mencionaste, el asistente la busca dentro del archivo de la historia de usuario en el Paso 1. - El resto de la configuración técnica (dónde guardar archivos, con qué herramienta probar, etc.) → el asistente la lee sola de la "ficha técnica" del proyecto (qa-stack.yaml); no tenés que preocuparte por eso.

7. Paso a paso

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

Paso 1 — "Leer la historia del módulo"

Trigger: /qa-read-user-story

Qué pasa: el asistente lee la historia de usuario del cupón de descuento y separa qué partes de esa historia realmente pertenecen al módulo carrito (por si la historia mencionara, de paso, alguna otra parte de la tienda que no nos interesa revisar ahora).

Cómo saber si salió bien: todo lo que el asistente extrajo (los puntos a validar) debería hablar específicamente del carrito y del cupón — no del login ni del checkout.

Paso 2 — "Armar un plan de prueba enfocado solo en el carrito"

Trigger: /qa-create-test-plan + indicar el módulo

Cómo invocar: pegale al asistente, junto en un solo mensaje:

/qa-create-test-plan
Cubrí solo los puntos del módulo carrito, ignorá el resto de la historia

Qué pasa: el asistente arma un plan de prueba detallado (escenarios paso a paso) pero solo con lo que hace al carrito — por ejemplo: "agregar un cupón válido", "agregar un cupón vencido", "quitar el cupón aplicado". Si la historia mencionara además algo del checkout, esa parte queda afuera del plan.

Cómo saber si salió bien: - Se guardó un plan de prueba en un archivo. - Todos los escenarios del plan hablan del carrito — ninguno habla de login, catálogo o checkout. - Hay al menos un escenario por cada punto a validar del carrito.

Si el asistente frena en este paso: puede pasar que el nombre del módulo que diste no tenga relación con nada de la historia leída. En ese caso el asistente no va a inventar un plan vacío — te va a avisar y sugerir revisar el nombre del módulo con el equipo de desarrollo (ver sección 5).

Paso 3 — "Realizar la exploración del módulo del carrito guiada por el plan de pruebas del paso 2"

Trigger: /qa-scripted-execution

Qué pasa: el asistente entra realmente a TechStore y prueba en vivo los escenarios del plan del Paso 2 — agrega productos al carrito, aplica el cupón, revisa que el descuento se refleje correctamente — igual que lo haría una persona probando la tienda a mano, pero de forma guiada y documentada, con capturas de pantalla como evidencia.

Si en el camino aparece algo que depende de otra parte de la tienda (por ejemplo, que para aplicar el cupón haga falta estar logueada), el asistente anota esa dependencia pero no se pone a probar el login — se mantiene enfocado en el carrito.

Cómo saber si salió bien: queda un reporte legible con lo que se probó, capturas de pantalla de cada paso, y quedan identificados los elementos reales de la pantalla (botones, campos) del carrito para poder automatizar las pruebas en el paso siguiente.

Paso 4 — "Automatizar las pruebas del carrito"

Trigger: /qa-generate-test-suite

Qué pasa: con todo lo relevado en el Paso 3, el asistente escribe las pruebas automáticas correspondientes — el equivalente a dejar "grabado" el proceso de probar el carrito, para que de ahora en más se pueda repetir en segundos, sin que nadie tenga que volver a hacerlo a mano.

Cómo saber si salió bien: aparecen archivos de prueba nuevos, y todos corresponden a escenarios del carrito (ninguno de otra parte de la tienda).

Paso 5 — "Correr las pruebas del carrito y reparar lo que se pueda"

Trigger: /qa-run-and-heal

Qué pasa: el asistente corre las pruebas automáticas recién generadas (o las que ya existían del carrito, si se lo indicás). Si alguna falla por un motivo menor (por ejemplo, un pequeño cambio en la pantalla que no afecta el comportamiento), el asistente intenta repararla sola, repitiendo el intento varias veces hasta que todas pasen o se llegue a un límite de intentos.

Cómo saber si salió bien: queda un resumen con cuántas pruebas pasaron al principio, cuántas al final, y si quedó alguna sin poder repararse (con el motivo).

Paso 6 — "Reporte final del carrito"

Trigger: /qa-write-test-report

Qué pasa: el asistente junta todo lo hecho en los pasos anteriores (lo probado a mano en el Paso 3 y lo automatizado/reparado en el Paso 5) y escribe un reporte final, legible por cualquier persona del equipo, que dice específicamente qué se probó del módulo carrito y con qué resultado. Este reporte nunca borra reportes anteriores — cada corrida deja su propio registro.

Cómo saber si salió bien: el reporte menciona explícitamente "carrito" como módulo cubierto y lista los puntos validados.

8. ¿Qué me queda al finalizar los seis pasos?

Qué obtenés	Para qué te sirve
Un plan de prueba enfocado solo en el módulo revisado	Documentación de qué se decidió probar y por qué
Un reporte de la exploración guiada por el plan con capturas de pantalla	Evidencia de que alguien (el asistente) realmente usó esa parte de la app
Pruebas automáticas nuevas o actualizadas de ese módulo	Quedan listas para volver a correrse en el futuro sin esfuerzo manual
Un resumen de cuántas pruebas pasaron / fallaron	Saber si el cambio original (ej. el cupón de descuento) rompió algo o no
Un reporte final del módulo	Para compartir con el equipo como cierre de la validación

A partir de acá, ese módulo de TechStore queda validado contra el cambio puntual que lo disparó. Para el próximo cambio (en el mismo módulo o en otro), se vuelve a correr este mismo playbook indicando el nuevo módulo o historia.

9. Problemas comunes (y qué hacer)

Lo que ves	Por qué puede pasar	Qué hacer
El plan incluye escenarios que no tienen nada que ver con el módulo que pediste	La instrucción de filtro no fue lo bastante clara	Repetí el Paso 2 siendo más específica/o con el nombre del módulo
Las pruebas fallan por algo que no tiene que ver con el módulo que estás probando	El módulo depende de otra parte de la app que no está en el estado esperado (ej. necesita estar logueada primero)	Avisá al equipo técnico para agregar ese estado previo antes de correr la prueba
El asistente frena en el Paso 2 y no genera el plan	El nombre del módulo no coincide con nada de la historia leída en el Paso 1	Confirmá el nombre exacto del módulo con el equipo de desarrollo (ver sección 5)
El proceso queda "bloqueado" sin poder correr las pruebas	La herramienta de testing detectada para el proyecto todavía no tiene soporte completo	Es un tema para el equipo técnico, no algo que puedas resolver sola/o

10. Resumen visual del flujo

Cambio puntual en un módulo (ej: cupón de descuento en el carrito de TechStore)
            │
            ▼
Paso 1 — Leer la historia del módulo
            │
            ▼
Paso 2 — Armar un plan de prueba enfocado solo en ese módulo
            │
            ▼
Paso 3 — Ejecución del plan guiado por el asistente
            │
            ▼
Paso 4 — Automatizar las pruebas de ese módulo
            │
            ▼
Paso 5 — Correr las pruebas y reparar lo que se pueda
            │
            ▼
Paso 6 — Reporte final enfocado en ese módulo
            │
            ▼
Módulo validado — listo para el próximo cambio