Tarea: Estructurar la implementación de la prueba
En esta tarea se describe cómo definir la estructura general para la implementación del conjunto de aplicaciones de prueba.
Objetivo

El objetivo de esta tarea es:

  • Establecer la estructura en la que residirá la implementación del conjunto de aplicaciones de prueba
  • Asignar responsabilidades para las áreas de implementación del conjunto de aplicaciones de prueba y su contenido
  • Esquematizar los conjuntos de aplicaciones de prueba necesarios
Relaciones
Pasos
Examinar el enfoque de prueba, los elementos de prueba de destino y las necesidades de valoración
Objetivo:  Entender cómo se valorarán las pruebas, y sus implicaciones en el modo en que se deben implementar los conjuntos de aplicaciones de prueba específicos, para valorar los elementos de prueba de destino. 

Empezando por una revisión del plan de prueba para determinar las necesidades de valoración, considere cómo se puede determinar la valoración del grado de prueba y la calidad del software utilizando el enfoque de prueba indicado. Tenga en cuenta las necesidades especiales relacionadas con elementos de prueba de destino específicos.

Examinar los mecanismos de comprobabilidad y los elementos de soporte
Objetivo:  Conocer los elementos de comprobabilidad disponibles, y entender a qué mecanismos dan soporte y qué ventajas ofrecen. 

Revise los mecanismos que son útiles para habilitar las pruebas en este entorno, e identifique los elementos de comprobabilidad específicos que implementan esos mecanismos. Esto incluye revisar recursos como, por ejemplo, las bibliotecas de funciones que ha desarrollado el equipo de prueba, y los fragmentos o los fijadores que ha implementado el equipo de desarrollo.

La comprobabilidad se obtiene mediante la combinación del desarrollo de software que se puede probar y la definición de un enfoque de prueba que proporciona el soporte adecuado a las pruebas. De esta forma, la comprobabilidad es un aspecto importante del desarrollo de activos de los equipos de prueba, a la vez que constituye una parte importante del esfuerzo de desarrollo de software. Para alcanzar la comprobabilidad (la habilidad de probar el producto de software de manera eficaz), se necesita normalmente una combinación de lo siguiente:

  • habilitadores de comprobabilidad proporcionados por las herramientas de automatización de pruebas
  • técnicas específicas para crear los scripts de prueba de componentes
  • bibliotecas de funciones que separan y encapsulan la complejidad de la definición básica de procedimientos de prueba en el script de prueba, a la vez que proporcionan un punto central de control y modificación.

Analizar los requisitos de distribución

¿Tiene el conjunto de aplicaciones de prueba actual el requisito de estar distribuido? En caso afirmativo, utilice los elementos de comprobabilidad que dan soporte a la distribución. Estos elementos serán normalmente características de herramientas específicas de soporte de automatización que distribuirán el conjunto de aplicaciones de prueba, lo ejecutarán de forma remota y devolverán el registro de prueba y otras salidas para la determinación de resultados centralizados.

Analizar los requisitos de concurrencia

¿Tiene el conjunto de aplicaciones de prueba actual el requisito de ejecutarse de forma concurrente con otros conjuntos de aplicaciones de prueba? En caso afirmativo, utilice los elementos de comprobabilidad que dan soporte a la concurrencia. Estos elementos serán normalmente una combinación de herramientas específicas de soporte y funciones de programa de utilidad para habilitar la ejecución concurrente de varios conjuntos de aplicaciones de prueba en máquinas físicas diferentes. La concurrencia requiere una gran precisión en el diseño y la gestión de los datos de prueba para garantizar que no se produzcan efectos secundarios imprevistos o inesperados como, por ejemplo, que dos pruebas concurrentes actualicen el mismo registro de datos.

Crear la estructura inicial del conjunto de aplicaciones de prueba
Objetivo:  Esquematizar los conjuntos de aplicaciones de prueba que se van a implementar. 

Enumere uno o varios conjuntos de aplicaciones de prueba que proporcionen (cuando se ejecuten) un resultado completo y significativo de gran valor para el equipo de prueba, lo que permite realizar informes posteriores para los interesados. Intente encontrar un equilibrio entre un nivel de detalle suficiente que permita proporcionar información específica al equipo del proyecto, pero que no sea tanto que no se pueda abarcar ni gestionar.

Allí donde ya existan scripts de prueba, puede ensamblar el conjunto de aplicaciones de prueba y sus partes constituyentes, y pasar el trabajo de estabilización del conjunto de aplicaciones de prueba a un implementador de conjuntos de aplicaciones de prueba para que lo complete.

Para los conjuntos de aplicaciones de prueba que requieran la creación de nuevos scripts de prueba, también debe proporcionar alguna indicación de los scripts de prueba (o de otros conjuntos de aplicaciones de prueba) a los que crea que se hará referencia en este conjunto de aplicaciones de prueba. Si es fácil enumerarlos, hágalo. Si no, puede proporcionar simplemente una breve descripción de la cobertura de contenido esperada del conjunto de aplicaciones de prueba principal y dejar que el implementador de conjuntos de aplicaciones de prueba tome las decisiones tácticas sobre qué scripts de prueba se incluyen exactamente.

Adaptar la estructura de conjuntos de aplicaciones de prueba para que refleje la organización del equipo y las restricciones de herramientas
Objetivo:  Perfeccionar la estructura de conjuntos de aplicaciones de prueba para trabajar con las asignaciones de responsabilidad del equipo. 

Puede que tenga que subdividir o reestructurar aún más los conjuntos de aplicaciones de prueba que ha identificado para albergar la estructura detallada de trabajo (WBS) con la que trabaja el equipo. Esto permitirá reducir el riesgo de que se produzcan conflictos de acceso durante el desarrollo de conjuntos de aplicaciones de prueba. A veces, las herramientas de automatización de pruebas pueden añadir restricciones sobre cómo pueden trabajar las personas con los activos de automatización, por lo que se deben reestructurar los conjuntos de aplicaciones de prueba para que incluyan esto si es necesario.

Identificar mecanismos de comunicación entre scripts de prueba
Objetivo:  Identificar datos de prueba y estados del sistema que se deben compartir o pasar entre scripts de prueba. 

En la mayoría de los casos, los conjuntos de aplicaciones de prueba pueden llamar simplemente a scripts de prueba en un orden específico. Esto será suficiente en la mayoría de los casos para garantizar que se pasa el estado del sistema correcto de un script de prueba al siguiente.

No obstante, en determinadas clases de sistema, el sistema genera datos de tiempo de ejecución dinámicos o estos se derivan como resultado de las transacciones que tienen lugar en ellos. Por ejemplo, en un sistema de entrada y envío de pedidos, cada vez que se entra un pedido, el sistema genera un número de pedido exclusivo. Para habilitar un script de prueba automatizado para que envíe un pedido, el script de prueba de entrada de pedido anterior tiene que capturar el número exclusivo que genera el sistema y pasarlo al script de prueba de envío de pedidos.

En casos como este, deberá considerar qué mecanismo de comunicación entre scripts de prueba es el más adecuado. Las alternativas típicas incluyen los parámetros pasados, la escritura y lectura de valores en un archivo de disco y la utilización de variables de tiempo de ejecución globales. Cada estrategia tiene sus pros y sus contras que la hacen más o menos adecuada en cada situación.

Definir dependencias iniciales entre elementos de conjuntos de aplicaciones de prueba
Objetivo:  Identificar y registrar las dependencias de tiempo de ejecución entre elementos de conjuntos de aplicaciones de prueba. 

Esto se asocia principalmente con la secuencia de los scripts de prueba y probablemente de los conjuntos de aplicaciones de prueba para la ejecución del tiempo de ejecución. Las pruebas que se ejecutan sin tener establecidas las dependencias correctas corren el riesgo de fallar o de notificar datos anómalos.

Modelar visualmente la arquitectura de implementación de la prueba
Objetivo:  Utilizar un diagrama para documentar y explicar cómo se realiza la implementación de la prueba. 

Si tiene acceso a una herramienta de dibujo o de modelado UML, puede crear un diagrama del modelo de implementación de la prueba que describa los elementos clave del software de prueba automatizada. De la misma forma, también puede crear un diagrama de los aspectos clave de la arquitectura de automatización de pruebas.

Otro enfoque es dibujar estos diagramas en una pizarra blanca que sea visible para el equipo de prueba.

Perfeccionar la estructura del conjunto de aplicaciones de prueba
Objetivo:  Realizar los ajustes necesarios para mantener la integridad de la implementación de la prueba. 

A medida que avanza el proyecto, los conjuntos de aplicaciones de prueba pueden cambiar: se añadirán nuevos scripts de prueba, y se actualizarán, reorganizarán o suprimirán scripts antiguos. Estos cambios constituyen una parte normal del mantenimiento del conjunto de aplicaciones de prueba y debe aceptarlos en lugar de evitarlos.

Si no mantiene de manera activa los conjuntos de aplicaciones de prueba, se romperán rápidamente y entrarán en desuso. Si se deja para unas pocas compilaciones, un conjunto de aplicaciones de prueba puede necesitar mucho esfuerzo para volver a funcionar, y será más fácil abandonarlo y crear uno nuevo desde cero. Consulte el apartado Más información: en la tabla de cabecera de esta página para obtener más directrices sobre el mantenimiento de conjuntos de aplicaciones de prueba automatizados.

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.

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, le recomendamos 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