¿Por qué fallan mis pruebas cuando la aplicación está bien?

Una prueba de extremo a extremo se pone en rojo cuando la red está lenta, el DNS falla, el sitio responde con un 403 o un 429 o muestra un desafío antibot, o el navegador muere, y nada de eso es un defecto de tu aplicación. Nexus Studio, de Verdict System LLC, da a estos fallos sus propios veredictos: TIMEOUT, UNREACHABLE, BLOCKED y CRASHED. Ninguno se reporta como un bug de la aplicación.

Por el equipo de Nexus Studio, Verdict System LLC. 7 de octubre de 2026.

¿Qué hace fallar una prueba sin que haya un bug?

Una prueba solo informa de que algo no ocurrió. La causa puede estar en cuatro lugares que no tienen nada que ver con tu código:

• la página fue lenta y la prueba se quedó sin tiempo;
• no se pudo llegar al host, por ejemplo porque el nombre no se resolvió;
• el sitio se defendió con un 403, un 429, un CAPTCHA o un desafío antibot, y la petición nunca llegó a tu producto;
• el navegador o el proceso murió.

Cuando todos estos casos se leen como un simple rojo, el equipo los reporta como bugs, o aprende a relanzar los rojos en vez de leerlos. De cualquier modo, el defecto real se esconde en el ruido.

¿Cómo distingue Nexus Studio un falso fallo de un bug?

Cuando una prueba falla, el motor lee el mensaje de error y el registro de red de la ejecución y los contrasta con grupos de patrones en un orden fijo. El primer grupo que coincide decide el veredicto. El orden es CONFIG_ERROR, luego CRASHED, BLOCKED, UNREACHABLE y TIMEOUT, y solo después BREACHED_FLAKY o BREACHED. Así, BREACHED, el veredicto que equivale a un reporte de bug, queda para un fallo que ningún patrón del entorno ni del arnés explica. Los patrones cubren la redacción de Playwright y de Selenium WebDriver.

¿Qué significan TIMEOUT, UNREACHABLE, BLOCKED y CRASHED?

• TIMEOUT: la prueba nunca recibió respuesta a tiempo. Eso no prueba que la aplicación esté rota, ni que funcione: la ejecución no puede saberlo. Una navegación que se quedó sin tiempo es un TIMEOUT, porque empezó y la página fue lenta.
• UNREACHABLE: no se pudo llegar al host. El DNS o la conexión fallaron antes de observar ninguna página, como con un nombre que no se resolvió, una conexión rechazada o una máquina sin red. Un error de certificado no entra aquí: ese es un hallazgo.
• BLOCKED: el sitio se defendió con un 403, un 429, una página de bloqueo o un desafío antibot. Cuando había una defensa en pantalla, metadata.json la nombra. Un teléfono Android real que se durmió o está bloqueado también es BLOCKED, como requisito previo sin cumplir.
• CRASHED: el navegador o el proceso murió, por ejemplo una página cerrada, un error del protocolo DevTools o una sesión de WebDriver muerta. Es infraestructura: revisa la máquina y el driver.

La guía de veredictos lista los patrones de error exactos de cada uno.

¿Qué ve mi pipeline de CI?

Siete de los 14 veredictos terminan con código 0: SECURE, AUTO_RECOVER, FLAKY, CHAOS_RESILIENT, PERFORMANCE_DEGRADED, A11Y_VIOLATION y SECURITY_VIOLATION. Los otros siete terminan con 1, y TIMEOUT, UNREACHABLE, BLOCKED y CRASHED están entre ellos. Así que el build sigue en rojo, porque la prueba no pasó, pero el informe y el Historial dicen cuál fue la causa. Los runners de pytest y Selenium terminan con 2 cuando la ejecución no pudo arrancar.

¿Qué evidencia guarda cada falso fallo?

Cada uno de los cuatro guarda report.md, metadata.json, raw-data.json y una captura del último fotograma. El video es distinto:

• TIMEOUT y BLOCKED: el video está apagado por defecto. Actívalo en Settings, en Keep failure video for.
• UNREACHABLE: no se ofrece video, porque no cargó ninguna página y la grabación saldría en blanco.
• CRASHED: no se ofrece video, porque la grabación de un navegador muerto sale rota.

Solo graban video las ejecuciones web de Playwright y las de móvil emulado. Un teléfono Android real, una ejecución de Selenium y una prueba de API no lo hacen.

Con Jira activado, un TIMEOUT abre un ticket, y un bloqueo, una caída del navegador y un sitio inalcanzable nunca lo hacen.

¿Cuáles son los límites?

• La clasificación lee el texto del error. Un mensaje que escribiste tú y que contiene 403, Forbidden o Access Denied se lee como BLOCKED. Mantén específicos tus mensajes de aserción personalizados y abre metadata.json cuando un veredicto te sorprenda.
• Un TIMEOUT no prueba que la aplicación funcione. Una prueba que da TIMEOUT en cada ejecución merece una revisión.
• Un timeout más largo no oculta un elemento roto: falla más tarde.
• Estos veredictos nombran la causa de una ejecución fallida. No la eliminan: un sitio que bloquea sigue bloqueando hasta que cambies cómo llegas a él.

¿Dónde puedo verlo?

La página de Evidence sigue una prueba fallida y lista cada archivo que deja cada veredicto en tu disco. La guía de veredictos explica en qué orden decide el motor los 14. La prueba de 30 días ejecuta el mismo motor sobre tus propias pruebas.