De 18% a 2% de flakiness en una suite E2E
Cómo un equipo de e-commerce recuperó la confianza en su suite E2E atacando las causas raíz de las pruebas intermitentes en lugar de añadir reintentos.
Contexto
Equipo de producto e-commerce, ~12 ingenieros, suite E2E de ~140 casos en Playwright corriendo en CI. La suite tardaba 22 minutos y fallaba de forma intermitente.
Análisis (root cause)
Se instrumentó la suite para registrar qué tests fallaban y por qué, en lugar de tratar el flakiness como ruido uniforme. El 80% de la intermitencia venía de un 12% de los tests, concentrada en tres causas:
| Causa | % de los fallos flaky |
|---|---|
Esperas fijas (waitForTimeout) | 46% |
| Estado compartido entre tests | 31% |
| Dependencia de un tercero no mockeado | 23% |
Decisión
En lugar de añadir reintentos automáticos (que ocultan el problema), se atacó la causa raíz. Ver el concepto de flaky tests y su política de cuarentena.
Implementación
- Reemplazo de esperas fijas por web-first assertions (espera sobre condición).
- Aislamiento de estado: cada test crea y limpia sus datos (factories).
- Virtualización del tercero con un mock contractual.
- Cuarentena temporal de los peores ofensores con SLA de reparación.
Resultado
Lección generalizable
El flakiness no se “tolera” con reintentos: se diagnostica y se erradica por causa raíz. Medir antes de actuar (defect clustering) concentró el esfuerzo donde rendía.
Grafo de conocimiento
Complementa a
Mitigado por