Testing (I) - Las pruebas según el CMMi

Este es el primero de una serie de artículos sobre el testing y el cmmi:

• Testing (I) - Las pruebas según el CMMi
• Testing (II) - Planificación de las pruebas
• Testing (III) - Analizar los resultados de las pruebas

Las pruebas en el modelo CMMI DEV están tratadas principalmente en las áreas de proceso "Verificación" y "Validación".

La verificación tiene como objetivo demostrar que el producto de trabajo cumple los requisitos que se especificaron para ese producto de trabajo, la validación asegura que el producto que se proporciona es adecuado para su uso previsto y en el entorno operativo previsto. Con la oportunidad que da el sintético idioma inglés, los americanos dicen que la pregunta para la verificación es Did you build the product right?, mientras que la pregunta para la validación es Did you build the right product?

La verificación se hace sobre productos de trabajo y sobre el producto final, entendiendo que los productos de trabajo son resultado de actividades diversas y no solamente de la codificación. Se tienen que verificar los documentos que se generan respecto a los requisitos que se acordaron al inicio y durante el desarrollo del proyecto. Por ejemplo, el manual de usuario deberá cumplir con algún tipo de requisito o normativa, especificado por el cliente o por la organización que hace el desarrollo. Se tendrá que comprobar que se haya escrito en el idioma o idiomas pedidos, que sigue una estructura adecuada y que está completo, que figuran los logos del cliente si así se ha especificado. Como éstos puede haber otros requisitos para este producto o para otros.

En la validación intervienen los usuarios finales u otros involucrados en el proyecto, que tienen autoridad para revisar los productos obtenidos y rechazarlos si no satisfacen las necesidades del usuario cuando se encuentran en el entorno en el que van a operar. Siguiendo con el ejemplo del Manual de Usuario, la persona que tiene que validarlo, comprobará que los resultados de las consultas le son útiles en el entorno y la función de la aplicación para las que las hace. Por ejemplo, puede encontrarse que entre los parámetros de configuración no figuran los necesarios para su sistema operativo.

El modelo CMMi considera especialmente la utilización de las revisiones entre pares como instrumento de verificación, tanto es así que la utilización de las mismas es una de las metas del área de proceso “Verificación”. Para decirlo más claramente, si una organización quiere alcanzar el nivel 3 está obligada a utilizar este método.

Las revisión entre pares es una técnica en la que el producto del trabajo de una persona se expone a la consideración de otras personas con las que no tiene relación de dependencia, es decir, son sus iguales, sus compañeros. El producto generado se revisa utilizando listas de comprobación ("checklists") en las cuales se pueden encontrar cuestiones sobre reglas de construcción, guías de diseño, facilidad de mantenimiento, tipos de defectos comunes, etc, que se van a comprobar en elementos  entre los que pueden estar los productos de trabajo claves de las actividades de especificación, de diseño, de prueba y de implementación, y sobre los productos de trabajo específicos de planificación.

Verificar es más que probar.

Solamente probar código no es verificar, las pruebas del software son una parte del concepto de verificación tal y cómo lo entiende el modelo. Todos lo productos de  trabajo del proyecto, no solamente el código, deben considerarse para decidir si se incorporan entre los que van a ser verificados, y entre ellos están los documentos técnicos, los planes, los productos COTS (*), herramientas a utilizar, e incluso elementos de formación.

Validación.

En las actividades de validación, interviene el usuario para comprobar que el producto le presta las funcionalidades pedidas en el entorno de producción. Se han llamado normalmente “pruebas de aceptación” y tradicionalmente se hacen cuando el producto está terminado y sólo sobre el software. Para evitar sustos a última hora, deberían seleccionarse productos de trabajo intermedios, susceptibles de ser validados, que puedan predecir si el producto final cumplirá las expectativas del usuario y de este modo ir validando pronto, paulatina e incrementalmente durante todo el proyecto.
Ejemplo de los productos que se pueden validar son: los requisitos, diseños, componentes de producto, interfaces de usuario, manuales de usuario, materiales de formación y documentación del proceso.
El modelo exige las mismas prácticas para validar que para verificar, excepto la revisión entre pares.

 (*) COTS: Commercial Off The Shelf; paquetes o productos comerciales, que hay que probar (al menos su integración con el resto de nuestro producto).