CAPITULO 17 U: estrategia de prueba de software proporciona una guia que describe los pasos que EsTRATEGIAS DE PRUEBA DE SOFTWARE Concertos cLave. 44 deben realizarse como parte de la prueba, cuando se planean y se llevan a cabo dichos. pasos, y cudinto esfuerzo, tiempo y recursos se requeriran, Por tanto, cualquier estrategia de prueba debe incorporar la planificacién de la prueba, el disefio de casos de prueba, la eject- cién de la prueba y la recoleccién y evaluacién de los resultados. Una estrategia de prueba de software debe ser suficientemente flexible para promover un uso personalizado de la prueba, Al mismo tiempo, debe ser suficientemente rigida para alentar la planificacién razonable y el seguimiento de la gestién conforme avanza el proyecto. Shooman probe probe de derplgu proce deinen [shos3} analiza estos temas: aca de resin re ect En muchas formas, la prueba es un proceso de individualizacién, y el niimero de tipos diferentes de race de widad «.... pruebas varla tanto como los diferentes acercamientos para su desarrollo. Durante muchos aos, la Seal Aiica defensa conta los errores de programacion fue el diseRo cuidadoso y la nteligencia natural del ee programador. Ahora estamos en una era en a que modemas técnicas de disefio ty revisiones ténicas) tevin dee : fa econ ayudan a educir el mimero de ervores iniciales que son inherentes al eddigo. De igual modo, dferen: va. tes métodos de prueba comienzan a agruparse en métodas y flosofias distintos Estos “enfoques y filosofias” a los que denomino estrategias son el tema que se presenta en este capitulo, En los capitulos 18, 19 y 20 se exponen los métodos y técnicas de prueba que permiten desarrollar la estrategia, TN SOE Eure Qué es? El sofware se prueba para deseu brir errores que se cometieron de manera inad veriida conforme se disefié y consiuyé, Pero, primeras tapas de prucba se enfocan sobre un solo com ponente © un pequete grupe de componentes rlacione ds y se aplican pruebas para descubrir errores en los 4¢émo 50 redlizan las pruebes? ;Debe realizar se un plan formal para las mismas? :Debe probarse el programa complete, come un tode, © aplicar pruebas sélo sobre una pequefia parte de él? Debe volverse o oplicar las pruebas que yo se realizaron mieniras se ogregan revos componentes a un sistema grande? xCuéndo debe involucrarse al cliente? Estas y muchas olras preguntas se responden evand se desarrola una esirategia de prueba de software. 2Quien Io hace? El gerente de proyecto, los ingenieros de software y los expecialsias en pruebas desarrolian una. ‘sirategia para probar el software. Por qué es importante? Con frecuencia, la prueba requiere més esfuerzo que cualquiera otra accién de inge tira dl svar. iw rediza sn orden se despre tiempo, se emplea esfuerze innecesare y, posible que algunos errores posen Swope Por Por tonto, poreceria razonable establecer una eslralega sist maética para probar el software, aCuéles son los pasos? La prueba comienza “por lo ‘pequefio" y avanza “hacia lo grande”, Es decir que las dios y en la ligica de procesamiento que se encapsularon ‘los componentes. Después de probar ésos, deben int ‘grarse hasta que se consiruya el sistema completo. En este punto, se ejecuta una serie de pruebas de orden superior para descubri errores en la satisfaccién de los requer: mientos del clente. Conforme se descubren, los errores dhe dagosicre crepe vendo un procto ue ACuaI es ol producto final? Una Especifcacién pruebas documenta la forma en la que el equipo de sofware pre ppara la prueba al defnir un plan que describe una este toga global y on procedimiento con pasos de prueba ficos y los fpos de pruebas que se reclizarén iCéme me asegure de que fe hice bient Al revisor la Especificacién pruebas antes de realizar las pruebas, es ble vol etn compe le eos de proabay fareas de la misma, Un plan de prueba y procedimientos scivot on darn ale corsfuien orcad dal ware y ol deseubrimiento de errores en eada etapa del proceso de consiruccién 383 [Link]384 PARTE TRES ADMINISTRACION DE LA CALIDAD 17.1 __Un Enroave EstRaTéGico PARA LA PRUEBA DE SOFTWARE co [Link]/-storm pure eos sero peas ee. o> i “trobre pate neil de cuir esuerz response por desarllrun sister de solver Williom Howden La prueba es un conjunto de actividades que pueden planearse por adelantado y realizarse de manera sistematica, Por esta razén, durante el proceso de software, debe definirse una plantilla para la prueba del software: un conjunto de pasos que incluyen métodos de prueba y técnicas de disefio de casos de prucba especificos. _En la literatura sobre el tema, se han propuesto algunas estrategias de prucha de software, ‘Todas proporcionan una plantilla para la prueba y tienen las siguientes caracteristicas genéri- cas: ‘= Para realizar una prueba efectiva, debe realizar revisiones técnicas efectivas (capitulo 15). Al hacerlo, climinara muchos ertores antes de comenzat la prueba ‘= La prueba comienza en los componentes y opera "hacia afwera’, hacia la integracion de todo el sistema de computo, * Diferentes técnicas de prueba son adecuadas para distintos enfoques de ingenieria de software y en diferentes momentos en el tiempo. ‘© Las pruebas las realiza el desarrollador del software y (para proyectos grandes) un grupo de prueba independiente. ‘© Prueba y depuracién son actividades diferentes, pero la depuracién debe incluirse en cualquier estrategia de prueba Una estrategia para la prueba de software debe incluir pruebas de bajo nivel, que son nece- sarias para verificar que un pequeno segmento de cédigo fuente se implements correctamente, asi como pruebas de alto nivel, que validan las principales funciones del sistema a partir de los requerimientos del cliente. Una estrategia debe proporcionar una guia para ef profesional y un conjunto de gutas para el jefe de proyecto. Puesto que los pasos de la estrategia de prueba oct- ren cuiando comienza a aumentar la presién por las fechas limite, el avance debe ser medible {los problemas deben salir ala superficie tan pronto como sea posible 17.1.1 Verificacién y validacién La prueba de software es un elemento de un tema mas amplio que usalmente se conoce como verificacion y validacion (V&V). La venficacin se refiere al conjunto de tareas que garantizan que el software implementa correctamente una funci6n especifica, La validacién es un conjunto diferente de tareas que aseguran que el software que se construye sigue los requerimientos del cliente. Bochm {Boe81] afirma esto de esta forma: Verifcacién: *{Construimos el producto correctamente?” Validacién: “zConstruimas el producto correcto”™ La definicion de V&V abarca muchas actividades de aseguramiento de calidad del software (capitulo 16). La verificacién y Ja validacién ineluyen un amplio arreglo de actividades SQA: revisiones técnicas, auditorias de calidad y configuracién, monitareo de rendimiento, simulacién, estudio de factibilidad, revision de documentacién, revisién de base de datos, analisis de algoritmos, pruebas de desarrollo, pruebas de usabilidad, pruebas de calficacion, pruebas de aceptacién y 1 Bebe notarse que hay una fuerte dvergencia de opnian acerce de qué ties de pruebas constituyen la valida cin. Algunas personas creen que fodas as pruebas siven parla verficacién y que la valiacién se lleva acabo ‘cuando los requrimientos se revisany aprucban,y, mas tarde, pore usuato, cuando el sistema resulta opera- twvo. otras personas ven las pruebas de unidad y de integracién (secciones 173.1 y 173.2) coma verificacién y las de orden superior (secciones 17.6 177) como valdacion [Link]c Coun an rpms ges pas son ona “ed deen” stp toes ve cara coro prc dices kts de ingen de sere Nae fas. loco ada htc de reso ago el woe de sfc. _< Gin “epmine wd ego orl elo progranacée 1 rab slate. Bok i pe de prota oped tne oof de nese pede xpetimantr os carci so CAPITULO 17. ESTRATEGIAS DE PRUEBA DE SOFTWARE 385 pruebas de instalacién. Aunque las pruebas juegan un papel extremadamente importante en ‘Vee, también son necesarias muchas otras actividades. Las pruebas representan el altimo bastién desde donde puede valorarse la calidad y, de ma- era mas pragmatica, descubrirse errores, Pero las pruebas no deben verse como una red de seguridad. Como se dice: “no se puede probar la calidad, Si no esta ali antes de comenzar las pruebas, no estara cuando termine de probar". La calidad se incorpora en el software a lo largo de todo el proceso de ingenieria del software, La adecuada aplicaci6n de métodos y herramien- tas, revisiones técnicas efectivas, y gestion y medicién sélidas conducen a la calidad que se confirma durante las pruebas. Miller (Mil77} relaciona la prueba del software con el aseguramiento de la calidad al afirmar que "la motivacion subyacente de las pruebas de los programas es aflrmar la claridad del soft- ware con métodos que puedan aplicarse de manera econémica y efectiva a sistemas a gran y pequetia escala’. 17.1.2 Organizacién de las pruebas del software En todo proyecto de software hay un conficto inherente de intereses que ocurte conforme co- mienzan las pruebas. Hoy en dia alas personas que construyen el software se les pide probario, En si esto parece sencillo; después de todo, zquién conoce mejor el programa que sus desarro- liadores? Por desgracia, estos mismos desarrolladores tienen nnucho interés en demostrar que el programa est libre de errores, que funciona de acuerdo con los requerimientos del cliente y que se completara a tiempo y dentro del presupuesto, Cada uno de estos intereses tienen un efecto negativo sobre las pruebas mas cuidadosas Desde un punto de vista psicoldgico, el analisis y disefio de software (unto con la codifica cidn) son tareas constructivas, EI ingeniero de software analiza, modela y luego crea un pro- grama de computadora y su documentacién, Como cualquier constructor, el ingeniero de sof- wate esté orgulloso del edificio que construyéy ve con desconfianza.a quien intente derrumbario, Cuando comienzan las pruebas, hay un sutil, pero definitvo, intento por “romper” lo que cons- truy6 el ingeniero de software. Desde el punto de vista del constructor, las pruebas pueden considerarse como (psicoldgicamente) destructivas. De modo que el constructor actuaré con cuidado, y disehara y ejecutara pruebas que demostraran que el programa funciona, en lugar de descubri errores. Desafortunadamente, los errores estaran presentes. ¥ si el ingeniero de soft ware no los encuentta, jel cliente lo harat Con frecuencia, existen algunas malas interpretaciones que pueden inferirse de manera erro nea a partir de la discusién anterior: 1) que el desarrolladar de software no debe hacer pruebas en absoluto, 2) que el sofware debe "ponerse tras una pared” que lo separe de los extrafios que lo probarén sin misericordia, 3) que quienes realicen las prucbas deben involucrarse con el proyecto sélo cuando los pasos de las pruebas estén por comenzar. Cada uno de estos enuncia~ dos es incorrect. El desarvollador de software siempre es responsable de probar las unidades individuales {componentes) del programa y de asegurarse de que cada una desempefia Ia funcién o muestra el comportamiento para el cual se diseRé. En muchos casos, el desarrolladar también realiza pruebas de integracién, una etapa en las pruebas que conduce a la construccién (y prueba) de Ta arguitectura completa del sofware. Solo después de que la arquitectura de software esta completa se involucra tn grupo de prueba independiente (GP3. El papel de un grupo de prueba independiente (GP!) es remover los prablemas inherentes que estén asociados con dejar al constructor probar lo que construy6. Las pruebas independientes Temueven el conficto de intereses que de otto modo puede estar presente. Después de todo, al personal cel GPI se le paga por encontrar errores. Sin embargo, el desarvollador no da el software al GPl y se retira. ily el GP trabajan de ma nera cercana a lo largo del proyecto de software para garantizar que se realizaran pruebas ex- [Link]