Cuando una prueba End-to-End falla, el equipo necesita entender qué ocurrió. No alcanza con saber que el escenario "falló"; necesitamos saber en qué paso, con qué datos, qué veía el usuario, qué respondió el sistema y qué información quedó registrada.
Las evidencias de ejecución son los elementos que ayudan a reconstruir una corrida de prueba: capturas de pantalla, videos, trazas, registros, mensajes de error, datos usados, tiempos de respuesta y estado del ambiente.
En este tema veremos qué evidencias conviene guardar, cómo usarlas para diagnosticar fallas y qué errores evitar para que la información sea útil en lugar de convertirse en ruido.
Una evidencia de ejecución es cualquier información generada durante una prueba que permite entender qué pasó. Puede ser visual, técnica o funcional.
Las evidencias son especialmente importantes en pruebas E2E porque estas pruebas atraviesan muchas partes del sistema. Una falla puede estar en la interfaz, en el backend, en los datos, en un servicio externo, en permisos, en sincronización o en el propio escenario de prueba.
Sin evidencias, una falla puede ser difícil de reproducir. El equipo puede perder tiempo intentando adivinar si el error fue real, si el ambiente estaba mal configurado o si la prueba quedó desactualizada.
Las evidencias ayudan a:
Una suite E2E puede generar distintos tipos de evidencias. No todas son necesarias para todos los escenarios, pero conviene conocer sus usos.
| Evidencia | Qué muestra | Cuándo ayuda |
|---|---|---|
| Captura de pantalla | Estado visual de una página en un momento concreto. | Errores de interfaz, mensajes, pantallas inesperadas. |
| Video | Secuencia completa o parcial de la ejecución. | Problemas de navegación, timing, elementos que aparecen y desaparecen. |
| Traza | Pasos, acciones, eventos, red y estado del navegador. | Diagnóstico técnico detallado de fallas complejas. |
| Registros o logs | Mensajes del sistema, backend, navegador o herramienta. | Errores internos, respuestas de APIs, excepciones. |
| Datos de prueba | Usuario, entidad, identificador o valores usados. | Reproducir el caso y buscar información en el sistema. |
Las capturas de pantalla son una de las evidencias más simples y útiles. Permiten ver qué mostraba la aplicación en un momento determinado, especialmente cuando una prueba falla al buscar un elemento, verificar un mensaje o completar una acción.
Una captura puede mostrar:
Lo habitual es tomar capturas cuando una prueba falla. También puede ser útil capturar puntos clave de un flujo crítico, pero hacerlo en exceso puede generar demasiados archivos.
Una práctica muy común es guardar automáticamente una captura cuando la prueba falla. Esto evita depender de que alguien recuerde tomar evidencia manualmente.
Para que la captura sea útil, conviene nombrarla de forma clara. Por ejemplo, puede incluir fecha, ambiente, nombre del escenario y navegador. Si el nombre del archivo es genérico, luego será difícil relacionarlo con la ejecución correcta.
El video permite revisar la secuencia de acciones de la prueba. Es especialmente útil cuando la falla depende del orden, de una transición, de una espera, de un modal que aparece brevemente o de un elemento que se cubre por otro.
Los videos ayudan a ver:
Como los videos pueden ocupar mucho espacio, muchas suites los guardan solo cuando hay fallas o en ejecuciones importantes de integración continua.
Una traza es una evidencia más completa que una captura o un video. Puede incluir acciones realizadas, selectores usados, eventos del navegador, solicitudes de red, respuestas, consola, tiempos y estado de la página.
Las trazas son muy valiosas para investigar fallas complejas, porque permiten reconstruir la ejecución con más detalle técnico.
Una traza puede responder preguntas como:
Los registros, también llamados logs, muestran mensajes producidos por la aplicación, el servidor, el navegador, las APIs o la herramienta de prueba. Son fundamentales cuando el problema no se ve directamente en pantalla.
| Tipo de registro | Qué puede aportar |
|---|---|
| Logs del navegador | Errores JavaScript, advertencias, problemas de recursos o consola. |
| Logs del backend | Excepciones, validaciones fallidas, operaciones internas. |
| Logs de APIs | Solicitudes, respuestas, códigos de estado y tiempos. |
| Logs de la herramienta E2E | Pasos ejecutados, selectores, aserciones y errores de prueba. |
| Logs de servicios externos | Eventos de pago, correos enviados, webhooks recibidos. |
Una falla puede ser imposible de investigar si no sabemos qué datos usó la prueba. Por eso, además de capturas y logs, conviene registrar identificadores relevantes.
Datos útiles:
Estos datos permiten buscar la entidad en la base de datos, revisar logs del backend o reproducir el caso manualmente.
Cuando las pruebas E2E se ejecutan en integración continua, las evidencias deben quedar disponibles para el equipo. No sirve que una captura o un log quede guardado solamente en una máquina temporal que se elimina al terminar la ejecución.
En un pipeline conviene conservar:
La evidencia debe estar asociada al resultado de la ejecución para que sea fácil encontrarla desde el reporte.
Un reporte de prueba organiza la información de la ejecución. Puede mostrar qué escenarios pasaron, cuáles fallaron, cuánto tardaron y qué evidencia quedó asociada a cada uno.
Un buen reporte debería permitir ver:
El reporte no debe ser solo una lista de archivos. Debe ayudar a priorizar y diagnosticar.
Guardar todo puede parecer útil, pero puede traer problemas: archivos enormes, costos de almacenamiento, dificultad para encontrar lo importante y exposición innecesaria de datos sensibles.
Una estrategia razonable puede ser:
Las evidencias pueden contener información sensible: correos, nombres, documentos, tokens, números de operación, datos personales, direcciones o fragmentos de respuestas de APIs.
Antes de guardar y compartir evidencias, conviene revisar:
En ambientes de prueba se deben usar datos ficticios siempre que sea posible. Además, los secretos no deberían aparecer en logs ni reportes.
Una evidencia mal organizada pierde valor. Si los archivos se llaman screenshot.png, video.webm o log.txt sin contexto, será difícil relacionarlos con la prueba fallida.
Conviene incluir información como:
La organización debe permitir encontrar la evidencia desde el reporte y también navegar los archivos cuando sea necesario.
Las fallas intermitentes son especialmente difíciles: a veces ocurren y a veces no. En estos casos, las evidencias son clave para detectar patrones.
Conviene comparar:
Una captura aislada puede no alcanzar. Para fallas intermitentes, las trazas y logs suelen ser más importantes.
En un escenario E2E de compra de curso, podríamos guardar estas evidencias:
| Momento | Evidencia | Utilidad |
|---|---|---|
| Inicio de la prueba | Usuario, curso y ambiente usados. | Permite reproducir y buscar datos. |
| Después del pago | Número de orden e identificador de operación. | Ayuda a revisar backend o proveedor de pago. |
| Al verificar "Mis cursos" | Captura si el curso no aparece. | Muestra el estado visible para el alumno. |
| Si falla el escenario | Video, traza y logs del error. | Permite reconstruir pasos y respuestas. |
| Final de la ejecución | Reporte del escenario. | Resume resultado y enlaces a evidencias. |
Las evidencias pueden generarse manualmente o de forma automática. En pruebas E2E automatizadas, lo ideal es que la evidencia importante se capture sin intervención humana.
| Tipo | Ventaja | Riesgo |
|---|---|---|
| Manual | Permite agregar contexto humano y observaciones. | Puede olvidarse o ser inconsistente. |
| Automática | Es repetible y se genera en cada ejecución relevante. | Puede producir demasiado volumen si no se configura bien. |
En general, conviene automatizar la evidencia básica y dejar las notas manuales para análisis exploratorio o defectos que requieren explicación adicional.
Al trabajar con evidencias de ejecución, conviene evitar estos errores:
Para revisar la estrategia de evidencias de una suite E2E, podemos preguntar:
Las evidencias de ejecución convierten una falla E2E en información útil. Permiten reconstruir el flujo, revisar el estado de la aplicación, identificar datos usados y distinguir problemas reales de errores de ambiente o de la propia prueba.
Una estrategia equilibrada guarda suficiente información para diagnosticar sin llenar el proceso de ruido. Capturas al fallar, reportes claros, datos de prueba, logs relevantes y trazas para casos complejos forman una base sólida para mantener una suite confiable.
En el próximo tema veremos análisis de fallas: distinguir defectos reales, problemas de ambiente y errores de prueba.