Guía de "Demo Walkthrough"

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 la demo salga bien — sin necesidad de saber programar.

1. ¿Qué es un "playbook"?

Pensalo como una receta de cocina para el asistente de IA. Vos le decís "quiero hacer esto" (por ejemplo, "quiero mostrarle a un cliente cómo probamos su funcionalidad") y el playbook es la receta que el asistente sigue paso a paso, en orden, sin saltarse 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 explorar la aplicación, otro para escribir el reporte final. 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é aplicación, qué historia, qué URL) para que el resultado final sirva.

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 "Demo Walkthrough"?

Es el playbook que usás cuando necesitás mostrarle a otras personas, en vivo y paso a paso, cómo el asistente prueba una funcionalidad de punta a punta — sin que se pierdan en el medio.

El asistente puede hacer todo el trabajo de QA de una historia de usuario (leerla, armar un plan de pruebas, probar la aplicación, escribir los tests automáticos, correrlos y armar el reporte final) en un solo tiro, sin pausas. Eso es perfecto para el trabajo del día a día, pero no es ideal para una demo: si todo pasa de golpe, la audiencia no llega a entender qué está viendo, no puede hacer preguntas a tiempo, y ver cada artefacto apenas se genera.

Este playbook resuelve exactamente ese problema: hace lo mismo que el flujo completo de QA, pero:

Va narrando en lenguaje simple qué está haciendo en cada paso, antes de hacerlo.
Se detiene después de cada paso, para que la audiencia mire el resultado en pantalla y pregunte lo que quiera.
Deja bien visible cada documento o archivo que se generó, en el momento en que se generó (no todos juntos al final).

Lo que este playbook NO hace distinto: no prueba nada extra ni de forma diferente al flujo normal de QA. La aplicación se prueba exactamente igual — la única diferencia es el ritmo y la narrativa pensados para que una audiencia pueda seguir el proceso en vivo.

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

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

Situación	Ejemplo de negocio
Tenés que mostrarle el proceso a un cliente o a stakeholders antes de que aprueben algo	El cliente de TechStore quiere ver, con sus propios ojos, cómo se prueba la nueva funcionalidad de carrito antes de dar el visto bueno para pasar a producción
Estás incorporando a alguien nuevo al equipo y necesita entender el flujo completo de una sola vez	Un nuevo QA se suma al equipo de TechStore y necesita ver de principio a fin cómo se prueba una historia, sin tener que leer diez documentos distintos
Vas a grabar un video para mostrar internamente cómo trabaja el equipo, o para venderle el proceso a otro cliente	El área comercial de TechStore pide una grabación corta para mostrarle a un cliente potencial "así probamos lo que construimos"
Necesitás la aprobación final del cliente ("sign-off") sobre una historia candidata, mostrando en vivo que funciona	Antes de cerrar el sprint, el cliente de TechStore quiere ver funcionando el flujo de "Finalizar compra" antes de firmar la aceptación

¡IMPORTANTE! - Este playbook no es para el trabajo diario de QA — para eso ya existe el flujo normal, que hace lo mismo pero sin pausas ni narrativa, mucho más rápido. - Usalo específicamente cuando hay una audiencia mirando (un cliente, un stakeholder, una persona nueva, una cámara grabando) y necesitás que esa audiencia entienda cada paso, no solo ver el resultado final.

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

Vamos a seguir el mismo caso de negocio de ejemplo que en otras guías: TechStore, una tienda online de electrónica con carrito de compras (agregar productos, ver el carrito, pagar). Es el tipo de aplicación que cualquiera reconoce por haber comprado alguna vez online.

Supongamos este escenario: el equipo de TechStore acaba de terminar de desarrollar la funcionalidad "Finalizar compra" (el cliente agrega productos al carrito, hace clic en "Finalizar compra", y el sistema le confirma el pedido). Antes de dar por cerrada esa historia, el Product Owner de TechStore quiere que el equipo le muestre, en una reunión de 20 minutos, cómo se probó esa funcionalidad de punta a punta — no solo que le digan "ya está probada", sino verlo pasar en vivo.

Ese es exactamente el escenario para este playbook: hay una audiencia (el Product Owner), hay una historia concreta ("Finalizar compra"), y el objetivo es que esa audiencia entienda y confíe en el proceso, paso por paso.

A lo largo de los pasos siguientes vamos a ver qué le dirías al asistente en cada momento, usando esta demo de TechStore 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
La historia de usuario que vas a mostrar en la demo, con sus criterios de aceptación bien definidos	El documento que describe "Como cliente quiero finalizar mi compra y recibir una confirmación"
La URL de la aplicación, funcionando y accesible antes de que arranque la reunión	`https://techstore-staging.com`
Credenciales de acceso, si la app pide login	Usuario y contraseña de una cuenta de prueba
El archivo `qa-stack.yaml` del proyecto ya armado	Si TechStore todavía no lo tiene, hay que correr primero el playbook de puesta en marcha del proyecto "new-project-bootstrap"
Pantalla compartida lista, si la demo es presencial o por videollamada	Tener el navegador y el chat con el asistente visibles para toda la audiencia
(Recomendado) Haber leído la historia una vez antes, para saber qué esperar durante la demo	Así, si algo no sale como se esperaba, quien presenta no se sorprende frente al cliente

Consejo: si es la primera vez que corrés esta demo sobre una historia, probala antes en privado. La primera vez que se corre puede aparecer algún imprevisto (por ejemplo, la app tarda en responder) que preferís descubrir a solas, no en vivo frente al cliente.

6. Cómo arrancar la conversación

Antes de arrancar la demo, contale al asistente qué historia vas a mostrar y en qué contexto, así lo tiene presente durante todo el proceso. Por ejemplo:

Vamos a hacer una demo en vivo para el Product Owner de TechStore.
La historia a mostrar es "Finalizar compra" (archivo user-stories/TS-US-08.md).
La app está en https://techstore-staging.com.
Quiero que vayas narrando cada paso y te detengas después de cada uno para que el
Product Owner pueda mirar el resultado y hacer preguntas antes de seguir.

El asistente va a usar esta descripción durante todos los pasos siguientes, así no tenés que repetirla cada vez.

7. Paso a paso

Cada uno de estos seis pasos termina con una pausa — el asistente muestra lo que generó y espera antes de avanzar al siguiente. Esa pausa es el momento ideal para que la audiencia pregunte.

Paso 1 — "Leer la historia de usuario"

Qué pasa: el asistente lee el documento de la historia ("Finalizar compra") y extrae de ahí lo esencial: qué tiene que cumplir la funcionalidad, en qué URL está, y con qué usuario de prueba hay que entrar.

Qué mostrarle a la audiencia: el documento de la historia abierto, y al lado, lo que el asistente entendió de ese documento.

Pausa para preguntas: "¿Esto es lo que ustedes esperaban que hiciera 'Finalizar compra'? ¿Falta algo?"

Paso 2 — "Armar el plan de pruebas"

Qué pasa: con lo que sacó del Paso 1, el asistente arma una lista concreta de todo lo que hay que probar: el camino normal (el cliente compra y le confirman el pedido), y los casos raros o negativos (por ejemplo, qué pasa si el carrito está vacío, o si se pierde la conexión a mitad de pago).

Qué mostrarle a la audiencia: el documento con la lista de casos a probar, y cuántos casos salieron por cada requisito de la historia original.

Pausa para preguntas: "¿Hay algún caso que no se les había ocurrido? ¿Quieren que agreguemos alguno puntual?"

Paso 3 — "Exploración en vivo, dentro de la aplicación real"

Qué pasa: este es el momento de mayor impacto de toda la demo. El asistente entra a TechStore como lo haría cualquier cliente real — agrega productos, va a pagar, hace clic en "Finalizar compra" — y la audiencia ve todo esto pasar en pantalla, en tiempo real, con un navegador abierto delante de todos.

Qué mostrarle a la audiencia: el navegador navegando solo por la aplicación, y cada hallazgo apareciendo a medida que se descubre (por ejemplo, si algo no se comporta como se esperaba).

Momentos de mayor impacto para la audiencia: - Cuando el asistente encuentra algo inesperado (un bug, una inconsistencia). - Cuando saca una captura de pantalla de un error real, en el momento en que ocurre.

Pausa para preguntas: "¿Encontramos algo que no esperaban? ¿Este comportamiento les parece correcto?"

Paso 4 — "Generar las pruebas automáticas"

Qué pasa: con el plan del Paso 2 y todo lo que descubrió navegando en el Paso 3, el asistente escribe las pruebas automáticas — el conjunto de instrucciones que, de ahora en más, se van a poder correr solas, cada vez que se necesite, sin que nadie tenga que repetir los clics a mano.

Qué mostrarle a la audiencia: los archivos de prueba apareciendo, y abrir uno para mostrar que usa exactamente los mismos pasos que se vieron navegar en el Paso 3 (nada se inventa de más).

Pausa para preguntas: "¿Esto se parece a los pasos que acabamos de ver? ¿Ven algo que les genere dudas?"

Paso 5 — "Correr las pruebas y repararlas si hace falta"

Qué pasa: el asistente corre las pruebas automáticas que acaba de generar. Si alguna falla, no se rinde ni te avisa y ya — analiza por qué falló, la ajusta, y la vuelve a correr. Este ciclo se repite unas pocas veces como máximo, hasta que todo pase o hasta que quede claro que ese caso puntual necesita que lo revise una persona.

Qué mostrarle a la audiencia: la consola corriendo las pruebas, y si hay alguna reparación automática, el ciclo completo: falla → se analiza → se corrige → se vuelve a correr.

Momento de mayor impacto: cuando una prueba falla y, segundos después, el asistente la repara solo y vuelve a pasar.

Pausa para preguntas: "¿Qué les pareció el ciclo de reparación automática? Las pruebas que no se pudieron reparar — ¿son un problema real de la aplicación, o una limitación de la prueba en sí?"

Paso 6 — "Reporte final"

Qué pasa: el asistente junta todo lo que pasó en la demo — lo que encontró navegando en el Paso 3, y los resultados de correr las pruebas en el Paso 5 — y lo vuelca en un documento único, prolijo, con fecha y hora, que queda guardado como registro histórico (no borra reportes anteriores).

Qué mostrarle a la audiencia: el reporte final abierto, mostrando con claridad si todo terminó bien o si quedó algo pendiente de revisar.

Cierre de la demo: "En una sola sesión pasamos de la historia de usuario a un conjunto de pruebas documentado, ejecutado y reportado. Todo esto se puede volver a correr cuando quieran, y queda trazado hasta el requisito original."

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

Qué obtenés	Para qué te sirve
El plan de pruebas de la historia mostrada	Documento de referencia de todo lo que se cubrió
Los hallazgos de la exploración en vivo, con capturas	Evidencia de que la funcionalidad se probó de verdad, no "de palabra"
Las pruebas automáticas generadas	Quedan disponibles para volver a correrlas en el futuro, sin repetir la demo
El reporte final con fecha y hora	Documento único para adjuntar al sign-off del cliente o al onboarding de la persona nueva
Una audiencia que entendió y confía en el proceso	El objetivo principal de este playbook — no es solo "probar", es "mostrar cómo se prueba"

9. ¿Y después? — Qué hacer una vez terminada la demo

Situación	Qué hacer
El cliente dio el visto bueno ("sign-off") sobre la historia mostrada	Se cierra la historia como aceptada; las pruebas generadas quedan como parte de la cobertura del proyecto
La exploración en vivo encontró un bug real	Se documenta como tal y se sigue con el playbook de reproducción de bugs, para confirmarlo formalmente y pasarlo a desarrollo
La persona nueva del equipo ya vio el flujo completo	Puede empezar a correr el flujo normal de QA (sin narrativa ni pausas) sobre sus propias historias
Se grabó la demo para uso comercial o interno	El video queda disponible para mostrarle el proceso a otros clientes o áreas, sin tener que repetir la sesión en vivo cada vez

10. Problemas comunes (y qué hacer)

Lo que ves	Por qué puede pasar	Qué hacer
El navegador no abre durante el Paso 3	La herramienta que controla el navegador no está conectada	Verificarlo antes de que arranque la reunión, nunca en vivo frente al cliente
La historia no tiene criterios claros	La historia está mal redactada o incompleta	Reescribir la historia antes de la demo — el asistente solo puede extraer lo que el documento realmente dice
Las pruebas fallan con un error de conexión	El ambiente de pruebas (staging) no está disponible	Levantar y verificar el ambiente antes de empezar
La demo se siente muy larga para la audiencia	La historia elegida tiene demasiados criterios de aceptación	Elegir una historia más acotada (2 o 3 criterios) para una demo corta, o saltar directo al Paso 4 si ya existen hallazgos de una exploración previa

11. Resumen visual del flujo

Historia de usuario a mostrar (ej: "Finalizar compra" en TechStore)
            │
            ▼
Paso 1 — Leer la historia               → pausa para preguntas
            │
            ▼
Paso 2 — Armar el plan de pruebas       → pausa para preguntas
            │
            ▼
Paso 3 — Exploración en vivo            → pausa para preguntas   (momento de mayor impacto)
            │
            ▼
Paso 4 — Generar las pruebas automáticas → pausa para preguntas
            │
            ▼
Paso 5 — Correr y reparar las pruebas    → pausa para preguntas
            │
            ▼
Paso 6 — Reporte final                   → cierre de la demo
            │
            ▼
Audiencia que vio, entendió y confía en cómo se prueba la funcionalidad