Al diseñar pruebas End-to-End, no alcanza con elegir un flujo crítico. También debemos decidir qué variante de ese flujo vamos a probar. Un mismo proceso puede tener un camino exitoso, variantes válidas y situaciones de error que deben manejarse correctamente.
Por eso se suele hablar de escenarios felices, escenarios alternativos y escenarios de error. Esta clasificación ayuda a ordenar la cobertura y a evitar que la suite E2E crezca sin criterio.
En este tema veremos qué significa cada tipo de escenario y cómo seleccionarlos para que aporten valor real.
Un escenario feliz, también llamado camino feliz, representa el recorrido principal donde todo ocurre como se espera. Los datos son válidos, los servicios responden correctamente, el usuario tiene permisos y el resultado final se alcanza sin obstáculos.
Ejemplo en una compra:
El escenario feliz suele ser el primer candidato para una prueba E2E porque valida el flujo principal de valor.
Un escenario alternativo representa una variante válida del flujo. No es un error, sino otra forma aceptada de completar el objetivo.
Ejemplos de escenarios alternativos:
Una variante alternativa merece prueba E2E cuando cambia una regla importante, atraviesa componentes diferentes o cubre un riesgo que el camino feliz no cubre.
Un escenario de error verifica cómo responde el sistema cuando algo impide completar el flujo. El objetivo no es que la operación tenga éxito, sino que el sistema maneje la situación de manera correcta, segura y comprensible.
Ejemplos:
Un buen escenario de error no solo comprueba que aparece un mensaje. También verifica que el sistema no deja datos inconsistentes ni permite acciones indebidas.
La siguiente tabla resume las diferencias:
| Tipo | Qué representa | Resultado esperado | Ejemplo |
|---|---|---|---|
| Feliz | Camino principal exitoso. | El objetivo se completa. | Compra aprobada y orden creada. |
| Alternativo | Variante válida del proceso. | El objetivo se completa por otro camino. | Compra con cupón válido. |
| De error | Situación inválida o bloqueante. | El sistema rechaza, informa o evita una acción incorrecta. | Pago rechazado sin crear compra. |
Cuando se diseña una suite E2E desde cero, conviene comenzar por el escenario feliz del flujo crítico principal. Si ese camino falla, probablemente el sistema no esté listo para los usuarios.
El escenario feliz ayuda a responder preguntas básicas:
Una vez cubierto ese camino, se analizan variantes y errores según riesgo.
No toda variante merece una prueba E2E. Una alternativa es valiosa cuando modifica de manera importante el flujo, los datos, las reglas o las dependencias.
Preguntas útiles para decidir:
Si la variante solo cambia un dato sin modificar el riesgo, quizá no sea necesaria como E2E.
Los escenarios de error son necesarios, pero también deben seleccionarse con criterio. Muchos errores pequeños pueden validarse mejor con pruebas unitarias, de integración o de interfaz.
Un error suele ser buen candidato para E2E cuando:
Por ejemplo, en una compra, el rechazo de pago puede merecer E2E porque debe evitar la creación de una compra válida y debe informar correctamente al usuario.
Para una plataforma de cursos, podríamos diseñar estos escenarios:
| Tipo | Escenario | Validación principal |
|---|---|---|
| Feliz | Alumno compra un curso con pago aprobado. | El curso aparece disponible en "Mis cursos". |
| Alternativo | Alumno compra usando un cupón válido. | Se aplica el descuento y el curso queda habilitado. |
| De error | Alumno intenta comprar, pero el pago es rechazado. | Se informa el rechazo y el curso no queda habilitado. |
Estos tres escenarios cubren comportamientos diferentes. No son repeticiones del mismo caso con datos apenas distintos.
En una aplicación de turnos, el diseño podría ser:
| Tipo | Escenario | Resultado esperado |
|---|---|---|
| Feliz | Paciente reserva un turno disponible. | El turno queda confirmado y visible en su agenda. |
| Alternativo | Paciente reserva un turno para un familiar registrado. | El turno queda asociado al familiar correcto. |
| De error | Paciente intenta reservar un turno que acaba de ser ocupado. | El sistema informa que ya no está disponible y no duplica la reserva. |
Un riesgo frecuente es crear demasiados escenarios E2E. Si combinamos todos los usuarios, permisos, datos, navegadores, estados y errores, la cantidad puede crecer de manera inmanejable.
Para evitarlo:
Cada tipo de escenario necesita verificaciones distintas:
| Tipo | Qué conviene verificar |
|---|---|
| Feliz | Que el resultado se completa, se persiste y es visible para el usuario. |
| Alternativo | Que la variante produce el resultado correcto sin romper el flujo principal. |
| De error | Que el sistema bloquea o informa correctamente y no genera efectos indebidos. |
En los escenarios de error, muchas veces es tan importante verificar lo que no debe ocurrir como lo que sí debe ocurrir.
Un escenario E2E debe ser entendible para personas técnicas y no técnicas. Conviene escribirlo con foco en el comportamiento, no en detalles frágiles de implementación.
Recomendaciones:
Al diseñar escenarios felices, alternativos y de error, es común cometer estos errores:
Diseñar escenarios E2E implica elegir con cuidado qué caminos del flujo vamos a validar. Los escenarios felices dan confianza sobre el uso principal. Los alternativos cubren variantes relevantes. Los de error comprueban que el sistema responda bien cuando algo no permite completar el proceso.
La clave está en equilibrar cobertura y mantenimiento. Una suite E2E útil no es la que contiene más casos, sino la que protege mejor los flujos y riesgos que realmente importan.
En el próximo tema veremos cómo preparar el ambiente de pruebas End-to-End para que estos escenarios puedan ejecutarse de forma confiable.