Integración continua + Build&Deploy = Agilidad en la fase de pruebas 

(Puedes leerlo en 3 minutos)]

Cada día oímos hablar con más frecuencia de la integración continua y sus beneficios, pero ¿Qué es la Integración continua? ¿Por qué debo integrar mi código de forma continua? ¿Cómo afecta la integración continua a las pruebas que está realizando el equipo de QA?

Vayamos por partes, antes de nada debemos entender que significa Integración continua. Según su creador, Martin Flower, Integración continua se define como:

“Práctica de desarrollo software donde los miembros del equipo integran su trabajo frecuentemente, al menos una vez al día. Cada integración se verifica con un Build automático (que incluye la ejecución de pruebas) para detectar errores de integración tan pronto como sea posible.”

Esta práctica surge como solución al eterno problema de integración surgido durante los últimos días de cualquier proyecto de desarrollo, en el que hayan colaborado diversos desarrolladores. Y es que  está más que demostrado, que si posponemos la tarea de integración para el final, la integración se vuelve compleja y pesada, ya que es necesario encajar múltiples cambios que pueden ensamblar de forma armoniosa O NO.

Es esa gran posibilidad de que NO encajen la que puede retrasar el proyecto, justo en ese momento en el que no hay tiempo.  En ese punto surge una cuestión, ¿posponemos la salida a producción o se reduce el tiempo de pruebas? La respuesta suele ser recurrente: se reduce el tiempo de pruebas.

Por ello, trabajar con un control de versiones que facilite a los desarrolladores hacer entregas continuas permite realizar compilaciones de forma periódica, y ejecutar sobre el Build generado una batería de pruebas automatizadas garantizando determinados niveles de calidad.

Después, si todo está correcto, el equipo de calidad puede comenzar a realizar sus pruebas sobre esta nueva versión, y obviar la versión anterior pues la versión anterior ya no existirá más, no llegará a producción.

Si vemos esta evolución de forma cíclica, por ejemplo de forma diaria, pudiéramos pensar que QA no puede garantizar la calidad del producto porque no ha probado por completo ninguna versión. Sin embargo, ocurre justo lo contrario, QA puede garantizar mucho mejor la calidad del producto ya que ha probado el producto a medida que ha ido evolucionando, por tanto la complejidad de las pruebas y la profundidad de estas ha ido aumentando a medida que el código ha ido creciendo.

Siempre hay quien piensa pero… si se probó el modulo A con la versión 1,  y cuando me toca probar el modulo B tengo la versión 2, ¿cómo puedo garantizar que el módulo A sigue funcionando correctamente? ¡Fácil! Tan sencillo de explicar cómo que, difícilmente el modulo A y el modulo B son completamente independientes, en un porcentaje muy muy alto, ambos módulos están interrelacionados, por lo que probando el modulo B deberé pasar por alguna pantalla del módulo A  o internamente se llamará a la funciones del módulo A, lo que permite estar constantemente garantizando la correcta funcionalidad del sistema en conjunto.

¿Y cuándo se debe hacer Deploy de la nueva versión en ambiente de QA? Es aquí donde reside el quid de la cuestión, ya que esto siempre depende de la cantidad de ambientes de prueba que tenga el equipo de QA, de los proyectos bajo prueba de forma simultánea y de la prueba que se esté realizando en el momento en que sea necesario el Deploy,  pero de lo que no hay duda es que el Deploy de los ambientes de QA debe ser controlado por el equipo de QA, ya que de lo contrario, se generan enormes pérdidas de tiempo entre el momento de solicitar un nuevo Deploy y la implementación de este.

Por ejemplo, para verificar un defecto bloqueante que ha sido encontrado durante la primera hora de ejecución de pruebas y que el desarrollador ha podido resolver en 5  minutos, se ha realizado la solicitud de Deploy al equipo de infraestructura, que por estar resolviendo incidentes de producción no podrá realizar el Deploy hasta mañana. Mientras en QA, un grupo de 4 testers estarán parados durante el resto del día.

Si QA tuviera el control del Deploy sobre sus propios ambientes, incluso de la solicitud de Build, el desarrollador hubiera resuelto el problema en 5 min,  el mismo desarrollador o un tester hubiera podido solicitar el Build y posteriormente hacer Deploy en ambiente de QA, y los 4 testers hubieran podido continuar su trabajo con normalidad.

En mis años de experiencia como QA, he podido comprobar que la agilidad de un equipo depende inevitablemente de dos factores:

1. La velocidad de respuesta a los cambios.
2. Conceder el “poder” de realizar cambios a aquellas personas que realmente se van a beneficiar de ellos. (Eliminar las dependencias innecesarias)

De lo contrario, las personas sienten que pierden el tiempo,  pierden el “porqué” de lo que están haciendo, la responsabilidad se diluye y los proyectos se enquistan.

Si te estás planteando contratar nuevos recursos para salir a producción más rápido, pregúntate primero si el proceso definido te permite sacar el máximo rendimiento de tu equipo y si cuentas con las herramientas necesarias. Más manos con las mismas herramientas no podrán construir más rápido.

María Villar Gallego
Consultor de Calidad de Software