jueves, 31 de julio de 2014

En testing también debemos gestionar los cambios


Por Nadia Soledad Cavalleri

Software Configuration Management (SCM) es una disciplina de la ingeniería de software que comprende el conjunto de actividades necesarias para identificar, administrar y controlar todos los elementos que constituyen un software, sus cambios y sus relaciones, definiendo mecanismos para gestionar las diferentes configuraciones y posibilitar la reproducción de cualquiera de éstas.

Cuando hablamos de SCM, en lo primero que tendemos a pensar, es en su aplicación a equipos, ambientes y prácticas de desarrollo. Probablemente, esto se deba a que SCM emergió como disciplina enfocada en la programación, sin cubrir otros aspectos del proceso de desarrollo de software. Pese a esto, debemos tomar dimensión de la importancia que SCM tiene en los equipos, ambientes y prácticas de testing.

Repasando estos tres aspectos, nos encontramos con que los equipos tradicionales de pruebas están conformados por diferentes roles, en general, un gerente o líder de pruebas, algunos analistas, diseñadores, automatizadores, testers, y por qué no, algunos otros colaboradores.

Cuando hablamos de ambientes de pruebas, nos referimos a las configuraciones y los artefactos. Entendiendo por configuraciones, al conjunto de hardware, software, base de datos, sistemas operativos, redes y permisos y, por artefactos, a los productos de las actividades, tales como, planes de prueba, casos de prueba, scripts, logs, mejoras, bugs y reportes.

Siguiendo las buenas prácticas de SCM, deberíamos identificar aquellos ítems propensos a cambiar. Todos los artefactos mencionados tienen esa cualidad ya que están fuertemente relacionados con productos de otras disciplinas, como análisis y desarrollo, que también cambian permanentemente. Por ejemplo, el plan de pruebas está directamente relacionado con el plan del proyecto, los casos de prueba dependen de los requerimientos o de la especificación de casos de uso, los script de pruebas y los logs de sus ejecuciones están asociados a una versión determinada del build así como los bugs son reportados y resueltos en versiones específicas. Entonces, si el plan del proyecto, las especificaciones y el software pueden cambiar ¿Por qué no va a cambiar su par asociado en testing?

A pesar de que la configuración parece la parte más estática, también es susceptible de cambios, por ejemplo, por la instalación de parches, la migración hacia diferentes versiones, la creación de usuarios, la asignación de roles, la modificación de permisos, etc. Todos estos son ejemplos de situaciones con las que nos topamos a diario y que evidencian que en testing también ocurren cambios y, por lo tanto, también hay que gestionarlos.

Pero SCM no implica solamente gestionar los cambios con un controlador de versiones. Su objetivo es un poco más ambicioso. Cuando hablamos de SCM también nos estamos refiriendo al trabajo en paralelo, a la posibilidad de restaurar configuraciones previas y a mantener la trazabilidad entre los artefactos, entre otras cosas.

La aplicación de todas estas prácticas es tan indispensable en testing como lo es en desarrollo. Por ejemplo, al probar, también trabajamos de manera concurrente, quizá porque mientras un miembro del equipo está diseñando un caso de prueba otro está ejecutando o quizá porque tenemos dos o más automatizadores que están desarrollando sus scripts al mismo tiempo. En este caso, los automatizadores comparten el código fuente utilizado para automatizar las pruebas de la misma manera que los desarrolladores comparten el código de la aplicación que están construyendo. Poder volver a una versión anterior, a nivel de configuración y no solo de código, también puede ser necesario si tenemos que reproducir un bug en la misma versión y configuración del software en la que fue detectado.

La trazabilidad no es un tema menor. Los productos de testing están asociados con productos generados por otras disciplinas. En el medio de los cambios, la trazabilidad es extremadamente importante porque nos permite mantener la integridad de los modelos, datos y documentación. Además nos ayuda a identificar unívocamente las pruebas asociadas a una versión de la aplicación o de cualquier otro artefacto.

Queda claro entonces que si reconocemos la importancia de SCM en los equipos, ambientes y prácticas de desarrollo debemos otorgarle el mismo peso a los equipos, ambientes y prácticas de testing porque tienen un modo similar de funcionamiento y, a pesar de que ambos equipos trabajen con diferentes artefactos, tienen que gestionar temas de similar envergadura.