La métrica más mentirosa en QA: cobertura de tests
Tabla de contenidos
200 tests automatizados. Dashboard en verde. Y nadie sabe qué validan.
Nota: Los ejemplos de código en este artículo usan Playwright + TypeScript, pero todos los principios, anti-patrones y recomendaciones aplican a cualquier herramienta de automatización y cualquier lenguaje de programación.
La falsa seguridad del porcentaje
Cobertura del 80%. El pipeline pasa en verde. El equipo está tranquilo.
Pero hacé esta prueba: elegí un test al azar de tu suite y preguntale a cualquier persona del equipo qué valida ese test. No qué archivo toca. No qué endpoint llama. Qué valida. Qué regla de negocio protege.
Si la respuesta es silencio, tenés un problema que ningún porcentaje de cobertura va a resolver.
80% de cobertura no significa 80% de confianza en el producto. Significa que el 80% del código se ejecuta durante los tests.
La cobertura mide ejecución. La confianza mide intención.
5 anti-patrones de naming que matan la confianza
El nombre de un test es su documentación más inmediata. Si el nombre no comunica intención, el test es opaco para cualquier persona que no lo escribió — incluyendo tu yo del futuro.
1. El nombre genérico
El problema: cuando falla, nadie sabe qué se rompió sin abrir el código.
2. El nombre que describe implementación, no comportamiento
El problema: si cambia la UI, el nombre pierde sentido aunque el comportamiento siga siendo válido.
3. El número secuencial
El problema: los números no comunican nada. Cuando falla test_flow_2, necesitás abrir el archivo para saber qué pasó.
4. El test que solo valida el happy path
El problema: si solo testeás que las cosas funcionan cuando todo está bien, no estás testeando. Estás confirmando.
5. El test copy-paste
El problema: tests duplicados con nombres similares inflan la cobertura sin agregar valor. Son ruido que parece señal.
Código que habla vs código que corre
La diferencia entre un test que aporta confianza y uno que solo suma al contador de cobertura muchas veces está en detalles que no requieren más esfuerzo — solo más intención.
test("dashboard", async ({ page }) => { await page.goto("/dashboard"); const items = await page.locator(".item-list").count(); expect(items).toBe(0);});¿Qué valida? ¿Qué se rompe si falla? ¿Qué regla de negocio protege?
Imposible saberlo sin abrir el código y rastrear qué hace .items.
test("deberia_mostrar_estado_vacio_cuando_usuario_no_tiene_transacciones", async ({ page,}) => { await page.goto("/dashboard"); await expect(page.getByText("No tienes transacciones")).toBeVisible();});Mismo esfuerzo. Misma cantidad de líneas. Pero cuando este test falla, cualquier persona del equipo sabe exactamente qué se rompió: el dashboard no muestra el estado vacío para usuarios sin transacciones.
- El nombre describe el comportamiento esperado, no la acción técnica - El
locator usa
getByText()en vez de una clase CSS genérica — el assertion es legible - Si falla en el pipeline, el mensaje del reporte ya te dice qué pasó sin investigar
Más allá del porcentaje: métricas que sí miden confianza
Si la cobertura de código no es suficiente para medir la salud de tu suite, ¿qué sí lo es? Estas son las métricas que considero más valiosas:
1. Tasa de falsos positivos
¿Cuántas veces falla tu suite por razones que no son un bug real? Si tu equipo ya tiene el reflejo de darle “re-run” al pipeline sin investigar, tu suite tiene un problema de credibilidad. Un test que falla sin razón real entrena al equipo a ignorar las fallas.
2. Tiempo de diagnóstico
Cuando un test falla, ¿cuánto tarda alguien en entender qué se rompió? Si la respuesta es “abro el código, reviso los selectores y reproduzco manualmente”, tus tests no están comunicando. El nombre del test, el mensaje de error y el reporte deberían ser suficientes para diagnosticar el 80% de las fallas.
3. Cobertura de reglas de negocio
No cuántas líneas de código se ejecutan, sino cuántas reglas de negocio están protegidas por al menos un test. ¿Tenés test para “usuario intenta transferir más de lo que tiene”? ¿Para “sesión expira después de 30 minutos”? ¿Para “descuento no aplica si el carrito tiene menos de 3 ítems”? Esa es la cobertura que importa.
4. Ratio de detección vs escape
¿Cuántos bugs encontró tu suite antes de llegar a producción vs cuántos se escaparon? Si los bugs importantes se siguen escapando a pesar de tener “buena cobertura”, tu suite está testeando las cosas equivocadas.
5. Velocidad de feedback
¿Cuánto tarda tu suite en darte una respuesta? Una suite de 200 tests que tarda 45 minutos no está dando feedback — está dando resultados históricos. El valor de un test automatizado está directamente ligado a la velocidad con la que te dice si algo se rompió.
Checklist: ¿tu suite es confiable?
No hace falta responder todas hoy — pero si más de 3 respuestas son “no”, tienes trabajo por hacer.
Ver las 10 preguntas del checklist
- ¿Cualquier persona del equipo puede entender qué valida un test solo leyendo su nombre?
- ¿Los nombres de tus tests describen comportamiento de negocio, no acciones técnicas?
- ¿Cuando un test falla en el pipeline, el mensaje de error es suficiente para diagnosticar sin abrir el código?
- ¿Tu suite testea caminos negativos y edge cases, no solo happy paths?
- ¿Podés identificar qué reglas de negocio NO están cubiertas por ningún test?
- ¿El equipo investiga cada falla antes de darle re-run al pipeline?
- ¿Tu suite completa corre en menos de 15 minutos?
- ¿Los tests nuevos pasan por code review con el mismo rigor que el código de producción?
- ¿Tenés un proceso para retirar o refactorear tests que ya no aportan valor?
- ¿Los tests están organizados por funcionalidad de negocio, no por tipo técnico?
La cobertura real no se mide en porcentaje
¿Si este test falla, alguien entiende inmediatamente qué se rompió en el negocio?
Si la respuesta es sí para la mayoría de tu suite, tenés cobertura real — sin importar qué diga el porcentaje.
Si la respuesta es no, no tenés un problema de cobertura. Tenés un problema de claridad. Y la buena noticia es que la claridad no requiere reescribir toda la suite. Requiere empezar a nombrar, documentar y revisar los tests con la misma intención con la que se escribe el código que protegen.
No es más trabajo. Es el trabajo que falta.