Una prueba End-to-End no consiste solamente en ejecutar pasos. Su valor aparece cuando compara lo que ocurrió con lo que debería ocurrir. Esa comparación se realiza mediante verificaciones, también llamadas aserciones.
Si una prueba recorre un flujo completo pero no comprueba resultados importantes, puede pasar aunque el sistema no haya cumplido el objetivo real del usuario. Por eso, definir qué verificar es tan importante como definir qué acciones ejecutar.
En este tema veremos qué conviene comprobar al final del flujo, qué puede verificarse durante el recorrido y qué errores evitar.
Una verificación es una comprobación concreta de que el sistema se encuentra en el estado esperado. Puede observar la interfaz, un dato, un mensaje, un estado de negocio o una consecuencia del flujo.
Por ejemplo, después de una compra no alcanza con haber hecho clic en "Confirmar". Debemos comprobar que la compra fue aceptada, que existe una orden y que el usuario puede verla.
La verificación final comprueba que el objetivo principal del escenario se cumplió. Es la comprobación más importante de una prueba E2E.
Ejemplos:
La verificación final debe estar conectada con el objetivo del usuario o del negocio.
Las verificaciones intermedias comprueban que el flujo avanza correctamente antes de llegar al final. Son útiles cuando el proceso tiene varios pasos o cuando un error temprano puede confundir el diagnóstico.
Ejemplos de verificaciones intermedias:
No conviene verificar todo en cada paso. Las verificaciones intermedias deben ser pocas y relevantes.
Una pantalla puede mostrar un mensaje de éxito aunque el estado real del sistema no se haya actualizado correctamente. Por eso, en flujos críticos conviene verificar consecuencias más fuertes.
| Verificación débil | Verificación más fuerte |
|---|---|
| Aparece "Compra realizada". | La orden aparece en el historial y el curso queda habilitado. |
| Aparece "Solicitud enviada". | La solicitud figura con estado pendiente para el usuario correspondiente. |
| Aparece "Turno confirmado". | El turno aparece en la agenda y ya no está disponible para otro paciente. |
| Aparece "Cambios guardados". | Al volver a abrir el perfil, los datos actualizados se conservan. |
Una prueba E2E debe apoyarse en resultados observables. Esto no significa que todo deba verse en la pantalla, pero sí que debe existir una evidencia comprobable.
Resultados observables pueden ser:
La evidencia debe ser clara y relacionada con el objetivo del escenario.
Una verificación positiva comprueba que algo esperado ocurrió. Es la forma más habitual de validar un escenario feliz o alternativo.
Ejemplos:
Estas verificaciones confirman que el sistema produjo el resultado correcto.
Una verificación negativa comprueba que algo incorrecto no ocurrió. Son importantes en escenarios de error, seguridad o permisos.
Ejemplos:
En muchos errores críticos, verificar lo que no debe pasar es tan importante como verificar el mensaje mostrado.
No basta con comprobar que algo existe. También debemos comprobar que contiene los datos correctos.
Por ejemplo, si una compra aparece en el historial, conviene revisar datos como:
Esto evita falsos positivos donde la prueba encuentra una entidad, pero no necesariamente la que generó el escenario.
Muchas pruebas terminan verificando que un dato aparece en una lista o tabla. En esos casos, conviene identificar el dato por una clave única y luego comprobar su contenido.
Ejemplo:
Evitar verificaciones como "hay al menos una orden" o "aparece una fila", porque pueden pasar con datos de otra prueba.
Los estados son fundamentales en muchos sistemas. Una solicitud puede estar pendiente, aprobada o rechazada. Una orden puede estar creada, pagada o cancelada. Un turno puede estar disponible, reservado o finalizado.
Verificar estados permite confirmar que el flujo avanzó correctamente.
| Flujo | Estado inicial | Estado esperado |
|---|---|---|
| Enviar solicitud | Borrador | Pendiente de revisión |
| Aprobar solicitud | Pendiente | Aprobada |
| Reservar turno | Disponible | Reservado |
| Cancelar compra | Pagada | Cancelada o reembolsada |
En escenarios de error, una buena verificación debe comprobar tres cosas:
Por ejemplo, si un pago es rechazado, la prueba puede verificar que aparece el mensaje de rechazo, que el usuario permanece en un estado recuperable y que el curso no queda habilitado.
Agregar muchas verificaciones no siempre mejora la prueba. Puede hacerla más frágil y difícil de mantener. Una prueba E2E debe verificar lo suficiente para confirmar el objetivo, sin revisar detalles secundarios innecesarios.
Señales de exceso:
Las verificaciones deben proteger comportamiento importante, no inmovilizar toda la pantalla.
El problema contrario es verificar muy poco. Una prueba débil puede pasar aunque el sistema esté mal.
Ejemplos de verificaciones débiles:
Estas comprobaciones pueden ser útiles como parte del flujo, pero no deberían ser la única evidencia de éxito.
Un escenario E2E de compra de curso podría tener estas verificaciones:
| Momento | Verificación | Motivo |
|---|---|---|
| Después de iniciar sesión | El alumno ve su panel o menú de cuenta. | Confirma que opera como el usuario correcto. |
| Después de agregar al carrito | El curso aparece en el resumen de compra. | Confirma que el flujo avanza con el dato correcto. |
| Después del pago | Se muestra confirmación con número de operación. | Aporta evidencia inmediata de la acción. |
| Al final | El curso aparece disponible en "Mis cursos". | Confirma el objetivo principal del usuario. |
Al definir verificaciones E2E, conviene evitar estos errores:
Para revisar las verificaciones de un escenario E2E, podemos preguntar:
Las verificaciones son lo que transforma una secuencia de acciones en una verdadera prueba. Sin ellas, no sabemos si el sistema cumplió el objetivo del usuario ni si quedó en un estado correcto.
Una buena prueba E2E combina una verificación final fuerte con algunas verificaciones intermedias útiles. Debe comprobar consecuencias importantes, evitar detalles frágiles y reducir falsos positivos.
En el próximo tema veremos cómo manejar dependencias externas, correos, pagos y servicios de terceros.