La mayoría de los equipos de QA no fueron diseñados: emergieron. Cuando el equipo de desarrollo era pequeño, alguien asumió las pruebas. Cuando el producto creció, se sumó un tester. Cuando los bugs en producción se volvieron un problema, se formalizó el rol. La estructura resultante refleja el orden en que se tomaron esas decisiones, no el modelo que mejor se adapta a la velocidad, el tamaño y los requerimientos de calidad actuales.

El problema de una estructura de QA que creció por acreción es que optimiza para la situación que existía cuando se tomó cada decisión, no para la situación actual. Un equipo de QA centralizado que funcionaba cuando había tres equipos de desarrollo se convierte en un cuello de botella cuando hay quince. Un modelo de QA embebido que era eficiente con releases mensuales pierde cobertura cuando los ciclos se comprimen a semanal. La estructura que produjo buenos resultados el año pasado no escala automáticamente.

Rediseñar la estructura del equipo de QA no es un ejercicio teórico: es la decisión que determina si la función de calidad puede operar al ritmo que el negocio exige.

Los tres modelos de estructura de QA

No existe un modelo universalmente correcto. Existe el modelo correcto para el tamaño, la velocidad de entrega y el nivel de madurez de QA de tu organización en este momento. Las organizaciones con mayor madurez frecuentemente migran de un modelo a otro a medida que escalan.

Modelo 1: QA centralizado

Todos los ingenieros de QA pertenecen a un equipo central que atiende las necesidades de testing de todos los equipos de desarrollo de forma transversal. El QA Manager administra los recursos y los asigna según la demanda.

• Cuándo funciona bien: organizaciones con hasta cuatro o cinco equipos de desarrollo, ciclos de release relativamente largos (quincenales o mensuales), y necesidad de consistencia metodológica fuerte. También es el punto de partida natural para organizaciones que están formalizando su práctica de QA por primera vez.
• Sus ventajas: facilita la especialización —un tester de performance o security no necesita estar duplicado en cada equipo—, permite establecer estándares y metodología uniforme desde un solo punto, y simplifica la gestión de carrera de los perfiles de QA.
• Su limitación estructural: genera dependencia y crea cuellos de botella a medida que crece el número de equipos o se comprimen los plazos. Los testers centralizados tienen menos contexto sobre cada producto específico, lo que impacta la profundidad del testing y la velocidad de detección. En organizaciones con ciclos de CI/CD cortos, la capacidad central raramente puede seguir el ritmo de todos los equipos simultáneamente.

Modelo 2: QA embebido

Cada equipo de producto tiene su propio ingeniero o ingenieros de QA dedicados, que forman parte del equipo y participan desde el inicio del ciclo de desarrollo. No hay un equipo central de QA: los recursos están distribuidos.

• Cuándo funciona bien: organizaciones con ciclos de release cortos (semanales o continuos), múltiples equipos autónomos con productos diferenciados, y un nivel de madurez de QA suficiente para que los ingenieros de calidad puedan operar sin supervisión metodológica centralizada.
• Sus ventajas: el tester embebido tiene contexto profundo del producto, participa en la definición de requerimientos, reduce el tiempo de detección y eleva la calidad de los criterios de aceptación. Es el modelo más compatible con los principios de “shift-left” y con prácticas como BDD y Three Amigos.
• Su limitación estructural: sin un nodo central que establezca estándares, la consistencia metodológica entre equipos se deteriora con el tiempo. Cada equipo desarrolla su propio enfoque de testing, y la organización termina con múltiples subculturas de calidad. Los perfiles de QA embebidos también tienen menor visibilidad de carrera que los centralizados, lo que puede impactar la retención. Las capacidades especializadas —testing de seguridad, performance, accesibilidad— son difíciles de mantener cuando están fragmentadas en cada equipo.

Modelo 3: Centro de Excelencia con ejecución distribuida

Un equipo central pequeño y senior —el Centro de Excelencia (CoE) de QE— es responsable de la estrategia de testing, la metodología, los estándares, las herramientas compartidas y las capacidades especializadas. Los ingenieros de QA embebidos en cada equipo de producto ejecutan dentro del marco que el CoE establece.

• Cuándo funciona bien: organizaciones de tamaño mediano a enterprise con múltiples equipos de producto, alta velocidad de entrega y requerimientos de consistencia y cumplimiento regulatorio. Es el modelo al que convergen las organizaciones con mayor madurez de QE.
• Sus ventajas: combina la consistencia metodológica del modelo centralizado con la velocidad y el contexto del modelo embebido. El CoE concentra la especialización (performance, security, AI testing), diseña la arquitectura de pruebas y mantiene los estándares; los equipos embebidos tienen autonomía para ejecutar dentro de ese marco. La gobernanza existe sin convertirse en un cuello de botella.
• Su limitación estructural: requiere liderazgo claro del CoE y mandato organizacional para que sus estándares sean adoptados, no ignorados. Sin esa autoridad, el CoE se convierte en un equipo consultivo que produce documentos que nadie implementa. También requiere un nivel de madurez de QE que muchas organizaciones todavía están construyendo.

Los roles que no pueden faltar

Una estructura de QA eficiente no se define solo por cuántas personas tiene, sino por qué capacidades cubre. Estos son los roles que determinan la cobertura funcional del equipo:

• QA Lead o Manager. Responsable de la estrategia de testing, la metodología del equipo, la comunicación con stakeholders y la alineación de la función de QA con los objetivos del negocio. En organizaciones pequeñas este rol puede ser un QA Engineer senior con responsabilidades de liderazgo; en organizaciones más grandes es un rol de gestión de tiempo completo. Sin este perfil, el equipo opera tácticamente sin dirección estratégica.
• QA Engineer con automatización. El perfil central de ejecución: diseña y ejecuta casos de prueba, construye y mantiene scripts de automatización, integra el testing en el pipeline de CI/CD y gestiona la suite de regresión. La automatización no es opcional en equipos con alta frecuencia de release: sin ella, el volumen de regresión manual se convierte en el cuello de botella que limita la velocidad de entrega.
• SDET (Software Development Engineer in Test). Un perfil de ingeniería de software especializado en infraestructura de testing: diseña frameworks de automatización, construye herramientas de testing internas, instrumenta el sistema para facilitar la observabilidad y desarrolla las capacidades técnicas que el equipo de QA necesita para operar a escala. No todos los equipos necesitan un SDET dedicado, pero cuando la complejidad del framework de automatización crece más allá de lo que los QA Engineers pueden sostener, este perfil elimina la deuda técnica de testing.
• Especialistas por tipo de prueba. Testing de performance (carga, estrés, pico), testing de seguridad (SAST, DAST, pentesting) y testing de accesibilidad (WCAG) requieren perfiles y herramientas específicos que el testing funcional no cubre. En la mayoría de las organizaciones medianas, estos especialistas no justifican una posición permanente en el equipo interno: se incorporan por proyecto o se resuelven con un proveedor externo que los mantiene activos y actualizados.

La composición correcta depende del contexto. Un equipo de tres personas que cubre lo básico —un QA Lead que también automatiza, un QA Engineer senior, un QA Engineer junior— puede ser más eficiente que uno de ocho personas sin metodología. El tamaño sin estructura produce headcount, no capacidad.

La trampa del ratio QA/desarrollador

La pregunta que más frecuentemente hacen los Engineering Directors al iniciar una conversación sobre estructura de QA es: ¿cuántos testers necesito por cada X desarrolladores?

Es la pregunta equivocada. O más precisamente: es la pregunta correcta si ya resolviste las tres anteriores. El ratio de QA por desarrollador que resulta eficiente depende de cuatro variables que ningún número de referencia genérico puede ignorar:

• Nivel de automatización. Un equipo donde el 80% de la regresión es automatizada y corre en el pipeline puede soportar muchos más desarrolladores por tester que uno donde el testing es mayoritariamente manual. La automatización no reemplaza al tester: reemplaza la ejecución repetitiva y libera al tester para diseño, exploración y testing de riesgo.
• Frecuencia de release. Un ciclo de release semanal con múltiples equipos en paralelo tiene requerimientos de capacidad de testing radicalmente distintos a uno mensual. Comprimir el ciclo sin ajustar la capacidad de testing produce acumulación de deuda de calidad, no velocidad real.
• Criticidad del sistema y requerimientos regulatorios. Una aplicación de banca digital bajo CNBV necesita más cobertura, más trazabilidad y más tipos de prueba que una aplicación interna de gestión de inventario. El overhead de cumplimiento regulatorio es real y tiene que estar reflejado en la capacidad del equipo.
• Madurez de QA del equipo de desarrollo. En equipos donde los desarrolladores escriben pruebas unitarias robustas, definen criterios de aceptación claros y participan activamente en el proceso de calidad, el equipo de QA puede concentrarse en pruebas de integración, exploración y riesgo. En equipos donde la calidad es exclusivamente responsabilidad de QA, la carga es mayor.

El ratio correcto emerge de entender estas cuatro variables. El número de referencia es un punto de partida para la conversación, no un sustituto de ese análisis.

Las cuatro decisiones que definen la eficiencia del equipo

Más allá de la estructura y los roles, la eficiencia de un equipo de QA depende de cómo se resuelven cuatro decisiones de proceso que frecuentemente quedan sin respuesta explícita:

1. ¿Quién diseña la estrategia de testing? En equipos sin QA Lead dedicado, la estrategia de testing emerge de forma incremental: cada ingeniero decide qué prueba según su criterio. El resultado es cobertura inconsistente, duplicación de esfuerzo en áreas de bajo riesgo y vacíos en áreas críticas. La estrategia de testing tiene que ser un entregable explícito, no un subproducto del trabajo diario.
2. ¿Quién posee los quality gates y con qué autoridad? Un quality gate sin la autoridad de bloquear un release es una sugerencia. La eficiencia del equipo de QA depende en parte de que sus hallazgos críticos tengan un proceso claro de escalación y de que los criterios de bloqueo estén acordados antes del sprint, no negociados bajo presión de entrega.
3. ¿Cómo se gestiona la deuda de testing? Los equipos que no tienen un proceso explícito para priorizar y remediar la deuda de testing —casos de prueba obsoletos, cobertura de automatización que no sigue el ritmo del desarrollo, ambientes de testing degradados— acumulan pasivo que eventualmente paraliza la capacidad de release. La deuda de testing necesita el mismo tratamiento que la deuda técnica: visibilidad, priorización y tiempo de sprint para resolverla.
4. ¿Cómo se integra el equipo con los ciclos de desarrollo? La integración más tardía posible —QA entra cuando el feature está “terminado”— maximiza el costo de corrección y crea el patrón de handoff que genera fricción. La integración más temprana posible —QA participa en el refinamiento, define criterios de aceptación, revisa diseños técnicos— reduce defectos antes de que existan. La decisión sobre cuándo y cómo integra QA no es solo operativa: define el rol de la calidad en la cultura del equipo.

¿Cuándo el equipo interno alcanza sus límites?

Hay señales concretas de que la estructura de QA actual no está escalando al ritmo del negocio:

El ciclo de testing es el último cuello de botella antes de cada release, y se comprime bajo presión en lugar de completarse. Los defectos escapan a producción con frecuencia que no corresponde al nivel de inversión en QA. El equipo no tiene capacidad para cubrir todas las capas de testing requeridas —performance, seguridad, accesibilidad— sin sacrificar la funcional. Los ciclos de contratación para perfiles especializados de QA duran más que el proyecto que los necesita. El nivel de automatización no crece porque el equipo está permanentemente en modo reactivo.

Cuando aparecen estas señales, hay dos respuestas estructurales posibles: escalar el equipo interno con los perfiles que faltan, o adoptar un modelo híbrido donde el equipo interno conserva la estrategia, el liderazgo y la propiedad de los quality gates, y un proveedor externo aporta la capacidad de ejecución, los perfiles especializados y la metodología que el equipo interno no puede construir internamente con la velocidad que el negocio necesita.

El modelo híbrido no es una solución de emergencia: es la estructura que la mayoría de las organizaciones medianas y enterprise en México con prácticas de QA maduras ha adoptado porque optimiza el costo, el acceso a especialización y la velocidad de escalamiento mejor que cualquiera de las dos alternativas puras.

Preguntas frecuentes

¿Un equipo de QA debería reportar a Engineering o a una función independiente? No hay una respuesta universalmente correcta, y la decisión tiene implicaciones en ambas direcciones. Cuando QA reporta directamente a Engineering, la integración con el proceso de desarrollo es más fluida y la velocidad de ciclo tiende a ser mayor; el riesgo es que la presión de entrega del equipo de desarrollo influya sobre los criterios de aceptación del equipo de QA. Cuando QA reporta a una función independiente —como Product o una función de Calidad transversal—, la independencia del proceso de validación es mayor; el riesgo es la desconexión del ritmo de desarrollo y la fricción operativa. El factor más relevante no es la línea de reporte sino si los quality gates tienen criterios objetivos y autoridad real para bloquear un release, independientemente de quién gestiona el equipo.

¿Cómo se estructura un equipo de QA en una empresa que está escalando rápidamente? La estructura que funciona en una organización que escala rápido es la que puede crecer sin rehacerse desde cero con cada etapa. El modelo CoE + ejecución distribuida tiene esa propiedad: el CoE define los estándares una vez y los equipos embebidos los aplican; agregar un nuevo equipo de producto no requiere rediseñar la metodología ni la estructura central. Lo que más frecuentemente frena el escalamiento es no separar temprano la función de strategy y methodology ownership de la función de ejecución: cuando ambas están mezcladas en las mismas personas, escalar el headcount no escala la capacidad de dirección, y el QA Lead se convierte en el cuello de botella de todo.

¿Qué diferencia a un equipo de QA eficiente de uno que solo detecta defectos? Un equipo que solo detecta defectos opera al final del ciclo: recibe el feature terminado, lo prueba, reporta los bugs y espera la corrección. Un equipo eficiente interviene antes de que existan los defectos: participa en el refinamiento de requerimientos para identificar ambigüedades, define criterios de aceptación en lenguaje ejecutable antes del desarrollo, y diseña la estrategia de riesgo que determina qué partes del sistema necesitan qué nivel de cobertura. La diferencia en resultado es significativa: los defectos encontrados antes de escribir el código cuestan una fracción de los encontrados en testing tardío. La diferencia en estructura del equipo es que el primero requiere solo ejecución; el segundo requiere diseño de estrategia, conocimiento del dominio y participación en el proceso de discovery.

¿Tu equipo de QA está estructurado para el ritmo de entrega que el negocio exige hoy, o para el que tenía cuando se formó?

El Quick Assessment de Madurez de QE de MTP evalúa tu estructura actual en cinco días hábiles y produce el diagnóstico y el roadmap para el siguiente nivel de capacidad.