El imperativo de la trazabilidad

La trazabilidad parece una de estas palabras técnicas a las que tan aficionados son los profesionales de las Tecnologías de la Información. En este caso, la realidad es muy distinta porque el concepto que abarca es realmente sencillo.

Publicado el 06 Feb 2003

Cuando se crea cualquier producto, ya sea una casa, un coche o un software, la idea es cubrir las necesidades concretas de los usuarios/consumidores. En la jerga informática, estas necesidades se suelen llamar requerimientos y constituyen el fundamento que da paso al diseño del sistema y luego al código que se ejecutará sobre una máquina. Posteriormente, un equipo de ingenieros de test se encarga de probar si los requerimientos iniciales quedan cubiertos con el producto resultante.
En todo este proceso, el papel de la trazabilidad es documentar con precisión los enlaces que existen desde los requerimientos iniciales hasta las pruebas, pasando por el diseño y la creación del código. En resumen, permite responder a la pregunta tan sencilla como clave ¿se ha comprobado que el sistema hace lo que debe hacer?
Para probar correctamente un sistema hay que definir adecuadamente lo que éste debe hacer. La ausencia de algo tan simple, a menudo, supone el fracaso de muchos desarrollos. Esto es así porque las organizaciones usuarias fallan a la hora de concretar sus requerimientos sin ambigüedad.
Ejemplo si construimos un coche podemos definir un requisito que sea capaz de transportar 4 personas a 100 km/h. Esto parece fácil de probar. Basta poner el coche en la autopista con 4 pasajeros…, pero ¿ qué pasa si el coche se enfrenta a la subida de, por ejemplo, el puerto de Pajares?, ¿correrá el coche a 100 km/hora? y, además, ¿influye el peso de los pasajeros sobre el requerimiento previo?
Este ejemplo muestra que el requerimiento inicial no era lo suficientemente preciso para ser probado o, como mínimo, que según el tipo de pruebas a las que se someta al vehículo podría darse el caso de que se cumpla o no la premisa inicial.
Los requerimientos se deben detallar con precisión y formalizarse de manera que se puedan probar. En esta línea, deben incluir las condiciones de aceptación que los tests podrán verificar sin ambigüedad.
Poniendo otro ejemplo, esta vez en el campo concreto de las TI, un requerimiento de alto nivel en un sistema ERP puede ser se permitirá crear un nuevo artículo en la base de datos. Las condiciones de aceptación pueden ser varias, tal y como se describe en el gráfico siguiente
Se permitirá crear un nuevo articulo en la base de datos.
– Cond 1 el nombre del artículo no tendrá más de 15 caracteres
– Cond 2 el nombre no podrá contener caracteres no alfanuméricos, puntuación u otros signos
– Cond n ningún artículo de mismo nombre deberá existir en la base de datos
– etc.
Frecuentemente la precisión se consigue mediante un diálogo y revisión constantes entre los usuarios/clientes y los arquitectos de la solución. Involucrar a los ingenieros de calidad desde esta etapa es importante porque éstos aportan el ojo crítico del tester, cuya misión es comprobar que el requerimiento se cumple.

El ingeniero de test tiene luego la responsabilidad de diseñar las pruebas que verificarán las condiciones de aceptación de los requerimientos. En los sistemas complejos, una prueba puede compartir varios pasos y, posiblemente, probar varias condiciones. En el ejemplo anterior, un tester podría diseñar una prueba como esta
Test Paso 1 conectarse al sistema
Paso 2 crear un artículo en la base de datos tornillos 50×20
verificar que el artículo está creado correctamente
Paso 3 crear otra vez el artículo tornillos 50×20
verificar que el sistema deniega la creación
Paso 4 crear un artículo en la base de datos destornillador eléctrico
verificar que el sistema deniega la creación
Paso 4 desconectarse del sistema
Este test verifica a la vez la condición 1 (prueba con un artículo de más de 15 caracteres) y la condición n (prueba con un artículo ya existente).
Una vez diseñados los diferentes tests los analistas los ejecutarán, una o varias veces a lo largo del proyecto, para verificar que el sistema sigue funcionando.
La trazabilidad permite, por tanto, relacionar los requerimientos del usuario (sobre los cuales se va a crear el producto) con cada uno de los test y pruebas que se realizan para comprobar que dicho requisito se cumple, como se describe esquemáticamente en los gráficos adjuntos
A lo largo del proyecto puede usarse desde una simple matriz Excel hasta herramientas dedicadas que permiten obtener varios tipos de listados, estadísticas y control. Estas herramientas permiten, en general, navegar fácilmente adelante y atrás, desde el requerimiento hasta la ejecución de las pruebas o viceversa.
Así se puede conocer, fácilmente y en cualquier momento, si un requerimiento está cubierto por un test que lo verifica, si este test ha sido diseñado, y cuándo se ha ejecutado. Permite, igualmente, archivar los resultados de estas pruebas.
Asimismo, se pueden extraer todos los requerimientos que nunca han sido probados o bien todos los requerimientos que fallan en las pruebas. Y, algo fundamental, a partir de todas las pruebas que se han ejecutado en un momento dado, conocer cuántos requerimientos han sido probados.
La trazabilidad es, por tanto, el concepto de cobertura de la calidad de un desarrollo que más y más se está extendiendo en nuestra industria. Normas internacionales como el DO818 o FDA están imponiendo estas medidas de certificación de la calidad del software a sistemas informáticos críticos, espaciales o médicos.
Al fin y al cabo, saber exactamente si se ha probado correctamente un software es una condición imprescindible para garantizar un cierto nivel de calidad, satisfacer las necesidades del usuario final y, consecuentemente, salvaguardar los valores de la marca.
Raynald Korchia, director general de inQAlabs.

¿Qué te ha parecido este artículo?

La tua opinione è importante per noi!

C
Redacción Computing

Artículos relacionados

Artículo 1 de 5