Los bugs en producción bajaron a la mitad en un trimestre.
En la reunión de resultados, nadie supo decir por qué.
Me lo contó una amiga hace unos días, y me quedé varios días pensando en eso. Su equipo metió la automatización en el pipeline, las pruebas empezaron a correr en cada cambio, y los errores que llegaban al cliente cayeron de golpe. Todo lo que un equipo de QA persigue durante años, ella lo consiguió en meses.
Cuando los jefes miraron el gráfico, hicieron la pregunta lógica: ¿esto fue por los devs, que ahora escriben mejor código, o por QA?
Silencio. Nadie tenía cómo separarlo. Y en esa duda, un año de trabajo suyo quedó sin dueño.
No es una anécdota aislada. Es la situación de una parte enorme del QA hoy: mejorar la calidad puertas adentro del equipo, sin que ese trabajo se vea desde afuera. Y lo que quiero contarte es que eso no se arregla trabajando más. Se arregla midiendo distinto.
El problema no es la calidad, es la atribución
Cuando algo sale mal en producción, todos saben a quién preguntarle. Hay un incidente, un postmortem, una reunión de urgencia, y alguien tiene que explicar qué pasó.
Cuando algo deja de salir mal, no pasa nada de eso. No hay incidente que investigar. No hay reunión. Hay silencio. Y el silencio, en una organización, se lee como “se arregló solo”.
Ese es el punto ciego: la ausencia de bugs no cuenta su propia historia. Si nadie mide explícitamente qué parte de la mejora vino de QA, el crédito queda flotando. A veces se lo lleva otro. A veces no se lo lleva nadie, y la conversación termina en un “no sabemos bien qué pasó, pero qué bueno que pasó”.
Y a QA le toca perder en esa duda por una razón estructural: es el área que revisa, no la que construye. Cuando no se pueden separar causas, el mérito tiende a irse hacia quien produjo el código.
Por qué pasa
No es mala intención de nadie. Es un problema de diseño en cómo se reporta la calidad.
La mayoría de los equipos reportan con una sola cifra: bugs en producción, mes a mes. Y esa cifra mezcla, sin querer, todo lo que pudo haber influido en el mismo período:
- Cambios en cómo los devs escriben código.
- Una herramienta nueva de análisis estático.
- Un refactor que redujo complejidad.
- El trabajo de QA: automatización, quality gates, casos límite cubiertos.
Cuando todo eso vive en un solo número, es imposible separar causas. Y cuando es imposible separar causas, QA pierde por defecto.
Y casi nunca hay mala intención detrás. Quien mira el gráfico da la explicación que el reporte le permite dar. Si lo único que recibe es una curva que baja, va a llenar el hueco con lo que tenga a mano: que el equipo maduró, que la aplicación se estabilizó, que ese trimestre vino tranquilo. No está inventando. Está trabajando con lo único que le llegó.
El reconocimiento no se pide. Se muestra con un número que solo QA puede explicar.
Lo que sí separa el aporte de QA
La solución no es pedir crédito. Es traer datos que separen las causas. Estas cuatro métricas cuentan esa historia, y ninguna necesita un dashboard nuevo.
Defect escape rate
Cuántos bugs llegan a producción contra cuántos se detectan antes de salir, en el mismo período. Si ese ratio baja después de que metiste automatización o un quality gate nuevo, la correlación empieza a hablar sola. Es la métrica más directa, porque mide exactamente el trabajo de QA: atrapar antes.
Tiempo de detección
No es lo mismo un bug que se encuentra en QA en minutos que uno que un usuario reporta tres semanas después. Medir cuánto tardas en atrapar un problema muestra el valor del trabajo temprano, no solo el resultado final. Y es una métrica que los devs no mueven: la mueve la suite y el proceso.
Cobertura de flujos críticos
No de líneas. De negocio. Cuántos de los flujos que duelen si fallan (pagos, login, checkout, verificación de identidad) están cubiertos hoy con tests automatizados que no estaban antes. “Doce flujos críticos identificados, nueve cubiertos” dice mucho más que “80% de coverage”, y ya escribí por qué el coverage de líneas es la métrica más mentirosa en QA.
Línea de tiempo correlacionada
Marcar en un gráfico simple cuándo se introdujo cada mejora de QA (la automatización, un gate nuevo, un cambio de proceso) al lado de la curva de bugs en producción. No hace falta análisis estadístico. Una correlación visual, con la fecha del cambio anotada, ya cuenta la historia que las cifras solas no cuentan.
El costo evitado (horas o incidentes que no ocurrieron gracias a la automatización) es la métrica que más convence a quien no vive el día a día técnico. Pero una estimación floja resta más credibilidad de la que suma. Si no tienes el dato con confianza, déjala fuera.
La tabla que se reenvía
Nadie reenvía un informe. Todos reenvían una tabla que cabe en un mensaje. Esta la lee cualquier jefe en treinta segundos:
| Métrica | Antes | Después | Qué cambió en QA |
|---|---|---|---|
| Bugs en producción / mes | 14 | 6 | Automatización + gate de requisitos |
| Tiempo de detección promedio | 9 días | 2 horas | Suite corriendo en cada PR |
| Flujos críticos cubiertos | 4 de 12 | 9 de 12 | Casos límite agregados a la suite |
Los números son de ejemplo. Los tuyos van a ser otros, pero el molde es este: una fila por métrica, el antes, el después, y la cuarta columna con lo que hizo QA para que cambiara. Esa cuarta columna es la que separa causas. Sin ella, la tabla vuelve a ser un gráfico de bugs que cualquiera puede explicar como quiera.
La primera frase la puede decir cualquiera. La segunda solo la puede decir QA, y es la que se reenvía.
Si respondes por el equipo
Si lideras QA, esto tiene una capa más. La tabla no es solo para que se vea tu trabajo: es para que la próxima decisión se tome con tu evidencia y no con la intuición de otro.
Tres cosas que hacen que funcione hacia arriba:
- Una métrica, no cinco. Elige la que mejor explique tu caso y ponle una línea de tiempo. Cinco métricas se leen como un informe; una se recuerda.
- La fecha del cambio de proceso va en el mismo gráfico. “En marzo activamos el gate” escrito sobre la curva. Eso es lo que convierte una correlación en una historia.
- Se comparte antes de que pregunten. El momento de mandar la tabla no es cuando alguien dice “¿por qué mejoró?”. Es el primer lunes del mes, siempre, aunque nadie pregunte. La tercera vez que la reciben, ya saben de quién es la mejora.
Para aplicar mañana: elige una de las cuatro métricas, saca el antes y el después de tus herramientas de siempre, y arma la tabla con la cuarta columna.
Para poner sobre la mesa: la tabla, con la fecha del cambio de proceso, enviada el primer lunes del mes sin que nadie la pida.
Cierre
El coverage no demuestra calidad. Y los bugs que no pasan tampoco se demuestran solos.
Si tu equipo mejoró y nadie arriba sabe por qué, el problema no es tu trabajo. Es que ese trabajo nunca se tradujo a un lenguaje que la organización pudiera ver. No hace falta reportar todo, todo el tiempo. Alcanza con elegir una métrica, ponerle una línea de tiempo, y contar la historia una vez.
La próxima vez que alguien pregunte “¿por qué bajaron los bugs?”, que la respuesta no sea “no sé, pero qué bueno”. Que sea la tabla.
Y sí, ya sé cuál es la siguiente pregunta, porque me la hicieron apenas mostré esta tabla: “está bien, ¿pero de dónde saco esos datos?”. Esa es la guía que viene después de esta: dónde buscar cada número en Jira, GitHub Actions y Playwright, sin dashboard nuevo.