Tarea: Implementar la prueba
En esta tarea se describe cómo desarrollar pruebas autónomas o de colaboración.
Disciplinas: Prueba
Objetivo

El objetivo de esta tarea es:

  • Implementar uno o más productos de trabajo de prueba que permitan la validación del producto de software mediante la ejecución física
  • Desarrollar pruebas que se puedan ejecutar conjuntamente con otras pruebas como parte de una infraestructura de prueba mayor
Relaciones
Pasos
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:

Scripts de prueba manuales Para seleccionar implementar la técnica

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.

Scripts de prueba programados Para seleccionar implementar la técnica

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.

Scripts de prueba registrados o capturados Para seleccionar implementar la técnica

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]

Pruebas generadas Para seleccionar implementar la técnica

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:

(Opcional) Ensayo manual de la prueba Para configurar

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.

Identificar y confirmar la adecuación de los oráculos de prueba Para configurar

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.

Restablecer el entorno y las herramientas de prueba Para configurar

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:

Implementar acciones de navegación Ir a la parte superior de la página

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.

Implementar puntos de observación Ir a la parte superior de la página

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.

Implementar puntos de control Ir a la parte superior de la página

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.

Resolver errores en la implementación de prueba Ir a la parte superior de la página

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.

Restaurar el entorno de prueba a un estado conocido Verificar la implementación de prueba

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.

Configurar las herramientas e iniciar la ejecución de la prueba Verificar la implementación de la prueba

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.

Resolver errores de ejecución Verificar la implementación de prueba

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.



Más información