Cuando una prueba End-to-End falla, no siempre significa que existe un defecto en la aplicación. La falla puede deberse a un error real del producto, a un ambiente mal preparado, a datos de prueba incorrectos, a un servicio externo caído, a un selector frágil o a una espera mal diseñada.
El análisis de fallas busca entender la causa antes de tomar una decisión. Si clasificamos mal una falla, podemos reportar defectos inexistentes, ignorar problemas importantes o mantener una suite inestable que pierde credibilidad.
En este tema veremos cómo investigar una falla E2E, qué señales observar y cómo distinguir defectos reales, problemas de ambiente y errores de la propia prueba.
Analizar una falla significa revisar la evidencia disponible para responder una pregunta concreta: ¿por qué la prueba no obtuvo el resultado esperado?
El objetivo no es culpar a una parte del sistema, sino identificar la causa más probable y definir la acción siguiente: corregir la aplicación, arreglar la prueba, estabilizar el ambiente, limpiar datos o investigar más.
Una forma práctica de comenzar es clasificar la falla en una categoría inicial. Esta clasificación puede cambiar durante la investigación, pero ayuda a ordenar el análisis.
| Categoría | Descripción | Ejemplo |
|---|---|---|
| Defecto real | La aplicación no cumple el comportamiento esperado. | Una compra aprobada no habilita el curso. |
| Problema de ambiente | La prueba falla por configuración, disponibilidad o estado del entorno. | El backend de pruebas está caído. |
| Error de prueba | El escenario está mal escrito, desactualizado o verifica algo incorrecto. | La prueba busca un selector que ya no corresponde. |
| Problema de datos | Las condiciones iniciales no son válidas o los datos están contaminados. | El usuario de prueba ya tiene el curso comprado. |
| Dependencia externa | Un proveedor o servicio fuera del control directo falla o responde distinto. | El sandbox de pagos no responde. |
Antes de modificar código o reejecutar pruebas sin criterio, conviene hacerse algunas preguntas básicas.
Estas preguntas ayudan a evitar conclusiones apresuradas.
El tema anterior mostró la importancia de capturas, videos, trazas y registros. En el análisis de fallas, esas evidencias se combinan para reconstruir lo ocurrido.
| Evidencia | Qué revisar |
|---|---|
| Captura de pantalla | Si la aplicación estaba en la pantalla correcta y mostraba datos esperados. |
| Video | Si el flujo avanzó en el orden correcto y si hubo cambios visuales inesperados. |
| Traza | Qué acción falló, qué selector se usó, qué solicitudes ocurrieron y cuánto tardaron. |
| Logs | Errores internos, excepciones, códigos de respuesta o fallas de servicios. |
| Datos de prueba | Si el usuario, entidad o estado inicial correspondían al escenario. |
Un defecto real ocurre cuando la aplicación no cumple el comportamiento esperado para un flujo válido. La prueba hizo lo que debía hacer, el ambiente y los datos eran correctos, pero el sistema respondió mal.
Señales de defecto real:
Cuando hay un defecto real, la acción correcta es reportarlo con evidencia clara y pasos de reproducción.
Un problema de ambiente ocurre cuando la aplicación o sus dependencias no están en condiciones de ejecutar la prueba correctamente. No necesariamente hay un defecto funcional; el entorno puede estar caído, incompleto, desactualizado o mal configurado.
Ejemplos:
Un error de prueba ocurre cuando el escenario no representa correctamente el comportamiento esperado o está implementado de manera frágil. En ese caso, la aplicación puede estar funcionando bien, pero la prueba falla igual.
Ejemplos de errores de prueba:
La solución no es ignorar la falla, sino corregir la prueba para que vuelva a representar el escenario de manera clara.
Los datos de prueba pueden provocar fallas difíciles de interpretar. Un escenario puede fallar porque el usuario ya estaba en otro estado, porque una entidad fue usada por otra ejecución o porque la limpieza anterior no se completó.
Señales de problema de datos:
Cuando los datos no son confiables, la prueba puede producir falsos positivos y falsos negativos.
Las fallas por sincronización aparecen cuando la prueba avanza antes de que la aplicación esté lista. Ya vimos que las esperas fijas suelen ser una causa importante de inestabilidad.
Ejemplos:
Si una falla desaparece al aumentar tiempos de espera, no significa que esté resuelta. Lo correcto es esperar por una condición observable y relevante.
Cuando un escenario depende de correos, pagos, autenticación externa o APIs de terceros, una falla puede venir de fuera de nuestra aplicación.
Conviene revisar:
Aunque el origen sea externo, también puede existir un defecto propio si la aplicación no maneja la falla de manera adecuada.
Reproducir una falla significa ejecutar nuevamente los pasos necesarios para observar el mismo problema. No siempre es obligatorio reproducir antes de reportar, pero ayuda a confirmar la causa.
Para reproducir de manera útil, conviene controlar:
Si la falla no se reproduce, no se debe descartar automáticamente. Puede tratarse de una falla intermitente que requiere más evidencia.
Una forma efectiva de investigar es comparar la ejecución fallida con ejecuciones exitosas anteriores. Esto ayuda a detectar qué cambió.
| Comparación | Pregunta útil |
|---|---|
| Versión de aplicación | ¿La falla comenzó después de un despliegue? |
| Datos usados | ¿El usuario o entidad tenía un estado distinto? |
| Duración de pasos | ¿Algún paso empezó a tardar más? |
| Errores de logs | ¿Apareció una excepción nueva? |
| Ambiente | ¿Cambió la configuración o la disponibilidad de servicios? |
Reintentar una prueba fallida puede ser útil para detectar intermitencia, pero no debe reemplazar el análisis. Si una prueba falla y luego pasa, todavía existe una señal que merece revisión.
El reintento automático puede ocultar problemas como:
Cuando el análisis indica que hay un defecto real, el reporte debe ser claro y accionable. Un buen reporte reduce el tiempo que desarrollo necesita para entender y corregir el problema.
Debe incluir:
El reporte no debe decir solamente "falló la prueba". Debe explicar qué comportamiento incorrecto se observó en la aplicación.
Si la causa está en la prueba, hay que corregirla con el mismo cuidado que cualquier otro código. No conviene simplemente borrar la verificación o aumentar tiempos de espera sin entender el problema.
Acciones posibles:
Una prueba corregida debe seguir protegiendo el comportamiento importante del flujo.
Supongamos que una prueba E2E falla porque, después de pagar, el curso no aparece en "Mis cursos". Esa falla puede tener distintas causas.
| Observación | Causa probable | Acción |
|---|---|---|
| La orden figura como pagada, pero el curso no se habilita. | Defecto real de negocio. | Reportar defecto con datos de la orden. |
| El backend de cursos no responde. | Problema de ambiente. | Revisar disponibilidad y despliegue. |
| El pago sandbox queda pendiente. | Dependencia externa o configuración. | Revisar proveedor y eventos recibidos. |
| El curso sí aparece, pero la prueba busca otro nombre. | Error de prueba o datos. | Corregir dato esperado o preparación del escenario. |
| La lista carga tarde y la prueba verifica demasiado pronto. | Sincronización. | Esperar por el curso específico o estado de carga finalizado. |
El análisis debe terminar en una acción clara. Dejar fallas sin clasificar hace que la suite pierda valor y que el equipo ignore resultados importantes.
Posibles decisiones:
La decisión debe quedar registrada cuando la falla afecta una suite compartida.
Al analizar fallas E2E, conviene evitar estos errores:
Para analizar una falla E2E, podemos seguir esta lista:
El análisis de fallas es una habilidad central para trabajar con pruebas End-to-End. Estas pruebas atraviesan muchas capas, por lo que una falla puede tener múltiples causas posibles.
Una suite E2E madura no solo ejecuta escenarios: también produce evidencias útiles y permite clasificar fallas con criterio. Distinguir defectos reales, problemas de ambiente y errores de prueba evita diagnósticos incorrectos y mejora la confianza del equipo en los resultados.
En el próximo tema veremos organización de una suite E2E: nombres, carpetas y responsabilidades.