Cuando, en Gerencia de Proyectos, se habla de Calidad, nos referimos a cumplir con los requerimientos y necesidades del cliente, dentro del Alcance establecido, pero también se trata de precisión y veracidad. Precisión se relaciona con la consistencia de los resultados y veracidad con el resultado en sí, qué tan cercano a la realidad, al deber ser, se encuentra la solución desarrollada.

La Calidad en un Sistema Web tiene dos caras. Por lo general hay una de ellas que no es fácilmente visible y requiere de una evaluación más detallada y de ejecutores más conscientes de la importancia presente y futura de códigos fuentes bien elaborados. Presente por la salud del proyecto y futura por la salud del mantenimiento durante la operatividad.

Hay que tener muy presente que el cliente no posee, necesariamente conocimientos técnicos y las personas que elaboran las pruebas de certificación del producto son usuarios, y como tal hacen revisión del funcionamiento, muy probablemente con datos no reales y en un escenario que tampoco se ajusta al “día a día” del uso que debe darse a éste cuando se encuentre operacional.

Es por ello que cuando se trata de evaluar Calidad en los Sistemas que desarrollamos, no debemos dejar la responsabilidad de las pruebas del lado del cliente. La responsabilidad mayor del Aseguramiento de la Calidad se encuentra del lado del equipo de desarrollo, que no está formado sólo por los programadores, aclaro.

Por otra parte, la Gestión de Calidad es un proceso continuo que nos ayuda a mitigar riesgos y a evitar re-trabajo. Es por ello que las actividades que se deben llevar a cabo para ello se incluyen en la Planificación del Proyecto.

Es cierto que estas actividades incrementan los tiempos de ejecución en el plan, pero hay que tomar en cuenta que previenen los incrementos en tiempos de ejecución fuera del plan y por ende, los costos no considerados.

La acción clave es “probar”, palabra sencilla que bien analizada se expande en muchas más e incluiré algunas metáforas:

No dejar que los documentos se llenen de polvo.Tener siempre presente los requerimientos especificados y cualquier cambio sobre estos que se haya aprobado. El documento de especificaciones es la guía de viaje del programador.

• Recorrer el camino sin pasar desapercibidos los detalles. No dejar para “después”. Realizar pruebas durante el desarrollo basadas en un plan que contemple los escenarios reales y posibles. Es necesario documentar los resultados y acciones correctivas. Aparece acá otra clave “no asumir”.
• Ver el objeto desde lejos para ver el todo. Hacer una corrección no sólo afecta el módulo que se está probando. Por lo general los Sistemas están formados por partes interrelacionadas, al menos es parte de su etimología, por lo que alterar una parte puede afectar otras. Es por ello que debemos estar al tanto de qué partes se interrelacionan para hacer pruebas posteriores a cambios.
• Luego de las partes, no olvidemos el todo. Lo que llamamos comúnmente Pruebas Integrales, se refiere a que luego de asegurarnos de que cada módulo funciona en las pruebas individuales, debemos asegurarnos de que el Sistema, los módulos en conjunto, funcionan.
• Efectividad y Eficiencia.Lo más seguro es que el cliente se fije más en la efectividad en algunos escenarios, sin embargo, en el mundo de la tecnología sabemos cuán valioso es que un Sistema sea eficiente. Efectividad – que funcione y dé los resultados esperados. Eficiencia – que esos resultados los dé en un buen tiempo. Con buen tiempo me refiero a que se aprovechen los recursos de procesamiento y memoria adecuadamente, valiéndose de las bondades del lenguaje de programación con el que se esté trabajando.
• El cocinero luego de varias pruebas tiene el paladar cansado y ya no saborea. Finalmente se necesita que un equipo de personas no involucradas en la programación, y con ayuda de su experiencia técnica y la documentación del proyecto, realice pruebas integrales del Sistema. Es sólo luego de esta actividad, y por supuesto de que se certifique que el producto pasa con éxito los chequeos de calidad – probablemente de más de un ciclo de corrección-pruebas, que se puede hacer la entrega al Cliente. Nos acerca a la obtención de un cliente satisfecho y los méritos de un buen trabajo a todo el equipo que participó en su desarrollo.

El tiempo que tomemos para ejecutar todo lo mencionado no es un gasto, es una inversión. Y sólo mencioné lo que respecta a las acciones por parte del proveedor del servicio de desarrollo del Sistema, podría generar otras líneas para dejar algunas lecciones en cuanto a la responsabilidad del cliente – quien debe tener el mayor conocimiento del objetivo del producto para su negocio o fin, no obstante, es otro tema.

Esto es sólo un breve resumen acerca del tema, pues sobre Calidad podemos encontrar mucho material teórico y normas. Con este artículo intento sólo dejar una semilla de consciencia a programadores, líderes y gerentes de proyectos tecnológicos.

“Una de las grandes desventajas de la prisa es que lleva demasiado tiempo.” Gilbert Keith Chesterton