Guía de "Smoke Test Post-Deploy"

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 chequeo 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 confirmar que el despliegue de recién no rompió nada") 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 correr las pruebas, 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, en qué ambiente pasó el despliegue) para que el resultado final sirva.

Un deploy (o despliegue) es cuando se sube una nueva versión de la aplicación.

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 "Smoke Test Post-Deploy"?

Es el playbook que usás apenas se termina de subir una nueva versión de la aplicación (un deploy), para confirmar rápido que nada crítico se rompió — antes de dar por buena esa versión.

Pensalo como el chequeo rápido que le hacés a un auto recién salido del taller: no volvés a desarmar el motor entero, pero sí te fijás que arranque, que las luces prendan y que los frenos respondan antes de entregarle las llaves al dueño. Si esas cosas básicas funcionan, confiás en que el trabajo del taller salió bien. Si alguna no funciona, no seguís manejando — volvés a fijarte qué pasó.

Este playbook hace exactamente eso, pero con la aplicación: toma la batería de pruebas que ya existe de antes (no crea pruebas nuevas) y la corre una sola vez, tal cual está, sin detenerse a arreglar nada que falle en el momento. Al final, deja un documento con fecha y hora que dice con claridad: "después de este deploy, esto es lo que funcionó y esto es lo que no".

Lo que este playbook NO hace: no revisa la aplicación a fondo ni prueba cosas nuevas, y no genera ni modifica ninguna prueba. Tampoco arregla nada que encuentre roto — solo lo detecta y lo deja documentado. Es un chequeo de "signos vitales", no un chequeo médico completo. Si algo falla y hay que repararlo, ese es un trabajo distinto (lo vemos en el punto 9).

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

Usalo cuando estés frente a alguna de estas situaciones — todos son puntos de partida típicos para este playbook:

Situación (punto de partida)	Ejemplo de negocio
Se acaba de terminar un deploy a producción o a ambiente de pruebas	El equipo de TechStore acaba de subir una nueva versión de la tienda a producción, y antes de avisarle a todos que "ya está" quieren confirmar que el carrito y el pago siguen funcionando
Es un chequeo automático dentro del pipeline, antes de dejar pasar una versión de un ambiente a otro	Cada vez que TechStore sube código al ambiente de pruebas, el sistema corre este chequeo solo, sin que nadie lo pida, y si algo falla no deja avanzar esa versión a producción
Se acaba de aplicar un hotfix o un rollback	TechStore detectó que el botón "Finalizar compra" no respondía, subieron un arreglo urgente, y ahora hay que confirmar rápido que el arreglo no rompió otra cosa (por ejemplo, el login)
Alguien pide evidencia concreta de que el ambiente responde bien	El líder técnico de TechStore quiere un documento fechado que confirme que, después del deploy de esta mañana, el sistema sigue sano

¡IMPORTANTE!

Este playbook necesita que la batería de pruebas ya exista de antes. No crea pruebas nuevas ni las modifica. Si TechStore todavía no tiene pruebas armadas para su carrito de compras, primero hay que correr el playbook de puesta en marcha del proyecto (new-project-bootstrap) o el flujo completo de QA.
Este playbook no es una regresión completa. Es rápido y liviano a propósito, pensado para confirmar lo crítico después de un deploy — no para volver a revisar toda la aplicación de punta a punta.

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: son las 10 de la mañana y el equipo de desarrollo de TechStore acaba de terminar de desplegar una nueva versión en producción, con varias mejoras en la pantalla de pago. Antes de anunciar que el deploy salió bien, alguien del equipo dice: "esperá, confirmemos primero que el carrito y el pago siguen funcionando como antes".

Ese es exactamente el escenario para este playbook: ya hay una batería de pruebas armada de antes para TechStore (se generó en algún momento previo, con otro playbook), y lo que hace falta ahora es correrla una vez, rápido, y dejar constancia del resultado — no rehacer el trabajo de pruebas desde cero.

A lo largo de los pasos siguientes vamos a ver qué le dirías al asistente en cada momento, usando este deploy 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
Que la batería de pruebas ya exista de un trabajo previo	TechStore ya tiene pruebas automáticas del carrito y del pago, generadas cuando se armó el proyecto
La URL del ambiente donde se hizo el deploy, y que esté accesible	`https://techstore.com` (producción) o `https://techstore-staging.com`, según dónde se hizo el deploy
Un nombre para identificar este chequeo	Algo simple que diga de qué deploy se trata: `staging`, `prod`, o `hotfix-login` si fue un arreglo puntual
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`)

Antes de arrancar, confirmá que la aplicación responde. Si la URL de TechStore no carga o tira error, no tiene sentido correr el chequeo todavía — primero hay que resolver eso, porque si no, el resultado no va a decir nada real sobre el deploy.

6. Cómo arrancar la conversación

Antes de pedirle nada puntual, contale al asistente sobre qué deploy se trata, así lo tiene presente durante todo el proceso. Por ejemplo:

Se acaba de completar un deploy de TechStore a producción (https://techstore.com).
Quiero correr el smoke test post-deploy para confirmar que el carrito y el pago
siguen funcionando bien, sin que se reparen ni modifiquen las pruebas.
Llamale a este chequeo "prod" (va a aparecer así en el nombre del reporte).

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

Paso 1 — "Correr la batería de pruebas existente, una sola vez, sin repararla"

Qué pasa: el asistente toma las pruebas que ya existen de TechStore (las del carrito, el login, el pago) y las corre todas, una vez, contra el ambiente donde se hizo el deploy. A diferencia de otros playbooks, acá el asistente no intenta arreglar nada que falle en el momento — si una prueba no pasa, la deja anotada como falló y sigue de largo. La idea es que el resultado refleje exactamente el estado real del deploy, sin que nadie lo "toque" en el medio.

Qué junta el asistente durante este paso:

Información	Para qué sirve
Cuántas pruebas pasaron y cuántas fallaron	El número clave para saber si el deploy está sano
Cuánto tardó en correr todo	Referencia de tiempo para futuros chequeos
El detalle de cada prueba que falló, si hay alguna	Punto de partida para investigar si hace falta

Al final de este paso, puede pasar una de estas situaciones:

Resultado	Qué significa
Todo pasó	El deploy no rompió nada crítico — buena señal
Algo falló	Puede ser una regresión real causada por el deploy — se sigue igual al Paso 2, que va a dejarlo documentado
El ambiente no respondió (por ejemplo, la página no carga, o tira error de conexión)	Esto no es un resultado de smoke test — es que el ambiente del deploy no está disponible. No es lo mismo que "una prueba falló": hay que resolver el acceso al ambiente primero, y recién ahí volver a correr este paso

Por qué importa esta distinción: si el carrito de TechStore "falla" porque la página ni siquiera cargó, eso no dice nada sobre si el deploy rompió el carrito — dice que el ambiente está caído. Confundir estas dos cosas puede hacer que el equipo persiga un bug que en realidad no existe.

Paso 2 — "Generar el reporte del chequeo"

Qué pasa: el asistente junta todo lo que encontró en el Paso 1 y escribe un documento prolijo, con fecha y hora, que queda guardado como registro histórico de ese deploy puntual — sin borrar ni pisar reportes de deploys anteriores.

Lo único que puede llegar a pedirte en este paso es el nombre que le querés dar al chequeo (por ejemplo, prod, staging o hotfix-login), para poder nombrar el archivo del reporte. Todo lo demás ya lo tiene, porque viene del Paso 1.

Qué te queda al final de este paso:

Condición del reporte	Qué esperar
Archivo de reporte creado, con fecha y hora	Por ejemplo: `smoke-prod-test-report-2026-07-17-1015.md`
Conteo total de pruebas, pasadas y fallidas	Un número claro, sin ambigüedad
Lista de fallos, si los hay, con el motivo de cada uno	Punto de partida para investigar o repriorizar
Estado general del deploy	"Pasó" o "Falló", bien visible al principio del documento

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

Qué obtenés	Para qué te sirve
Un reporte fechado del estado del deploy	Evidencia concreta de que el deploy se chequeó, no solo "de palabra"
El conteo de pruebas pasadas y fallidas	Un número simple para decidir si el deploy queda o se revierte
El detalle de qué falló, si algo falló	Punto de partida para decidir el siguiente paso (investigar, reparar, escalar)
La certeza de que nada se modificó en el proceso	El chequeo es fiel al estado real del deploy, sin reparaciones automáticas que lo disimulen

9. ¿Y después? — Qué hacer según el resultado del chequeo

Resultado del smoke test	Qué hacer
Todo pasó	El deploy queda confirmado como sano. Se guarda el reporte como evidencia y se sigue con normalidad (por ejemplo, avisar que el deploy está OK)
Algo falló, y parece una regresión real	Se investiga con el playbook de reproducción de bugs, o se repara la cobertura con el playbook de regresión sobre ese módulo — este playbook, por diseño, no arregla nada por sí solo
El ambiente no respondió (no es un fallo real, es un bloqueo de infraestructura)	Se resuelve el acceso al ambiente (ver por qué no responde la URL) y se vuelve a correr el Paso 1 desde cero
Fue un hotfix o un rollback	Además de este chequeo, vale la pena avisarle al equipo que el arreglo quedó confirmado (o no) con evidencia fechada, para cerrar el incidente con tranquilidad

Este playbook, por sí solo, no repara nada — su tarea termina en confirmar y documentar el estado del deploy. Si algo quedó mal, el trabajo de arreglarlo o cubrirlo con más pruebas continúa en otro playbook, tomando como base el reporte que ya se generó acá.

10. Problemas comunes (y qué hacer)

Lo que ves	Por qué puede pasar	Qué hacer
El asistente dice que no encuentra las pruebas para correr	Todavía no se generó ninguna batería de pruebas para TechStore	Correr primero el playbook de puesta en marcha del proyecto o el flujo completo de QA, para que exista algo que chequear
Todas las pruebas fallan con timeout o error de conexión	El ambiente del deploy no está disponible (no es un problema de la aplicación en sí)	Verificar que la URL de TechStore responde en un navegador normal antes de volver a correr el chequeo
No se genera el archivo de reporte	Problema de permisos o de configuración en la carpeta de reportes	Avisarle a alguien del equipo técnico para que revise la configuración del proyecto
El asistente dice que empezó a "reparar" pruebas que fallaron	Se corrió sin las opciones correctas y entró en modo de reparación completa	Aclarar explícitamente que se quiere el modo "smoke, sin reparar" antes de volver a correrlo

11. Resumen visual del flujo

Deploy recién completado (ej: nueva versión de pago en TechStore)
            │
            ▼
Paso 1 — Correr la batería de pruebas existente, una sola vez, sin repararla
            │
            ▼
Paso 2 — Generar el reporte fechado del chequeo
            │
            ▼
[Deploy confirmado OK]  o  [Fallos documentados, listos para investigar]