Prueba de todo el ciclo de vida del software

CAPÍTULO 2

Prueba de todo el ciclo de vida del software

El testeo no es una actividad aislada. Tiene su lugar dentro de un desarrollo modelo de ciclo de vida del software, por lo que el ciclo de vida aplicado determinará en gran medida de cómo se organiza la prueba. Hay muchas formas diferentes de pruebas. Debido a varias disciplinas, a menudo con diferentes intereses, están involucrados en el ciclo de vida de desarrollo, es importante entender claramente y definir los distintos niveles de prueba y tipos. Este capítulo trata de los modelos de desarrollo de software más comúnmente aplicados, niveles de prueba y tipos de pruebas. El mantenimiento puede ser visto como una instancia específica de un proceso de desarrollo. La forma de mantenimiento influye en el proceso de pruebas, niveles y tipos de pruebas y cómo se puede organizar, se describe en la última sección de este capítulo.

2.1 MODELOS DE DESARROLLO DE SOFTWARE

1) Comprender la relación entre desarrollo, actividades de prueba y productos de trabajo en el ciclo de vida de desarrollo y dar ejemplos basados en proyecto y las características del producto y el contexto. ( K2 )

2) Reconocer el hecho de que los modelos de desarrollo de software deben adaptarse al contexto de las características del proyecto y del producto. ( Kl )

3) Recordar razones para los diferentes niveles de la prueba y características de una buena prueba en cualquier modelo de ciclo de vida. ( Kl )

El proceso de desarrollo adoptado para un proyecto dependerá de los objetivos y metas del proyecto. Hay numerosos ciclos de vida de desarrollo que se han desarrollado con el fin de conseguir diferentes objetivos requeridos. Estos ciclos de vida van desde metodologías ligeras y rápidas, donde el tiempo de comercialización es de la esencia, hasta metodologías totalmente controladas y documentadas en los que la calidad y la fiabilidad son factores clave. Cada uno de estos métodos tiene su lugar en el desarrollo de software moderno y el proceso de desarrollo más adecuado se debe aplicar a cada proyecto. Los modelos especifican las diversas etapas del proceso y el orden en el que se llevan a cabo.

El modelo de ciclo de vida que se adopte para un proyecto tendrá un gran impacto en la prueba que se lleva a cabo. Pruebas no existe de manera aislada; las actividades de prueba están muy relacionadas con las actividades de desarrollo de software. Definirá el qué, el dónde y el cuándo de nuestra prueba planificada, la influencia de las pruebas de regresión y determinan, en gran medida, que técnicas de prueba usar. La manera de cómo la prueba está organizada debe ajustarse al ciclo de vida del desarrollo o no será capaz de entregar su beneficio. Si el tiempo de comercialización es el factor clave, entonces, la prueba debe ser rápida y eficiente. Si un ciclo de vida de desarrollo de software completamente documentado, con una pista de auditoría de pruebas, es requerido, la prueba debe estar completamente documentada.

En cada ciclo de vida de desarrollo, una parte de la prueba se centra en las pruebas de verificación y otra se centra en las pruebas de validación. Verificación tiene que ver con la evaluación de un producto de trabajo, componente o sistema para determinar si cumple con los requisitos establecidos. De hecho, la verificación se centra en la pregunta " ¿El entregable está construido de acuerdo a la especificación? '. La validación se refiere a la evaluación de un producto de trabajo, componente o sistema para determinar si cumple con las necesidades y requerimientos del usuario. La validación se concentra en la pregunta " ¿El entregable está ajustado al propósito , por ejemplo, ¿proporciona una solución al problema? ' .

2.1.1 V-model

Antes de discutir el modelo V, vamos a ver el modelo que había antes de él. El modelo en cascada fue uno de los primeros modelos que fueron diseñados. Tiene una línea de tiempo natural, donde las tareas se ejecutan de manera secuencial. Empezaremos por la parte superior de la cascada con un estudio de factibilidad y el flujo a través de las diferentes tareas del proyecto acabado con la implementación en el entorno de producción. El diseño atraviesa el desarrollo, que a su vez desemboca en la construcción, y finalmente en la prueba. Las pruebas suelen ocurrir en el final del ciclo de vida del proyecto, así defectos se detectan cerca de la fecha de implementación en vivo. Con este modelo ha sido difícil obtener retroalimentación y hay dificultades si tenemos que llevar a cabo numerosas iteraciones para una fase particular.

El modelo V se desarrolló para abordar algunos de los problemas experimentados con el enfoque tradicional del modelo cascada. Los defectos se encuentran demasiado tarde en el ciclo de vida, porque las pruebas no se realizaron hasta el final del proyecto. Las pruebas también agregan tiempo de espera debido a su tardía participación. El modelo - V señala que la prueba debe comenzar lo antes posible en el ciclo de vida, que, como hemos visto en el capítulo 1 , es uno de los principios fundamentales de la prueba estructurada. También muestra que la prueba no es sólo una actividad basada en ejecución. Hay una variedad de actividades que deban llevarse a cabo antes del final de la fase de codificación. Estas actividades deben llevarse a cabo en paralelo con las actividades de desarrollo, y los testers tienen que trabajar con los desarrolladores y los analistas de negocio para que puedan llevar a cabo estas actividades y tareas y producir un conjunto de entregables de prueba. Los productos de trabajo producidos por los desarrolladores y analistas de negocio durante el desarrollo son la base de las pruebas en uno o más niveles. Al comenzar el diseño temprano de la prueba, los defectos se encuentran a menudo en los documentos básicos de prueba. Una buena práctica es tener testers involucrados incluso antes, durante la revisión de los (borrador) los documentos básicos de prueba. El modelo V es un modelo que ilustra cómo las actividades de prueba (verificación y validación) se pueden integrar en cada fase del ciclo de vida. Dentro del modelo V, las pruebas de validación se llevan a cabo sobre todo durante las primeras etapas, por ejemplo, la revisión de los requisitos de los usuarios, y al final del ciclo de vida, por ejemplo, durante las pruebas de aceptación del usuario.

Aunque existen variantes del modelo en V, un tipo común del modelo V utiliza cuatro niveles de prueba. Los cuatro niveles de prueba utilizados, cada uno con sus propios objetivos, son:

• Las pruebas de componentes: busca defectos y verifica el funcionamiento de los componentes de software (por ejemplo, módulos, programas, objetos, clases, etc) que son probados por separado;

• Pruebas de integración: pruebas de interfaces entre componentes, las interacciones a diferentes partes de un sistema como un sistema operativo, sistema de archivos y mercancías duras o las interfaces entre los sistemas;

• Pruebas del sistema: se ocupa del comportamiento de todo el sistema / producto, definida por el alcance de un proyecto de desarrollo o producto. El objetivo principal de las pruebas del sistema es la verificación respecto a los requisitos especificados;

• Pruebas de aceptación: pruebas de validación con respecto a las necesidades del usuario, requieren mentos, y los procesos de negocio llevados a cabo para determinar si se acepta o no el sistema.

Los diferentes niveles de la prueba se explican y discuten en detalle en la Sección 2.2.

En la práctica, un modelo V puede tener más, menos o diferentes niveles de desarrollo y pruebas, en función del proyecto y del producto de software. Por ejemplo, puede haber pruebas de integración de los componentes después de la prueba de componentes y pruebas de integración del sistema después de las pruebas del sistema. Los niveles de prueba pueden ser combinados o reorganizados en función de la naturaleza del proyecto o de la arquitectura del sistema. Para la integración de un off-the-shelf (COTS) de productos software comercial en un sistema, un comprador puede realizar sólo pruebas de integración a nivel de sistema (por ejemplo, la integración de la infraestructura y otros sistemas) y luego una prueba de fase de recepción más tarde.

El lado izquierdo de la V representa la descomposición de las necesidades, y la creación de las especificaciones del sistema. El lado derecho de la V representa la integración de las piezas y su verificación.

Tenga en cuenta que los tipos de productos de trabajo mencionadas en la Figura 2.2 en el lado izquierdo de la modelo V son sólo una ilustración. En la práctica, vienen con muchos nombres diferentes. Referencias para los productos de trabajo genéricos incluyen el Modelo de Integración de Madurez de Capacidades (CMMI) o los "procesos del ciclo de vida del software" de la norma ISO / IEC 12207. El CMMi es un marco para la mejora de procesos, tanto para ingeniería de sistemas e ingeniería de software. Proporciona orientación sobre dónde enfocar y cómo, con el fin de aumentar el nivel de madurez de los procesos [CHRISSIS et ah, 2004]. ISO / IEC 12207 es un estándar de proceso del ciclo de vida del software integrado que se está convirtiendo rápidamente más popular.

2.1.2 Ciclos de vida iterativos

No todos los ciclos de vida son secuenciales. También hay ciclos de vida iterativos o incrementales, donde, en lugar de una gran línea de tiempo de desarrollo de principio a fin, nos desplazamos a través de una pequeña serie

...