Podcast: Play in new window | Download
Suscribirse: Apple Podcasts | Spotify | Email | RSS
A lo largo de mi carrera profesional he escuchado lo siguiente en diferentes ámbitos:
“Es normal que el software tenga defectos” o su variante “El software siempre tendrá defectos”
No es normal.
Ustedes no andarían por un puente vehicular, del que saben que tiene defectos. No aceptarían un coche defectuoso o aceptarían una casa con múltiples defectos. Sin embargo, como decía mi profesor Carlos Montes de Oca “el software es tan necesario que le perdonamos que sea malo”.
Se vuelve el cuento de nunca acabar. En general, las organizaciones con este problema dedican entre 65% y 85% del tiempo solo a esta actividad en lugar de producir funciones nuevas, o dedican equipos completos solamente a esto. Algunas organizaciones, con algo de cinismo, la incluyen en los contratos como “fase de estabilización”, que solo es trasladarle el costo al cliente por la mala calidad del desarrollo.
A continuación te presento razones por las que se presenta este comportamiento en organizaciones de software.
No hay cultura de la calidad
Cuando pregunto “¿Quién es responsable de la calidad del software en la organizacion?” suelen responder:
- El equipo de QA
- La fase de Testing
Es decir, asumen que la calidad es “algo que sucede en un momento del tiempo” o es una actividad concreta, en lugar de ser un trabajo continuo.
Esto genera una forma de trabajo donde la responsabilidad se diluye. El equipo de desarrollo espera que QA sea quienes encuentren los defectos, y QA espera que desarrollo esté atento a los ciclos de pruebas para reparar cuanto antes. Además, genera conflicto y fricción, sobre todo si ambos grupos solo se involucran en su fase y no colaboran en el resto del ciclo.
Presiones para entregar a Testing rápido
Esto es consecuencia de la pobre cultura de la calidad. Project Managers, Gerentes y Líderes saben, por la experiencia anterior, que la fase con más costo será testing. Por lo tanto, concluyen que una forma de acortarla es iniciarla rápidamente. Presionan para entregar y empezar a probar, en lugar de promover que se aseguren de que lo que entregan aprobará las pruebas rápidamente. El resultado siempre es el opuesto al que esperan: mientras más defectos encuentran, más defectos hay por arreglar.
Watts Humphrey lo dice en su libro “A discipline for software engineering”: “Al llegar a testing, la calidad ya se encuentra dentro del producto”. William Lewis lo remata así: “No se puede agregar calidad a un producto ya terminado”
