Dotando a nuestra organización de una estructura madura para Software Testing

Sirva este post para retomar la serie de posts que desde hace unos meses estoy elaborando con cierta ninguna regularidad acerca de la apasionante y necesaria disciplina del Software Testing dentro del ciclo de desarrollo software.


En esta ocasión, voy a hablaros acerca de los niveles TMM. Seguramente, la mayoría de vosotros conoceréis el modelo CMM (Capacity Maturity Model), aplicable a los procesos de desarrollo software. Pues bien, TMM es un modelo de madurez aplicado al Software Testing, basado en este modelo CMM y en otra serie de consideraciones específicas del software testing (como por ejemplo las “fases en la vida mental de un tester“, redactadas por Boris Beizer, uno de los mayores expertos en Software Testing del mundo).


TMM establece cinco niveles diferentes, que reflejan cinco estadíos diferentes de una organización en cuanto a la madurez o estandarización de sus procesos de pruebas. Son los siguientes:


1.- Nivel inicial:



 a) No existen objetivos de madurez en este nivel.
 b) El proceso de pruebas es caótico.
 c) Las pruebas se desarrollan ad-hoc, una vez que el artefacto a probar ha sido implementado.
 d) El testing y el debugging (depuración) se mezclan.
 e) El objetivo de las pruebas es demostrar que el software NO tiene errores.


2.- Fase de definición:



 a) Se establecen los primeros objetivos para las fases de pruebas y de depuración.
 b) Se inicia un proceso de planificación de pruebas.
 c) Los métodos básicos de pruebas a emplear se institucionalizan y documentan.


3.- Integración:



 a) Existe una estructura organizada para el testing, no obstante, esta estructura puede no ser independiente sino estar compuesta por miembros del   equipo de desarrollo del software.
 b) Se ponen en práctica programas de entrenamiento para mejorar las habilidades del equipo de testers.
 c) Integración de las pruebas en el ciclo de vida del software.
 d) Creación de mecanismos de monitorización y control del proceso de software.


4.- Gestión y métricas:



 a) Establecimiento de un programa de revisiones común a toda la organización.
 b) Establecimiento de una serie de métricas para evaluar la calidad de nuestras pruebas.
 c) Creación de mecanismos que permiten evaluar la calidad del software antes y después de nuestras pruebas, y también, de una versión a otra del producto.


5.- Optimización, prevención de defectos y control de calidad:



 a) Empleo de métricas y datos previos (de los recogidos en la fase 4) para ayudar en la prevención de defectos.
 b) Controles de calidad estandarizados.
 c) Optimización del proceso de pruebas.


 


Idealmente, una organización dedicada a la construcción de software debería pretender alcanzar los niveles 4 y 5 de esta clasificación. No obstante, es probable que por diversos motivos (presupuesto, ausencia de personal cualificado o con experiencia previa en equipos de software testing, etc) sea utópico dar el salto entre las fases 2 y 3 (creación de un equipo de expertos en pruebas independiente del equipo de desarrollo). La importancia de que el equipo de pruebas sea independiente del equipo de desarrollo se debe en primer lugar a que las características de un Ingeniero de Sofware de Pruebas son diferentes a las de un Ingeniero de Software (como ya comenté por aquí), y en última instancia, en caso de que las pruebas deban ser realizadas por Ingenieros de Software, deberíamos procurar que un desarrollador probara el código de otro en aquellas pruebas de Caja Negra que llevemos a cabo (las pruebas de Caja Blanca básicas, o Pruebas Unitarias, sí que deben desarrollarse a priori por el propio desarrollador; especialmente si empleamos un paradigma TDD puesto que ése es su principal objetivo). Este hecho se debe a que un desarrollador siempre tiende a sobrevalorar su propio código y tiende a omitir el análisis exhaustivo sobre el mismo de forma subconsciente, debido a su convencimiento de que el desarrollo ha sido el adecuado y por tanto carece de errores.


A pesar de ello, el resto de puntos orientados al control y monitorización del proceso de pruebas sí deben llevarse a cabo y los beneficios que aportarán a nuestros equipos son enormes. Por citar algunos de ellos:



 1.- El proceso de pruebas se convertirá en algo gestionable y capaz de ser estimado de forma precisa.
 2.- El uso de planes de pruebas y artefactos estandarizados (diseño de casos de prueba, especificación de los mismos, etc) permitirá que la puesta en marcha de nuevos planes de prueba sea inmediata, al conseguir que dicho plan forme parte intrínseca del ciclo de vida de nuestros proyectos y, por tanto, un elemento más dentro de la larga lista de tareas que monitorizamos diariamente en nuestros proyectos.
 3.- Dispondremos en todo momento de información empírica que nos servirá para determinar cómo y en qué momento deberemos aplicar cada tipo de pruebas, de este modo, podremos definir políticas organizacionales al respecto.
 4.- Mediante el uso de todas estas guías para el Software Testing en nuestra organización, podremos formar a nuevos especialistas y también mejorar el nivel del resto (podrán analizar y aprender de errores anteriores).


Existen otras tantas ventajas asociadas a la adopción de niveles TMM 4 y 5. No obstante, creo que como primera aproximación a la taxonomía de niveles de madurez de los procesos de pruebas ya está bien con estas… 🙂


En posteriores entradas hablaré sobre cómo pasar de una a otra fase, qué tipo de estructuras organizativas se requieren en un equipo de Pruebas y qué mecanismos de control y de comunicación con los demás grupos (grupos de desarrollo, grupos o responsables de planificación y control del proyecto, etc) se deben establecer.

Un comentario en “Dotando a nuestra organización de una estructura madura para Software Testing”

Deja un comentario

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *