Liudmila Betancourt Rivero / liudmila.betancourt@scu.jovenclub.cu

Desarrollar un software con calidad debería ser la meta de todas las empresas desarrolladoras de soluciones informáticas en el mundo, pero no todas aplican dicho principio. El Aseguramiento de la Calidad de un Software (SQA) está basado en un conjunto de actividades bien planificadas y sistemáticas necesarias para tributar a la confianza de que el producto satisfaga los requisitos dados de calidad.

En Cuba también existen empresas desarrolladoras de soluciones informáticas con calidad, entendiéndose esta como el grado con el que un sistema, componente o proceso cumple los requerimientos especificados y las necesidades o expectativas del cliente o usuario  (IEEE, 1990).

Debido a la importancia que tiene para la economía del país, desarrollar software con calidad se hace necesario el diseño y la aplicación de un conjunto de pruebas que aseguren la eliminación de la mayor cantidad de defectos antes del despliegue.

Prueba de software.
Las pruebas se centran principalmente en la evaluación o la valoración de la calidad del producto y representan un elemento crítico para la garantía del mismo. Es una actividad en la cual un sistema o uno de sus componentes se ejecutan en circunstancias previamente especificadas, los resultados se observan y registran y se realiza una evaluación de algún aspecto.

Es el proceso de ejecutar un programa con el fin de encontrar errores. El nombre prueba, además de la actividad de probar, se puede utilizar para designar un conjunto de casos y procedimientos de prueba. (Myers, 1979)

Contexto de las pruebas de software.
La prueba de software debiera verse como un proceso paralelo al desarrollo del software, y que se realiza por el convencimiento de que todo sistema debe ser revisado con el objetivo de establecer si el nivel de calidad requerido es alcanzado. Esto aceptando limitantes prácticas que implican la inconveniente de revisarlo exhaustivamente, pero aplicando técnicas ingenieriles para subsanar estas limitantes.

Objetivo de las pruebas de software.
Diseñar casos de prueba que, sistemáticamente, identifiquen diferentes clases de errores, haciéndolo con la menor cantidad de tiempo y de esfuerzo. La prueba no puede asegurar la ausencia de errores; solo puede demostrar que existen defectos en el software.

Proceso de las pruebas de software.
Las pruebas se realizan a lo largo del desarrollo del sistema y no simplemente al final. Esto significa descubrir problemas no conocidos y no demostrar la perfección de programas manuales o equipo.

Antes de que el sistema sea puesto en aceptación, todos los programas deben ser probados, revisados con datos de prueba y examinados para ver si los módulos trabajan juntos entre ellos, tal como se planeó. Verificar que los módulos trabajen juntos validará que el sistema trabaja como un todo y que estos módulos se integran y funcionan correctamente.

El proceso de prueba tiene dos entradas: la configuración del software que incluye la especificación de requisitos del software, la especificación del diseño y el código fuente y una segunda entrada la configuración de prueba, que incluye un plan y un procedimiento de prueba.

Diseño de pruebas.
Pasos a seguir para realizar pruebas de software:

– Seleccionar qué es lo que debe medir la prueba, es decir, cuál es su objetivo, para qué exactamente se hace la prueba.
– Decidir cómo se va a realizar la prueba que ha de utilizarse para medir la calidad escogida y qué elementos de pruebas se deben usar.
– Diseñar los casos de prueba.
– Determinar cuáles deberían ser los resultados esperados o correctos de los casos de prueba y crear el documento con los diseños de casos de pruebas, antes de realizar la prueba.
– Ejecutar los casos de prueba.
– Comparar los resultados de la prueba con los resultados esperados. Cualquier discrepancia entre ellos significa un error.

Niveles de prueba.
Cuando se le van a aplicar pruebas a un software, se tienen en cuenta una serie de objetivos en diferentes escenarios y niveles de trabajo, debido a que las pruebas son agrupadas por niveles que se encuentran en distintas etapas del proceso de desarrollo. Los niveles de pruebas de software son los siguientes:

– Prueba Independiente.
– Prueba de Unidad.
– Prueba de Integración.
– Prueba del Sistema.
– Pruebas de Rendimiento.
– Pruebas de Aceptación.

Existen otros tipos de pruebas entre ellas:

– Pruebas de Liberación.
– Pruebas Piloto.
– Pruebas Funcionales.
– Prueba de Caja Blanca.
– Prueba de Caja Negra.
– Pruebas de Seguridad.

Las actividades y los artefactos que se generan durante el proceso de prueba, dependen de la metodología de desarrollo utilizada en el desarrollo del software.

Por su parte RUP(Proceso Unificado de Rational o Rational Unified Process) define las siguientes actividades:

– Planificar las pruebas.
– Diseñar las pruebas.
– Implementar las pruebas.
– Realizar pruebas de integración.
– Realizar pruebas de sistema.
– Evaluar pruebas.

Artefactos que se generan:
– Modelo de pruebas.
– Caso de prueba.
– Procedimiento de prueba.
– Componente de prueba.
– Plan de prueba.
– Evaluación de prueba.
– Estrategia de prueba.

Roles que define RUP para el flujo de trabajo prueba.
– Diseñador de pruebas.
– Ingeniero de componentes.
– Ingeniero de pruebas de integración.
– Ingeniero de pruebas de sistema.
– Administrador de prueba.
– Analista de prueba.
– Probador.

Métodos de prueba.
– Método de la Caja Negra: A la mayor parte de los usuarios de programas extensos no les interesa los detalles de su funcionamiento, lo único que desean es conseguir respuestas. Es decir, desean tratar el programa como una caja negra a la cual le introducen datos de entrada y obtienen de ella los datos de salida que esperan. De ahí el nombre de este método. (Beizer, 1990)
– Método de la Caja de Cristal o Caja Blanca: El segundo enfoque en la selección de los datos de prueba inicia con la observación de que un programa difícilmente puede considerarse como probado por completo si su código contiene partes que nunca han sido ejecutadas. En el método de la caja de blanca, se analiza la estructura lógica del programa y, para cada alternativa que pueda presentarse, los datos de prueba ideados conducirán a ella.

Herramientas de prueba.
A continuación se listan algunas de las herramientas que se utilizan en la automatización de pruebas de software en el mundo.

– JCrawler: es una herramienta para realizar pruebas no funcionales (de estrés principalmente) a sistemas de información o aplicaciones desarrolladas en ambiente web.
– WebInject: es una herramienta libre y gratuita (GPL) para realizar test automáticos de aplicaciones y servicios web (SOAP/XML).
– Apache JMeter: aplicación java que nos permite definir comportamientos para casos de pruebas y medir su rendimiento. Válido para contenido estático y dinámico (ficheros, Servlets, scripts de Perl, objetos Java, bases de datos y consultas, FTP).
– Brutus: Un cracker de autenticación de fuerza bruta para redes.

Entregar productos con calidad es la principal exigencia en la industria del software, por lo que se hace necesario el desarrollo de un proceso de pruebas que se encargue de validar la calidad de las soluciones informáticas. Es un proceso que requiere tiempo y esfuerzo, pero que permite que nuestros productos una vez terminados, cumplan con los requerimientos y expectativas del cliente. Una vez aplicado este proceso, se puede constatar que la solución informática probada está a un paso de adquirir la calidad requerida, al permitir encontrar errores en la misma y ser corregidos antes de entregar al cliente.

Referencias

1- Barrio, Francisco José Sáez. 2010. La calidad de las aplicaciones. 2010.
2- Beizer, Boris. 1995. Black-Box Testing. 1995.
3- Brito, Irina Napal y Irina. 2003. Las pruebas de software, su aplicación al Config.CASE.Tesis presentada en opción al título de Ingeniero Informático. Ciudad de la Habana: s.n., 2003.
4- Cortés, Oscar Hernando Guzmán. 2003-2004. Aplicación práctica del diseño de pruebas de software a nivel de programación. 2003-2004.
5- Cueva, Juan Manuel. 1999. Calidad del Software. 1999.
6- Edumilis Méndez, María Pérez, Luis E. Mendoza. 2007. Aplicación de un Método para Especificar Casos de Prueba de Software en la administración pública. Caracas : s.n., 2007.
7- 1990. IEEE Standard Glossary of Software Engineering Terminology. 1990.
8- 1997. IEEE Standard Glossary of Software Engineering Terminology. 1997.
9- Isabel Blank, Larissa Herrera, Miguel Ortiz. 2005. Pruebas Funcionales. 2005.
10- Lovelle, Juan Manuel Cueva. 1999. Calidad del Software. 1999.
11- Myers, Glenford J Myers. 2004. The art of sotware Testing. 2004.
12- Myers, Glenford J. 1979. The art of sotware Testing. 1979.
13- Pressman, Roger S. 2002. Ingeniería del software, un enfoque práctico. 2002.
14- Sáez, Francisco José. 2010. Las Pruebas y la Calidad del Software,ahora una necesidad más que nunca. 2010.
15- Tuya, Javier. 2007. Las Pruebas del software. 2007.
16- Vence, Jose Maria Perez. 2009. Plan de pruebas de integracion. Madrid : s.n., 2009.
17- zonajava. 2005. Métodos de prueba del software. 2005.
18- Noa, Eliane Paz. 2007. Trabajo de diploma para optar por el título de Ingeniero en Ciencias Informáticas, Diseño y aplicación de pruebas al producto “Árbol Genealógico». Habana : s.n., 2007.
19- Santanach, Juan Emilio Vargas y Alejandro. 2010. Trabajo de diploma para optar por el título de Ingeniero en Ciencias Informáticas, Método de Estimación de tiempo y esfuerzo para las pruebas de liberación, aceptación y piloto de los proyectos de desarrollo de software de la Universidad de las Ciencias . Habana: s.n., 2010.

Deja una respuesta

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *