Contenido
Las pruebas inestables (flaky tests) se encuentran mirando el historial, no un build en rojo aislado: una prueba es inestable cuando pasa y falla con el mismo código. Guarda cada intento de cada prueba, reintentos incluidos, y luego lista las pruebas cuyos resultados mezclan aprobados y fallos en el mismo commit. Google midió que cerca del 84% de las transiciones de aprobado a fallido en su CI involucraban una prueba inestable (Google Testing Blog), así que esa lista suele concentrar la mayor parte del ruido de "build roto".
¿Qué es una prueba inestable?
Una prueba inestable es una prueba que puede pasar y fallar sin que cambie el código ni la propia prueba. Google la define como "una prueba que muestra un resultado aprobado y uno fallido con el mismo código" (Google Testing Blog). El mismo artículo indica que alrededor del 1,5% de todas sus ejecuciones de pruebas daban un resultado inestable, y que casi el 16% de sus pruebas tenían algún grado de inestabilidad.
Dos condiciones hacen que la definición sirva en la práctica:
Mismo código. Una prueba que empezó a fallar tras un commit y sigue fallando es una regresión, no una prueba inestable. El SHA del commit (o el build) es lo que permite distinguirlas.
Resultados mezclados. Un solo fallo no demuestra nada. Necesitas al menos un aprobado y al menos un fallo con ese mismo código, ya sea entre ejecuciones distintas o entre reintentos de la misma ejecución.
El problema no es exclusivo de Google. Un estudio de febrero de 2026 sobre GitHub Actions encontró que el 3,2% de los builds se volvían a ejecutar, que el 67,73% de esas repeticiones eran inestables (fallaron y luego pasaron sin ningún cambio) y que las pruebas inestables causaban el 64,99% de los fallos inestables, por delante de los problemas de red, con un 15,8% (Ge y Zhang, arXiv 2602.02307).
¿Cómo encuentro las pruebas inestables de mi suite?
Las pruebas inestables se encuentran en cinco pasos: guardar cada intento, vincularlo a un commit, consultar los resultados mezclados, priorizar y confirmar.
Guarda cada intento. Activa unos pocos reintentos en CI (uno o dos) y asegúrate de que tus reportes conserven cada intento como un resultado propio. Si solo se guarda el resultado final, una prueba que falló y luego pasó en el reintento aparece en verde, y la evidencia desaparece.
Vincula cada resultado al código con el que corrió. Guarda la rama, el SHA del commit y la URL del build de CI en cada ejecución. Sin esos datos no puedes distinguir "falló con el mismo código" de "falló después de un cambio".
Consulta los resultados mezclados. Lista las pruebas que tienen al menos un fallo y al menos un aprobado en una ventana reciente, por ejemplo los últimos 30 días, en tu rama principal. Cuentan dos señales: un fallo seguido de un aprobado al reintentar en la misma ejecución, y un aprobado y un fallo en ejecuciones distintas del mismo commit.
Prioriza por costo. Ordena la lista según cuántas veces falló cada prueba en esa ventana. Una prueba que falló de forma intermitente 12 veces en un mes cuesta más repeticiones y más confianza que una que lo hizo una vez, así que va arriba.
Confirma antes de etiquetar. Ejecuta cada sospechosa muchas veces de forma aislada (siguiente sección). Una prueba que solo falla dentro de la suite completa y nunca sola apunta a estado compartido o al orden de las pruebas, que se corrige de forma distinta a un problema de tiempos.
Ejecuta la consulta de forma periódica, por ejemplo cada semana, y no una sola vez. Google señala que su ritmo de nuevas pruebas inestables era "más o menos el mismo que el ritmo de corrección" (Google Testing Blog), así que una limpieza puntual no se mantiene limpia.
¿Cómo confirmo que una prueba es realmente inestable?
Confirma una sospecha ejecutando la prueba muchas veces sobre código sin cambios y contando los fallos. La mayoría de los runners lo permiten directamente:
# Playwright: ejecuta 50 veces cada prueba que coincida
npx playwright test tests/checkout.spec.ts --repeat-each=50
# Playwright: hace fallar el job de CI si alguna prueba queda marcada como flaky
npx playwright test --retries=2 --fail-on-flaky-testsLa CLI de Playwright documenta --repeat-each <N> como "ejecuta cada prueba N veces" y --fail-on-flaky-tests como "falla si alguna prueba se marca como flaky" (Playwright CLI).
Interpreta el resultado así:
Resultado de 50 ejecuciones aisladas | Qué sugiere | Siguiente paso |
|---|---|---|
50 aprobados, pero falla en la suite completa | Dependencia del orden o estado compartido (datos, caché, globales) | Ejecútala después de las pruebas que la preceden en CI; reinicia el estado entre pruebas |
Algunos fallos en aislamiento | Tiempos, concurrencia o una dependencia externa | Compara los errores de los intentos fallidos; busca timeouts y esperas |
50 fallos | No es inestable: está rota con este código | Trátala como una regresión |
50 aprobados, y también pasa en la suite | No se reproduce aquí; a menudo, recursos que solo existen en CI | Compara el entorno de CI con el local (CPU, red, datos) |
Google menciona como causas habituales la concurrencia, la dependencia de comportamientos no deterministas o indefinidos, el código de terceros inestable y los problemas de infraestructura (Google Testing Blog). Compara los mensajes de error de los intentos fallidos: un timeout en el mismo localizador cada vez es una pista muy distinta a una aserción diferente en cada fallo.
¿Basta con activar los reintentos automáticos?
Activa los reintentos para reunir evidencia y mantener los pipelines en marcha, pero nunca trates un reintento que pasó como un aprobado que puedes ignorar. Cada framework tiene su propia opción:
Framework | Cómo reintentar | Qué registra |
|---|---|---|
Playwright |
| Clasifica cada prueba como "passed", "flaky" (falló primero y pasó al reintentar) o "failed" (Playwright) |
Jest |
| Solo disponible con el runner por defecto, |
pytest |
| Versión 16.7 del plugin, publicada en septiembre de 2026 (PyPI) |
El riesgo es que los reintentos oculten errores reales. Google describe cómo marcar una prueba como inestable para que solo informe un fallo tras 3 fallos seguidos, y lo califica de "lejos de ser una solución perfecta": reduce los falsos positivos, pero anima a ignorar la inestabilidad, y una rotura real en una prueba marcada de 15 minutos tarda 45 minutos en aparecer (Google Testing Blog).
Una regla práctica: permite uno o dos reintentos, guarda cada intento y revisa la lista de "falló y luego pasó" como parte de la consulta semanal de la sección anterior.
¿Pongo en cuarentena, corrijo o elimino una prueba inestable?
Corrige las pruebas inestables que protegen comportamiento importante, pon en cuarentena las que no puedas corregir esta semana y elimina las que nadie echaría de menos. Cuarentena significa que la prueba sigue ejecutándose pero ya no bloquea el pipeline; Google creó una herramienta que pone en cuarentena las pruebas con demasiada inestabilidad y abre un bug para su responsable, y advierte que esto "podría ocultar fácilmente una condición de carrera real" (Google Testing Blog).
Situación | Decisión |
|---|---|
Cubre un camino crítico (checkout, login, facturación) y la causa es conocida | Corregir ya |
Falla a menudo, causa desconocida, bloquea a otros equipos | Cuarentena, con responsable y fecha de revisión |
Duplica la cobertura que ya da otra prueba estable | Eliminar |
Lleva semanas en cuarentena sin ningún aprobado | Tratarla como rota: corregir o eliminar |
Decidas lo que decidas, márcalo en un solo lugar. Una etiqueta o un indicador en el caso de prueba te permite contar las pruebas en cuarentena, ver cuánto tiempo llevan ahí y notar cuándo una deja de pasar por completo.
Dónde encaja Probara
Probara guarda el historial de intentos del que depende el método anterior. Sus reporters para Playwright, Jest, Vitest y Cypress envían cada intento como un resultado propio, con su estado, su duración y sus errores: una prueba reintentada dos veces envía tres resultados. La ejecución muestra el último resultado, y los intentos anteriores quedan en el historial del caso (Resultados y reintentos de Playwright). Cada ejecución registra además la rama, el commit y la URL del build de CI.
En los planes Pro y Enterprise, Consultas convierte el paso 3 en una consulta guardada. Esta lista los casos automatizados con al menos un fallo y un aprobado en los últimos 30 días:
FROM cases WHERE automated = true
AND exists(results where status = failed AND executed > now(-30d))
AND exists(results where status = passed AND executed > now(-30d))
ORDER BY titleCada caso de prueba tiene un campo is flaky, que puedes contar en un dashboard con el widget Casos de prueba inestables (Dashboards) y consultar con isFlaky. La referencia de PQL incluye una consulta para los casos marcados sin ningún aprobado en los últimos 30 días, la fila "lleva semanas en cuarentena" de la tabla de decisión. Para una visión más amplia de lo que registra una herramienta de gestión de pruebas, consulta ¿Qué es una herramienta de gestión de pruebas?.
Preguntas frecuentes
¿Qué diferencia hay entre una prueba inestable y una prueba que falla?
Una prueba que falla lo hace siempre con el mismo código; una prueba inestable pasa en unas ejecuciones y falla en otras sin ningún cambio. Volver a ejecutarla sobre el mismo commit permite distinguirlas.
¿Cuántas repeticiones hacen falta para demostrar que una prueba es inestable?
Un aprobado y un fallo con el mismo código bastan para calificarla de inestable. Para estimar con qué frecuencia falla, ejecútala muchas veces en aislamiento, por ejemplo con --repeat-each=50 de Playwright, y cuenta los fallos.
¿Los reintentos empeoran las pruebas inestables?
Los reintentos no causan la inestabilidad, pero pueden ocultarla junto con los errores reales que hay detrás. Guarda cada intento y revisa las pruebas que fallaron y luego pasaron al reintentar, en lugar de contarlas como verdes.
¿Qué causa la mayoría de las pruebas inestables?
Google menciona la concurrencia, los comportamientos no deterministas o indefinidos, el código de terceros inestable y los problemas de infraestructura. En GitHub Actions, un estudio de 2026 atribuyó el 64,99% de los fallos inestables a pruebas inestables y el 15,8% a problemas de red.
¿Una prueba inestable debe bloquear un release?
Una prueba inestable en un camino crítico debe bloquear hasta que alguien confirme que el fallo no es real. Una prueba en cuarentena no debería bloquear, pero necesita un responsable y una fecha para volver.
