Es una de las preguntas que más me hacen líderes de equipos que están creciendo: “¿cuál es el ratio ideal de QA por developer?”. Circulan números — 1 a 4, 1 a 5, 1 a 10 — como si fueran una verdad universal. No lo son, y aplicar un ratio genérico sin entender por qué existe ese número suele generar más problemas que los que resuelve.
Por qué el ratio fijo es una trampa
Un ratio de “1 QA por cada 5 developers” puede ser correcto para un equipo y completamente equivocado para otro, porque ignora variables que pesan más que la cantidad de gente:
Madurez de automatización. Un equipo con una suite de automatización sólida y bien mantenida necesita mucho menos esfuerzo manual de QA por developer que uno que depende casi enteramente de testing manual. El ratio “correcto” para el primero puede ser la mitad que para el segundo, con el mismo tamaño de equipo de desarrollo.
Criticidad del producto. Un sistema de pagos o de salud no se puede medir con la misma vara que una herramienta interna de uso ocasional. El costo de un bug en producción no es lineal — es exponencial según qué tan crítico es el sistema — y el ratio de calidad necesario tiene que reflejar eso, no un promedio de la industria.
Calidad del proceso de desarrollo. Equipos con buenas prácticas de revisión de código, criterios de aceptación claros y testing unitario sólido generan menos carga para QA que equipos donde todo el control de calidad recae al final del pipeline. El ratio no mide esto, pero debería.
Velocidad de release. Un equipo que despliega una vez por semana tiene una dinámica de calidad distinta a uno que despliega varias veces al día. La frecuencia de release cambia qué tipo de cobertura automatizada es indispensable, independientemente de cuántas personas haya en cada rol.
La pregunta que reemplaza al ratio
En vez de preguntar “¿cuántos QA necesitamos?”, la pregunta más útil es: ¿qué porcentaje de nuestra cobertura crítica depende hoy de una persona ejecutando pasos a mano?
Si la respuesta es alta, el problema no se resuelve necesariamente contratando más QA — se resuelve invirtiendo en automatización y procesos para que la calidad no dependa linealmente de cuánta gente hay disponible para probar a mano. Si la respuesta ya es baja porque hay buena automatización, agregar más QA manual probablemente no es la inversión con mejor retorno.
Cómo se calcula en la práctica
Un enfoque más útil que un ratio fijo:
- Mapear cuánta cobertura crítica de negocio depende de ejecución manual hoy.
- Estimar cuánto tiempo de ese trabajo manual se puede convertir en automatización sostenible en los próximos meses.
- Recién ahí, dimensionar el equipo humano necesario — combinando personas que diseñan estrategia de calidad, personas que mantienen automatización, y la porción de testing manual que realmente lo justifica (exploratorio, usabilidad, casos donde el juicio humano es insustituible).
Ese número va a ser distinto para cada equipo, y va a cambiar con el tiempo a medida que la madurez de automatización mejora. Un ratio fijo te da una falsa sensación de certeza sobre algo que en realidad depende de tu contexto específico.
Si estás dimensionando un equipo de QA y el ratio genérico no te convence, podemos mapear tu contexto real en un diagnóstico. Agendemos una conversación.