DIPLOMADO INGENIERÍA DE SOFTWARE Módulo VI: Pruebas de Software

Módulo: Pruebas de Software

Tabla de Contenido

Pruebas de Software

Introducción

Objetivos Específicos

Conceptos Básicos

Beneficios

3

3

5

5

Roles y Responsabilidades en las Pruebas

Gerente de Pruebas

Diseñador de Pruebas

Ejecutor de la Pruebas

Administrador del Ambiente de Pruebas

Gerencia de Proyectos

7

7

7

7

7

Proceso de Pruebas de Software

Proceso Global de Pruebas de Software

Planificar

Diseñar

Construir Pruebas

Ejecutar Pruebas

Analizar y Evaluar Resultados

8

9

10

11

11

11

Bibliografía 13

Resumen Curricular 14

2

Módulo: Pruebas de Software

Pruebas de Software

Introducción El Diplomado de Ingeniería del Software está orientado a la producción de software de alta calidad. Parte primordial del aseguramiento de calidad del software son las pruebas. Dado que el software es un producto donde la probabilidad de falla por error humano es alta. Que los errores se producen como se indica en los Módulos I y IV durante la fase de Requerimientos, debido a las debilidades de comunicación. Las pruebas representan una revisión de cada una de las fases anteriores: especificaciones, diseño y construcción. Cuando en un proceso de Ingeniería de Software las actividades de Aseguramiento de Calidad no se ejecutan a medida que se desarrollan estas fases, el proceso de pruebas puede tomar entre un 30 a un 40% del esfuerzo total de un proyecto y el número de defectos a manejar es potencialmente mayor. Sin embargo, a pesar de que se establezcan unos procesos de Aseguramiento de Calidad efectivos estos no sustituyen las pruebas. El objetivo de las pruebas es encontrar el mayor número de errores. Para que las pruebas sean efectivas deben conducirse sistemáticamente, es decir, debe ser: planificadas, diseñadas y construidas. Esta fase es paralela al resto de las fases principales del proceso de desarrollo. Las actividades de planificación y diseño efectivamente ejecutadas sirven como validación adicional de las especificaciones.

En este módulo se presentan conceptos, beneficios, actividades y técnicas que aseguran una implantación efectiva de un proceso de pruebas de software.

3

Módulo: Pruebas de Software

Pruebas de Software

Objetivos Específicos

Este módulo tiene los siguientes objetivos específicos:

1. Dar a conocer a los participantes los conceptos, técnicas y beneficios de un proceso de pruebas sistemático.

2. Exponer como implementar el proceso de pruebas en proyectos de desarrollo y mantenimiento de software.

4

Módulo: Pruebas de Software

Pruebas de Software

Conceptos Básicos Error: es el comportamiento no esperado del sistema. Prueba: es ejecutar el sistema con la intención de encontrar errores, comprobando que el sistema se comporta de acuerdo con sus especificaciones y demostrar que el software satisface los requerimientos para los que fue construido. Etapas de Pruebas:

• Unitaria, está enfocada en los componentes mas pequeños identificables del software. En esta fase para cada unidad a probar se debe validar el desempeño de la interfaz, la integridad de las estructura de datos, las condiciones líimites de procesamiento, el recorrido de los caminos independientes y los caminos de manejo de errores.

• Integración, pruebas orientadas a asegurar que las unidades del software operan correctamente cuando se combinan.

• Sistemas, pruebas orientadas a validar que la aplicación funciona como un todo.

• Aceptación, pruebas realizadas por el usuario. Tipos de Pruebas:

• Funcional, verifica que el software produce los resultados esperados, incluyen tanto los resultados esperados en positivo (entradas correctas), así como resultados no esperadas (entradas no válidas).

• Interfaz usuario, se valida la navegabiidad, consistencia, uso de estándares, mensajes de error, uso de expresiones propias del negocio.

• Desempeño (performance), se utilizan para validar los tiempos de respuestas y como se comporta el software concurrentemente.

• Carga, se utilizan para detectar errores por escasez de recursos o el uso de recursos compartidos.

• Volumen, se ejecutan pruebas con grandes volúmenes de datos, validando los límites de uso que puede ser concebido.

• Configuración, se utilizan para validar el comportamiento del software bajo diferentes configuraciones de equipos y software común que pueda existir en la plataforma.

Casos de Prueba: Pasos detallados que determinan si un requerimiento se cumple o no.

Beneficios Los beneficios de la ejecución de pruebas planificadas y sistemáticas

5

Módulo: Pruebas de Software

son:

• Incremento de la satisfacción del cliente, al disminuir la probabilidad de errores una vez que el software ha sido implantado.

• Aumento en la certeza de que los resultados de las pruebas será exitoso

6

Módulo: Pruebas de Software

Roles y Responsabilidades en las Pruebas

Gerente de Pruebas El Gerente de Pruebas es responsable de:

• Elaborar y mantener el plan de pruebas.

• Dirección y búsqueda de recursos para ejecutar el plan de pruebas.

• Reportar los resultados de las pruebas.

Diseñador de Pruebas

El Diseñador de las pruebas es responsable de:

• Preparar los casos de Pruebas.

• Preparar el ambiente y los procedimientos de pruebas.

• Evaluar los resultados de las pruebas.

Ejecutor de la Pruebas

El ejecutor de las pruebas es responsable de:

• Ejecutar las pruebas y registrar los resultados.

• Recuperar el ambiente.

Administrador del Ambiente de Pruebas

El Administrador del ambiente de pruebas, es responsable de:

• Administrar el sistema de configuración del ambiente.

• Instalar nuevos usuarios.

• Manejar los requerimientos de datos.

Gerencia de Proyectos

La Gerencia de Proyectos es responsable de:

• Asegurar que se cree un plan de pruebas y velar por su cumplimiento.

• Asegurar que los productos de software cumplen con los requerimientos especificados.

• Hacer seguimiento a los defectos detectados y asegurar su solución.

• Revisar los reportes de las pruebas.

• Implantar acciones de mejora en función de los resultados de las pruebas.

7

Módulo: Pruebas de Software

Proceso de Pruebas de Software

Proceso Global de Pruebas de Software

El proceso de prueba debe ser sistemático, es decir, guiado por una metodología que incluya métodos, instancias y técnicas especificas de diseño de condiciones y casos de pruebas, con procedimientos de seguimiento a la solución de problemas detectados.

El personal responsable de las pruebas debe ser un equipo independiente no involucrado en el desarrollo del producto.

Planificar

El objetivo de la Planificación es crear el plan de pruebas, para ellos se debe:

• Recolectar y organizar los requerimientos de las pruebas, se debe determinar el conjunto óptimo de casos de pruebas que maximice la probabilidad de encontrar errores considerando las restricciones de recursos. En el caso de que se considere que debe ejecutarse mayor número de casos pero los recursos no sean suficientes, esto debe ser considerado un riesgo para la gerencia del proyecto.

Algunos principios que guían la planificación de las Pruebas son:

- Una especificación de un requerimiento que no pueda ser probado o que sus resultados no puedan ser observados o validados no es un requerimiento.

- Cada requerimiento debe tener al menos un caso de prueba y debe poderse identificar que caso de prueba está asociado a que requerimiento.

- La fase de Planificación de las pruebas debe iniciarse una vez que los requerimientos están especificados.

- La fase de Diseño de los casos de pruebas debe iniciarse una vez que el diseño ha sido completado.

- Es difícil y costoso probar el 100% del software, y dado que estadísticamente el principio de Pareto se cumple “80% de los fallas se deben al 20% de los elementos”. Se puede determinar cuales son las partes del software mas

8

Módulo: Pruebas de Software

propensas a fallas (20%) y probarlos en profundidad. - Las pruebas deben ejecutarse por etapas: unitarias,

integración, sistemas y aceptación. - Las pruebas debería realizarlas un equipo independiente

al equipo de desarrollo. - Las pruebas no deben ser redundantes, un procedimiento

de prueba debe integrase a otros cuando se requiera. • Desarrollar la estrategia de prueba, consiste en describir el

esquema de prueba a aplicar y los objetivos por cada etapa y tipo de prueba aplicar, las herramientas y técnicas a aplicar, los criterios de aceptación y las consideraciones especiales, como restricciones de recursos, tiempo, horario. La estrategia debe especificar el comportamiento a validar por función, por transacción, considerado las validaciones de campos y la integridad referencial.

• Estimar recursos (herramientas, infraestructura, ambiente) y

esfuerzo requerido. Entre los recursos se encuentra: - Sistemas, repositorio de pruebas - Servidor de pruebas

• Calcular los costos asociados a las actividades pruebas.

• Programar las actividades de acuerdo al Plan de Desarrollo

de Software - PDS.

• Asignar roles y responsabilidades de las pruebas según la estrategia definida.

• Someter el plan a revisión y aprobación.

• Realizar los ajustes que sean necesarios.

• Colocar el Plan bajo control de la configuración.

El resultado de este proceso es un Plan de Pruebas aprobado y bajo control de la Configuración, que en términos generales contiene:

• Propósito y alcance del documento.

• Roles y responsabilidades.

• Estrategia de pruebas.

• Manejo de los defectos.

• Recursos requeridos para ejecutar el plan, incluye: personal, facilidades, herramientas, presupuesto.

• Cronograma de las actividades.

9

Módulo: Pruebas de Software

• Recolección y reporte de métricas.

• Productos de las pruebas Diseñar

Consiste en el desarrollo de los caso de pruebas que ayuden a determinar que las especificaciones o requerimientos del sistema se cumplen. Los casos de prueba están compuestos por:

• Condiciones previas para realizar las pruebas.

• Condiciones y datos de entrada.

• Acciones a realizar para ejecutar las pruebas.

• Resultados esperados.

• Método para verificar el resultado esperado. Los casos de pruebas deben cubrir todos los requerimientos, por lo cual su desarrollo es un árbol de requerimientos igual a los requerimientos del proyecto. Cada requerimiento de software debe tener al menos un caso de prueba y debe ser referenciado. Deben ser elaborados de manera independiente del diseño y cambios en los datos. Los casos de pruebas pueden orientarse en cualquiera de estos dos sentidos:

• Caja Blanca, se diseñan conociendo la funcionalidad del producto y haciendo que todas las piezas encajen. En este caso se garantiza que se ejecuten todos los caminos posibles del software, las decisiones lógicas, los nidos con sus límites operacionales y las estructuras de datos para asegurar su validez.

• Caja Negra, se diseña en base a la interfaz del software, es

decir se determina la entrada, se demuestra la funcionalidad porque se genera el resultado esperado una vez que se ejecuta el software. Este tipo de pruebas ayuda a detectar errores de funcionalidad, interfaz, de estructura de datos, de rendimiento, de inicialización y de finalización.

Basándose en los principios que guían la planificación y esta orientación, se puede concluir que las pruebas de caja blanca son conveniente para aquellas áreas de la aplicación propensas a fallas (20%) y al resto se le puede aplicar las pruebas de caja negra.

10

Módulo: Pruebas de Software

Construir Pruebas

El proceso de construcción de pruebas busca desarrollar los procedimientos para ejecutar los casos de pruebas diseñados, instrucciones del paso a paso a realizar durante la ejecución de las pruebas. Los procedimientos de pruebas deben ser modulares, de manera que sean fácil de mantener y reutilizables. Los procedimientos de pruebas se pueden desarrollar de manera que sean:

• Dirigidas por datos (data driven), involucra el ingreso de una gran conjunto de datos.

• En base a instrucciones de base de datos, desarrollados en

lenguajes de programación.

Ejecutar Pruebas

La ejecución de las pruebas, se realiza de la siguiente manera:

• Efectuar las pruebas.

• Revisar los resultados.

• Organizar los resultados para su evaluación.

• Registrar los defectos de manera que se pueda hacer seguimiento a su solución, tal cual como sucede con las no conformidades encontradas durante las revisiones de ACS.

Para ejecutar las pruebas se debe disponer de un ambiente estructurado para satisfacer la estrategia de pruebas diseñada. Los desarrolladores son responsables de ejecutar las pruebas unitarias y de integración. En algunos casos son responsables de ejecutar las pruebas del sistema. Las que deben ser independientes son las pruebas de aceptación. La ejecución de las pruebas finaliza cuando se han ejecutado el 100% de los procedimientos de prueba de acuerdo con la estrategia de prueba planteado y no se han encontrado errores que detengan la operación del sistema o que no cumplan con los resultados esperados.

Analizar y Evaluar Resultados

El proceso de analizar y evaluar los resultados de las pruebas, se realiza de la siguiente manera:

• Desarrollar medidas cuantificables del proceso de pruebas.

• Generar informes sobre los defectos y la cobertura de las pruebas.

11

Módulo: Pruebas de Software

La cobertura de las pruebas es un valor que indica según los resultados de las pruebas qué tanto se cumple con los requerimientos de funcionalidad del software desarrollado. El informe incluye:

• La lista de las pruebas ejecutadas y el resultado (exitoso o fallido).

• Un resumen de los Procedimientos de Pruebas ejecutados

indicando el requerimiento que cubre.

• Gráficos de distribución de defectos, tendencia del número de defectos en un periodo de tiempo y Tiempo de permanencia de los defectos no solucionados.

12

Módulo: Pruebas de Software

Bibliografía

Moschini, R., Fundamentos de Prueba Funcional – Manual del Estudiante, Rational.Software, 2004

Pressman, R. S., Ingeniería de Software - Un Enfoque Práctico, Mc Graw Hill, 2002.

13

Módulo: Pruebas de Software

Resumen Curricular

Eumelia Marcano de Silva

La Sra. Eumelia Marcano de Silva es Consultor de Procesos y Calidad con 23 años de experiencia en Informática. Durante este tiempo ha estado involucrado en diferentes proyectos asociados a diferentes áreas de negocios: producción de crudo, materiales, finanzas y gobierno, desempeñándose en posiciones técnicas y supervisoras con logros significativos en el análisis, diseño, construcción e implantación de Sistemas de Información utilizando metodologías estructuradas, así como en la Planificación y Control de Proyectos y en la aplicación de modelos y métodos para la Mejora de Procesos. Ha trabajado en equipo de En el año 1997 fue asignada al equipo de Calidad y Procesos en Venezuela y en asignaciones especiales es USA. Ha participado en equipo de Mejoras de Procesos de Desarrollo de Software y en la implantación del Capability Maturity Model (CMM) del Software Engineering Institute de la Carnegie Mellon University; siendo responsable de implantar las funciones de Aseguramiento de Calidad para satisfacer los requerimientos del Software Engineering Institute (SEI) CMM Nivel 2, revisión de los procesos y procedimientos de Gerencia de Proyectos, preparación y dictado de talleres de adiestramiento y asesorías a los equipos de proyectos. Entre los adiestramientos se incluyen CMM, Gerencia de Proyectos, Planificación y Control de Proyectos, Gerencia de Requerimientos, Aseguramiento de Calidad , Manejo de la Configuración y Pruebas. Adicionalmente, ha participado en dos evaluaciones de CMM. Actualmente se desempeña como Gerente de Calidad de Sistemas para una institución financiera, implantando la función de Aseguramiento de Calidad de Sistemas y un modelo de Desarrollo de Software.

14

Módulo: Pruebas de Software

Resumen curricular (continuación)

Gloria Vergel Especialista en Gerencia de Proyectos con una experiencia de 17 años en el área de Informática. Es graduada en Ingeniería Civil en la Universidad Rafael Urdaneta (URU), con estudios de cuarto nivel en Gerencia de Mantenimiento y Gerencia de Empresas ambas en la Universidad del Zulia (LUZ). Certificada como Project Managenement Professional - PMP (1999) por el Project Management Institute.

Ha participado en equipos de Mejoras de Procesos de Desarrollo de Software y en la implantación del Capability Maturity Model (CMM) del Software Engineering Institute de la Carnegie Mellon University; siendo responsable de implantar las funciones de Planificación y Control de Proyectos para satisfacer los requerimientos del Software Engineering Institute (SEI) en CMM Nivel 2.

Ha realizado la preparación y dictado de talleres de adiestramiento en diferentes áreas, tanto de Ingeniería de Software como de Gerencia de Proyectos. Ha brindado asesorías a los equipos de proyectos en las áreas de Planificación y Control de Proyectos, Gerencia de Requerimientos y en los requisitos del SEI para las evaluaciones de CMM para el Nivel 2. Adicionalmente, ha participado en dos evaluaciones de CMM.

15