Proceso de Pruebas de RUP CONTENIDO
Introducción. Actividades de Pruebas. Contribución de los Probadores (tester) a las 4 Fases de RUP.
Descripción General Del Workflow De Pruebas. Etapas Del Workflow De Pruebas. Artefactos de Pruebas. Roles y Actividades Presentes en el Proceso de Pruebas. Herramientas. INTRODUCCIÓN Hoy en día y como vemos las pruebas ya no son u na situación que surja en las etapas finales del proyecto, estas conllevan una planeación, estrategias y parámetros para poder lograr su ob jetivo, las cuales se conciben desde la fase de incepción del pro yecto, contando con ciertas actividades que ayudan a llevarlas de manera mas eficiente. Las actividades comienzan con el plan de pruebas, este documento contiene información relacionada con los objetivos, tanto generales como específicos, así como de la estrategia y los recursos que le serán destinados. Es necesario definir que se va a probar, como se va a hacer, de tal forma que vayamos obteniendo resultados que nos permitan refinar el proyecto. Rational ofrece su enfoque de pruebas usando RUP para valorar la calidad del software por medio de los siguientes objetivos:
Encontrar y documentar los defectos en la calidad del software Aconsejando acerca de la calidad percibida en el software Proveyendo la validación de los supuestos hechos en las especificaciones de diseño y los requerimientos a través de demostraciones concretas Validando las funciones del producto de software según fueron diseñadas Validando que los requerimientos hayan sido implementados apropiadamente Validación del diseño.
ACTIVIDADES DE PRUEBAS
CONTRIBUCIÓN DE LOS PROBADORES A LAS 4 FASES DE RUP
El siguiente diagrama muestra de forma general las pruebas realizadas en RUP:
DESCRIPCIÓN GENERAL DEL WORKFLOW DE PRUEBAS El propósito de este workflow de RUP es:
Verificar la interacción entre objetos Verificar la interacción apropiada de todos los componentes del software Verificar que todos los requerimientos hayan sido implementados correctamente Identificar y asegurar que los defectos se hayan atendido y resuelto antes del despliegue del software En RUP, las pruebas son enfocadas a través del uso de un proceso iterativo y de herramientas. Un enfo que iterativo para probar permite a la organización tratar las pruebas casi de la misma forma que el desarrollo de software es enfocado. Cada elemento del proyecto es un objetivo para las pruebas. Según se vayan produciendo nuevos productos de trabajo, el cuerpo de pruebas será añadido y refinado. Eventualmente, todas las pruebas en el cuerpo de pruebas serán acumuladas de tal manera que pueden ser usadas para las posteriores pruebas de regresión en el ciclo de vida del desarrollo de software. Este enfoque permite a una organización:
Identificar posibles riesgos al inicio de un proyecto. Reducir el costo de corregir fallas enfocando los recursos cuando y donde tendrán el mayor impacto. Maximizar la efectividad por medio de adaptar el enfoque, el proceso o el presupuesto según va progresando el proyecto. Este workflow del de Pruebas está relacionado a otros workflows del RUP como sigue:
El Workflow de Requerimientos captura el input principal para identificar cuales pruebas efectuar en la forma de requerimientos en un modelo de casos de uso. El Workflow de Análisis y Diseño captura el input principal para identificar cuales pruebas efectuar describiendo cómo desarrollar un diseño. El Workflow de Implementación produce las construcciones de software del modelo de implementación que es probado por medio del Workflow de Pruebas.
Dentro de una iteración, hay varias construcciones probadas: la primera cuando el sistema es integrado y la última para probar todo el sistema.
ETAPAS DEL WORKFLOW DE PRUEBAS
Planificar las Pruebas: El principal artefacto producido es el Plan de Pruebas. Diseñar las Pruebas: Los principales artefactos producidos son el Modelo de Pruebas (Test Model), los Casos de Prueba (Test Case), los Procedimientos de Prueba (Test Procedures) y el documento de Análisis de Carga de Trabajo (Workload Analysis Document). Implementar las Pruebas: Los principales artefactos producidos son el Script de la Prueba y el Componente de la Prueba. Ejecutar las Pruebas en la etapa de Integración de Pruebas: El principal artefacto producido es el documento Resultado de Pruebas. Ejecutar las Pruebas en la etapa de Pruebas del Sistema: El principal artefacto producido es el documento Resultado de Pruebas. Evaluar las Pruebas: Los principales artefactos producidos son el Sumario de Evaluación de Pruebas (Test Evaluation Summary) y los Requerimientos de Cambio (Change Request).
Cada actividad en el Workflow es esencial para probar el proyecto exitosamente. Ninguna actividad debe ser removida del Workflow de Pruebas.
ARTEFACTOS DE PRUEBAS Los artefactos presentados en la siguiente tabla son productos finales e intermedios que son realizados y usados durante el Workflow de Pruebas de un proyecto. Los artefactos de Pruebas capturan y comunican información de pruebas y pueden tomar la forma de un documento, un modelo o un elemento de modelo. La Tabla 1: Identifica algunos de los artefactos que deben ser desarrollados en el Workflow de Pruebas.
Artefactos
Creado / Revisado Incep Elab Cons Trans
Caso de Pruebas
X
Plan de Pruebas / Procedimientos
X
Informal Test Manager - Interno X
Formal
Manager
– Externo o Prueba Interna
Resultados de las Pruebas Script de Pruebas
Revisar Herramientas Detalles Usadas
X
X
X
Formal Interno
X
X
Informal Robot, Manual Test – Interno
Breve esquema de un caso de prueba 1. Descripción del caso de prueba.
Test Manager
Una descripción de la finalidad o el objetivo de la prueba, el alcance, y cualquier precondición de la prueba. 2. Condición de ejecución. Una descripción de la condición de que se ejecutará durante esta prueba: 1. Condiciones previas. Por cada condición de ejecución, describir el estado requerido en el que el sistema deberia estar antes de que la prueba pueda comenzar. 2. Prueba de Entradas. Por cada condición de ejecución, enumerar una lista de los estímulos específicos que deben aplicarse durante la prueba. Esto es lo que suele denominarse la "Entradas" de la prueba, e incluye los objetos o campos que se comunican y los valores especificos de datos entrados al ejecutar este caso de prueba. 3. Puntos de observación. Durante la ejecución de la prueba, enumerar qué observaciones se deberán efectuar. 4. Puntos de Control. Durante la ejecución de la prueba, identificar los puntos en los que el flujo de control se puede alterar o puede variar. 5. Resultados esperados. El estado resultante o las condiciones observables que se espera como resultado de la prueba de haber sido ejecutados. Tener en cuenta que este puede tener tanto resultados positivos como negativos (por ejemplo, condiciones erroneas y fallas). 6. Post condiciones. Por cada condición de ejecución, describir el estado requerido que el sistema debería regresar, permitiendo posteriores pruebas.
Breve esquema del plan de pruebas El plan de pruebas captura información de los siguientes elementos:
1. 2. 3. 4.
La definición de las metas y objetivos del esfuerzo de pruebas en el ámbito de aplicación de la iteración (o proyecto). La definición de los elementos de prueba dirigidos. Una explicación del enfoque o estrategia que se utilizará. Los recursos y calendario requeridos.
5.
Los entregables a ser producidos.
Breve esquema de los resultados de pruebas La información (en contraposición a los datos brutos), contenida por los resultados de prueba puede variar dependiendo de la tecnología y las herramientas utilizadas durante la ejecución de prueba para capturar el registro de pruebas (Test log), y después del hecho de conducir el análisis de la materia prima de las pruebas, los datos del registro de pruebas (Test Log). Aquí están algunas ideas para datos que se puede determinar, y puestos a disposición para su revisión y evaluación:
1. 2.
Identificador de resultados de Prueba (ID para la identificación de estos Resultados de Prueba de otros). Hora, fecha, nombre del evaluador, e información del ambiente (como O/S, características de la máquina, y así sucesivamente). 3. Identificación específica de los objetos de prueba objetivo (por ejemplo, la versión, objetos y archivos). 4. Casos de prueba destinados a ser ejecutados. 5. Casos de prueba ejecutados. 6. Medición de tamaño de los objetos de prueba objetivo a ser ejecutados. 7. Medición de tamaño de los objetos de prueba objetivo ejecutados. 8. Tiempo de respuesta para determinadas secuencias de eventos. 9. Rastro de datos que contienen los detalles de las conversaciones entre los actores y los objetos de prueba objetivo, y/o entre los objetos en los objetos de prueba objetivo. Resultado obtenido de cada caso de prueba ejecutado. 10. Las diferencias entre el resultado esperado y el resultado obtenido. 11. Una indicación de avance o no para cada caso de prueba ejecutado. 12. Nivel real de integridad y los resultados positivos de cada Suite de pruebas ejecutado. 13. Cualquier imprevisto o resultados anormales o comportamientos. 14.
Breve Esquema de los Script de Pruebas
Cada script de pruebas debe considerar varios aspectos incluyendo los siguientes:
1. 2. 3. 4. 5. 6. 7.
Los requerimientos básicos de hardware de computadora, por ejemplo, procesadores, memoria de almacenamiento, disco duro de almacenamiento, dispositivos de interfaz de entrada / salida de interfaz de dispositivo. La base subyacente del ambiente de software, por ejemplo, el sistema operativo y las herramientas básicas de productividad como el correo electrónico o un sistema de calendario. Hardware periférico adicional especializado de entrada / salida; por ejemplo, escáner de código de barras, dispositivos sensor, etc. El software necesario para hardware periférico adic ional especializado de entrada / salida, por ejemplo, controladores, interfaz y puertas de enlace de software. El conjunto mínimo de herramientas de software necesarias para facilitar la prueba, la evaluación y actividades de diagnóstico, por ejemplo, los diagnósticos de memoria, ejecución de pruebas automatizadas, y así sucesivamente. Los ajustes de configuración necesarios tanto de hardware como de software, por ejemplo, resolución de pantallas de video, la asignación de recursos, las variables de entorno, y así sucesivamente. Las necesidades de "preexistentes" de consumo, por ejemplo, los conjuntos de datos de población.
Fragmentos tomados del libro electrónico de RUP Version 2003.06.12.01
ROLES Y ACTIVIDADES PRESENTES EN EL PROCESO DE PRUEBAS
Habilidades del encargado de las pruebas:
El conjunto de conocimientos y habilidades pueden variar en función de los tipos de pruebas ejecutados y de las fases del ciclo de vida del proyecto, sin embargo, en general, el personal encargado de las pruebas debe tener las siguientes competencias:
* Conocimiento de técnicas y enfoques de prueba. * Habilidades de diagnóstico y resolución de problemas * El conocimiento del sistema o la aplicación a probar (deseable) * Conocimiento de redes y arquitectura de sistemas (deseable) Cuando se requieren pruebas automatizadas, estas habilidades deben considerarse además de las que ya se ha señalado anteriormente: * Formación en el uso adecuado de herramientas de automatización de pruebas * Experiencia en el uso de herramientas de automatización de pruebas * Conocimientos de programación * Habilidades de depuración y diagnóstico Este papel es el principal responsable de: * Identificar el más adecuado enfoque de implementación para una prueba dada. * La aplicación de las pruebas individuales * Creación y ejecución de las pruebas * Registro de resultados de prueba y verificación de la ejecución * Análisis y recuperación de errores de ejecución Segmento tomado del libro electrónico de RUP Version 2003.06.12.01
HERRAMIENTAS
Robots de Pruebas (Rational Robot) Herramientas de Pruebas funcionales (Rational TeamTest, Rational VisualTest). Herramientas de Pruebas de desempeño y confiabilidad (Rational SiteLoad, Rational QualityArchitect). Frameworks de pruebas unitarias (JUnit).
PROCESO DE PRUEBAS EN RUP
De acuerdo al libro electrónico RATIONAL UNIFIED PROCESS, "la disciplina de pruebas se centra principalmente en la evaluación de la calidad del producto y se lleva acabo de acuerdo a las siguientes prácticas:
1. 2. 3. 4. 5.
Buscar y documentar defectos en la calidad del software. Servir como guía para el logro de la calidad del software. Validar que el software funciona de acuerdo a las especificaciones que se hicieron en el diseño". Dicha disciplina, está representada en un diagrama de actividades o flujo de trabajo en donde se especifican cada una de las etapas que evalúan cada aspecto del desarrollo de software.
Primer flujo de trabajo: MISIÓN DE LA EVALUACIÓN. Segundo flujo de trabajo: VERIFICACIÓN DEL ENFOQUE DE LA PRUEBA . Tercer flujo de trabajo: VALIDACIÓN DE LA ESTABLIDAD . Cuarto flujo de trabajo: PRUEBAS Y EVALUACIÓN . Quinto flujo de trabajo: LOGRO DE UNA MISIÓN ACEPTABLE . MISIÓN DE LA EVALUACIÓN El propósito de la misión de la evaluación es identificar la manera más adecuada para realizar los modelos de prueba en cada iteración, así como de ponerse de acuerdo con las partes interesadas sobre los objetivos correspondientes en cada prueba.
1. 2. 3. 4. 5.
DESCRIPCIÓN "Para cada iteración, esta actividad se centra:
Identificar los objetivos y los resultados de las pruebas. Identificación de una estrategia para el aprovechamiento de los recursos. Definir el alcance y límites de la prueba. Hacer un bosquejo del enfoque que se utilizará. Definir la forma de evaluación del proceso de cada prueba". (libro electrónico: RATIONAL UNIFIED PROCESS).
VERIFICACIÓN DEL ENFOQUE DE PRUEBA El objetivo del enfoque es demostrar que las diversas técnicas descritas en dicho enfoque facilitan la consecución del objetivo. Se enfoca en verificar que el enfoque de trabajo produce resultados exactos y es apropiado para los recursos disponibles.
DESCRIPCIÓN La verificación del enfoque ayuda a investigar si existen riesgos en el ciclo de vida del proyecto antes de que sea demasiado tarde y que pueda dar resultado de la viabilidad de la prueba. "Para cada iteración, este trabajo se centra principalmente en: a) Comprobar que la estrategia de trabajo produce resultados de valor. b) El establecimiento de la infraestructura básica para permitir y apoyar la estrategia de prueba. c) Obtener el compromiso del equipo para el desarrollo del software para satisfacer los requisitos de prueba necesarios para cumplir con la estrategia de prueba y garantizar la continuidad de dicha estrategia. d) Identificar el alcance, fronteras, limitantes y restricciones de cada técnica". (libro electrónico: RATIONAL UNIFIED PROCESS). VALIDACIÓN DE LA ESTABILIDAD
El propósito de este flujo de trabajo es validar que la construcción es lo suficientemente estable como para conocer con detalle la evaluación de la prueba. También se le conoce como prueba de humo, prueba de verificación de la construcción, prueba de construcción de regresión, etc. Contribuye también a evitar que l os recursos se desperdicien inútilmente.
"Para cada objeto que será construido y que será sujeto a prueba, la validación de la estabilidad se enfoca en: a) Realizar una evaluación de la estabilidad y comprobabilidad de la construcción. b) Obtener una confirmación de las expectativas del trabajo de desarrollo de la construcción. c) Realizar una decisión de aceptación (documento) para la construcción, que sea adecuado para su uso, guiándose de la misión de la evaluación en cada una de las pruebas o para conducir a la construcción de nuevas pruebas". (Libro electrónico: RATIONAL UNIFIED PROCESS).
PRUEBAS Y EVALUACIÓN El propósito de éste flujo de trabajo es permitir una evaluación consistente de los elementos que serán sujetos a prueba donde la evaluación se rige por las pruebas de motivación y misión de la evaluación. Se lleva a cabo una vez por cada ciclo de prueba, este trabajo implica la realización de un trabajo de prueba y evaluación del esfuerzo tales como: conocimiento de la implementación, ejecución y evaluación de pruebas específicas y reportes correspondientes a los incidentes que son encontrados a lo largo del ciclo. "Para cada ciclo de prueba, este trabajo se enfoca principalmente en:
Proporcionar una evaluación continua y un a evaluación de las pruebas metas de cada ciclo.
Recopilación de la información necesaria para diagnosticar y resolver ciertas cuestiones o problemas identificados. Proveer una lista de riesgos potenciales". (Libro electrónico: RATIONAL UNIFIED PROCESS). LOGRO DE UNA MISIÓN ACEPTABLE El objetivo de este flujo de trabajo es entregar un resultado útil de evaluación a los interesados (stakeholders) de la prueba, siempre y cuando los resultados de la evaluación son útiles en términos de la misión de la evaluación. En la mayoría de los casos, esto se centraría en ayudar al equipo de trabajo para el logro de los objetivos del plan de iteración que aplicaran al ciclo de pruebas. "Para cada ciclo de prueba, este trabajo se centra principalmente en:
Dar prioridad a la selección de pruebas que sean necesarias para conducir al cumplimiento de la evaluación de la misión. Promover la resolución de cuestiones importantes que tienen un impacto negativo en la misión de de la evaluación". (Libro electrónico: RATIONAL UNIFIED PROCESS).
