Pilares para construir software con calidad

En mi opinión hay 4 pilares básicos, no relacionados directamente con pruebas de software, análisis de código, ni otras tareas diarias de un equipo de QA, importantísimos para construir software con calidad. Hablando desde el punto de vista del proceso de construir software, gestionar correctamente los requisitos, los entornos, las versiones de nuestro código y las dependencias, supondrá una sólida base para construir software de calidad, más rápido y con un menor coste.

Gestión de requisitos

Decir que es importante tener una correcta gestión de requisitos parece una obviedad, pero la cruda realidad es que en muchos proyectos la gestión de requisitos es absolutamente nula, y la toma de requisitos se limita a que alguien transmita de viva voz lo que quiere a los desarrolladores, quienes posteriormente lo plasman en un nuevo desarrollo, que pasa a la fase de pruebas sin estar muy claro que es lo que esa nueva funcionalidad debe hacer. En ese momento el tester comienza a plantear al desarrollador qué es lo que debería ocurrir en los casos de prueba, y el desarrollador le dice como cree él que debe comportarse la funcionalidad en cada caso, ya que quién debería ejercer de product owner no lo hace realmente.

Resultado: Los requisitos los crea el equipo de pruebas una vez que la funcionalidad ya está hecha, y lo que se hace es definir cómo se comporta de hecho la funcionalidad, no cómo debería comportarse. No se hace una funcionalidad a partir de unos requisitos, sino que se hacen los requisitos a partir de la funcionalidad.

Gestión / Control de entornos

Podemos discutir sobre cuántos entornos son necesarios, pero está claro que debe haber un mínimo de entornos, y que estos deben estar debidamente controlados.

El software debe promocionar por los entornos, desde la máquina local del desarrollador que implementa la funcionalidad hasta el entorno de producción, pasando por los entornos que en cada caso hayamos decidido. Que el software pase de la máquina del desarrollador al entorno de producción, sin pasar antes por otros entornos dónde probar su integración con el sistema en todos los niveles, es una ruleta rusa. Ruleta rusa a la que en muchos casos se juega una y otra vez.

Control del código (control de versiones)

Otra obviedad. Hay que tener un estricto control de versiones. El caso es que en la vida real no es muy difícil encontrarse con equipos en los que no sólo no hay ningún tipo de control de versiones, sino que incluso se discute sobre la necesidad de versionar el software. Claro, luego te encuentras en producción un componente en distintos sitios, que en teoría deberían ser exactamente igual, pero que si comparas los 2 componentes binariamente te encuentras que se parecen como un huevo a una castaña.

Herramientas como git, convertido en un estándar en el desarrollo de software moderno, nos permiten llevar un perfecto control de versiones y, lo mejor, es gratuito y de código abierto.

Control de dependencias

En este caso me refiero a controlar las dependencias entre distintos componentes de nuestro sistema. Es decir, si para que un componente funcione, necesita de otro, debemos asegurarnos de que siempre subimos versiones compatibles.

Lo mismo ocurre si tenemos una actualización de un componente que requiere una modificación de base de datos, pero tenemos otro componente que con esa actualización en base de datos deja de funcionar correctamente. Es importante tener el control de qué componentes tiran de qué parámetros, para que actualizaciones en un sitio para un determinado componente no impidan el correcto funcionamiento de otro.

Esto aplica igualmente al caso de librerias incompatibles. Quizás en un momento dado actualizamos una libreria para obtener una serie de ventajas con esa actualización, pero olvidamos que otro componente de nuestro sistema no es capaz de trabajar con esa nueva versión.

En resumen:

• si en nuestros desarrollos somos capaces de controlar los requisitos, documentándolos, actualizándolos, añadiendo aclaraciones, y haciendo que sean un elemento dinámico,
• si controlamos los entornos, utilizando cada equipo el entorno que debe utilizar, y no el único que funciona,
• si cada versión de un componente es claramente identificable, y podemos volver atrás a versiones que sabemos que funcionan correctamente,
• si controlamos las dependecias entre los distintos componentes de nuestro software,

estaremos mucho más cerca de generar un software de mayor calidad.