Caracterizacin de un protocolo de pruebas

Paola Andrea Gonzlez Montoya

LIDIS Laboratorio de Investigacin para el Desarrollo de la Ingeniera de Software Universidad de San Buenaventura. Cali, Colombia ing.paolaagm@gmail.com
ResumenEn este artculo se presenta la caracterizacin del proceso de pruebas para los productos de software que se realizan al interior del programa de ingeniera de sistemas de la Universidad de San Buenaventura. El protocolo de pruebas planteado es el resultado de la investigacin sobre los procesos de aseguramiento de calidad con que actualmente cuenta la industria del desarrollo de software colombiana y el estudio de las estandarizaciones internacionales sobre el proceso de pruebas dentro de la gestin de la calidad. Este proceso de pruebas es independiente del ciclo de vida de desarrollo y cuyo objetivo es impactar el proceso de desarrollo desde el inicio e ir incrementando su efectividad a medida que el producto de software es construido. El objetivo del protocolo de pruebas implementado es generar el menor impacto negativo sobre el resultado final de la implementacin de una solucin de software, y as generar una mayor satisfaccin sobre el uso del producto en el usuario final. Gestin de calidad; verificacin y validacin; inspecciones de software; proceso de pruebas.

En la Figura 1, el proceso de verificacin y validacin del software juega un rol importante dentro proceso de gestin de la calidad del software, este proceso toma en cuenta: Requerimientos funcionales y requerimientos no funcionales del software. Fallos e inconsistencias del sistema. Pruebas estticas y pruebas dinmicas del sistema.

El objetivo del proceso de verificacin y validacin es establecer la seguridad de que el sistema esta hecho para un propsito. Esto significa que el sistema debe ser lo suficientemente bueno para su uso pretendido. (Sommerville, 2005) II. LAS PRUEBAS DE SOFTWARE

I.

INTRODUCCIN

En el ejercicio de la gestin de la calidad, las pruebas que se realizan al software son el mecanismo por el cual el proceso de verificacin y validacin tiene xito. Este proceso, es de vital importancia para asegurar la calidad del producto o servicio objetivo del inters del cliente(s) que lo solicita(n), o a aquellos que se toman como punto de partida para dar solucin a cierta problemtica en general.

Las pruebas de software son una funcin del control de calidad y que poseen un objetivo principal: encontrar errores. Son un conjunto de actividades que pueden ser planeadas y conducidas sistemticamente. Una prueba que no encuentra errores, es una prueba mal realizada, que no fue exitosa. (Pressman, 2010) Las pruebas de software, no pueden demostrar que el sistema se encuentre libre de defectos o que se comportar como se especific en todas las circunstancias. Siempre es posible que una prueba que se haya pasado por alto, hubiese podido descubrir ms problemas en el sistema. (Sommerville, Pruebas del Software, 2005) A. Roles en las pruebas de software Las pruebas deben ser diseadas y ejecutadas por personal diferente al que realiz el anlisis de las reglas del negocio, tambin de las personas que realizaron los diseos y principalmente, deben ser diferentes a las que realizaron la labor de programacin. (Rojas Rojas & Barrios, 2007) En la labor de desarrollo de software existen varios roles que cumplen los integrantes del proyecto, entre esos se destacan los siguientes: (Rojas Rojas & Barrios, 2007)

Gestin de la Calidad
Sistema de Gestin de la Calidad Plan de Aseguramiento de la Calidad (PAQ) Control de Calidad Verificacin y Validacin

Figura 1. Verificacin y validacin como parte de un proceso de gestin de calidad

Analistas, Diseadores y Programadores: este grupo de personas poseen un punto de vista creativo, ya que ellos son los que a partir de una necesidad del cliente, disean, analizan y codifican una solucin informtica. Debido a esa situacin, ellos no alcanzan a divisar los posibles defectos que tiene el software que ellos realizaron. Probador: son las personas responsables de entender las reglas del negocio, requerimientos, casos de uso y todas aquellas cosas que ayuden a comprender el negocio. Este grupo de personas poseen por decirlo de alguna manera un punto de vista destructivo, ya que ellos saben que determinada parte del programa tiene que llevar a cabo ciertas funciones, y ellos en su quehacer tratan de encontrar defectos a la funcionalidad realizada por otra persona. TCNICAS PARA APLICAR PRUEBAS DE SOFTWARE

de ejecutar el cdigo. Esto algunas veces se refiere a un anlisis estructural. Pruebas dinmicas de caja blanca: en estas pruebas se revisa dentro de la caja, se examina el cdigo y se observa ste mientras se ejecuta. La prueba de caja blanca dinmica, en resumidas palabras, utiliza la informacin que se obtiene al observar qu hace el cdigo, cmo trabaja, para as determinar qu probar, qu no probar y cmo aproximarse a las pruebas. B. Enfoque de caja negra

III.

A. Enfoque de caja blanca

Figura 2. Enfoque de diseo de pruebas de caja negra

Fuente: (Piattini, Calvo-Manzano, Cervera Bravo, & Fernandez Sanz, 2004)

Figura 1. Enfoque de diseo de pruebas de caja blanca

Fuente: (Piattini, Calvo-Manzano, Cervera Bravo, & Fernandez Sanz, 2004)

Las pruebas de caja negra se centran en los requisitos funcionales del software (Pressman, 2010). Es decir, la prueba de caja negra permite obtener conjuntos de condiciones de entrada que ejerciten completamente todos los requisitos funcionales de un programa. Se trata de un enfoque que intenta descubrir diferentes tipos de errores que no se encuentran con los mtodos de caja blanca (Rojas Rojas & Barrios, 2007). Las pruebas de caja negra para (Pressman, 2010), intentan encontrar errores de las siguientes categoras:

De acuerdo con (Pressman, 2010), la prueba de caja blanca denominada a veces prueba de caja de cristal es un mtodo de diseo de casos de prueba que usa la estructura de control del diseo procedimental para obtener los casos de prueba. Mediante este mtodo, el ingeniero de software puede obtener casos de prueba que: (Rojas Rojas & Barrios, 2007) 1. 2. 3. 4. Garanticen que se ejercitan por lo menos una vez todos los caminos independientes de cada mdulo. Ejerciten todas las decisiones lgicas en sus vertientes verdadera y falsa. Ejecuten todos los bucles en sus lmites y con sus lmites operacionales. Ejerciten las estructuras internas de datos para asegurar su validez.

Funciones incorrectas o ausentes. Errores de interfaz. Errores en estructuras de datos o en accesos a bases de datos externas. Errores de rendimiento. Errores de inicializacin y de terminacin.

De acuerdo al enfoque con que se desee disear los casos de prueba mediante las tcnicas de caja negra, se puede encontrar divididas en dos grupos caractersticos: Pruebas de caja negra estticas, probando la especificacin: la especificacin es un documento, no es el programa ejecutndose; esto es lo que se considera esttico. Entonces se puede tomar el documento, hacer las pruebas estticas de caja negra y examinar cuidadosamente esta para encontrar errores. Pruebas de caja negra dinmicas: es probar el software sin tener un conocimiento de los detalles del cdigo fuente. Es

De acuerdo al enfoque con que se desee disear los casos de prueba mediante las tcnicas de caja blanca, se puede encontrar divididas en dos grupos caractersticos: Pruebas estticas de caja blanca: es el proceso que cuidadosa y metdicamente revisa el diseo del software, la arquitectura o el cdigo para encontrar defectos sin necesidad

dinmica porque el programa se est ejecutando mientras se est probando. Y es caja negra porque se prueba sin tener un conocimiento exacto de cmo trabaja. Se ingresan entradas, se reciben salidas, y se comprueban resultados.

construye. Este enfoque, aunque es menos atractivo para muchos, puede ser muy efectivo. Desafortunadamente, algunos desarrolladores de software no les gusta usarlo. (Pressman, 2010) Las estrategias de pruebas que usualmente se escogen por la mayora de los equipos de software, caen entre los dos extremos. Se requiere de un enfoque incrementalista de las pruebas, en la Figura 4, se comienza con las pruebas unitarias del programa, trasladndose a las pruebas diseadas para facilitar la integracin de las unidades, y culminando con las pruebas que ejerciten el sistema construido. (Pressman, 2010)

Pruebas del Sistema

Pruebas de Validacin

Figura 3. Pruebas de caja negra

Fuente: (Sommerville, Pruebas del Software, 2005)
Pruebas de Integracin Pruebas de Integracin

Cuando se prueba el sistema, debera intentarse romper el software eligiendo casos de prueba que pertenecen al conjunto Ee de la Figura 3. Es decir, el objetivo debera ser seleccionar entradas que tienen una alta probabilidad de generar fallos de ejecucin en el sistema (salidas del conjunto Se). (Whittaker, 2002), a raz de su experiencia personal con las pruebas, desarroll un conjunto de guas que incrementan la probabilidad de que las pruebas de defectos tengan xito. Algunos ejemplos de dichas guas son: 1. 2. 3. 4. 5. Elegir entradas que fuerzan a que el sistema genere todos los mensajes de error. Disear entradas que hacen que los bferes de entrada se desborden. Repetir la misma entrada o series de entradas varias veces. Forzar a que se generen las salidas invlidas. Forzar los resultados de los clculos para que sean demasiado grandes o demasiado pequeos. ESTRATGIA PARA APLICAR PRUEBAS DE SOFTWARE

Pruebas de Unidad

Pruebas de Unidad

Pruebas de Unidad

Pruebas de Unidad

Pruebas de Unidad

Figura 4. Estrategia para aplicar pruebas a un sistema

Fuente: (Pressman, 2010)

A. Pruebas de unidad Las pruebas de unidad, tienen como objetivo verificar la funcionalidad y estructura de cada componente individualmente una vez que ha sido codificado. (Rojas Rojas & Barrios, 2007) Las pruebas de unidad son un proceso para probar los subprogramas, las subrutinas, los procedimientos individuales o las clases en un programa. Es decir, es mejor probar primero los bloques desarrollados ms pequeos del programa, que inicialmente probar el software en su totalidad.

IV.

Hay muchas estrategias que pueden ser usadas para probar un software. En un extremo, se podra esperar hasta que el sistema este completamente construido, y slo entonces realizar las pruebas sobre el sistema esperando encontrar errores. Este enfoque, aunque atractivo, simplemente no funciona. Resultar en un sistema con lleno de errores que decepcionar a los clientes. En el otro extremo, se pueden realizar pruebas diarias, cada vez que una parte del sistema se

B. Pruebas de integracin El objetivo de las pruebas de integracin es verificar el correcto ensamblaje entre los distintos componentes una vez que han sido probados unitariamente con el fin de comprobar que interactan correctamente a travs de sus interfaces, tanto internas como externas, cubren la funcionalidad establecida y se ajustan a los requisitos no funcionales especificados en las verificaciones correspondientes. (Ministerio de Administracin Pblica, 2002)

El objetivo es tomar los componentes ya probados unitariamente y construir una estructura que haya sido especificada en el diseo. (Pressman, 2010) C. Pruebas de validacin Las pruebas de validacin inician una vez las pruebas de integracin han culminado, cuando los componentes individuales han sido probados, el software est completamente ensamblado como un paquete, y los errores de interfaz han sido descubiertos y corregidos. Al nivel de validacin o de sistema, la distincin entre software convencional, orientado a objetos y aplicaciones web, desaparece. Las pruebas se enfocan en las acciones que perciben los usuarios, y las salidas reconocidas por los mismos. (Pressman, 2010) Criterios de una prueba de validacin La validacin de un software se logra a travs de una serie de pruebas que demuestran la conformidad con los requerimientos. Un plan de pruebas describe las clases de pruebas que se realizarn, y un procedimiento de pruebas define casos de prueba especficos que son diseados para asegurar que todos los requerimientos funcionales se satisfacen, que todas las caractersticas de comportamiento se logran, que todo el contenido esta correcta y apropiadamente presentado, que todos los requerimientos de rendimiento son alcanzados, que la documentacin es correcta, y que los requerimientos de usabilidad y otros, se logran (por ejemplo, transportabilidad, compatibilidad, la recuperacin de errores, mantenibilidad). (Pressman, 2010) D. Pruebas del sistema Las pruebas de sistema buscan discrepancias entre el programa y sus objetivos o requerimientos enfocndose en los errores hechos durante la transicin del proceso al disear la especificacin funcional. Las pruebas de sistema tienen como objetivo ejercitar profundamente el sistema comprobando la integracin del sistema de informacin globalmente, verificando el funcionamiento correcto de las interfaces entre los distintos subsistemas que lo componen y con el resto de sistemas de informacin con los que se comunica. (Ministerio de Administracin Pblica, 2002) V. PROTOCOLO DE PRUEBAS DE SOFTWARE

definida para realizar pruebas de software, slo una serie de pautas que nos pueden ayudar a que este proceso sea fcil y realmente efectivo. Entre las propuestas de los autores y organizaciones respecto al proceso de pruebas, se puede encontrar que: La propuesta de (Kit, 1995), incluye la especificacin de las etapas del proceso de pruebas y las actividades que se deben realizar, pero no se define una metodologa de trabajo. La propuesta de (Black, 2002) se enfoca en la planificacin de las pruebas, definiendo las etapas sin entrar en detalle en sus actividades. (Kanek, Bach, & Pettichord, 2001), han recopilado las lecciones que aprendieron mediante su propia experiencia en las pruebas de software, pero estas, no las han organizado en un proceso definido. (Hetzel, 1988), especifica las etapas de las pruebas junto con el ciclo de vida del software. (Hetzel, 1988), divide el esfuerzo de prueba en etapas, que se realizan al mismo tiempo que el desarrollo. (Whittaker, 2002), define las etapas del proceso de prueba, pero no define detalladamente las actividades de cada una de ellas. (Whittaker, 2002), define 4 etapas de las pruebas de software, que brindan a los testers una estructura para agrupar problemas relacionados que deben resolver antes de seguir con siguiente etapa. (Foundation Level Syllabus) de (International Software Testing Qualifications Board, 2011) (ISTQB), define el proceso de prueba que se compone de las actividades, que si bien son secuenciales, pueden ocurrir concurrentemente. A. Caractersticas del protocolo de pruebas de software

Basados en la propuesta de una previa configuracin del ambiente de pruebas, el cual se adapte al ciclo de vida y metodologas seleccionadas para desarrollar el producto (software), y de esta forma adaptar el ciclo de vida de las pruebas de software (tcnicas de prueba, personal involucrado, etc.) a nuestro proceso de desarrollo. No hay una nica forma

Figura 5. Ciclo completo de las pruebas

Fuente: (Piattini, Calvo-Manzano, Cervera Bravo, & Fernandez Sanz, 2004)

En la Figura 5, (Piattini, Calvo-Manzano, Cervera Bravo, & Fernandez Sanz, 2004) indica que el proceso de pruebas inicia una vez se implemente un plan de pruebas basado en la documentacin del proyecto y la documentacin del software que se someter a pruebas. Tomando como base dicho plan, se entra en detalle diseando pruebas especficas, basndose en la documentacin del software a probar. Una vez detalladas las pruebas, se toma la configuracin del software que se va a probar para ejecutar sobre ella los casos, los resultados obtenidos de las pruebas se evalan mediante la comparacin con la salida esperada y la obtenida. (Rojas Rojas & Barrios, 2007) La idea de este protocolo es mejorar, a partir de los procesos existentes en la industria de desarrollo, aquellas prcticas que no se realizan por parte de ellas, y tambin, incluir dentro del mismo, las prcticas que han llevado las empresas y que para ellas ha dado resultado. En la etapa de inspecciones descrita en captulos anteriores, se tiene que, las pruebas se deben empezar a estructurar a medida que se disea el software, para que as las pruebas abarquen todas las posibles formulas de fallo e inconsistencia, y se puedan desarrollar una vez se complete la construccin del software. Es necesario entender que, para desarrollar pruebas de software orientadas a encontrar defectos de programacin (pruebas de caja blanca), y que las mismas no representen un gran desgaste y consumo de recursos, tanto humanos como tecnolgicos, se requiere de la implantacin de pruebas automatizadas, cuya metodologa no se tratarn dentro de los alcances de esta investigacin. Consolidar un proceso de pruebas basados en los estudios realizados sobre la industria de desarrollo Colombiana e internacional y sus prcticas, y tomar los planteamientos expuestos por (Hetzel, 1988) y (Kit, 1995), en el cul integran el proceso de pruebas al ciclo de vida de desarrollo del software, se debe implementar un proceso que sea aplicable al contexto educativo, que el mismo sea de fcil entendimiento y aplicabilidad para los estudiantes del programa de ingeniera de sistemas de la Universidad de San Buenaventura de Cali, mediante el cual sea posible encontrar el mayor nmero de errores presentes en el producto desarrollado. Este proceso se encuentra demarcado por las siguientes pautas: 1. Refinamiento de los requerimientos del software mediante la ejecucin de inspecciones generalizadas de la especificacin del software, que permitan ampliar la visin de negocio y del producto que se requiere desarrollar. Mediante estas inspecciones se pueden encontrar inconsistencias entre funcionalidades mal descritas y/o mal enlazadas entre las otras funcionalidades del software. A partir del refinamiento de requerimientos, se debe iniciar la estructuracin del plan de pruebas del sistema.

El plan de pruebas es una recopilacin global de las pruebas que se ejecutarn en el sistema en pro de validar que se probarn todos los posibles aspectos de los requerimientos especificados. El plan de pruebas debe contener una descripcin de los artefactos de prueba, las caractersticas que sern sometidas a pruebas y aquellas que no lo sern, de igual forma, el proceso que se llevar hasta concluir con la fase de pruebas en el proyecto, en cuyo proceso se incluir el diseo de las pruebas de alto nivel para agrupar las pruebas relacionadas. 3. Para la etapa de diseo, se debe emplear la misma metodologa de extraccin y mejoramiento del producto que se utiliz para la extraccin de requerimientos, mediante el cual, se busca un mayor entendimiento y mejoramiento de las funcionalidades del producto final. Se deben listar las caractersticas principales con las cuales el software debe contar para que sea fcil de probar, en este punto de la evaluacin del sistema. A partir de esta verificacin, se debe siempre tener en cuenta estos aspectos para la implementacin del sistema. Diseo de casos de prueba de software, particularizar cada uno de los componentes de software y sus funcionalidades es el primer paso para hacer un diseo detallado de los casos de prueba de software. Se deben identificar los tems que deben ser probados de acuerdo a la priorizacin de las funcionalidades realizada durante la etapa de anlisis, y priorizar los tems basndose en los riesgos. Ejecutar todos los casos de prueba que se han especificado y observar los resultados que se obtienen de ellos. La ejecucin de estas pruebas incluye: a) Seleccionar los casos de prueba. b) Configurar del ambiente de pruebas especificado en el plan de pruebas para su ejecucin. c) Ejecutar los casos de prueba. d) Anlisis posterior de los resultados obtenidos, para esto es necesario completar el log de pruebas. e) Registrar actividades, resultados e incidentes. f) Determinar si las fallas fueron causadas por errores en el producto o en las pruebas. Se debe completar el formato de revisin de los casos de prueba, para determinar estas fallas y tomar las acciones necesarias. 6. Finalizando la etapa de pruebas del proyecto, se debe evaluar el cubrimiento de las pruebas: Se evalan los casos de prueba en su conjunto y se decide si es necesario o no realizar ms pruebas, se estudia el cubrimiento en varios niveles: funciones, requerimientos, lgica. Para esto se toma en cuenta los resultados obtenidos durante la

4.

5.

2.

ejecucin y con esto dar paso a evaluar de los errores del producto, con lo cual se busca evaluar la calidad del producto respecto a la ejecucin de las pruebas realizadas. Esto se logra tomando en cuenta la cantidad de casos de prueba ejecutados, qu porcentaje de estos encontraron errores y qu porcentaje de estos errores fueron corregidos. Por ltimo, se evala la efectividad de las pruebas realizadas, tomando en cuenta que se debe evaluar las pruebas respecto al criterio de completitud establecido en la especificacin de las pruebas y decidir cundo parar o agregar ms pruebas y seguir, se basa en los resultados obtenidos del cubrimiento de las pruebas y los errores encontrados en el producto que anteriormente se describieron. VI. CONCLUSIONES

VII. REFERENCIAS
Sommerville, I. (2005). Verificacin y Validacin. En I. Sommerville, Ingeniera del Software (7 ed., pgs. 469-490). Madrid: Pearson Educacin S.A. Pressman, R. (2010). Quality Management. En R. Pressman, Software Engineering: A Practitioner's Approach (7 ed., pgs. 397555). New York: Mc. Graw Hill. Sommerville, I. (2005). Pruebas del Software. En I. Sommerville, Ingeniera del Software (7 ed., pgs. 491-517). Madrid: Pearson Educacin S.A. Rojas Rojas, J., & Barrios, E. J. (2007). INVESTIGACIN SOBRE ESTADO DEL ARTE EN DISEO Y APLICACIN DE PRUEBAS DE SOFTWARE. Recuperado el 27 de Agosto de 2011, de Grupo de Investigacin ARQUISOFT: http://gemini.udistrital.edu.co/comunidad/grupos/arquisoft/ Piattini, M. G., Calvo-Manzano, J. A., Cervera Bravo, J., & Fernandez Sanz, L. (2004). En Anlisis y diseo de aplicaciones informticas de gestin: Una perspectiva de ingeniera del software (pgs. 419-469). Alfaomega. Whittaker, J. (2002). How to Break Software: A Practical Guide to Testing. Michigan: Addison Wesley. Ministerio de Administracin Pblica. (2002). Tcnicas y Prcticas. Recuperado el 28 de Septiembre de 2011, de Metodologa Mtrica v3: http://administracionelectronica.gob.es/recursos/pae_000001039.pdf Kit, E. (1995). Software Testing In The Real World: Improving The Process. Addison Wesley. Black, R. (2002). Managing the Testing Process (2 ed.). Wiley. Kanek, C., Bach, J., & Pettichord, B. (2001). Testing Techniques. In Lessons Learned in Software Testing (1 ed.). Wiley. Hetzel, B. (1988). The complete guide to Software Testing (2 ed.). QED Information Sciences Inc. Pol, M., Teunissen, R., & Van Veenendaal, E. (2002). Software Testing: A Guide to the TMap Approach. Michigan: Addison-Wesley. International Software Testing Qualifications Board. (Marzo de 2011). Foundation Level Syllabus 2011. Recuperado el 12 de Diciembre de 2011, de Certified Tester Foundation Level Syllabus: http://istqb.org/download/attachments/5439583/ISTQB_Foundation+ Level+Syllabus_2011.pdf?version=1&modificationDate=131712618 0000

Mediante la implementacin de un proceso adecuado de pruebas de software, se tiene que el aseguramiento de la calidad del producto desarrollado debe primar sobre cualquier objetivo contemplado durante el desarrollo del mismo. Las pruebas de software contemplan el mecanismo adecuado para brindar al usuario la satisfaccin de un producto cumple a cabalidad su objetivo. La inclusin del proceso de pruebas dentro de un ciclo de vida de desarrollo del software, se debe realizar gradualmente y de tal forma que no se vean impactados significativamente, las dems etapas que la componen (anlisis, diseo, implementacin, etc.). El criterio para evaluar un sistema, se debe basar en el conocimiento previo y enriquecido a cerca de sus funcionalidades exactas, es decir, para saber qu se debe evaluar, se debe tener un gran conocimiento sobre las funcionalidades especficas del software y cmo se espera que el usuario final entienda el producto. Basar el procedimiento en una serie de pautas a seguir es la forma mas acertada de enfocar el proceso de pruebas planteado, dado que un nico procedimiento de pruebas no es posible se adapte a cualquier tipo de desarrollo, tomando en cuenta factores como el ciclo de vida, la metodologa de desarrollo, el personal disponible para el desarrollo del producto, la complejidad del sistema a desarrollar, el tipo de sistema a desarrollar, etc.; es por esto que el enfoque del procedimiento de pruebas planteado se basa en el conocimiento general de cmo realizar las pruebas de software y el planteamiento de una serie de puntos que se deben tener en cuenta al plantear una etapa de pruebas para el desarrollo de software en un proyecto.