Examinar los conjuntos de aplicaciones de prueba candidatos
Objetivo:
|
Entender los conjuntos de aplicaciones de prueba y seleccionar qué candidatos se implementarán
|
Empiece por revisar las esquematizaciones de conjuntos de aplicaciones de prueba existentes y determine qué conjuntos
de aplicaciones de prueba son buenos candidatos para la implementación actualmente. Utilice el plan de prueba de
iteración, la lista de ideas de prueba y los productos de trabajo adicionales de definición de pruebas como base en la
toma de decisiones.
|
Examinar las pruebas relacionadas y los elementos de prueba de destino
Objetivo:
|
Entender las relaciones entre las pruebas planificadas y los elementos de prueba de destino
|
Para cada conjunto de aplicaciones de prueba seleccionado para su implementación, identifique los elementos de prueba
de destino y las pruebas asociadas que son candidatos para incluirse en el ámbito del conjunto de aplicaciones de
prueba.
|
Identificar las dependencias de las pruebas
Objetivo:
|
Identificar las dependencias que tienen las pruebas en términos de otras pruebas y, en general, en relación
con el estado del sistema
|
Empiece por considerar la configuración del entorno de prueba y el estado específico de inicio del sistema. Considere
cuáles serán los requisitos de configuración específicos como, por ejemplo, el conjunto de datos de inicio para las
bases de datos dependientes. Si se va a utilizar una configuración de entorno de destino para varios conjuntos de
aplicaciones de prueba, identifique los valores de configuración que se deberán gestionar para cada conjunto de
aplicaciones de prueba como, por ejemplo, la resolución de las pantallas de vídeo o los valores regionales del sistema
operativo.
A continuación, determine las relaciones específicas entre las pruebas. Busque dependencias donde la ejecución de una
prueba incluida en el conjunto de aplicaciones de prueba provoque un cambio de estado del sistema necesario como
condición previa de otra prueba.
Una vez identificadas las dependencias relevantes, determine la secuencia correcta de ejecución de las pruebas
dependientes.
|
Identificar oportunidades de reutilización
Objetivo:
|
Mejorar la capacidad de mantenimiento del conjunto de aplicaciones de prueba, mediante la reutilización de
los activos existentes y la consolidación de nuevos activos
|
Uno de los principales retos en el mantenimiento de un conjunto de aplicaciones de prueba (especialmente de uno
automatizado) es garantizar que los cambios en curso sean fáciles de realizar. Siempre que sea posible y útil, se
recomienda mantener un punto central de modificación de elementos que se utilizan en varias partes. Esto es
especialmente útil si esos mismos elementos pueden cambiar.
Aunque las propias pruebas forman unidades naturales de modularidad, el ensamblaje de las pruebas en un conjunto de
aplicaciones de prueba identifica a menudo elementos de procedimiento duplicados en varias pruebas que se pueden
mantener mejor si se consolidan. Identifique si es posible los mecanismos generales de las pruebas que se puedan
refactorizar en una rutina estándar para ayudar al mantenimiento en curso.
|
Aplicar los programas de utilidad de infraestructura necesarios
Objetivo:
|
Descomponer en factores los detalles de implementación complejos necesarios para dar soporte a las pruebas
como funciones de programas de utilidad simplificadas
|
La mayoría de esfuerzos de prueba requieren el uso de uno o más "programas de utilidad" que generan, recopilan,
diagnostican, convierten y comparan la información utilizada durante la ejecución de la prueba. Estos programas de
utilidad permiten simplificar las tareas complejas y laboriosas que normalmente darían errores si se ejecutaran de
forma manual. Este paso está relacionado con la aplicación de funciones de programas de utilidad existentes dentro del
conjunto de aplicaciones de prueba y con la identificación de los nuevos programas de utilidad necesarios.
Se recomienda simplificar las interfaces a estos programas de utilidad y encapsular la máxima complejidad posible
dentro de la implementación privada del programa de utilidad. También es una buena idea desarrollar el programa de
utilidad de forma que se pueda reutilizar cuando sea necesario para los esfuerzos de prueba manuales y automáticos.
Se recomienda no ocultar la información que caracteriza a una prueba individual dentro de estos programas de utilidad;
en su lugar, limite el programa de utilidad a la mecánica compleja de recopilar información o de comparar los valores
reales con los resultados esperados, etc.; no obstante, siempre que sea posible, pase las características específicas
de cada prueba individual como entrada de (y devuelva los resultados reales individuales como salida a) una prueba o un
conjunto de aplicaciones de prueba de control.
|
Determinar los requisitos de recuperación
Objetivo:
|
Habilitar los conjuntos de aplicaciones de prueba para que se puedan recuperar sin necesidad de volver a
ejecutar completamente el conjunto de aplicaciones de prueba
|
Determine los puntos adecuados dentro del conjunto de aplicaciones de prueba para proporcionar la recuperación si el
conjunto de aplicaciones de prueba falla durante la ejecución. Este paso gana en importancia cuando el conjunto de
aplicaciones de prueba está previsto que contenga un gran número de pruebas o que se ejecute un periodo prolongado de
tiempo, a menudo desatendido. Aunque casi siempre se identifican como un requisito para los conjuntos de aplicaciones
de prueba automatizados, también es importante considerar los puntos de recuperación en los conjuntos de aplicaciones
de prueba ejecutados manualmente.
Además de los puntos de recuperación o reinicio, puede considerar (en el caso de los conjuntos de aplicaciones de
prueba automatizados) la recuperación automatizada de conjuntos de aplicaciones de prueba. Los dos enfoques de la
recuperación automática son: 1) la recuperación básica, donde el conjunto de aplicaciones de prueba existente puede
recuperarse de un error menor ocurrido en una de sus pruebas, normalmente recuperando la ejecución en la siguiente
prueba del conjunto de aplicaciones de prueba; 2) la recuperación sofisticada, que realiza una limpieza después de la
prueba anómala y restablece el estado del sistema correspondiente, incluido el reinicio del sistema operativo y la
restauración de los datos si es necesario. Como en el primer enfoque, el conjunto de aplicaciones de prueba determina
la prueba que ha fallado y selecciona la siguiente prueba que debe ejecutarse.
|
Implementar los requisitos de recuperación
Objetivo:
|
Implementar y verificar que el proceso de recuperación funciona según lo esperado
|
Dependiendo del nivel de sofisticación necesario, requerirá un esfuerzo adicional para implementar y estabilizar el
proceso de recuperación. Deberá dedicar algún tiempo a simular una serie de anomalías probables (y algunas menos
probables) para probar que el proceso de recuperación funciona.
En el caso de la recuperación automatizada, los dos enfoques descritos en el paso anterior tienen puntos débiles y
fuertes. Considere atentamente el coste de la sofisticada recuperación automatizada, en términos de desarrollo inicial
y de esfuerzo de mantenimiento constante. A veces, la recuperación manual es suficiente.
|
Estabilizar conjunto de aplicaciones de prueba
Objetivo:
|
Resolver los problemas de dependencia en términos de estado del sistema y secuencias de ejecución de
prueba
|
Dedique tiempo a estabilizar el conjunto de aplicaciones de prueba mediante una o varias ejecuciones de prueba
experimentales, siempre que sea posible. La dificultad de alcanzar la estabilidad aumenta proporcionalmente con la
complejidad del conjunto de aplicaciones de prueba, y allí donde existe un acoplamiento excesivo entre pruebas no
relacionadas y una cohesión débil ente pruebas relacionadas.
Existe la posibilidad de que se produzcan errores cuando se ejecutan pruebas conjuntamente dentro de un determinado
conjunto de aplicaciones de prueba que no se producen cuando las pruebas individuales se ejecutan independientemente.
Estos errores son a menudo los más difíciles de rastrear y diagnosticar, especialmente cuando se encuentran a medio
camino en una ejecución de prueba automatizada de larga duración. Se recomienda, siempre que resulte práctico, volver a
ejecutar el conjunto de aplicaciones de prueba regularmente a medida que se añadan pruebas adicionales. Esto permitirá
aislar un número menor de posibles pruebas candidatas que se diagnosticarán para identificar el problema.
|
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. Los conjuntos de aplicaciones de prueba se pueden rastrear hasta guiones de prueba definidos o
hasta ideas de prueba. De manera opcional, se pueden rastrear hasta casos de uso , elementos de la especificación de
software, elementos del modelo de implementación y hasta una o varias medidas de cobertura de la prueba.
|
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.
|
|