¿Cómo empezar con la automatización de pruebas funcionales?

En una entrada anterior del blog hablamos sobre cuándo conviene emprender la automatización de pruebas funcionales. En este post veremos ideas relativas a cómo emprender ese camino.

Podemos distinguir 2 etapas en el proceso:

  1. Desarrollo de la plataforma de automatización
  2. Desarrollo de las pruebas automatizadas

Desarrollo de la plataforma de automatización

El desarrollo de la plataforma de automatización es el puntapié inicial en la automatización de pruebas para un producto puntual. En primera instancia es vital conocer los requerimientos necesarios para las pruebas. Por ejemplo, verificaciones con lectura de bases de datos o si hay reportes en pdf que las pruebas deben leer y comparar.

Luego que sabemos lo que necesitamos buscamos herramientas o la combinación de estas para satisfacer las necesidades. En el ejemplo anterior (lectura en bases de datos y pdf’s) podemos combinar un framework de pruebas unitarias como JUnit o TestNG con librerías de automatización a nivel de interfaz gráfica, librerías para conexión a bases de datos, librerías para manejo de pdf, entre otras.

Una vez seleccionadas las herramientas es necesario integrarlas y hacer una prueba de concepto de la plataforma.

El siguiente paso es desarrollar las funciones o módulos básicos para que las pruebas sean composición de estas. Por ejemplo, crear las funciones: Login, CrearInstancia, VerificarCreación, ModificarInstancia, VerificarModificación, Logout.

Las pruebas serán combinaciones de estas funciones con diferentes datos. Por ejemplo:

  • Login (usuario1)
  • CrearInstancia (instancia1)
  • VerificaciónCreación (instancia1)
  • Logout
  • Login (usuario2)
  • ModificarInstancia (instancia1)
  • VerificarModificación (instancia1)
  • Logout

Por supuesto, en el desarrollo de las pruebas se continuará creando nuevos módulos y funciones a medida que surjan las necesidades.

Desarrollo de las pruebas automatizadas

Como en un proyecto de desarrollo de software (que de hecho lo es), comenzamos con ciclos de diseño, implementación, verificación y validación de pruebas. Es importante marcar ciclos cortos de manera que se puedan mostrar resultados rápidamente.

Un esfuerzo no despreciable es el dedicado a la configuración del entorno de datos necesario para los scripts. Pronto publicaremos una entrada relativa a eso.

El diseño de las pruebas es fundamental para encontrar elementos  comunes y reutilizables que se puedan consolidar en funciones  para el uso de varios scripts. De esta manera aumentamos la  productividad porque se crearán nuevos scripts más rápido,  reutilizando funciones. De la misma forma se aumenta la  mantenibilidad ya que ante cambios en las interfaces de la  aplicación (tanto GUI como API) los cambios se realizan  únicamente en las funciones y no en cada script.

Para la implementación, en este esquema de trabajo, las herramientas Record and Playback pasan a un segundo plano ya que directamente se codifica las pruebas pudiendo utilizar  scripts similares como plantillas. La grabación de un script no tiene sentido ya que este se construye a partir de la composición de funciones y no una nueva serie de acciones.

En cuanto a la etapa de prueba de los scripts, cabe destacar que la  verificación se refiere a la prueba de los scripts en el ambiente en donde se desarrollan. La validación es deseable que se haga en un nuevo ambiente para probar así que los datos requeridos para la ejecución están bien documentados y configurados.

Resumen

Esperamos con este post haber dado un pantallazo a alto nivel de cómo se puede arrancar con un proyecto de automatización de pruebas funcionales.

En resumen, se desarrolla una plataforma que establece las bases para un desarrollo sustentable de scripts, facilitando la creación de nuevos y el mantenimiento de los actuales.

Hasta la próxima.

Mauricio Farías

¿Los informáticos necesitamos cábalas para reproducir incidentes?

Ayer casi sin quererlo me encontré rodeada de fanáticos “hinchas” futboleros, al principio todo lo que decían carecía de sentido para mí. Al pasar los minutos, mi actitud hacia lo que escuchaba cambió y comencé a sorprenderme.  Algo que realmente no deja de sorprenderme son las cábalas, la creencia popular supone que existe una fuerza más allá de lo natural relacionada con una o varias acciones que provocan que suceda algo.

En el deporte y en este caso en el fútbol, ocurre que si queremos un resultado igual al anterior debemos repetir exactamente la secuencia de acciones que hicimos antes y durante el partido anterior.  Fue ahí cuando comprendí que estos hinchas no hacen más que intentar generar un contexto igual al anterior para generar un resultado igual al anterior.

Algo similar ocurre cuando probando software encontramos un incidente, para lograr reproducirlo debemos generar un contexto igual para obtener nuevamente el incidente.

Así cuando estamos probando un software debemos prestar atención a todo el ambiente y las acciones que ejecutamos para saber exactamente cómo reproducir una situación. Pero cuidado hinchas y testers de software olvidar tan sólo una de estas acciones puede significar la perdida de la copa Libertadores!

María Elisa Presto