Pruebas proactivas, tests de integración y equipos de tests

Hay un dicho que suele decir que un poco de prevención vale más que un mucho de curación. Personalmente, este dicho lo aplicaría al mundo de las pruebas de software para crear el concepto de pruebas proactivas.

¿Qué es una prueba proactiva? : Una prueba proactiva es aquella cualquier prueba que no tendríamos obligatoriamente que realizar pero que nos permite adelantarnos a los acontecimientos. La principal ventaja de las pruebas proactivas es que nos permiten crear software mucho más sólido previniendo problemas no esperados desde un punto de vista unitario, integracional o funcional.

Ejemplos de pruebas no proactivas serían aquellas que es obligatorio realizar para mantener un software saludable, como los tests unitarios, tests de integración o tests funcionales.

Ejemplos de pruebas proactivas pueden ser los tests de rendimiento, tests de carga y tests de integración.

Ahora bien, si miráis la lista veréis que los tests de integración están tanto en la lista de pruebas proactivas como en la lista de pruebas obligatorias. ¿Por qué? El problema es que los tests de integración yacen en el limbo de los tests.

En una empresa normalmente tenemos diferentes equipos de desarrollo que trabajan con diferentes componentes. Los desarrolladores de estos equipos tienen la responsabilidad de ofrecer componentes lo suficientemente probados a través de tests unitarios. Por otra parte, hay muchas empresas que tienen un equipo completo de testers que se encargarán de realizar todas las pruebas funcionales de cara al usuario final.

El punto más peliagudo es el de los tests de integración. Los tests de integración se encargan de comprobar que los diferentes componentes de nuestro sistema funcionan como es debido, y que interactuan como se espera dentro de sistemas que imitan al entorno de producción que nos vamos a encontrar. Nótese que la palabra integrar aquí adquiere un significado algo ambiguo y se refiere tanto a integrar dos piezas de software que se deben comunicar entre sí, como a integrar esas piezas de software en un entorno de ejecución determinado.

¿Quién hace y cómo se hacen estas pruebas de integración? Sin lugar a dudas, lo ideal es mantener un equipo de desarrollo de tests de integración que se encargue de desplegar los componentes en un sistema similar al de producción y de probar la integración de estos componentes. Aquí es donde entra la proactividad. Estos equipos de producción deben realizar el test del producto olvidándose del usuario final. Esto permite eliminar la dependencia de los casos de uso y alcanzar una cobertura mucho mayor en nuestro software, ya que incluso aunque estuviésemos cubriendo el 100% de los casos de uso definidos en la arquitectura, la realidad es que probablemente los casos de uso no estan cubriendo el 100% de las acciones que nuestros usuarios realizarán.

El problema de mantener los tests de integración orientados al usuario final es que uno no puede realmente estar seguro de que su software es sólido y fiable. Es muy común por ejemplo en los entornos de tests el realizar las pruebas de integración utilizando robots web o robots de GUI, que se encargan de simular el comportamiento del usuario final. ¿Es esto una prueba de integración real entre componentes? No. Esto son pruebas funcionales, y nunca se deberían tratar como pruebas de integración. El problema es que se tratan como tales debido a falta de presupuesto para contratar equipos de test de integración, a falta de conocimiento por parte de los equipos de testing funcional o a falta de tiempo por parte de los desarrolladores para asumir semejante carga.

En resúmen, ponga un equipo de ejecución y creación de tests de integración en su vida y será mucho más feliz :-)