Estrategias Efectivas para la Detección y Corrección de Defectos en Software

Defectos y Fallas del Software

Muchos programadores consideran que la prueba es una comprobación de que sus programas operan correctamente. La idea de demostración de exactitud es realmente lo inverso de lo que entraña la prueba. Se prueba un programa para demostrar la existencia de un defecto. La prueba es destructiva, dado que la meta es descubrir defectos.

Identificación de defectos: es el proceso de determinar cuál o cuáles son los defectos que originan las fallas.

Corrección de defectos o remoción: es el proceso de efectuar cambios al sistema de manera que se eliminen los defectos.

Aspectos de la Prueba

¿Quién realiza las pruebas?

Muchas veces se manifiestan dificultades para separar los sentimientos personales del proceso de prueba. Por lo tanto, a menudo se utiliza un equipo de prueba independiente.

Justificación de un equipo independiente de prueba:

• Es claro que nadie entrega su código para la prueba sin pensar que el código ha sido realizado de acuerdo con la especificación, pero se puede estar demasiado apegado al código como para ser realmente objetivo y reconocer algunos de los defectos más sutiles.
• Las pruebas pueden llevarse concurrentemente con la codificación; el equipo de prueba verifica los componentes a medida que son completados y comienza a consolidarse mientras el plantel de programación continúa codificando los demás.

Pruebas de Integración

Cuando se llega a un convencimiento de que los componentes individuales están trabajando correctamente y se satisfacen los objetivos, se los combina en un sistema activo. Esta integración se planea y coordina para que, al producirse una falla, se pueda tener alguna idea de lo que le ha dado origen.

Integración Ascendente (Bottom-Up)

Este enfoque permite realizar pruebas desde los componentes elementales a los más generales. Cuando se usa este método, se prueba primero en forma individual cada componente al nivel más bajo de la jerarquía del sistema. Luego, los próximos componentes que se prueban son los que llaman a los ya probados. Este método es útil cuando muchos de los componentes de bajo nivel son rutinas utilitarias de uso general que son invocados a menudo por otros componentes.

Considerando esta jerarquía, se comienza probando los módulos E, F, G. Como no existe ningún programa preparado para llamar a estos programas del más bajo nivel, se escribe un código especial para llamar la integración. Este código se llama controlador de componentes (Driver), es una rutina que llama a un componente particular y le pasa un caso de prueba. Considerando la jerarquía planteada anteriormente, estos son los pasos de la prueba.

Es un enfoque funcional, la queja radica en que, al ser los módulos superiores los más importantes, son los últimos en ser probados. Por otra parte, este enfoque es a menudo el más razonable para los programas orientados a objetos. Los objetos se combinan de uno por vez con objetos o colecciones de objetos que se han probado previamente.

Integración Descendente (Top-Down)

Es lo contrario del bottom-up. El componente principal se prueba aisladamente, después todos los componentes llamados por el componente se combinan y se prueban como una unidad mayor. Este enfoque se vuelve a aplicar hasta que todos los componentes estén incorporados.

Un componente que se está probando puede llamar a otro todavía no probado, de modo que se escribe un programa de propósito especial que simule la actividad del componente omitido, denominado talón. Ejemplo basado en la jerarquía anterior:

En la prueba descendente no se necesitan programas controladores. Por otro lado, la escritura de los talones puede ser difícil, porque estos deben permitir probar todas las posibles condiciones. Otra problemática es que, si el diseño se cambia, los talones también. Una desventaja de esta técnica es la posibilidad de requerir números muy grandes de talones. Esta situación se produce cuando el nivel más bajo tiene muchas rutinas. Una manera de evitar este problema es alterar ligeramente la estrategia. En lugar de incorporar un nivel completo por vez, un enfoque descendente modificado prueba los componentes de cada nivel individualmente antes de llevar a cabo la fusión.

Integración Intercalada

El sistema es como de 3 capas, al igual que un sándwich: en el medio la capa objetivo, los niveles por encima del objetivo y los niveles por debajo del objetivo. En la capa superior se utiliza top-down y en la capa inferior bottom-up. La prueba converge a la capa objetivo, elegida en base a las características del sistema y a la estructura de la jerarquía del componente. Este enfoque permite utilizar el enfoque bottom-up para verificar lo correcto de los utilitarios al principio de la prueba. Por lo tanto, no se necesita escribir talones para los utilitarios porque están disponibles.

Basados en el ejemplo anterior, el nivel objetivo es el nivel medio, compuesto por los componentes B, C y D.

Este enfoque mezcla las ventajas de los 2 métodos. Sin embargo, no permite probar los componentes antes de la integración. La prueba intercalada modificada permite probar los componentes antes de unirlos con otros.

Principio de la Prueba de Sistema

(Asegurar que el sistema hace lo que el cliente quiere que haga)

Proceso de la Prueba de Sistema

Objetivo del proceso:

Prueba funcional: verifica que el sistema integrado realiza las funciones especificadas en la especificación de requerimientos.

Prueba de desempeño: luego de que se convencen de que las funciones trabajan de acuerdo con la especificación, se realiza esta prueba. Esta prueba compara el rendimiento de los componentes integrados con los requerimientos no funcionales.

Hasta este punto, el sistema opera de la manera en que los diseñadores piensan. Se le denomina sistema verificado, es la interpretación de la especificación de requerimientos por parte de los diseñadores.

Luego, si se comprueba satisfactoriamente que el sistema que se ha construido cumple los requerimientos, se tiene un sistema validado, es decir, se ha verificado el cumplimiento de los requerimientos.

Pruebas de aceptación: asegura a los clientes que el sistema que pidieron es el sistema que se construyó para ellos. A veces se ejecutan en el ambiente real, pero a menudo se realiza en una instalación del desarrollador.

Prueba de instalación: se realiza (en el caso de que la prueba de aceptación no sea realizada en el lugar del cliente) para permitir que los usuarios ensayen las funciones del sistema y documenten todos los problemas adicionales surgidos de la puesta del sistema en el sitio real.