Las siete mejores prácticas de automatización de pruebas

La automatización de pruebas nos brinda los siguientes beneficios:

• Eficiencia: La velocidad de ejecución de una máquina es considerablemente mayor a la de un ser humano, lo que permite acelerar el proceso de pruebas.
• Precisión: Una máquina es menos propensa a cometer errores que un ser humano, aumentando la efectividad y confiabilidad de las pruebas.
• Mayor cobertura: Disponer de scripts que ejecutan pruebas de manera autónoma permite enfocar los recursos de testing manual en otras funcionalidades del sistema.

Sin embargo, es común cometer el error de centrar la atención únicamente en las ventajas, dejando de lado los riesgos que conlleva no seguir un proceso adecuado a la hora de diseñar e implementar pruebas automatizadas. No tener en cuenta estos riesgos puede tener como consecuencia que un proyecto de automatización no llegue a buen puerto, es decir, no alcanzar  a cumplir los objetivos planificados en tiempo y forma.

A continuación se detallan las 7 mejores prácticas de automatización de pruebas que se deben tener en cuenta durante un proceso de automatización, para minimizar los riesgos y sacar el máximo provecho a las ventajas que nos brinda el testing automatizado:

1. 1. Viabilidad del proyecto de automatización 
2. 2. Planificar tiempos y definir recursos
3. 3. Seleccionar la herramienta adecuada
4. 4. Mayor parametrización se traduce en mayor mantenibilidad
5. 5. Buenas estrategias de localización
6. 6. Correr pruebas sobre el mismo juego de datos
7. 7. Automatización de pruebas como complemento a las pruebas manuales

1. Viabilidad del proyecto de automatización

Una de las peores situaciones que se pueden dar es que se dedique tiempo y recursos en automatizar pruebas sobre un sistema que no está listo para ello, o que se automaticen casos de prueba que no aportan valor al proyecto.

Se debe tener presente que la automatización de pruebas es una inversión de tiempo que se realiza para tener mayor eficiencia a la hora de la ejecución de las mismas. Si el tiempo que se dedica al mantenimiento de los scripts de prueba supera por mucho el que lleva hacer las pruebas de forma manual, porque por ejemplo, el sistema no se encuentra en una versión estable, entonces no se están obteniendo los beneficios brindados por la automatización de pruebas.

Lo mismo sucede cuando no se tiene un objetivo bien definido relacionado a lo que se quiere probar al implementar pruebas automatizadas. Definiciones poco claras del alcance de las pruebas pueden llevar a que se inviertan recursos en automatizar áreas del sistema que no son prioritarias.

Este tipo de situaciones se pueden evitar fácilmente haciendo un análisis inicial de factibilidad del proyecto, así como plantear de forma clara el alcance y los objetivos que se quieren cumplir con la integración de la automatización de pruebas.

2. Planificar tiempos y definir recursos

Ya habiendo definido el alcance y los objetivos del proyecto, el siguiente paso fundamental es definir los recursos que serán asignados al mismo.

No realizar una distribución clara de los recursos es una de las formas más comunes en las que un proyecto de automatización de pruebas puede llegar a no progresar más allá de la etapa inicial de planificación.

Después de todo, si no está claro quienes van a ser las personas que participarán en dicho proyecto y cuánto tiempo de dedicación se invertirá en el mismo, el progreso se verá enlentecido debido a que se hará foco en otras tareas no relacionadas a la automatización que sí tengan prioridades claras y bien definidas.

Otro error que se comete a menudo es automatizar únicamente en los tiempos libres. Desde las etapas tempranas del proceso de introducción de pruebas automatizadas se tiene que tener muy en claro que se trata de una inversión a futuro. De no invertir recursos específicos, no se cosecharán resultados.

3. Seleccionar la herramienta adecuada

La elección de la herramienta o framework que se utilizará durante el proceso de automatización es sin dudas una de las mejores prácticas para la automatización, así como una de las consideraciones más importantes a definir en el plan de automatización. Esta decisión puede llevar, tanto a que el proceso de automatización finalice de acuerdo a lo planificado cumpliendo con los plazos pactados, como a no llegar a término.

Elegir la herramienta de manera adecuada no es tarea sencilla. Sin embargo, estas son las ideas más importantes a tener en cuenta a la hora de seleccionar la herramienta de automatización que se utilizará durante el proceso.

Como primer concepto a tener en cuenta, no existe una herramienta que se adecúe y sea la mejor opción para todos los contextos. Es por esto que las características que se mencionan, serán aquellas que ayuden a tomar decisiones según el contexto en cuestión.

Dicho esto, la herramienta o framework ideal es aquella que mejor se adecúa tanto a las necesidades del proyecto, como a las capacidades del equipo de testing encargado de llevar a cabo la automatización.

En la actualidad existe una gran variedad de herramientas de automatización. Dentro de estas opciones, debemos elegir aquellas que se adecúen mejor a los tiempos del proyecto, al alcance del mismo (desafíos técnicos necesarios), así como la cobertura que se pretende alcanzar (cantidad de escenarios a automatizar, o si precisa cross-browser testing por ejemplo).

Por otro lado, como se mencionó anteriormente, es claro que los conocimientos y capacidades del equipo automatizador son determinantes a la hora de seleccionar la herramienta a utilizar. Sin embargo, este punto toma aún más relevancia si el equipo no tiene conocimientos de programación elevados. En estos casos lo mejor es optar por una herramienta “codeless”, permitiendo crear y mantener scripts de automatización de manera intuitiva y sin necesidad de programar.

Cabe destacar que existen también frameworks que integran ambas opciones, permitiendo al tester optar por programar o realizar los scripts de manera asistida e intuitiva. La ventaja de estas herramientas es que permiten combinar un equipo de trabajo heterogéneo en sus capacidades de programación, logrando muy buenos resultados en poco tiempo.

4. Mayor parametrización se traduce en mayor mantenibilidad

Una vez creados los scripts de automatización, hay que mantenerlos. Debido a que los sistemas a probar se encuentran en estado de desarrollo constante, es esperable que ciertos cambios al sistema requieran actualizar los scripts de automatización.

Esta actualización de los scripts automatizados insume mucho esfuerzo, más aún si el sistema en cuestión es de mediano o gran porte.

Por este motivo una de las mejores prácticas de automatización de pruebas es la correcta parametrización durante el proceso de desarrollo de los scripts automatizados. Mayor parametrización se traduce directamente en menos esfuerzo a la hora de mantener los scripts automatizados y en mayor capacidad de reutilización.

Como se mencionó anteriormente, a medida que el sistema crece, aumentan la cantidad de casos de prueba automatizados, por lo que se vuelve indispensable la parametrización. En estos casos es recomendable saltar al próximo nivel de parametrización, y crear un framework de automatización personalizado para el sistema en cuestión; funciones de alto nivel para manejar el sistema permiten crear casos de prueba de manera más rápida, eficiente y estandarizada, aumentando en gran medida la robustez y minimizando el esfuerzo de mantenimiento ante cualquier cambio.

5. Buenas estrategias de localización

Si las pruebas a automatizar son de interfaz de usuario, es muy probable que gran parte del esfuerzo se enfoque en localizar elementos de la misma. Es por esto que elegir una correcta estrategia de localización de elementos es sin dudas una de las prácticas para la automatización más importantes a tener en cuenta. Una mala estrategia de localización de elementos puede multiplicar enormemente los esfuerzos de mantenimiento de los scripts de prueba, y ser el motivo por el cuál no se lleguen a cumplir los objetivos planteados inicialmente.

Teniendo en cuenta que el sistema bajo pruebas se encuentra en continuo desarrollo, es importante darle preferencia a los localizadores menos propensos al cambio, es decir, aquellos que tienen menos probabilidad de variar en futuras versiones del sistema (por ejemplo “ID”, “name” o “class”). Sin embargo, existen ocasiones en las que los elementos del sistema no cuentan con localizadores únicos, lo cual hace necesario utilizar estrategias un poco más complejas como CSS o XPath.

Una vez detectado un elemento que no cuenta con identificador único, es preciso tener ciertas consideraciones a la hora de elegir los selectores CSS y XPath. Selectores demasiado generales pueden resultar en que nuestras pruebas arrojen falsos positivos (los scripts dan por buenos elementos que no se encuentran en la interfaz realmente), mientras que selectores muy específicos pueden generar falsos negativos (ante el mínimo cambio los scripts automatizados fallan por no poder localizar el elemento, aunque el mismo esté presente en la interfaz de usuario). El éxito se encuentra en el punto medio de estos dos polos, generando un selector que sea lo más simple posible y refiera sólo al elemento en cuestión. 

Teniendo en cuenta la diferencia de tiempos que se genera en la implementación de los scripts debido a la localización de elementos de la interfaz, se recomienda analizar el sistema durante la etapa de planificación; si los elementos del sistema no cuentan con identificadores únicos es importante conocerlo antes de comenzar a implementar los scripts automatizados, ya sea para estimar con más precisión el esfuerzo necesario, o incluso evaluar junto al equipo de desarrollo la posibilidad de mejorar estos localizadores.

6. Correr pruebas sobre el mismo juego de datos

Dependiendo del contexto y del proyecto al que se pretende introducir prácticas de testing automatizado, es importante tener en cuenta ciertas consideraciones en lo que respecta a los datos del sistema que formarán parte de las pruebas a automatizar.

Existen ciertos contextos donde el estado inicial y el estado final de un sistema luego de realizar una prueba es el mismo. Sin embargo, en otros casos, luego de ejecutar pruebas los datos del sistema quedan alterados respecto al estado inicial. Teniendo en cuenta que el script automatizado necesita partir desde el mismo juego de datos, notaremos que frente a un sistema de este tipo, la segunda ejecución de un mismo script automatizado fallará al no contar con el juego de datos necesario como precondición.

Para poder hacer frente a esta situación, se vuelve imprescindible detectar en cuál de estos contextos nos encontramos. Si el sistema o funcionalidad a probar necesita un juego de datos específico, será útil valorar las siguientes opciones:

• Deshacer los cambios que se efectuaron al sistema durante un script automatizado mediante instrucciones, e integrarlas al final del script original. En otras palabras, incluir al final del script automatizado, instrucciones que devuelvan el sistema a su estado inicial.
• Agrupar los scripts de flujos de prueba relacionados. Por ejemplo, agrupar casos de prueba de agregar y eliminar un registro, garantizando que siempre se ejecuten ambos y en ese orden. De esta manera, el elemento agregado se elimina en el mismo flujo, logrando que el estado final del sistema sea el mismo que el inicial.
• Coordinar junto al equipo de desarrollo una reinicialización automática de datos, para así integrarlo a nuestras pruebas automatizadas. Por ejemplo, en caso de estar automatizando pruebas de interfaz de usuario, una aplicación de esta alternativa sería tener un botón en alguna pantalla del ambiente de pruebas que permita reiniciar los datos. Si este fuera el caso, alcanza con crear una función que haga click sobre este botón, y luego llamar a esta función al final de cada script automatizado. Esta alternativa es la más recomendada de las tres, ya que otorga mayor robustez al proceso de automatización. Disponer del reinicio de datos como una función de nuestro proyecto de automatización, permite ejecutarlo luego de cada caso de prueba (“@AfterTestCase”), y así devolver el sistema a su estado inicial en caso de que una prueba no termine de ejecutarse por algún motivo.

7. Automatización de pruebas como complemento a las pruebas manuales

Como se mencionó anteriormente, son claras las ventajas que aporta la automatización de pruebas. Sin embargo, existen cualidades en las que el ser humano aún vence a las máquinas, como lo es la capacidad de discreción. Asimismo, existen pruebas cuya relación costo beneficio de automatizarlas no es favorable, y que conviene continuar ejecutando de manera manual.

Teniendo en cuenta esto, es claro que las pruebas de automatización no deben sustituir las pruebas manuales, o al menos no todas. Aquellas pruebas no repetitivas, discrecionales o que insumen demasiado tiempo en diseñar y/o mantener el script de automatización, deben seguir siendo probadas manualmente.

Es importante tener presente este punto en la planificación del proceso de automatización. No hacerlo pueden significar horas de trabajo en automatizar tareas que no deberíamos automatizar. Invertir esfuerzos en automatizar pruebas que deben ser ejecutadas manualmente es un error muy común de cometer, por eso es importante tenerlo presente desde el comienzo del proceso de automatización.

Tener en cuenta y aplicar los consejos detallados anteriormente, aumentarán significativamente la efectividad y eficiencia de un proyecto de automatización. Sin embargo, recordar que si bien es importante tenerlos en cuenta durante todo el proceso de implementación, cuánto antes se pongan en práctica, mejores resultados se obtendrán.