Nexus Studio¿Esta prueba es inestable o es un bug real?
Una prueba inestable falló y luego pasó en un reintento sin que nadie arreglara nada, y un bug real falla por una razón que ningún reintento cambia. Nexus Studio, de Verdict System LLC, las distingue registrando cada reintento: FLAKY para un fallo que un reintento pasó, BREACHED para un hallazgo real y BREACHED_FLAKY para un fallo que es en sí mismo inconsistente. Un reintento nunca convierte un defecto en una ejecución verde.
Por el equipo de Nexus Studio, Verdict System LLC. 7 de octubre de 2026.
¿Qué es una prueba inestable?
Una prueba inestable es aquella cuyos intentos no coinciden: falla una vez y pasa en otro intento, con el código y la prueba sin cambios. En Nexus Studio la palabra tiene un solo significado. FLAKY es una prueba que falló y luego pasó en un reintento, sin que nada se reparara. Algo es inestable, en la aplicación o en la prueba, y nada se arregló.
Un fallo duro que ocurre en todos los intentos no es inestable, aunque el autoreparador haya intentado y fallado al reparar un selector. Una versión anterior del motor archivaba ese caso como FLAKY. Los equipos leen FLAKY como "la prueba es mala" y siguen adelante, así que una aplicación rota salía como ruido. El motor ya no hace eso.
¿Los reintentos esconden bugs reales?
Pueden hacerlo, y la razón es el número de estados. Con solo pasa y falla, un reintento que pasa vuelve verde una ejecución roja, y un defecto intermitente de la aplicación se vuelve invisible. Es uno de los tipos de bug más caros de encontrar. Cuando el rojo también puede significar una red que parpadeó o un navegador muerto, el equipo aprende a relanzar los rojos en vez de leerlos, y la suite pierde confianza.
Nexus Studio mantiene visible el reintento. Una prueba que falló y luego pasó no es SECURE. Sale con 0 en CI, así que no rompe el build, pero aparece en el reporte y en History como FLAKY, un pase con reservas. Consulta cómo se deciden los 14 veredictos para ver el orden completo de las revisiones.
¿Cuál es la diferencia entre FLAKY, BREACHED y BREACHED_FLAKY?
- FLAKY: falló, luego un reintento la pasó y nada se reparó. Lee el raw-data.json del intento fallido y después la tendencia en History. Sale con 0.
- BREACHED: la prueba falló en un solo intento, y ningún patrón del entorno o del arnés explica el error. Falló una aserción. Este es el reporte de bug, y sale con 1.
- BREACHED_FLAKY: la prueba falló en su último intento después de un reintento previo, y ningún patrón del entorno o del arnés lo explica. El fallo en sí es inconsistente. Compara los intentos antes de abrir un bug. Sale con 1.
Dos veredictos vecinos completan el cuadro. AUTO_RECOVER es un pase donde el autoreparador reemplazó un selector, así que el locator del autor está muerto y la prueba no es limpia. Un primer intento que falló solo por tiempo y luego pasó en el reintento es SECURE, porque eso muestra latencia, no inestabilidad.
Antes de que un fallo sea BREACHED o BREACHED_FLAKY, el clasificador descarta las otras explicaciones en un orden fijo: un error del arnés, un crash, un bloqueo, un host inalcanzable y un timeout. Solo un fallo que ninguna de ellas explica es un hallazgo. Por eso un timeout o un CAPTCHA no llegan como reporte de bug.
¿Cómo se cuentan los reintentos?
El motor lee el número de intento de la ejecución. Una prueba que pasa con un número de reintento mayor que cero es FLAKY, salvo que se haya reparado un selector, y entonces es AUTO_RECOVER. Una prueba que falla o agota el tiempo con un número de reintento mayor que cero, y sin explicación del entorno, es BREACHED_FLAKY. Un pase limpio exige reintento cero y ningún selector reparado.
FLAKY significa que los intentos no coincidieron, y nada más. Un fallo en un solo intento, con cero reintentos, nunca se etiqueta como inestable. Cada fila de History también registra retry_attempt y attempts, así que la cuenta queda con la ejecución.
¿Qué evidencia deja cada veredicto?
- FLAKY: screenshot.png, metadata.json y raw-data.json. La carpeta conserva el raw-data.json del intento fallido, así que un reintento que ocultó el fallo igual deja su registro. Esto sigue el ajuste Keep evidence of a FLAKY / AUTO_RECOVER pass, que viene activado por defecto.
- BREACHED_FLAKY: report.md, metadata.json, raw-data.json y screenshot.png, y su video del fallo se conserva por defecto.
- BREACHED: los mismos archivos, con el video conservado por defecto.
El veredicto está en el nombre de la carpeta de evidencia, por ejemplo un nombre que termina en [BREACHED]. La página de evidencia sigue una prueba fallida a través de cada archivo.
¿Cómo detecta History una prueba que alterna?
History guarda una fila por ejecución para cada prueba y navegador o dispositivo, con el veredicto, el intento de reintento y la firma del error. Con esas filas muestra tendencias por sesión, día o semana: Regressed, Recovered, Still broken y Slower. Una prueba que pasa a verde, a rojo y otra vez a verde aparece ahí en vez de perderse entre relanzamientos.
El ranking de riesgo, en el Evidence Locker y en Patrol, ordena las pruebas por la frecuencia con que alternan, se rompen o cuestan tiempo. También muestra un riesgo previsto con una regresión logística sobre tu historial, con un respaldo EWMA cuando hay pocos datos. Nada se llama inestable con menos de cinco ejecuciones, porque una o dos no pueden mostrar un patrón.
Límites
- Los reintentos son lo que separa FLAKY de SECURE y BREACHED_FLAKY de BREACHED. Sin reintentos, un fallo intermitente es un BREACHED.
- FLAKY dice que los intentos no coincidieron. No dice por qué. Encontrar la causa en la aplicación o en la prueba sigue siendo trabajo de una persona.
- La clasificación lee el texto del error, así que un mensaje de aserción propio que contenga palabras como
403oForbiddenpuede leerse como un problema del entorno. Abre metadata.json cuando un veredicto te sorprenda. - Con menos de cinco ejecuciones, History y el ranking de riesgo no llaman inestable a nada.
Adónde ir después
La página de evidencia muestra cada archivo que deja una prueba fallida, y cómo Nexus Studio decide 14 veredictos de prueba explica el orden de las revisiones. La prueba de 30 días corre el mismo motor sobre tus propias pruebas.