Estrategia de Pruebas

Estrategia de Pruebas

Estrategia de Pruebas. 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.

Elementos

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. La estrategia que se ha de seguir a la hora de evaluar dinámicamente un sistema software debe permitir comenzar por los componentes más simples y más pequeños e ir avanzando progresivamente hasta probar todo el software en su conjunto. Más concretamente, los pasos a seguir son:

• Pruebas Unitarias. Comienzan con la prueba de cada módulo.
• Pruebas de Integración. A partir del esquema del diseño, los módulos probados se vuelven a probar combinados para probar sus interfaces.
• Prueba del Sistema. El software ensamblado totalmente con cualquier componente hardware que requiere se prueba para comprobar que se cumplen los requisitos funcionales.
• Pruebas de Aceptación. El cliente comprueba que el software funciona según sus expectativas.

Pruebas Unitarias

La prueba de unidad es la primera fase de las pruebas dinámicas y se realizan sobre cada módulo del software de manera independiente.

Objetivo

El objetivo es comprobar que el módulo, entendido como una unidad funcional de un programa independiente, está correctamente codificado. En estas pruebas cada módulo será probado por separado y lo hará, generalmente, la persona que lo creo. En general, un módulo se entiende como un componente software que cumple las siguientes características:

• Debe ser un bloque básico de construcción de programas.
• Debe implementar una función independiente simple.
• Podrá ser probado al cien por cien por separado.
• No deberá tener más de 500 líneas de código.

Tanto las pruebas de caja blanca como las de caja negra han de aplicar para probar de la manera más completa posible un módulo. Nótese que las pruebas de caja negra (los casos de prueba) se pueden especificar antes de que módulo sea programado, no así las pruebas de caja blanca.

Pruebas de Integración

Aún cuando los módulos de un programa funcionen bien por separado es necesario probarlos conjuntamente: un módulo puede tener un efecto adverso o inadvertido sobre otro módulo; las subfunciones, cuando se combinan, pueden no producir la función principal deseada; la imprecisión aceptada individuamente puede crecer hasta niveles inaceptables al combinar los módulos; los datos pueden perderse o malinterpretarse entre interfaces, etc. Por lo tanto, es necesario probar el software ensamblando todos los módulos probados previamente. Ésta es el objetivo de la pruebas de integración. A menudo hay una tendencia a intentar una integración no incremental; es decir, a combinar todos los módulos y probar todo el programa en su conjunto. El resultado puede ser un poco caótico con un gran conjunto de fallos y la consiguiente dificultad para identificar el módulo (o módulos) que los provocó. En contra, se puede aplicar la integración incremental en la que el programa se prueba en pequeñas porciones en las que los fallos son más fáciles de detectar. Existen dos tipos de integración incremental, la denominada ascendente y descendente. Veamos los pasos a seguir para cada caso: Integración incremental ascendente:

• Se combinan los módulos de bajo nivel en grupos que realicen una subfunción específica.
• Se escribe un controlador (un programa de control de la prueba) para coordinar la entrada y salida de los casos de prueba.
• Se prueba el grup.
• Se eliminan los controladores y se combinan los grupos moviéndose hacia arriba por la estructura del programa.

Pruebas del Sistema

Este tipo de pruebas tiene como propósito ejercitar profundamente el sistema para verificar que se han integrado adecuadamente todos los elementos del sistema (hardware, otro software, etc.) y que realizan las funciones adecuadas. Concretamente se debe comprobar que:

• Se cumplen los requisitos funcionales establecidos.
• El funcionamiento y rendimiento de las interfaces hardware, software y de usuario.
• La adecuación de la documentación de usuario.
• Rendimiento y respuesta en condiciones límite y de sobrecarga.

Para la generación de casos de prueba de sistema se utilizan técnicas de caja negra. Este tipo de pruebas se suelen hacer inicialmente en el entrono del desarrollador, denominadas Pruebas Alfa, y seguidamente en el entrono del cliente denominadas Pruebas Beta.

Pruebas de Aceptación

A la hora de realizar estas pruebas, el producto está listo para implantarse en el entorno del cliente. El usuario debe ser el que realice las pruebas, ayudado por personas del equipo de pruebas, siendo deseable, que sea el mismo usuario quien aporte los casos de prueba. Estas pruebas se caracterizan por:

• Participación activa del usuario, que debe ejecutar los casos de prueba ayudado por miembros del equipo de pruebas.
• Están enfocadas a probar los requisitos de usuario, o mejor dicho a demostrar que no se cumplen los requisitos, los criterios de aceptación o el contrato. Si no se consigue demostrar esto el cliente deberá aceptar el producto.
• Corresponden a la fase final del proceso de desarrollo de software.

Es muy recomendable que las pruebas de aceptación se realicen en el entorno en que se va a explotar el sistema (incluido el personal que lo maneje). En caso de un producto de interés general, se realizan pruebas con varios usuarios que reportarán sus valoraciones sobre el producto. Para la generación de casos de prueba de aceptación se utilizan técnicas de caja negra.

Pruebas de Regresión

La regresión consiste en la repetición selectiva de pruebas para detectar fallos introducidos durante la modificación de un sistema o componente de un sistema. Se efectuarán para comprobar que los cambios no han originado efectos adversos no intencionados o que se siguen cumpliendo los requisitos especificados. En las pruebas de regresión hay que:

• Probar íntegramente los módulos que se han cambiado.
• Decidir las pruebas a efectuar para los módulos que no han cambiado y que han sido afectados por los cambios producidos.

Este tipo de pruebas ha de realizarse, tanto durante el desarrollo cuando se produzcan cambios en el software, como durante el mantenimiento.

Fuentes

• Proceso de Pruebas de Software
• Gemini.udistrital
• Slideshare
• Wiziq

Enlace relacionado

• Software