Tus pruebas siguen siendo Playwright, Selenium y pytest. No las reemplazamos. Las hacemos listas para la empresa, y tú eres dueño de todo: el código, la evidencia y el historial.
Una prueba fallida. Todo lo que dejó en tu disco.
Una ejecución real, no una maqueta: TC92 el 2026-09-30, headless, en Chromium, Firefox y WebKit. Abre example.com, sigue Learn more hasta IANA y espera que el encabezado diga Example Domain. La página dice Example Domains. Estos son los archivos de la ejecución en Chromium, sus tamaños reales y lo que hay dentro de cada uno.
en la carpeta de la ejecución, más una fila en History
531.2 kB
toda la carpeta, con el video incluido
32 campos
en metadata.json, para máquinas
9 secciones
en report.md, el reporte forense
Lo que deja una falla
La carpeta que archiva una falla, abierta.
La línea 23 de TC92_Iana_heading.js espera que el encabezado diga Example Domain. La página de IANA dice Example Domains: en 10000 ms el locator se resolvió 23 veces y leyó el plural todas las veces. BREACHED, en los tres motores. Este es el fotograma en el que falló y todos los archivos que escribió.
https://www.iana.org/help/example-domains
screenshot.png · 89.8 kB · una captura del viewport del último fotograma, 1280×720: lo que habría visto un usuario cuando se ejecutó la verificación
En el Evidence Locker el mismo registro se abre en cinco pestañas:
ReportMetadataTelemetryRaw LogAI Analysis
report.md5.3 kB
El reporte forense, en Markdown: se lee sin el Studio.
Incident summary
Root cause analysis
Network telemetry
Failure timeline
Historical stability
Self-healing log
Evidence artifacts
Performance budget
Lazy-loading audit
Sirve para abrir un ticket: el Incident summary nombra la prueba, el navegador, la página y el impacto en el negocio, y el Root cause analysis la verificación fallida, el selector, los valores esperado y recibido y la línea de código.
metadata.json2.2 kB
32 campos, legibles por máquinas. Algunos, tal como se escriben:
Sirve para filtrar fallas con un script en lugar de un parser de Markdown. También es el archivo que sella la cadena de custodia: una carpeta con un metadata.json es un registro.
raw-data.json5.1 kB
El log crudo: cada línea de consola, error de red, problema de seguridad y error de página de la ejecución, y las muestras de rendimiento.
Sirve para ver qué hizo la página alrededor de la falla. Un aprobado FLAKY o AUTO_RECOVER conserva el raw-data.json del intento fallido, así que un reintento que ocultó la falla igual deja su log.
Telemetrymedido
Medido al final de la prueba, contra tus presupuestos. La barra es la medición sobre su presupuesto.
LCP992 / 2500 ms
FCP992 / 1800 ms
CLS0.0295 / 0.1
TTFB727 / 800 ms
TBT0 / 200 ms
DOM114 / 1500 nodes
Heap5 / 50 MB
INPnot measured
Todo dentro del presupuesto, y el reporte marca TTFB como cercano a él. INP muestra not measured, nunca un aprobado: no se hizo clic ni se escribió nada en la página que midió. La auditoría de lazy loading dio a la página 85 de 100, grado B: una imagen sin ancho ni alto.
Sirve para distinguir una página lenta de una aserción equivocada.
video.webm428.8 kB
0:08 de 0:16
La sesión completa, 16.6 segundos: example.com, el clic en Learn more y luego la página de IANA mientras la comprobación se reintentaba. Se conserva porque la ejecución fue BREACHED, y se reproduce en el Evidence Locker. Una falla real conserva su video: BREACHED, BREACHED_FLAKY y CHAOS_BREACHED por defecto, TIMEOUT y BLOCKED cuando los activas en Settings. CRASHED y UNREACHABLE nunca se ofrecen, porque esa grabación sale rota o en blanco. Solo graban las ejecuciones de Playwright web y de móvil emulado: un teléfono Android real, una ejecución de Selenium y una prueba de API no.
Sirve para ver cómo llegó la página a la verificación fallida, paso a paso; la captura de arriba es el último fotograma.
Análisis de IAtu IA
Activado por defecto, con tu IA conectada. Con un modelo local de Ollama, el predeterminado, u otro proveedor que elijas, el motor añade cuatro encabezados al reporte: Diagnosis, Probable cause, Impact y Recommended action. Cuando tu propia herramienta de IA de línea de comandos está activada en el AI writer, lee report.md después de la ejecución, hasta cinco fallas por ejecución, y añade un quinto encabezado:
Diagnosis
Classification (solo con la herramienta de línea de comandos)
Probable cause
Impact
Recommended action
La clasificación es exactamente una de APP_BUG, APP_CHANGE, TEST_AUTHORSHIP, TEST_SETUP o INFRA_FLAKY. Sin IA conectada: no hay análisis, y los cinco archivos siguen igual.
trace.zip es un sexto archivo. Con Record a forensic trace on failure activado, que es el valor por defecto, una carpeta BREACHED también archiva un trace de Playwright (instantáneas del DOM, capturas de pantalla y código fuente), que se abre con npx playwright show-trace trace.zip. No se graba en un teléfono Android real. TC92 se ejecutó antes de que el trace fuera el valor por defecto, así que su carpeta contiene los cinco archivos de arriba.
Los 14 veredictos y lo que cada uno te indica hacer a continuación.
El veredicto está en el nombre de la carpeta: la de TC92 termina en [BREACHED]. El clasificador lee una falla en un orden fijo: primero el arnés, luego una caída, un bloqueo, un host inalcanzable y un timeout, y solo después BREACHED_FLAKY o BREACHED. Así que un BREACHED es una falla que ningún patrón del entorno explica. Cada tarjeta dice a quién le toca y qué archiva ese veredicto.
SECURENadie
Pasó por sí solo: sin reintento y sin selector reparado. Nada que hacer. Se archiva en evidence-passed-test, los 5 más recientes por prueba y navegador.
screenshot.pngmetadata.json
CHAOS_RESILIENTNadie
Pasó mientras se inyectaba una falla, así que la app aguantó. Se archiva en chaos-runs, aparte de los reportes de bugs, para que el caos nunca distorsione las cifras de estabilidad.
En verde, pero no sin ayuda: el self-healer cambió un selector roto. El locator de la prueba está muerto, y el próximo cambio del DOM rompe la suite de verdad. Corrige el locator. raw-data.json aparece cuando hizo falta un reintento, y es el del intento fallido.
screenshot.pngmetadata.jsonraw-data.json
FLAKYPrueba o app
Falló, luego un reintento lo pasó y no se reparó nada. Es inestabilidad sin explicar en la app o en la prueba, no una corrección. Lee el raw-data.json del intento fallido y luego la tendencia de History.
screenshot.pngmetadata.jsonraw-data.json
PERFORMANCE_DEGRADEDApp
Las aserciones pasaron y la página fue demasiado lenta: se superó un presupuesto de Web Vitals o de lazy loading. Es solo una advertencia hasta que hagas estricta la verificación.
screenshot.pngmetadata.json
A11Y_VIOLATIONApp
Las aserciones pasaron, la accesibilidad no. metadata.json lista cada regla de axe-core que se activó, con su impacto y su cantidad de nodos. Es solo una advertencia hasta que hagas estricta la verificación.
screenshot.pngmetadata.json
SECURITY_VIOLATIONApp
Las aserciones pasaron, los encabezados de seguridad no (por ejemplo, falta un CSP). Corrige los encabezados de la respuesta. Es solo una advertencia hasta que hagas estricta la verificación.
screenshot.pngmetadata.json
BREACHEDApp
Falló una aserción y ningún patrón del entorno o del arnés explica el error. Lee Expected y Received en report.md, mira el video y luego márcalo como Real bug o False alarm, con una razón.
Falló en el último intento tras un reintento anterior: la falla en sí es inconsistente. Compara los intentos antes de reportar un bug. Su video se conserva por defecto.
Se rompió bajo una falla inyectada. Un hallazgo de resiliencia, archivado aparte de los reportes de bugs funcionales; el reporte registra la falla aplicada y el impacto en el usuario. La retención nunca elimina una ejecución que se rompió. Su video se conserva por defecto.
Nunca respondió a tiempo, lo cual no prueba que la app esté rota. Revisa qué tan rápida fue la página en Telemetry antes de mover cualquier ajuste: un límite más largo no esconde un elemento roto, solo hace que falle más tarde. Su video viene apagado por defecto; actívalo en Settings, en Keep failure video for.
No se pudo llegar al host: falló el DNS o la conexión antes de observar página alguna. Revisa la URL, la red y la disponibilidad del objetivo. No es un hallazgo sobre la app. No se cargó ninguna página, así que su video saldría en blanco y no se ofrece ninguno.
El sitio se defendió: un 403, un 429, una página de bloqueo o un desafío anti-bots. metadata.json nombra la defensa cuando había una en pantalla. No es un hallazgo sobre la app, y Jira nunca archiva un bloqueo. Su video viene apagado por defecto; actívalo en Settings, en Keep failure video for.
El navegador o el proceso murió: una página cerrada, un error del protocolo DevTools, una sesión de WebDriver muerta. Infraestructura, no la app. Revisa la máquina y el driver. La grabación de un navegador muerto sale rota, así que no se ofrece ninguna.
Fuera de los 14: CONFIG_ERROR (el arnés no pudo iniciar la prueba: un import roto, un valor de .env que falta), SKIPPED e INTERRUPTED. Ninguno es un resultado sobre tu app, así que ninguno archiva una carpeta de evidencia ni una fila en History. Un CONFIG_ERROR igual se escribe completo, con una pista, en un log bajo .run-cache/config-errors/, para que la prueba rota se corrija. Las pruebas de API tienen siete veredictos propios: pruebas de API.
History
Cada ejecución escribe una fila. Las filas juzgan la prueba.
Junto a la carpeta, cada ejecución agrega una fila a history/<browser>/<test>/runs.json: las últimas 50 ejecuciones de cada prueba en cada navegador, por defecto. Estas son las tres filas de TC92, una por navegador, tal como se escriben. El mismo error_signature en las tres dice que es un solo error, no tres.
Un valor que el navegador no puede medir se escribe como null, nunca como cero: WebKit no reporta TTFB aquí. Las horas de las filas son UTC, como las escribe la fila; los nombres de carpeta usan la hora local de la máquina, UTC−5 en esta.
perf contiene LCP, FCP, CLS, TTFB, TBT, INP, tareas largas, tamaño del DOM, heap, cada página visitada y la puntuación de lazy loading. raw_log_ref y evidence_ref apuntan de vuelta a la carpeta de arriba.
Lo que el motor imprime a partir de ahí
TC92 chromium BREACHED 13.7s
expect(locator).toHaveText(expected) failed
at TC92_Iana_heading.js:23 waiting for getByRole('heading', { level: 1 })
stability CRITICAL 0% · 0/1 runs · 1 failed in a row
# TC91, la demo preparada de la página de inicio: un BREACHED y luego un TIMEOUT
stability CRITICAL 0% · 0/2 runs · 2 failed in a row
El duration_ms de la fila, 12291, es el de la prueba en sí, tal como lo midió Playwright, en el segundo de sus dos intentos.
Las mismas filas alimentan la sección Historical stability del reporte, las tendencias de la pantalla History (Regressed, Recovered, Still broken, Slower) y el ranking de riesgo, donde nada se llama flaky por debajo de cinco ejecuciones.
Un aprobado guarda poco. Una falla guarda todo. Los archivos viejos se van.
Una suite que corre cada noche llena un disco. El motor pone un tope a cada carpeta que escribe, por prueba y por navegador, de modo que el disco deja de crecer en un tamaño que puedes predecir. Una falla igual conserva lo necesario para reproducirla: el error con su selector y sus valores, la URL de la página, el fotograma, las líneas de consola, de red y de errores de página, el runtime y la plataforma, y el contexto de la ejecución, contra qué se midió. Los topes se definen en Settings, en Evidence & Retention.
La carpeta completa de arriba: 531.2 kB para TC92 en Chromium, 428.8 kB de los cuales son el video. trace.zip se suma mientras el tracing está activado.
Los mismos archivos sin la grabación, porque el video de TIMEOUT viene apagado por defecto: 23.9 kB para el TIMEOUT de TC91, la demo preparada de la página de inicio.
Un aprobado
screenshot.pngmetadata.json
Se archiva aparte de los reportes de bugs, las 5 más recientes por prueba y por navegador. La captura de pantalla es lo que compara la regresión visual. Un aprobado FLAKY o AUTO_RECOVER también conserva su carpeta, con el raw-data.json del intento fallido, mientras Keep evidence of a FLAKY / AUTO_RECOVER pass esté activado.
Settings · Evidence & Retention · valores por defecto
Bug reports kept per test20NEXUS_BUGREPORT_RETAIN
Passing screenshots kept5NEXUS_PASSED_RETAIN
Keep evidence of a FLAKY / AUTO_RECOVER passonNEXUS_RECOVERED_RETAIN
Raw run history window50 runsNEXUS_HISTORY_RETAIN
Smart Monkey sessions kept10NEXUS_MONKEY_RETAIN
Run contexts kept (what each run tested against)100NEXUS_RUN_CONTEXT_RETAIN
Record failure videoonNEXUS_VIDEO_ENABLED
Keep failure video for3 verdictsNEXUS_VIDEO_VERDICTS=BREACHED,BREACHED_FLAKY,CHAOS_BREACHED
Record a forensic trace on failureonNEXUS_TRACE_ENABLED
Estas tres líneas siguieron a la ejecución de TC92. Los archivos temporales de telemetría de la ejecución nunca son evidencia: se comprimen en un zip, las copias sueltas se eliminan, y quedan como máximo 2 zips de hasta 7 días, dentro de 500 MB. Esos tres límites son NEXUS_CACHE_ZIPS, NEXUS_CACHE_RETENTION_DAYS y NEXUS_CACHE_MAX_MB en .env, no campos de Settings.
En Settings, Clear cache elimina las carpetas test-results y playwright-report del espacio de trabajo y cierra cualquier navegador que haya dejado una ejecución caída o terminada a la fuerza. Se rechaza mientras un patrol está corriendo.
Workspace · Disk · el límite que tiene hoy cada carpeta
area limit today
Bug reports newest 20 runs per test and browser
Passed tests newest 5 runs per test and browser
API evidence newest 20 passing runs per test; failures kept
Chaos runs newest 20 held runs; runs that broke kept
Smart Monkey newest 10 sessions
Visual regressions newest 10 per test and checkpoint
Run context newest 100 runs
Run history newest 50 runs per test and browser
Chain of custody append-only, never trimmed
Archive no automatic limit
El panel Disk lista cada carpeta en la que escribe una ejecución, de la más grande a la más pequeña, con su tamaño, su cantidad de archivos y su fecha más antigua, el total y el espacio libre en la unidad. Una carpeta sin límite automático se marca. Clean se ofrece solo donde es seguro: la caché de ejecuciones, las versiones de archivos de prueba con más de 14 días y los reportes Executive con más de 30 días. Nunca toca la evidencia ni el Archive.
Evidence Locker · conserva lo que importa, libera el resto
Archive… copia exactamente las partes que marcas, con Screenshot y Report marcados al empezar, a View → Archive. La copia queda junto a la carpeta de evidencia, no dentro de ella, así que ninguna limpieza de retención la alcanza, y la ejecución en el Locker no se toca.
Restore, en la pantalla Archive, devuelve un registro a donde estaba y de nuevo al conteo. Si su carpeta se liberó, las partes archivadas se vuelven a escribir en el Evidence Locker. Un veredicto False alarm lo sigue dejando fuera del conteo.
Free disk envía una carpeta a la papelera de reciclaje. Donde el registro está sellado, el motor escribe primero la disposición, así que nexus verify informa PURGED, no TAMPERED. La retención hace lo mismo cuando elimina la carpeta más antigua, y el ledger sigue probando qué hash tenía la carpeta, quién la eliminó y cuándo. El sellado es opcional: hasta el primer veredicto Real bug o False alarm, o hasta nexus verify --seal, el Locker marca UNVERIFIED.
Mira lo que dejan tus propias fallas.
Gratis por 30 días, con todas las funciones, en tus máquinas. No necesitas tarjeta.