Hola mi amigo y amiga de la calidad y colegas del mundo del desarrollo. Me hace muy feliz saber que este contenido lo están leyendo personas de distintos países, porque al final todos compartimos algo en común: trabajamos en una industria donde la calidad sigue siendo uno de los temas más mal entendidos.

¿Por qué siempre que hay un problema pensamos primero en QA?

Déjame comenzar con una escena que probablemente ya viviste: algo falla en producción, el equipo no tiene claridad inmediata de lo que ocurrió, el cliente comienza a reportar el problema y desde negocio aparece la presión por entender qué pasó. Y casi automáticamente surge la pregunta: “¿Esto no lo probó QA?”, “¿Por qué QA aprobó esta funcionalidad?”.

Lo interesante no es que esto ocurra, sino que ocurre casi por reflejo. Como si ya tuviéramos internalizado que la calidad depende de una sola persona o de un solo equipo. En muchos casos, ni siquiera es una acusación consciente, es simplemente la forma en la que hemos aprendido a trabajar.

Pero si lo analizamos con calma, esta reacción dice mucho más sobre cómo está diseñado el proceso que sobre el trabajo de QA.

¿Qué recomiendan los desarrolladores experimentados?

En libros como Clean Coder, hay una idea que se repite constantemente: el código no debería avanzar de estado si no está listo. Y listo no significa “que QA lo valide después”, sino que quien lo escribió ya hizo el esfuerzo de entender sus riesgos, probar sus escenarios y asegurarse de que lo que entrega tiene un nivel de calidad sólido.

Los desarrolladores con más experiencia entienden algo que cambia completamente la dinámica del equipo: la calidad no es una fase, es parte del desarrollo. No se trata de escribir código rápido y dejar que alguien más lo revise, sino de asumir responsabilidad desde el momento en que se toma una tarea.

Cuando este principio no está presente, ocurre algo muy común: el desarrollador construye, QA valida, QA detecta, QA reporta… y cuando algo se escapa, QA responde. No porque sea justo, sino porque el sistema está diseñado así.

¿Qué proponen las grandes empresas sobre cómo trabajar la calidad?

Aquí es donde vale la pena traer dos referencias muy importantes.

Por un lado, en How Google Tests Software, se explica claramente que la calidad no es responsabilidad de un equipo separado. En Google, los desarrolladores son responsables de sus pruebas, de su código y de su impacto en el sistema. Esto permite que el feedback sea rápido, que los errores se detecten antes y que el sistema sea más fácil de mantener.

Por otro lado, en Fifty Quick Ideas to Improve Your Tests, se plantea algo muy directo: tratar la automatización como una actividad secundaria o delegarla a especialistas es un error económico. Cuando separas desarrollo y testing, introduces retrasos, duplicas esfuerzos y generas cuellos de botella. Pero lo más peligroso no es eso, sino que los desarrolladores dejan de sentirse responsables por la calidad.

Y cuando eso pasa, el sistema entra en un ciclo complicado: más errores, más dependencia de QA, más presión, más retrasos… y eventualmente, más frustración para todo el equipo.

Entonces, ¿QA está para supervisar el trabajo del desarrollador?

Aquí es donde quiero ser muy claro, porque este es uno de los malentendidos más grandes.

QA no está para supervisar, ni una es auditoría. Tampoco es la persona que valida si el desarrollador hizo bien o mal su trabajo. El analista de calidad es un habilitador.

Es quien ayuda a que el equipo piense mejor, a que se hagan las preguntas correctas, a que se entiendan los riesgos y a que el producto se construya con una visión más completa, no solo técnica sino también desde el usuario y el negocio.

Cuando QA se convierte en un filtro final, el proceso ya está fallando. Pero cuando QA participa desde el inicio, en conversaciones, en diseño, en definición de escenarios, el impacto es completamente distinto.

Mi recomendación para finalizar

Aquí quiero cerrar con algo que puede sonar contra intuitivo, pero que he visto repetirse durante años.

Mientras más supervisas el trabajo de los desarrolladores, menos responsables se vuelven de su propia calidad. No porque no les importe, sino porque el sistema les dice que alguien más se encargará de eso.

Lo que realmente ha funcionado, y no lo digo solo desde mi experiencia de más de 18 años, sino también apoyado en lo que proponen autoras como Janet Gregory y Lisa Crispin, es generar espacios de conversación. Tener la oportunidad de sentarse con el desarrollador, hacer preguntas, explorar escenarios y ayudarle a pensar en soluciones, es mucho más efectivo que revisar su trabajo al final.

Porque la calidad no se impone. Se construye, y cuando el equipo entiende esto, deja de buscar culpables y comienza a mejorar el proceso.

📥 Recurso práctico descargable

Guía rápida: ¿Tu equipo está delegando mal la calidad?

Puedes usar estas preguntas con tu equipo:

• ¿Quién es responsable de probar el código antes de integrarlo?
• ¿Cuánto tiempo pasa entre escribir código y recibir feedback?
• ¿QA está validando todo o el equipo comparte esa responsabilidad?
• ¿El sistema está diseñado para ser fácil de probar o depende de flujos completos?
• Cuando algo falla, ¿buscan culpables o revisan el proceso?

Si estas preguntas generan incomodidad, probablemente hay una oportunidad clara de mejora.