Lamentablemente el Testing de hoy fue un éxito rotundo con los módulos puestos a pruebas de verificación, los cuales dan fallo de severidad INVALIDANTE.
Este tipo de reportes suele ser típico en la mayoría de las organizaciones dedicadas a la construcción de software y por mucho esfuerzo que se hace en introducir mejoras en los procesos a niveles de mejoras en las tomas de requerimiento, análisis, diseño y desarrollo, no se logra superar ciertas barreras que tal vez son de otra índole.
Lo que pude ver y analizas hasta ahora, esta relacionado a una grave falencia en el proceso de integración, quizás en su método, tal vez en su ambiente o en ambos, en el área de Desarrollo. ¿Por que digo esto?
Los desarrolladores juran que los fallos que resultan en Testing no se presentan en sus ambientes de desarrollo y no hay dudas de que ellos entregan los componentes con las pruebas ejecutadas que el entorno de diseño les permite, más las limitaciones que cada quien tiene en su PSP. Luego pasan a otro componente y lo entregan, siempre cumpliendo el mismo circuito.
Finalmente se integra todo y se versiona el sistema para ser entregado a SQA, quien genera los ciclos de verificaciones funcionales y donde a las primeras surgen fallos.
Esto evidencia claramente que no hay Pruebas de Integración o las mismas son muy escuetas y es por eso que el primer ciclo de “Pruebas Funcionales” que ejecuta Testing es considerado por mí como “Pruebas de Integración”.
Lo lamentable y donde se evidencia fuertemente la falta del ambiente de integración, es cuando el defecto se hace persistente y es reportado dos o tres veces sin que realmente se solucione.
Una solución posible según mi óptica, sería que se formen los ciclos de desarrollo lo suficientemente chicos como para ser integrados N veces cada vez que ese ciclo finaliza, es decir cada vez que los desarrolladores entregan los N componentes del ciclo. Así pues se los integra y los desarrolladores mismos puedan ejecutar las pruebas de integración (funcionales) y detectar los fallos lo antes posible sin tener que considerar su trabajo finalizado hasta que superen esa etapa.
Esto no implica que cada ciclo de integración deba entregarse a Testing, sino el costo de las pruebas sería muy alto, sin embargo ya tendríamos predefinidos en los cronogramas del proyecto los ciclos de pruebas funcionales para integraciones más grandes, modulares y que representen una versión del sistema en si misma.
Sin duda duda que esta referencia y análisis lo hago para ambientes de desarrollo donde existe poco y nada de automatización y no se puede trabajar con Integración Continua, siendo más primitiva la metodología de generación de versiones, aún con potentes IDES, como es el caso de Lotus Notes.
