Serie: Gstack (6/7)
QA y Browse: Dale Ojos a la IA para que 'Vea' Realmente tu App
Hay un punto ciego en el desarrollo de software que ha sido ignorado durante mucho tiempo: la IA puede escribir código, pero no puede ver cómo luce ese código cuando se ejecuta.
Le pides a Claude que escriba un flujo de inicio de sesión, lo escribe, parece bien. Le preguntas "¿se muestra correctamente la página de inicio de sesión?" — no puede responder, porque nunca ha abierto un navegador; solo puede ver código.
Este punto ciego es particularmente peligroso con cambios de frontend, regresiones de UI y flujos de autenticación — el problema no está en la lógica, está en el estado visual; no está en el código, está en lo que realmente se ejecuta.
El /browse y /qa de Gstack están diseñados para cerrar este punto ciego.
/browse: Dale Ojos Reales a la IA
/browse está respaldado por un daemon de Chromium persistente controlado a través de Playwright:
- Primer lanzamiento: unos 3 segundos
- Cada comando posterior: 100-200ms (clics, navegación, capturas de pantalla, relleno de formularios)
- Estado persistente: las cookies, localStorage y pestañas abiertas se preservan entre comandos
- Apagado automático: se apaga automáticamente después de 30 minutos de inactividad
Comparado con Claude for Chrome MCP, Gstack aficia oficialmente una mejora de velocidad de 20x — porque la arquitectura es diferente: el browse de Gstack es un binario compilado independiente (58MB, compilado con Bun) que se comunica directamente con Chromium, evitando el round-trip de MCP.
Qué Puede Hacer
/browse https://tu-app.com
La IA abre tu app, y luego puedes pedirle que:
- Navegue a páginas, rellene formularios, tome capturas de pantalla
- Confirme si ciertos elementos aparecen
- Lea errores de consola
- Inspeccione solicitudes de red
Usa refs de árbol de accesibilidad (@e1, @e2) para localizar elementos, no selectores CSS — por lo que no se romperá cuando cambies un nombre de clase. Es más robusto que los scripts típicos de Playwright.
Probando Páginas Detrás de un Login
Muchas funcionalidades importantes están detrás de muros de autenticación. Las pruebas automatizadas estándar requieren configurar credenciales y gestionar sesiones — mucha fricción. La solución de Gstack:
/setup-browser-cookies
Este comando abre un selector interactivo donde eliges qué cookies de qué dominios importar desde tu navegador real (Chrome, Arc, Brave, Edge, Comet). Después de importar, /browse y /qa pueden probar tu estado autenticado directamente, sin necesidad de volver a introducir credenciales.
Los valores de las cookies nunca se muestran en pantalla durante el proceso — el acceso a Keychain requiere tu aprobación explícita, y la base de datos se abre en modo de solo lectura.
/qa: No Solo Mirar — Encontrar, Arreglar, Verificar
/browse es "darle ojos a la IA"; /qa es "hacer que la IA use esos ojos para ejecutar un proceso QA completo" — la diferencia está en el grado de automatización y profundidad.
Modo de Pruebas Consciente del Diff (Por Defecto)
/qa por defecto usa el modo consciente del diff: primero analiza tu git diff, encuentra qué páginas y funcionalidades se ven afectadas por el cambio, luego solo prueba esas partes afectadas.
Esto importa — si tu app tiene 50 páginas, no quieres ejecutar el suite E2E completo cada vez que cambias un botón. El modo consciente del diff hace que el alcance de las pruebas sea proporcional al alcance del cambio: más rápido, más objetivo.
Cuatro Modos de Prueba
- Consciente del diff (por defecto): analiza el git diff, solo prueba las páginas afectadas
- Exploración completa: ejecuta toda la app, bueno para verificaciones completas antes de lanzamientos mayores
- Smoke test rápido: confirma rápidamente que los flujos principales siguen funcionando
- Comparación de línea base de regresión: compara con la línea base anterior para encontrar regresiones
Arregla lo que Encuentra
El ciclo completo de /qa es:
- Analizar diff, decidir qué páginas probar
- Abrir navegador, probar realmente cada página
- Encontrar problemas, arreglar bugs automáticamente (commits atómicos)
- Después de arreglar, volver a probar para confirmar que el arreglo funcionó
- Generar una puntuación de salud (0-100) e informe de pruebas
La parte de "arregla lo que encuentra" merece más explicación — no está haciendo cambios aleatorios. Hace el mismo análisis consciente del diff que /review, modifica código directamente relacionado con el problema, y cada cambio es un commit atómico independiente para que puedas revisarlos fácilmente.
Después de que /qa termina, puedes comprobar git log para ver qué hizo — cada commit tiene una descripción clara.
/qa-only: Reportes Sin Tocar el Código
Si quieres un informe puro de bugs — dejar que la IA pruebe y te diga qué está mal, pero sin arreglar nada automáticamente — usa /qa-only.
Buenos escenarios para esto:
- Quieres organizar el informe de bugs antes de asignarlo a miembros del equipo
- Todavía no tienes suficiente confianza en el arreglo automático para querer que toque tu código
Ambos skills usan la misma lógica de pruebas — la única diferencia es si se auto-arregla al final.
Cómo Leer la Puntuación de Salud
La puntuación de salud de 0-100 de /qa está ponderada basándose en las páginas y funcionalidades probadas en esa ejecución.
Referencia aproximada:
- 90+: Los flujos principales están bien, quizás algunos problemas menores de UX
- 70-89: Algunas cosas a vigilar, pero la funcionalidad principal funciona
- 50-69: Hay problemas bloqueantes — arreglar antes de entregar
- Por debajo de 50: Problemas críticos, no se recomienda entregar
La puntuación no es absoluta — refleja "la salud de lo que Gstack probó," no una garantía de que todo lo que Gstack no probó esté bien. Trátala como una métrica de referencia, no como un veredicto final.
Por Qué Vale la Pena Configurar /browse + /qa
Configurar las cookies del navegador y aprender la sintaxis de comandos requiere algo de inversión inicial. Pero lo que obtienes a cambio:
Un proceso QA que normalmente requiere que abras un navegador, hagas clic en una docena de páginas y confirmes que no hay regresiones — ahora se ejecuta con un solo comando mientras vas a por un café y vuelves al informe.
Para los desarrolladores en solitario este beneficio es especialmente claro — no siempre puedes encontrar tiempo para hacer pruebas manuales completas, pero /qa puede ejecutar una verificación de cordura básica cada vez que subes código.
Conceptos de cinco artículos cubiertos. El artículo final conecta todo, demostrando el flujo de trabajo completo de Gstack con un escenario de desarrollo real.
Volver a la Visión General de la Serie
Esta es la quinta parada de la serie Gstack, enfocada en /qa y /browse. Para el camino de lectura completo y otros temas de artículos, vuelve al Curso Gstack para Principiantes.