Pautas útiles para reconocer la viabilidad de automatizar las pruebas de software, según el contexto del proyecto.

Gracias a la automatización de pruebas funcionales, se puede lograr un Importante ahorro en energía, tiempo y costos.

“Automaticemos las pruebas tanto como sea posible”. Eso siempre suena como una buena idea, ¿verdad? Es la forma en que va el mundo en general, ¿no? El ejercicio de automatizar pruebas de software puede ser un gran elemento potenciador de la productividad, pero solo en ciertos contextos.

En esta entrada, presentamos junto a Alejandro Berardinelli, QE lead en Abstracta, un enfoque para la automatización de pruebas, con el objetivo de reconocer su viabilidad de acuerdo al contexto del proyecto.

Primer paso: identificar el contexto del proyecto

Es muy útil para un tester comprender qué es la automatización y tener claridad de cuando algo es automatizable. Asimismo, debe tener en cuenta cómo puede optimizar su trabajo, ya sea colaborando con otros colegas, otros desarrolladores o animándose a probar una herramienta de automatización.

Abordaremos algunos conceptos que son fundamentales cuando aún no tiene experiencia con la automatización. También evaluaremos su importancia y beneficios, en relación con las pruebas manuales.

¿Por qué automatizar pruebas de software?

Históricamente, la automatización surgió para reducir el esfuerzo humano requerido en actividades que podrían ser replicadas por un sistema o máquina programable. Al automatizar pruebas de software se persigue el objetivo de simplificar el trabajo dispendioso, repetitivo o complejo, haciéndolo efectivo y más productivo.

De esta manera, es posible ahorrar energía, tiempo y costos, al tiempo que libera a las personas para que se concentren en otras tareas.

Automatización de esfuerzos manuales

En el desarrollo de software, esta práctica puede abordarse de la misma manera mediante la automatización de ciertos esfuerzos que se realizan manualmente. Los pasos seguidos por las personas se traducen en secuencias de comandos repetibles, para que puedan concentrar su energía en otras tareas específicas que proporcionan un mayor valor y reducen los tiempos de ejecución.

En algunos casos, la automatización nos permite realizar pruebas que un humano no podría, especialmente teniendo en cuenta la limitación del número de ejecuciones que podemos hacer en un determinado período de tiempo.

¿Cuándo algo se considera automatizable?

Esta suele ser una de las preguntas más comunes entre los testers. Y es que saber cuándo automatizar pruebas de software implica evaluar la inversión potencial, el enfoque, los beneficios y lo que es más importante, el conocimiento actual del proceso manual.

En primer lugar, tenemos que entender completamente y convertirnos en expertos en el proceso manual, y solo entonces es posible automatizar.

El conocimiento completo del proceso manual es el pilar para saber cuándo algo es automatizable, lo que implica que las pruebas manuales no son completamente sustituibles. (Frecuentemente hay un debate sobre la muerte inminente de las pruebas manuales, ¡simplemente no pueden desaparecer!)

Mitos de la automatización

Automatizar pruebas de software tiene sus ventajas y desventajas. Depende del proyecto, el tiempo, el costo, la calidad y la metodología.

Basado en lo anterior, otro aspecto importante es que más allá de automatizar o no automatizar, se debe comprender el contexto.

Además, hay que considerar que todo lo que hace se basa en cumplir los objetivos de la mejor manera posible, seleccionando y aplicando los métodos, herramientas y habilidades apropiadas.

Entre los mitos comunes sobre la automatización de pruebas encontramos:

  • Es posible automatizar todo.
  • La automatización siempre conduce a una mejor calidad de software.
  • Las pruebas automatizadas son mejores que las manuales.
  • La automatización trae un rápido retorno de la inversión.

Desde luego, pueden haber ocasiones en que uno de estos mitos sea realmente cierto, pero eso sería una excepción a la regla.

Según Context-Driven Testing School, los siguientes siete principios ayudan a comprender el objetivo del testing, ya sea manual o automatizado:

  • 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 juntas, son la parte más importante del contexto de cualquier proyecto.
  • Los proyectos no son estáticos y a menudo toman caminos impredecibles.
  • El producto es una solución. Si el problema no se resuelve, el producto no funcionará.
  • El testing de software es un proceso intelectual desafiante.
  • Solo a través del juicio y la habilidad, practicados cooperativamente durante todo el proyecto, podremos hacer las cosas correctas en el momento adecuado para probar nuestros productos de manera efectiva.

Estos siete principios fueron propuestos por Cem Kaner, James Bach y Brett Pettichord en su libro “Lecciones aprendidas en Software Testing: un enfoque basado en el contexto“.

Este recurso ayuda a comprender la importancia de la capacidad de adaptarse, de acuerdo con la situación actual del proyecto.

Manual vs. Automatizado

Al comenzar, es posible que queramos automatizar todo, pero el costo de desarrollar y mantener los scripts para las pruebas automatizadas no es algo que deba tomarse a la ligera.

Cuando un proyecto apuesta por automatizar pruebas de software, idealmente debería tener una base sólida comenzando con los casos de prueba unitarios, evitando tantos errores como sea posible.

Esta automatización debe contar con una retroalimentación inmediata y continuar sucesivamente a las diferentes capas. De esta forma, las pruebas manuales y exploratorias son más valiosas en el nivel de la interfaz de usuario, centrándose en aquellas pruebas que no son posibles de automatizar.

Este concepto lo explica detalladamente la pirámide de automatización de pruebas de Mike Cohn:

Pirámide de Automatización de Pruebas Funcionales de Mike Cohn - Abstracta Chile

A la izquierda, vemos cómo se realiza comúnmente la automatización y a la derecha, podemos ver la forma ideal, donde las pruebas unitarias tienen el mayor peso en la pirámide.

Pruebas Automatizadas vs. Pruebas Manuales

Aunque existen diferencias entre pruebas automatizadas y pruebas manuales, no son mutuamente excluyentes. Más bien se consideran tareas complementarias en la búsqueda de una mejor calidad de software.

Si pensamos en el retorno de la inversión de las pruebas, probar una nueva funcionalidad manualmente le permite conocer más sobre la aplicación, a bajo costo y rápidamente.

A medida que se adquiere conocimiento, el inventario de pruebas aumenta. En consecuencia, el costo también sube para las pruebas manuales.

Por otro lado, la automatización tiene un costo inicial más alto que disminuye a medida que avanza. Este comportamiento se puede ver a continuación:

Diagrama que representa la relación entre el tiempo y costo de pruebas manuales y automatizadas
Fuente: QATest Lab Blog

Analizando lo anterior, vemos que la automatización tiene una gran inversión inicial hasta el “punto de quiebre” donde comenzamos a ver el impacto positivo que genera en los costos a largo plazo.

En contraste con las pruebas manuales, para lo cual podemos estimar que ambas actividades de pruebas son totalmente compatibles, generando beneficios a corto y largo plazo.

¿Qué es la automatización de casos de prueba?

Ahora que somos conscientes de la importancia y los beneficios de la automatización, tenemos que identificar los casos que podemos automatizar.

Para esto, debemos tener en cuenta el objetivo que se persigue y a qué nivel, como vimos en la pirámide de Cohn.

Objetivos de la automatización de casos

Lo primero que buscamos es apuntar siempre a un mayor nivel de calidad de software y analizar si la automatización “encaja” dentro del proyecto. Para responder a este interrogante, es aconsejable realizar un análisis de viabilidad en relación con los objetivos.

A continuación, exponemos algunos escenarios en los que probablemente tenga sentido automatizar:

  • Hay una deuda técnica que eliminar.
  • Las pruebas de regresión requieren mucho tiempo.
  • El proyecto es altamente complejo y de largo plazo.

¿Cuáles casos de prueba son automatizables?

Como hemos visto, no todo es automatizable en contexto. Por tanto, es muy importante determinar qué casos son adecuados para nuestro propósito.

Si pensamos desde la perspectiva del desarrollador y a nivel de código, las pruebas unitarias son las más sencillas para hacer un script.

Por el lado del tester, generalmente se trabaja en la automatización de los casos de regresión a nivel de UI y API, pensando primero en los flujos más críticos y complejos.

Ahora bien, en las siguientes líneas detallamos los casos de prueba que son automatizables:

Pruebas de regresión

Dada la situación en la que ya tenemos un conjunto de pruebas definido que debe ejecutarse periódicamente después de cada lanzamiento del producto, el esfuerzo para ejecutarlos manualmente se vuelve repetitivo. Además de quitarle tiempo a otras tareas que no son automatizables y donde podemos proporcionar más valor.

Estos casos de prueba de regresión son altamente automatizables, siendo particularmente convenientes integrarlos dentro de un modelo de integración y entrega continua.

Lo anterior, no solo agrega valor en términos de costos, también en el tiempo que se gana para realizar otras tareas, puesto que los scripts se pueden ejecutar sin supervisión, mientras se realizan otras actividades.

Pruebas basadas en el riesgo

Estos casos generalmente son acordados por las partes interesadas, donde se pone énfasis en verificar las funciones críticas y de alta prioridad que, si fallan, afectan en gran medida el modelo de negocio. Es por eso que este enfoque se llama “Pruebas basadas en el riesgo”.

Automatizar los casos que prueban estas funcionalidades puede ayudar a encontrar – casi inmediatamente después de cada lanzamiento – los incidentes en los que se deben tomar medidas rápidamente y se puede bloquear la producción de dicho lanzamiento.

Pruebas complejas y/o que consumen mucho tiempo

Puede haber casos en un proyecto que son complejos de reproducir manualmente, por lo que si lo llevamos a un script, será más fácil ejecutarlos de manera automatizada.

Si se trata de un formulario con muchos datos, quizás el tester sea más propenso a errores, especialmente si tiene que probar el mismo formulario con muchas variantes de datos.

En otras palabras, podemos reducir la probabilidad de error mediante la automatización.

Casos de prueba repetitivos

De la misma manera que las pruebas de regresión se convierten en una tarea repetitiva, podemos tener casos particulares en los que es conveniente dar 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 una cantidad de tiempo considerable y si también tenemos que repetirlo, se vuelve algo tedioso.

Sin embargo, al automatizar el flujo, podríamos parametrizar estos datos y así olvidarnos de tener que probar cada valor manualmente. Esto también se conoce como prueba basada en datos.

Básicamente, esto consiste en que una prueba automatizada se parametriza y se alimenta con datos de una fuente de datos, como un archivo o una base de datos.

Herramientas para automatizar Pruebas de Software?

Ahora que sabemos qué automatizar, podemos pasar a seleccionar la herramienta que vamos a utilizar. Esta actividad puede ser una de las más complejas de analizar inicialmente, dado el número de herramientas disponibles.

No obstante, la decisión tendrá que considerar el proyecto, el presupuesto, el conocimiento y la experiencia de los involucrados.

Herramientas open source comerciales y personalizadas

Primero, las herramientas que tenemos a nuestro alcance varían en sus limitaciones y posibilidades. Por lo que para seleccionar la herramienta correcta para automatizar una prueba, hay que tener claridad de los requisitos que deben cumplirse para continuar el análisis de costo-beneficio de su uso.

En Abstracta tenemos una amplia variedad de herramientas que seleccionamos de acuerdo con el contexto del proyecto. Sin embargo, nuestras herramientas de automatización de pruebas favoritas son las que detallamos a continuación:

Selenium

Selenium es una herramienta de código abierto, ampliamente aceptada en todo el mundo para probar aplicaciones web en diferentes navegadores y plataformas.

→ Conozca más sobre la herramienta Selenium aquí.

Appium

Appium es otra herramienta open source basada en Selenium que se puede emplear para automatizar las pruebas, principalmente en dispositivos móviles para iOS y Android.

→ Conozca más sobre la herramienta Appium aquí.

Cucumber

Cucumber es parte del enfoque BDD (Behavior Driven Development) y su principal ventaja es la facilidad de uso, ya que es muy intuitiva.

También proporciona una amplia variedad de características y similar a las anteriores, es una herramienta open source.

→ Conozca más sobre la herramienta Cucumber aquí.

Ghost Inspector

Lo más interesante de Ghost Inspector es que nos permite automatizar sin saber codificar, lo que la convierte en una herramienta ideal para principiantes.

Ciertamente, esta herramienta solo permite 100 ejecuciones gratuitas por mes. Revise nuestra reseña de Ghost Inspector aquí.

→ Conozca más sobre la herramienta Ghost Inspector aquí.

GXtest

En Abstracta desarrollamos GXtest para permitir la automatización de aplicaciones desarrolladas con GeneXus de una manera simple (la única de su tipo). Y eso no es todo, también permite integrar pruebas en un modelo CI/CD.

→ Ver detalles del caso de éxito de GXtest aquí.

Es importante tener en cuenta que pese a que no hay mejores herramientas para todos los casos, podemos elegir entre aquellas que nos ofrecen más flexibilidad.

Aunque esto siempre dependerá de la aplicación bajo prueba y los criterios de toma de decisiones.

Importancia de optimizar el tiempo con automatización

En general, podemos encontrar diferentes formas de guiar nuestros esfuerzos para automatizar una prueba. Pero lo más importante es tener un propósito y un objetivo bien definidos.

El contexto de la aplicación bajo prueba no es un detalle menor y deberíamos saber que no todo es automatizable. Por consiguiente, el Retorno sobre la Inversión (RSI) proviene del trabajo de un buen análisis de factibilidad.

En cualquier caso, es recomendable que la automatización se realice en todos los niveles – con un mayor esfuerzo en los niveles más bajos – como las pruebas unitarias y de API, y no solo a nivel de la interfaz de usuario.

Teniendo en cuenta lo anterior, podremos evitar un mayor número de errores y acompañar la prueba manual, que necesita la facultad de los testers. De esta manera, se evita la carga excesiva de tareas repetitivas que se pueden programar.

¿Bsuca iniciarse en la automatización o quiere profundizar sus conocimientos? ¡Descargue nuestro último e-book! 👇😉

Introducción a la Automatización de Pruebas Funcionales

Descargue gratis Introducción a la automatización de pruebas funcionales, recurso útil con todo lo que necesita considerar para hacer que la automatización sea realmente efectiva.

E-book con una completa introducción a la automatización de pruebas funcionales

En nuestro último e-book de 50 páginas podrá descubrir:

  • Valor comercial y de TI en la automatización de pruebas, así como su RSI potencial.
  • Qué, dónde, cómo y cuándo la automatización tiene más sentido.
  • Prácticas y enfoques líderes en la industria que brindan una máxima efectividad.

¿Quiere obtener más información sobre nuestro servicio de automatización de pruebas? Agende aquí una consultoría gratuita y personalizada de 30 minutos con nuestros expertos, y conozca cómo nuestro equipo de ingenieros de calidad pueden trabajar codo a codo con usted.


Más recursos para automatizar pruebas de software

Para profundizar en la automatización y saber cuándo automatizar una prueba, compartimos otros excelentes recursos:

Un enfoque basado en el contexto para la automatización | James Bach y Michael Bolton.

Automatización de pruebas: ¿Cómo elegir la mejor herramienta? | Software Testing Help.

Mitos comunes de la automatización| Amir Ghahrai.

Otros artículos de automatización de pruebas | Abstracta US