En la actualidad el proceso de desarrollo de software se ha vuelto controversial. Por tal motivo se hace necesario un proceso que guíe a sus desarrolladores. En estos momentos la metodología existente en la Empresa de Aplicaciones Informáticas proporciona una guía de actividades y flujos de trabajo que organiza el proceso de desarrollo de software en esta institución. Para manejar el enorme esfuerzo necesario para ejecutar un proyecto con esta metodología es necesario dividir el mismo en iteraciones. Cada iteración del proceso (entregable realizado) toma como entrada el producto resultado de la iteración anterior y genera como salida un producto incrementado, que deberá ir verificando y validando cada iteración con el área de calidad y el cliente. Este proceso no se aplica a todas las divisiones, está centralizado por regiones (Occidente, Centro y Oriente) lo cual imposibilita medir el avance de la calidad en cada etapa del proyecto. Por lo antes expuesto surgió la necesidad de crear un procedimiento para realizar pruebas parciales en las diferentes iteraciones de desarrollo de software con el fin de limar aquellas asperezas que puedan llegar a manos del usuario final una vez terminado el producto solicitado.
INTRODUCCIÓN
Actualmente en la industria del software la construcción de sistemas va encaminada a productos cada vez más grandes y complejos. Con mucha frecuencia ocurre que se hace necesario producirlos en un breve período de tiempo bajo las especificaciones de los clientes.
El mundo de la comercialización y los negocios se vuelve cada día más competitivo y exige mayor calidad en el proceso de desarrollo y control de la ejecución de los proyectos de software, se hace imprescindible el uso de las más modernas tecnologías de la Informática para garantizar una mayor efectividad en los procesos de desarrollo de software.
Estas situaciones aparejadas a la metodología de desarrollo implementada en las divisiones territoriales de la Empresa de Aplicaciones Informáticas conllevan a implementar un mecanismo para controlar el avance con calidad de los proyectos en cada iteración. Esto propicia que el producto llegue con un mínimo de errores a manos del usuario final.
El objetivo de este trabajo es presentar un procedimiento, detallado a continuación, que establece el proceder en la gestión de la calidad parcial de los productos desarrollados en la División Territorial Guantánamo.
DESARROLLO
Caracterización de la División Territorial Guantánamo
La Empresa de Aplicaciones Informáticas (Desoft) tiene un objeto enfocado a la informatización de la sociedad cubana, para ello se dedica fundamentalmente al desarrollo, comercialización, despliegue y soporte de software, aunque trabaja además líneas como: servicios de movilidad, la formación, la seguridad informática, entre otras. Está estructurada en Divisiones Territoriales y una Oficina Central en la capital, por lo que los especialistas y técnicos que en ella laboran se encuentran distribuidos por todo el país. En la División Territorial Guantánamo el grupo de desarrollo cuenta con 15 integrantes. La duración promedio de cada proyecto es de nueve meses y cada equipo de desarrollo está integrado por tres especialistas cuando más. Las Pruebas de Aceptación se realizan al finalizar cada proyecto según plantea la Metodología de Desarrollo de Desoft en su versión vigente 3.0. El grupo de calidad a nivel nacional se encuentra en la División Territorial de Santi Spíritus y solo revisa los proyectos que posean las características para formar parte de la cartera de productos de la empresa a nivel nacional. En tanto, los demás productos quedan a la merced del criterio de los clientes que en mucha ocasiones no saben expresar lo que quieren y firman las Actas de Aceptación por salir del paso.
Procedimiento de Pruebas de Software
La realización de las pruebas no funcionales cumple un papel importante a la hora de comprobar la calidad de un producto de software, partiendo de la premisa que plantea que cuanto más se pruebe el producto y mientras más grande sea la gama de los tipos de prueba, más se logra un acercamiento a la calidad deseada. El presente documento sirve de guía para la revisión de la Calidad de un producto, está confeccionado siguiendo las normas establecidas en la metodología para el desarrollo de un producto de software en la empresa Desoft. En él se detallan las etapas, los roles con sus responsabilidades, las herramientas y artefactos involucrados en cada etapa, los tipos de pruebas a realizar y el flujo de las no conformidades una vez detectadas.
Alcance
Es aplicable a todas las áreas de desarrollo de las Subdirecciones de Informatización y Centros Territoriales de Servicios Informáticos de las Divisiones Territoriales. Estarán sujetas a este procedimiento las aplicaciones informáticas que constituyan desarrollo a la medida, así como aquellas que puedan o no formar parte de la cartera de productos. También es ajustable a entidades con características de infraestructura semejante y que poseen equipos de desarrollo pequeños.
Objetivo
- Definir los pasos a seguir y requisitos a cumplir para la revisión parcial de sistemas informáticos desarrollados por la División Territorial Guantánamo.
- Lograr que los productos se entreguen con niveles consistentes de calidad que cumplan con las expectativas de los clientes.
- Validar la funcionalidad de los módulos, sistemas e interfaces definidas dentro del alcance del proyecto.
Términos y Definiciones
SW – Software
HW – Hardware
GB – Gigabyte
RAM – Random Access Memory
NC – No Conformidades
EPGD – Especialista Principal del Grupo de Desarrollo
EFC – Especialista en Funciones de Calidad
CP – Caso de Prueba
Etapas del procedimiento
El procedimiento de prueba de software integra un conjunto de actividades que describen los pasos que hay que llevar a cabo en un proceso de prueba como son: la planificación, el diseño de casos de prueba, la ejecución y los resultados, tomando en consideración cuánto esfuerzo y recursos se van a requerir, con el fin de obtener como resultado una correcta construcción del software. La siguiente figura describe gráficamente las etapas del procedimiento de pruebas.
Planificación
En esta etapa se realiza el Comité de Proyecto donde se efectúa un intercambio entre todos los roles que intervienen en el proceso de pruebas. Aquí se confecciona un Acta en cada Reunión como evidencia de la realización del mismo con una periodicidad mensual. También se analizan las etapas correspondientes según los cronogramas de proyectos para decidir cuáles entraran a revisión en el mes en cuestión. Las tareas a realizar en esta etapa son:
- Realizar Comité de Proyectos
- Acordar con los desarrolladores cronograma de pruebas
- Definir cantidad de inspecciones mensuales
- Preparar ambiente de pruebas
Implementación
El objetivo fundamental de esta etapa son las revisiones. Para ello los desarrolladores entregarán al Especialista Principal de Desarrollo los Casos de Pruebas que luego serán entregados al Especialista en Funciones de Calidad para procesarlos y proceder a revisar la aplicación apoyándose en las listas de chequeo. Una vez concluido este proceso se insertarán las no conformidades detectadas en la herramienta mantis para su posterior análisis y monitoreo. Además, se informará al Subdirector de Informatización del estado del proceso mediante un informe parcial luego de culminada cada inspección. Las tareas a realizar en esta etapa son las siguientes:
- Entregar los artefactos
- Realizar las revisiones
- Ejecutar los tipos de pruebas
- Elaborar informe de pruebas parcial
- Monitorear no conformidades
Liberación
En esta etapa se procede a cerrar las no conformidades resueltas una vez confirmada a través de las pruebas de regresión por el Especialista en Funciones de Calidad. También se valoran las principales y más urgentes dificultades encontradas durante todo el proceso de pruebas por el Subdirector de informatización en conjunto con el Especialista Principal de Desarrollo y el Especialista en Función de Calidad y por último se procede a liberar el producto. Por lo que las tareas a realizar en esta etapa serian:
- Realizar pruebas de regresión
- Cerrar no conformidades
- Liberar el módulo
- Elaborar informe de pruebas final
Requisitos necesarios para la recepción del producto
Se creará un ambiente de pruebas donde estará disponible la aplicación a revisar.
Se deberá hacer entrega de clave(s) personalizada(s) según los usuarios del sistema y el expediente de proyecto según la metodología de desarrollo en la etapa correspondiente.
La documentación necesaria deberá ser publicada en la siguiente dirección: ftp://ftpdesarrollo.gtm.desoft.cu al finalizar los viernes de cada semana.
Tipos de pruebas a realizar
Para garantizar el éxito de las inspecciones semanales el Especialista de Calidad se apoyará en algunos tipos de pruebas que se especifican a continuación.
- Pruebas Exploratorias
No son más que un proceso de exploración del producto, que valida la calidad de la entrega, donde se evaluarán los requisitos necesarios para la recepción del producto, de no cumplir con los mismos las pruebas serán abortadas automáticamente.
Pruebas de Integración
Las pruebas de integración se llevan a cabo durante la construcción del sistema, involucran a un número creciente de módulos y terminan probando el sistema como conjunto. Se prueban todos los módulos asociados. Se realizan con el fin de encontrar fallos en las interfaces entre el software y otros con los que interacciona.
Pruebas Funcionales
Evalúan el conjunto de características y capacidades de los componentes del sistema. Aseguran el trabajo apropiado de los requisitos funcionales, incluyendo la navegación, entrada de datos, procesamiento y obtención de resultados.
Función: Consisten en la revisión de las funcionalidades presentes en la aplicación (según Catálogo de Requisitos) fijando la atención en las validaciones, excepciones y servicios.
Seguridad: Asegurar que tanto los datos como el sistema solamente serán accedidos por los actores deseados y cada uno con sus permisos específicos.
Se verifica lo siguiente:
- Que se aplique apropiadamente cada regla de negocio.
- Que los resultados esperados ocurran cuando se usen datos válidos.
- Que sean desplegados los mensajes apropiados de error y precaución cuando se usan datos inválidos.
Pruebas de Usabilidad
Prueba enfocada a factores humanos, estéticos, ayuda sensitiva al contexto y en línea. Errores en la interfaz de usuario como pueden ser: Correspondencia entre sí, similitud en el prototipo, mismo tipo de letra, mismos tipos de botones, íconos, formato, visibilidad, navegabilidad, menús, colores, legibilidad, etc.
Puebas de Fiabilidad
Recuperación y tolerancia a fallas: Verificar que los procesos de recuperación manual o automática restauran apropiadamente la base de datos, aplicaciones y sistemas, y los llevan a un estado conocido o deseado.
Pruebas de Rendimiento
Enfocadas a monitorear el tiempo en flujo de ejecución, acceso a datos, en llamada a funciones y sistema para identificar y direccionar los cuellos de botellas y los procesos ineficientes.
Contención: Enfocada a la validación de las habilidades del elemento a probar para manejar aceptablemente la demanda de múltiples actores sobre un mismo recurso.
Pruebas de Soportabilidad
Configuración: Enfocada a asegurar que funciona en diferentes configuraciones de hardware y software. Esta prueba es implementada también como prueba de rendimiento del sistema.
Instalación: Enfocada a asegurar la instalación en diferentes configuraciones de hardware y software bajo diferentes condiciones, insuficiente espacio en disco, etc.
Pruebas de Regresión
Prueba enfocada a comprobar que las incidencias detectadas en una iteración previa fueron resueltas correctamente por el equipo de proyecto, para poder pasar a la siguiente iteración, en la que se comprobará que no se introdujeron errores al corregir los encontrados anteriormente. El propósito de estas pruebas es asegurar que los defectos identificados en la ejecución anterior de la prueba se han corregido y que los cambios realizados no han introducido nuevos defectos o reintroducido defectos anteriores.
Pruebas de Sistema
Asegura la apropiada navegación dentro del sistema, ingreso de datos, procesamiento y recuperación. Comprueba la implementación apropiada de las reglas de negocio.
Pruebas de Valores Límites
Pruebas diseñadas para evaluar el manejo de error con valores límites o valores extremos. Si una condición de entrada está en un rango de valores entre A y B, se deben diseñar pruebas para los límites A y B, así como para los valores dentro de los límites y por encima de estos.
Herramientas para pruebas de software
Caso de Prueba
Son un conjunto de entradas, condiciones de ejecución y resultados esperados desarrollados para un objetivo particular. Se diseñan aplicando técnicas como las de caja blanca y caja negra. Se ejecutan en el software siguiendo el caso de prueba o se comparan las salidas obtenidas con los resultados esperados con el fin de determinar si existe algún error. Cada caso de pruebas debe tener la identificación y objetivo, la descripción detallada de las entradas, su modo de ejecución y la descripción detallada de las salidas esperadas.
Especifican la forma de probar el sistema, incluyendo las entradas, las precondiciones, la especificación de los actores que realizarán las pruebas y las condiciones bajo las que ha de probarse. Es un conjunto de entradas y resultados esperados que ejercitan a un componente con el propósito de causar fallas y detectar defectos.
Listas de Chequeo
Se define como un listado de preguntas, en forma de cuestionario que sirven para verificar el grado de cumplimiento de determinadas reglas establecidas a priori con un fin determinado. Son fáciles de aplicar, resumir y comparar. Su análisis es rápido, pues consiste en verificar si existe o no un control que es aplicable al objeto analizado.
Informe de Pruebas
Contiene la información acerca de la ejecución de las prueba. Para cada caso de prueba se debe especificar la salida obtenida, y en caso de ser diferente a la esperada, documentar el error encontrado con el mayor nivel de detalle posible. Se debe entregar al Subdirector de Informatización todos los viernes despues de conciliado con el Especialista Principal del Grupo de Desarrollo.
Mantis es un sistema de registro y control de No conformidades. El acceso a la aplicación al ser de tipo Web, se realiza mediante un navegador. El Mantis, no tiene ninguna restricción al tipo de navegador que debe usarse para trabajar como cliente. El objetivo de Mantis es crear y mantener un sistema de control de No conformidades, y está diseñado de manera que sea fácilmente modificable, personalizable y actualizable.
GitLab
Es un servicio web de control de versiones y desarrollo de software colaborativo basado en Git. Además de gestor de repositorios, el servicio ofrece también alojamiento de wikis y un sistema de seguimiento de errores, todo ello publicado bajo una licencia de código abierto.
Nas Desarrollo
Herramienta ftp para el repositorio del código fuente y expedientes de proyectos.
Roles y Responsabilidades
Especialista Principal de Desarrollo:
- Entregar al Esp. en Informática la documentación de los proyectos que van a ser revisados en cada etapa, previa revisión con los desarrolladores designados.
- Revisar y despachar con los desarrolladores las No Conformidades detectadas en las diferentes etapas para cada uno de los proyectos y tomar las medidas pertinentes.
- Tomar decisiones cuando existan discrepancia entre las partes implicadas en las revisiones.
- Enviar al Subdirector de Informatización la relación de proyectos que serán revisados en cada etapa.
Especialista de Calidad:
- Revisar la documentación y aplicaciones recibidas del Esp. Principal.
- Entregar informe de No Conformidades detectadas en la etapa correspondiente al Esp. Principal y al Subdirector de Informatización.
Subdirector de Informatización
- Tomar decisiones estratégicas con respecto a los avances de los proyectos.
Flujo de Trabajo
- Acerca de la documentación que debe entregar el Especialista Principal del Grupo de Desarrollo (EPGD) al Especialista en Funciones de Calidad (EFC).
- El EPGD debe revisar los artefactos y documentos que le entregan sus especialistas según sus respectivos avances. El artefacto principal que se necesita es el Caso de Prueba (CP) de cada proyecto a revisar. Se necesita además acceso a cada módulo integrante de dichos proyectos. En su defecto puede utilizarse el manual de usuario parcial, si existe.
- El EPGD entrega al EFC los artefactos que van a ser revisados a partir del lunes siguiente y notifica de esta acción al Subdirector de Informatización.
- Acerca de las tareas del EFC.
- El EFC debe notificar al Subdirector de Informatización que ha recibido o no los artefactos que va a revisar antes de que finalice la jornada laboral correspondiente al día lunes.
- El EFC debe revisar los documentos de la metodología vigente para los proyectos de desarrollo y elaborar un Informe Parcial (IP) donde reflejará de manera expedita las No Conformidades (NC) que encuentre. Las mismas serán introducidas en la herramienta mantis para su posterior análisis y monitoreo.
- El EFC debe revisar los módulos que haya recibido y utilizar como base el CP recibido del EPGD, o en su defecto el manual de usuario parcial correspondiente a dichos módulos.
- El EFC deberá elaborar un Informe Parcial (IP) donde, además de reflejar de manera expedita las funcionalidades con problemas, tendrá que incluir las pantallas que serán reflejadas en la herramienta mantis para su posterior análisis y monitoreo.
- Acerca de la entrega y discusión del informe resumen del EFC.
- El Informe Parcial (IP) deberá ser enviado por el EFC al EPGD en la tarde del viernes, luego de conciliado con el EPGD. Debe mandar una copia de dicho informe al Subdirector de Informatización.
- Si al momento de la recepción del informe el EPGD encontrara NC que pudieran ser salvadas en no más de 1 día laborable, debe informarlo al Subdirector de Informatización para que este tome decisiones al respecto y en caso de aprobarlo notificarlo de inmediato al EFC.
- El EPGD deberá entregar al EFC los artefactos corregidos a más tardar al día siguiente de la decisión del Subdirector de Informatización.
- Una vez confeccionada la versión definitiva de la revisión de calidad el EFC deberá enviar por correo electrónico dicho Informe Final al EPGD y al Subdirector de Informatización.
- Acerca de las NC detectadas y su solución para la siguiente iteración de pruebas.
- El EPGD debe elaborar un plan de acción para el tratamiento de las NC. Y definir cuáles de dichas NC será considerada nuevamente para la revisión de calidad del siguiente periodo.
- Estas NC deben ser incluidas en los artefactos que entregará a EFC en el siguiente periodo.
RESULTADOS
Con el propósito de respaldar la solución propuesta se escogió un proyecto desktop desarrollado con IDE NetBeans y el lenguaje de programación Java demostrando así la aplicabilidad del procedimiento. Cabe destacar que el proyecto nació junto con la idea de la solución. Las revisiones a este proyecto se han realizado en un periodo de tres años. A continuación se muestran datos estadísticos con el resultado de las mismas.
CONCLUSIONES
En el mercado tan competitivo que existe en la actualidad, sólo los productos de calidad sobreviven. Y la calidad, aunque es una percepción subjetiva del cliente, nace en la filosofía de la empresa, que se esfuerza por ofrecer productos y servicios que superen las expectativas del cliente. Para ello, realizar pruebas del producto es un factor fundamental. Además, para aumentar las probabilidades de detectar errores, incluso menores, es importante que las pruebas la realice otra persona. No es secreto para nadie que es difícil que el que construye el software identifique los propios errores. Por eso es fundamental utilizar herramientas avanzadas y personalizadas para la automatización y la realización de pruebas de software, y contar con un equipo de probadores altamente cualificados.
BIBLIOGRAFÍA
[1] ¿Qué son las metodologías agiles? Disponible en:http://blog.leanmonitor.com/es/que-son-las-metodologias-agiles/
[2] ¿Qué es scrum? Disponible en:http://proyectosagiles.org/que-es-scrum/
[3] Beneficios de aplicar metodologías agiles en el desarrollo de software. Disponible en:http://www.i2btech.com/blog-i2b/tech-deployment/5-beneficios-de-aplicar-metodologias-agiles-en-el-desarrollo-de-software/
[4] Metodologías agiles de desarrollo de software. Disponible en:http://danielgrifol.es/metodologias-agiles-de-desarrollo-de-software/
[5] Metodología para procesos de desarrollo de software v3.0.doc
[6] Jacobson, I. y otros, El Proceso Unificado de Desarrollo de Software, Addison Wesley, Madrid, España, 2000.
[7] Norma ISO/IEC 90003:2006.
[8] Flores, Mariano, Aplicación de una Metodología de Dirección Integrada deProyecto al Sistema Integrado de Gestión Empresarial en la Unión Eléctrica. (SIGEMETODO V1.0), Maestría EOI América-CENSAI, mayo 2001.Moliner, E, Softmétodo V 1.0, Softcal, 2003.
[9] RAFAEL, M. Ingeniería del software. Metodologías de desarrollo, 05.02.2008.
[10] PATRICIO, L. T., EMILIO, A. S. L. Metodologias Ágilesenel Desarrollo de Software.
________________
SOBRE LOS AUTORES
Ing. Arlethy Betancourt Matos trabaja en la Empresa de Aplicaciones Informáticas Desoft, específicamente en la división territorial de Guantánamo, tiene una experiencia de 6 años en el departamento de informatización y hace 3 años se desempeña específicamente en el rol de especialista de calidad de software. Categoría Docente: Instructor Interno de Desoft. Miembro de la Asociación Nacional de Economistas de Cuba ANEC. Unión de Informáticos de Cuba UIC.
Ing. Lian Lisette Hurtado Linares trabaja en la Empresa de Aplicaciones Informáticas Desoft, específicamente en la división territorial de Sancti Spíritus, tiene una experiencia de 9 años en el departamento de desarrollo de software y hace 5 años se desempeña específicamente en el rol de especialista de calidad de software estando al frente de un grupo nacional de revisiones técnicas a los productos de software. Categoría Docente: Instructor Interno de Desoft. Miembro de la Asociación Nacional de Economistas de Cuba ANEC. Unión de Informáticos de Cuba UIC.
