Tarea: Implementar el conjunto de aplicaciones de prueba
En esta tarea se describe cómo identificar qué pruebas se deben ejecutar conjuntamente.
Objetivo

El objetivo de esta tarea es:

  • Ensamblar colecciones de pruebas que se van a ejecutar conjuntamente para capturar registros de prueba útiles
  • Facilitar la amplitud adecuada de cobertura de prueba mediante la ejecución de combinaciones interesantes de pruebas
Relaciones
Pasos
Examinar los conjuntos de aplicaciones de prueba candidatos
Objetivo:  Entender los conjuntos de aplicaciones de prueba y seleccionar qué candidatos se implementarán

Empiece por revisar las esquematizaciones de conjuntos de aplicaciones de prueba existentes y determine qué conjuntos de aplicaciones de prueba son buenos candidatos para la implementación actualmente. Utilice el plan de prueba de iteración, la lista de ideas de prueba y los productos de trabajo adicionales de definición de pruebas como base en la toma de decisiones.

Examinar las pruebas relacionadas y los elementos de prueba de destino
Objetivo:  Entender las relaciones entre las pruebas planificadas y los elementos de prueba de destino

Para cada conjunto de aplicaciones de prueba seleccionado para su implementación, identifique los elementos de prueba de destino y las pruebas asociadas que son candidatos para incluirse en el ámbito del conjunto de aplicaciones de prueba.

Identificar las dependencias de las pruebas
Objetivo:  Identificar las dependencias que tienen las pruebas en términos de otras pruebas y, en general, en relación con el estado del sistema

Empiece por considerar la configuración del entorno de prueba y el estado específico de inicio del sistema. Considere cuáles serán los requisitos de configuración específicos como, por ejemplo, el conjunto de datos de inicio para las bases de datos dependientes. Si se va a utilizar una configuración de entorno de destino para varios conjuntos de aplicaciones de prueba, identifique los valores de configuración que se deberán gestionar para cada conjunto de aplicaciones de prueba como, por ejemplo, la resolución de las pantallas de vídeo o los valores regionales del sistema operativo.

A continuación, determine las relaciones específicas entre las pruebas. Busque dependencias donde la ejecución de una prueba incluida en el conjunto de aplicaciones de prueba provoque un cambio de estado del sistema necesario como condición previa de otra prueba.

Una vez identificadas las dependencias relevantes, determine la secuencia correcta de ejecución de las pruebas dependientes.

Identificar oportunidades de reutilización
Objetivo:  Mejorar la capacidad de mantenimiento del conjunto de aplicaciones de prueba, mediante la reutilización de los activos existentes y la consolidación de nuevos activos 

Uno de los principales retos en el mantenimiento de un conjunto de aplicaciones de prueba (especialmente de uno automatizado) es garantizar que los cambios en curso sean fáciles de realizar. Siempre que sea posible y útil, se recomienda mantener un punto central de modificación de elementos que se utilizan en varias partes. Esto es especialmente útil si esos mismos elementos pueden cambiar.

Aunque las propias pruebas forman unidades naturales de modularidad, el ensamblaje de las pruebas en un conjunto de aplicaciones de prueba identifica a menudo elementos de procedimiento duplicados en varias pruebas que se pueden mantener mejor si se consolidan. Identifique si es posible los mecanismos generales de las pruebas que se puedan refactorizar en una rutina estándar para ayudar al mantenimiento en curso.

Aplicar los programas de utilidad de infraestructura necesarios
Objetivo:  Descomponer en factores los detalles de implementación complejos necesarios para dar soporte a las pruebas como funciones de programas de utilidad simplificadas 

La mayoría de esfuerzos de prueba requieren el uso de uno o más "programas de utilidad" que generan, recopilan, diagnostican, convierten y comparan la información utilizada durante la ejecución de la prueba. Estos programas de utilidad permiten simplificar las tareas complejas y laboriosas que normalmente darían errores si se ejecutaran de forma manual. Este paso está relacionado con la aplicación de funciones de programas de utilidad existentes dentro del conjunto de aplicaciones de prueba y con la identificación de los nuevos programas de utilidad necesarios.

Se recomienda simplificar las interfaces a estos programas de utilidad y encapsular la máxima complejidad posible dentro de la implementación privada del programa de utilidad. También es una buena idea desarrollar el programa de utilidad de forma que se pueda reutilizar cuando sea necesario para los esfuerzos de prueba manuales y automáticos.

Se recomienda no ocultar la información que caracteriza a una prueba individual dentro de estos programas de utilidad; en su lugar, limite el programa de utilidad a la mecánica compleja de recopilar información o de comparar los valores reales con los resultados esperados, etc.; no obstante, siempre que sea posible, pase las características específicas de cada prueba individual como entrada de (y devuelva los resultados reales individuales como salida a) una prueba o un conjunto de aplicaciones de prueba de control.

Determinar los requisitos de recuperación
Objetivo:  Habilitar los conjuntos de aplicaciones de prueba para que se puedan recuperar sin necesidad de volver a ejecutar completamente el conjunto de aplicaciones de prueba 

Determine los puntos adecuados dentro del conjunto de aplicaciones de prueba para proporcionar la recuperación si el conjunto de aplicaciones de prueba falla durante la ejecución. Este paso gana en importancia cuando el conjunto de aplicaciones de prueba está previsto que contenga un gran número de pruebas o que se ejecute un periodo prolongado de tiempo, a menudo desatendido. Aunque casi siempre se identifican como un requisito para los conjuntos de aplicaciones de prueba automatizados, también es importante considerar los puntos de recuperación en los conjuntos de aplicaciones de prueba ejecutados manualmente.

Además de los puntos de recuperación o reinicio, puede considerar (en el caso de los conjuntos de aplicaciones de prueba automatizados) la recuperación automatizada de conjuntos de aplicaciones de prueba. Los dos enfoques de la recuperación automática son: 1) la recuperación básica, donde el conjunto de aplicaciones de prueba existente puede recuperarse de un error menor ocurrido en una de sus pruebas, normalmente recuperando la ejecución en la siguiente prueba del conjunto de aplicaciones de prueba; 2) la recuperación sofisticada, que realiza una limpieza después de la prueba anómala y restablece el estado del sistema correspondiente, incluido el reinicio del sistema operativo y la restauración de los datos si es necesario. Como en el primer enfoque, el conjunto de aplicaciones de prueba determina la prueba que ha fallado y selecciona la siguiente prueba que debe ejecutarse.

Implementar los requisitos de recuperación
Objetivo:  Implementar y verificar que el proceso de recuperación funciona según lo esperado 

Dependiendo del nivel de sofisticación necesario, requerirá un esfuerzo adicional para implementar y estabilizar el proceso de recuperación. Deberá dedicar algún tiempo a simular una serie de anomalías probables (y algunas menos probables) para probar que el proceso de recuperación funciona.

En el caso de la recuperación automatizada, los dos enfoques descritos en el paso anterior tienen puntos débiles y fuertes. Considere atentamente el coste de la sofisticada recuperación automatizada, en términos de desarrollo inicial y de esfuerzo de mantenimiento constante. A veces, la recuperación manual es suficiente.

Estabilizar conjunto de aplicaciones de prueba
Objetivo:  Resolver los problemas de dependencia en términos de estado del sistema y secuencias de ejecución de prueba 

Dedique tiempo a estabilizar el conjunto de aplicaciones de prueba mediante una o varias ejecuciones de prueba experimentales, siempre que sea posible. La dificultad de alcanzar la estabilidad aumenta proporcionalmente con la complejidad del conjunto de aplicaciones de prueba, y allí donde existe un acoplamiento excesivo entre pruebas no relacionadas y una cohesión débil ente pruebas relacionadas.

Existe la posibilidad de que se produzcan errores cuando se ejecutan pruebas conjuntamente dentro de un determinado conjunto de aplicaciones de prueba que no se producen cuando las pruebas individuales se ejecutan independientemente. Estos errores son a menudo los más difíciles de rastrear y diagnosticar, especialmente cuando se encuentran a medio camino en una ejecución de prueba automatizada de larga duración. Se recomienda, siempre que resulte práctico, volver a ejecutar el conjunto de aplicaciones de prueba regularmente a medida que se añadan pruebas adicionales. Esto permitirá aislar un número menor de posibles pruebas candidatas que se diagnosticarán para identificar el problema.

Mantener relaciones de rastreabilidad
Objetivo:  Permitir ejecutar el análisis de impactos y el informe de valoración en los elementos rastreados 

Utilizando los requisitos de rastreabilidad descritos en el plan de prueba, actualice las relaciones de rastreabilidad según sea necesario. Los conjuntos de aplicaciones de prueba se pueden rastrear hasta guiones de prueba definidos o hasta ideas de prueba. De manera opcional, se pueden rastrear hasta casos de uso , elementos de la especificación de software, elementos del modelo de implementación y hasta una o varias medidas de cobertura de la prueba.

Evaluar y verificar los resultados
Objetivo:  Verificar que la tarea se ha realizado correctamente y que los productos de trabajo resultantes son aceptables 

Ahora que ha terminado el trabajo, se recomienda verificar que el trabajo tenía el valor suficiente y que no sólo ha gastado una gran cantidad de papel. Debe evaluar si el trabajo tiene la calidad correcta y si es lo suficientemente completo para que resulte útil a aquellos miembros del equipo que vayan a utilizarlo posteriormente como entrada de su trabajo. Siempre que sea posible, utilice las listas de comprobación proporcionadas en RUP para verificar que la calidad y la completitud son lo "suficientemente buenas".

Fomente la participación en la revisión del trabajo interno de las personas que realizan tareas basadas en los resultados de su trabajo. Hágalo mientras todavía tenga tiempo para realizar acciones para solucionar sus problemas. También debe evaluar su trabajo en los productos de trabajo de entrada clave para asegurarse de que los ha representado de forma precisa y suficiente. Para ello, es muy útil hacer que el autor del producto de trabajo de entrada revise su trabajo.

Recuerde que RUP es un proceso de entrega iterativo y que en muchos casos los productos de trabajo evolucionan con el tiempo. Como tal, no siempre es necesario (y a veces es contraproducente) formar completamente un producto de trabajo que sólo se utilizará de forma parcial o que no se utilizará en absoluto en un trabajo inmediatamente posterior. Esto se debe a que existe una alta probabilidad de que la situación alrededor del producto de trabajo cambie (y que las suposiciones realizadas cuando se creó el producto de trabajo se demuestre que son incorrectas) antes de que se utilice el producto, lo que da como resultado un esfuerzo inútil y una revisión costosa. Asimismo, evite la trampa de invertir demasiados ciclos en la presentación en detrimento del valor del contenido. En entornos de proyecto en los que la presentación tenga importancia y un gran valor económico como entregable del proyecto, puede utilizar un recurso administrativo para ejecutar tareas de presentación.



Propiedades
Varias apariciones
Condicionado por sucesos
Continuo
Opcional
Planeado
Se puede repetir
Más información