Probamos, pero… contra qué nos comparamos?

Anteriormente comenté sobre nuestra misión como testers, sobre cómo podemos pensar qué probar, y sobre la relación entre los servicios de TI y nuestras actividades como testers.

Pero independientemente de nuestra misión, las características del servicio brindado, las técnicas de prueba específicas, no podemos dejar fuera de nuestras incumbencias la mejora de nuestros procesos.

Esa mejora, como ocurre en general con los procesos de mejora, implica
- entender qué y cómo lo hacemos,
- compararnos con algún modelo reconocido,
- analizar cómo nos impactan los gaps (las cosas que no hacemos o hacemos de manera distinta),
- decidir qué gaps interesa cerrar según su costo/beneficio,
- asignar prioridad a los gaps a cerrar,
- planificar y ejecutar las acciones para cerrarlos,
- evaluar cómo nos fue, y definir próximos pasos / ciclos de mejora.

Si bien este ciclo es claro, no siempre es claro contra qué compararnos.

Muchas veces hemos observado que quienes comienzan a probar sistemáticamente el software producido en sus organizaciones, no dejan de hacerlo, ya que se evidencian fácilmente los beneficios. Suele darse una secuencia de aplicación de prácticas similar a ésta:

En esta secuencia de escenarios, se van incorporando herramientas y buenas prácticas gradualmente, a la vez que se mejora la organización propiamente dicha, y se capacita a sus recursos formalmente. Hasta aquí, seguir trabajando en el proceso de mejora a prueba y error es una posibilidad, pero suele dar mejores resultados compararnos con modelos conocidos.

En el caso de las actividades de pruebas de software, el modelo de referencia es el TMM – Test Maturity Model, elaborado por Ilene Burnstein y sus colegas en el Illinois Institute of Technology hacia 2002.

TMM

Actualmente este modelo es impulsado por la TMMi Foundation - http://www.tmmifoundation.org/html/tmmiorg.html , y comprende cinco niveles de madurez, que complementan a los equivalentes del CMMi en lo relativo al proceso de pruebas.

En cada nivel, el modelo caracteriza las Metas (Goals), que son soportados por Submetas (Subgoals) y ATRs (Actividades, Tareas y Responsabilidades).

Los niveles de madurez descriptos son:

1. Inicial (Initial). Este nivel no tiene metas, y es aquél en el que la organización no hace nada específico o definido para probar su software. Puede probar algo, pero en forma ad-hoc y casi sin registración. La prueba no es considerada crítica, no separada del desarrollo propiamente dicho.

2. De Definición de Fases (Phase Definition). En este nivel aparecen metas específicas, relacionadas con separación de testing y debugging, planificación de pruebas e institucionalización de técnicas básicas de prueba.

3. De Integración (Integration). En este nivel, se espera que el proceso de prueba esté totalmente integrado con el ciclo de vida del desarrollo y la planificación de los proyectos.
Por lo tanto, las metas específicas se relacionan con establecer un grupo de prueba con personal independiente, un programa técnico para mantener a ese grupo adecuadamente capacitado, integrar el proceso de prueba las al ciclo de vida del desarrollo, y controlar y monitorear el proceso (por ejemplo, llevando métricas de esfuerzo, costo y calendario).

4. De Medición y Gestión (Management and Measurement). En este nivel, las pruebas no son una fase más de los proyectos. Son un proceso independiente que se mide, administra y mejora.
Por lo tanto, sus metas tienen que ver con establecer programas de revisión tempranamente en el ciclo de vida, establecer programas de medición y evaluación del proceso de pruebas, y evaluar la calidad del software generado, poniendo metas para estos programas y niveles de calidad, a nivel Organización.

5. De Optimización, Prevención y Control de Calidad (Optimization/Defect Prevention

and Quality Control). En este nivel, el objetivo es optimizar, o sea, gastar menos para obtener mejor calidad. Sus metas tienen que ver con utilizar los datos recabados para prevenir la aparición de defectos (análisis de causa raíz, equipos y planes de prevención), aplicar control estadístico a los procesos, optimizarlos y mejorarlos.

Por dónde empezar

Entender qué y cómo lo hacemos, es una buena manera.

Para ello, primero veamos si el conjunto básico de buenas prácticas está siendo utilizado, y cómo:

· Separación de ambientes

· Control de configuraciones

· Control de versiones

· Registración y seguimiento de defectos

· Conjunto básico de métricas

· Uniformidad de criterios de reporte

· Uniformidad de criterios de planificación

Luego, sigamos con los demás pasos del proceso de mejora, poco a poco pero con fundamentos sólidos (léase, con convencimiento nuestro y de los niveles que tienen que brindarnos soporte y fondos).

Hasta la próxima!!!

Bibliografía:

[1] I. Burnstein. Practical Software Testing. Springer, New York, 2003.

[2] I. Burnstein, A. Homyen, T. Suwanassart, G. Saxena, and R. Grom. A Testing Maturity Model for Software Test Process Assessment and Improvement. Software Quality Professional , September 1999, pp. 1–8.