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,

...