Examinar la arquitectura de software y sus entornos de destino
Objetivo:
|
Conocer mejor la arquitectura de software y su relación con los entornos de despliegue de destino.
|
Para realizar esta tarea en el contexto apropiado, es importante conocer a fondo el software que se está desarrollando,
su arquitectura y los principales mecanismos y características a los que dará soporte. Examine la documentación
disponible sobre la arquitectura de software para obtener una idea inicial y compleméntela con entrevistas o charlas
con el arquitecto de software según sea necesario. Considere el impacto que cada entorno de despliegue de destino puede
tener sobre esta información y anote cualquier hallazgo importante que piense que puede ser relevante para el esfuerzo
de prueba.
|
Identificar los mecanismos candidatos de la prueba
Objetivo:
|
Identificar los mecanismos de prueba potenciales que requerirá el enfoque de prueba.
|
Utilizando los conocimientos que tiene sobre la arquitectura de software y sus entornos de destino, examine la
información proporcionada en el enfoque de prueba. Considere los aspectos técnicos más importantes del enfoque y
confeccione una lista de mecanismos candidatos que se necesitarán para dar soporte al mismo. A continuación se indica
una lista parcial de mecanismos habituales que debe considerar como candidatos; permanencia, concurrencia,
distribución, comunicación, seguridad, gestión de transacciones, recuperación, manejo e informe de la detección de
errores, y sincronización y control de procesos.
Tenga en cuenta que estos mecanismos a menudo se aplican tanto a los esfuerzos de prueba manuales como a los
automatizados, aunque un mecanismo específico pueda tener más o menos relevancia para la prueba manual o automatizada.
Tenga en cuenta también que incluso cuando el mismo mecanismo es necesario tanto para los esfuerzos de prueba manuales
como para los automatizados, las características de la solución implementada normalmente serán distintas.
|
Inventariar los mecanismos de prueba existentes
Objetivo:
|
Identificar oportunidades para reutilizar las implementaciones existentes para los mecanismos candidatos e
identificar qué implementaciones adiciones deberán desarrollarse.
|
Examine las herramientas de prueba disponibles y las implementaciones de prueba existentes y cree un inventario de
mecanismos que tienen una o más soluciones existentes. Aunque este paso es evidentemente más relevante para esfuerzo de
prueba automatizado, existen algunas consideraciones equivalentes para el esfuerzo de prueba manual.
Subtemas:
Empiece compilando una lista de las herramientas que están a su disposición o que tiene la intención de adquirir.
Recuerde que las herramientas de automatización tienen muchas formas y la lista normalmente incluirá más herramientas
que las de implementación y ejecución de prueba automatizadas. Para cada herramienta, examine los mecanismos que
proporciona la herramienta. Por ejemplo, ¿la herramienta de creación de scripts que va a utilizar proporciona un propio
mecanismo de permanencia de datos y, en caso afirmativo, es adecuada para sus necesidades o necesitará complementarla?
Otras preguntas podrían ser: ¿La herramienta de ejecución permite la ejecución concurrente de scripts de prueba en
varias máquinas cliente de host? ¿La herramienta de ejecución permite la distribución de scripts desde un sistema
maestro central a varias máquinas cliente de host?
En los casos en que las implementaciones de automatización de prueba existentes estén disponibles, habrá mecanismos
adicionales para inventariar. Algunos aspectos de estas implementaciones ampliarán o complementarán los mecanismos
básicos que proporcionan las herramientas para hacerlas más útiles. Otros aspectos ofrecerán implementaciones para
mecanismos adicionales no proporcionados en la herramienta base.
A un nivel básico, esto implicará revisar las directrices de prueba que existen para la implementación y ejecución de
la prueba. Debe buscar soluciones de proceso existentes para problemas tales como la concurrencia: cómo pueden
compartir los verificadores conjuntos de datos, especialmente los conjuntos de datos existentes sin que se afecten
negativamente entre sí; o la distribución: si el equipo de prueba está distribuido, qué soluciones están disponibles
para coordinar los distintos esfuerzos de prueba.
|
Definir los mecanismos de prueba que utilizará
Objetivo:
|
Comunicar las decisiones tomadas acerca de los mecanismos de prueba necesarios.
|
Ahora que ha decidido los mecanismos de prueba necesarios, debe comunicar su elección al equipo de prueba y a otros
interesados en el esfuerzo de prueba. Se recomienda documentar las decisiones sobre los mecanismos de prueba necesarios
para la automatización como parte de la documentación de la arquitectura de automatización de pruebas, y las que están
relacionadas con las pruebas manuales como parte de las directrices de prueba.
Como alternativa a la documentación formal, puede elegir registrar esta información simplemente como un conjunto de
notas informales de arquitectura y proceso acompañadas de algunos diagramas explicativos, posiblemente dibujados en una
pizarra. Durante la implementación y ejecución de la prueba, verificadores individuales utilizarán esta información
para tomar decisiones tácticas.
Cuando haya identificado el requisito potencial para las interfaces de prueba especiales que deben incorporarse en el
software que se está desarrollando, debe considerar la posibilidad de registrar este requisito creando una o varias
especificaciones de interfaz de prueba esquematizadas; el esquema debe incluir un nombre, una descripción breve y
enumerar los requisitos o características principales de la interfaz de prueba. No emplee mucho tiempo en estos
esquemas; la lista de requisitos y características se detallará posteriormente en la Tarea:
Definir los elementos de comprobabilidad.
|
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.
|
|