Reflexiones sobre la automatización de pruebas

La semana pasada dicté junto a @dfontde un taller de automatización de pruebas. Entre la audiencia tuvimos principalmente desarrolladores.

Obviamente uno de los temas que tratamos fue la automatización de pruebas a nivel de Interface Gráfica de Usuario (GUI). De hecho cada vez que dicto este taller la gente suele venir con la expectativa de encontrar la bala de plata para poder automatizar pruebas exclusivamente a nivel GUI. Mi posición al respecto es siempre la misma: ¿en verdad que quieres automatizar pruebas a ese nivel?.  A lo largo del taller trabajamos fuertemente sobre la cuestión de a qué nivel automatizar las pruebas y muchos suelen convencerse que puede resultarles más conveniente trabajar la automatización a nivel del API/Servicios.

Las pruebas a nivel GUI suelen ser frágiles (cambios mínimos en la GUI pueden romper las pruebas) y costosas de ejecutar (ya que requieren instanciar la aplicación completa). Pero al mismo tiempo pueden ser la única opción de automatización, ya que prueban la aplicación en modo caja negra, no importa como esté construida la aplicación pues simplemente se interactúa con ella desde afuera. Este es un punto muy relevante para el caso de aplicaciones legacy, que muchas veces han sido construidas sin características de testeabilidad. Más allá de estos argumentos que son clásicos y pueden encontrarse en la bibliografía hay algunas cuestiones adicionales que se han puesto de manifiesto en los últimos años.

  • Por un lado cada vez son más comunes las famosas SPAs (Single Page Application), muchas veces basadas en frameworks “client-side”como AngularJS. Esto implica una creciente cantidad de código JavaScript. Este tipo de aplicaciones no suele ser tan simple de automatizar a nivel GUI pues no todas las herramientas no se lo bancan bien. Pero al mismo tiempo aparece un nuevo nivel de automatización posible: pruebas unitarias de los componentes JavaScript.
  • Por otro lado, los frameworks de desarrollo / generadores de código “server-side” como Spring-Boot ya incluyen como parte de sus funcionalidades una propuesta para la codificación de pruebas automatizadas a nivel de API e incluso en algunos casos se encargan de generar el código de algunas de estas pruebas.

En mi opinión estas dos cuestiones refuerzan necesidad de repensar cualquier intento de automatización de pruebas a nivel GUI. Y quiero ser muy claro en cuanto a esto: no estoy diciendo que no se automaticen pruebas a nivel GUI, sino simplemente que no me parece una buena estrategia que el grueso de las pruebas automatizadas sea a nivel GUI. Creo que hay que pensar en una estrategia de automatización más integral que incluya pruebas a distintos niveles. Esto nos permitirá tener una mejor cobertura con un esfuerzo mucho menor y repartido entre los distintos perfiles del equipo (tengamos presente que el testing no es sólo responsabilidad de los testers).

Anuncios

Un comentario en “Reflexiones sobre la automatización de pruebas

  1. Excelente Analisis Nico. La estrategia de pruebas tiene que tener un enfoque holistico e interdisciplinario, siempre, los equipos tienen que tener también TODAS las habilidades necesarias para producir un producto potencialmente entregable.
    Ojo tambien que los “QA” automations conocen algunos tips ara robustecer los TCs de UI y que no pinchen.
    El testing depende del contexto y hay que elegir la estrategia siempre.

Responder

Introduce tus datos o haz clic en un icono para iniciar sesión:

Logo de WordPress.com

Estás comentando usando tu cuenta de WordPress.com. Cerrar sesión / Cambiar )

Imagen de Twitter

Estás comentando usando tu cuenta de Twitter. Cerrar sesión / Cambiar )

Foto de Facebook

Estás comentando usando tu cuenta de Facebook. Cerrar sesión / Cambiar )

Google+ photo

Estás comentando usando tu cuenta de Google+. Cerrar sesión / Cambiar )

Conectando a %s