Tarea: Identificar destinos de prueba
En esta tarea se describe cómo identificar los elementos individuales del sistema, tanto de hardware como de software, que deben someterse a prueba.
Disciplinas: Prueba
Relaciones
Pasos
Determinar qué software se implementará
Objetivo:  Entender los principales entregables del equipo de desarrollo en la próxima planificación. 

Utilizando el plan de iteración y otras fuentes disponibles, identifique los elementos de software individuales que el equipo de desarrollo tiene la intención de producir para la próxima iteración. En los casos en que la tarea de desarrollo se distribuye a equipos de diversas ubicaciones, es posible que deba analizar los planes de desarrollo directamente con cada equipo. Compruebe si algún desarrollo está subcontratado y utilice cualquier canal que tenga a su disposición para recopilar detalles sobre la tarea de desarrollo de los subcontratistas.

Además del software nuevo, observe también los cambios realizados en la infraestructura y en los componentes compartidos. Estos cambios pueden afectar a otros elementos de software dependientes o asociados producidos en ciclos de desarrollo anteriores, haciendo que sea necesario probar el efecto de estos cambios sobre dichos elementos. Por motivos similares, debe identificar los cambios y adiciones en componentes de terceros que la tarea de desarrollo tiene la intención de utilizar. Entre ellos se incluyen los componentes compartidos, las bibliotecas de códigos base o comunes, objetos gráficos de la GUI, programas de utilidad de permanencia, etc. Revise la arquitectura de software para determinar qué mecanismos están siendo utilizados y que pueden verse afectados por los cambios en los componentes de terceros.

Identificar elementos del sistema candidatos que deben someterse a prueba
Objetivo:  Identificar elementos de destino en los que se debe ejercer el esfuerzo de prueba. 

Para cada motivador de prueba identificado, examine la lista de elementos de software que deben entregarse como parte de este ciclo de desarrollo. Confeccione una lista inicial que excluya los elementos que no pueden justificarse como útiles en términos de satisfacer los motivadores de prueba. Recuerde incluir el software disponible comercialmente así como el que debe desarrollar directamente el equipo de desarrollo del proyecto.

También deberá tener en cuenta el impacto que los diversos entornos de despliegue de destino tendrán sobre los elementos que deben probarse. La lista de elementos del sistema candidatos debe ampliarse de modo que incluya tanto el software que se está desarrollando como los elementos candidatos del entorno de destino. Estos elementos incluyen dispositivos de hardware, software de controlador de dispositivo, sistemas operativos, software de red y comunicaciones, componentes de software base de terceros (p.ej., software de cliente de correo electrónico, navegadores de Internet, etc.). También incluyen varias configuraciones y valores relacionados con las posibles combinaciones de todos estos elementos.

En los casos en los que haya identificado entornos de despliegue de destino importantes, debe considerar la posibilidad de registrar esta información creando o actualizando una o varias configuraciones de entorno de prueba esquematizadas; el esquema debe incluir un nombre, una descripción breve y enumerar los requisitos o características principales de la configuración. No emplee mucho en estos esquemas; la lista de requisitos y características se detallará posteriormente en la Tarea: Definir las configuraciones del entorno de prueba.

Perfeccionar la lista de candidatos de elementos de destino
Objetivo:  Eliminar destinos innecesarios del plan de trabajo del esfuerzo de prueba y añadir al mismo los elementos que falten.  

Teniendo en cuenta la misión de evaluación y el ámbito del esfuerzo de prueba que se han acordado con los interesados de la evaluación, examine la lista de elementos de destino e identifique los elementos que no satisfacen la misión de evaluación y que están claramente fuera del ámbito del esfuerzo de prueba.

Como comprobación inversa, examine de nuevo los elementos de manera crítica y pregúntese si la lista perfeccionada de elementos de destino cumplirá la misión de evaluación y el ámbito del esfuerzo de prueba. Es posible que sea necesario añadir elementos adicionales a la lista de elementos de destino para garantizar el ámbito apropiado y la capacidad de cumplir la misión de evaluación.

Definir la lista de elementos de destino.
Objetivo:  Comunicar las decisiones tomadas acerca de los elementos del destino de la prueba para el próximo trabajo. 

Ahora que ha decidido los elementos del destino de la prueba, debe comunicar su elección al equipo de prueba y a otros interesados en el esfuerzo de prueba. Posiblemente el método más habitual es documentar las decisiones sobre los elementos de destino en el plan de prueba de iteración.

Una alternativa es simplemente registrar esta información en alguna forma de tabla u hoja de cálculo y utilizarla para llevar a cabo la asignación de trabajos y responsabilidades. Durante la implementación y ejecución de la prueba, verificadores individuales utilizarán esta información para tomar decisiones tácticas sobre las pruebas específicas que deben implementarse y sobre qué resultados de la prueba deben capturarse en relación con estos elementos de destino.

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 por parte 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.



Más información