Estrategia De Prueba De Sofware

ESTRATEGIAS DE PRUEBA DEL SOFTWARE

________________________________________

Una estrategia de prueba del software integra las técnicas de diseño de casos de prueba en una serie de pasos bien planificados que dan como resultado una correcta construcción del software. Y lo que es más importante, una estrategia de prueba del software proporciona un mapa a seguir para el responsable del desarrollo del software, a la organización de control de calidad y al cliente: un mapa que describe los pasos que hay que llevar a cabo como parte de la prueba, cuándo se deben planificar y realizar esos pasos, y cuánto esfuerzo, tiempo y recursos se van a requerir. Por tanto, cualquier estrategia de prueba debe incorporar la planificación de la prueba, el diseño de casos de prueba, la ejecución de las pruebas y la agrupación y evaluación de los datos resultantes.

Una estrategia de prueba del software debe ser suficientemente flexible para promover la creatividad y la adaptabilidad necesarias para adecuar la prueba a todos los grandes sistemas basados en software. Al mismo tiempo, la estrategia debe ser suficientemente rígida para promover un seguimiento razonable de la planificación y la gestión a medida que progresa el proyecto. Shooman trata estos puntos:

En muchos aspectos, la prueba es un proceso individualista y el número de tipos diferentes de pruebas varía tanto como los diferentes enfoques de desarrollo. Durante muchos años, nuestra única defensa contra los errores de programación era un cuidadoso diseño y la propia inteligencia del programador. Ahora nos encontramos en una era en la que las técnicas modernas de diseño (y las revisiones técnicas formales) nos ayudan a reducir el número de errores iniciales que se encuentran en el código de forma inherente. De forma similar, los diferentes métodos de prueba están empezando a agruparse en varias filosofías y enfoques diferentes.

UN ENFOQUE ESTRATÉGICO PARA LA PRUEBA DEL SOFTWARE

La prueba es un conjunto de actividades que se pueden planificar por adelantado y llevar a cabo sistemáticamente. Por esta razón se debe definir en el proceso de la ingeniería del software una plantilla para la prueba del software: un conjunto de pasos en los que podamos situar los métodos específicos de diseño de casos de prueba.

Se han propuesto varias estrategias de prueba del software en distintos libros. Todas proporcionan al desarrollador de software una plantilla para la prueba y todas tienen las siguientes características generales:

• La prueba comienza en el nivel de módulo y trabaja «hacia fuera», hacia la integración de todo el sistema basado en computadora.

• Según el momento son apropiadas diferentes técnicas de prueba.

• La prueba la lleva a cabo el responsable del desarrollo del software y (para grandes proyectos) un grupo independiente de pruebas.

• La prueba y la depuración son actividades diferentes, pero la depuración se debe incluir en cualquier estrategia de prueba.

Una estrategia de prueba del software debe incluir pruebas de bajo nivel que verifiquen que todos los pequeños segmentos de código fuente se han implementado correctamente, así como pruebas de alto nivel que validen las principales funciones del sistema frente a los requisitos del cliente. Una estrategia debe proporcionar una guía al profesional y proporcionar un conjunto de hitos para el jefe de proyecto. Debido a que los pasos de la estrategia de prueba se dan a la vez cuando aumenta la presión de los plazos fijados, se debe poder medir el progreso y los problemas deben aparecer lo antes posible.

Verificación y validación

La prueba del software es un elemento de un tema más amplio que, a menudo, se le conoce como verificación y validación (V&V). La verificación se refiere al conjunto de actividades que aseguran que el software implementa correctamente una función específica. La validación se refiere a un conjunto diferente de actividades que aseguran que el software construido se ajusta a los requisitos del cliente. Bohem lo define de otra forma:

Verificación: «¿Estamos construyendo el producto correctamente?»

Validación: «¿Estamos construyendo el producto correcto?»

Organización para la prueba del software

En cualquier proyecto de software existe un conflicto de intereses inherente que aparece cuando comienza la prueba. Se pide a la gente que ha construido el software que lo pruebe.

Esto parece totalmente inofensivo: después de todo, ¿quién puede conocer mejor un programa que los que lo han desarrollado? Desgraciadamente, los mismos programadores tienen un gran interés en demostrar que el programa está libre de errores, que funciona de acuerdo con las especificaciones del cliente y que estará listo de acuerdo con los plazos y el presupuesto. Cada uno de estos intereses se convierte en inconveniente a la hora de encontrar errores a lo largo del proceso de prueba.

Desde un punto de vista psicológico, el análisis y el diseño del software (junto con la codificación) son tareas constructivas. El ingeniero de software crea un programa de computadora, su documentación y sus estructuras de datos asociadas. Al igual que cualquier constructor, el ingeniero de software está orgulloso del edificio que acaba de construir y se enfrenta a cualquiera e intente sacarle defectos. Cuando comienza la prueba, aparece una sutil, aunque firme intención de «romper» lo que el ingeniero del software ha construido. Desde el punto de vista del constructor, la prueba se puede considerar (psicológicamente) destructiva. Por lo tanto, el constructor anda con cuidado, diseñando y ejecutando pruebas que demuestren que el programa funciona, en lugar de detectar errores. Desgraciadamente, los errores seguirán estando. Y si el ingeniero de software no los encuentra, el cliente si lo hará.

A menudo, existen ciertos malentendidos que se pueden deducir equivocadamente de la anterior discusión: (1) el responsable del desarrollo no debería entrar en el proceso de prueba; (2) el software debe ser «puesto a salvo» de extraños que puedan probarlo de forma despiadada; (3) los encargados de la prueba sólo aparecen en el proyecto cuando comienzan las etapas de prueba. Todas estas

...