¿Cuándo automatizar una prueba?

En este artículo, escrito por Charles Rodríguez con el apoyo de Alejandro Berardinelli, ambos de Abstracta, presentan una aproximación a la automatización, con el objetivo de reconocer la viabilidad de automatizar una prueba según el contexto del proyecto. Creo que es muy útil para un tester entender en qué consiste la automatización, y tener claro cuándo algo es automatizable como para estar atento a cómo optimizar su trabajo, ya sea colaborando con otros compañeros, desarrolladores, o animándose a probar alguna herramienta para esto.

---

• 

• 

---

Abordaremos algunos conceptos que son fundamentales cuando no se tiene experiencia automatizando, así como también evaluando su importancia y beneficios en relación con el testing manual.

Históricamente la automatización surge para reducir el esfuerzo del ser humano, en aquellas actividades que pueden ser replicadas por un sistema o máquina programable, con el objetivo de simplificar el trabajo pesado, repetitivo o complejo, haciéndolo eficaz y más productivo. Se busca de esta manera ahorrar en energía, tiempo y costos, lo que permitiría enfocarse en otras tareas.

En el Desarrollo de Software puede abordarse de igual forma automatizando el esfuerzo que puede ser realizado manualmente.  Los pasos seguidos se traducen a scripts repetibles, enfocando la energía en otras tareas específicas que aporten mayor valor y reduciendo los tiempos de ejecución. Por otro lado, en algunos casos la automatización nos permite llegar a realizar pruebas que un humano no podría, sobretodo teniendo en cuenta la limitación en la cantidad de ejecuciones en relación al tiempo.

Seguramente la pregunta que se nos presenta con mayor frecuencia al querer automatizar, motivo de este artículo, es: ¿cuándo algo es automatizable?

Responder a esto nos introduce en el desafío de identificar la inversión, enfoque y beneficios adecuados en un determinado contexto, pero lo más importante que se tiene que evaluar es el “conocimiento”.

Como ejemplo para entender lo anterior, podríamos pensar en la automatización industrial para la elaboración de un alfajor, en la cual se ejecutan varios pasos que, con el paso del tiempo, se van optimizando. Consecuentemente, gracias al estudio de estos pasos ejecutados en forma artesanal por personas expertas, se comenzó la automatización de los mismos.

Con la automatización del Testing debemos hacer lo mismo, primero conocer, aprender y luego automatizar. Este es el pilar para saber cuándo algo es automatizable, lo que implica que el testing manual no es completamente sustituible.

Mitos

Automatizar tiene sus ventajas y desventajas, dependiendo del proyecto, lo que está relacionado con las variables de tiempo, costo, calidad y metodología.

En base a lo anterior, otro punto muy importante, es que más allá de automatizar o no, hay que comprender el contexto y que todo lo que se hace es en función de cumplir con los objetivos de la mejor manera posible, seleccionando y aplicando los métodos, herramientas y skills adecuados. Por lo que es recomendable evitar caer en ciertos mitos:

• Se puede automatizar todo
• Automatizar siempre determina una mejor calidad
• El testing automatizado es mejor que el manual
• Automatizar tiene un rápido retorno de la inversión

Obviamente se pueden dar casos en el que alguno de estos tenga lugar, pero no es la regla.

En la escuela del Context-Driven Testing se exponen los siguientes siete principios que ayudan a entender el objetivo que se debe buscar, ya sea en pruebas manuales o automatizadas, siendo aplicables a cualquier proyecto.

• El valor de cualquier práctica depende de su contexto.
• Hay buenas prácticas en contexto, pero no hay “buenas prácticas”.
• Las personas, trabajando en conjunto, es la parte más importante del contexto en cualquier proyecto.
• Los proyectos no son estáticos y frecuentemente toman caminos impredecibles.
• El producto es una solución. Si el problema no se resuelve, el producto no funcionará.
• El buen testing de software es un proceso intelectual desafiante.
• Sólo a través de juicio y habilidad, practicándose cooperativamente durante todo el proyecto, seremos capaces de hacer las cosas correctas en el momento correcto para poner a prueba nuestros productos de manera efectiva.

Estos principios fueron propuestos por Cem Kaner, James Bach y Brett Pettichord en su libro “Lessons Learned in Software Testing: A Context-Driven Approach”: los cuales nos ayudan a captar la importancia que tiene la capacidad de amoldarse según la situación del proyecto actual.

En estos días se ha adoptado una cultura “Agile” que requiere la concreción de resultados visibles en determinados períodos de tiempo, significando un gran desafío para los testers, por lo que se hace necesario comprender el marco de trabajo en el cual la automatización cumple un papel fundamental.

Manual versus automatizado

Sin tener experiencia previa podríamos querer automatizar todo, ya sea tests unitarios, API, a nivel de UI, funcionales, entre otros, pero el costo que genera desarrollar y mantener los scripts no es algo para tomar de forma liviana.

Cuando en un proyecto se apuesta a la automatización, idealmente sería recomendable tener una base sólida desde los casos unitarios, previniendo la mayor cantidad de bugs posible con un feedback inmediato y así sucesivamente por las diferentes capas, para que el testing Manual y Exploratorio tome el mayor valor posible a nivel de UI, enfocándose en pruebas que no son posibles automatizar por la condición de ser humano.
En la siguiente imagen se puede ver la conocida pirámide de Cohn, que intenta evidenciar lo anterior. Para ver en mayor profundidad este tema, ver este post en el blog de Abstracta.

A la izquierda vemos cómo se hace comúnmente y a la derecha podemos apreciar el ideal que se debería alcanzar, donde vemos el peso de la automatización en la pirámide.

Aunque existan diferencias entre el testing automatizado y el manual, estas no son tareas excluyentes, sino que se apoyan como unidades complementarias en búsqueda de una mejor calidad de software.

Si pensamos en el retorno de la inversión del Testing, probar una nueva funcionalidad de forma manual permite conocer rápidamente la aplicación a un bajo costo. A medida que se adquiere  conocimiento, el inventario de pruebas aumenta y en consecuencia el costo también crece para las pruebas manuales. Por otro lado, la automatización tiene un costo inicial mayor el cual va disminuyendo a medida que se avanza. Este comportamiento se puede visualizar en el siguiente gráfico (tomado de acá):

Analizando esto, vemos que automatizar tiene una gran inversión inicial hasta el “punto de quiebre” en donde comenzamos a visualizar el impacto positivo que genera en los costos a largo plazo si lo comparamos con el testing manual, para lo cual podemos evaluar que ambas actividades de testing, son totalmente compatibles generando beneficios a corto y largo plazo.

¿Qué automatizar?

Ahora que ya tenemos conocimiento de la importancia y efectos de la automatización, tenemos que identificar los casos que podemos automatizar. Para ello debemos tener en cuenta el objetivo que se está persiguiendo y a qué nivel, como vimos en la pirámide de Cohn.

En este sentido podemos intentar responder lo siguiente:

¿Cuál es el objetivo?

Lo primero que estamos buscando es apuntar siempre a una mejor calidad del software y analizar si automatizar “encaja” dentro del proyecto que se esté desarrollando.

Para responder la pregunta sería recomendable hacer un análisis de viabilidad en relación con nuestros objetivos.

Para esto se pueden presentar los siguientes escenarios según la aplicación bajo prueba, en los cuáles podríamos automatizar:

• Existe deuda técnica y se quiere trabajar para eliminarla.
• Las pruebas de regresión consumen mucho tiempo.
• Se dispone de un proyecto complejo y largo en el tiempo.

Si la aplicación que se quiere automatizar va por el camino de alguno de estos escenarios, podemos deducir que la automatización es casi necesaria, por lo que hay que atacar estos problemas.

¿Qué casos de prueba automatizar?

Como ya vimos, no todo es automatizable en contexto, por eso es que se hace relevante conocer cuáles casos son los adecuados para nuestro fin. Pensando a nivel de código y del desarrollador, los test unitarios son los más sencillos de llevar a un script. Del lado del tester generalmente se trabaja en automatizar los casos de regresión a nivel de UI y de API, pensando primero en los flujos más críticos y más complejos.

A continuación se presentan aquellos casos que puede llegar a servir automatizar.

Regresiones

Ante la situación en que ya tenemos un repositorio de pruebas definidos y hay que ejecutarlos periódicamente luego de cada liberación del producto, se vuelve repetitivo el esfuerzo de correrlos manualmente, además de quitarnos tiempo a otras tareas que no son automatizables y donde podemos aportar más valor.

Es muy claro que estos casos de prueba de regresión son por excelencia automatizables, siendo conveniente en particular para integrar dentro de un modelo de CI/CD. Esto adquiere valor en cuanto a lo que respecta al costo y el tiempo que se gana para realizar otras tareas, ya que los scripts pueden ser ejecutados desatendidamente mientras se realizan otras actividades.

De alto riesgo para el negocio

Estos casos por lo general se acuerdan con los stakeholders, en donde se pone énfasis en verificar las funcionalidades prioritarias y críticas, que de fallar afectan en gran medida el modelo de negocio. Por esto es que a este enfoque se llama “Testing basado en riesgos”.

Automatizar los casos que prueban estas funcionalidades, puede ayudar a encontrar casi inmediatamente, luego de cada release, aquellas incidencias en las que se debe tomar acción rápidamente y puedan ser bloqueantes para la puesta en producción de dicho release.

Complejos y/o que consumen mucho tiempo

Puede que se presente en un proyecto algunos casos que sean complejos de reproducir manualmente, por lo que si lo llevamos a un script resultará más sencillo ejecutarlos de forma automatizada. Si se trata de un formulario con muchos datos, tal vez es más probable que el tester se equivoque, y más si tiene que probar el mismo form con muchas variantes de datos. Podemos reducir la probabilidad de error si lo automatizamos.

Casos Repetitivos

De igual forma que las regresiones se vuelven una tarea repetitiva, puede que tengamos casos particulares en los que sea conveniente darle lugar a la automatización. Por ejemplo, se puede presentar que al probar manualmente una gran cantidad de datos para el mismo flujo, nos llevaría un tiempo considerable y si además lo tenemos que repetir se vuelve algo tedioso. En cambio automatizando este flujo podríamos parametrizar estos datos y olvidarnos de tener que probar con cada valor manualmente. Esto se conoce también como data-driven testing, donde una prueba automatizada se parametriza y se alimenta con datos de alguna fuente de datos, como puede ser un archivo o una base de datos.

Selección de herramientas

Ahora que ya sabemos qué automatizar, podemos avanzar a seleccionar la herramienta que vamos a utilizar. Esta actividad puede ser una de las más complejas de analizar en un principio dada la cantidad de herramientas disponibles, pero la decisión tendrá que considerar básicamente el proyecto, presupuesto, conocimiento y experiencia de los involucrados.

Existen diversas herramientas open-source, comerciales, y customizadas, que varían en sus limitaciones y posibilidades, por lo que, para seleccionar la herramienta correcta, hay que tener claros los requerimientos con los que se debe contar para avanzar a evaluar el costo-beneficio de su uso.

En Abstracta utilizamos una gran variedad de herramientas que, como hemos mencionado durante todo el artículo, se seleccionan según el contexto del proyecto, pero dada la flexibilidad que algunas brindan, se prioriza el uso de unas sobre otras. En nuestro caso las más utilizadas son Selenium, Appium, Ghost Inspector, Cucumber, GXtest, entre otras. A continuación dejamos una breve reseña sobre estas.

• Selenium: Es una herramienta open-source, que tiene una gran aceptación en todo el mundo para testear aplicaciones web en diferentes navegadores y plataformas.
• Appium: Es un framework open-source basado en Selenium, con el cual se pueden automatizar pruebas principalmente en dispositivos móviles para iOS y Android.
• Ghost Inspector: Lo más destacable de esta herramienta es que nos permite automatizar sin saber de programación, siendo muy recomendable para comenzar en la automatización dada su facilidad de uso. Por otro lado, esta herramienta es comercial y sólo permite 100 ejecuciones gratuitas por mes.
• Cucumber: Esta herramienta se enmarca dentro del enfoque BDD (Behavior Driven Development) que puedes leer más en este post. Cucumber tiene como principal ventaja la facilidad de uso, ya que es muy intuitiva, proporcionando una gran variedad de características y además es open-source.
• GXtest: Es una herramienta que permite la automatización en aplicaciones desarrolladas con Genexus de forma sencilla, siendo la única en su tipo. Además nos brinda la posibilidad de integrar las pruebas en un modelo de CI/CD.

Se hace importante destacar que no hay mejores herramientas para todos los casos. Sí podemos elegir entre aquellas que nos ofrezcan mayor flexibilidad, aunque siempre va a depender de la aplicación que se tenga bajo prueba y los criterios por los cuales se tomen las decisiones.

Conclusiones

En general podemos encontrar diferentes formas de guiarnos para automatizar, pero lo más importante es contar con un propósito y objetivo bien definidos. El contexto de la aplicación bajo prueba no es un detalle menor y debemos saber que no todo es automatizable, ya que el retorno de la inversión viene de la mano de un buen análisis de viabilidad.

De todas formas, si se llega a la automatización es muy recomendable que se haga a todo nivel y con mayor esfuerzo en los niveles más bajos, como lo pueden ser los tests unitarios y de API, y no solo a nivel de UI.

Teniendo en cuenta lo anterior, vamos a poder prevenir una mayor cantidad de bugs y acompañar al “testing manual”, que necesitan de la habilidad de los testers, y así evitar también la carga excesiva de tareas repetitivas que pueden ser programadas.

Referencias

Te dejamos algunas referencias más para que puedas profundizar en algunos de estos temas.

• A Context-Driven Approach to Automation in Testing – James Bach and Michael Bolton
• How to Choose the Best Automation Testing Tool (A Complete Guide) – Software Testing Help
• Common Myths of Test Automation – Amir Ghahrai
• A Complete Introduction to Functional Test Automation – Federico Toledo
• How to Select Best Automation Testing Tool – Guru99