How to Haz QA de tu app con Computer Use with Eigent

Cómo funciona

1. Indícale a Eigent qué entorno de la app debe probar y qué flujos de usuario son los más importantes.
2. Eigent hace clic a través de los flujos, escribe en los campos y registra lo que falla.
3. Por cada bug encontrado, Eigent documenta los pasos de reproducción, el resultado esperado, el resultado real y la severidad.
4. Eigent continúa a pesar de los problemas no bloqueantes y termina con un breve resumen de triage.
5. Opcionalmente, pide a Eigent que corrija un bug encontrado, cree issues en Linear o limite el siguiente pase a un solo flujo fallido.

Más prompts para probar

• Prueba mi app. Encuentra cualquier problema importante y dame un informe.
• Prueba el registro, invita a un compañero de equipo y actualiza la facturación en staging. Registra cada bug con pasos de reproducción, resultado esperado, resultado real y severidad.
• Continúa el pase de QA y céntrate solo en el flujo de pago; quiero entender todos los casos límite.
• Convierte los bugs P1 de este informe en borradores de issues en Linear.

Cómo usar

Indícale a Eigent qué entorno debe probar (local, staging o similar a producción) y qué flujos debe cubrir. Nombra los tipos de problemas que te importan: funcionalidad rota, problemas de diseño, texto confuso o todo lo anterior. Si el estado de la cuenta, los datos de prueba o los flags de características afectan el flujo, inclúyelo desde el principio. Si una sola incidencia bloqueante debe terminar la ejecución, indícalo; de lo contrario, Eigent recopila todos los problemas y los resume al final. Después del pase, pide a Eigent que corrija bugs, cree tickets o ejecute un pase de seguimiento en un flujo fallido específico.

Resultado esperado

Un informe de errores estructurado que enumera cada problema encontrado con pasos de reproducción, resultado esperado frente a resultado real y severidad. Termina con un breve resumen de triage de los hallazgos P0–P2 y las siguientes acciones recomendadas.

Limitaciones

• Computer Use ejecuta la UI directamente; no puede probar lógica del lado del servidor ni trabajos en segundo plano que no sean visibles en la interfaz.
• La precisión de la prueba depende de proporcionar desde el principio un estado de cuenta y detalles del entorno claros.
• Los planes de prueba muy largos o complejos se benefician de dividirse en pases enfocados en lugar de una sola ejecución larga.