Las historias de usuario y los criterios de aceptación son una fuente muy útil para diseñar escenarios de pruebas End-to-End. Ayudan a entender qué necesita lograr el usuario, qué condiciones deben cumplirse y cómo sabremos si la funcionalidad está lista.
Una prueba E2E no debería nacer solo de mirar pantallas o botones. Debe conectarse con una necesidad real. Por eso, antes de escribir un escenario, conviene revisar qué historia se quiere validar y cuáles son sus criterios de aceptación.
En este tema veremos cómo pasar de una historia de usuario a escenarios E2E claros, verificables y orientados al valor.
Una historia de usuario describe una necesidad desde el punto de vista de quien usará el sistema. Una forma habitual de escribirla es:
Por ejemplo:
La historia no detalla toda la implementación. Su valor está en expresar quién necesita algo, qué necesita y para qué.
Los criterios de aceptación describen condiciones que deben cumplirse para considerar que una historia está correctamente implementada. Ayudan a evitar ambigüedades y sirven como base para diseñar pruebas.
Para la historia de compra de un curso, algunos criterios podrían ser:
Estos criterios orientan qué comportamientos conviene verificar.
La historia explica la necesidad. Los criterios de aceptación explican las condiciones de éxito. El escenario E2E convierte esa información en una prueba concreta.
| Elemento | Pregunta que responde | Ejemplo |
|---|---|---|
| Historia de usuario | ¿Qué quiere lograr el usuario? | Comprar un curso para acceder al contenido. |
| Criterio de aceptación | ¿Qué condición debe cumplirse? | El curso comprado aparece en "Mis cursos". |
| Escenario E2E | ¿Cómo verificamos el flujo completo? | Alumno inicia sesión, compra el curso y verifica que está disponible. |
No todos los criterios de aceptación se transforman automáticamente en una prueba E2E separada. Algunos criterios se validan mejor dentro del mismo escenario y otros se prueban mejor en niveles más pequeños.
Una forma práctica de convertir criterios en escenarios es agruparlos alrededor del objetivo del usuario:
El resultado debe ser un escenario que pueda ejecutarse y evaluarse con claridad.
Un formato muy usado para expresar escenarios es Dado, Cuando, Entonces. También se conoce por sus palabras en inglés: Given, When, Then.
| Parte | Función | Ejemplo |
|---|---|---|
| Dado | Describe el estado inicial. | Dado que existe un alumno registrado y un curso publicado. |
| Cuando | Describe la acción principal. | Cuando el alumno compra el curso con un pago aprobado. |
| Entonces | Describe el resultado esperado. | Entonces el curso aparece disponible en "Mis cursos". |
Este formato obliga a pensar en condiciones iniciales, acción y resultado, tres elementos esenciales para una prueba E2E.
Partamos de esta historia:
Un escenario E2E principal podría ser:
Este escenario une varios criterios de aceptación dentro de un flujo completo y verificable.
Una misma historia puede generar más de un escenario. Conviene clasificarlos para evitar confusión.
| Tipo | Qué representa | Ejemplo |
|---|---|---|
| Principal | El camino esperado y exitoso. | El alumno compra un curso con pago aprobado. |
| Alternativo | Una variante válida del flujo. | El alumno compra usando un cupón válido. |
| Negativo | Una situación que debe ser rechazada o manejada correctamente. | El pago es rechazado y el curso no se habilita. |
No todos los escenarios negativos deben ser E2E. Deben elegirse los que tengan impacto real en el flujo completo.
A veces los criterios de aceptación son demasiado vagos. Por ejemplo:
Ese criterio no ayuda a diseñar una prueba porque no define qué significa "correctamente". Un criterio más útil sería:
Los criterios claros permiten pruebas claras. Los criterios ambiguos producen escenarios incompletos o discusiones durante la ejecución.
También puede ocurrir lo contrario: criterios escritos con demasiado detalle técnico interno. Por ejemplo:
Ese criterio puede ser útil para una prueba de API o integración, pero no describe por sí solo una experiencia End-to-End. Para una prueba E2E, conviene expresarlo desde el resultado del usuario:
La información técnica puede ayudar al diagnóstico, pero el escenario E2E debe mantener el foco en el flujo observable.
La trazabilidad permite relacionar una prueba con la historia, requisito o criterio que valida. En proyectos grandes, esto ayuda a saber por qué existe una prueba y qué riesgo cubre.
Una trazabilidad simple puede registrar:
Esto facilita revisar la suite cuando cambian las historias o se modifica una funcionalidad.
Los escenarios E2E mejoran cuando participan distintas miradas. El tester o QA puede diseñar la prueba, pero necesita entender la intención del negocio y los riesgos técnicos.
En la definición de escenarios pueden participar:
La colaboración evita que los escenarios sean técnicamente correctos pero poco relevantes, o relevantes pero imposibles de ejecutar con estabilidad.
Al relacionar historias, criterios y escenarios E2E, conviene evitar estos errores:
Una plantilla simple ayuda a escribir escenarios consistentes:
| Historia relacionada | Identificador o nombre de la historia. |
|---|---|
| Objetivo del escenario | Qué flujo real queremos validar. |
| Dado | Estado inicial, usuario, datos y condiciones previas. |
| Cuando | Acción principal o recorrido del usuario. |
| Entonces | Resultado esperado y evidencia observable. |
| Criterios cubiertos | Lista breve de criterios de aceptación validados. |
Las historias de usuario y los criterios de aceptación son una base natural para diseñar pruebas End-to-End. Permiten conectar la prueba con una necesidad real y evitar escenarios desconectados del valor del producto.
Un buen escenario E2E no es una copia mecánica de un criterio ni una lista de clics. Es una validación concreta de que un usuario puede cumplir un objetivo importante bajo condiciones definidas.
En el próximo tema veremos cómo diseñar escenarios felices, alternativos y de error dentro de una estrategia E2E.