Imaginemos que somos mecánicos y tenemos un coche. Le estamos arreglando un faro, un faro que se ha roto o que alumbra poco o tiene un golpe. Ya tenemos la pieza de recambio, quitamos el faro antiguo y le ponemos el nuevo. Acto seguido ¿qué debemos hacer? ¿llamamos al dueño a que lo recoja directamente?
Tenemos mucha prisa porque estamos reparando una cosa tras otra. Nos han hecho una llamada de última hora y no nos hemos dado cuenta de que no hemos hecho las conexiones correctamente. Llega el dueño, va a arrancar y revienta un fusible porque no hemos hecho las conexiones bien. Ahora es cuando se nos cae la cara de vergüenza porque ni siquiera hemos arrancado el coche a ver si funcionaba el nuevo faro..
En el desarrollo de software es de vital importancia hacer los programas rápidamente, entregarlos en el tiempo y forma, además de que deben funcionar bien. Estas prisas nos pueden jugar malas pasadas pero hay soluciones profesionales, formas de trabajo para controlar o evitar estos problemas.
Pruebas unitarias y funcionales
Esto que le ha pasado al mecánico con prisas es lo mismo que nos puede pasar si entregamos un programa sin haber hecho las pruebas pertinentes. En el mundo del software existen, además de las pruebas manuales, formas de trabajo en las que se pueden tener una batería de pruebas automatizadas que prueben el buen funcionamiento de una aplicación.
Por ejemplo, estoy empezando el desarrollo de un proyecto Open Source y tenemos ya el inicio de unas pruebas automatizadas. Los resultados de cobertura del código se pueden ver aquí:
Esto es el resultado de un navegador que simula un usuario que va probando las diferentes secciones de una aplicación web (programa web). El resultado mostrado es el Code Coverage, que significa cobertura del código. Es decir, es el porcentaje del programa que se ha probado navegando automáticamente por él sin que se funda ningún fusible 😉
Para el que quiera curiosear más en el programa que cito, el repositorio público está aquí:
Garantía de buen funcionamiento
Un nivel adecuado de cobertura oscila desde el 70% al 100%. Es muy tedioso alcanzar el 100%, y dependiendo de la naturaleza del software con un 70% – 80% será bastante. Pero si de ello dependen sistemas de vital importancia es aconsejable aumentar la cobertura al 100% o casi.
Esto a su vez evita que a medida que se va ampliando un programa, pasen desapercibidos errores nuevos al introducir nuevas mejoras en las aplicaciones web. Por esto es siempre bueno pedir los resultados de las pruebas automatizadas.
Integración Contínua (CI, Continuous Integration)
La integración continua es el sistema por el que todas estas pruebas automáticas se lanzan continuamente dando reportes de estado y alarmas para su supervisión.
Es un buen trabajo montar este sistema, pero una vez montado, la persona o el equipo de desarrollo se centrarán en desarrollar las nuevas funcionalidades, o en mantener el software.
Todo estará centralizado, organizado desde un punto desde el que, cada cierto tiempo se lanzarán automáticamente toda esta serie de pruebas automatizadas. También se suelen hacer a ciertas horas del día, o por la noche. Se podrán ver los resultados, con todo tipo de estadísticas. Se pueden automatizar análisis para buscar posibles problemas futuros, códigos fuentes duplicados. Se puede estudiar la mantenibilidad de un programa, entre otras cosas..
Para el proyecto anterior que cito, junto con las pruebas también se generan reportes de peligros o chequeos de estilo del código fuente:
También la documentación de la aplicación:
Aquí, el equipo o persona encargada de desarrollar, se podrá centrar en el análisis y programación puramente. Siempre que el sistema de Integración Contínua no de señales de alarma simplemente se puede continuar el trabajo, pudiendo dormir tranquilo.
Entregando
Aquí no termina todo, ahora tenemos un programa. Un programa que no da fallos, ha pasado las pruebas, tenemos alto porcentaje de cobertura, etc.. pero quedan otras tareas.
Una cosa es que el programa no de errores, y otra que haga lo que realmente tiene que hacer. Aquí es donde empezarán las pruebas de usuario, mantenimientos varios. Las llamadas pruebas de estrés, donde se mide la capacidad que tiene un programa. Es como si llevamos al circuito de carreras al coche con el que estamos trabajando para probarlo, damos unas cuantas vueltas viendo cómo va todo, su velocidad, frenada, etc.. Ahora sí que estaremos seguros al entregar el coche de que todo va a ir bien, o casi seguros.
Se quedan en el aire muchos conceptos pero no quiero extenderme demasiado y así tengo tema para otros posts 😉
Un saludo.
