Software Quality

En este artículo se comenta la importancia de la figura de un Chief Software Quality Officer en las organizaciones. Para muchas empresas esto es inviable, suena a entelequia pero no debería serlo para las empresas que se dediquen al desarrollo de software o estén involucradas.

Considero que se descuida mucho la calidad en los desarrollos de software. Por supuesto, nos llenemos la boca de palabras sobre la calidad y todo el mundo es muy consciente de su importancia. ¿Qué empresa no tiene una metodología en la que se detalla los procedimientos para asegurar la calidad de sus desarrollos?. No hay oferta (copy & paste) que se precia que no incluye una referencia a estos procedimientos.

En la práctica, qué ocurre: la fase de pruebas es muy deficiente, no se ponen medios ni recursos. Para mí es una de las fases más importantes, críticas diría yo.

Un responsable de Marketing es consciente de la importancia de la fase de pruebas antes de lanzar un producto al mercado, no creo que le agrade la medida de tener que retirar su producto del mercado debido a fallos. Porque en mayor o menor grado afecta a la percepción de su productos por parte de sus clientes y clientes potenciales.

La misma importancia debería de darse para un producto de software desarrollado ad-hoc para un cliente determinado que aunque no va a tener una comercialización si que tiene un grupo de "clientes". Los usuarios siempre son más reticentes al cambio, si la aplicación esta llena de defectos funcionales y errores de programación ya tienen un buen argumento para justificar su predisposición negativa a la aplicación. Y aunque los defectos no sean críticos (que no es excusa) es suficiente para que se escriban ríos de tinta sobre lo mala que es la aplicación y al final cualquier cosa que ocurra se le echa la culpa al nuevo aplicativo. Frecuentemente que se confunden modificaciones en los procedimientos de trabajo con funcionalidad de la aplicación; la nueva funcionalidad existe porque se ha modificado la operativa, no es que la funcionalidad modifique la operativa. No es lo mismo. Además hay que considerar todo lo que obliga (esfuerzo, costes, riesgos) tener que modificar aplicaciones que están ya en producción.

De este artículo me quedo:
"Create a cross-functional task force that focuses on the role of QA software development. This insures that quality is discussed with members of the business unit, not just the development team. Educate the application development and deployment teams on the role of QA in their success. With sufficient education, QA members will be consulted early and often. Insure that QA management is part of the team determining the new vision of applications. [....] Educate business management on the importance of quality testing. "