31 dic 2025·7 min
Pruebas de aceptación desde prompts: convierte funciones en escenarios
Aprende a convertir cada feature prompt en 5–10 escenarios de aceptación claros que cubran ruta feliz y casos límite, sin suites de pruebas infladas.
Aprende a convertir cada feature prompt en 5–10 escenarios de aceptación claros que cubran ruta feliz y casos límite, sin suites de pruebas infladas.
Los prompts en estilo chat parecen claros porque se leen como una conversación. Pero a menudo condensan elecciones, reglas y excepciones en unas pocas frases amables. Las lagunas no aparecen hasta que alguien usa la función en la práctica.
La mayoría de los prompts dependen silenciosamente de supuestos: quién puede realizar la acción, qué cuenta como “éxito” (guardado, enviado, publicado, pagado), qué sucede cuando faltan datos y qué debe ver el usuario cuando algo falla. También ocultan estándares difusos como qué significa “lo suficientemente rápido” o “lo suficientemente seguro”.
La ambigüedad suele manifestarse tarde en forma de bugs y retrabajo. Un desarrollador construye lo que cree que significa el prompt, un revisor lo aprueba porque parece correcto, y luego los usuarios encuentran los casos raros: envíos duplicados, zonas horarias, datos parciales o desajustes de permisos. Arreglar esto después cuesta más porque suele afectar código, texto de la UI y a veces el modelo de datos.
La calidad no requiere suites de pruebas enormes. Significa que puedes confiar en la función en uso normal y bajo estrés predecible. Un pequeño conjunto de escenarios bien escogidos te da esa confianza sin cientos de pruebas.
Una definición práctica de calidad para funciones construidas desde prompts:
Ese es el objetivo de transformar prompts en escenarios de aceptación: tomar una petición difusa y convertirla en 5–10 comprobaciones que saquen a la luz las reglas ocultas pronto. No intentas probarlo todo. Intentas atrapar las fallas que realmente suceden.
Si construyes desde un prompt rápido en una herramienta tipo Koder.ai, la salida puede parecer completa mientras sigue saltándose reglas límite. Un conjunto de escenarios ajustado obliga a nombrar esas reglas mientras los cambios aún son baratos.
Un escenario de aceptación es una breve descripción en lenguaje llano de una acción del usuario y el resultado que debe ver.
Mantente en la superficie: lo que el usuario puede hacer y lo que el producto muestra o cambia. Evita detalles internos como tablas de base de datos, llamadas API, jobs en segundo plano o qué framework se usa. Esos detalles pueden importar después, pero vuelven los escenarios frágiles y más difíciles de consensuar.
Un buen escenario también es independiente. Debe ser fácil de ejecutar mañana en un entorno limpio, sin depender de que otro escenario se haya ejecutado antes. Si un escenario depende de un estado previo, indícalo claramente en la configuración (por ejemplo, “el usuario ya tiene una suscripción activa”).
Muchos equipos usan Given–When–Then porque obliga a la claridad sin convertir los escenarios en una especificación completa.
Un escenario suele estar “hecho” cuando tiene un objetivo, un estado inicial claro, una acción concreta y un resultado visible. Debe ser binario: cualquiera del equipo puede decir “aprobado” o “fallado” después de ejecutarlo.
Ejemplo: “Dado un usuario conectado sin método de pago guardado, cuando elige Pro y confirma el pago, entonces ve un mensaje de éxito y el plan aparece como Pro en su cuenta.”
Si construyes en un creador orientado al chat como Koder.ai, aplica la misma regla: prueba el comportamiento de la app generada (lo que experimenta el usuario), no cómo la plataforma produjo el código.
El mejor formato es el que la gente escribirá y leerá. Si la mitad del equipo usa narrativas largas y la otra mitad escribe viñetas breves, tendrás huecos, duplicados y discusiones sobre la redacción en lugar de mejora de calidad.
Given–When–Then funciona bien cuando la función es interactiva y con estado. Una tabla simple funciona mejor cuando tienes reglas de entrada-salida y muchos casos similares.
Si tu equipo está dividido, elige un formato durante 30 días y ajústalo después. Si los revisores siguen preguntando “¿qué significa éxito?”, suele ser señal de moverse hacia Given–When–Then. Si los escenarios se vuelven extensos, una tabla puede ser más fácil de escanear.
Pase lo que pase, estandarízalo. Mantén los mismos encabezados, el mismo tiempo verbal y el mismo nivel de detalle. También acordad qué no incluir: detalles pixel-perfect de UI, implementación interna y lenguaje de base de datos. Los escenarios deben describir lo que ve el usuario y lo que el sistema garantiza.
Pon los escenarios donde ya ocurre el trabajo y mantenlos cerca de la funcionalidad.
Opciones comunes incluyen guardarlos junto al código del producto, en los tickets bajo una sección “Acceptance scenarios”, o en un espacio compartido con una página por función. Si usas Koder.ai, también puedes conservar los escenarios en Modo de planificación para que permanezcan con el historial de la build junto a snapshots y puntos de rollback.
La clave es hacerlos buscables, tener una única fuente de verdad y exigir escenarios antes de considerar que la implementación ha “comenzado”.
Empieza reescribiendo el prompt como un objetivo del usuario más una línea de llegada clara. Usa una oración para el objetivo (quién quiere qué), y luego 2–4 criterios de éxito que puedas verificar sin discutir. Si no puedes señalar un resultado visible, aún no tienes una prueba.
A continuación, desglosa el prompt en entradas, salidas y reglas. Las entradas son lo que el usuario proporciona o selecciona. Las salidas son lo que el sistema muestra, guarda, envía o bloquea. Las reglas son los “solo si” y “debe” escondidos entre líneas.
Después, comprueba de qué depende la función antes de que pueda funcionar. Aquí es donde se esconden los huecos: datos requeridos, roles de usuario, permisos, integraciones y estados del sistema. Por ejemplo, si construyes una app en Koder.ai, indica si el usuario debe iniciar sesión, crear un proyecto o cumplir requisitos de plan o acceso antes de que la acción pueda ocurrir.
Ahora escribe el conjunto mínimo de escenarios que pruebe que la función funciona: normalmente 1–2 rutas felices y luego 4–8 casos límite. Mantén cada escenario centrado en una razón de fallo.
Buenos casos límite para elegir (solo lo que encaje con el prompt): entrada faltante o inválida, desajuste de permisos, conflictos de estado como “ya enviado”, problemas con dependencias externas como timeouts, y comportamiento de recuperación (errores claros, reintento seguro, sin guardado parcial).
Termina con un rápido repaso de “¿qué podría salir mal?”. Busca fallos silenciosos, mensajes confusos y lugares donde el sistema podría crear datos incorrectos.
Un escenario de ruta feliz es la ruta más corta y normal donde todo sale bien. Si la mantienes aburrida a propósito, se convierte en una línea base fiable que facilita detectar casos límite después.
Nombra el usuario por defecto y los datos por defecto. Usa un rol real, no “Usuario”: “Cliente con sesión iniciada y email verificado” o “Admin con permiso para editar facturación”. Luego define los datos de ejemplo más pequeños que tengan sentido: un proyecto, un elemento en una lista, un método de pago guardado. Esto mantiene los escenarios concretos y reduce supuestos ocultos.
Escribe primero la vía más corta hacia el éxito. Elimina pasos opcionales y flujos alternativos. Si la función es “Crear una tarea”, la ruta feliz no debería incluir filtrado, ordenación o edición posterior a la creación.
Una forma sencilla de mantenerlo ajustado es confirmar cuatro cosas:
Luego añade una variante que cambie solo una variable. Elige la variable más probable de romperse después, como “título largo” o “usuario sin items previos”, y mantiene todo lo demás idéntico.
Ejemplo: si tu prompt dice “Añadir un toast ‘Snapshot created’ tras guardar un snapshot”, la ruta feliz es: el usuario hace clic en Crear snapshot, ve un estado de carga, recibe “Snapshot created” y el snapshot aparece en la lista con la marca de tiempo correcta. Una variante de una sola variable podría ser los mismos pasos pero con un nombre en blanco y una regla de nombrado por defecto clara.
Los casos límite son donde se esconden la mayoría de los bugs, y no necesitas un gran conjunto para cazarlos. Para cada prompt de función, elige un pequeño conjunto que refleje comportamientos reales y modos reales de fallo.
Categorías comunes para extraer:
No todas las funciones necesitan todas las categorías. Un buscador se preocupa más por la entrada. Un flujo de pagos se preocupa más por integración y datos.
Elige casos límite que coincidan con el riesgo: coste alto de fallo (dinero, seguridad, privacidad), alta frecuencia, flujos fáciles de romper, errores conocidos o problemas difíciles de detectar después.
Ejemplo: para “el usuario cambia el plan de suscripción”, escenarios que suelen pagar son expiración de sesión en el checkout, doble clic en “Confirmar” y timeout del proveedor de pagos que deja el plan sin cambiar mientras muestra un mensaje claro.
Prompt de ejemplo (lenguaje llano):
"Cuando rompo algo, quiero restaurar mi app a una instantánea previa para que la última versión funcional vuelva a estar en producción."
Abajo hay un conjunto compacto de escenarios. Cada escenario es corto, pero fija un resultado.
S1 [Obligatorio] Restaurar a la instantánea más reciente
Dado que he iniciado sesión y soy propietario de la app
Cuando elijo “Rollback” y confirmo
Entonces la app despliega la instantánea previa y el estado de la app muestra la nueva versión como activa
S2 [Obligatorio] Restaurar a una instantánea específica
Dado que estoy viendo la lista de snapshots de mi app
Cuando selecciono el snapshot “A” y confirmo la restauración
Entonces el snapshot “A” pasa a ser la versión activa y puedo ver cuándo se creó
S3 [Obligatorio] No autorizado (auth)
Dado que he iniciado sesión pero no tengo acceso a esta app
Cuando intento restaurar
Entonces veo un error de acceso y no se inicia ninguna restauración
S4 [Obligatorio] Instantánea no encontrada (validación)
Dado que un ID de snapshot no existe (o fue eliminado)
Cuando intento restaurar a ese ID
Entonces recibo un mensaje claro de “instantánea no encontrada”
S5 [Obligatorio] Doble envío (duplicados)
Dado que hago clic en “Confirmar restauración” dos veces rápidamente
Cuando se envía la segunda petición
Entonces solo se ejecuta una restauración y veo un único resultado
S6 [Obligatorio] Falla del despliegue (fallos)
Dado que la restauración comienza
Cuando el despliegue falla
Entonces la versión activa actual permanece en producción y se muestra el error
S7 [Deseable] Timeout o conexión perdida
Dado que mi conexión cae a mitad de la restauración
Cuando recargo la página
Entonces puedo ver si la restauración sigue en curso o ha finalizado
S8 [Deseable] Ya está en esa instantánea
Dado que el snapshot “A” ya está activo
Cuando intento restaurar a “A”
Entonces se me indica que no hubo cambios y no se inicia un nuevo despliegue
Cada escenario responde a tres preguntas: quién lo realiza, qué hace y qué debe ser verdadero después.
El objetivo no es “probarlo todo”. El objetivo es cubrir los riesgos que perjudicarían a los usuarios, sin crear un montón de escenarios que nadie ejecuta.
Un truco práctico es etiquetar escenarios según cómo esperas usarlos:
Limítate a un escenario por riesgo distinto. Si dos escenarios fallan por la misma razón, probablemente solo necesitas uno. “Formato de email inválido” y “email faltante” son riesgos distintos. Pero “email faltante en Paso 1” y “email faltante en Paso 2” podrían ser el mismo riesgo si la regla es idéntica.
Además evita duplicar pasos de UI en muchos escenarios. Mantén las partes repetidas cortas y céntrate en lo que cambia. Esto importa aún más cuando se construye en una herramienta basada en chat como Koder.ai, porque la UI puede cambiar mientras la regla de negocio permanece.
Finalmente, decide qué comprobar ahora vs después. Algunas comprobaciones son mejores manualmente al principio y luego automatizadas cuando la función se estabiliza:
Un escenario debe protegerte de sorpresas, no describir cómo el equipo planea construir la función.
El fallo más común es convertir un objetivo de usuario en una lista técnica. Si el escenario dice “la API devuelve 200” o “la tabla X tiene la columna Y”, te encierra a un diseño y aun así no demuestra que el usuario obtuvo lo que necesitaba.
Otro problema es combinar múltiples objetivos en un escenario largo. Parece un viaje completo, pero cuando falla, nadie sabe por qué. Un escenario debe responder una sola pregunta.
Cuidado con casos límite que suenan ingeniosos pero no son reales. “Usuario tiene 10 millones de proyectos” o “la red cae cada 2 segundos” rara vez coinciden con producción y son difíciles de reproducir. Elige casos límite que puedas montar en minutos.
También evita resultados vagos como “funciona”, “sin errores” o “se completa correctamente”. Esas palabras ocultan el resultado exacto que debes verificar.
Si estás construyendo algo como la función de “exportar código fuente” de Koder.ai, un escenario débil es: “Cuando el usuario hace clic en exportar, el sistema comprime el repo y devuelve 200.” Prueba una implementación, no la promesa.
Un mejor escenario es: “Dado un proyecto con dos snapshots, cuando el usuario exporta, entonces la descarga contiene el código del snapshot actual y el registro de exportación guarda quién exportó y cuándo.”
No olvides las rutas de “no”: “Dado un usuario sin permiso de exportar, cuando intenta exportar, entonces la opción está oculta o bloqueada y no se crea ningún registro de exportación.” Una línea puede proteger seguridad e integridad de datos.
Antes de tratar un conjunto de escenarios como “listo”, léelo como un usuario exigente y como un administrador de datos. Si no puedes decir qué debe ser verdadero antes de empezar la prueba, o qué significa “éxito”, no está listo.
Un buen conjunto es pequeño pero específico. Debes poder entregarlo a alguien que no escribió la función y obtener los mismos resultados. Usa este repaso rápido para aprobar (o devolver) escenarios:
Si generas escenarios en un creador basado en chat como Koder.ai, exígeles el mismo estándar: nada de “funciona como se espera” vago. Pide salidas observables y cambios guardados, y aprueba solo lo que puedas verificar.
Haz que escribir escenarios sea un paso real en tu proceso, no una tarea de limpieza al final.
Escribe escenarios antes de empezar la implementación, mientras la función sigue siendo barata de cambiar. Esto forcea al equipo a responder las preguntas incómodas temprano: qué significa “éxito”, qué pasa con entradas malas y qué no vas a soportar todavía.
Usa los escenarios como tu definición compartida de “hecho”. Producto posee la intención, QA posee el pensamiento de riesgo y ingeniería la factibilidad. Cuando los tres pueden leer el mismo conjunto y estar de acuerdo, evitas enviar algo que está “terminado” pero no es aceptable.
Un workflow que funciona en la mayoría de los equipos:
Si construyes en Koder.ai (Koder.ai), redactar escenarios primero y luego usar Modo de planificación puede ayudarte a mapear cada escenario a pantallas, reglas de datos y resultados visibles por el usuario antes de generar o editar código.
Para cambios riesgosos, toma una instantánea antes de iterar. Si un caso límite rompe un flujo que funcionaba, restaurar puede evitar que pases un día desenredando efectos secundarios.
Mantén los escenarios junto a la solicitud de función (o dentro del mismo ticket) y trátalos como requisitos versionados. Cuando los prompts evolucionan, el conjunto de escenarios debe evolucionar con ellos, o tu definición de “hecho” se desviará silenciosamente.
Empieza con una frase que indique el objetivo del usuario y la línea de llegada.
Luego descompone el prompt en:
A partir de ahí, escribe 1–2 rutas felices más 4–8 casos límite que reflejen riesgos reales (permisos, duplicados, timeouts, datos faltantes).
Porque los prompts ocultan suposiciones. Un prompt puede decir “guardar”, pero no definir si eso significa borrador vs publicado, qué sucede en caso de fallo o quién está autorizado.
Los escenarios te obligan a nombrar las reglas desde el principio, antes de enviar bugs como envíos duplicados, desajustes de permiso o resultados inconsistentes.
Usa Given–When–Then cuando la función tiene estado e interacción del usuario.
Usa una tabla simple de entrada/salida cuando tengas muchas comprobaciones similares.
Elige un formato durante un mes y estandarízalo (mismo tiempo verbal, mismo nivel de detalle). El mejor formato es el que el equipo realmente mantendrá.
Un buen escenario es:
Está “listo” cuando cualquiera lo ejecuta y acuerda el resultado sin discusión.
Enfócate en comportamiento observable:
Evita detalles de implementación como tablas de base de datos, códigos de respuesta API, jobs en segundo plano o frameworks. Esos detalles cambian y no prueban que el usuario obtuvo el resultado deseado.
Escribe la ruta más aburrida y normal donde todo sale bien:
Luego verifica cuatro cosas: pantalla/estado correcto, mensaje de éxito claro, datos guardados y que el usuario pueda continuar con la siguiente acción lógica.
Elige casos límite según riesgo y frecuencia:
Apunta a , no a todas las variaciones posibles.
Manténlo seguro y claro:
Un escenario de fallo debe demostrar que el sistema no corrompe datos ni engaña al usuario.
Trata la salida de Koder.ai como cualquier otra app: prueba lo que experimenta el usuario, no cómo se generó el código.
Enfoque práctico:
Guárdalos donde ya ocurra el trabajo y mantén una única fuente de verdad:
Si usas Koder.ai, conserva los escenarios en Modo de planificación para que queden ligados al historial de la build. Lo importante: exige escenarios antes de considerar que empezó el desarrollo.