No contrates más testers (todavía)

Hola mi amigo de la calidad, hoy quiero comentarte que hay una frase que suena provocadora, incluso irresponsable, cuando se escucha por primera vez: “No contrates demasiados testers.” En una industria donde los productos crecen sin pausa, donde cada sprint agrega nuevas funcionalidades y donde los errores parecen inevitables, la reacción natural suele ser exactamente la contraria: más features implican más pruebas, y más pruebas implican más personas dedicadas a probar. Es una lógica que parece impecable.

Sin embargo, lo que parece lógico no siempre es lo que realmente escala.

El software, por definición, nunca estará libre de errores. Pensar en un sistema completamente perfecto es una falacia que cualquier persona que lleve tiempo en esta industria reconoce. Siempre habrá defectos, siempre existirán escenarios imprevistos, siempre habrá combinaciones que nadie anticipó. Pero aceptar que el software es imperfecto no significa que debamos gestionar desde el afán de encontrar todo lo que posiblemente puede fallar. Creanme cuando les digo que esta visión es de las más estresantes.

Cuando un producto crece, lo primero que muchos equipos hacen es mirar a QA y decir: “Necesitamos más testers”. El backlog de pruebas aumenta, las regresiones son más complejas, las integraciones se multiplican y la presión por salir a producción no disminuye. Desde fuera, reforzar el equipo de testing parece la respuesta más acertada. Pero hay una pregunta incómoda que rara vez se hace con honestidad: ¿estamos contratando más testers porque el producto está creciendo… o porque el equipo de desarrollo no está asumiendo completamente la responsabilidad por la calidad?

Tengo mucha experiencia en equipos que, cada vez que el volumen aumenta, la solución organizacional es añadir más personas al final de la cadena. Más ojos para revisar. Más manos para ejecutar casos. Más responsables de detectar lo que otros no previnieron. Y lo que ocurre de manera silenciosa —sin que nadie lo declare explícitamente— es que la responsabilidad comienza a desplazarse. Si existe un equipo cuyo trabajo es encontrar errores, entonces el resto del sistema empieza a operar bajo la premisa implícita de que alguien más validará lo que se construyó.

No sucede por mala intención. Sucede por diseño.

He estado leyendo estos dias el libro “How Google Tests Software” y me llama la atención que allí afirman que cuando los desarrolladores saben que existe una capa posterior dedicada a revisar, corregir y validar, la presión interna por entregar algo robusto disminuye ligeramente. QA se convierte en red de seguridad. En filtro. En la última barrera antes de producción. Y cuando algo falla en el campo, la conversación inicial suele girar alrededor de por qué no fue detectado antes, en lugar de por qué fue introducido el defecto en primer lugar.

Ese cambio sutil en la cultura es el verdadero riesgo de contratar testers como respuesta automática al crecimiento.

La calidad no es principalmente un ejercicio de detección. Es un ejercicio de prevención. Si cada nueva funcionalidad exige más personas que inspeccionen al final, entonces el sistema está optimizando para encontrar errores, no para evitarlos. Y cuando una organización optimiza para detectar, inevitablemente acepta que los defectos se producirán con cierta normalidad. En cambio, cuando optimiza para prevenir, la conversación cambia hacia diseño, hacia testabilidad, hacia automatización desde el primer momento, hacia responsabilidad directa del autor del cambio.

Cada persona que escribe código debería trabajar con una premisa muy sencilla pero poderosa: lo que entrego debería ser difícil de romper. No imposible, porque eso no existe. Pero sí suficientemente sólido como para que encontrar un error evidente no sea la regla sino la excepción. Cuando la mentalidad es esa, la automatización deja de ser un accesorio y se convierte en parte natural del desarrollo. Las pruebas unitarias no son una obligación externa; son una herramienta de protección personal. Las pruebas de integración no son una carga adicional; son un mecanismo de confianza. Los pipelines no son una formalidad; son un sistema de retroalimentación inmediata.

El problema es que cuando QA absorbe la mayor parte del trabajo de validación, el resto del equipo deja de sentir con la misma intensidad el impacto de romper algo. Y en los sistemas complejos, lo que no se siente directamente tiende a perder prioridad.

Existe además un efecto organizacional que pocas veces se menciona. A medida que se contratan más testers sin redefinir la responsabilidad del desarrollo, aumenta la coordinación, aumentan los handoffs, aumentan las reuniones de sincronización y aumenta la fricción. Lo que comenzó como una intención de acelerar puede terminar ralentizando el ciclo completo. QA se convierte en cuello de botella no porque el equipo no sea competente, sino porque el diseño del sistema organizacional lo posiciona como último filtro obligatorio.

Y entonces aparece el ciclo repetitivo: el producto crece, QA se satura, se contratan más testers, la complejidad aumenta, la responsabilidad se diluye, y el problema estructural permanece intacto.

Esto no significa que nunca debamos contratar más testers. Significa que hacerlo debe ser una decisión estratégica, no reactiva. Antes de ampliar el equipo de calidad, conviene preguntarse si los desarrolladores realmente están escribiendo pruebas sólidas sin depender de que alguien más las exija, si los bugs en producción escalan hacia quienes modificaron el código, si el diseño contempla la testabilidad desde el inicio y si la automatización nace en desarrollo y no únicamente al final del ciclo.

Cuando los problemas escalan, no deberían escalar automáticamente hacia el equipo de calidad. Deberían escalar hacia el sistema que permitió que el error fuera introducido sin ser prevenido. En equipos maduros, el primer análisis ante un incidente no es “¿por qué QA no lo encontró?”, sino “¿qué parte del diseño, del código o de nuestras pruebas técnicas falló?”. Esa diferencia en la conversación cambia la cultura completa.

El software seguirá teniendo errores. Eso es inevitable. Pero la forma en que distribuimos la responsabilidad sobre esos errores sí es una elección. Podemos construir organizaciones donde QA sea el departamento que limpia después de la fiesta, o podemos construir equipos donde cada persona asuma que la calidad es parte inseparable de su trabajo.

Antes de contratar más testers, revisa si realmente necesitas más personas validando… o más personas asumiendo responsabilidad por lo que construyen.

Porque cuando todos son dueños de la calidad, la necesidad de aumentar el equipo como reacción automática comienza, curiosamente, a disminuir.

Checklist: ¿Estamos usando QA como muleta?

Evalúa tu equipo:

• ☐ Los developers escriben unit tests sin que QA los obligue.
• ☐ Si un bug escapa a producción, el primer análisis lo hace quien tocó el código.
• ☐ QA no es el único responsable de cobertura.
• ☐ Los criterios de aceptación incluyen pruebas técnicas.
• ☐ Existe cultura de “prevenir” y no solo “detectar”.

Si marcaste menos de 3, tu problema no es falta de testers, sino una necesidad de adoptar una cultura preventiva. Dime en los comentarios si te gustaria un blog al respecto.