El alcance de una prueba End-to-End indica qué partes del sistema participan en el flujo que queremos validar. Una prueba E2E puede atravesar la interfaz de usuario, el backend, la base de datos, servicios de autenticación, proveedores de pago, sistemas de correo y otros componentes.
Definir bien el alcance es importante porque una prueba demasiado pequeña puede no dar confianza sobre el flujo completo, mientras que una prueba demasiado grande puede volverse lenta, frágil y difícil de diagnosticar.
En este tema veremos cómo pensar el alcance de una prueba E2E y qué rol cumple cada capa dentro del recorrido.
En una prueba E2E, el alcance responde preguntas como estas:
El frontend es la parte visible con la que interactúa el usuario: pantallas, formularios, botones, mensajes, menús, tablas, enlaces y navegación. Muchas pruebas E2E comienzan en esta capa porque intentan reproducir el uso real de la aplicación.
Cuando una prueba E2E incluye frontend, puede validar aspectos como:
El frontend no es solo una decoración. En muchos sistemas contiene validaciones, estados, permisos visibles y experiencia de uso que forman parte del flujo.
El backend procesa las reglas de negocio, valida datos, coordina operaciones y se comunica con bases de datos o servicios externos. Aunque el usuario no lo vea directamente, es una parte central de muchos flujos E2E.
Una prueba E2E puede atravesar el backend cuando, por ejemplo:
Cuando el backend participa, la prueba puede detectar problemas que no se ven solo mirando la pantalla: reglas mal aplicadas, errores de permisos, estados incorrectos o datos incompletos.
La base de datos guarda información necesaria para que el flujo exista y para que el resultado se mantenga. En una prueba E2E puede intervenir de dos maneras: como estado inicial y como destino de los cambios producidos por la prueba.
Por ejemplo, antes de ejecutar una prueba, puede ser necesario que exista un usuario, un producto publicado o una agenda con turnos disponibles. Después de ejecutar el flujo, podemos esperar que se haya creado una compra, una reserva o una solicitud.
| Uso de la base de datos | Ejemplo |
|---|---|
| Preparar estado inicial | Crear un producto disponible para poder comprarlo durante la prueba. |
| Persistir resultado | Guardar la orden generada cuando el usuario confirma la compra. |
| Verificar consecuencia | Comprobar que la reserva aparece en la agenda del usuario. |
Conviene ser cuidadoso: verificar directamente la base de datos puede ser útil, pero la evidencia principal de una prueba E2E debería estar conectada con el resultado observable del flujo.
Muchos sistemas dependen de servicios externos: pagos, correos, mapas, mensajería, verificación de identidad, almacenamiento de archivos, facturación o proveedores de autenticación.
En una prueba E2E debemos decidir si esos servicios se usarán realmente, si se reemplazarán por un ambiente de prueba o si se simularán. La decisión depende del riesgo y del costo.
| Enfoque | Ventaja | Riesgo |
|---|---|---|
| Servicio real | Mayor realismo. | Puede ser costoso, lento o afectar datos reales. |
| Ambiente de prueba del proveedor | Buen equilibrio entre realismo y seguridad. | Puede comportarse distinto al ambiente real. |
| Simulación o reemplazo controlado | Más estabilidad y control. | Menos realismo sobre la integración completa. |
La autenticación y los permisos suelen formar parte del alcance de muchas pruebas E2E. No alcanza con saber que una acción funciona; también importa saber si la puede realizar el usuario correcto.
Algunos ejemplos:
Cuando el flujo depende de roles o permisos, el alcance de la prueba debe incluir el estado del usuario y la verificación del acceso correcto.
Imaginemos una prueba E2E para reservar un turno médico. El flujo podría tener este alcance:
| Parte del sistema | Participación en el flujo |
|---|---|
| Frontend | El paciente busca un profesional, selecciona fecha y confirma el turno. |
| Backend | Valida disponibilidad, permisos y reglas de reserva. |
| Base de datos | Guarda el turno reservado y actualiza la disponibilidad. |
| Servicio de correo | Envía una confirmación al paciente. |
| Panel del usuario | Muestra el turno reservado en la agenda del paciente. |
Esta prueba entrega confianza porque valida el recorrido completo y las consecuencias principales del flujo.
Una prueba puede llamarse E2E pero tener un alcance demasiado reducido. Por ejemplo, si solo abre la pantalla de turnos y comprueba que el botón "Reservar" existe, no está validando el flujo completo.
Señales de alcance demasiado pequeño:
En estos casos puede tratarse de una prueba de interfaz o una verificación superficial, pero no de una prueba E2E completa.
También puede ocurrir lo contrario: una prueba intenta cubrir demasiadas cosas en un solo escenario. Esto vuelve difícil entender por qué falló y aumenta el costo de mantenimiento.
Señales de alcance demasiado grande:
Una decisión importante es si las dependencias externas deben participar realmente en la prueba. No siempre existe una única respuesta correcta.
Conviene incluir una dependencia real cuando:
Conviene controlar o simular una dependencia cuando:
Cuanto mayor es el alcance de una prueba E2E, más información puede aportar, pero también más difícil puede ser diagnosticar una falla. Si una prueba que recorre diez componentes falla, el problema puede estar en cualquiera de ellos.
Por eso conviene acompañar las pruebas E2E con evidencias útiles:
Una prueba E2E bien delimitada facilita entender si la falla está en el producto, en el ambiente, en los datos o en la prueba misma.
Antes de escribir o ejecutar una prueba E2E, podemos responder estas preguntas:
Estas preguntas evitan que la prueba crezca sin control o que quede demasiado superficial.
Definir el alcance de una prueba End-to-End es una decisión central. Una prueba E2E debe atravesar las partes necesarias para validar un flujo real, pero sin transformarse en una prueba enorme que intente cubrir todo el sistema.
El equilibrio está en incluir lo que aporta confianza sobre el objetivo del usuario y controlar lo que introduce inestabilidad innecesaria. Así la prueba resulta más clara, más útil y más fácil de mantener.
En el próximo tema veremos cómo identificar flujos críticos del negocio y cómo seleccionar los escenarios E2E que realmente vale la pena probar.