ESTRATEGIAS DE PRUEBA DEL SOFTWARE

INTRODUCCION

Las estrategias de pruebas del software son las líneas guía del equipo de pruebas de un proyecto de desarrollo de software. A menudo éstas son escritas por el director del equipo de pruebas, en un documento, que será entregado formalmente al director del proyecto, para su posterior revisión y aprobación.

Se debe tener claridad en que dicho documento no debe ser visto como un entregable más, éste debe ser visto como un artefacto especialmente creado para reunir las ideas más representativas del proceso de pruebas que se llevará a cabo.

ESTRATEGIAS DE PRUEBA DEL SOFTWARE

Una estrategia 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. 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.

UN ENFOQUE ESTRATEGICO PARA LA PRUEBA

La prueba es un conjunto de actividades que se pueden planificar por adelantado y llevar a cabo sistemáticamente.

Se debe definir una plantilla: un conjunto de pasos en los que podamos situar los métodos específicos de diseños de casos de prueba. Características de la plantilla:

La prueba comienza en el nivel de módulo y trabaja hacia fuera

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 debe incluir pruebas de bajo nivel que verifiquen que todos los pequeños segmentos de código fuente se han implementado correctamente, así como las pruebas de alto nivel que validen las principales funciones del sistema frente a los requisitos del cliente.

VERIFICACIÓN Y VALIDACIÓN

Verificación: se refiere al conjunto de actividades que aseguran que el software implementa correctamente una función específica.

Validación: se refiere a un conjunto diferente de actividades que aseguran que el software construido se ajusta a los requisitos del cliente.

No se puede probar la calidad

La calidad se confirma durante la prueba.

ABARCAN UNA AMPLIA LISTA DE LAS ACTIVIDADES SQA:

 Revisiones técnicas formales

 Auditorias de calidad y de configuración

 Monitorización de rendimiento

 Simulación de estudios de factibilidad

 Revisión de la documentación

 Revisión de la base de datos

 Análisis algorítmicos

 Prueba de desarrollo

 Prueba de validación y pruebas de instalación

ORGANIZACIÓN PARA LA PRUEBA DEL SOFTWARE

Desde el punto de vista psicológico, el análisis y el diseño (junto con la codificación) del software son tareas constructivas. Desde el punto de vista del constructor, la prueba se puede considerar destructiva.

El responsable del desarrollo del software siempre es responsable de probar las unidades individuales (módulos) del programa, asegurándose de que cada una lleva a cabo la función para la que fue diseñada. También se encargara de la prueba de integración. Solo una vez que la arquitectura del software este completa entra en juego un grupo independiente de prueba (GIP), cuyo papel es eliminar

los inherentes problemas asociados con el hecho de permitir al constructor que pruebe lo que ha construido.

El responsable del desarrollo y el GIP trabajan estrechamente a lo largo del proyecto para asegurar que se realizan pruebas exhaustivas. Mientras se realiza la prueba el desarrollador debe estar disponible para corregir los errores que se van descubriendo.

El GIP es parte del equipo del desarrollo de software. El GIP informa a la organización de garantía de calidad del software, consiguiendo independencia.

ESTRATEGIA DE PRUEBA DEL SOFTWARE.

El proceso de ingeniería del software se puede ver como un espiral

La prueba de unidad comienza en el vértice de la espiral y se centra en cada unidad del software, tal como está implementada el código fuente.

La prueba de integración, el foco de atención es el diseño y la construcción de la arquitectura del software.

La prueba de validación, donde se validan los requisitos del software comparándolos con el sistema que se ha construido.

Finalmente en la prueba del sistema se prueban como un todo el software y otros elementos del sistema.

Desde el punto de vista procedimental, la prueba es una serie de cuatro pasos secuenciales:

Prueba de unidad: hace uso intensivo de las técnicas de prueba de caja blanca

Prueba de integración: prevalecen las técnicas de prueba de caja negra, aunque se pueden llevar a cabo algunas de caja blanca con el fin de asegurar que se cubren los principales caminos de control. Pruebas de alto nivel: se realizan después que se ha integrado (construido) el software.

Pruebas de validación proporciona una seguridad final de que el software satisface todos los requisitos funcionales, de comportamiento y de rendimiento. Se utilizan exclusivamente técnicas de prueba de caja negra.

CRITERIOS PARA COMPLETAR LA PRUEBA.

Cada vez que se trata la prueba del software surge una pregunta clásica: ¿cuándo hemos terminado la prueba, cómo sabemos que hemos probado lo suficiente?

La prueba nunca termina ya que el responsable del desarrollo del software carga o pasa el problema al cliente.

Musa y Ackerman sugieren una respuesta basada en un criterio estadístico: No, no podemos tener la certeza absoluta de que el software nunca fallará, pero en base a un modelo estadístico de corte teórico y validado experimentalmente, hemos realizado las pruebas suficientes para decir, con un 95 por ciento de certeza, que la probabilidad de funcionamiento libre de fallo de 1000 horas de CPU, es al menos 0,995.

ASPECTOS ESTRATÉGICOS

Tom Gilb plantea que se deben abordar los siguientes puntos si se desea implementar con éxito una estrategia de prueba del software.

Especificar los requisitos del producto de manera cuantificable mucho antes de que comiencen las pruebas.

Establecer los objetivos de la prueba de manera explícita (términos medibles) Comprender qué usuarios va a tener

...