menu_superior

Automatización de Pruebas (III): el Cómo

Este post forma parte de una serie sobre automatización de pruebas. Puedes acceder aquí a la primera parte y aquí a la segunda.


En los capítulos anteriores he repasado algunas características que debemos ponderar antes de decidir automatizar. Estamos en ese punto en que si ejecutamos de manera automática algunos casos de prueba baja la saturación de los recursos y aumenta la calidad del producto software. Es decir, ya sabemos que la automatización aporta valor añadido y por lo tanto queremos que forme parte de nuestro kit de recursos.

A modo de guía estos pasos son los que yo suelo seguir para automatizar casos de prueba.

  1. seleccionar las funcionalidades. El criterio de selección puede ser la importancia de la funcionalidad para el negocio, la frecuencia de uso, si tiene antecedentes problemáticos, que no tenga una funcionalidad “alternativa”… El criterio depende del objetivo y de las prioridades así que lo mejor es consultar con el negocio e incluso con los equipos de desarrollo para establecer el conjunto de funcionalidades más significativas.
  2. definir la frecuencia con la que se ejecutarán los casos de prueba. Normalmente esto se hace en función de la frecuencia con la que el software sale a producción, si bien podemos definir nuestro propio criterio dependiendo de otros factores como cambios en el entorno o que haya actualización de controladores de dispositivos. Incluso es posible tener varios conjuntos de casos de prueba automáticos y ejecutarlos de manera independiente según las partes del sistema afectadas por los cambios.
  3. construir los scripts. Esta es la parte central, la más importante, pero seguramente la más obvia por que construir un script para automatizar un caso de prueba no necesita mayores explicaciones. Recordar que el objetivo es validar que el aplicativo sigue la secuencia y produce los resultados esperados. Si disponemos de una herramienta que lo permita podremos mapear objetos, propiedades y elementos visuales para afinar que el resultado de la ejecución es exactamente el esperado.
  4. analizar la vigencia de los datos. La gasolina de los scripts van a ser los datos de los que se alimenta y es importante que esos datos sean correctos para que no generen errores (altas duplicadas, consultas fuera de fecha, borrado o modificación de elementos inexistentes, etc.) Hay que saber si los datos de entrada son reutilizables, si tienen un periodo de validez o cualquier restricción, si es así, los responsables de la aplicación por la parte del negocio y los equipos implicados en el desarrollo del software nos deberán proporcionar los juegos de datos de prueba antes de la ejecución.
  5. programar la ejecución y estudiar los informes. Como la ejecución es automática, hay que programarla: definir la fecha y la hora o los eventos que la desencadenan (triggers) y, posteriormente estudiar el resultado de las pruebas. Personalmente prefiero que los logs o informes de resultados sean simples y que solo tengan información cuando haya errores, pero eso depende de los requisitos y del objetivo de las pruebas.

Todos estos pasos son una generalización y es necesario adaptarlos cuando se aplican a un caso real y la decisión óptima dependerá de las circunstancias, las prioridades y el objetivo de las pruebas automáticas. Este es el valor añadido del analista y del jefe de proyecto de pruebas, aplicar el criterio y la experiencia a un contexto determinado para optimizar el resultado.

Puedes continuar leyendo la última entrada sobre automatización de pruebas: Un caso de éxito.

, , ,