Testeo

Las pruebas tienen su propia sección debido a su importancia. Siempre que se está diseñando o desarrollando una aplicación software o componente no trivial, una de las primeras cosas que se deben tener en cuenta es cómo las diferentes personas o grupos involucrados en el proceso de desarrollo van a poner a prueba su trabajo. Cualquier diseño que se produzca debe estar pensado para facilitar su testeo. Esto es de una importancia vital porque lo que tenemos que hacer es acortar, en la medida de lo posible, el circuito de retroalimentación (feedback) para el equipo de desarrollo. En palabras más sencillas, lo que esto significa es que si algo está roto o se rompe, cuanto antes nos enteremos del error, más barato será de corregir.

Al incorporar pruebas repetibles y bien documentadas que promuevan automatizarse por si mismas podemos reducir el tiempo que lleva detectar errores y al mismo tiempo incrementar las posibilidades de detectarlos. Reducimos, de esta forma, tanto el tiempo que conlleva como el riesgo involucrado en el proceso de desarrollo de software.

La inversión necesaria para implementar un conjunto de pruebas sólido depende en gran medida del tipo de proyecto y de donde este esté en el ciclo de vida. Para un proyecto en el inicio de la fase de diseño el coste de implementación es bajo e incluiría, por ejemplo, la selección y la configuración del framework de pruebas y herramientas, la capacitación de los desarrolladores (tanto en el uso del framework / instrumentos y la mentalidad de desarrollar con pruebas) y la formación del arquitecto / técnico principal en el diseño orientado a la testabilidad. El coste y la complejidad de la introducción de testeo se incrementa con el tiempo que lleve un proyecto en marcha, es difícil decir cuanto aumenta exactamente, pero depende de cosas como la calidad y el tamaño de la base de código, de la calidad de la documentación, del número de dependencias externas que tiene un sistema, de la arquitectura del sistema, de si los desarrolladores originales siguen en el proyecto, etc. En el pasado hemos tenido éxito en la incorporación de todo tipo de pruebas en proyectos en cualquier fases. La elección de incorporar un conjunto de pruebas se basa en el coste que implica mantener y modificar el sistema más su esperanza de vida contra el coste de implementar el conjunto pruebas deseado.

Si usted está comenzando un proyecto y quiere saber la mejor manera de testearlo, le podemos ayudar. Si está a medio camino de terminar un proyecto y le gustaría empezar a probar, le podemos ayudar. Si usted es un gerente o un cliente que está cansado de escuchar "El ámbito del proyecto es demasiado complicado para testear", "La base de datos es demasiado grande / complicada para que podamos escribir tests", "Los cambios rompen otras partes del software" o "El sistema tiene (demasiadas) dependencias externas por lo que necesitamos desplegar la aplicación para poder probar cualquier cosa", entonces podemos ayudarle. Lo que todas estas frases quieren decir realmente es que el sistema no ha sido diseñado para ser testeado y por eso algunos de sus elementos no pueden ser aislados y probados.

En nuestra opinión, todo el software debe poseer un conjunto de pruebas que se puedan ejecutar de forma individual, en conjunto o se puedan programar para ejecutarse automáticamente. En la mayoría de los lenguajes de programación modernos existen frameworks libres y otras herramientas que facilitan este tipo de pruebas y generan automáticamente informes de sus resultados. Las pruebas también ayudan a documentar las entrañas de un sistema y ayudan a aislar sus proyectos de los problemas asociados a tener mucho conocimiento específico de programación almacenado en la mente de unos pocos desarrolladores. Para un resumen de los tipos de pruebas de las que, en función del tipo de proyecto, usted podría estar aprovechandose, póngase en contacto con nosotros por favor.