CalidadySotware.com / Testing / TMMI

Autor: Ing. Alexander Oré B.

TMMI - CUANDO EL CMMI NO ES SUFICIENTE.

 

Desde hace buen tiempo la industria del software viene realizando grandes esfuerzos por mejorar las calidad de los productos, Esta ha sido una tarea difícil, ya que el tamaño y la complejidad de la software aumenta rápidamente, mientras que los clientes y usuarios son cada vez más exigentes. A pesar de resultados alentadores con diversos enfoques de mejora de la calidad, la industria del software aún está lejos de lograr los cero defectos.

Para mejorar la calidad de los productos, la industria del software se ha centrado mucho en la mejora de sus procesos de desarrollo. Una directriz que se ha utilizado ampliamente para mejorar los procesos de desarrollo es el Modelo de la capacidad de madurez. (CMM) y su sucesor, el Modelo de la capacidad de madurez Integrado (CMMI).

Son a menudo estos modelos considerados como el estándar de la industria del software para la mejora de procesos.

 

 
 

A pesar del hecho de que las pruebas de software (Software testing), a menudo cuestan por lo menos el 30 ó 40% del total del proyecto, se presta poca atención a las pruebas en los distintos modelos de mejora de procesos tales como el CMM y el CMMI. Para lograr superar estos inconvenientes es que se ha desarrollado el modelo TMMI - Test Maturity Model Integration, desarrollado por el instituto de tecnología de Illinois.

El TMMI proporciona un enfoque más amplio y estructurado al proceso de prueba, existe un gran número de experiencias positivas con el modelo TMMI y las organizaciones que la utilizan van en aumento, las experiencias muestran que aplicar el modelo de madurez TMMI tiene un impacto positivo sobre la calidad del producto.

En este artículo resumimos algunas recomendaciones sobre como se debe organizar y ejecutar con éxito una mejora de proceso utilizando el TMMI.

De manera similar al CMMI el TMMI nos presenta una mejora en los procesos relativos a la calidad del software y define también 5 niveles de madurez o jerarquía evolutiva.

Cada nivel de madurez contiene un conjunto de áreas de proceso, Las áreas de proceso por cada nivel se muestran en la siguiente figura.

Fig 1. Los 5 niveles de Tmmi.

La estructura interna del TMMI contiene prácticas de pruebas que pueden ser aprendidas y aplicadas sistemáticamente para apoyar la mejora de calidad gradualmente. Hay 5 niveles en el TMMI que definen la jerarquía de madurez y el camino de evolución a la mejora del proceso de pruebas.

EL PROYECTO DE MEJORA USANDO TMMI

El TMMi no es sólo un modelo teórico, sino un conjunto bien definido de áreas proceso y objetivos basados sobre casos de estudio prácticos. Aunque el modelo es bastante fácil de entender, su aplicación en una organización no siempre es una tarea simple. En promedio podríamos tardar 2 años para alcanzar el TMMI nivel 2.

En base a experiencias prácticas un típico proyecto de TMMI tiene las siguientes fases:

Iniciación (determinar el alcance y objetivo).
Planificación (definir el proyecto en términos de estructura, recursos, etc.)
Implementación (desarrollo de entregables, procedimientos y plantillas).

Despliegue (publicación, despliegue de los resultados y la institucionalización)

1. FASE DE INICIACIÓN:

Determinar el estado actual de la organización:

Antes de iniciar cualquier proyecto de mejora, es necesario conocer el nivel de madurez actual. Es posible que no sea necesario realizar una evaluación 100% formal que nos tome demasiado tiempo, un análisis rápido puede resultar muchas veces suficiente para determinar nuestro nivel de madurez. Podríamos empezar por escoger un proyecto de software típico en nuestra organización, realizar entrevistas a un grupo de involucrados en el mismo y preparar un informe que contenga el perfil de madurez actual, por razones obvias estas entrevistas deben ser dirigidas por personas que tengan experiencia en CMMI y de ser posible en TMMi. Este informe se presenta luego al área de gestión de proyectos, lo que finalmente puede derivar o crear las bases para un proyecto de mejora de TMMi.

Este informe podría contener algo similar a esta tabla:

AREA DE POCESO

PUNTUACION

CONCLUSIÓN

Estrategia de Pruebas

3.9

Deficiente

Plan de Pruebas

4.6

Deficiente

Seguimiento

4.2

Deficiente

Diseño y ejecución de casos de Prueba

5.4

Regular

Ambiente de pruebas

6.6

Adecuado

Es muy importante tener objetivos definidos en el proyecto de mejora, y estos objetivos deberían estar alineados con los objetivos de toda la organización, de esta manera será más sencillo obtener el compromiso y apoyo de todos los participantes del proyecto.

2. FASE DE PLANIFICACIÓN

Un problema común al llevar a cabo un proyecto de mejora de procesos es que generalmente no recibe la suficiente atención y recursos para que el proyecto marque la diferencia. Se ven resultados muy positivos cuando el proyecto es organizado alrededor de recomendaciones rápidas de mejora. Cada recomendación es asignada a un grupo de trabajo el cual se encarga de analizar estas mejoras y si se estima conveniente se hace el despliegue.

Dado que los cambios o recomendaciones se van a desplegar en proyectos de pruebas, cada grupo debe estar compuesto por representantes de todos los proyectos de pruebas, cada grupo debe informar sobre el resultado del despliegue de la mejora al jefe de proyecto, quien a su vez debe informar a la dirección general. Es fundamental que la dirección general tenga miembros que apoyen las mejoras que se pretender realizar y esperen beneficiarse de estas. Si no existe suficiente capacidad de personal asignado al equipo de mejora de proyectos, y los miembros no están dedicados al 100% en esta labor, pronto todos los recursos ocuparan el resto de sus actividades a su día a día habitual y se diluirá la iniciativa.

Otra de las partes importantes en un proyecto de mejora es la comunicación, las personas rechazan el cambio naturalmente y solo cambiarán si realmente se entiende que el cambio es necesario, para esto es importante brindarles información clara y efectiva. Las personas van a observar a sus compañeros ocupados en el importante proyecto de mejora y van a querer saber que esta sucediendo lo antes posible. Es conveniente enviar periódicamente correos informativos o boletines sobre el avance del proyecto y los cambios en el mismo, así como también tener reuniones o charlas periódicas con los departamentos o áreas impactadas. Una buena práctica es la participación de estas personas en la revisión de los entregables del proyecto.

Consultores externos:

Con sus conocimientos y experiencia, los consultores externos pueden hacer una valiosa contribución a un proyecto de mejora. Especialmente si son asignados a tiempo completo, ya que pueden estimular las mejoras de procesos en términos de esfuerzo y progreso. En un proyecto que sufrimos las dificultades de combinar la responsabilidad de un proyecto de mejora de procesos y las funciones habituales de la administración de pruebas, (especialmente cuando las pruebas exigían gran demanda de nuestra atención), hemos experimentado las ventajas del trabajo en pares, el consultor externo trabajando en equipo con el administrador de pruebas. Se ha descubierto que con un buen equilibrio entre proceso y proyecto, las mejoras fueron inmediatamente incorporadas en la organización. Inevitablemente el consultor externo debe tarde o temprano dejar la organización sin embargo la organización debe continuar mejorando por si misma. Es por esta razón que la titularidad de los proyectos de mejora del proceso de pruebas sea de personal interno y nunca del consultor.

Crear compromiso en los interesados (stakeholders):

No todas los involucrados pueden ser evidentes a primera vista, es muy recomendable realizar un análisis de los interesados en el inicio del proyecto de mejora. Las personas cuya participación o contribuciones necesitamos son los interesados, pero también las personas que tienen un cierto interés en nuestros resultados, por ejemplo el promotor del proyecto de mejora debería estar muy bien informado.

Madurez del proceso de desarrollo:

En este modelo no es solo importante observar la madurez del proceso de prueba, sino también los procesos de los que dependen las pruebas. La madurez del proceso de desarrollo ente otros procesos también son importantes. Es necesario asegurarnos que la gestión de proyectos, gestión de la configuración, gestión de requisitos y gestión de riesgos tienen la suficiente atención en la organización que se esta intentando mejorar. La falta de una adecuada gestión de proyectos hará que el proyecto de mejora de pruebas sea un fracaso. Si la organización no está acostumbrada a trabajar en proyectos, será difícil integrar las actividades de prueba de una manera estructurada. Debemos asegurarnos no iniciar un proyecto de mejora del área de pruebas si la organización no esta lista para soportarlo.

Alinearse con otras iniciativas de mejora:

Dentro de nuestras organizaciones otras iniciativas de mejora pueden estar en curso, por ejemplo, mejora de procesos software basado en el CMMI. Cuidado con la "otra iniciativa". Un departamento sólo puede manejar una cierta cantidad de cambios en un determinado momento. Para evitar duplicar actividades que se ejecutan en un proceso de mejora, se recomienda tener un mapa de actividades exclusivo para la mejora de prueba. Esta cartografía debe ser responsabilidad de los administradores de proyecto.

3. FASE DE IMPLEMETACIÓN

Durante esta fase, todos los cambios planeados deben ser implementados, especialmente  aquellos que se obtuvieron de las recomendaciones rápidas de mejora. En la medida de lo posible se recomienda utilizar las mejores prácticas recomendadas, en algunas ocasiones un proceso es realmente eficiente y no es necesario realizar cambio alguno, para estos casos solo es necesario documentar el proceso.

Métricas:

Medir el progreso y la calidad de las pruebas así como el establecimiento de indicadores de rendimiento para el proceso de pruebas son importantes para controlar la calidad y para mostrar los beneficios del proceso de mejora continua.

Piense acerca de las cifras en el ámbito de la eficiencia, la eficacia y el despliegue. Un problema común aparece cuando se definen un gran número de métricas y el resultado es que tenemos que hacer un tremendo esfuerzo para interpretarlas y utilizarlas.

Lo conveniente podría ser empezar por un pequeño pero efectivo numero de métricas, las cuales seamos capaces de analizar, comprender y aplicar en nuestro proceso de mejora.

Documentación:

La documentación debe definirse rápidamente al iniciar la etapa de implementación, detallarla de forma clara y concisa, por ejemplo: “Principales funciones de la organización”, “pruebas funcionales requeridas”, “Especificaciones funcionales del modulo 1”, “Casos de pruebas que deben ser ejecutados necesariamente para dar conformidad al sistema”, “Que técnicas de pruebas de código se utilizaran”, etc.

Estrategia de pruebas:

El TMMi requiere la definición de una estrategia o plan de pruebas para cada uno de los sistemas que se esta probando en la organización. Esta estrategia proporciona una visión de cómo los productos son probados a lo largo de su ciclo de vida. Deben evitarse probar sistemas que escapen del plan o de la metodología ya implementada, ya que al no tener una visión clara de lo que se hace, se corre el riesgo de perder el control del proyecto.

De forma similar la metodología utilizada en pruebas debe alinearse con la utilizada en la etapa de desarrollo. (RUP, RAD, etc.).

Todo plan de pruebas debería considerar aspectos como:

  1. Cual es el objetivo de las pruebas.
  2. Cual es el alcance de las pruebas.
  3. Que tipos de pruebas se realizaran.
    1. Funcionales.
    2. Stress.
    3. Automatizadas.
    4. De Regresión.
  4. Cuantos ciclos o barridas de prueba se estima realizar.
  5. Casos de prueba que se utilizaran.
  6. Que recursos realizarán las pruebas.
  7. Tiempos.
  8. La estrategia para la puesta en producción. Etc.

4. FASE DE DESPLIEGUE

Accesibilidad de los entregables:

Asegúrese de que todos los documentos, tanto los procedimientos y las plantillas, sean de fácil acceso para todos los testers y otras partes interesadas.

Una forma fácil y efectiva para compartir los documentos es crear una intranet, aquí se puede graficar la estructura de trabajo y permitir tener un fácil acceso para descargar los documentos que se necesitan. La representación de los documentos en forma de pirámide puede ser beneficiosa, con el proceso general en la parte superior y todos los documentos de apoyo como instrucciones de trabajo y plantillas en la base. Esta pirámide se llagara convertir en un núcleo del trabajo de pruebas y pronto todo el mundo reconocerá la importancia de “La Pirámide” en la Intranet como punto de partida en la búsqueda de documentos y plantillas.

El proceso de cambio:

El proceso de despliegue es el más difícil y el que consume más tiempo en el proyecto de mejora, es posible publicar los documentos o plantillas pero eso no asegura que serán utilizados de inmediato por todos los testers y jefes de pruebas. En muchas ocasiones el problema en los proyectos de mejora no es la disponibilidad de la documentación sino la falta de compromiso a la nueva forma que se ha descrito para trabajar. Es decir las normas o procedimientos pueden llegar a ser letra muerta. Si están normas no son utilizadas en varios proyectos pueden servir de excusa para que no sean utilizadas en ninguno, ya que esta nueva forma de trabajo podría requerir de mayores esfuerzos en los recursos en una primera etapa.

Para lograr cierto nivel de madurez al menos el 80% de las personas en el área de pruebas deben trabajar de acuerdo al procedimiento documentado. Si los procedimientos no se siguen, se debe tratar de resolver ese problema en primer lugar. Solo cuando es claro que los procesos definidos nunca se siguen es que vale la pena iniciar el cambio y hacerlos cumplir.

El tiempo que tomará un proyecto de mejora no solo dependerá de los cambios que se realicen, también debemos considerar la cultura de la organización, y la gestión de proyectos. Resultaría conveniente empezar por un proyecto piloto para determinar si los cambios en los procedimientos son realmente viables. Este piloto candidato debe estar en sus primeras etapas y todos los involucrados deberían estar dispuestos a participar. Considerar también que en una cultura en donde existen héroes y estos tienen una gran influencia, los cambios en las mejoras de los procesos no serán aceptados fácilmente. Debemos estar preparados a la resistencia cuando se apliquen los cambios, aceptar de buena gana las críticas y sobre todo no cambiemos más de lo necesario, es mejor avanzar en pasos pequeños y comunicar los cambios tantas veces como sea necesario.

Un proyecto de mejora no tiene éxito hasta que se ha desplegado y es aceptado por personas motivadas por la mejora. Finalmente este proyecto de mejora enfocado al proceso de pruebas debe motivar a cada uno de los analistas de prueba o testers de forma que siempre se mantenga presente la búsqueda de mejoras a la calidad de los procesos y asegurar que cada iniciativa no sea apagada con pesimismo, desgano o desinterés, los jefes de área deben ser los principales responsables de mantener esta cultura de mejora y de constante cambio en la organización. Que la labor diaria de pruebas no frene nuestro crecimiento y desarrollo profesional.

Ing. Alexander Oré B.

 
 
 
CalidadySoftware.com 2009 - © Todos los derechos reservados
Sitio Web Alojado por NazcaSoft.com