Robot de QA que revisa el checkout antes de cada cambio
Resultado: Un comando y unos 65 segundos. El robot compra en una copia de prueba, en computador y celular, y te dice si algo se rompió.
evidencia: Reporte completo de la corrida: 20 de 20 casos, 60 pruebas unitarias, error inyectado atrapado, video y trace evidencia ↗
$ npm run qa:checkout▸ levantando copia de prueba de la tienda… ok▸ fixture: 12 productos · 2 pantallas · 10 reglas✓ EE-01 el servidor decide el precio✓ EE-02 detal: 1 a 10 por SKU, duplicados unidos✓ EE-03 mínimos de mayorista respetados✓ EE-04 envío: Bogotá, nacional y umbral gratis✓ EE-05 contacto y consentimiento validados en el servidor✓ EE-06 opt-ins sin marcar y opcionales⚠ defecto plantado: opt-ins marcados → atrapado✓ EE-07 a EE-10 pedido, pago y totales coherentes✓ checkout escritorio · 10/10✓ checkout celular · 10/1020/20 en verde · 65 s · exit 0
Para el dueño
Resultado para el negocio
- Cada cambio en la tienda puede romper el pago.
- Piloto en mi tienda. 20 de 20 casos del checkout en verde y 60 pruebas unitarias. Atrapa el error inyectado en las dos pantallas. Corre sobre datos sintéticos: no hace compras ni pagos reales. Ganó el reto de la clase de harness de Ricardo Celis en Gradiente (8 de octubre de 2026).
- Construyo con control de calidad desde el principio. Un sistema de IA sin pruebas es una apuesta.
En una línea
Un comando y unos 65 segundos. El robot compra en una copia de prueba de mi tienda, en computador y en celular, y me dice si algo se rompió. Con este proyecto gané el reto de harness de la clase de Ricardo Celis en Gradiente Escuela de Ingeniería, el 8 de octubre de 2026.
Contexto
Tengo una tienda en línea de perfumes. Cada vez que cambio algo, un precio, un texto, una sección, puedo romper el checkout sin darme cuenta. Y si el checkout falla, pierdo ventas y ni me entero.
En la clase de Ricardo Celis nos retaron a construir nuestro propio harness, mostrarlo funcionando y hacer un video. Escogí el problema que más me dolía en mi negocio.
El problema
- Revisar el checkout a mano en cada cambio es lento y aburrido. Por eso uno termina no haciéndolo.
- Lo que funciona en el computador puede fallar en el celular, y la mayoría de mis clientes compran desde el celular.
- Un error pequeño, como una casilla de promociones marcada por defecto, puede ser un problema legal y de confianza.
El enfoque
Un harness es el arnés que rodea al trabajo automático: las reglas, los límites, las pruebas y la evidencia. La idea central fue esta: la IA no necesita más libertad, necesita reglas claras.
Por eso el robot tiene límites duros:
- Nunca toca la tienda real. Trabaja sobre una copia de prueba con datos sintéticos.
- No hace compras ni pagos reales.
- No puede decir “terminé” sin evidencia: video, trace y resumen.
- Se prueba a sí mismo. Le meto un error a propósito y lo tiene que atrapar. Si no lo atrapa, el robot no sirve.
Qué construí
- Un solo comando que levanta la copia de prueba del checkout.
- Recorrido completo en computador y en celular: llena el formulario con datos sintéticos, deja las promociones sin marcar y confirma el pedido.
- Prueba negativa. Inyecta un defecto: las promociones vienen marcadas por defecto. El robot lo atrapa en las dos pantallas.
- Evidencia al final. Un video del recorrido, el trace técnico para depurar y un resumen en español que cualquier persona entiende.
Lo construí con Claude Code y Codex. Yo definí qué debía revisar, qué no podía tocar y cuándo se consideraba terminado. Los agentes escribieron el código y las pruebas. Yo revisé y corrí todo antes de grabar.
Demo y estado
- Estado: piloto en mi propia tienda.
- Resultados de la demo: 20 de 20 casos del checkout en verde, 60 pruebas unitarias y la prueba negativa correcta. La demo completa, con video, tarda unos 65 segundos.
- Límite honesto: corre sobre una copia con datos sintéticos. No certifica la tienda real, los pagos ni el CRM.
- Lo que vino después: con la misma idea armé un segundo revisor que mira la tienda publicada en busca de errores de diseño, contenido y SEO, y prueba la compra hasta antes de pagar.
Lo que aprendí
- Un robot que nunca falla no prueba nada. La prueba negativa es lo que le da valor. Si no atrapa un error que yo mismo puse, no le creo cuando dice que todo está bien.
- La evidencia vende. El video y el resumen en español fueron lo que más gustó en la clase. Un dueño de negocio no lee un trace. Sí ve un video y lee un resumen.
- Contarlo con honestidad también cuenta. En el video dije que el robot prueba una copia con datos falsos. Prefiero eso a que alguien crea que certifico pagos reales.
Qué se rompió y cómo lo encontré
- Un robot que siempre decía “todo bien”. Antes de la prueba negativa no había forma de distinguir un robot que funciona de uno roto. Metí un error a propósito (casillas de marketing premarcadas) e hice que dos pruebas fallaran por esa causa, en escritorio y celular. Ahora cada corrida demuestra que el detector funciona.
- “Listo” sin evidencia. Una corrida podía terminar sin video o con un trace viejo y verse terminada igual. La revisión de cobertura ahora rechaza omisiones, fallos, reintentos y evidencia ausente, alterada o de otro código.
- Un puerto ocupado probaba lo que no era. Si el puerto 4173 está ocupado, el runner se niega a arrancar en vez de reutilizar un servidor desconocido. Mejor fallar que probar la aplicación de otro.
¿Tu tienda o tu web necesitan esto?
Si tienes una tienda en línea, un formulario de contacto o un sistema de reservas, un robot así te avisa antes de que se entere tu cliente.
Para el equipo que contrata
Notas técnicas
- Arquitectura
- Playwright con Node.js sobre un servidor fixture local (puerto 4173); un solo comando corre las pruebas unitarias, las diez reglas en escritorio y celular, la prueba negativa y la revisión de cobertura.
- Datos
- Solo datos sintéticos; sin compras, pagos ni clientes reales; cada corrida deja run.json, results.json, un veredicto, un resumen en español, video y trace.
- Pruebas
- 60 pruebas unitarias, 20 casos del checkout (10 reglas × 2 pantallas), 2 pruebas negativas que deben fallar por el error inyectado; ciclo completo en unos 65 segundos.
- Dónde corre la IA y sus guardas
- Sin IA en tiempo de ejecución. Construido y gobernado con Claude Code y Codex bajo guardas que limitan herramientas, rutas y destinos; nada lee .env ni toca la tienda en vivo.
- Costo mensual de operación
- Costo de nube cero: corre en un portátil. El perfil de staging es una prueba de humo de solo lectura.
- Repositorio y estado
- Repositorio privado. Piloto en mi propia tienda. Ganador del reto en Gradiente, 8 de octubre de 2026. Página de evidencia con la corrida.
Con qué