Para cada elemento del destino de la prueba necesario, identifique relaciones con los mecanismos de prueba
Objetivo:
|
Conseguir que los elementos del destino de la prueba conozcan mejor el soporte de los mecanismos de prueba
necesarios.
|
Para cada elemento de prueba, revisar la lista de mecanismos de prueba e identificar los que pueden proporcionar
soporte. Analizar la distancia a la que se encuentran los mecanismos de prueba seleccionados para proporciona una
solución de prueba completa y cómo pueden adaptarse mejor. Si no se encuentra ningún candidato o el esfuerzo de
adaptación es significativo, defina nuevos mecanismos de prueba e intente buscar un equilibrio entre especificidad y
reutilización.
|
Identificar elementos dinámicos y sucesos del sistema
Objetivo:
|
Conocer mejor los aspectos del tiempo de ejecución y la dinámica del sistema.
|
Utilice la información de diseño y los requisitos de software disponibles para identificar los sucesos y los elementos
dinámicos del sistema. Mediante los modelos de despliegue, implementación, diseño y caso de uso, puede identificar
elementos relevantes como clases de control, procesos, hebras y sucesos. Algunos lugares para iniciar la investigación
son las clases estereotipadas como <<control>>, las ejecuciones de casos de uso y los elementos que se
describen en la vista de la arquitectura del proceso o el modelo de implementación estereotipado como
<<proceso>> o <<hebra>>.
En cuanto las restricciones impuestas por el entorno de prueba, defina los requisitos físicos
|
Identificar los límites del sistema y las interfaces
Objetivo:
|
Conocer las responsabilidades del sistema como proveedor de servicios y las dependencias del sistema como
cliente.
|
Otro grupo de elementos que resulta útil examinar son las Interfaces del sistema, especialmente las que se relacionan
con actores externos a los límites del sistema. Utilice los modelos de implementación y diseño para buscar elementos
definidos con el estereotipo <<interfaz>>. Busque también clases estereotipadas como
<<límite>>.
Como verificador, resulta útil explorar más allá de los límites del sistema para conocer las expectativas de los
sistemas relacionados, tanto los proveedores de servicios como el cliente. De esta manera, tendrá un conocimiento más
profundo de las necesidades para la validación de interfaces y para la infraestructura de la prueba necesaria para
probar y, posiblemente, simular estas interfaces.
|
Identificar elementos de infraestructura de la prueba
Objetivo:
|
Identificar los elementos esenciales del esfuerzo de prueba que permitirá la ejecución de la prueba
necesaria.
|
Para que un esfuerzo de prueba iterativo sea satisfactorio, es importante identificar y mantener una infraestructura
adecuada. Si no dispone de una infraestructura que lo sostenga, el esfuerzo de prueba puede convertirse en insostenible
e inutilizable rápidamente. La infraestructura de la prueba, aunque es más importante para el esfuerzo de prueba
automatizado, también es importante para el esfuerzo de prueba manual.
Reflexiones sobre los sucesos y los elementos dinámicos del sistema, ¿qué dependencias crearán en la implementación de
pruebas individuales? Busque oportunidades para desparejar las dependencias entre pruebas individuales y gestionarlas
mediante puntos de control comunes que proporcionen una capa de direccionamiento indirecto. Las áreas comunes que debe
explorar para las dependencias son la navegación de pruebas, la utilización de datos de prueba y los cambios de estado
del sistema.
Utilice la información que ha reunido y reflexione sobre los requisitos que regirán la infraestructura de la prueba y
los recursos que necesitará para ofrecer un enfoque de prueba satisfactorio.
Subtemas:
Algunas pruebas tienen una estructura común con el caso de ejemplo o el procedimiento que se siguió en su ejecución,
pero es necesario realizar el mismo procedimiento muchas veces en elementos de destino de la prueba diferentes. En el
caso de la automatización de pruebas, puede resultar útil crear funciones de programa de utilidad o scripts de prueba
comunes que se puedan volver a utilizar en muchos contextos diferentes para llevar a cabo los casos de ejemplo de
prueba comunes de manera eficaz. Esto proporciona un punto central de modificación si es necesario modificar el caso de
ejemplo de prueba. Por ejemplo, ejecutar pruebas de límite estándar en clases adecuadas de elementos de interfaz y
comprobar si los elementos de UI cumplen los estándares de diseño de UI.
Cuando se ejecutan las pruebas en una configuración del entorno de prueba dada, existe la posibilidad de que se
produzcan conflictos en los valores de los datos de la prueba que se utilicen. Este problema se agrava cuando el
entorno lo comparten varios miembros del equipo de prueba. Considere la posibilidad utilizar un enfoque controlado por
datos que separe los valores de los datos de la prueba de los scripts de prueba que los utilizan y proporcione un punto
central de recopilación y modificación de datos de la prueba. Esto supone dos ventajas clave: posibilita que todos los
miembros del equipo de prueba puedan ver los datos de la prueba, lo que les permite evitar conflictos potenciales en la
utilización de datos de la prueba y proporciona un punto central de modificación para los datos de la prueba cuando
deban actualizarse.
La mayoría de las pruebas requieren que el sistema esté en un estado específico antes de ejecutarse, y devuelven al
sistema a un estado conocido específico cuando finalizan. Las dependencias comunes incluyen derechos de seguridad
(función o datos), datos sensibles al contenido o dinámicos (por ejemplo: datos del sistema, números de pedido,
preferencias de ID de usuario, etc.), ciclo de caducidad de datos (por ejemplo, contraseñas de seguridad, caducidad del
producto, etc.). Algunas pruebas son muy dependientes entre sí; por ejemplo, una prueba puede crear un número de pedido
exclusivo y es posible que una prueba posterior tenga que enviar el mismo número de pedido.
Una solución común es utilizar los conjuntos de aplicaciones de prueba para ordenar las pruebas dependientes en el
orden de estados del sistema correcto. Los conjuntos de aplicaciones de prueba pueden unirse con programas de utilidad
de configuración y recuperación del sistema adecuados. En el caso de los esfuerzos de prueba automatizada, algunas
soluciones implican el uso de almacenamiento centralizado de datos dinámicos del sistema y la utilización de variables
en los scripts de prueba que hacen referencia a la información centralizada.
A veces, las pruebas tienen que calcular o derivar valores de datos adecuados de uno o más aspectos del estado del
sistema de tiempo de ejecución. Esto se aplica a valores de datos de la prueba para los resultados esperados y la
entrada. Tenga en cuenta la posibilidad de desarrollar programas de utilidad que calculen los valores de los datos
derivados y, de esta manera, simplificar la ejecución de la prueba y la eliminación de las imprecisiones potenciales
debidas a errores humanos. Cuando sea posible, desarrolle estos programas de utilidad de manera que se puedan utilizar
para los esfuerzos de prueba automatizada y manual.
Para la automatización de pruebas, debería aislar secuencias de navegación comunes e implementarlas con funciones de
programa de utilidad centralizadas o scripts de prueba. Estas secuencias de navegación comunes se pueden volver a
utilizar en muchos sitios, y proporcionan un punto central de modificación en el caso de que la navegación cambie.
Estas ayudas comunes para la navegación se limitan a desplazarse por la aplicación de un punto a otro; normalmente, no
realizan pruebas, excepto verificar los estados de inicio y fin.
|
Identificar necesidades de diseño específicas de la prueba
Objetivo:
|
Identificar la necesidades de la disciplina de prueba que supondrán restricciones potenciales en el proceso
de ingeniería de software, la arquitectura de software y el diseño y la implementación
correspondientes.
|
Sobre todo en lo que se refiere a la automatización de pruebas, es probable que las necesidades de evaluación e
implementación de pruebas limiten la manera de activar el proceso de software del equipo de desarrollo y la
arquitectura y el diseño del software. Es importante que el equipo de desarrollo de software no se vea entorpecido
indebidamente en el trabajo de desarrollo central y tenga la capacidad para efectuar las pruebas necesarias. Consulte
el apartado Tarea: Obtener confirmación de comprobabilidad para obtener
información sobre la presentación de las necesidades del equipo de prueba al equipo de desarrollo y la búsqueda de
soluciones ejecutables que satisfagan las necesidades de todas las disciplinas.
Con la información que ha reunido, reflexione sobre qué requisitos colocará el esfuerzo de prueba para la tarea de
desarrollo.
Subtemas:
Considere las interfaces identificadas, ¿hay requisitos adicionales que el esfuerzo de prueba necesite incluir en el
diseño de software y, posteriormente, exponer en la implementación? En algunos casos, son necesarias interfaces
adicionales específicamente para dar soporte al esfuerzo de prueba, o interfaces existentes requieren modalidades
operativas o firmas modificadas del mensaje (cambios en los parámetros de entrada y de retorno).
En cuando a los entornos de despliegue de destino (tal como se capturan en las configuraciones del entorno de prueba) y
la propia planificación de desarrollo, identifique las restricciones y las dependencias del esfuerzo de prueba. Estas
dependencias pueden necesitar la provisión de fragmentos para la simulación de elementos del entorno que no estarán
disponibles o que requieren demasiados recursos para realizar pruebas, o para proporcionar la oportunidad de realizar
pruebas de componentes desde el principio del sistema terminado parcialmente.
Algunas pruebas tienen un valor potencial, pero son demasiado caras para implementarse como pruebas de caja negra
reales. Además, en entornos muy fiables, es importante poder realizar pruebas y aislar los errores lo más rápido
posible para conseguir una resolución rápida. En estos casos, puede resultar útil crear pruebas directamente en el
software ejecutable.
Para conseguir esto se pueden adoptar diferentes enfoques; dos de los más comunes son las pruebas automáticas
incorporadas, en las que el software utiliza ciclos de proceso redundantes para efectuar las pruebas de integridad
automática, y las rutinas de diagnóstico, que se pueden llevar a cabo cuando se le envía al software un mensaje de
suceso de diagnóstico, o cuando el sistema está configurado para ejecutarse con las rutinas de diagnóstico habilitadas.
Algunas de las opciones de implementación y diseño del equipo de desarrollo habilitarán o inhibirán el esfuerzo de
prueba. Muchas de estas pruebas son necesarias, pero hay muchas decisiones más pequeñas (sobre todo en el área de
implementación) que tienen un impacto mínimo en el equipo de desarrollo y un gran impacto en el equipo de prueba.
Las áreas que debe tener en cuenta son: Utilización de protocolos de comunicación estándar reconocidos; Utilización de
componentes de implementación de UI que puedan reconocer las herramientas de automatización de pruebas; Adhesión a las
reglas de diseño de UI, incluida la denominación de elementos de UI; Utilización coherente de las convenciones de
navegación de UI.
|
Definir los requisitos de comprobabilidad de software
Objetivo:
|
Especificar los requisitos de las funciones de software necesarias para dar soporte a la implementación y
la ejecución de pruebas.
|
Utilice el trabajo realizado anteriormente en la tarea para definir las restricciones y los requisitos específicos de
la prueba que se deberían tener en cuenta en el diseño y la implementación de software.
Es importante explicar con claridad los motivos por los que es necesario integrar características específicas de la
prueba en el software al equipo de desarrollo. Los motivos principales suelen encontrarse en una de las áreas
siguientes:
-
Permitir que las pruebas se implementen (manual o automáticamente) mediante una interfaz entre el elemento del
destino de la prueba y la prueba manual o automatizada. Esto suele ser más importante como un aspecto de la
automatización de pruebas para superar los límites de las herramientas de automatización de pruebas a la hora de
acceder a la aplicación de software para la entrada y la salida de información.
-
Permitir que las pruebas automáticas incorporadas las lleve a cabo el software desarrollado.
-
Permitir que los elementos del destino de la prueba se puedan aislar del resto del sistema desarrollado y probado.
Las características específicas de la prueba se incorporan en el software para alcanzar un equilibrio entre el valor de
una característica incorporada de la prueba y el esfuerzo necesario para implementarla y probarla. Algunos ejemplos de
características incorporadas de la prueba son la producción de registros de auditoría, funciones de diagnóstico
automático e interfaces para preguntar el valor de las variables internas.
Otro uso común de la función específica de la prueba es durante el trabajo de integración, donde es necesario
proporcionar fragmentos para simulación para los componentes o subsistemas que todavía no se han implementado o
incorporado. Existen dos estilos de implementación principales para los fragmentos para simulación:
-
Los fragmentos para simulación y los controladores que son simples "elementos ficticios" cuya única función es
proporcionar un valor (o valores) predefinido específico como valor de retorno o como entrada.
-
Los fragmentos para simulación y los controladores que son más inteligentes y pueden "simular" o aproximarse a un
comportamiento más complejo.
Este segundo estilo de fragmento para simulación también proporciona un potente medio para aislar componentes o grupos
de componentes del resto del sistema y, de esta manera, proporcionar flexibilidad a la implementación y la ejecución de
pruebas. Al igual que en el caso de las características específicas de la prueba, es aconsejable alcanzar un equilibrio
entre el valor de un fragmento para simulación complejo y el esfuerzo necesario para implementar y probar el fragmento
para simulación. El segundo estilo debe utilizarse con prudencia por dos motivos: en primer lugar, necesita más
recursos para implementarse y, en segundo lugar, es más fácil pasar por alto la existencia del fragmento para
simulación y olvidarse de eliminarlo después.
Registre los resultados de los requisitos específicos de la prueba directamente en modelos de diseño e implementación,
o utilizando una o más especificaciones de la interfaz de prueba.
|
Definir la infraestructura de prueba
Objetivo:
|
Especificar los requisitos de la infraestructura de la prueba necesaria para dar soporte a la
implementación y la ejecución de pruebas.
|
Utilice el trabajo realizado anteriormente en la tarea para definir la infraestructura de la prueba necesaria para dar
soporte a la implementación y la ejecución de la prueba.
Recuerde que está definiendo las características de implementación de la infraestructura; el objetivo principal es
definir las diferentes partes de la solución que implementará la infraestructura.
Subtemas:
Los requisitos o características clave de la infraestructura de automatización de pruebas incluyen:
-
Modelo de navegación: los enfoques comunes son el directo e inverso, el segmentado o el híbrido. Otras alternativas
pueden ser la utilización de un marco de acción-palabra o tablas de navegación en pantalla.
-
Acceso externo a datos: método para acceder a los datos externamente desde las instrucciones de la prueba
-
Recuperación y notificación de errores: rutinas comunes de manejo de errores y derivadores de ejecución de la
recuperación del conjunto de aplicaciones de prueba
-
Perfiles de acceso y seguridad: ID de usuario de ejecución de pruebas automatizadas
-
Capacidad del software para realizar pruebas automáticas
Registre las decisiones como definiciones en las secciones de implementación de la Arquitectura de automatización de
pruebas, la orientación del proceso en una o más directrices de prueba o como scripts de prueba, conjuntos de
aplicaciones de prueba o rutinas del programa de utilidad de la biblioteca de pruebas. Consulte el apartado Producto de trabajo: Arquitectura de automatización de pruebas para
ver más sugerencias.
Los requisitos o características clave de la infraestructura de prueba manual incluyen:
-
Repositorio de datos de prueba: un repositorio común para la definición de datos de prueba.
-
Restauración y recuperación: un método para restaurar o recuperar la configuración del entorno de prueba para un
estado conocido.
-
Permitir que los elementos del destino de la prueba se puedan aislar del resto del sistema desarrollado y probado.
Registrar las decisiones como orientación del proceso en uno o más Producto de trabajo: Directrices específicas 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 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.
|
|