En casi todos los proyectos de desarrollo hay un punto en común: todos dicen preocuparse por la calidad. Se mencionan buenas prácticas, se reservan fases de testing, se asumen compromisos con la excelencia. Pero cuando llega la hora de verdad, la calidad suele ser lo primero que se sacrifica ante la presión de los plazos, los costes o las prioridades cambiantes.
En ese escenario, los equipos de QA suelen ser los actores con menos poder en la mesa. Normalmente se espera que garanticen la calidad, pero sin estorbar demasiado.
A menudo, los intentos de influir en la forma de trabajar, cuestionar una práctica o pedir más claridad en una historia se interpretan como una molestia, no como una mejora. Cuando la calidad empieza a implicar cambios en la metodología, incomodidad en procesos ya establecidos, revisión de trabajo incompleto o retrasos en los hitos de entrega y facturación, deja de ser vista como valor… y pasa a verse como un obstáculo.
La paradoja es que se suele pedir asegurar el éxito de un proceso en el que, como QAs, no se nos permite intervenir a tiempo, encontrando sistemas rotos, documentación ambigua y expectativas imposibles.
Como profesionales de calidad, no queremos ser quienes encuentran errores: queremos ser quienes evitan que ocurran pero muchas veces, el margen para hacerlo simplemente no existe. Las fechas están cerradas antes de que se defina el alcance, las validaciones se comprimen o se descartan para no retrasar entregas, y las decisiones se toman sin considerar el impacto en pruebas o corrección de errores.
Cuando un sistema, proyecto u organización empieza a tener incidencias recurrentes, retrabajo o deuda técnica, el problema rara vez está en las pruebas, lo que suele haber es un problema estructural.
Es común que el éxito del proyecto dependa de la habilidad para gestionar los defectos detectados por el cliente y disfrazarlos de “ajustes”, “feedback” y una serie de eufemismos que enmascaran un proceso poco eficiente y de baja calidad.
Cuando se desarrollan funcionalidades sin criterios de aceptación definidos, se entregan versiones incompletas sin validaciones, y los cambios de última hora alteran todo el flujo sin margen para evaluar el riesgo, el QA solo puede apagar fuegos.
La calidad no se añade al final del proceso: se diseña desde el principio y eso implica que cada rol —desde negocio hasta desarrollo— asuma su parte de responsabilidad.
No se trata de hacer más testing, sino de construir un sistema que haga más difícil fallar.
La calidad es el resultado de decisiones compartidas, no del trabajo de un equipo aislado, el problema es que intentar influir en la calidad cuesta esfuerzo, tiempo y compromiso, y eso rara vez encaja en los plazos o presupuestos habituales.
Proponer revisiones, planificar pruebas exploratorias, establecer criterios medibles o automatizar procesos suena bien… hasta que alguien pregunta cuánto tarda o cuánto cuesta. Ahí es donde la conversación se desvía, y la intención de mejorar se diluye entre prioridades más visibles.
Al margen de la experiencia personal que uno pueda tener, este es un patrón común que se repite en foros y comunidades de testing, donde se comparte una misma sensación:
el equipo de QA quiere aportar, pero el sistema no está diseñado para escucharlo.
Por eso es necesario cambiar el relato. El QA no es el guardián del proceso, es la conciencia del sistema.
El objetivo no es encontrar errores, sino crear las condiciones para que no existan. Y eso solo puede lograrse si el equipo de calidad tiene voz, visibilidad y poder de influencia reales en cada etapa del ciclo de desarrollo.
Porque la calidad no se impone: se construye cuando el sistema te deja hacerlo.