Resumen Estrategia de prueba del software

 La prueba es un conjunto de actividades que pueden planearse por adelantado y realizarse de manera sistemática. Por esta razón, durante el proceso de software, debe definirse una plantilla para la prueba del software: un conjunto de pasos que incluyen métodos de prueba y técnicas de diseño de casos de prueba específicos. En la literatura sobre el tema, se han propuesto algunas estrategias de prueba de software. Todas proporcionan una plantilla para la prueba y tienen las siguientes características genéricas: 

• Para realizar una prueba efectiva, debe realizar revisiones técnicas efectivas (capítulo 15). Al hacerlo, eliminará muchos errores antes de comenzar la prueba. 

• La prueba comienza en los componentes y opera “hacia afuera”, hacia la integración de todo el sistema de cómputo. 

• Diferentes técnicas de prueba son adecuadas para distintos enfoques de ingeniería de software y en diferentes momentos en el tiempo. 

• Las pruebas las realiza el desarrollador del software y (para proyectos grandes) un grupo de prueba independiente. 

• Prueba y depuración son actividades diferentes, pero la depuración debe incluirse en cualquier estrategia de prueba.

Verificación y validación 

La prueba de software es un elemento de un tema más amplio que usualmente se conoce como verificación y validación (V&V). La verificación se refiere al conjunto de tareas que garantizan que el software implementa correctamente una función específica. La validación es un conjunto diferente de tareas que aseguran que el software que se construye sigue los requerimientos del cliente. Boehm [Boe81] afirma esto de esta forma: Verificación: “¿Construimos el producto correctamente?” Validación: “¿Construimos el producto correcto?” 

Criterios para completar las pruebas

Cada vez que se analiza la prueba del software, surge una pregunta clásica: “¿cuándo terminan las pruebas?, ¿cómo se sabe que se ha probado lo suficiente?”. Lamentablemente, no hay una respuesta definitiva a esta pregunta, pero existen algunas respuestas pragmáticas e intentos tempranos a manera de guía empírica. Una respuesta a la pregunta es: “nunca se termina de probar; la carga simplemente pasa de usted (el ingeniero de software) al usuario final”. Cada vez que el usuario ejecuta un programa de cómputo, el programa se pone a prueba. Este instructivo hecho subraya la importancia de otras actividades a fin de garantizar la calidad del software. Otra respuesta (un tanto cínica, mas no obstante precisa) es: “las pruebas terminan cuando se agota el tiempo o el dinero”.

Pruebas de integración 

Un neófito en el mundo del software podrá plantear una pregunta aparentemente legítima una vez que todos los módulos se hayan probado de manera individual: “si todos ellos funcionan individualmente, ¿por qué dudan que funcionarán cuando se junten todos?”. Desde luego, el problema es “juntarlos todos”: conectarlos. Los datos pueden perderse a través de una interfaz; un componente puede tener un inadvertido efecto adverso sobre otro; las subfunciones, cuando se combinan, pueden no producir la función principal deseada; la imprecisión aceptable individualmente puede magnificarse a niveles inaceptables; las estructuras de datos globales pueden presentar problemas. Lamentablemente, la lista sigue y sigue. Las pruebas de integración son una técnica sistemática para construir la arquitectura del software mientras se llevan a cabo pruebas para descubrir errores asociados con la interfaz. El objetivo es tomar los componentes probados de manera individual y construir una estructura de programa que se haya dictado por diseño.