Tarea: Definir el enfoque de prueba
En esta tarea se describe cómo definir la estrategia de prueba y las técnicas específicas que se utilizarán, y se esboza la arquitectura de automatización de pruebas.
Objetivo

El objetivo de esta tarea es:

  • Identificar cada técnica específica que se utilizará para habilitar la prueba deseada
  • Describir los trabajos de cada técnica, incluidos los tipos de prueba que admite
  • Definir una arquitectura candidata para el sistema de automatización de pruebas
Relaciones
Pasos
Examinar los motivadores de prueba y los elementos de prueba
Objetivo:  Tener en cuenta la influencia de la misión, los motivadores de prueba y los elementos de prueba en el enfoque del siguiente esfuerzo de prueba. 

Utilizando la misión de evaluación como contexto, examine el plan de prueba de la iteración y estudie los motivadores de prueba que se han identificado para el siguiente esfuerzo de prueba. Puede que sea necesario realizar una investigación adicional en el origen del motivador; normalmente, el plan de iteración proporciona un medio de localizar información adicional.

Para cada motivador, considere qué enfoque de prueba y qué técnicas asociadas se necesitarán para tratar cada motivador. Asimismo, examine el plan de prueba de la iteración y estudie los elementos de prueba. Se debe tener en cuenta cada elemento de prueba de destino en relación con cada motivador, y se deben ampliar el enfoque y las técnicas según corresponda. Si no puede encontrar suficiente información o no está familiarizado con los elementos de prueba, será útil analizar los elementos de destino con el personal de desarrollo, normalmente empezando por el arquitecto de software o los líderes del equipo de desarrollo.

Céntrese en identificar el conjunto mínimo de técnicas necesario para tratar satisfactoriamente los motivadores y la misión de evaluación. Busque oportunidades donde se pueda utilizar una técnica para tratar más de un aspecto de la prueba necesaria. Tenga en cuenta otras técnicas potenciales que parezcan interesantes de explorar, pero identifíquelas como adicionales más que como esenciales.

Examine la arquitectura de software
Objetivo:  Considerar la influencia de la arquitectura de software en el enfoque de prueba. 

Estudie la arquitectura de software para entender los mecanismos de sus elementos clave, las vistas principales, etc. Normalmente, el documento de arquitectura de software proporciona suficiente información específica, con el nivel adecuado de detalle, para que se utilice al considerar un enfoque de prueba. Para aclarar esta información, o en la ausencia de un documento, se puede analizar la arquitectura con el personal de desarrollo, normalmente hablando directamente con el arquitecto de software o con alguno de los líderes del equipo de desarrollo.

Céntrese en identificar y analizar los mecanismos clave, para conocer bien estos aspectos del sistema. Normalmente, cada mecanismo y característica clave de la arquitectura supondrá retos o restricciones para el esfuerzo de prueba. Por ejemplo, una arquitectura distribuida puede necesitar organizar el equipo de prueba en subequipos, cada uno destinado a un nivel de arquitectura.

Aunque a menudo se puede utilizar un enfoque creativo en la estrategia de ejecución y de la implementación de la prueba para superar estos retos, puede que el equipo de desarrollo tenga que modificar el software para habilitar las pruebas, tal como se describe en  Tarea: Definir elementos de comprobabilidad.

Considerar la extensión y la profundidad adecuadas del enfoque de prueba
Objetivo:  Considerar la completitud del enfoque de prueba, en términos de extensión y profundidad. 

Tener en cuenta todos los detalles conocidos sobre los requisitos en el enfoque de prueba permite volver atrás y considerar el enfoque de prueba con una perspectiva de nivel superior. ¿Qué elementos no tiene en cuenta el enfoque de prueba y debería tenerlos? ¿Existen problemas que se deberían analizar que no aparecen en ninguna parte de la información documentada?

A partir de su experiencia, revise los requisitos del enfoque de prueba para ver la cobertura adecuada para esta fase del ciclo vital del proyecto. Tenga en cuenta requisitos adicionales que le ayudarán a presentar un enfoque más completo.

Identificar las técnicas de prueba existentes para su reutilización
Objetivo:  Reutilizar o adaptar técnicas de prueba existentes de capacidad probada allí donde corresponda. 

A partir de su propia experiencia, o de otras experiencias a las que tenga acceso, identifique las técnicas existentes que cumplan los requisitos del enfoque de prueba, o que se puedan adaptar para cumplirlos.

Identificar técnicas adicionales
Objetivo:  Identificar las técnicas necesarias para proporcionar un enfoque de prueba completo y suficiente. 

No es demasiado útil pensar en términos de un enfoque de prueba "completo"; siempre dispone técnicas adicionales que se pueden probar si tuviera tiempo y recursos ilimitados.

No obstante, es importante que el enfoque de prueba sea exhaustivo e integrado para que se pueda realizar una evaluación útil de la calidad percibida. Para ello, se necesita un enfoque que evalúe suficientes aspectos de los riesgos de calidad o las dimensiones de calidad para que el equipo del proyecto pueda valorar la calidad percibida con un grado de confianza suficiente.

Definir técnicas
Objetivo:  Describir el trabajo de cada técnica, incluidos el objetivo de la prueba que soporta. 

Describa el trabajo de cada técnica. Analice el tipo de pruebas que soporta, el objetivo y el ámbito, el método de implementación, los oráculos de prueba, el método de valoración y las necesidades de automatización de la técnica.

En muchos casos, deberá reutilizar técnicas de un proyecto al siguiente. En este caso, sólo tiene que hacer referencia a una definición común de la técnica o copiar la definición existente y revisarla si es necesario.

Para cada técnica existente o necesaria:

Definir los objetivos y el ámbito Ir a la parte superior de la página

Muchas técnicas darán soporte a más de un tipo de prueba, por lo que debe identificar atentamente qué pruebas deberá soportar la técnica. Esto permite identificar el ámbito del esfuerzo necesario si se está definiendo la técnica por primera vez.

Considere el objetivo y el valor subyacente que representa esta técnica.

Describir el método de implementación Ir a la parte superior de la página

Defina cómo se implementará la técnica. No es suficiente indicar "Estamos realizando las pruebas de rendimiento del sistema"; debe analizar atentamente cómo se logrará ese objetivo.

Algunas de las técnicas que desee utilizar resultarán antieconómicas. Si describe brevemente cómo tiene previsto implementar esta técnica, podrá tener una idea general de la logística implicada y la factibilidad de continuar aplicando esa técnica.

Identificar el método de evaluación adecuado Ir a la parte superior de la página

Determine cómo desea observar y evaluar los resultados de cada prueba implementada utilizando esta técnica. Considere atentamente los distintos Oráculos de prueba que hay disponibles; ¿existe un único oráculo o hay varias formas de determinar el resultado de cada prueba?

Identificar el uso aplicable de la automatización Ir a la parte superior de la página

La automatización puede desempeñar un papel importante en muchas técnicas de prueba. En otros casos será menos sofisticada y simplemente proporcionará soporte a las pruebas manuales.

Considere atentamente cómo se puede implementar, mantener y gestionar de manera más eficaz el trabajo que implica la técnica. Debe estar dispuesto a aceptar nuevas ideas y considere el máximo de opciones posible.

Identificar las herramientas aplicables Ir a la parte superior de la página

Identifique las herramientas adecuadas que debe utilizar con esta técnica de prueba. Utilice el trabajo del paso anterior donde se identificaban usos de la automatización.

Recuerde considerar una amplia gama de categorías de herramientas; la lista de herramientas candidatas no debe incluir sólo herramientas de automatización de ejecución de pruebas. Además de las herramientas que automatizan la ejecución de las pruebas, tenga en cuenta herramientas que aumenten la productividad del equipo de prueba y reduzcan las tareas repetitivas y laboriosas como, por ejemplo, la gestión de datos de prueba, el análisis de resultados de prueba, las herramientas de informe de incidentes y solicitudes de prueba, etc.

Esbozar la arquitectura de automatización de pruebas
Objetivo:  Definir una arquitectura candidata para el sistema de automatización de pruebas. 

Basándose en la experiencia obtenida de sistemas similares o dominios de problemas parecidos, empiece a definir una arquitectura candidata para el sistema de automatización de prueba.

Se recomienda revisar la información relacionada con el desarrollo de la arquitectura de software para ayudarle con esta tarea.

Definir la estrategia de gestión de configuración de activos de prueba
Objetivo:  Considerar los requisitos de gestión de configuración que tendrá la prueba. 

Como muchos otros productos de trabajo producidos durante el proyecto de desarrollo de software, los activos de prueba son candidatos para la gestión de configuración y el control de versiones.

Los requisitos específicos pueden variar en complejidad desde la decisión de utilizar la copia de seguridad básica y habilitar los servicios de recuperación, hasta tener un soporte completo para el desarrollo paralelo de scripts de prueba automatizados en varios sitios con versiones diferentes de una aplicación.

Considere los requisitos de gestión de configuración y empiece a esquematizar las necesidades de logística para realizar esos requisitos.

Inspeccionar la disponibilidad de los activos reutilizables
Objetivo:  Reducir los riesgos y el esfuerzo mediante la reutilización de activos probados existentes. 

Algunas veces tiene sentido crear activos desde cero y otras no. Intente encontrar un equilibrio entre una filosofía completamente "hágalo usted mismo" y una política de bibliotecario rígida y burocrática en la creación de nuevos productos de trabajo.

Existen casos en los que un enfoque es mejor que el otro, y debe tener la flexibilidad suficiente para aprovechar las ventajas que proporcionan ambos enfoques.

Capturar los descubrimientos
Objetivo:  Registrar la información importante sobre el enfoque de la prueba. 

Dependiendo de varios factores, entre los que se encuentran el tamaño del equipo y la cultura de la organización, habrá mejores y peores formas de registrar las decisiones que ha tomado sobre el enfoque de la prueba.

Normalmente, deberá tener en cuenta dos públicos: el equipo de gestión deseará revisar esta información para dar su aprobación y conocer las implicaciones de logística del enfoque, y el equipo de prueba deseará utilizar el enfoque de prueba como guía en el trabajo que llevan a cabo. Intente encontrar un medio adecuado para responder a ambas necesidades, por ejemplo, la utilización de un sitio web de Intranet del proyecto.

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