menu_superior

LA CALIDAD NO ES COMO PONER AZÚCAR AL CAFÉ

cafeLa frase brillante que da título a este post, no es mía, es de Javier Garzás, a quien se la he escuchado más de una vez. Me gusta lo de “la calidad no es como poner azúcar al café” por lo lo gráfica que es: la calidad no es algo que se añade al final, es algo que forma parte del proceso, es la forma de hacer. Bueno, me gusta por eso y por que estoy totalmente de acuerdo.

Hay quien tiende a considerar la construcción de software como un proceso, el testing como otro proceso, el QA (aseguramiento de la calidad) como otro, etc. En el mejor de los casos corren casi en paralelo, pero son considerados procesos independientes. Yo no estoy de acuerdo con esto, mi visión es que la construcción de software es una tarea muy compleja que integra procesos (construcción, testing y QA) que interactúan y que no son independientes.

test often, test early

En lo que respecta al testing, es un estándar conocido universalmente que los defectos son más caros de resolver cuanto más tarde se detecten. La idea es que el testing no sólo es ejecutar pruebas, sino que supone también participar en el análisis de requisitos para contribuir a afinar éstos lo máximo posible ya que son el origen de las pruebas. Es decir, los requisitos se pueden analizar y refinar para convertirlos en código y para convertirlos en pruebas, si el análisis es “compartido”, se enriquece el código y se enriquecen las pruebas. Es así de sencillo.

análisis estático de código

El análisis estático de código consiste en someter el código del software a una revisión de acuerdo con unas reglas o unas buenas prácticas. Lo recomiendo por que es una tarea que se hace automáticamente (sin consumir grandes recursos) y por que en organizaciones o en equipos donde no hay implantada una cultura de calidad da una imagen muy fidedigna de los defectos de construcción del código. Además de todo esto, es una de las primeras barreras para filtrar errores grandes, que con toda seguridad se detectarán más adelante y que, con toda seguridad serán más caros de solucionar.

profiling de aplicaciones

Otra forma de enriquecer el desarrollo a través de las pruebas es hacer un profiling, es decir, someter los módulos de la aplicación a pruebas de rendimiento. Estas pruebas aportan una visión técnica de la aplicación, evitando encerrarnos en la pura funcionalidad. Ejecutar módulos de la aplicación a través de scripts nos permite optimizar los accesos a bases de datos, verificar estrategias de caché, gestionar el uso de los recursos del sistema… Abre un mundo de posibilidades para mejorar la estructura interna del software por que los equipos de desarrollo van a disponer de información y van a poder usarla para optimizar no solo su código, si no su diseño de la aplicación componente a componente.

pruebas funcionales y técnicas de sistema

Obviamente, por muchas pruebas que hayamos hecho antes, nada sustituye a las pruebas funcionales y técnicas con toda la aplicación integrada. En primer lugar por un tema de integración, por muy bien que funcionen los módulos individualmente, nada garantiza que la integración esté libre de defectos. En segundo lugar por que hay que ver hasta dónde se cumplen las expectativas del usuario (pruebas de aceptación) o cómo interactúa con la infraestructura (pruebas de dimensionamiento).

En resumen, que la implementación de pruebas y prácticas de calidad en fases tempranas no debe ser una mera frase hecha por que la construcción de software debe ser un proceso integrado en el que el equipo de calidad, el de pruebas y el de desarrollo interactuen desde el primer momento para construir un producto software de la máxima calidad.

, , , ,

Comments are closed.