Hola mi estimado colega del mundo de desarrollo, hoy quiero decirte por qué la calidad no es un gasto, sino la forma más efectiva de ahorrar en desarrollo, y te lo quiero explicar rapidamente en este post. Durante años, muchas empresas han cometido el mismo error conceptual: confundir testing con calidad, y ese error no es inocente, cuesta dinero, mucho dinero.
En el post anterior hablaba de por qué no siempre contratar más testers es la solución cuando el producto crece. Ese artículo generó bastante conversación porque toca un punto sensible: la tendencia de resolver problemas estructurales agregando más personas al final del proceso.
Pero hoy quiero ir más profundo, y es que el verdadero problema no es cuántos testers tienes, sino creer que calidad y testing son lo mismo. Spolier: ¡no lo son!.
El error que sigue repitiéndose
En el libro How Google Tests Software, hay una idea que me parece fundamental: la calidad no puede “probarse al final”. Testing no es un departamento que inspecciona lo que otros hicieron. En Google, desarrollo y testing están mezclados hasta volverse casi indistinguibles. La calidad no es una etapa; es una propiedad del sistema.
Sin embargo, en muchas organizaciones sigue existiendo esta secuencia mental: primero construimos -> después probamos -> y , si falla, corregimos.
Y cuando los errores cuestan demasiado, la conclusión suele ser: “estamos gastando mucho en desarrollo”. Aquí es donde quiero compartir algo que viví personalmente.
Cuando intentaron ahorrar eliminando el desarrollo
Trabajé con una empresa que llegó a la conclusión de que su equipo de desarrollo era demasiado costoso. El mantenimiento era complejo, los cambios tardaban, había errores recurrentes y el presupuesto parecía crecer cada trimestre.
La solución que encontraron fue aparentemente brillante: eliminar gran parte del desarrollo tradicional y adoptar una herramienta low-code / no-code que prometía resolverlo todo sin necesidad de un equipo técnico robusto.
La promesa era seductora: menos código, menos errores, menos costos. Pero, lo que ocurrió fue exactamente lo contrario, la herramienta era costosa. Mucho más costosa de lo que habían proyectado. Además, nadie sabía usarla correctamente. El conocimiento técnico seguía siendo necesario, solo que ahora estaba oculto detrás de una interfaz visual. Las limitaciones de la plataforma comenzaron a aparecer rápidamente, las personalizaciones eran difíciles y las integraciones no eran tan simples como el proveedor había prometido.
El resultado fue inevitable: tuvieron que volver a contratar un equipo de desarrollo, por supuesto con un nuevo equipo de QA. Sin embargo, para sorpresa de nadie, seguían teniendo los mismos problemas, porque el problema nunca fue el código, ni la herramienta, ni el tamaño del equipo. El problema era que la calidad seguía tratándose como una etapa, no como una forma de trabajo.
Calidad como prevención, no como inspección
Cuando estaba escribiendo Shift Left Testing en Pocas Páginas, algo se volvió cada vez más claro para mí: la calidad es, en esencia, una estrategia de ahorro.
Cada error detectado tarde cuesta exponencialmente más que uno prevenido temprano. Cada retrabajo implica tiempo duplicado. Cada incidente en producción impacta reputación, soporte, clientes y energía del equipo. Cuando se acumulan, esos costos invisibles superan con creces el salario de cualquier ingeniero.
Pero esto solo se entiende cuando dejamos de pensar que calidad es igual a testing. Te explico rápidamente, mientras el testing es una actividad que detecta y puede medir el daño, calidad es una cultura de trabajo, de prevención donde se evitan que los daños ocurran, y cuando un equipo internaliza eso, cambia completamente su dinámica. Las conversaciones dejan de girar alrededor de “¿quién no encontró el error?” y comienzan a enfocarse en “¿cómo diseñamos para que esto no vuelva a pasar?”.
El verdadero ahorro
La empresa de la que hablo no comenzó a estabilizarse hasta que implementó algo mucho más simple —y mucho más difícil— que cambiar de herramienta o de proveedores.
Implementó un sistema de desarrollo donde la calidad no era un checkpoint, sino una práctica integrada. Donde los desarrolladores asumían la responsabilidad de sus pruebas. Donde el diseño contemplaba riesgos desde el inicio. Donde QA no era un filtro final, sino un socio estratégico desde el principio.
Porque cuando la calidad es una forma de trabajo, el retrabajo disminuye. Las discusiones improductivas disminuyen. Los incendios en producción disminuyen. Entonces, la confianza aumenta y todo el desarrollo se vuelve más barato porque disminuye el retrabajo y los errores de ultimo minuto.
El mito del “ahorro rápido”
Muchas empresas creen que ahorrar significa reducir equipo técnico, externalizar o adoptar herramientas que prometen simplificar la complejidad.
Pero el software es complejo por naturaleza. No se vuelve simple porque cambiemos de plataforma. Lo que cambia es dónde se esconde esa complejidad y si no existe un buen proceso de calidad, la complejidad se transformará en errores. Y los errores siempre son más costosos que la prevención.
Por eso insisto tanto en esto: calidad no es un lujo. Es una estrategia financiera.
No es testing. Es mentalidad.
El libro de Google muestra algo muy cierto: puedes tener menos testers que otras compañías y aún así mantener productos masivos, complejos y utilizados por millones de personas. Pero eso solo funciona cuando la responsabilidad está distribuida y la calidad está integrada al desarrollo.
Si en el post anterior hablábamos de por qué no deberías contratar más testers automáticamente, hoy el mensaje es complementario: no reduzcas costos sacrificando calidad estructural.
Porque lo que parece ahorro en el corto plazo, suele convertirse en deuda en el largo plazo.
Cuando estaba escribiendo mi libro Shift Left Testing en Pocas Páginas entendí algo que ahora veo con más claridad que nunca: la calidad siempre será más barata que el caos. La pregunta no es cuánto cuesta implementar un buen proceso.
La pregunta es cuánto te está costando no tenerlo.
