Si llevas un tiempo trabajando con tests automatizados, tarde o temprano te encuentras con esto: un test que a veces pasa y a veces falla sin que hayas cambiado nada. Lo ejecutas de nuevo y pasa. Lo vuelves a ejecutar y falla otra vez. Eso es un test flaky y es una de las mayores frustraciones en el mundo del QA Automation.
En este artículo te explico qué son, por qué aparecen y cómo eliminarlos.
Qué es un test flaky
Un test flaky es un test automatizado que produce resultados inconsistentes — a veces pasa y a veces falla con el mismo código y sin cambios en la aplicación.
El término viene del inglés flaky, que significa «que se descascara» o «poco fiable». Es una descripción perfecta — como algo que parece sólido pero que se rompe de forma impredecible.
Los tests flaky son especialmente problemáticos porque destruyen la confianza en la suite de tests. Cuando el equipo no puede distinguir un fallo real de un fallo aleatorio, empieza a ignorar los resultados — y ahí es cuando los bugs reales llegan a producción sin que nadie lo detecte.
Por qué los tests flaky son tan peligrosos
Un test flaky no es solo una molestia — es un problema serio para el equipo.
Primero destruye la confianza. Si los tests fallan aleatoriamente, el equipo deja de tomarlos en serio. Cuando llega un fallo real, nadie le hace caso porque «seguramente es otro flaky».
Segundo ralentiza el desarrollo. Cada fallo aleatorio requiere tiempo para investigar, re-ejecutar y confirmar que no hay un bug real. En equipos con muchos tests flaky, esto puede consumir horas a la semana.
Tercero bloquea los pipelines de CI/CD. Si un test flaky falla en GitHub Actions, bloquea el merge o el despliegue hasta que alguien lo investigue y re-ejecute manualmente.
Las causas más comunes de los tests flaky
Problemas de timing y sincronización
Es la causa más frecuente. El test intenta interactuar con un elemento que todavía no está completamente cargado o listo. En Selenium esto es especialmente común porque hay que gestionar las esperas manualmente. En Playwright el auto-waiting reduce mucho este problema pero no lo elimina completamente.
Ejemplo típico: el test hace clic en un botón antes de que el spinner de carga haya desaparecido, o intenta leer un texto antes de que la petición AJAX haya terminado.
Dependencias entre tests
Cuando un test depende del estado que dejó el test anterior, si el orden de ejecución cambia o el test anterior falla, el siguiente también falla. Cada test debe ser completamente independiente — preparar su propio estado y limpiarlo después.
Datos de prueba compartidos
Si varios tests usan los mismos datos de prueba simultáneamente — especialmente en ejecución en paralelo — pueden interferir entre sí. Un test modifica un dato que otro test está usando y el resultado es impredecible.
Dependencias de entorno
Tests que dependen de la hora del sistema, del orden de resultados de una base de datos sin ordenación explícita, de servicios externos que pueden estar lentos o caídos, o de condiciones de red variables.
Animaciones y transiciones CSS
Los tests que intentan interactuar con elementos que están animándose pueden fallar dependiendo de en qué punto de la animación se ejecuta el test. Una animación de 300ms puede ser suficiente para provocar un fallo intermitente.
Cómo detectar tests flaky
Antes de eliminarlos hay que identificarlos. Estas son las formas más eficientes.
Re-ejecutar los tests múltiples veces
La forma más directa es ejecutar la suite completa varias veces seguidas y ver qué tests producen resultados inconsistentes. En pytest puedes usar el plugin pytest-repeat para ejecutar cada test N veces automáticamente.
bash
pip install pytest-repeat
pytest --count=5 tests/Si un test falla en 2 de 5 ejecuciones sin cambios en el código, es un flaky.
Revisar el historial de CI/CD
GitHub Actions guarda el historial de ejecuciones. Si un test tiene un patrón de fallos intermitentes en el historial — falla, se re-ejecuta y pasa — es un flaky candidato a investigar.
Ejecutar en paralelo
Muchos tests que parecen estables en ejecución secuencial muestran su naturaleza flaky cuando se ejecutan en paralelo. Ejecuta la suite con paralelización activada y observa qué falla.
Cómo eliminar tests flaky en Playwright
Usa los locators correctos
Los locators frágiles son una fuente importante de flakiness. Un locator basado en la posición del elemento en el DOM o en clases CSS generadas dinámicamente puede cambiar entre ejecuciones.
Playwright recomienda usar locators semánticos siempre que sea posible — roles ARIA, text content, labels. Son más estables porque están vinculados al significado del elemento, no a su posición o estilo.
python
# Frágil — depende de la estructura del DOM
page.locator("div.container > div:nth-child(2) > button")
# Estable — basado en el texto visible
page.get_by_role("button", name="Confirmar pedido")Evita las esperas fijas
El time.sleep() es la fuente de flakiness más fácil de eliminar. Si pones time.sleep(2) para esperar a que cargue algo, el test fallará si el servidor tarda más de 2 segundos y será innecesariamente lento si tarda menos.
Playwright tiene métodos de espera inteligentes que esperan exactamente hasta que se cumple una condición:
python
# Mal — espera fija arbitraria
import time
time.sleep(2)
page.click("#confirmar")
# Bien — espera hasta que el elemento esté listo
page.wait_for_selector("#confirmar", state="visible")
page.click("#confirmar")
# Aún mejor — el auto-waiting de Playwright lo maneja solo
page.get_by_role("button", name="Confirmar").click()Aísla cada test completamente
Cada test debe preparar su propio estado inicial y limpiarlo después. No debe depender de lo que haya hecho el test anterior.
python
import pytest
from playwright.sync_api import Page
@pytest.fixture(autouse=True)
def setup_test(page: Page):
# Preparar estado inicial
page.goto("https://miweb.com")
page.evaluate("localStorage.clear()")
yield
# Limpiar después del test
page.evaluate("localStorage.clear()")Desactiva las animaciones en los tests
Las animaciones CSS son una fuente de flakiness difícil de detectar. Puedes desactivarlas globalmente en Playwright añadiendo esto a tu configuración:
python
# En conftest.py
@pytest.fixture
def page(browser):
context = browser.new_context()
page = context.new_page()
# Desactivar animaciones CSS
page.add_style_tag(content="*, *::before, *::after { animation-duration: 0s !important; transition-duration: 0s !important; }")
yield page
context.close()Usa datos de prueba únicos por test
Si los tests necesitan crear datos — usuarios, pedidos, registros — cada test debe crear los suyos propios con identificadores únicos para evitar conflictos en ejecución paralela.
python
import uuid
def test_crear_usuario(page: Page):
email_unico = f"test_{uuid.uuid4().hex[:8]}@test.com"
# Usar email_unico en el testLa estrategia de cuarentena
Cuando identificas un test flaky no siempre puedes arreglarlo inmediatamente — puede requerir investigación. Mientras tanto, puedes ponerlo en cuarentena para que no bloquee el pipeline.
En pytest puedes usar el marker xfail para marcar un test como esperado-que-falle:
python
@pytest.mark.xfail(reason="Test flaky pendiente de investigar - issue #123")
def test_proceso_pago(page: Page):
# ...Esto hace que el test siga ejecutándose pero no bloquee el pipeline si falla. Y si empieza a pasar de forma consistente, pytest te avisará con un XPASS para que lo saques de cuarentena.
La regla de oro con los tests flaky
Si un test falla de forma intermitente, nunca lo re-ejecutes sin investigar la causa. Re-ejecutar un test flaky es como apagar la luz de avería del coche sin ir al mecánico — el problema sigue ahí.
Cada test flaky que arreglas hace la suite más fiable. Cada test flaky que ignoras hace que el equipo confíe menos en la automatización.
Si quieres saber más sobre cómo organizar una suite de tests profesional puedes leer qué es el Page Object Model y cómo usarlo con Playwright o cómo hacer pruebas de regresión con Playwright.
Y si necesitas ayuda para estabilizar la suite de tests de tu proyecto puedes ver mis servicios en fatimaqa.com.