PRUEBAS DEL SOFTWAREPRUEBAS DEL SOFTWARE

Lic. Juan Gabriel Bernal LópezLic. Juan Gabriel Bernal López

• Cuando se desarrolla software se Cuando se desarrolla software se realizan una serie de actividades en realizan una serie de actividades en la que hay enormes posibilidades de la que hay enormes posibilidades de que aparezca el error humano.que aparezca el error humano.

• Los errores pueden presentarse Los errores pueden presentarse desde el primer momento.desde el primer momento.

• Debido a la imposibilidad humana de Debido a la imposibilidad humana de trabajar y comunicarse de forma trabajar y comunicarse de forma perfecta es necesario acompañar el perfecta es necesario acompañar el desarrollo del SW de una actividad desarrollo del SW de una actividad que garantice la calidad.que garantice la calidad.

• La pruebas son un elemento crítico La pruebas son un elemento crítico para la garantía de la calidad del SW para la garantía de la calidad del SW y representan una revisión final de y representan una revisión final de las especificaciones, el diseño y de la las especificaciones, el diseño y de la codificación.codificación.

• No es raro que una organización de No es raro que una organización de desarrollo de SW emplee entre el 30 desarrollo de SW emplee entre el 30 y el 40 por ciento del esfuerzo total y el 40 por ciento del esfuerzo total del proyecto en las pruebas.del proyecto en las pruebas.

• La pruebas de SW para actividades La pruebas de SW para actividades críticas (Control de tráfico aéreo o de críticas (Control de tráfico aéreo o de reactores nucleares) pueden costar reactores nucleares) pueden costar de 3 a 5 veces más que el resto de de 3 a 5 veces más que el resto de los pasos de la Ing. De SW juntos.los pasos de la Ing. De SW juntos.

• En la fases anteriores el Ing. Intenta En la fases anteriores el Ing. Intenta “construir” el SW.“construir” el SW.

• Al llegar a la pruebas crea una serie Al llegar a la pruebas crea una serie de casos de prueba que intentan de casos de prueba que intentan “demoler” el SW construido.“demoler” el SW construido.

• La pruebas son el paso de la Ing. de La pruebas son el paso de la Ing. de SW que se puede ver SW que se puede ver (psicológicamente) como destructivo (psicológicamente) como destructivo en lugar de constructivo.en lugar de constructivo.

• Los Ing. de SW son por naturaleza Los Ing. de SW son por naturaleza constructivos.constructivos.

• Las pruebas requieren que se Las pruebas requieren que se descarten ideas preconcebidas sobre descarten ideas preconcebidas sobre la “corrección” del SW que de acaba la “corrección” del SW que de acaba de desarrollar y se supere cualquier de desarrollar y se supere cualquier conflicto de intereses que aparezca conflicto de intereses que aparezca cuando se descubran errores.cuando se descubran errores.

• Existe un mito que dice que si Existe un mito que dice que si fuéramos realmente buenos fuéramos realmente buenos programando, no habría errores que programando, no habría errores que buscar. No habría errores.buscar. No habría errores.

• Según el mito existen errores porque Según el mito existen errores porque somos malos en lo que hacemos y somos malos en lo que hacemos y debemos sentirnos culpables por ello.debemos sentirnos culpables por ello.

• Las pruebas serían un reconocimiento Las pruebas serían un reconocimiento de nuestros fallos e implica una buena de nuestros fallos e implica una buena dosis de culpabilidad.dosis de culpabilidad.

• ¿Deben infundir culpabilidad las ¿Deben infundir culpabilidad las pruebas? ¿Son realmente pruebas? ¿Son realmente destructivas?destructivas?

• NO.NO.

OBJETIVOS DE LAS OBJETIVOS DE LAS PRUEBASPRUEBAS

• La prueba es el proceso de ejecución de La prueba es el proceso de ejecución de un programa con la intención de un programa con la intención de descubrir un error.descubrir un error.

• Un buen caso de prueba es aquel que Un buen caso de prueba es aquel que tiene una alta probabilidad de mostrar tiene una alta probabilidad de mostrar un error no descubierto hasta entonces.un error no descubierto hasta entonces.

• Una prueba tiene éxito si des cubre un Una prueba tiene éxito si des cubre un error no detectado hasta entonces.error no detectado hasta entonces.

• Hay que quitarse la idea, que Hay que quitarse la idea, que normalmente tenemos, de que una normalmente tenemos, de que una prueba tiene éxito si no descubre prueba tiene éxito si no descubre errores.errores.

• El objetivo es diseñar pruebas que El objetivo es diseñar pruebas que sistemáticamente saquen a la luz sistemáticamente saquen a la luz diferentes clases de errores, diferentes clases de errores, haciéndolo con la menor cantidad de haciéndolo con la menor cantidad de tiempo y esfuerzo.tiempo y esfuerzo.

• Como ventaja secundaria, la prueba Como ventaja secundaria, la prueba demuestra hasta qué punto la funciones demuestra hasta qué punto la funciones del SW trabajan de acuerdo con las del SW trabajan de acuerdo con las especificaciones.especificaciones.

• Los datos recogidos indican en cierta Los datos recogidos indican en cierta medida la fiabilidad y calidad del SW medida la fiabilidad y calidad del SW como un todo.como un todo.

• La prueba no puede asegurar la La prueba no puede asegurar la ausencia de defectos; sólo puede ausencia de defectos; sólo puede demostrar que existen defectos en el demostrar que existen defectos en el SW.SW.

PRINCIPIOS DE LAS PRINCIPIOS DE LAS PRUEBASPRUEBAS

• A todas las pruebas se les debería A todas las pruebas se les debería poder hacer un seguimiento hasta poder hacer un seguimiento hasta los requisitos del clientelos requisitos del cliente

• Las pruebas deberían planificarse Las pruebas deberían planificarse mucho antes de que empiecen.mucho antes de que empiecen.

• El principio de Pareto es aplicable a El principio de Pareto es aplicable a las pruebas del SW. (80% de los las pruebas del SW. (80% de los errores en 20% de los módulos)errores en 20% de los módulos)

PRINCIPIOS DE LAS PRINCIPIOS DE LAS PRUEBASPRUEBAS• Las pruebas deberían empezar por “lo Las pruebas deberían empezar por “lo

pequeño” y progresar hacia “lo grande”.pequeño” y progresar hacia “lo grande”.

• No son posibles las pruebas exhaustivas.No son posibles las pruebas exhaustivas.

• Para ser más eficaces la pruebas Para ser más eficaces la pruebas deberían ser realizadas por un equipo deberían ser realizadas por un equipo independiente.independiente.

FACILIDAD DE PRUEBAFACILIDAD DE PRUEBA

• Es la facilidad con la que se puede Es la facilidad con la que se puede probar un SW.probar un SW.

Caraterísticas que llevan a un Caraterísticas que llevan a un SW. Fácil de probar.SW. Fácil de probar.

• OPERATIVIDAD. Cuanto mejor OPERATIVIDAD. Cuanto mejor funcione, más eficientemente se funcione, más eficientemente se puede probar.puede probar.

-Pocos errores-Pocos errores

- Ningún error bloquea las pruebas.- Ningún error bloquea las pruebas.

OBSERVABILIDADOBSERVABILIDAD

• Lo que ves es lo que pruebas.Lo que ves es lo que pruebas.– El código fuente es accesible.El código fuente es accesible.– Se informa automáticamente de los Se informa automáticamente de los

errores internos.errores internos.– Un resultado incorrecto se identifica Un resultado incorrecto se identifica

fácilmente.fácilmente.– Los errores internos se detectan Los errores internos se detectan

automáticamente a través de automáticamente a través de mecanismos de autocomprobación.mecanismos de autocomprobación.

CONTROLABILIDADCONTROLABILIDAD

• Cuanto mejor podamos controlar el Cuanto mejor podamos controlar el SW , más se puede automatizar y SW , más se puede automatizar y optimizar.optimizar.– El Ing. De pruebas puede controlar El Ing. De pruebas puede controlar

directamente los estados y variables del directamente los estados y variables del SW y HW.SW y HW.

– Las pruebas pueden especificarse, Las pruebas pueden especificarse, automatizarse y reproducirse automatizarse y reproducirse convenientemente.convenientemente.

CAPACIDAD DE CAPACIDAD DE DESCOMPOSICIÒN.DESCOMPOSICIÒN.

• Controlando el ámbito de las Controlando el ámbito de las pruebas, podemos aislar más pruebas, podemos aislar más rápidamente los problemas y llevar a rápidamente los problemas y llevar a cabo mejores pruebas.cabo mejores pruebas.– SW. Construido en módulos.SW. Construido en módulos.– Los módulos se pueden probar Los módulos se pueden probar

independientemente.independientemente.

SIMPLICIDADSIMPLICIDAD

• Cuanto menos haya que probar, más Cuanto menos haya que probar, más rápidamente podremos probarlo.rápidamente podremos probarlo.– Simplicidad funcional (Características Simplicidad funcional (Características

mínimas para cumplir los requisitos)mínimas para cumplir los requisitos)– Simplicidad Estructural (Arquitectura Simplicidad Estructural (Arquitectura

modularizada)modularizada)– Simplicidad del código.Simplicidad del código.

ESTABILIDADESTABILIDAD

• Cuanto menos cambios, menos Cuanto menos cambios, menos interrupciones a las pruebas.interrupciones a las pruebas.– Cambios infrecuentes.Cambios infrecuentes.– Cambios controlados.Cambios controlados.– El SW se recupera bien de lo fallos.El SW se recupera bien de lo fallos.

FACULIDAD DE FACULIDAD DE COMPRENSIÓNCOMPRENSIÓN

• Cuanto más información tengamos, Cuanto más información tengamos, más inteligentes serán las pruebas.más inteligentes serán las pruebas.– Entender perfectamente el diseño.Entender perfectamente el diseño.– Se ha entendido la dependencia entre Se ha entendido la dependencia entre

os componentes.os componentes.– Se conocen los cambios en el diseño.Se conocen los cambios en el diseño.– La documentación es instantáneamente La documentación es instantáneamente

accesible, está bien organizada, es accesible, está bien organizada, es específica, detallada y exacta.específica, detallada y exacta.

ATRIBUTOS DE UNA BUENA ATRIBUTOS DE UNA BUENA PRUEBAPRUEBA

• Tiene una alta probabilidad de Tiene una alta probabilidad de encontrar un error.encontrar un error.

• No debe ser redundante.No debe ser redundante.

• Debería ser “la mejor de la cosecha”Debería ser “la mejor de la cosecha”

• No debe ser ni demasiado sencilla ni No debe ser ni demasiado sencilla ni demasiado compleja.demasiado compleja.

ReferenciaReferencia

• Pressman, Roger. (2001). Pressman, Roger. (2001). Ingeniería Ingeniería del Software.del Software.