ISO 29119 - Un estándar para pruebas

El objetivo de la norma ISO/IEC 29119 es proporcionar una norma o estándar definitivo para las pruebas de software definiendo vocabulario, procesos, documentación, técnicas y un modelo de evaluación del proceso de pruebas de software que se puede utilizar dentro de cualquier ciclo de vida de desarrollo.

La norma se centra en un modelo de proceso de tres niveles basado en el riesgo para las pruebas de software que proporciona orientación sobre el desarrollo de estrategias de prueba organizativas y políticas, la gestión de proyectos de prueba (incluyendo el diseño de estrategias de prueba del proyecto / nivel) y los planes y el seguimiento y control de pruebas, y un proceso de prueba dinámica que proporciona una guía para el análisis y diseño de prueba, entorno de prueba de configuración y mantenimiento, la ejecución de prueba y se informa. En la actualidad se están desarrollando, probando y revisando por profesionales y académicos de todo el mundo, con 27 países representados en el grupo de trabajo que se encarga de elaborar la norma.

Este estándar (cuya elaboración comenzó en 2007) tiene como objetivo cubrir todo el ciclo de vida de las pruebas de sistemas software incluyendo los aspectos relativos a la organización, gestión, diseño y ejecución de las pruebas, para remplazar varios estándares IEEE y BSI sobre pruebas de software. La estructura de ISO/IEC 29119 consta de cinco partes:

1. Conceptos y Vocabulario
2. Proceso de Pruebas
3. Documentación de Pruebas
4. Técnicas de Prueba
5. ISO/IEC 33063 Modelo de Evaluación para los procesos de pruebas de software (número estándar de doble pendiente)

Estructura ISO 29119

Este estándar se basa en las principales normas que actualmente son los referentes de esta área:

• BSI (British Standards Institution): BS 7925-1, Software Testing: Part 1-Vocabulary y BS 7925-2, Software Testing: Part 2-Software Component Testing.
• IEEE Std. 829, Software Test Documentation y IEEE Std 1008, Software Unit Testing, IEEE Std 1012-1998 Software Verification and Validation y IEEE Std 1028-1997 Software Reviews.
• ISO/IEC 12207, Software Life Cycle Processes, ISO/IEC 15289, System and Software Life Cycle Process Information Products y ISO/IEC TR 19759, Guide to the Software Engineering Body of Knowledge

El trabajo está siendo desarrollado por ISO, concretamente por subcomité 7 / grupo de trabajo 26. En el proyecto participan 18 países, entre ellos España, que está representada por el correspondiente grupo de trabajo 26 de AENOR, que lidera Javier Tuya (Universidad de Oviedo).

En lo que refiere a fechas, la planificación dice que para 2013 estará la primera versión de la norma ISO 29119.

Como parte final, sólo cabe decir que esta norma ISO 29119 tiene una estructura bastante amplia y contiene una descripción de procesos que intervienen durante todo el proceso de testeo. No obstante, sigue basándose en pruebas unitarias, de integración, de regresión y aceptación para el proceso, las cuales se van realizando de acuerdo al momento. Además, nos ofrece una forma de realizar las pruebas de forma iterativa y evolutiva. También nos indica que debe existir una estructura, que aparte de estar separada de los desarrolladores, debe tener toda una serie de documentaciones para poder realizar las pruebas. Cada resultado de prueba alimenta las siguientes pruebas.

Dicho de otra forma, la ISO 29119 nos ofrece una forma de realizar pruebas de forma más organizada y procedimental que las tradicionales. 

Análisis comparativo de los ciclos de vida del software

Para empezar, primero veamos la definición de un "modelo de ciclo de vida" según la ISO 12207-1:

“Es un marco de referencia que contiene los procesos, las actividades y las tareas involucradas en el desarrollo, la explotación y el mantenimiento de un producto de software, abarcando la vida del sistema desde la definición de los requisitos hasta la finalización de su uso”

Ahora bien, existen distintos tipos de modelo de ciclos de vida: cascada, en V, iterativo, incremental, en espiral, de prototipos, entre otros. 

Las principales diferencias entre distintos modelos de ciclo de vida están en:

• El alcance del ciclo dependiendo de hasta dónde llegue el proyecto correspondiente. Un proyecto puede comprender un simple estudio de viabilidad del desarrollo de un producto, o su desarrollo completo o en el extremo, toda la historia del producto con su desarrollo, fabricación y modificaciones posteriores hasta su retirada del mercado.

• Las características (contenidos) de las fases en que dividen el ciclo. Esto puede depender del propio tema al que se refiere el proyecto, o de la organización.

• La estructura y la sucesión de las etapas, si hay realimentación entre ellas, y si tenemos libertad de repetirlas (iterar).

Pero ahora vamos a tratar de describir y comparar brevemente cada uno de ellos, para así tener una mejor comprensión de estos ciclos de vida:

Modelo en cascada

Este modelo es un proceso de desarrollo estrictamente secuencial, es decir que el desarrollo se ve fluyendo hacia abajo sobre las fases que componen el ciclo de vida. Ahora bien, esto nos deja claro algunas cosas:

• Puede parecernos un modelo en el que todo está bien organizado, de apariencia simple y fácil de usar, pero en la vida real un proyecto rara vez sigue una secuencia lineal, lo cual hace que no sea práctico en la mayoría de los casos.
• Para que este modelo funcione adecuadamente, el cliente debe establecer al principio absolutamente todos los requisitos necesarios, de manera que mientras no se tenga todo establecido se provoca un gran atraso (innecesario en el caso de otros ciclos de vida).
• Los resultados se presentan de golpe ya que sólo son visibles cuando el producto está finalizado en su totalidad. Esto provoca una gran inseguridad por parte del cliente, el cual probablemente preferiría ir viendo los avances del producto en el transcurso de su desarrollo.
• Es un modelo pobre para proyectos complejos, largos, orientados a objetos y además genera grandes cantidades de riesgos e incertidumbres.

Modelo iterativo

Este es un modelo derivado del ciclo de vida en cascada. Entre algunos aspectos a considerar tenemos:

• Busca reducir el riesgo que surge durante la etapa de recogida de requisitos, por ello consiste en la iteración de varios ciclos de vida en cascada. Así que no hace falta que los requisitos estén totalmente definidos al inicio del desarrollo (uno de los grandes problemas del ciclo de vida en cascada), sino que se pueden ir refinando en cada iteración.
• Tiene la ventaja de gestionar mejor los riesgos y las entregas (entre otras cosas), ya que realiza el desarrollo en pequeños ciclos.
• Un inconveniente podría ser que surgieran problemas con la arquitectura si no se definen los requisitos necesarios desde el principio.
• La creación y entrega de prototipos es algo que ayuda bastante a conseguir la conformidad del cliente.

Modelo de desarrollo incremental

Este modelo combina elementos del ciclo de vida en cascada con la construcción de prototipos (algo similar al modelo iterativo). Aplica secuencias lineales de forma escalonada mientras en cada una de ellas produce un incremento del software. Entonces podemos decir que:

• Es un modelo más flexible que los anteriores, ya que se reduce el coste en el cambio de alcance y requisitos.
• Al igual que el anterior, es más fácil de gestionar riesgos y probar/depurar en una iteración más pequeña.
• Podrían surgir problemas con la arquitectura justamente por el mismo factor del anterior ciclo de vida: no todos los requisitos se reúnen al inicio.
• Cada fase es una iteración rígida y no se superponen con otras.
• Los errores en los requisitos se detectan tarde.

Modelo en V

Este modelo es un proceso que representa la secuencia de pasos en el desarrollo del ciclo de vida de un proyecto. 

• Su diferencia con el ciclo de vida en cascada es que éste, en lugar de ir de forma lineal (hacia abajo), las fases del proceso vuelven hacia arriba tras la fase de codificación, formando una V (de ahí el nombre).
• En cada fase hay entregables específicos.
• Suele funcionar bien en proyectos pequeños donde los requisitos son entendidos sin complicaciones.
• Tiene poca flexibilidad y ajustar el alcance es difícil y caro.
• No se producen prototipos del software, ya que éste se desarrolla únicamente en la fase de implementación.

Modelo de prototipos

Una vez se hace la recolección de requisitos, el desarrollador y el cliente encuentran y definen los objetivos globales para el software para que luego haga su aparición un diseño rápido que lleve a la construcción de un prototipo. Luego el cliente evalúa dicho prototipo, de manera que la iteración ocurre cuando el prototipo se pone a punto para satisfacer las necesidades del cliente.

• Al estar esperando la aprobación del cliente prototipo tras prototipo, hace que trabajar con este modelo de ciclo de vida sea un desarrollo lento.
• Reduce el riesgo de construir productos que no satisfagan las necesidades de los usuarios.
• El cliente reacciona mejor ante prototipos en los que puede experimentar.
• Permite introducir cambios en las iteraciones siguientes de cada ciclo.
• No presenta calidad ni robustez.

Modelo en espiral

Este modelo de desarrollo combina las características del modelo de prototipos y el modelo en cascada. Si bien, esto modelo no fue el primero en tratar el desarrollo iterativo, fue el primero en explicar las iteraciones.

• Este modelo está pensado para proyectos largos, caros y complicados.
• Trata de mejorar los ciclos de vida clásicos y prototipos.
• Al ser un modelo de ciclo de vida orientado a la gestión de riesgos se dice que uno de los aspectos fundamentales de su éxito radica en que el equipo que lo aplique tenga la necesaria experiencia y habilidad para detectar y catalogar correctamente los riesgos.
• Eliminar errores y alternativas no atractivas al comienzo.
• Permite iteraciones, vuelta atrás y finalizaciones rápidas.
• Al dividir el proyecto en ciclos, al final de cada uno existe un acuerdo para los cambios que hay que realizar en el sistema.
• Este modelo se adapta a cualquier tipo de actividad adicional.