Universidad de las Ciencias Informáticas Facultad # 3 Turismo y Negocios.
Título: Proceso de Pruebas para el Módulo Mercantil del Proyecto Registros y Notarías
Trabajo de Diploma para optar por el título de Ingeniero en Ciencias Informáticas.
Autor(es): Evelyn Domínguez Ayub Ariadne Delgado Hernández
Tutor: Ing. Yanosky Rios La Hoz
Junio 2007
Declaración de Autoría
Declaramos que somos las únicas autoras de este trabajo y autorizamos al <nombre área> de la Universidad de las Ciencias Informáticas a hacer uso del mismo en su beneficio.
Para que así conste firmamos la presente a los ____ días del mes de ________ del año ________.
_____________________________ ______________________________
Ariadne Delgado Hernández Evelyn Domínguez Ayub Autor Autor
____________________________
Ing. Yanosky Ríos La Hoz
II
Agradecimientos
A mis padres, guardianes de mi bienestar y desarrollo profesional. Los que me han dado el mayor impulso para salir adelante. Los adoro.
A mi hermana, por peleona, pero a pesar de todo tienes la razón en muchas cosas.
A Rogito por cuidarme, apoyarme y brindarme todo su amor y cariño. Y sobre todo enseñarme a ver un poquito más allá de lo visible. Te quiero mucho.
A mis profesores que admiro mucho, en especial a Belkis, Berena, Susana y Pedro.
A Ameirys y Alianis por su dedicación y amistad.
A Evelyn por entenderme.
A Daimi por hacerme reir.
A Yonnito por su apoyo incondicional y por ser tan buena persona.
En general a todos mis compañeros por hacerme la vida más placentera, por su paciencia, ayuda y dedicación en los momentos más difíciles.
Mil Gracias!!…Ariadne
A mis padres, quienes me enseñaron a nadar contra la corriente…gracias por tanto amor y por ser mi guía.
A mi hermano… por vivir y traer nuevas energías al hogar, gracias por confiar en mí.
A Jai: Sin Palabras, Con todo el Corazón…
A mis amigos, los que han pasado y los que se han quedado....Anais, Dayi, Yasmina, Yuli, Nela, Ariadne, Lily, Ali…por tener siempre una sonrisa, mil gracias ¡!
A mi familia…
Gracias…Evelyn
A todos los que contribuyeron amable y desinteresadamente con la realización de este trabajo, con su tiempo, conocimiento y experiencia.
A nuestro tutor Yanosky Ríos por los conocimientos impartidos y por guiarnos en nuestro
trabajo.
III
Dedicatoria A MIS PADRES:
Alina Hernández Joel Delgado Gómez.
A MI HERMANA:
Yalina Delgado Hernández
A mi familia y especialmente a mi abuelita Celia y mi tía Arasmelis.
A mi novio:
Roger Alemay Tórres A mis amigos.
IV
Resumen
Uno de los factores de éxito más relevantes en el desarrollo de los proyectos de software es que éste sea capaz de satisfacer las necesidades y expectativas de sus usuarios. Lograr un producto final con el nivel de calidad requerido depende en gran medida de tener organizado de forma integral el proceso de pruebas a lo largo del ciclo de vida del proyecto. En el contexto de este trabajo se presenta la aplicación del proceso de pruebas de software al módulo Mercantil del Proyecto Registros y Notarías. Se describen los diferentes artefactos o entregables desarrollados durante la planificación y ejecución de las pruebas en dicho módulo, el Plan de Pruebas para seleccionar y coordinar todas las actividades del proceso, la Estrategia de Pruebas que facilita el análisis de cómo plantear la pruebas en el ciclo de vida del proyecto, los Datos a ser utilizados en el diseño de los diferentes Casos de Pruebas, la Configuración del Entorno para determinar las características del hardware y software necesarios para la ejecución de las pruebas, así como la Evaluación de los Resultados de las pruebas aplicadas.
Palabras Claves
Calidad de Software, Pruebas de Software, Artefactos de Pruebas, Plan de Pruebas, Estrategia de Pruebas, Casos de Pruebas, Datos de Pruebas, Evaluación de Pruebas, Errores.
V
Índice
INTRODUCCIÓN ... 1
SITUACIÓN PROBLÉMICA ... 1
OBJETIVO GENERAL ... 2
OBJETIVOS ESPECÍFICOS ... 2
OBJETO DE ESTUDIO ... 2
CAMPO DE ACCIÓN ... 2
HIPÓTESIS ... 2
TAREAS DE INVESTIGACIÓN ... 2
CAPÍTULO 1: FUNDAMENTACIÓN TEÓRICA ... 4
1.1. INTRODUCCIÓN ... 4
1.2. ESTADO ACTUAL ... 4
1.3. PRUEBAS DE SOFTWARE ... 6
1.3.1. Pruebas de Unidad ... 7
1.3.2. Prueba de Caja Negra ... 7
1.3.3. Prueba de Caja Blanca ... 8
1.3.4. Prueba de Integración ... 9
1.3.4.1. Prueba de regresión ... 9
1.3.5. Pruebas de Validación ... 9
1.3.6. Pruebas de Sistemas ...10
1.3.6.1. Prueba de Procedimientos ...10
1.3.6.2. Prueba de Recuperación ...10
1.3.6.3. Prueba de Factores Humanos ...10
1.3.6.4. Prueba de Carga Máxima ...11
1.3.6.5. Prueba de Almacenamiento ...11
1.3.6.6. Prueba de Tiempo de Ejecución ...11
1.4. METODOLOGÍAS ...11
1.4.1. RUP (Rational Unified Process) ...11
1.4.1.1. Artefactos del Proceso de Pruebas. ...12
1.4.1.1.1. Modelo de Pruebas ...12
1.4.1.1.2. Caso de Prueba ...12
1.4.1.1.3. Procedimiento de Prueba ...13
VI
1.4.1.1.4. Componente de Prueba ...13
1.4.1.1.5. Plan de Prueba ...13
1.4.1.1.6. Defecto ...14
1.4.1.1.7. Evaluación de Prueba ...14
1.4.1.1.8. Estrategias de Pruebas del Software ...14
1.4.2. XP (Extreme Programing) ...14
1.4.3. Test Driven Development (Desarrollo basado en Pruebas) ...15
1.4.4. TPI (Test Process Improvement) ...16
1.4.5. TMap (Test Management approach) ...18
1.5. HERRAMIENTAS ...18
1.5.1. Rational Rose ...19
1.5.2. Rational TestManager (Administración de pruebas) ...19
1.5.3. Rational Manual Tester ...19
1.5.4. Rational ClearQuest y Functional Testing ...20
1.6. CONCLUSIONES ...20
CAPÍTULO 2: ARTEFACTOS DEL PROCESO DE PRUEBAS. ...21
2.1. INTRODUCCIÓN ...21
2.2. PLAN DE PRUEBAS ...21
2.2.1. Propósito ...21
2.2.2. Alcance ...22
2.2.3. Definición, Acrónimos y Abreviaturas ...22
2.2.4. Información del Proyecto ...22
2.2.5. Listado Requerimientos ...22
2.2.5.1. Pruebas de Funcionalidad ...22
2.2.5.1.1. Sesión ...22
2.2.5.1.2. Administración Local ...23
2.2.5.1.3. Denominación Mercantil ...23
2.2.5.1.4. Presentación ...23
2.2.5.1.5. Gestión Documental ...23
2.2.5.1.6. Revisión Legal ...23
2.2.5.1.7. Archivo ...23
2.2.5.1.8. Supervisión ...23
2.2.5.2. Pruebas de Interfaz de Usuario ...24
VII
2.2.6. Estrategia de Pruebas ...24
2.2.6.1. Pruebas de Funcionalidad ...24
2.2.6.2. Pruebas de Interfaz de Usuario ...24
2.2.7. Trabajadores...25
2.2.8. Sistema ...25
2.2.9. Hitos del proceso de Pruebas ...26
2.2.10. Entregables del Proyecto ...26
2.2.11. Tareas del Proceso de Pruebas ...26
2.3. ESTRATEGIA DE PRUEBAS ...27
2.3.1. Propósito ...27
2.3.2. Alcance ...28
2.3.3. Técnicas de Pruebas ...28
2.4. DICCIONARIO DE DATOS ...29
2.4.1. Definición de Clases Válidas y no Válidas ...29
2.4.1.1. Denominación Mercantil ...29
2.4.1.1.1. Realizar Búsqueda ...29
2.4.1.1.2. Reservar Nombre ...29
2.4.1.1.3. Activar Nombre ...31
2.4.1.2. Presentación ...31
2.4.1.2.1. Trámites no Constitutivos ...31
2.4.1.3. Gestión Documental ...32
2.4.1.3.1. Recaudos del Trámite ...32
2.4.1.4. Supervisión ...33
2.4.1.4.1. Editar Datos de Persona ...33
2.4.2. Datos Reales de Pruebas ...34
2.4.2.1. Denominación Mercantil ...34
2.4.2.1.1. Solicitud de una Denominación Mercantil. ...34
2.4.2.1.2. Realizar Búsqueda ...35
2.4.2.1.3. Reservar Nombre ...35
2.4.2.1.4. Activar Nombre ...36
2.4.2.2. Presentación ...36
2.4.2.2.1. Trámites No Constitutivos ...36
2.4.2.3. Gestión Documental ...37
2.4.2.3.1. Recaudos del Trámite ...37
VIII
2.4.2.4. Supervisión ...37
2.4.2.4.1. Editar Datos de Persona ...37
2.5. CASOS DE PRUEBAS ...38
2.5.1. Propósito ...38
2.5.2. Casos de Pruebas ...39
2.5.2.1. Sesión ...39
2.5.2.1.1. CPR 1. Verificar la funcionalidad de Bloquear y Desbloquear Sesión. ...39
2.5.2.1.2. CPR 2. Verificar la funcionalidad Tiempo de Bloqueo...40
2.5.2.1.3. CPR 3. Verificar la funcionalidad de Cambiar Contraseña. ...42
2.5.2.1.4. CPR 4. Verificar la funcionalidad Cerrar Sesión. ...44
2.5.2.2. Administración Local ...45
2.5.2.2.1. CPR 5. Verificar la funcionalidad de Gestión de Roles. ...45
2.5.2.2.2. CPR 6. Verificar la funcionalidad de Restablecer Contraseña. ...47
2.5.2.3. Denominación Mercantil ...50
2.5.2.3.1. CPR 7. Verificar Funcionalidad de la Búsqueda por Parámetros ...50
2.5.2.3.2. CPR 8. Verificar que se capturen correctamente los Datos del Presentante entrados al sistema. ...51
2.5.2.3.3. CPR 9. Verificar el funcionamiento de la solicitud de una Denominación Mercantil. ...57
2.5.2.3.4. CPR 10. Verificar la funcionalidad de búsqueda fonética de Coincidencias de Denominación. ...60
2.5.2.3.5. CPR 11. Verificar la funcionalidad de Reserva de Nombre. ...62
2.5.2.3.6. CPR 12. Verificar la funcionalidad de Activar Nombre. ...63
2.5.2.3.7. CPR 13. Verificar la funcionalidad de Análisis de Coincidencias. ...65
2.5.2.4. Presentación ...66
2.5.2.4.1. CPR 14. Verificar la funcionalidad de Trámites No Constitutivos. ...66
2.5.2.4.2. CPR 15. Verificar la funcionalidad Cambio de Otorgante. ...72
2.5.2.5. Gestión Documental ...74
2.5.2.5.1. CPR 16. Verificar la funcionalidad de Digitalización de Documentos. ...74
2.5.2.5.2. CPR 17. Verificar la funcionalidad de Gestionar Recaudos. ...75
2.5.2.5.3. CPR 18. Verificar la funcionalidad de Solicitud de Expedientes. ...77
2.5.2.5.4. CPR 19. Verificar la funcionalidad de Aceptar Expedientes Solicitados. ...79
2.5.2.6. Revisión Legal ...80
2.5.2.6.1. CPR 20. Verificar Funcionalidad de Reasignar Funcionario. ...80
IX
2.5.2.7. Archivo ...82
2.5.2.7.1. CPR 21. Verificar la funcionalidad de Actualizar Custodia. ...82
2.5.2.7.2. CPR 22. Verificar la funcionalidad de Localizador de Expediente. ...84
2.5.2.7.3. CPR 23. Verificar la funcionalidad de Libro de Control. ...85
2.5.2.8. Supervisión ...87
2.5.2.8.1. CPR 24. Verificar la funcionalidad de Cambiar el Estado del trámite. ...87
2.5.2.8.2. CPR 25. Verificar la funcionalidad de Editar Datos Personas. ...88
2.5.2.8.3. CPR 26. Verificar la funcionalidad de Actividades del Registro. ...91
2.6. CONFIGURACIÓN DEL ENTORNO DE PRUEBAS ...93
2.6.1. Propósito ...93
2.6.2. Alcance ...93
2.6.3. Descripción física de la Configuración de una Oficina Mercantil ...93
2.6.4. Breve descripción del Entorno de Prueba ...94
2.6.5. Inventario de Hardware ...95
2.6.6. Inventario de Software ...95
2.7. CONCLUSIONES ...96
CAPÍTULO 3 EVALUACIÓN DE RESULTADOS DEL PROCESO DE PRUEBAS. ...97
3.1. EVALUACIÓN DE PRUEBAS ...97
3.1.1. Introducción ...97
3.1.2. Alcance ...98
3.1.3. Sumario de Evaluación ...98
3.1.3.1. Cobertura de la Prueba ...98
3.1.3.1.1. Casos de Pruebas Incorrectos ... 100
3.1.3.2. Análisis de Defectos ... 105
3.1.3.3. Evaluación del Resultado de las Pruebas del Sistema. ... 106
3.1.3.3.1. Listas de Comprobación para interfaz Windows. ... 106
3.1.3.4. Conclusiones de la Evaluación. ... 113
CONCLUSIONES GENERALES ... 114
RECOMENDACIONES ... 115
BIBLIOGRAFÍA ... 116
ANEXOS ... ¡ERROR! MARCADOR NO DEFINIDO. GLOSARIO DE TÉRMINOS ... 118
1
Introducción
El desarrollo de sistemas de información se ve sometido actualmente a grandes exigencias en cuanto a productividad y calidad, y se hace necesaria la aplicación de un nuevo enfoque en la producción del software, más cercano a una disciplina de ingeniería que a los hábitos y modos artesanales que desafortunadamente se han venido aplicando en más de una ocasión.
La producción de aplicaciones informáticas debe abordarse, por tanto, con técnicas y metodologías adecuadas, acompañadas por una precisa gestión de proyectos y una eficaz gestión de la calidad. Un importante elemento para lograr la calidad en un producto de software es el proceso de pruebas, que no es más que un arte, un trabajo que requiere una buena dosis de mala intención y añade valor al producto que se maneja.
Situación Problémica
:En la Universidad de las Ciencias Informáticas, específicamente en la Facultad 3 un grupo de estudiantes y profesores están implementando un sistema para estandarizar la gestión de las oficinas de Registros y Notarías de la República Bolivariana de Venezuela y así lograr establecer una forma única de dirigir y controlar la información. La finalidad del sistema en cuestión se centra en automatizar los Registros Mercantiles e Inmobiliarios para gestionar de forma eficiente todas las actividades: atención al cliente, gestión documental, gestión administrativa y contable, comunicaciones con las diferentes instituciones, organismos públicos y entidades a través de servicios. El sistema consta de cuatro módulos: Inmobiliario, Mercantil, Administración Contable y Servicio Autónomo, específicamente los Registros Mercantiles recogen cuatro funciones principales: Inscripción de Actos de Comercio, Solicitud de Copias Certificadas, Solicitud de Sellado de Libros y Solicitud de Acceso a los Expedientes. Para lograr que las diversas funcionalidades del sistema automatizado garanticen la generación de los trámites de forma rápida y concisa y así ofrezcan un mejor servicio a los clientes de los Registros Mercantiles, es de vital importancia que desde fases tempranas del desarrollo del sistema se realice una adecuada planificación y gestión del Proceso de Pruebas, que permita obtener el mayor número de errores posibles y por tanto contribuir a la mejora de la calidad del producto. Dada la no existencia en el módulo Mercantil, de una definición de un plan estratégico, objetivos, recursos, para organizar un proceso de pruebas efectivo surge el siguiente problema a resolver:
¿Cómo desarrollar un adecuado Proceso de Pruebas en el módulo Mercantil del Proyecto Registros y Notarías?
2
Objetivo general
:Desarrollar un adecuado Proceso de Pruebas en el módulo Mercantil del Proyecto Registros y Notarías que permita encontrar la mayor cantidad de errores posibles en el software.
Objetivos específicos
:1.
Realizar un Plan de Prueba para identificar toda la información existente en el proyecto y los recursos requeridos.2.
Elaborar la Estrategia de Prueba para definir todo el proceso estratégico y la forma en que será probado el software.3.
Elaborar los diferentes Casos de Pruebas que describan aspectos específicos del sistema y las distintas funcionalidades a probar.4.
Elaborar los Datos de Pruebas para su posterior uso a lo largo del proceso.5.
Confeccionar la Configuración del Entorno de Prueba para especificar la forma en que será distribuido el hardware y el software para la aplicación de las pruebas.6.
Realizar la Evaluación del Resultado de las Pruebas para medir la calidad objetiva del producto a partir de dichos resultados.Objeto de Estudio
:Proceso de pruebas de software.
Campo de Acción
:Proceso de pruebas de software en el Módulo Mercantil del Proyecto Registros y Notarías.
Hipótesis
:Si se desarrolla un adecuado proceso de pruebas en el módulo Mercantil del Proyecto Registros y Notarías entonces se podrá encontrar la mayor cantidad de errores posibles en el software.
Tareas de Investigación
:1. Investigar sobre tendencias y tecnologías actuales vinculadas al Proceso de Pruebas.
2. Estudiar conceptos, métodos y procedimientos relacionados a la aplicación de pruebas al sistema.
3. Estudiar el manual de especificación de casos de usos y el manual de usuario del Módulo Mercantil para un buen entendimiento de la aplicación a la hora de diseñar y ejecutar los Casos de Pruebas.
3 4. Aplicar la plantilla confeccionada por el departamento central de calidad de la
universidad (Calisoft) para el diseño de los Casos de Pruebas.
5. Aplicar las diferentes plantillas que propone la ayuda de RUP para la elaboración de los diferentes artefactos a desarrollar en el proceso de pruebas.
6. Diseñar los Casos de pruebas utilizando la técnica de Caja Negra.
7. Analizar el manual de Arquitectura y el manual de Tecnología para la Configuración del Entorno de Pruebas.
8. Realizar un estudio de las características del hardware y software de las computadoras a utilizar para la Configuración del Entorno de Pruebas.
9. Analizar la clasificación de los errores en cuanto a prioridad, que propone la ayuda de RUP para el reporte de la evaluación de los resultados de las pruebas.
10. Aplicar la plantilla que elaboró Calisoft para la aplicación de las Listas de Comprobación.
El presente trabajo se encuentra estructurado por tres capítulos y anexos, ambos contenedores de todo el trabajo investigativo y práctico realizado:
Capítulo 1: En este capítulo se aborda fundamentalmente el estado actual de las actividades relacionadas con el Proceso de Pruebas. Se realiza además un estudio sobre metodologías, herramientas y conceptos fundamentales del proceso.
Capítulo 2: Se elaboran los artefactos propuestos por RUP y requeridos (Plan de Pruebas, Estrategia de Pruebas, Datos de Pruebas, Configuración del Entorno de Pruebas y Casos de Pruebas) para la aplicación de las pruebas de software al módulo Mercantil.
Capítulo 3: Se realiza una Evaluación de los Resultados obtenidos a partir de la ejecución de las pruebas y se clasifican de acuerdo a la prioridad los errores encontrados.
4
Capítulo 1: Fundamentación Teórica
1.1. Introducción
En el presente capítulo se realiza una investigación sobre el estado del arte de las pruebas de software, un análisis de los conceptos de prueba desde el punto de vista de diferentes autores, así como un estudio de las diferentes metodologías para mejorar el proceso de pruebas. Se detallan los distintos tipos y técnicas de pruebas, y las características de una serie de herramientas para el apoyo de los especialistas en la administración y confección de artefactos de pruebas. Todo esto para desarrollar un adecuado proceso de pruebas que permita encontrar la mayor cantidad de errores posibles en el software del Módulo Mercantil.
1.2. Estado actual
El desarrollo de sistemas de software implica una serie de actividades de producción en las que en la mayoría de los casos se producen gran cantidad de errores, los cuales están dados principalmente por un mal manejo de herramientas, técnicas y artefactos de pruebas, principal elemento para garantizar la calidad de un producto a lo largo de todo el ciclo de vida. Una de las sorpresas que suelen encontrar los nuevos programadores es la enorme cantidad de tiempo y esfuerzo que requiere la fase de pruebas, hoy día se calcula que representa más de la mitad del valor total del producto, pues requiere un tiempo similar al de la programación y el coste de corregir los errores crece exponencialmente según avanza el proyecto.
Desde 1994 la firma de investigaciones The Standish Group realiza bianualmente el llamado CHAOS Research Study, sobre el número de proyectos que culminan exitosamente y los que se quedan en el camino. El reporte más reciente, en una muestra de 8 000 proyectos realizados en 352 compañías, arrojó los siguientes resultados:
15% de todos los proyectos del software se cancelan antes de completarse.
51% de los proyectos costarán 189% de las estimaciones realizadas.
Solo el 34% de los proyectos se realizan a tiempo y en el presupuesto.
Del análisis de éstos y otros estudios, se ha llegado a la siguiente conclusión: Si una unidad de costo de uno es asignada al esfuerzo requerido para detectar y reparar un error durante la etapa de codificación, entonces el costo para detectar y reparar un error durante la etapa de requerimientos es entre cinco y diez veces menor. Más aun, el costo de detectar y reparar un error durante la etapa de mantenimiento es 20 veces más alto (1).
5 Muchas organizaciones desconocen los aspectos fundamentales del proceso de pruebas, este desconocimiento lleva con frecuencia a subestimar la complejidad de las actividades involucradas en este proceso, lo cual cobra un alto precio en los proyectos. Debido a esto, muchas empresas productoras de software y algunas empresas consumidoras contratan servicios especializados de pruebas de software independiente orientados a mejorar la calidad de sus servicios. Según datos de las empresas proveedoras de estos servicios dentro del servicio de pruebas independiente, las pruebas de funcionalidad fueron las más solicitadas (78%) y el resto corresponde a pruebas de performance (22%). Algunas de estas empresas son:
El CES (Centro de Ensayos de Software) desarrolla su actividad desde el año 2004, por iniciativa de la Cámara Uruguaya de Tecnologías de la Información (CUTI) y la Universidad de la República. Fundamentalmente ofrece servicios de pruebas independientes de productos, consultoría y capacitación en pruebas. Este Centro ha participado en eventos nacionales e internacionales en el área de Ingeniería de Software, aportando sus conocimientos en la disciplina de pruebas y en la actualidad ha concretado proyectos con diferentes empresas, posicionándose como institución de referencia (2).
inQA.labs Líder mundial en soluciones de automatización de pruebas y gestión de los procesos de calidad de software, es una empresa de capital español fundada en Barcelona en 1999 especializada en servicios de prueba de software y consultoría de gestión de calidad de software. Sus servicios ayudan a las empresas a aumentar la rentabilidad de sus proyectos de software, ofreciéndoles la posibilidad de desarrollar productos de mayor calidad y reducir el ciclo de lanzamiento de sus productos (3).
SQS (Software Quality Systems) es la compañía líder en servicios de Consultoría de Calidad de Software y Pruebas en España. Ofrece servicios de Validación y Verificación independiente, es experta en Diseño e Implantación de entornos de pruebas, en revisiones formales de Documentación y Código, y otros servicios que ofrecen a sus clientes un mayor control sobre el proceso, una identificación temprana de errores y problemas y una reducción drástica de los costes para subsanar estos errores (4).
Argentina Software Factory es una compañía que provee servicios de Pruebas de Software y aseguramiento de la calidad, guías, Casos de Pruebas y procedimientos necesarios para el proceso de pruebas.
6 Debido a la poca madurez en el estudio de este tema la mayoría de las empresas realizan gran parte del proceso de pruebas de forma manual, lo que provoca atrasos en el trabajo, pero a partir del gran colapso causado por el efecto Y2K han aparecido en el mercado herramientas automatizadas que generan datos de prueba y que, además examinan paso a paso la ejecución de los programas. Además existen otras herramientas que optimizan el trabajo de los especialistas en el desarrollo del proceso.
1.3. Pruebas de Software
El proceso de pruebas de software es un elemento crítico para la garantía de la calidad del software. Es una actividad en la cual un sistema o unos de sus componentes se ejecutan en circunstancias previamente especificadas e integrada durante todo el ciclo de vida. Es un proceso que se enfoca sobre la lógica interna del software y las funciones externas. La prueba no puede asegurar la ausencia de defectos, sólo puede demostrar que existen defectos en el software (5).
La prueba de software es un conjunto de herramientas, técnicas y métodos que hacen a la excelencia el desempeño de un programa. Es también la mejor publicidad que una empresa dedicada a la producción de software pueda tener. Involucra las operaciones del sistema bajo condiciones controladas y evaluando los resultados.
Probar ―es un proceso de ejecución de un programa con la intención de descubrir un error‖. Un buen caso de prueba es aquel que tiene alta probabilidad de mostrar un error no descubierto hasta entonces. Dentro del proceso de pruebas, las técnicas para encontrar problemas en un programa son extensamente variadas y van desde el uso del ingenio por parte del personal de prueba hasta herramientas automatizadas que ayudan a aliviar el peso y el costo tiempo de esta actividad (6).
Las pruebas constituyen un método más para poder verificar y validar el software. Se puede definir la verificación como (7) ―el proceso de evaluación de un sistema o de uno de sus componentes para determinar si los productos de una fase dada satisfacen las condiciones impuestas al comienzo de dicha fase‖ y la validación como el proceso de evaluación del software al final del proceso de desarrollo para asegurar el cumplimiento de las necesidades del cliente.
El objetivo de la etapa de pruebas de manera general es garantizar la calidad del producto desarrollado, y para lograr esto se hace necesario (8):
1. Planificar las pruebas necesarias en cada iteración, incluyendo las pruebas de integración y las pruebas de sistema. Las pruebas de integración son necesarias para
7 cada construcción dentro de la iteración, mientras que las pruebas de sistema son necesarias sólo al final de la iteración.
2. Diseñar e implementar las pruebas creando los casos de prueba que especifican qué probar, creando componentes de pruebas ejecutables para automatizar las pruebas.
3. Realizar las diferentes pruebas y manejar los resultados de cada una de forma sistemáticas. Las construcciones en las que se detectan defectos son probadas de nuevo y posiblemente devueltas a otro flujo de trabajo, como diseño o implementación, de forma que los defectos importantes puedan ser arreglados.
La aplicación de pruebas comienza por lo pequeño y progresa hacia lo grande. Por esta razón, se deben comenzar las primeras pruebas sobre el componente elemental y aplicar:
1.3.1. Pruebas de Unidad:
Es la escala más pequeña de la prueba, está basada en la funcionalidad de los módulos del programa, como funciones, procedimientos, módulos de clase, etc. En ciertos sistemas también se verifican o se prueban los drivers y el diseño de la arquitectura. Para probar los componentes implementados como unidades individuales, se realizan las pruebas de especificación o de caja negra, que verifica el comportamiento de la unidad observable externamente y pruebas de estructura, o de caja blanca, que verifica la implementación interna de la unidad (9).
1.3.2. Prueba de Caja Negra:
La prueba de Caja Negra se centra principalmente en los requisitos funcionales del software.
Estas pruebas permiten obtener un conjunto de condiciones de entrada que ejerciten completamente todos los requisitos funcionales de un programa. En ellas se ignora la estructura de control, concentrándose solamente en los requisitos funcionales del sistema.
Muchos autores consideran que estas pruebas permiten encontrar (10):
Funciones incorrectas o ausentes.
Errores de interfaz.
Errores en estructuras de datos o en accesos a las Bases de Datos externas.
Errores de rendimiento.
Errores de inicialización y terminación.
8 Para desarrollar la prueba de Caja Negra existen varias técnicas, entre ellas están:
1. Técnica de la Partición de Equivalencia: Es una de las más efectivas pues permite examinar los valores válidos e inválidos de las entradas existentes en el software, descubre de forma inmediata una clase de errores que, de otro modo, requerirían la ejecución de muchos casos antes de detectar el error genérico. La partición equivalente se dirige a la definición de casos de pruebas que descubran clases de errores, reduciendo así en número de casos de prueba que hay que desarrollar.
2. Técnica del Análisis de Valores Límites: Esta Técnica prueba la habilidad del programa para manejar datos que se encuentran en los límites aceptables.
3. Técnica de Grafos de Causa-Efecto: Es una técnica que permite al encargado de la prueba validar complejos conjuntos de acciones y condiciones. Consiste en crear un grafo causa/efecto a partir de las especificaciones, y seleccionar suficientes casos de pruebas para asegurar la cobertura del grafo, y mediante el, construir una tabla de decisión para reflejar las dependencias de los resultados.
4. Técnica de Adivinación de errores: Esta técnica consiste en tratar de imaginar cuáles son los errores que se pueden haber cometido con mayor probabilidad, y generar casos de prueba para comprobar dichos errores.
El aspecto humano es esencial en la prueba de Caja Negra aplicando factibles sucesos de la vida real a la prueba, errores de escritura, trabajar en aplicaciones equivocadas creyendo trabajar en la aplicación deseada.
1.3.3. Prueba de Caja Blanca:
También llamadas estructurales o de cobertura lógica. En ellas se pretende indagar sobre la estructura interna del código, omitiendo detalles referidos a datos de entrada o salida. Su objetivo principal es probar la lógica del programa desde el punto de vista algorítmico.
Para esta prueba se consideran tres importantes puntos (11):
5. Conocer el desarrollo interno del programa, determinante en el análisis de coherencia y consistencia del código.
6. Considerar las reglas predefinidas por cada algoritmo.
7. Comparar el desarrollo del programa en su código con la documentación pertinente. La primera parte de esta prueba es el análisis estático.
9 Una técnica de prueba de Caja Blanca es la prueba del camino básico, los pasos que se siguen para aplicar esta técnica son:
1.
A partir del diseño o del código fuente, se dibuja el grafo de flujo asociado.2.
Se calcula la complejidad ciclomática del grafo.3.
Se determina un conjunto básico de caminos independientes.4.
Se preparan los casos de prueba que obliguen a la ejecución de cada camino del conjunto básico.Los casos de prueba derivados del conjunto básico garantizan que durante la prueba se ejecuta por lo menos una vez cada sentencia del programa.
1.3.4. Prueba de Integración:
Se basa en las pruebas de conexiones y comunicaciones entre diferentes módulos. Es esencial en sistemas de cliente-servidor o red. Tienen por objetivo verificar el conjunto funcionamiento de dos o más módulos, si bien se deben poner en práctica desde la creación de dos módulos que interactúen entre sí, en el supuesto caso que se necesiten más de dos módulos para efectuar las pruebas, deberán generarse simples emuladores de módulos que entreguen datos esperados para la prueba individual de cada uno. También las pruebas de integración pueden ser realizadas en forma ascendente, esto evita tener que crear módulos emuladores, ya que a medida que se va creando la pirámide va siendo probada de abajo hacia arriba (Down to Top), esto conducirá un trabajo simétricamente mayor, lo que equipará o superará el tiempo que podría tomar el crear módulos para prueba (12).
1.3.4.1. Prueba de regresión:
Es una nueva revisión en las pruebas del programa luego de que este haya sufrido algún cambio o por apuros de tiempo o la modificación fue en el ambiente en que se desenvuelve.
Actualmente aparecieron herramientas automatizadas que hacen que este tipo de pruebas no lleve demasiado tiempo.
1.3.5. Pruebas de Validación:
El objetivo de estas pruebas es obtener información útil para la validación de la implementación de los algoritmos estudiados. Se asume para esta parte que el software ha cumplido la etapa de verificación, por lo tanto está libre de errores de tiempo de ejecución, lo que no significa que esté libre de errores lógicos (diferencias entre la estrategia propuesta y la implementada) (13).
10
1.3.6. Pruebas de Sistemas:
Es el proceso de prueba de un sistema integrado de hardware y software para comprobar lo siguiente:
1. Cumplimiento de todos los requisitos funcionales, considerando el producto software final completo en un entorno de sistema.
2. El funcionamiento y rendimiento en las interfaces hardware, software, de usuario y de operador.
3. Adecuación de la documentación de usuario.
4. Ejecución y rendimiento en condiciones límite y de sobrecarga.
Las pruebas de sistemas persiguen la integración de cada módulo en el sistema. Además de buscar las discrepancias entre el sistema y sus especificaciones y la documentación del mismo.
Entre las pruebas especiales de sistemas se pueden considerar las siguientes:
1.3.6.1. Prueba de Procedimientos:
Con esta prueba se determina si los manuales de documentación y ejecución contienen una descripción detallada y si refleja realmente las acciones que se llevan a cabo para el funcionamiento del sistema. Para ello, el usuario debe seguir las instrucciones en forma exacta, como se indica en el manual de procedimientos.
1.3.6.2. Prueba de Recuperación:
La prueba de recuperación consiste en crear un evento de fallas o pérdidas de datos, para que los usuarios vuelvan a cargar y recuperar a partir de una copia de respaldo. Con ello, se determina si los procedimientos de recuperación son los más adecuados para cuando el sistema falle no ocurra pérdida de datos.
1.3.6.3. Prueba de Factores Humanos:
Esta prueba consiste en hallar repuestas sobre la reacción de los usuarios, cuando interactúen con el sistema y sucedan imprevistos, por ejemplo:
Los mensajes que deben aparecer en la pantalla cuando un usuario esté procesando una transacción.
Observar a las personas si tienen facilidad de manejo del teclado para el ingreso de datos.
Comodidad de los usuarios frente a lo mostrado en la pantalla (color, resplandor, mucho detalle).
11
1.3.6.4. Prueba de Carga Máxima:
Esta prueba se basa en la existencia de tiempos críticos en los sistemas en línea, es decir, la respuesta de un sistema en prueba cuando varios usuarios quieren acceder al mismo.
1.3.6.5. Prueba de Almacenamiento:
Las pruebas de almacenamiento determinan si el sistema soporta la capacidad del número de registros que un archivo puede almacenar en disco.
1.3.6.6. Prueba de Tiempo de Ejecución:
Esta prueba permite conocer qué tan rápido o lento es el sistema.
1.4. Metodologías
En el mundo de la computación tan cambiante de hoy en día, y sobre todo de gran evolución tecnológica, se ha hecho necesario desarrollar metodologías para asegurar la calidad de los productos de software y obtener un mejoramiento continuo de todos los procesos relacionados con el desarrollo de software. No existe una metodología universal para hacer frente con éxito a cualquier proyecto de desarrollo de software. Toda metodología debe ser adaptada al contexto del proyecto (recursos técnicos y humanos, tiempo de desarrollo, tipo de sistema).
Entre algunas de estas metodologías se encuentran:
1.4.1. RUP (Rational Unified Process)
RUP es un proceso que define claramente quien, cómo, cuándo y qué debe hacerse; y, como su enfoque está basado en modelos utiliza un lenguaje bien definido para tal fin, el UML.
El proceso de software propuesto por RUP tiene tres características esenciales: está dirigido por Casos de Uso, está centrado en la arquitectura, y es iterativo e incremental. Esto permite establecer trazabilidad entre los artefactos que son generados en las diferentes actividades del proceso de desarrollo, además se presta especial atención al establecimiento temprano de una buena arquitectura que no se vea fuertemente impactada ante cambios posteriores, y el trabajo se divide en partes más pequeñas o mini proyectos (14).
En esta metodología, el desarrollo del flujo de trabajo de prueba consistirá en planificar que es lo que hay que probar, diseñar cómo se va a hacer, implementar lo necesario para llevarlos a cabo, ejecutarlos en los niveles necesarios y obtener los resultados, de forma que la información obtenida sea utilizada para ir refinando el producto a desarrollar.
Para llevar a cabo todo el Proceso de Pruebas RUP define diferentes roles:
Especialistas en Pruebas (Probador)
12 Analista de Pruebas
Diseñador de Pruebas Administrador de Pruebas
Estos especialistas desarrollan una serie de artefactos propuestos por esta metodología para las actividades involucradas en el proceso de pruebas, ellos son:
1.4.1.1. Artefactos del Proceso de Pruebas.
Un artefacto es todo producto o subproducto resultante del proceso de desarrollo del software, es un trozo de información que es producido, modificado o usado. No siempre en todo proyecto se crean los mismos artefactos, esto dependerá de las características del proyecto y los requisitos del cliente. Para la fase de pruebas se tienen los siguientes artefactos (15):
1.4.1.1.1. Modelo de Pruebas:
Describe principalmente cómo se prueban los componentes ejecutables en el modelo de implementación con pruebas de integración y de sistema. Puede describir también cómo se han probado aspectos específicos del sistema, por ejemplo, si la interfaz de usuario del sistema cumple con su objetivo y describe el cumplimiento de los requisitos funcionales y no funcionales del sistema. Es una colección de casos de pruebas, procedimientos de prueba y componentes de prueba.
1.4.1.1.2. Caso de Prueba:
Un caso de prueba especifica una forma de probar el sistema, incluyendo la entrada o resultado con que se va a probar y las condiciones bajo las que ha de probarse. Existen varios casos de pruebas que son realizados en la práctica, por ejemplo: un caso de prueba que especifica cómo probar un caso de uso o un escenario específico de un caso de uso. Estos incluyen la verificación del resultado de la interacción entre los autores y el sistema, que satisfacen las precondiciones y postcondiciones especificadas por el caso de uso, como es el caso de las pruebas de caja negra. Otro tipo de caso de prueba es aquel que especifica cómo probar una realización de caso de uso-diseño o un escenario específico de la realización. Un caso de uso de este tipo puede incluir la verificación de la interacción de los componentes que implementan dicho caso de uso como por ejemplo las prueba de caja blanca.
Se pueden especificar otros casos de pruebas para probar el sistema como un todo, por ejemplo: las pruebas de instalación que verifica si el sistema puede ser instalado en la
13 plataforma del cliente y que este sea instalado correctamente. Las pruebas de configuración comprueban que el sistema funcione en diferentes configuraciones de red. Las pruebas negativas intentan provocar que el sistema falle para poder así revelar sus debilidades. Las pruebas de tensión o de estrés identifican problemas con el sistema cuando hay recursos insuficientes o cuando hay competencia por los recursos.
1.4.1.1.3. Procedimiento de Prueba:
Un procedimiento de prueba especifica cómo realizar uno o varios casos de pruebas ó partes de éstos. Un procedimiento de prueba puede ser una instrucción para un individuo sobre cómo realizar un caso de prueba manualmente, ó una especificación de cómo interactuar manualmente con una herramienta de automatización de pruebas, para crear componentes ejecutables de prueba.
1.4.1.1.4. Componente de Prueba:
Un componente de prueba automatiza uno o varios procedimientos de prueba o partes de ellos. Estos pueden ser desarrollados utilizando un lenguaje de guiones o un lenguaje de programación, o pueden ser gravados con una herramienta de automatización de pruebas. Los componentes de pruebas se utilizan también para probar los componentes en el modelo de implementación, proporcionando entradas de pruebas, controlando y motorizando la ejecución de los componentes a probar. Los componentes de pruebas pueden ser implementados usando tecnología de objetos.
1.4.1.1.5. Plan de Prueba:
El plan de prueba describe las estrategias, recursos y planificación de la prueba, el nivel de cobertura de prueba y de código necesario, además del porcentaje de prueba que deberían ejecutarse con un resultado específico. El propósito del plan de pruebas es dejar de forma explícita el alcance, el enfoque, los recursos requeridos, el calendario y los responsables del proceso de pruebas. Cada prueba debe dejar claro qué tipo de propiedades se quieren probar así como tener una visión clara de cómo medir los resultados. La construcción de un buen Plan de Pruebas es la piedra angular y en consecuencia el principal factor crítico de éxito para la puesta en práctica de un proceso de pruebas que permita entregar un software de mejor nivel.
14
1.4.1.1.6. Defecto:
Un defecto es un síntoma de un fallo software o un problema descubierto en una revisión, el cual puede ser utilizado para localizar cualquier cosa que los desarrolladores necesiten registrar cómo síntoma de un problema en el sistema.
1.4.1.1.7. Evaluación de Prueba:
Es una evaluación de los resultados de los esfuerzos de prueba, tales como la cobertura del caso de prueba, de código y el estado de los defectos. Los diseñadores evalúan los resultados de la prueba comparando los resultados obtenidos con los objetivos trazados en el plan de prueba. Se realizan métricas que les permiten determinar el nivel de calidad del software y qué cantidad de pruebas es necesario realizar.
1.4.1.1.8. Estrategias de Pruebas del Software:
Una estrategia de prueba del software integra las técnicas de diseño de casos de prueba en una serie de pasos bien planificados que llevan a la construcción correcta del software. Es el proceso de analizar cómo plantear las pruebas en el Ciclo de Vida. La estrategia de pruebas suele seguir estas etapas: comenzar pruebas a nivel de módulo, continuar hacia la integración del sistema completo y a su instalación, y culminar con la aceptación del producto por parte del cliente. La implementación de estrategias de pruebas exitosas pueden reducir los costes de pruebas en un 32%. Las Estrategias de Pruebas es la clave para la finalización exitosa de cualquier actividad de pruebas de software.
En el proyecto la prueba a veces requiere mayor esfuerzo que cualquier otra actividad de la Ingeniería de Software, si se efectúa sin un plan estratégico, el tiempo se desaprovecha y el esfuerzo es consumido innecesariamente y, en el peor de los casos, los errores inadvertidos quedarán sin detectar, por tanto, puede ser muy conveniente establecer una estrategia sistemática para probar el software.
1.4.2. XP (Extreme Programing)
La metodología XP es exitosa porque enfatiza la satisfacción del cliente y promueve el trabajo en equipo. Ha sido diseñada para solucionar el eterno problema del desarrollo de software por encargo: entregar el resultado que el cliente necesita a tiempo. El desarrollo bajo XP tiene características que lo distinguen claramente de otras metodologías (16):
Los diseñadores y programadores se comunican efectivamente con el cliente y entre ellos mismos.
15 Los diseños del software se mantienen sencillos y libres de complejidad o pretensiones excesivas.
Se obtiene retroalimentación de usuarios y clientes desde el primer día gracias a las baterías de pruebas.
El software es liberado en entregas frecuentes tan pronto como sea posible.
Los cambios se implementan rápidamente tal y como fueron sugeridos.
Las metas en características, tiempos y costos son reajustadas permanentemente en función del avance real obtenido.
Con estas características no es sorprendente que XP sea la metodología más apropiada para un entorno caracterizado por requerimientos cambiantes originados por un mercado fluctuante y los propios avances de la tecnología y los negocios.
XP divide las pruebas del sistema en dos grupos:
Pruebas unitarias.
Pruebas de aceptación o pruebas funcionales.
Desde hace un tiempo, Extreme Programming ha comenzado a cambiar los hábitos clásicos de los equipos de desarrollo. Uno de los pilares de esta metodología se centra en el aumento de la productividad de los equipos de desarrollo. Este aumento se puede lograr (en gran parte) si los equipos trabajan utilizando una nueva técnica de trabajo denominada TDD:
1.4.3. Test Driven Development (Desarrollo basado en Pruebas)
Es una técnica de programación que involucra el escribir primero los casos de prueba y luego implementar solo el código necesario para ejecutarla. El propósito del desarrollo guiado por pruebas es lograr una rápida retroalimentación, e implementa el "ilustrar la línea principal" al hacer un programa. Esta técnica es altamente enfatizada en la programación extrema. Diversos expertos destacan que el desarrollo guiado por pruebas, es esencialmente un método de diseño de software, y no solamente un método de pruebas. Esta metodología ofrece ciertas ventajas: al escribir primero los casos de prueba, se definen de manera formal los requisitos que se espera que cumpla la aplicación, así los Casos de Prueba sirven de documentación del sistema. Por ejemplo, al escribir una prueba de unidad se piensa en la forma correcta de utilizar un módulo que aún no existe y se hace hincapié en el diseño de la interfaz de un módulo antes de pensar en su implementación. Además la ejecución de los Casos de Pruebas se realiza de forma automatizada (con la ayuda de JUnit, NUnit y otras herramientas). Por último, los Casos de Pruebas definen claramente cuando termina el trabajo (cuando se pasan con éxito todos los Casos de Pruebas).
16 Básicamente, el ciclo de desarrollo en esta metodología consiste en (17):
Escribir la prueba: Se comienza escribiendo una prueba, en donde el desarrollador debe entender claramente las especificaciones y los requisitos. El diseño del documento cubre todos los escenarios de prueba y condiciones de excepciones.
Escribir el código: El paso siguiente es escribir el código haciendo que pase la prueba. Este paso fuerza al programador a tomar la perspectiva de un cliente, considerando el código a través de sus interfaces. Esta es la parte conducida por el diseño, del TDD.
Ejecutar las pruebas automatizadas: El paso siguiente es ejecutar los casos de pruebas automatizados y observar si pasan o fallan. Si pasan, el programador puede garantizar que el código resuelve los casos de prueba escritos. Si hay fallos, el código no resolvió los casos de prueba.
Refactorización: El paso final es la refactorización, aquí está cualquier necesidad de limpieza en el código. Después se vuelven a efectuar los casos de prueba y se observan los resultados.
Repetición: Después se repetirá el ciclo y se comenzará a agregar las funcionalidades adicionales o a arreglar cualquier error.
El poder del TDD radica en la capacidad de avanzar en pequeños pasos cuando se necesita.
Permite que un programador se centre en la tarea actual y la primera meta es a menudo hacer que la prueba pase satisfactoriamente. La naturaleza temprana y frecuente de las pruebas ayuda a capturar defectos prematuros en el ciclo de desarrollo, previniéndolos antes de que se conviertan en problemas grandes.
1.4.4. TPI (Test Process Improvement)
El Modelo de Mejora del Proceso de Pruebas (TPI) se ha desarrollado partiendo del conocimiento y la experiencia de las Pruebas de Control de Software. Este modelo es un medio de ayuda para mejorar el proceso de pruebas. Permite visualizar el nivel de ―madurez‖ del proceso de pruebas dentro de su organización. Partiendo de este criterio, el modelo ayuda a definir pasos de mejora graduales y controlados.
Se divide en:
Áreas Claves
En cada proceso de pruebas hay ciertas áreas que necesitan atención específica con el fin de lograr un proceso bien definido, estas Áreas Claves constituyen la base para mejorar y estructurar el proceso de pruebas, este modelo tiene 20 Áreas Claves, ella son:
1. Estrategia de Pruebas 2. Modelo del Ciclo de Vida
17 3. Momento de Involucración
4. Estimación y Planeamiento 5. Técnicas de Diseño de Pruebas 6. Técnicas de Pruebas Estáticas 7. Métricas
8. Herramientas de Pruebas 9. Entorno de Pruebas 10. Entorno de Oficina
11. Compromiso y Motivación
12. Funciones de Pruebas y Capacitación 13. Alcance de la Metodología
14. Comunicación 15. Informes
16. Manejo de Defectos
17. Administración de los Elementos de Pruebas 18. Administración del Proceso de Pruebas 19. Revisión Estructurada
20. Pruebas de Caja Blanca Niveles
La forma en que están organizadas las Áreas Claves dentro de un proceso de pruebas determina la ―madurez‖ del proceso. Es obvio que no toda Área Clave tendrá la misma atención ni profundidad: cada proceso de pruebas tiene sus puntos fuertes y débiles. Con el fin de permitir una visión del status de cada Área Clave, el modelo proporciona Niveles (de A a B a C). Como promedio, hay tres niveles por cada Área y cada nivel conlleva el cumplimiento de ciertos requisitos para el Área Clave.
Puntos de Verificación
Los requisitos para cada nivel están definidos en forma de Puntos de Verificación (Checkpoints): son preguntas que necesitan ser respondidas afirmativamente para poder calificar a dicho nivel. A partir de las listas de verificación se puede evaluar un proceso de pruebas y se puede determinar para cada Área Clave el Nivel alcanzado.
Matriz de Madurez de Pruebas
Después de determinar los niveles para cada Área Clave, se debe dirigir la atención hacia cuáles son los pasos de mejora que hay que realizar. Esto se debe a que no todas las Áreas Claves y Niveles tienen la misma importancia. Se conforma una matriz donde cada nivel está
18 relacionado con cierta escala de madurez de pruebas, resultando así 13 escalas de madurez de pruebas. El propósito principal de la matriz es mostrar los puntos fuertes y débiles del actual proceso de pruebas y ofrecer una ayuda a la hora de determinar la prioridad de las acciones de mejora.
El modelo TPI es un medio objetivo para obtener rápidamente información acerca de la situación actual del proceso de pruebas, ofrece una valiosa ayuda mediante Áreas Clave, Niveles y Sugerencias de Mejora. Se basa en el concepto de dar pasos pequeños y controlados, a partir de prioridades.
Debe considerarse como una herramienta para estructurar las acciones de mejora del proceso de pruebas y como un buen medio para comunicar (18).
1.4.5. TMap (Test Management approach)
Es una de las metodologías de Pruebas de Software más extendida internacionalmente, un método de pruebas de software estructurado. Esta metodología, basada en la experiencia de SOGETI, está diseñada para dirigir los temas claves de calidad, tiempo y coste. Es flexible por naturaleza, y ofrece una visión completa y consistente que se ajusta a todo tipo de organización, de cualquier tamaño, y su uso puede adaptarse a diferentes situaciones, desde el testeo de aplicaciones Web a aplicaciones desarrolladas utilizando metodologías de desarrollo iterativas. Para estructurar la empresa y ejecutar los procesos, TMap se basa en cuatro pilares (19):
Un modelo del ciclo de vida para las actividades de pruebas relacionado con los procesos del desarrollo de software.
Una Organización sólida.
Una Infraestructura adecuada.
Técnicas para las varias actividades de prueba.
Durante los últimos años, TMap se ha transformado en un estándar para las pruebas de software en los Países Bajos, Bélgica, Luxemburgo, y Alemania y está siendo utilizado por más de trescientas empresas.
1.5. Herramientas
El proceso de ingeniería de software se define como "un conjunto de etapas parcialmente ordenadas con la intención de lograr un objetivo, en este caso, la obtención de un producto de software de calidad" (20). Existen herramientas que han sido creadas para apoyar a los
19 especialistas en este proceso, facilitando el trabajo en cada etapa e incluso la interacción entre ellas, una de las herramientas más utilizadas es Rational Rose.
1.5.1. Rational Rose
Rational Rose es una herramienta CASE (Computer Arded Software Engineering) desarrollada por los creadores de UML (Booch, Rumbaugh y Jacobson) que cubre todo el ciclo de vida de un proyecto: concepción y formalización de modelos, construcción de componentes y certificación de las distintas fases y entregables. Con esta herramienta es posible llevar a cabo tanto la automatización de los sistemas para la posterior generación de código (realización de los distintos diagramas y generación del código posterior), como labores de ingeniería inversa, es decir la realización de diagramas una vez conocido el código.
Rational Rose contiene a su vez varias herramientas de pruebas que permiten probar todas las dimensiones de calidad, incluyendo funcionalidad, confiabilidad y desempeño del software. Con el uso de estas herramientas será posible asegurar una cobertura de pruebas más completa en menos tiempo, realizar pruebas con mayor anticipación y frecuencia, desde el diseño y modelado inicial hasta el desarrollo y despliegue. A continuación se hace mención a algunas de estas herramientas (21):
1.5.2. Rational TestManager (Administración de pruebas)
Es un framework abierto y extensible que une todas las herramientas, utensilios y datos de pruebas para ayudar al equipo a definir y refinar sus objetivos de calidad. Contiene y organiza el plan de pruebas que guía al equipo para lograr esos objetivos. Lo que es aun más importante, contiene las claves de toda la información necesaria para evaluar el estado del sistema en cualquier momento durante el ciclo de vida del proyecto. Brinda una única herramienta compartida para administrar y controlar todas las actividades de pruebas. Este ambiente abierto y expandible puede emplearse para controlar todas las evaluaciones de pruebas. Permite a todos los miembros del equipo planear, administrar y ejecutar pruebas y medir el progreso en comparación con el plan de pruebas al evaluar las ejecuciones de las mismas.
1.5.3. Rational Manual Tester
Es una herramienta de ejecución y autorización de pruebas manuales para probadores y analistas de negocio. Introduce técnicas nuevas de desarrollo para mejorar la velocidad, el alcance y la fiabilidad de los esfuerzos de pruebas manuales y promueve la reutilización de los pasos de pruebas para reducir la repercusión de los cambios de software realizados en las
20 actividades de mantenimiento de pruebas. Proporciona un editor de textos avanzado que soporta adjuntos e imágenes para mejorar la legibilidad de las pruebas. Facilita la entrada de datos y verificación durante la ejecución de pruebas para reducir los posibles errores humanos.
Importa pruebas manuales existentes previamente basadas en Microsoft Word y Excel; exporta los resultados de las pruebas en archivos basados en CSV (comma-separated values) para el análisis en las herramientas preferidas de otros proveedores.
1.5.4. Rational ClearQuest y Functional Testing
Es una solución para gestionar pruebas y defectos, además realiza pruebas funcionales del software de manera automática y manual. Es un paquete integral de gestión de cambios y calidad que ofrece a los equipos de pruebas acceso centralizado e integrado, para gestionar pruebas y defectos, y ensayos funcionales manuales y automáticos. Los equipos de pruebas o las empresas de control de calidad independientes que realicen un proyecto de desarrollo, en el mismo sitio o en diferentes ubicaciones, pueden utilizar esta solución para gestionar proyectos empresariales a gran escala. Su base es Eclipse y esta solución ofrece un ecosistema abierto de gestión de pruebas para reducir el coste de la gestión del laboratorio de pruebas.
1.6. Conclusiones
En este capítulo se definieron importantes conceptos y procedimientos de pruebas para el mejor entendimiento del proceso de pruebas, se realizó un estudio sobre tendencias y tecnologías actuales a nivel internacional, así como el estudio de las diferentes herramientas y metodologías para asegurar la calidad de los productos, llegándose a la conclusión de que será usada la metodología tradicional RUP para el desarrollo del software y el proceso de pruebas a realizar, pues su utilización es factible dadas las características de este proyecto.
21
Capítulo 2: Artefactos del Proceso de Pruebas.
2.1. Introducción:
El Proceso de Pruebas de Software debe formar parte de un proceso definido, documentado y medido para poder ser gestionado. En el presente capítulo se elaboran diferentes artefactos de prueba propuestos por la metodología RUP, necesarios para dirigir y organizar todas las actividades involucradas en esta fase, especificándose en estos artefactos los recursos necesarios, entregables, técnicas de pruebas a realizar, datos así como los elementos de hardware y software necesarios para la ejecución de las pruebas.
2.2. Plan de Pruebas
Revisión Histórica
Fecha Versión Descripción Autor
Noviembre/2006 1.0 Versión Inicial Evelyn Domínguez Ayub Ariadne Delgado Hernández
2.2.1. Propósito:
Este documento de Plan de Pruebas del Módulo Mercantil del Proyecto Registros y Notarías tiene como propósito seleccionar y coordinar todas las actividades para asegurar la calidad del producto durante el ciclo de vida del proyecto, explicitar el alcance, enfoque, recursos requeridos, calendario así como los responsables involucrados en el Proceso de Pruebas.
Apoya los siguientes objetivos:
1. Identificar toda la información existente del proyecto y los componentes/elementos del software que deben probarse.
2. Seleccionar los Requisitos Funcionales necesarios para el diseño de los Casos de Pruebas.
3. Describir la Estrategia de Prueba que será utilizada.
4. Identificar los recursos requeridos y proporcionar una estimación de los esfuerzos de la prueba.
5. Seleccionar los documentos a entregarse al culminar el proceso previsto por el plan.
22
2.2.2. Alcance:
Durante el proceso de pruebas se realizarán dos tipos de pruebas, las Pruebas de Funcionalidad y las Pruebas de Sistema. Para el desarrollo de las Pruebas de Funcionalidad se empleará la Técnica de Caja Negra. Las Pruebas de sistema se dirigirán a probar diferentes elementos, para determinar el correcto funcionamiento de las interfaces, así como algunos elementos de calidad como la usabilidad, confiabilidad y la eficiencia.
2.2.3. Definición, Acrónimos y Abreviaturas:
Referirse al Glosario de Términos.
2.2.4. Información del Proyecto:
La siguiente Tabla muestra la documentación requerida para el desarrollo del Plan de Prueba, así como la disponibilidad de la misma:
Documento Creada o Disponible Recibida
Documento Visión Si No Si No Especificaciones de Casos de Uso Si No Si No Glosario de Términos Si No Si No Requisitos Funcionales Si No Si No Modelo del Negocio Si No Si No Manual de Usuario Si No Si No Linea Base de Arquitectura Si No Si No
Manual de Tecnología Si No Si No
2.2.5. Listado Requerimientos:
La siguiente lista identifica los casos de uso y los requisitos funcionales que serán probados durante el proceso de pruebas.
2.2.5.1. Pruebas de Funcionalidad
Verificar que se capturen correctamente los Datos entrados al sistema.
Verificar la funcionalidad de la Búsqueda por Parámetros.
2.2.5.1.1. Sesión
Verificar la funcionalidad de Bloquear y Desbloquear Sesión.
Verificar la funcionalidad Tiempo de Bloqueo.
Verificar la funcionalidad de Cambiar Contraseña.
23 Verificar la funcionalidad Cerrar Sesión.
2.2.5.1.2. Administración Local
Verificar la funcionalidad de Gestión de Roles.Verificar la funcionalidad de Restablecer Contraseña.
2.2.5.1.3. Denominación Mercantil
Verificar el funcionamiento de la solicitud de una Denominación Mercantil.
Verificar la funcionalidad de búsqueda fonética de Coincidencias de Denominación.
Verificar la funcionalidad de Reserva de Nombre.
Verificar la funcionalidad de Activar Nombre.
Verificar la funcionalidad de Análisis de Coincidencias.
2.2.5.1.4. Presentación
Verificar la funcionalidad de Trámites Constitutivos.
Verificar la funcionalidad de Trámites No Constitutivos.
Verificar la funcionalidad de Otros Actos.
Verificar la funcionalidad de Cambio de Otorgante.
Verificar funcionalidad de Libro Diario.
2.2.5.1.5. Gestión Documental
Verificar la funcionalidad de Digitalización de Documentos.
Verificar la funcionalidad de Gestionar Recaudos.
Verificar la funcionalidad de Solicitud de Expedientes.
Verificar la funcionalidad de Aceptar Expedientes Solicitados.
2.2.5.1.6. Revisión Legal
Verificar la funcionalidad de Revisar Prohibiciones.
Verificar la funcionalidad de Trámites Prohibidos.
Verificar la funcionalidad de Reasignar Funcionario.
2.2.5.1.7. Archivo
Verificar la funcionalidad de Actualizar Custodia.
Verificar la funcionalidad de Localizador de Expediente.
Verificar la funcionalidad de Archivar Trámites.
Verificar la funcionalidad de Libro de Control.
2.2.5.1.8. Supervisión
Verificar la funcionalidad de Estado del trámite.
24 Verificar la funcionalidad de Editar Datos Personas.
Verificar la funcionalidad de Actividades del Registro.
2.2.5.2. Pruebas de Interfaz de Usuario
Navegar a través de todas las pantallas de la aplicación, verificando que cada uno de los campos, botones y menús son perfectamente entendibles por los usuarios, además elementos imprescindibles para la calidad como son la usabilidad, confiabilidad y eficiencia (utilizando Listas de Comprobación).
2.2.6. Estrategia de Pruebas:
En esta sección se describe brevemente como serán realizadas las pruebas; la descripción en detalle para cada tipo de prueba, las técnicas a implementar, los propósitos de estas y el curso de la acción a seguir será ampliamente explicado en el documento de Estrategia de Pruebas.
2.2.6.1. Pruebas de Funcionalidad
Objetivo de la Prueba
Ejecutar cada Caso de Uso, incluyendo sus flujos alternos, usando para realizar las pruebas datos válidos y no válidos. Se probará lo siguiente:
Resultados esperados al probar con datos válidos.
Mensajes de errores y advertencia al utilizar datos incorrectos.
Comprobar que se siga la secuencia de acciones especificado por el caso de uso.
Comprobar que se satisfagan las precondiciones y poscondiciones del caso de uso.
Técnica Caja Negra, con Técnica de Partición de Equivalencia.
2.2.6.2. Pruebas de Interfaz de Usuario
Objetivo de la Prueba
Probar lo siguiente:
Un correcto funcionamiento de las Interfaces con relación a los Requisitos Funcionales y al negocio.
Interfaces accesibles y de buen entendimiento para el usuario.
Técnica Lista de Comprobación.
25
2.2.7. Trabajadores
En esta sección se identifican los roles, sus principales responsabilidades y el conjunto de habilidades que estos poseen para la ejecución de las pruebas al sistema.
Recursos Humanos
Trabajadores Responsabilidades Específicas
Diseñador de Prueba Planear las pruebas, decidir los objetivos de prueba apropiados.
Identificar, priorizar, seleccionar y describir los Casos de Pruebas y los procedimientos correspondientes.
Identificar las técnicas apropiadas, herramientas y pautas para llevar a cabo las pruebas.
Definir la configuración del entorno para realizar las pruebas.
Probador Preparar y ejecutar las Pruebas.
Verificar y llevar el control de la ejecución de las pruebas.
Evaluar resultados obtenidos.
Conformar documentación al culminar el proceso.
Administrador de Prueba Asegurar la planificación apropiada y dirección de los recursos de las pruebas.
Evaluar el progreso y efectividad del proceso de pruebas.
Realizar el Plan de Prueba.
Realizar el Sumario de Evaluación de las Pruebas.
Resolución de problemas que impiden las pruebas.
2.2.8. Sistema:
La siguiente tabla muestra los recursos para el proceso de pruebas. En esta etapa no se conocen totalmente los elementos específicos a utilizar por lo que se realiza una simulación del ambiente de producción para así estimar los recursos apropiados.