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.
¿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.
¿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.
|
|