Cómo escribir historias de usuario comprobables.
Una historia de usuario debe expresar una capacidad y por qué importa. Evita disfrazar una tarea técnica de beneficio para el usuario.
Adapta el flujo de trabajo a tu tarea.
Nombra al usuario, la capacidad y la razón de su importancia; añade condiciones de aceptación que hagan observable el resultado. Mantén la historia suficientemente enfocada para revisar su finalización en un escenario concreto.
- Qué aportas
- Problema del usuario y capacidad deseada.
- Qué obtienes
- Historias centradas en el usuario con límites de alcance.
Mira la entrada y el resultado.
Entrada y salida ilustrativas · ejemplo didáctico, no una ejecución de WebAct en directo
Ejemplo campo
Catalog manager needs to identify changed supplier prices.
Ejemplo completo
As a catalog manager, I want to review changed prices so I can approve updates before importing them.
Carga esta entrada en el prompt y cópialo en WebAct para probar la tarea. Tu resultado puede diferir del ejemplo.
Decisiones y solución de problemas.
¿Debe forzarse un trabajo de mantenimiento técnico a una frase de historia de usuario?
Explica su propósito y restricciones reales. Una tarea técnica puede documentarse con honestidad sin inventar una acción del usuario para ajustarla al formato.
¿Por qué la historia parece terminada pero sigue siendo difícil de probar?
Añade el comportamiento esperado y límites relevantes. El beneficio explica por qué importa; las condiciones de aceptación explican qué significa terminar.
Pruébalo con tu propia fuente.
Sustituye el ejemplo por tu material en el prompt. Conserva los requisitos que necesites y copia la tarea en WebAct.
Personalizar y copiar la tarea ↑