Pruebas de QA con Codex y Playwright

Qué hace Codex para pruebas de QA

• Escribe tests end-to-end para los flujos que importan: registro, pago, las pantallas principales.
• Ejecuta la suite, lee los fallos y arregla el test o el código, diciendo cuál.
• Maneja un navegador real para comprobar un cambio a mano, y registra bugs con pasos y capturas de pantalla.
• Encuentra los tests inestables y los pone en cuarentena con una issue, en lugar de reintentarlos hasta que pasen.

Funciones de Codex para pruebas de QA

Cómo configurar Codex para pruebas de QA

1. Conecta las herramientas

   Añade el servidor MCP de Playwright con un comando, o con la misma tabla en config.toml. Si los tests tienen que llegar a una web de staging, activa el acceso a la red del sandbox.

   # Un navegador real para comprobaciones exploratorias
   codex mcp add playwright npx "@playwright/mcp@latest"
   
   # O en ~/.codex/config.toml
   [mcp_servers.playwright]
   command = "npx"
   args = ["@playwright/mcp@latest"]

2. Escribe las reglas en AGENTS.md

   Codex lee AGENTS.md antes de empezar a trabajar: ~/.codex/AGENTS.md y después los archivos desde la raíz del repositorio hasta la carpeta en la que trabaja. Pon ahí las reglas del trabajo, o en una skill dentro de .agents/skills/ si son largas. Consulta la guía de AGENTS.md.

   ## Reglas de QA
   - Prueba contra la app local o de staging, nunca contra producción.
   - Usa las cuentas de prueba de .env.example, nunca cuentas reales.
   - Un test que falla es un hallazgo: di si el que está mal es el test
     o el código antes de cambiar cualquiera de los dos.
   - Cada informe de bug: pasos, resultado esperado, resultado real,
     una captura de pantalla y el commit que probaste.
   - No borres ni te saltes un test para que la suite pase.

3. Ejecútalo sin la interfaz interactiva

   codex exec ejecuta una tarea y termina. El progreso va a stderr y el mensaje final a stdout; -o también lo escribe en un archivo y --json emite los eventos en streaming. El sandbox es de solo lectura salvo que pases --sandbox workspace-write.

   # Pásale a Codex la salida de los tests que fallan
   npm test 2>&1 | codex exec "resume los tests que fallan y propón el arreglo probable más pequeño"

4. Ponlo en un horario

   Crea una tarea programada en la app de escritorio de ChatGPT o en la web (la CLI no las gestiona), o ejecuta codex exec desde cron. Consulta cómo hacer que Codex sea proactivo.

Fuente: documentación de Codex

Límites y seguridad

• Prueba lo que tiene a su alcance: una app local o de staging con datos de prueba, no producción.
• Una suite que pasa solo cubre los flujos para los que alguien escribió tests. Pídele que enumere lo que no está cubierto.
• Las ejecuciones en el navegador son lentas y consumen más de tu plan. Ejecuta la suite completa según un horario y un smoke test en cada cambio.
• Codex ejecuta los comandos en un sandbox por defecto: las escrituras se quedan en el workspace y la red está desactivada. Reserva danger-full-access para un runner o un contenedor aislado.

¿Claude Code o Codex para pruebas de QA?

Las reglas sirven para los dos. Escríbelas una vez en AGENTS.md y pon @AGENTS.md en CLAUDE.md, y los dos agentes leerán el mismo archivo.

Paso a paso con el otro agente: pruebas de QA con Claude Code.

Dale a alguien el trabajo de pruebas de QA

Los comandos se ejecutan cuando alguien se acuerda de ejecutarlos. Crewmark convierte tu propio Codex en un empleado de IA con un rol, un objetivo en cifras, horario laboral y un heartbeat, para que el trabajo se haga según un horario y aparezca en un tablero.

1. Empieza por el rol

   El ingeniero de software de IA, con estas reglas en su brief.

2. Lleva el trabajo a su tablero

   Añade el trabajo como issue recurrente. El empleado se despierta con su heartbeat, lo hace e informa en un comentario.

3. Relacionado

   Issues de GitHub cubre qué pasa con los bugs que registra.

Preguntas frecuentes