Pensar en la automatización de pruebas

En muchos blogs, videos, cursos y empresas se habla sobre la automatización de pruebas en testers, analistas e ingenieros QA, pero ¿Qué es automatizar pruebas? ¿Cuál es su objetivo? ¿Cuándo automatizar? ¿Qué herramientas podemos utilizar? Son varios los enigmas que al momento de enfrentar dicha situación no sabemos cómo responder o que podemos hacer.

La automatización de pruebas tiene como objetivo ejecutar automáticamente una serie de acciones que se realizan recurrentemente al momento de enfrentar una ejecución de pruebas; Se utiliza comúnmente para agilizar los procesos y poder alertar tempranamente algún posible hallazgo, error o incidente. Son muy utilizadas en pruebas de regresión, pruebas de humo o tareas que un tester deba realizar reiterativamente evitando que tenga que ejecutarlas manualmente.

En la mayoría del tiempo, la fase de pruebas queda con una holgura muy corta de tiempo y normalmente nos quedamos solo con unos días antes de algún despliegue en ambiente productivo.

Por eso que es importante saber que con la automatización no se van a eliminar las pruebas manuales que son nuestra base, pero si vamos a mejorar la calidad de nuestros procesos, la calidad de nuestras entregas ya que lograremos ser más agiles optimizando nuestros tiempos, recursos, reduciremos el riesgo de errores humanos y cambios no intencionados.

Para empezar a automatizar es necesario conocer sobre el negocio y definir una estrategia de prueba para poder contextualizar, describir el enfoque y los objetivos generales de las tareas y los tipos de pruebas. Es necesario conocer los datos del proyecto, como, duración del sprint, tecnología y en que plataformas se debe validar para poder indicar cual será el alcance de estas pruebas.

Muchas veces en nuestro trabajo o simplemente estudiando, nos indican o imponen lo que debemos automatizar, sin embargo, no todo se puede o “debe” automatizar.

La automatización no solo es dar click en el botón record y grabar una serie de acciones, es más que eso y lo podemos descubrir mientras vayamos avanzando en éste camino.

Para realizar una automatización es necesario primero indagar, conocer el flujo que se desea automatizar, con ello es necesario realizar los siguientes cuestionamientos:

‍

•  ¿Qué es lo que queremos automatizar?

•  ¿Estos flujos de acciones se repiten? ¿Cada cuánto tiempo?

•  ¿Estos flujos son multiplataforma?

•  ¿Qué tan a menudo sufren cambios en el Código fuente?

‍

‍

‍

‍

‍

‍

Estos cuestionamientos nos darán el enfoque y nos aterrizará o ayudará a ver en términos generales lo que podemos o no realmente automatizar o si lo que vayamos o queremos automatizar de verdad vale la pena invertir tiempo.

Existen muchas herramientas de record & play que nos pueden facilitar la vida, como por ejemplo, Selenium IDE, Katalon, DataDog, Blazemeter, Jmeter, Sahi las cuales permiten simular y grabar interacciones en interfaz web y servicios, pero muchas veces estas herramientas nos ponen en grandes aprietos al querer mantener el código o simplemente al ejecutar play y vemos que no logra terminar el flujo por la simple razón que la interfaz web llama a tantas funciones que nuestro grabador no percató, pero, más importante aún es la mantención de nuestras automatizaciones cuando las basamos solo en una interfaz gráfica, la cual es la que en su gran mayoría sufre más cambios y probablemente un gran porcentaje de estos cambios influyan en nuestros scripts.

También debemos entender un poco la arquitectura de una infraestructura de lo que estemos planeando automatizar, por ejemplo, lenguaje (java, Gherkin, python), interprete (Cucumber, selenium, netbeans, visual studio code), drivers (Selenium web driver), librerías (Junit, maven) y motor de ejecución (Junit, TestNG). Todo esto en pro de conocer o armar nuestro marco de trabajo y que dicho marco logre ser robusto y que pueda abarcar no solo en lo que ya estemos trabajando, sino que también pensando en lo que podrá venir.

Es así como Mike Cohn nos muestra una estructura en forma de pirámide, el cual nos permite orientarnos con la planificación de las pruebas y considerar los niveles adecuados y así definir dónde o cómo empezar las pruebas automatizadas.

‍

‍

‍

‍

•  En la parte inferior de la pirámide se ubican los test unitarios los cuales representan la parte más extensa de la pirámide de automatización. Los test unitarios brindan feedback muy específico y rápido, pero suelen ser muchos.

•  En la parte superior de la pirámide se encuentran los test de interfaz gráfica y de los cuales debido a su fragilidad y alto costo de mantenimiento esperaríamos que fuesen muy pocos.

•  A partir de esto surge la parte media de la pirámide la cual está constituida por test que van justo por debajo de la interfaz de usuario y que Cohn denomina service tests puesto que validan las funcionalidades y servicios de la aplicación por debajo de la interfaz gráfica llamándose capa de integración y podemos validar como se integran la capa superior y la inferior. Esto hace que las validaciones realizadas por los testers sean más robustos y mantenibles y al mismo tiempo pueden lograr abarcar muchas más validaciones que en los test unitarios o test de GUI en menor tiempo.

‍

‍

Beneficios de las pruebas automatizadas:

‍

•  Ahorro de tiempo en tareas: Validar o certificar un componente o software o flujo de un proceso puede llevar mucho tiempo y más aún cuando es repetitivo como por ejemplo una prueba de regresión.

•  Prevenir errores humanos: Al ser automatizado correctamente, no debe comer errores de ejecución al ser una máquina, ya que debido al corto tiempo en el que normalmente llegan los entregables al ambiente certificador o QA, suelen ser las pruebas con un alto alcance en poco tiempo y podemos pasar por alto pequeños detalles que los podemos encontrar automatizando algunos flujos.

•  Ahorro de dinero y recursos: Al dedicar menos tiempo en ejecutar una tarea manual, nos ahorramos tiempo, lo que conlleva al ahorro de dinero y recursos a largo plazo.

•  Validar grandes volúmenes de datos o cargas: Para un testing manual es muy difícil realizar una prueba de estrés ya que debería tener varios emuladores o ventanas abiertas para poder realizarlo de manera manual, es por eso que las pruebas que verifican si pueden soportar una carga de varios cientos de usuarios simultáneamente deberían ser totalmente automatizadas y así evitar nuevamente la utilización de recursos y tiempo extras.

‍

‍

Desventajas de las pruebas automatizadas:

‍

•  Se sugiere que se automaticen en proyectos grandes que perduren, ya que no todo se debe automatizar como por ejemplo un flujo que cambie constantemente.

•  Tiempo invertido para escribir el código e investigación para aprender en que lenguaje programar la automatización, pero a largo plazo sigue siendo la mejor opción.

•  No todo es totalmente automatizable ya que no podemos validar diseños y facilidades de uso.

‍

‍

Cuadro comparativo de las pruebas manuales y las pruebas automatizadas:

‍

‍

‍

Hoy en día la automatización de pruebas ha ganado mucha popularidad, la literatura va creciendo a pasos muy grandes y los testers tenemos más herramientas muy útiles para poder realizar comparaciones de lo que nos puede brindar más funcionalidades u orientarnos para poder crear nuestro marco de trabajo y poder de esta manera robustecer nuestro labor del día a día, podemos sacar mucho provecho, aprender y también optimizar tiempos y recursos lo que en el día de hoy es muy importante tanto en lo laboral como en lo personal.

Creo también que las empresas de desarrollo de software deben orientar a que los testers, analistas QA e Ingenieros QA, fomenten en mejorar sus habilidades en combinar las tareas manuales y automatizadas y así poder sacar el mayor provecho a los dos métodos y combinarlos de la mejor manera.

‍

‍

‍

‍