Prompts de pruebas de IA: obtén comprobaciones pequeñas para flujos clave de usuarios

Por qué sigues recibiendo funciones en lugar de pruebas

La mayoría de las herramientas de programación con IA están entrenadas para mostrar progreso visible. Si preguntas “¿Puedes mejorar el login?” la opción más segura suele ser añadir código, nuevas pantallas o opciones extra. Las pruebas parecen más lentas porque no cambian lo que puedes clicar de inmediato.

Otro problema es cómo se redactan muchos prompts. Cuando describes un problema sin límites claros, el modelo rellena huecos inventando extras: manejo de casos límite, nuevos ajustes, “detalles agradables”. Está tratando de ayudar, pero se está optimizando para construir, no para comprobar.

Enviar cambios sin comprobaciones pequeñas es la forma en que los flujos básicos de usuario se rompen en silencio. Un pequeño ajuste de UI puede detener el registro. Un refactor puede romper el restablecimiento de contraseña. Un cambio “fácil” en auth puede exponer secretos o saltarse validaciones. Sueles darte cuenta después de que los usuarios se quejen o cuando tu base de datos empieza a guardar datos erróneos.

Una “comprobación pequeña” es deliberadamente estrecha: una prueba rápida que confirma que un flujo clave sigue funcionando. No es un plan de pruebas completo ni una reescritura del framework. Es un conjunto corto de pasos y resultados esperados que puedes ejecutar en minutos (manual o automatizado) para detectar roturas costosas.

Los buenos prompts de pruebas con IA piden comprobaciones, no mejoras. Indican a la IA que evite añadir características y que se enfoque en resultados observables.

Una comprobación pequeña suele incluir el estado inicial, los pasos exactos, el resultado esperado y una o dos señales claras de fallo.

Las comprobaciones pequeñas protegen tus flujos de usuario más importantes porque actúan como trampas. Si el registro, login, pago o “crear proyecto” es tu negocio, quieres saber en el momento en que ese camino deja de funcionar, antes de apilar nuevas funciones encima.

Esto importa aún más con prototipos generados por IA. El código puede parecer “terminado” mientras la auth es frágil, las reglas de datos están desordenadas y hay fallos de seguridad a la vista. Un puñado de comprobaciones bien redactadas detecta esas fallas temprano y te permite seguir construyendo con confianza.

Elige primero los flujos a proteger

Si pides pruebas sin establecer prioridades, sueles obtener un montón de ideas vagas. Antes de escribir cualquier prompt de pruebas para la IA, elige un pequeño conjunto de flujos de usuario cuya ruptura sería perjudicial de inmediato.

Empieza con 3 a 5 flujos que sostienen el producto. Para muchas apps, eso es registro, login, pago (si cobras), crear lo principal (post/proyecto/tarea/archivo) y actualizar ajustes clave (email/contraseña/plan).

Ahora define “hecho” para cada flujo en una oración. Mantenlo claro y comprobable. Ejemplo: “Un usuario nuevo puede registrarse con email, recibe un mensaje de verificación y puede iniciar sesión después de verificar.” Esa frase se convierte en el ancla para las comprobaciones que le pides a la IA.

A continuación, elige el nivel de prueba que realmente necesitas. No te compliques. Usa la prueba más barata que detecte el tipo de rotura que esperas.

• Pruebas unitarias: mejor cuando una función o regla suele fallar (como las reglas de fuerza de contraseña).
• Pruebas de integración: mejor cuando varias partes deben funcionar juntas (auth + base de datos + sesión).
• Pruebas end-to-end: mejor para los flujos que ven los usuarios (registro, login, pago). Mantenlas pocas.

Para decidir rápido, escribe qué aspecto tendría la falla y cuán grave sería. ¿Qué costaría más en soporte mañana? ¿Qué impide que los usuarios obtengan valor? ¿Qué podría crear problemas de seguridad o dinero? ¿Qué suele romperse cuando “solo tocas una cosa”?

Ejemplo: si tu prototipo a veces desconecta a los usuarios aleatoriamente, protege login/logout con una verificación end-to-end y una de integración alrededor de la creación de sesión.

Dale a la IA el contexto correcto (sin sobrecompartir)

Si quieres pruebas, no describas tu producto como un pitch. Da justo el contexto necesario para definir “funcionar”, además de dónde empieza y dónde termina el flujo. Un buen contexto ayuda a la IA a producir comprobaciones pequeñas y aburridas en lugar de ideas de nuevas funciones.

Empieza con un resumen de dos líneas: qué hace la app y para quién es. Ejemplo: “Una app sencilla de programación para freelancers. Usuarios nuevos se registran, crean un enlace de reserva y lo comparten.”

Luego añade solo los datos técnicos que realmente conoces. No necesitas un diagrama de arquitectura. Unos pocos hechos ayudan a la IA a elegir comprobaciones realistas y a preparar los datos: framework, backend y base de datos (si lo sabes). Si no lo sabes, dilo. Adivinar es peor que dejarlo en blanco.

Sé preciso sobre el límite del flujo. Nombra el inicio y el fin exactos usando lo que tengas: nombres de pantalla, rutas o etiquetas de botones. “Inicio: /signup. Fin: redirigido a /dashboard con un toast ‘Welcome’.” Ese detalle suele marcar la diferencia entre una prueba y una lista de verificación vaga.

Agrega notas prácticas del entorno de pruebas para que la IA no invente pasos imposibles. Por ejemplo: si puedes usar un usuario seed (y cuáles son las reglas de contraseña), si estás en modo de pago de prueba (y qué significa “éxito”) y qué datos demo deben existir (un plan, una org, un proyecto).

Por último, explica el dolor actual en palabras sencillas: qué se rompe o qué es difícil de verificar. “El login a veces funciona, pero al refrescar me desconecta.” O: “El registro tiene éxito pero el correo de verificación nunca llega.” Esto dice a la IA dónde añadir comprobaciones y aserciones.

Evita sobrecompartir que distraiga al modelo: historias largas de usuario, volcado de código completo y todas las funciones en la hoja de ruta. Si la base de código está desordenada (común con prototipos generados por IA), dilo también.

Las reglas del prompt que hacen predecible la salida de pruebas

Si tu IA sigue proponiendo nuevas funciones, a tu prompt le falta un límite firme. Empieza declarando qué significa el éxito: comprobaciones que confirmen el comportamiento actual, no una reescritura.

Esta línea cambia todo: “Do not change app behavior. Only add tests.” También reduce la probabilidad de que el modelo “arregle” rutas de código para que las pruebas pasen.

Regla 1: Mantén el alcance pequeño y concreto

Las pruebas se complican cuando la solicitud es vaga. Elige un flujo (registro, pago, restablecer contraseña), un tipo de prueba y un pequeño conjunto de archivos. Si dices “añade pruebas para la app”, obtendrás conjeturas.

Buenas restricciones se ven así: un solo flujo, un solo tipo de prueba (unit o API o UI, no los tres), una carpeta o conjunto de archivos y una línea clara de “hecho” (por ejemplo: 5 comprobaciones que cubran el camino feliz y 2 fallos comunes).

Regla 2: Obliga una forma de salida consistente

Los prompts de pruebas funcionan mejor cuando exiges un formato predecible antes de escribir código. Pide nombres de prueba, pasos, aserciones y fixtures, en ese orden. Esto evita muros de texto y hace obvio lo que falta.

Un patrón de prompt que se mantiene legible:

Write tests only. Do not change production code.
Flow: [describe one flow]
Output:
1) Assumptions (max 5)
2) Questions (if needed, max 5)
3) Test list with names
4) For each test: steps + assertions + data fixtures
Constraints: deterministic data only; no randomness unless seeded.

Regla 3: Exige comprobaciones deterministas

Las pruebas frágiles consumen más tiempo que las pruebas faltantes. Di a la IA que evite aserciones basadas en tiempo, correos aleatorios y resultados sin ordenar a menos que pueda controlarlos (valores seed, relojes fijos).

Regla 4: Haz que admita incertidumbre

Exige que el modelo liste supuestos y haga preguntas antes de escribir pruebas. Esto es especialmente importante con prototipos generados por IA, donde la lógica suele ser poco clara.

Plantillas de prompt que producen comprobaciones pequeñas

La forma más sencilla de obtener comprobaciones pequeñas en lugar de nuevas funciones es ser estricto con el alcance: un flujo, un objetivo, un formato de salida. También di lo que no quieres: no ideas de UI, no refactors, no endpoints nuevos.

Usa las plantillas abajo tal cual y sustituye tu flujo y stack. Si la herramienta aún inventa funciones, repite la línea de “Constraints” al final.

Plantilla 1: Plan de pruebas mínimo para un flujo

Pide un plan corto antes de pedir pruebas completas. Mantiene la salida ajustada.

You are a QA tester.
Flow: \u003cname the single flow\u003e.
Goal: produce a minimal test plan with small checks.

Context:
- App type: \u003cweb/mobile\u003e
- Auth state: \u003clogged out/logged in\u003e
- Data needed: \u003ce.g., existing user, empty cart\u003e

Output format:
- 8-12 test checks max
- Each check is 1 sentence, starting with “Verify…”
- Cover happy path + 2 failure cases + 1 security-ish check

Constraints:
- Tests only. Do not suggest features, UI changes, refactors, or new APIs.
- If you need assumptions, list them under “Assumptions” (max 3).

Plantilla 2: Criterios de aceptación primero, luego pruebas

Útil cuando el flujo es vago o cuando necesitas redacción que funcione para stakeholders no técnicos.

Act as a product QA.
User flow: \u003cflow name\u003e.
User goal: \u003cone sentence\u003e.

Step 1: Write acceptance criteria in Given/When/Then (5-7 items).
Step 2: Convert each criterion into 1-2 small test checks.

Constraints:
- Do not add new features.
- Keep wording specific (no “should work”, no “fast”).
- If something is unclear, ask 2 questions max, then proceed with assumptions.

Plantilla 3: Casos límite y estados de error

Úsala cuando ya tengas una cobertura básica y quieras la lista de “lo que rompe en producción”.

You are generating edge-case checks for \u003cflow name\u003e.
List 10 small checks focused on boundary cases and error states.

Include cases like:
- invalid input (e.g., wrong password)
- expired/invalid session
- missing permissions
- rate limit / too many attempts
- network timeout and retry behavior

Constraints:
- Tests only. No feature suggestions.
- Each check must name the expected user-visible result (message, redirect, blocked action).

Plantilla 4: “Top 5 regresiones” después de un refactor

Buena para prototipos donde pequeños cambios silenciosamente rompen caminos clave.

We just refactored \u003carea: auth, payments, settings\u003e.
Give the top 5 regressions that commonly happen in \u003cflow name\u003e.
For each regression, provide:
- what breaks
- how to detect it (1 small check)
- what logs or signals would confirm it (1 short hint)

Constraints:
- Do not propose refactors or new features.
- Keep it to 5 items.

Plantilla 5: “Solo pruebas” con una regla estricta de no cambios

Úsala cuando tu herramienta de IA sigue “útilmente” reescribiendo el producto.

Task: write tests for \u003cflow name\u003e.

Hard rule:
- Output tests only.
- Do not suggest code changes, new features, new endpoints, or UI updates.

Tech:
- Framework: \u003cPlaywright/Cypress/Jest/etc\u003e
- App URL/routes: \u003clist\u003e
- Test data: \u003ccredentials, sample records\u003e

Output:
- Provide exactly 6 tests: 3 happy path, 2 negative, 1 security check.
- If any test is not possible with given info, write a placeholder test with TODO and explain what info is missing (1 sentence).

Si la herramienta no puede escribir una prueba sin inventar comportamiento, ese suele ser el primer indicio de que necesitas un diagnóstico real antes de añadir más código.

Paso a paso: ve de cero a una prueba útil en 30 minutos

Obtendrás una prueba útil rápido si dejas de intentar cubrirlo todo. Elige un flujo, escribe una comprobación pequeña y luego expande.

1. Escribe un camino feliz para un flujo. Elige un inicio y un fin. Ejemplo: “Usuario se registra con un email no usado y llega al dashboard.” Manténlo lo bastante corto como para que un fallo indique algo específico.

2. Añade un caso negativo que coincida con la realidad. No inventes casos límite todavía. Usa un fallo que realmente hayas visto, como “el login falla con la contraseña correcta” o “el registro tiene éxito pero no se crea el usuario”.

3. Aserta lo que el usuario nota, no detalles internos. Comprueba resultados: mensaje de éxito, redirección, botón habilitado, fila guardada en la base de datos o banner de error. Si no puedes explicar el resultado esperado en una frase, la prueba es demasiado grande.

4. Ejecútala una vez y copia el fallo exacto. No parafrasees. Detalles pequeños como un nombre de ruta o un código de estado suelen apuntar al problema real.

5. Pide a la IA que arregle la prueba primero. Las pruebas fallan por razones aburridas: selectores cambiados, problemas de timing, setup incorrecto, falta de datos seed. Solo pídele cambiar la app si el comportamiento esperado es claramente correcto y la app está claramente equivocada.

Si estás atascado, pega tres cosas en tu prompt: la historia de usuario (una frase), el comportamiento actual (lo que viste) y el fallo (texto exacto). Por ejemplo: “Al registrarme aparece éxito, pero al refrescar estoy desconectado” más la aserción fallida.

Errores comunes que hacen perder tiempo

La forma más rápida de perder una tarde es pedir pruebas de forma vaga y luego aceptar cualquier cosa que devuelva la IA. Acabas con páginas de “cobertura” que no protegen lo que realmente te importa: que una persona real pueda completar un flujo clave.

Estos errores aparecen constantemente:

• Pedir “probar todo” o “cobertura completa.” Obtienes muchas comprobaciones de bajo valor (estados vacíos, detalles menores de UI, casos límite que ni siquiera decidiste).
• Dejar que la IA cambie el producto para que las pruebas pasen. Sugerirá cambiar mensajes de error, relajar validaciones o saltarse auth para reducir fallos. Eso reescribe requisitos, no prueba.
• Escribir comprobaciones frágiles atadas a detalles de UI. Si una prueba depende de un selector CSS específico, un layout o el texto exacto de un botón, fallará al mínimo ajuste.
• Omitir setup y limpieza. Sin datos claros y un paso de reset, una ejecución afecta a la siguiente. Eso crea fallos intermitentes.
• No fijar versiones y datos de prueba. Si el runner, el navegador, los datos seed o las variables de entorno cambian entre ejecuciones, los resultados son inconsistentes.

Un ejemplo simple: pides una prueba de login y la IA escribe “haz clic en el tercer botón del header, luego espera el texto ‘Welcome back!’”. La semana siguiente renombras el botón a “Sign in” y la prueba falla aunque el login funcione.

Unas pocas reglas evitan la mayoría de esto:

• Declara lo que no debe cambiar (reglas, validación, seguridad, copy si importa).
• Prefiere hooks estables (test IDs, respuestas API, registros de DB) sobre detalles visuales.
• Exige repetibilidad (datos seed, paso de reset, versiones fijas).

Comprobaciones rápidas para una prueba buena (antes de añadir más)

Antes de añadir más cobertura, asegúrate de que cada prueba realmente aporta valor. Una comprobación pequeña y fiable supera a diez frágiles.

Cinco comprobaciones de sentido común que detectan la mayoría de pruebas malas

• Rompe el flujo a propósito y observa por qué falla. Usa una contraseña incorrecta, elimina un campo requerido o bloquea una petición. El fallo debe señalar el paso de usuario que falló, no un timeout no relacionado.
• Aserta algo que el usuario pueda ver. Prefiere “muestra mensaje de error” o “llega al dashboard” antes que “el console.log contiene X” o “la API devolvió 200” por sí solo.
• Ponle un nombre legible. “login rechaza contraseña incorrecta” vence a “auth test 3.” Cuando una prueba falla en despliegue, el nombre debe indicar qué flujo está en riesgo.
• Ejecútala dos veces seguidas sin sorpresas. Si la segunda falla porque el usuario ya existe, la prueba no está aislada.
• Haz que las actualizaciones sean baratas cuando la UI cambie. Si cambia la etiqueta de un botón, actualiza un selector o helper, no diez archivos.

Un ejemplo rápido (registro)

Si tu prueba de registro solo comprueba “POST /signup devuelve 201”, puede pasar por alto el problema real: la UI muestra una página en blanco porque una redirección falló. Una comprobación mejor es: completar email y contraseña, enviar y confirmar que llegas a una página que demuestra que estás logeado (como un saludo o un botón “Log out”).

Ejemplo: proteger registro y login en una app simple

Una historia común: pides a una herramienta de IA “limpiar” tu código, hace un refactor y el onboarding se rompe en silencio. La UI parece bien, pero el registro deja de crear usuarios, los enlaces de verificación 404 o el login solo funciona a veces porque cambió la cookie de sesión.

En lugar de pedir más funciones, usa prompts de pruebas de IA para obtener tres comprobaciones pequeñas que protejan el flujo que más te importa:

• El registro crea un usuario nuevo y muestra el siguiente paso esperado
• La verificación por email marca al usuario como verificado (o desbloquea el login)
• El primer login funciona tras la verificación y llega a la página correcta

Aquí tienes prompts exactos que puedes pegar en tu herramienta de IA. Están escritos para forzar comprobaciones pequeñas, no una suite gigante.

You are helping me write SMALL user-flow checks, not new features.
App context:
- Stack: [fill in: e.g., Next.js + Supabase]
- Auth: [fill in: email/password]
- Environments: local only
- Seed user: none

Goal: Create 3 checks for onboarding.
Flows:
1) Signup
2) Email verification
3) First login

Output format MUST be:
- For each check: Name, Preconditions, Steps (max 6), Expected results (max 5)
- No code. No extra commentary.
- Use plain English.

Si tu app usa un enlace por email, añade esta restricción para que la salida sea realista:

Email verification detail:
- The app sends a verification link to the user.
- For the check, assume we can access the link in a test inbox OR read the token from logs.
- Do not invent third-party tools.

Estructura esperada (qué aspecto tiene una “buena salida”):

Check 1: Signup creates account
Preconditions: ...
Steps:
1. ...
Expected results:
- ...

Check 2: Email verification enables login
...

Check 3: First login lands on dashboard
...

Cuando una de estas comprobaciones falla, haz una división rápida:

• Bug: el comportamiento de la app es incorrecto (no se creó el usuario, la verificación no hace nada, el login devuelve 500)
• Error de prueba: la comprobación asumió texto de pantalla, ruta o método de verificación equivocado

Una regla rápida: si un usuario real quedaría bloqueado, trátalo como bug. Si el usuario aún puede completar el flujo pero cambió el wording o los selectores, probablemente fue un error de prueba.

Para un prototipo que avanza hacia producción, “suficiente” suele significar que las comprobaciones son estables, pequeñas y detectan fallos reales:

• Cada comprobación cabe en una pantalla y tarda menos de 10 minutos en ejecutarse manualmente
• Falla por la razón correcta (no por cambios triviales de texto)
• Cubre el camino feliz end-to-end
• Tiene resultados esperados claros que cualquiera pueda verificar
• Es fácil de volver a ejecutar tras un refactor generado por IA

Próximos pasos: mantén tu prototipo seguro a medida que crece

Una vez tengas unas pocas comprobaciones que detecten fallos reales, la meta es simple: añadir protección sin convertir las pruebas en un segundo trabajo. Mantén una lista muy pequeña de las acciones de usuario que te niegas a dejar que se rompan.

Escribe una página con los “flujos protegidos”. Manténla aburrida: registro/login/logout, pago o “empezar prueba”, crear/editar/borrar el elemento principal, pagos o cambios de plan (si aplica) y el correo o notificación que los usuarios deben recibir.

Añade exactamente una prueba pequeña por flujo primero. Si usas prompts de pruebas de IA, quédate con el camino feliz más un fallo común (contraseña incorrecta, campo requerido vacío, token expirado). Eso suele encontrar más bugs reales que una petición grande de “probar todo”.

Ejecuta las comprobaciones antes de cada release y antes de cualquier traspaso (a una agencia, un nuevo dev o a tu yo del futuro). Si tu prototipo cambia a diario, elige un disparador que te obligue a ejecutarlas, por ejemplo “antes de publicar en producción” o “antes de enviar un enlace de demo”.

Si la autenticación es inestable, hay secretos expuestos o la arquitectura es un espagueti, las pruebas solas no te salvarán. Perseguir fallos ruidosos consumirá tiempo. En esos casos, un diagnóstico y limpieza cortos primero hacen que las pruebas posteriores valgan la pena.

Si heredaste una base de código generada por IA y necesitas ese diagnóstico rápido, FixMyMess (fixmymess.ai) se centra en diagnóstico de código, reparación de lógica, endurecimiento de seguridad, refactor y preparación para despliegue, empezando con una auditoría de código gratuita.

Manténlo simple mientras creces:

• Protege una lista pequeña de flujos
• Añade una prueba por flujo
• Ejecuta comprobaciones antes de release o traspaso
• Diagnostica y arregla bases desordenadas antes de ampliar la cobertura
• Solo entonces añade más casos límite