Caracterización de un protocolo de pruebas

Paola Andrea González Montoya LIDIS – Laboratorio de Investigación para el Desarrollo de la Ingeniería de Software

Universidad de San Buenaventura. Cali, Colombia

ing.paolaagm@gmail.com

Resumen—En este artículo se presenta la caracterización del proceso de pruebas para los productos de software que se realizan al interior del programa de ingeniería de sistemas de la Universidad de San Buenaventura. El protocolo de pruebas planteado es el resultado de la investigación 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 gestión 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 implementación de una solución de software, y así generar una mayor satisfacción sobre el uso del producto en el usuario final.

Gestión de calidad; verificación y validación; inspecciones de software; proceso de pruebas.

I. INTRODUCCIÓN

En el ejercicio de la gestión de la calidad, las pruebas que se realizan al software son el mecanismo por el cual el proceso de verificación y validación tiene éxito. Este proceso, es de vital importancia para asegurar la calidad del producto o ser-vicio objetivo del interés del cliente(s) que lo solicita(n), o a aquellos que se toman como punto de partida para dar solución a cierta problemática en general.

Figura 1. Verificación y validación como parte de un

proceso de gestión de calidad

En la Figura 1, el proceso de verificación y validación del software juega un rol importante dentro proceso de gestión de la calidad del software, este proceso toma en cuenta:

• Requerimientos funcionales y requerimientos no funcionales del software.

• Fallos e inconsistencias del sistema.

• Pruebas estáticas y pruebas dinámicas del sistema.

El objetivo del proceso de verificación y validación es establecer la seguridad de que el sistema esta “hecho para un propósito”. Esto significa que el sistema debe ser lo suficientemente bueno para su uso pretendido. (Sommerville, 2005)

II. LAS PRUEBAS DE SOFTWARE

Las pruebas de software son una función del control de calidad y que poseen un objetivo principal: encontrar errores. Son un conjunto de actividades que pueden ser planeadas y conducidas sistemáticamente. 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 más problemas en el sistema. (Sommerville, Pruebas del Software, 2005)

A. Roles en las pruebas de software Las pruebas deben ser diseñadas y ejecutadas por personal

diferente al que realizó el análisis de las reglas del negocio, también de las personas que realizaron los diseños y principalmente, deben ser diferentes a las que realizaron la labor de programación. (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)

Gestión de la Calidad

Sistema de Gestión de la

Calidad

Plan de Aseguramiento de la Calidad

(PAQ)

Control de Calidad

Verificación y Validación

• Analistas, Diseñadores 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, diseñan, analizan y codifican una solución informática. Debido a esa situación, 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.

III. TÈCNICAS PARA APLICAR PRUEBAS DE SOFTWARE

A. Enfoque de caja blanca

Figura 1. Enfoque de diseño de pruebas de caja blanca

Fuente: (Piattini, Calvo-Manzano, Cervera Bravo, & Fernandez Sanz, 2004) De acuerdo con (Pressman, 2010), la prueba de caja blanca

denominada a veces prueba de caja de cristal es un método de diseño de casos de prueba que usa la estructura de control del diseño procedimental para obtener los casos de prueba.

Mediante este método, el ingeniero de software puede

obtener casos de prueba que: (Rojas Rojas & Barrios, 2007) 1. Garanticen que se ejercitan por lo menos una vez

todos los caminos independientes de cada módulo. 2. Ejerciten todas las decisiones lógicas en sus

vertientes verdadera y falsa. 3. Ejecuten todos los bucles en sus límites y con sus

límites operacionales. 4. Ejerciten las estructuras internas de datos para

asegurar su validez.

De acuerdo al enfoque con que se desee diseñar los casos de prueba mediante las técnicas de caja blanca, se puede encontrar divididas en dos grupos característicos:

Pruebas estáticas de caja blanca: es el proceso que

cuidadosa y metódicamente revisa el diseño del software, la arquitectura o el código para encontrar defectos sin necesidad

de ejecutar el código. Esto algunas veces se refiere a un análisis estructural.

Pruebas dinámicas de caja blanca: en estas pruebas se

revisa dentro de la caja, se examina el código y se observa éste mientras se ejecuta. La prueba de caja blanca dinámica, en resumidas palabras, utiliza la información que se obtiene al observar qué hace el código, cómo trabaja, para así determinar qué probar, qué no probar y cómo aproximarse a las pruebas.

B. Enfoque de caja negra

Figura 2. Enfoque de diseño de pruebas de caja negra

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 métodos de caja blanca (Rojas Rojas & Barrios, 2007).

Las pruebas de caja negra para (Pressman, 2010), intentan

encontrar errores de las siguientes categorías: • 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 inicialización y de terminación.

De acuerdo al enfoque con que se desee diseñar los casos

de prueba mediante las técnicas de caja negra, se puede encontrar divididas en dos grupos característicos:

Pruebas de caja negra estáticas, probando la

especificación: la especificación es un documento, no es el programa ejecutándose; esto es lo que se considera estático. Entonces se puede tomar el documento, hacer las pruebas estáticas de caja negra y examinar cuidadosamente esta para encontrar errores.

Pruebas de caja negra dinámicas: es probar el software

sin tener un conocimiento de los detalles del código fuente. Es

dinámica porque el programa se está ejecutando mientras se está probando. Y es caja negra porque se prueba sin tener un conocimiento exacto de cómo trabaja. Se ingresan entradas, se reciben salidas, y se comprueban resultados.

Figura 3. Pruebas de caja negra

Fuente: (Sommerville, Pruebas del Software, 2005) Cuando se prueba el sistema, debería intentarse “romper”

el software eligiendo casos de prueba que pertenecen al conjunto Ee de la Figura 3. Es decir, el objetivo debería ser seleccionar entradas que tienen una alta probabilidad de generar fallos de ejecución en el sistema (salidas del conjunto Se).

(Whittaker, 2002), a raíz de su experiencia personal con las pruebas, desarrolló un conjunto de guías que incrementan la probabilidad de que las pruebas de “defectos” tengan éxito. Algunos ejemplos de dichas guías son:

1. Elegir entradas que fuerzan a que el sistema genere

todos los mensajes de error. 2. Diseñar entradas que hacen que los búferes de

entrada se desborden. 3. Repetir la misma entrada o series de entradas varias

veces. 4. Forzar a que se generen las salidas inválidas. 5. Forzar los resultados de los cálculos para que sean

demasiado grandes o demasiado pequeños.

IV. ESTRATÉGIA PARA APLICAR PRUEBAS DE SOFTWARE

Hay muchas estrategias que pueden ser usadas para probar un software. En un extremo, se podría esperar hasta que el sistema este completamente construido, y sólo 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

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 mayoría 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, trasladándose a las pruebas diseñadas para facilitar la integración de las unidades, y culminando con las pruebas que ejerciten el sistema construido. (Pressman, 2010)

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 más pequeños del programa, que inicialmente probar el software en su totalidad.

B. Pruebas de integración El objetivo de las pruebas de integración es verificar el

correcto ensamblaje entre los distintos componentes una vez que han sido probados unitariamente con el fin de comprobar que interactúan correctamente a través 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 Administración Pública, 2002)

Pruebas  del  Sistema  

Pruebas  de  Integración  

Pruebas  de  Validación  

Pruebas  de  Integración  

Pruebas  de  Unidad  

Pruebas  de  Unidad  

Pruebas  de  Unidad  

Pruebas  de  Unidad  

Pruebas  de  Unidad  

El objetivo es tomar los componentes ya probados unitariamente y construir una estructura que haya sido especificada en el diseño. (Pressman, 2010)

C. Pruebas de validación Las pruebas de validación inician una vez las pruebas de

integración 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 validación o de sistema, la distinción 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 validación La validación de un software se logra a través de una serie

de pruebas que demuestran la conformidad con los requerimientos. Un plan de pruebas describe las clases de pruebas que se realizarán, y un procedimiento de pruebas define casos de prueba específicos que son diseñados para asegurar que todos los requerimientos funcionales se satisfacen, que todas las características de comportamiento se logran, que todo el contenido esta correcta y apropiadamente presentado, que todos los requerimientos de rendimiento son alcanzados, que la documentación es correcta, y que los requerimientos de usabilidad y otros, se logran (por ejemplo, transportabilidad, compatibilidad, la recuperación de errores, mantenibilidad). (Pressman, 2010)

D. Pruebas del sistema Las pruebas de sistema buscan discrepancias entre el

programa y sus objetivos o requerimientos enfocándose en los errores hechos durante la transición del proceso al diseñar la especificación funcional.

Las pruebas de sistema tienen como objetivo ejercitar

profundamente el sistema comprobando la integración del sistema de información globalmente, verificando el funcionamiento correcto de las interfaces entre los distintos subsistemas que lo componen y con el resto de sistemas de información con los que se comunica. (Ministerio de Administración Pública, 2002)

V. PROTOCOLO DE PRUEBAS DE SOFTWARE Basados en la propuesta de una previa configuración del

ambiente de pruebas, el cual se adapte al ciclo de vida y metodologías seleccionadas para desarrollar el producto (software), y de esta forma adaptar el ciclo de vida de las pruebas de software (técnicas de prueba, personal involucrado, etc.) a nuestro proceso de desarrollo. No hay una única forma

definida para realizar pruebas de software, sólo una serie de pautas que nos pueden ayudar a que este proceso sea fácil 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 especificación de

las etapas del proceso de pruebas y las actividades que se deben realizar, pero no se define una metodología de trabajo.

La propuesta de (Black, 2002) se enfoca en la planificación 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. Características del protocolo de pruebas de software

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 documentación del proyecto y la documentación del software que se someterá a pruebas. Tomando como base dicho plan, se entra en detalle diseñando pruebas específicas, basándose en la documentación del software a probar. Una vez detalladas las pruebas, se toma la configuración del software que se va a probar para ejecutar sobre ella los casos, los resultados obtenidos de las pruebas se evalúan mediante la comparación 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 prácticas que no se realizan por parte de ellas, y también, incluir dentro del mismo, las prácticas que han llevado las empresas y que para ellas ha dado resultado.

En la etapa de inspecciones descrita en capítulos

anteriores, se tiene que, las pruebas se deben empezar a estructurar a medida que se diseña 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 construcción del software.

Es necesario entender que, para desarrollar pruebas de

software orientadas a encontrar defectos de programación (pruebas de caja blanca), y que las mismas no representen un gran desgaste y consumo de recursos, tanto humanos como tecnológicos, se requiere de la implantación de pruebas automatizadas, cuya metodología no se tratarán dentro de los alcances de esta investigación.

Consolidar un proceso de pruebas basados en los estudios

realizados sobre la industria de desarrollo Colombiana e internacional y sus prácticas, y tomar los planteamientos expuestos por (Hetzel, 1988) y (Kit, 1995), en el cuál 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 fácil entendimiento y aplicabilidad para los estudiantes del programa de ingeniería de sistemas de la Universidad de San Buenaventura de Cali, mediante el cual sea posible encontrar el mayor número 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 ejecución de inspecciones generalizadas de la especificación del software, que permitan ampliar la visión 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.

2. A partir del refinamiento de requerimientos, se debe iniciar la estructuración del plan de pruebas del sistema.

El plan de pruebas es una recopilación global de las pruebas que se ejecutarán en el sistema en pro de validar que se probarán todos los posibles aspectos de los requerimientos especificados. El plan de pruebas debe contener una descripción de los artefactos de prueba, las características que serán sometidas a pruebas y aquellas que no lo serán, de igual forma, el proceso que se llevará hasta concluir con la fase de pruebas en el proyecto, en cuyo proceso se incluirá el diseño de las pruebas de alto nivel para agrupar las pruebas relacionadas.

3. Para la etapa de diseño, se debe emplear la misma metodología de extracción y mejoramiento del producto que se utilizó para la extracción de requerimientos, mediante el cual, se busca un mayor entendimiento y mejoramiento de las funcionalidades del producto final. Se deben listar las características principales con las cuales el software debe contar para que sea fácil de probar, en este punto de la evaluación del sistema. A partir de esta verificación, se debe siempre tener en cuenta estos aspectos para la implementación del sistema.

4. Diseño de casos de prueba de software, particularizar cada uno de los componentes de software y sus funcionalidades es el primer paso para hacer un diseño detallado de los casos de prueba de software. Se deben identificar los ítems que deben ser probados de acuerdo a la priorización de las funcionalidades realizada durante la etapa de análisis, y priorizar los ítems basándose en los riesgos.

5. Ejecutar todos los casos de prueba que se han especificado y observar los resultados que se obtienen de ellos. La ejecución de estas pruebas incluye:

a) Seleccionar los casos de prueba. b) Configurar del ambiente de pruebas especificado

en el plan de pruebas para su ejecución. c) Ejecutar los casos de prueba. d) Análisis 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 revisión 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 evalúan los casos de prueba en su conjunto y se decide si es necesario o no realizar más pruebas, se estudia el cubrimiento en varios niveles: funciones, requerimientos, lógica. Para esto se toma en cuenta los resultados obtenidos durante la

ejecución 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 ejecución 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 evalúa la efectividad de las pruebas realizadas, tomando en cuenta que se debe evaluar las pruebas respecto al criterio de completitud establecido en la especificación de las pruebas y decidir cuándo parar o agregar más 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

Mediante la implementación 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 satisfacción de un producto cumple a cabalidad su objetivo.

La inclusión 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 demás etapas que la componen (análisis, diseño, implementación, 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 específicas del software y cómo 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 metodología 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 cómo 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.

VII. REFERENCIAS Sommerville, I. (2005). Verificación y Validación. En I. Sommerville, Ingeniería del Software (7ª ed., págs. 469-490). Madrid: Pearson Educación S.A. Pressman, R. (2010). Quality Management. En R. Pressman, Software Engineering: A Practitioner's Approach (7ª ed., págs. 397-555). New York: Mc. Graw Hill. Sommerville, I. (2005). Pruebas del Software. En I. Sommerville, Ingeniería del Software (7ª ed., págs. 491-517). Madrid: Pearson Educación S.A. Rojas Rojas, J., & Barrios, E. J. (2007). INVESTIGACIÓN SOBRE ESTADO DEL ARTE EN DISEÑO Y APLICACIÓN DE PRUEBAS DE SOFTWARE. Recuperado el 27 de Agosto de 2011, de Grupo de Investigación ARQUISOFT: http://gemini.udistrital.edu.co/comunidad/grupos/arquisoft/ Piattini, M. G., Calvo-Manzano, J. A., Cervera Bravo, J., & Fernandez Sanz, L. (2004). En Análisis y diseño de aplicaciones informáticas de gestión: Una perspectiva de ingeniería del software (págs. 419-469). Alfaomega. Whittaker, J. (2002). How to Break Software: A Practical Guide to Testing. Michigan: Addison Wesley. Ministerio de Administración Pública. (2002). Técnicas y Prácticas. Recuperado el 28 de Septiembre de 2011, de Metodología Métrica 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=1317126180000