Seleccionar la técnica de implementación adecuada
Objetivo:
|
Determinar la técnica adecuada para implementar la prueba.
|
Seleccione la técnica más adecuada para implementar la prueba. Para cada prueba que desee llevar a cabo, considere la
posibilidad de implementar como mínimo un script de prueba. En algunos casos, la implementación de una determinada
prueba incluirá varios scripts de prueba. En otros, un único script de prueba proporcionará la implementación de varias
pruebas.
Los métodos habituales para implementar pruebas incluyen escribir una descripción textual en el formato de un script
que debe seguir (para la prueba manual) y la programación, registro capturado o generación de un lenguaje de
programación basado en scripts (para la prueba automatizada). En las secciones siguientes se describe cada método.
Al igual que con la mayoría de enfoques, se recomienda utilizar una combinación de las técnicas siguientes para obtener
los resultados más útiles. Aunque no es necesario utilizar todas las técnicas, tampoco debe limitarse a utilizar una
única técnica.
Subtemas:
Muchas pruebas se realizan mejor manualmente, por lo que debe evitar caer en la trampa de intentar automatizar pruebas
inapropiadamente. Las pruebas de utilización son un área en la que una prueba manual es en muchos casos una solución
mejor que una prueba automatizada. Además, las pruebas que requieren validar la precisión y la calidad de las salidas
físicas de un sistema de software normalmente requieren una validación manual. Como norma general, es una buena idea
empezar las primeras pruebas de un determinado elemento del destino de la prueba con una implementación manual; este
enfoque permite al verificador conocer el elemento de destino, adaptarse a un comportamiento inesperado del mismo y
aplicar lógica humana para determinar la siguiente acción adecuada que debe tomarse.
A veces, las pruebas realizadas manualmente más tarde se automatizan y se reutilizan como parte de una estrategia de
pruebas de regresión. Sin embargo, tenga en cuenta que no es necesario ni deseable, ni tan siquiera posible,
automatizar todas y cada una de las pruebas que por otro lado pueden llevarse a cabo manualmente. La automatización
aporta determinadas ventajas respecto a la velocidad y precisión de la ejecución de la prueba, a la visibilidad y
recopilación de resultados detallados de la prueba y a su eficacia a la hora de crear y mantener pruebas complejas,
pero al igual que todas las herramientas útiles, no es la solución para todas las necesidades.
La automatización tiene algunos inconvenientes: básicamente pueden resumirse en la ausencia de lógica y razonamiento
humano durante la ejecución de la prueba. Las soluciones de automatización disponibles actualmente simplemente no
tienen las capacidades cognitivas que tiene un ser humano y es improbable que alguna vez las tengan. Durante la
implementación de una prueba manual, se puede aplicar el razonamiento humano a las respuestas observadas del sistema
frente a los estímulos. Las actuales técnicas de prueba automatizadas y sus herramientas de soporte tienen una
capacidad limitada de percibir las implicaciones de determinados comportamientos del sistema y tienen una capacidad
mínima de inferir posibles problemas a través de un razonamiento deductivo.
Seguramente el método de elección que practican la mayoría de verificadores que utilizan la automatización de pruebas.
En su forma más pura, esta práctica se realiza de la misma manera y utilizando los mismos principios generales que la
programación de software. Como tales, la mayoría de métodos y herramientas que se utilizan para la programación de
software son generalmente aplicables y útiles en la programación de la automatización de pruebas.
Utilizando un entorno de desarrollo de software estándar (como por ejemplo Microsoft Visual Studio o IBM Visual Age) o
un entorno de desarrollo de automatización de pruebas especializado (como por ejemplo el IDE proporcionado con Rational
Robot), el verificador puede elegir utilizar las características y la potencia del entorno de desarrollo que
proporcionen los mejores resultados.
Los aspectos negativos de la programación de pruebas automatizadas están relacionados con los aspectos negativos de la
propia programación como técnica general. Para que la programación sea eficaz, se debe prestar atención al diseño
apropiado: sin éste, la implementación probablemente no será satisfactoria. Si el software desarrollado va a ser
modificado por diferentes personas a lo largo del tiempo, la situación más habitual, se deberá adoptar un estilo y
forma comunes para el desarrollo del programa y se deberá asegurar su uso correcto. Posiblemente los dos problemas más
importantes están relacionados con la mala utilización de esta técnica.
En primer lugar, existe el riesgo de que un verificador se vea absorbido por las características del entorno de
programación y dedique demasiado tiempo elaborando soluciones elegantes y sofisticadas para problemas que podrían
solucionarse con medios más sencillos. El resultado es que el verificador malgasta un tiempo valioso en lo que
básicamente son tareas de programación a costa del tiempo que podría dedicarse en probar y evaluar realmente los
elementos del destino de la prueba. Para no caer en esta trampa hace falta a la vez disciplina y experiencia.
En segundo lugar, existe el riesgo de que en el propio código de programa utilizado para implementar la prueba se
introduzcan errores debido a una omisión o un error humano. Algunos de estos errores podrán depurarse y corregirse
fácilmente en el transcurso normal de la implementación de la prueba automatizada; otros no. Del mismo modo que los
errores pueden ser difíciles de detectar en el elemento del destino de la prueba, también puede resultar difícil
detectar errores en el software de automatización de pruebas. Además, los errores pueden introducirse donde se basan
los algoritmos utilizados en la implementación de la prueba automatizada en los mismos algoritmos defectuosos que
utiliza la propia implementación de software. Esto hace que los errores no se detecten, ocultados por la falsa
seguridad de las pruebas automatizadas que aparentemente se ejecutan correctamente. Mitigue este riesgo utilizando
diferentes algoritmos en las pruebas automatizadas siempre que sea posible.
Existen diversas herramientas de automatización de pruebas que proporcionan la capacidad de registrar o capturar la
interacción humana con una aplicación de software y producir un script de prueba básico. Existen varias soluciones de
herramientas distintas para ello. La mayoría de herramientas producen un script de prueba implementado en alguna forma
de lenguaje de programación de nivel superior y normalmente editable. Los diseños más comunes funcionan de una de las
siguientes maneras:
-
Capturando la interacción con la UI de cliente
de una aplicación que se basa en interceptar las entradas enviadas desde los dispositivos de entrada periféricos
del hardware del cliente (ratón, teclado, etc.) al sistema operativo del cliente. En algunas soluciones, esto se
hace interceptando los mensajes de nivel superior intercambiados entre el sistema operativo y el controlador de
dispositivo que describen las interacciones de una forma más o menos significativa; en otras soluciones, se
capturan los mensajes de nivel inferior, a menudo basados en el nivel de los movimientos basados en el tiempo en
las coordenadas del ratón o los sucesos de presionar y soltar una tecla.
-
Interceptando los mensajes enviados y recibidos a través de red entre la aplicación cliente y una o varias
aplicaciones servidor. La interpretación correcta de estos mensajes normalmente depende de la utilización de
protocolos de mensajería reconocidos estándar, como por ejemplo HTTP, SQL y otros. Algunas herramientas también permiten capturar protocolos de
comunicaciones "básicos", como por ejemplo TCP/IPK sin
embargo puede ser más complicado trabajar con scripts de prueba de esta naturaleza.
A pesar de que estas técnicas normalmente son útiles cuando se incluyen como parte del enfoque para las pruebas
automatizadas, algunos profesionales creen que estas técnicas tienen limitaciones. Uno de los principales problemas es
que algunas herramientas simplemente capturan la interacción de la aplicación y no hacen nada más. Sin la inclusión
adicional de puntos de observación que capturen y comparen el estado del sistema durante la posterior ejecución del
script, el script de prueba básica no puede considerarse como una prueba completamente formada. Cuando éste sea el
caso, el registro inicial deberá aumentarse posteriormente con código de programa personalizado adicional para
implementar los puntos de observación dentro del script de prueba.
Varios autores han publicado libros y ensayos sobre éste y otros problemas relacionados con la utilización del registro
o captura del procedimiento de prueba como técnica de automatización de la prueba. Para obtener información más
detallada, recomendamos revisar el trabajo disponible en Internet de los siguientes autores: James Bach, Cem Kaner, Brian Marick y Bret Pettichord, y el contenido relevante de la publicación
Lessons Learned in Software Testing [KAN01]
Algunos de los programas de software de automatización de pruebas más sofisticados permiten la generación real de
varios aspectos de la prueba, ya sean aspectos de procedimiento o los aspectos de datos de prueba del script de prueba,
basados en algoritmos de generación. Este tipo de automatización puede ser de gran utilidad en el esfuerzo de prueba,
pero no debe considerarse un enfoque suficiente por sí solo. La herramienta Rational TestFactory y la característica de
generación de agrupaciones de datos Rational TestManager son implementaciones de ejemplo de este tipo de tecnología.
|
Configurar condiciones previas del entorno de prueba
Objetivo:
|
Preparar el entorno para el estado inicial correcto.
|
Configure el entorno de prueba, incluido todo el hardware, software, herramientas y datos. Asegúrese de que todos los
componentes funcionan correctamente. Normalmente, esto implicará alguna forma de restablecimiento del entorno básico
(por ej., restablecer el registro de
Windows y otros archivos de configuración), la restauración de las bases de datos subyacentes a un estado
conocido, además de tareas como cargar el papel en las impresoras. Aunque algunas tareas se pueden realizar
automáticamente, otros aspectos requieren la intervención humana.
Subtemas:
Especialmente aplicable a los scripts de prueba automatizados, puede ser beneficioso realizar manualmente un ensayo
inicial de la prueba para confirmar que los requisitos previos esperados están presentes. Durante el ensayo, debe
verificar la integridad del entorno, el software y el diseño de prueba. El ensayo es más relevante cuando se utiliza
una técnica de registro interactiva y menos relevante cuando se programa el script de prueba. El objetivo es verificar
que todos los elementos necesarios para implementar la prueba satisfactoriamente están presentes.
Cuando se sabe que el software es suficientemente estable o maduro, puede elegir saltarse este paso donde considere que
existe un riesgo relativamente bajo de que se produzcan problemas en las áreas tratadas por el ensayo manual.
Confirme que los oráculos de
prueba que tiene la intención de utilizar son apropiados. Si todavía no se han identificado, ahora es el
momento de hacerlo.
Debe intentar confirmar mediante métodos alternativos que el oráculo u oráculos de prueba elegidos proporcionarán
resultados exactos y fiables. Por ejemplo, si tiene la intención de validar los resultados de la prueba utilizando un
campo que se visualiza a través de la UI de la aplicación que indica que se realizado una actualización de la base de
datos, considere la posibilidad de consultar de manera independiente la base de datos de fondo para verificar el estado
de los registros correspondientes de la base de datos. Como alternativa, puede ignorar los resultados presentados en un
diálogo de confirmación de la actualización y, en su lugar, confirmar la actualización consultando el registro mediante
una función u operación frontal alternativa.
A continuación, debe restaurar el entorno, incluidas las herramientas de soporte, de nuevo a su estado original. Como
se ha indicado en pasos anteriores, esto normalmente implica alguna forma de restablecimiento del entorno operativo
básico, la restauración de las bases de datos subyacentes a un estado conocido, además de tareas como cargar el papel
en las impresoras. Aunque algunas tareas de restablecimiento se pueden realizar automáticamente, otros aspectos
requieren la intervención humana.
Establezca las opciones de implementación de las herramientas de soporte de la prueba, que variarán en función de la
sofisticación de la herramienta. Siempre que sea posible, debe considerar la posibilidad de almacenar los valores de
las opciones de cada herramienta de modo que se puedan volver a cargar fácilmente a partir de uno o varios perfiles
predeterminados. En el caso de las pruebas manuales, ello incluye tareas como, por ejemplo, crear una partición de una
nueva entrada en un sistema de soporte para registrar los resultados de la prueba o registrarse en un sistema de
registro de solicitudes de cambio o problemas.
En el caso de las herramientas de implementación de pruebas automatizadas, es posible que se deban tener en cuenta
muchos valores distintos. Si no se establecen correctamente estas opciones, puede disminuir la utilidad y el valor de
los activos de prueba resultantes.
|
Implementar la prueba
Objetivo:
|
Implementar uno o más activos de implementación de prueba reutilizables.
|
Utilizando la lista de ideas de prueba, o uno o más artefactos de caso de prueba seleccionados, empiece a implementar
la prueba. Empiece dando a la prueba un nombre identificable de manera exclusiva (si todavía no lo tiene) y prepare el
IDE, la herramienta de captura, la hoja de cálculo o documento para empezar a registrar los pasos específicos de la
prueba. Lleve a cabo las subsecciones siguientes tantas veces como sea necesario para implementar la prueba.
Tenga en cuenta que para algunas pruebas o tipos de pruebas en concreto, es posible que no sirva de mucho documentar
los pasos explícitos necesarios para realizar la prueba. En determinados estilos de pruebas
exploratoria , la repetición de la prueba no es entregable esperado. En pruebas muy simples, una breve
descripción del objetivo de las pruebas será suficiente en muchos casos para permitir su reproducción.
Subtemas:
Programe, registre o genere las acciones de navegación necesarias. Empiece seleccionando el método de navegación
apropiado de su elección. Para la mayoría de clases de sistema actuales, un "ratón" u otro dispositivo de puntero es el
medio de navegación principal y preferido. Por ejemplo, el dispositivo de puntero y escritura que se utiliza en las
agendas personales digitales (PDA) es conceptualmente equivalente un ratón.
El medio de navegación secundario es generalmente la interacción con el teclado. En la mayoría de casos, la navegación
consistirá en una combinación de acciones realizadas con el ratón y el teclado.
En algunos casos, deberá considerar el reconocimiento visual, por luz, activado por la voz u otras formas de
reconocimiento. Estos métodos pueden ser más problemáticos para automatizar las pruebas y pueden requerir la adición de
ampliaciones especiales de la interfaz de prueba a la aplicación para permitir cargar y procesar elementos de audio y
visuales a partir del archivo en lugar de capturarlos dinámicamente.
En algunas situaciones, es posible que desee, o necesite, realizar la misma prueba utilizando varios métodos de
navegación. Existen diferentes enfoques que puede elegir para lograrlo, como por ejemplo: automatizar todas las pruebas
utilizando un método y realizar todas o algún subconjunto de las pruebas utilizando otros métodos; separar los aspectos
de navegación de las pruebas de los datos de prueba que caracterizan la prueba específica, proporcionando y creando una
interfaz de navegación lógica que permita seleccionar cualquiera de los métodos para realizar la prueba; simplemente
mezclar y emparejar métodos de navegación.
En cada punto del script de prueba donde debe tomarse una observación, utilice el oráculo de prueba apropiado para
capturar la información deseada. En muchos casos, la información obtenida del punto de observación deberá registrarse y
conservarse para que se pueda hacer referencia a ella en posteriores puntos de control.
Si se trata de una prueba automatizada, decida cómo debe notificarse la información observada del script de prueba. En
la mayoría de casos, normalmente basta con simplemente registrar la observación en un registro de prueba central
relativo a su tiempo delta desde el principio del script de prueba; en otros casos, las observaciones específicas
pueden enviarse por separado a una hoja de cálculo o archivo de datos para usos más sofisticados.
En cada punto del script de prueba donde debe tomarse una decisión de control, obtenga y valore la información
apropiada para determinar la ramificación correcta que debe seguir el flujo de control. Los datos recuperados de puntos
de observación anteriores constituyen normalmente la entrada para los puntos de puntos.
Cuando se produce un punto de control y se toma una decisión acerca de la siguiente acción del flujo de control, se
recomienda registrar los valores de entrada en el punto de control y el flujo resultante que se selecciona en el
registro de prueba.
Durante la implementación de la prueba, es probable que introduzca errores en la propia implementación de prueba. Estos
errores pueden ser incluso el resultado de algo que haya omitido en la implementación de prueba o pueden estar
relacionados con algo que no haya tenido en cuenta en el entorno de prueba. Estos errores deben resolverse antes de que
la prueba pueda considerarse completamente implementada. Identifique cada error que encuentre y lleve a cabo los pasos
necesarios para solucionarlos.
En el caso de la automatización de pruebas en que se utiliza un lenguaje de programación, se pueden producir errores de
compilación debido a variables o funciones no declaradas o al uso no válido de dichas funciones. Revise y corrija los
mensajes de error que muestra el compilador u otros orígenes de mensajes de error hasta que el script de prueba esté
libre de errores sintácticos y otros errores de la implementación básica.
Tenga en cuenta que durante la ejecución subsiguiente de la prueba, pueden encontrarse otros errores en la
implementación de prueba. Inicialmente, estos errores pueden parecer anomalías en el elemento del destino de la prueba;
es necesario analizar las anomalías de prueba de forma diligente para confirmar que las anomalías están realmente en el
elemento del destino de la prueba y no en algún aspecto de la implementación de prueba.
|
Establecer conjuntos de datos externos
Objetivo:
|
Crear y mantener datos, almacenados externamente al script de la prueba, que utiliza la prueba durante la
ejecución.
|
En muchos casos, es más apropiado mantener los datos de prueba externos al script de prueba. Esto proporciona
flexibilidad, simplicidad y seguridad en el mantenimiento del script de prueba y de los datos de prueba. Los conjuntos
de datos externos proporcionan valor a la prueba de las siguientes maneras:
-
Los datos de prueba son externos al script de prueba, eliminando las referencias codificadas en el script de
prueba.
-
Los datos de prueba externos pueden modificarse fácilmente, normalmente con un impacto mínimo sobre el script de
prueba
-
Los datos de prueba pueden dar soporte fácilmente a casos de prueba adicionales con pocas modificaciones, o
ninguna, en el script de prueba.
-
Los datos de prueba externos pueden compartirse con muchos scripts de prueba
-
Se pueden desarrollar scripts de prueba de modo que utilicen datos de prueba externos para controlar la lógica de
ramificaciones condicionales dentro del script de prueba.
|
Verificar la implementación de prueba
Objetivo:
|
Verificar el funcionamiento correcto del script de prueba ejecutando el script de prueba.
|
Especialmente en el caso de la automatización de pruebas, probablemente necesitará emplear un cierto tiempo para
estabilizar el funcionamiento de la prueba mientras ésta se ejecuta. Cuando haya finalizado la implementación básica
del script de prueba, éste deberá probarse para garantizar que implementa adecuadamente las pruebas individuales y que
éstas se ejecutan correctamente.
Una vez más, debe restaurar el entorno a su estado original, haciendo limpieza después de que funcione la
implementación de prueba. Como se ha indicado en pasos anteriores, esto normalmente implica alguna forma de
restablecimiento del entorno operativo básico, la restauración de las bases de datos subyacentes a un estado conocido,
además de tareas como cargar el papel en las impresoras. Aunque algunas tareas se pueden realizar automáticamente,
otros aspectos requieren la intervención humana.
Especialmente en el caso de la automatización de pruebas, se deben cambiar los valores en las herramientas de soporte.
El objetivo es verificar el funcionamiento correcto del script de prueba ejecutando el script de prueba.
Es una buena idea realizar este paso utilizando la misma versión de compilación del software utilizado para implementar
los scripts de prueba. Con ello se elimina la posibilidad de que se produzcan problemas debido a los errores
introducidos en las compilaciones posteriores.
Es bastante habitual que algunas de las acciones realizadas y enfoques utilizados durante la implementación necesiten
un cierto grado de ajuste para permitir que la prueba se ejecute desatendida, especialmente por lo que se refiere a la
ejecución de la prueba en varias configuraciones de entorno de prueba.
En el caso de la automatización de pruebas, debe emplear un cierto tiempo comprobando que las pruebas "funcionan dentro
de las tolerancias" y ajustándolas hasta que funcionen de manera fiable antes de declarar la prueba como implementada.
Aunque puede retrasar este paso para más adelante en el ciclo de vida (p.ej., durante el desarrollo de conjuntos de
aplicaciones de prueba), se recomienda no hacerlo: si lo hace, podría terminar con una acumulación importante de
anomalías que deben solucionarse.
|
Restaurar el entorno de prueba a un estado de conocido
Objetivo:
|
Dejar el entorno tal como lo ha encontrado o en el estado necesario para implementar la siguiente
prueba.
|
Aunque este paso pueda parecer trivial, es importante crear el hábito de trabajar de forma eficaz con los otros
verificadores del equipo, especialmente cuando se comparte el entorno de implementación. También es importante
establecer una rutina que facilite pensar en el estado del sistema.
Aunque en un esfuerzo de prueba básicamente manual suele ser sencillo identificar y arreglar problemas de restauración
del entorno, recuerde que la automatización de pruebas tiene mucha menos capacidad de tolerar problemas no anticipados
con el estado del entorno.
|
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, se recomienda verificar que el trabajo tenía el valor suficiente. 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".
Intente que las personas que utilizarán el producto como entrada para realizar tareas en sentido descendente formen
parte de la revisión del trabajo interno. 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 o considerado 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 en muchos casos es contraproducente) formar completamente un producto de
trabajo que sólo se utilizará de forma parcial o que no se utilizará en absoluto en los trabajos en sentido descendente
inmediatamente posteriores. 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 la necesidad de
revisión.
Asimismo, evite la trampa de invertir un exceso de ciclos en la presentación en detrimento del valor del propio
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 o secundario para ejecutar trabajo en un producto de
trabajo y mejorar de esta forma su presentación.
|
|