Un modelo de IA genera la continuación más probable de tu entrada: un prompt vago como "escribe un test de Playwright para el login" produce un esqueleto con marcadores YOUR_URL y selectores CSS porque eso es lo que más abunda en los datos de entrenamiento. La misma solicitud con un rol, contexto específico y restricciones explícitas sobre los tipos de locators produce código que puedes pegar directamente. Este artículo cubre la estructura de cuatro partes de un prompt, las instrucciones específicas que previenen los errores más comunes en la generación de tests con IA, prompts para revisión de código y depuración, y qué hacer cuando el output vuelve a patrones genéricos después de varias iteraciones.
Por qué la calidad del output de la IA es principalmente tu problema
Claude, ChatGPT y GitHub Copilot no son buscadores. Generan la continuación más probable de tu entrada. Si la entrada es vaga, la continuación es genérica. Si la entrada es específica y bien estructurada, el output es útil.
El modelo no sabe:
- Qué framework estás usando
- Cómo está estructurado tu código
- Qué nivel de detalle quieres
- Qué ya intentaste
- Bajo qué restricciones trabajas
Cuando el output es malo, la primera pregunta no es "¿este modelo es malo?". Es "¿mi prompt le dio al modelo lo que necesitaba para hacer esto bien?"
La estructura de cuatro partes de un prompt
Un prompt que funciona para tareas de QA generalmente tiene cuatro componentes. No siempre los necesitas todos, pero cuando el output es pobre, generalmente falta uno.
Rol
Dile al modelo qué experto debe ser. "Eres un ingeniero senior de automatización de QA" o "Eres un experto en TypeScript especializado en arquitectura de tests con Playwright" cambia el registro y la profundidad del output.
Contexto
Describe la situación. Qué framework, qué lenguaje, qué tipo de app, qué restricción. Cuanto más específico, mejor.
Tarea
La solicitud real, formulada con precisión. No "escribe un test" sino "escribe un test de Playwright en TypeScript que inicie sesión usando storageState y verifique que el encabezado del dashboard muestra el nombre de usuario".
Formato
Cómo quieres el output. ¿Solo código? ¿Código con comentarios? ¿Con una breve explicación primero? ¿Una tabla? Especifícalo, o recibirás lo que el modelo produce por defecto.
Ejemplo de un prompt malo:
"Escribe un test de Playwright para el login"
El mismo prompt con los cuatro componentes:
"Eres un ingeniero senior de automatización de QA. Estoy trabajando en un proyecto de Playwright TypeScript usando el patrón Page Object Model. La página de login está en https://lab.becomeqa.com, usa un formulario de email/contraseña, y redirige a /dashboard al ingresar correctamente. Escribe un test que: inicie sesión con credenciales de variables de entorno, verifique que la URL cambia a /dashboard, y verifique que un encabezado con el texto 'My Travel Items' es visible. Usa solo locators getByRole y getByLabel. Sin comentarios en el código."
El segundo prompt te da código que puedes pegar directamente. El primero te da un esqueleto con marcadores.
Prompts para generación de tests
Al generar tests de Playwright, los problemas más comunes son:
Locators genéricos
La IA usa lo que más vio en los datos de entrenamiento, que incluye muchos selectores CSS. Apártala de ellos de forma explícita.
"Usa solo locators getByRole, getByLabel, getByPlaceholder o getByTestId. No uses selectores CSS ni XPath."
Aserciones faltantes
Los tests generados suelen tener una sola aserción al final. Los tests reales necesitan más.
"Incluye aserciones en cada paso significativo, no solo en el estado final. Verifica los estados intermedios donde importen."
Sin contexto de manejo de errores
Si estás probando un escenario de error, dilo explícitamente.
"Escribe un test para el caso donde el usuario envía el formulario con el campo de email vacío. Verifica que aparece el mensaje de error 'El email es requerido' debajo del input de email."
Datos de prueba hardcodeados
Previene esto desde el principio.
"Usa process.env para las credenciales. No hardcodees nombres de usuario, contraseñas ni URLs. Usa referencias a variables de entorno en su lugar."
Generar tests a partir de una historia de usuario
Este patrón de prompt es especialmente útil. Pega una historia de usuario directamente y pide los tests:
"Eres un ingeniero de automatización de QA. Aquí hay una historia de usuario:>
'Como usuario autenticado, quiero agregar un nuevo ítem a mi lista de viaje para poder registrar qué empacar.'>
La app está en https://lab.becomeqa.com. Escribe tests de Playwright TypeScript que cubran: el camino feliz (el ítem se agrega y aparece en la lista), agregar un ítem duplicado, y agregar un ítem con un nombre que supera el límite de caracteres. Usa locators getByRole. Incluye una aserción por test que verifique el resultado específico. Devuelve solo el código de los tests."
Generar datos de prueba
Para la generación de datos de prueba, la sintaxis de Faker.js cambia entre versiones y los modelos de IA a veces inventan nombres de métodos. Áncalo:
"Genera una función factory en TypeScript que crea un objeto de usuario aleatorio con los campos: email (formato válido), firstName, lastName, password (al menos 8 caracteres, una mayúscula, un número). Usa solo la sintaxis de @faker-js/faker v8. Devuelve solo la función."
Prompts para revisión de código
La revisión de código con IA está subutilizada entre los QA engineers. Es especialmente buena para detectar cosas que son fáciles de pasar por alto en una primera lectura.
Revisar la calidad de los tests
"Revisa este test de Playwright en busca de: esperas hardcodeadas (page.waitForTimeout), selectores CSS, aserciones faltantes, tests que dependen del orden de ejecución, y cualquier práctica que reduzca la estabilidad del test. Lista cada problema con la línea donde aparece y por qué es un problema."
Revisar la consistencia del Page Object Model
"Estoy construyendo un Page Object Model en TypeScript. Aquí está mi clase base y un page object. Revisa si: todos los selectores están en la clase del page (no en los tests), los métodos de acción devuelven promesas correctamente, el constructor sigue el patrón, y si le faltan métodos que serían útiles según lo que está importado. Sugiere adiciones específicas."
Verificar la calidad de los locators
"Mira estos locators de mis tests de Playwright. Para cada uno, dime: ¿es frágil (probable que se rompa en un rediseño de la UI)? Si es así, sugiere una alternativa más estable usando locators semánticos."
Prompts para depuración
Cuando un test falla y no sabes por qué, la IA puede ayudar, pero necesitas darle el output del fallo, no solo el código.
Plantilla para pedir ayuda con la depuración
"Este test de Playwright está fallando. Aquí está:
1. El código del test
2. El mensaje de error completo y el stack trace
3. Lo que se supone que debe hacer la app>
[pega cada cosa]>
¿Cuáles son las causas más probables de este fallo? Lístalas por orden de probabilidad y para cada una explica qué debería revisar."
El mensaje de error es fundamental. Sin él, el modelo está adivinando. Con él, a menudo puede identificar el problema exacto: un await faltante, un locator que no coincide, un problema de timing.
Diagnóstico de tests flaky
"Este test pasa aproximadamente el 70% de las veces y falla el 30% con este error: [error]. El test hace: [describe el flujo]. ¿Cuáles son las causas probables de este fallo intermitente en Playwright? ¿Qué revisarías primero?"
Prompts para documentación
Generar documentación para código de tests existente es uno de los usos de mayor valor de la IA en QA. A nadie le gusta escribirla, lleva tiempo, y la IA lo hace razonablemente bien.
Generar un README para la suite de tests
"Escribe una sección de README para este directorio de tests de Playwright. Incluye: qué cubre la suite, requisitos previos (variables de entorno necesarias, pasos de configuración), cómo ejecutar todos los tests, cómo ejecutar un archivo específico, y cómo ejecutar en modo debug. Básate en este playwright.config.ts y este ejemplo de archivo de test: [pega ambos]"
Resumir la cobertura de tests
"Aquí están mis archivos de tests de Playwright. Para cada archivo, escribe una oración describiendo qué prueba. Luego escribe un párrafo resumen de qué está cubierto y qué falta según los flujos típicos de una web app con login, gestión de datos y funcionalidad de exportación."
Generar un reporte de bug a partir de un test fallido
"Este test de Playwright está fallando y necesito escribir un reporte de bug. Aquí está el test, el error y las capturas de pantalla. Escribe un reporte de bug con este formato: Título, Entorno, Pasos para Reproducir, Resultado Esperado, Resultado Actual, Severidad."
Prompts para aprender
Cuando estás aprendiendo una nueva función de Playwright, no pidas ejemplos genéricos. Pide ejemplos específicos para tu tipo de proyecto:
"Explica cómo funciona storageState en Playwright, usando un ejemplo concreto donde una suite de tests tiene roles de admin y usuario regular. Muestra el archivo de setup que genera los estados y un test que usa cada rol. Usa TypeScript."
"Entiendo cómo funciona page.route() para mocking simple. Explica cómo usar route.fallback() para hacer un mock parcial de una API, dejando pasar algunas peticiones al backend real mientras interceptas solo las específicas. Muestra un ejemplo concreto."
La restricción concreta obliga al modelo a ir más allá de la explicación introductoria hacia la parte que realmente es útil.
Cuándo iterar y cuándo reiniciar
Después de recibir output de la IA, tienes dos opciones: iterar sobre él o reiniciar con un prompt mejor.
Itera cuando la estructura es correcta pero algo específico está mal. Haz preguntas de seguimiento concretas como cambiar el locator en la línea 8 para usargetByLabel en vez de getByPlaceholder, agregar una aserción después del envío del formulario que verifique que el toast de éxito es visible, o refactorizar el helper de login en una función separada.
Reinicia cuando el enfoque general está mal: el modelo generó JavaScript cuando querías TypeScript, produjo tests sin un Page Object cuando lo pediste, o malinterpretó el escenario de testing por completo. En ese punto, un prompt mejor desde el inicio es más rápido que intentar redirigir.
Una buena regla: si iteraste tres veces y todavía estás corrigiendo problemas estructurales, reinicia con un prompt más detallado.
Ventanas de contexto y conversaciones largas
Las herramientas de IA pierden contexto en conversaciones largas. Después de más de 20 intercambios, el modelo puede empezar a "olvidar" cosas que estableciste al principio, como la convención de locators que especificaste o la estructura de clases que pediste.
Mantén un documento de plantillas de prompts
Para tareas comunes (generar un test, revisar un page object, escribir un reporte de bug), guarda tus mejores prompts. No los reescribas. Cópialos y ajústalos.
Empieza una nueva conversación por cada tarea
El contexto reutilizable en una conversación genera confusión en otra. Las conversaciones cortas y enfocadas producen mejor output que las sesiones extensas.
Reitera las restricciones clave si el output se desvía
Si el modelo empieza a usar selectores CSS después de que le dijiste que no, recuérdaselo explícitamente: "Recuerda: solo getByRole, getByLabel, getByPlaceholder, getByTestId. Sin selectores CSS."
Lo que las herramientas de IA no pueden hacer en QA
Entender los límites previene la frustración y te ayuda a saber cuándo parar.
No pueden ejecutar tus tests
El modelo no tiene acceso a tu navegador, tu app ni tu test runner. Puede escribir código que cree que funcionará, pero no puede verificarlo.
No pueden inspeccionar tu app en vivo
Sin Playwright MCP configurado, el modelo no sabe cómo se ve tu UI. Está escribiendo tests contra una versión imaginaria de tu app basada en lo que describes. Si tu descripción es incompleta, los locators generados estarán mal.
Inventan detalles de la API
Las herramientas de IA a veces generan llamadas a métodos de Playwright que no existen, o usan métodos reales con firmas de parámetros incorrectas. Siempre verifica el código generado contra la documentación de Playwright antes de commitearlo.
No conocen las convenciones de tu equipo
A menos que pegues tu código real como contexto, el modelo no sabe si tu equipo usa factories o fixtures para los datos de prueba, cómo funciona tu clase base de página, o cómo está estructurado tu sistema de imports. Dale ejemplos.
No pueden tomar decisiones sobre cobertura
"¿Qué debería probar?" requiere entender el riesgo de la funcionalidad, la velocidad del equipo, qué ha fallado en producción y cuál es el nivel de riesgo aceptable. La IA puede sugerir cosas a probar, pero las decisiones de cobertura son tuyas.
Construir una biblioteca personal de prompts
Con el tiempo, colecciona los prompts que funcionan. Guárdalos en un archivo markdown, una página de Notion, o una carpeta de comandos .claude en tu proyecto.
Categorías útiles para desarrollar:
- Generar un nuevo test a partir de una descripción
- Revisar un archivo de tests para problemas de calidad
- Generar datos de prueba con Faker
- Escribir una clase Page Object a partir de la descripción de una página
- Depurar un error de Playwright
- Generar un reporte de bug a partir de un test fallido
- Resumir los gaps de cobertura de tests
- Generar YAML de workflow de CI para Playwright
