spinner

El gran dilema del QA: ¿Automatización o testing manual?

La correcta elección de las metodologías y las herramientas de automatización nos ayudarán a que todas las tareas del proceso de QA sean menos laboriosas. Una de las infraestructuras más destacadas es Robot Framework, basado en una automatización de código abierto.

Muchas veces nos preguntamos qué es QA y para qué sirve. QA es el acrónimo de Quality Assurance, garantía de calidad. Es una cultura como DevOps, es decir, todo lo que sea necesario para cumplir con la garantía y calidad que debe tener el producto. Cuando encontramos un entregable de calidad, tendemos a mantenerlo, y esa es una de las mayores apuestas de BBVA Next Technologies y de ahí la importancia de esta metodología en el Radar de Tecnología, la guía que marca nuestra estrategia tecnológica.

La norma internacional ISO/IEC 12207 Information Technology/Software Lifecycle Processes, que es el estándar para los procesos de ciclo de vida del software, define QA como un proceso que:«…proporciona la garantía adecuada para que los productos y procesos de software en el ciclo de vida del proyecto se ajusten a sus requisitos específicos y a los planes establecidos. Para ser imparcial, la garantía de calidad debe tener libertad de organización y autoridad frente a las personas directamente responsables del desarrollo del producto de software o de la ejecución del proceso en el proyecto».

Uno de los principales problemas al que nos enfrentamos es que la calidad se da por hecha. Nada más lejos de la realidad. QA proporciona una serie de metodologías, herramientas, y mecanismos que nos ayudarán a no caer en esta trampa o en la de “no hay tiempo para calidad”. En definitiva, para asegurar un producto y un proceso de calidad, adoptar esta cultura es nuestro objetivo fundamental.

Automatizar… ¿qué es eso?

Últimamente se le da mucha importancia a la palabra automatizar sin pararse a pensar en lo que conlleva, tanto beneficios como trabajo a corto y largo plazo. No debemos olvidar que automatizar, como cualquier proceso de desarrollo de software, lleva tiempo y esfuerzo y un mantenimiento a medida que nuestro producto cambie. Esto es importante, ya que la elección de la metodología y de las herramientas de automatización nos van a ayudar a que estas tareas sean más o menos laboriosas.

Cuando queremos ser ágiles y sacar nuestros productos al mercado lo más rápido posible sabemos que tenemos que mejorar la calidad de nuestros procesos, de nuestro software y de nuestros equipos. Tenemos que poner foco en detectar nuestros errores y optimizar nuestras pruebas y nuestro rendimiento, una mejora continua que no podemos descuidar.

Es posible que no sepamos enfrentarnos en nuestro día a día a algunas cuestiones como si pensáramos que automatizar tiene como final eliminar completamente el testing manual. Tenemos que tener en cuenta que el testing en un caso de prueba comienza siendo manual y finalmente será automatizado. Tampoco debemos quedarnos con la idea equivocada de que el testing es únicamente lo que nos va a asegurar la calidad del software.

Existen diferentes niveles de pruebas y es interesante conocer en qué medida debemos automatizarlas. En este punto es importante hablar de la pirámide de Cohn que representa el ideal de cómo deberían estructurarse los distintos niveles de test. En esta imagen se muestran estos niveles con la integración de la metodología Agile según el libro de Mike Cohn «Succeeding with Agile«.

Lo ideal serían muchos tests unitarios automáticos como punto principal para poder detectar fallos, después los test a nivel de APIs, servicios… y el menor grueso quedaría para las interfaces gráficas, y por último, estaría un nivel más estable de pruebas automáticas.

Por el contrario, una mala estrategia de automatización nos lleva a lo que se conoce como el «cono de helado«. Esto ocurre cuando perdemos el foco y no estamos automatizando ni en el nivel ni en la medida adecuada.

QA

Tenemos que hablar del anti-pattern que aún sigue siendo recurrente en gran cantidad de proyectos. Cuando se realizan pruebas de software se suele usar la interfaz de usuario, ya que de manera intuitiva, parece el método más sencillo. Las pruebas de mayor nivel son más escasas, como las unitarias, que son implementadas por los desarrolladores a nivel de código. Representamos entonces las pruebas de mayor dificultad en la parte superior del «cono de helado» puesto que la serían las más costosas de automatizar perdiendo el enfoque de Agile.

En una buena estrategia de automatización de pruebas no solo tenemos que automatizar, sino parametrizar tests, gestionar datos, sistemas de logs, crear buenos frameworks de automatización, crear buenas infraestructuras, generar buenos reportes de información, etc.

Por otro lado, es interesante que establezcamos una distinción entre la automatización de pruebas y las pruebas automatizadas. La prueba automatizada es un check manual codificado. Existen muchas herramientas para ello como Postman, Jmeter o Selenium, pero podríamos sintetizar diciendo que en la prueba automatizada se repiten los pasos que ejecutaría una persona para verificar un output concreto.

La automatización de pruebas implica que el proceso se tiene que automatizar, pensar en el producto, tener en cuenta las integraciones, que el set de pruebas se ejecute autónomamente sin necesidad de que haya intervención humana. Esto quiere decir que un equipo puede tener pruebas automatizadas ejecutadas localmente, pero no por ello tienen cubierto el objetivo de automatización de pruebas.

Ventajas y desventajas de la automatización

Como hemos visto, automatizar permite aumentar la capacidad productiva y ser más eficientes y ágiles en la respuesta al usuario. Algunas ventajas son:

  • Reducción del coste de la mano de obra.
  • Mayor homogeneidad.
  • Eliminación de los trabajos rutinarios.
  • Reducción de el tiempo empleado en procesar la información.
  • Fiabilidad técnica en procesos y en operación de equipos.
  • Ser competitivos frente al cliente.
  • Mejorar y optimizar la implementación del análisis, de las funciones y del diagnóstico.
  • Mejora de la calidad de producto

Algunas desventajas:

  • Lentitud y dificultad de adaptación a los cambios de un proceso ya automatizado para producir otros modelos diferentes.
  • Requiere especialización por parte del personal.
  • La inversión en equipos puede ser más costosa

Robot Framework, automatización de código abierto

La automatización en el desarrollo de software es muy importante para poder detectar fallos en las fases de implementación, en las pruebas de comportamiento, entornos, etc. Nos gustaría destacar Robot Framework como una de las infraestructuras más destacadas en la actualidad.

Esta tecnología tiene unas características que la convierten en una de las mejores opciones cuando estamos ante la automatización de testeo de hardware y software en desarrollo. Este framework se fundamenta en una automatización de código abierto, basado en librerías codificadas en Python. Es keyword-driven, esto quiere decir que se basa en palabras clave y tiene una sintaxis tabular, es decir, cross platform.

En foros como Robocon ya hace tiempo que se asocia el presente y el futuro de la RPA (Robotic Process Automation) con una sencilla frase: «If you can document it, you can automate it«. Esta frase va absolutamente de la mano con la calidad, y por supuesto, está totalmente conectada con la importancia de las historias de usuarios, de las definiciones, de los criterios de aceptación y todo lo que nos pueda a ayudar a reducir considerablemente el time to market.

También es importante destacar la diferencia entre RPA y la automatización de test. El primero tiene una orientación dirigida a usuario mientras que el segundo se dirige más a los desarrolladores.

¿Por qué recomendamos Robot Framework para testeo?

  • Tiene una instalación muy sencilla, usando los paquetes estándar de Python.
  • Al ser Open Source permite disfrutar de todas sus ventajas.
  • Tiene independencia de la aplicación a testear.
  • Proporciona una librería API para crear librerías de test propias y multitud de librerías para testear todo tipo de aplicaciones.
  • Incorpora una línea de comandos y ficheros de salida en formatos XML que luego se utilizan para construir ficheros de log en formato HTML. La información se muestra de una forma sencilla, precisa e intuitiva.
  • Los usuarios no necesitan lenguajes de programación para implementar tests y ejecutarlos.

En resumidas cuentas Robot es lo suficientemente fácil como para que una persona que no tenga o tenga pocas nociones de programación pueda automatizar sus test y a la vez es una gran herramienta para que un desarrollador pueda implementar nuevas funcionalidades.

Robot Framework tiene cuatro módulos:

  • Sistema bajo testeo: en donde se encuentran los sistemas físicos, aplicaciones, entornos, etc. Sería la parte más física.
  • Capa de Tests: con sus librerías, herramientas, etc, que conecta con la capa inferior mediante las interfaces del sistema y con la superior mediante una librería API de test.
  • Infraestructura de Robot Framework: Parsea los datos de testeo e interactúa con la capa inferior.
  • Datos de testeo.

Además un fichero estándar de Robot se compone de:

  • Settings: donde se documenta el fichero y se importan las librerías que se van a usar.
  • Variables: definimos las variables que vamos a utilizar.
  • Keywords: codificamos las keywords que van a comportar los testados.
  • Test cases: definimos la suite de test a partir de las keywords que hemos construido y de las librerías.

Brady Hill ya señalaba a Robot FW como una herramienta muy eficaz para su empresa puesto que 2 semanas de testing manual suponían 3 horas de testing automatizado. Robot FW influyó en su compañía hasta tal punto que hizo que los desarrolladores estuviesen totalmente involucrados en la calidad teniendo muy en cuenta el KISS principle (Keep It Simple Stupid): Construye — Prueba — Mide.

Miakel Siirtola también adoptó Robot FW para su empresa médica pasando de mejorar la automatización del 0% al 34% y resume una serie de consejos que son interesantes para tener en cuenta:

  • El QA es lo primero, sin olvidarnos que el proceso de calidad requiere tiempo.
  • Es importante considerar el proceso entero, no solo el test case (entorno, testing, documentación…).
  • Es importante tener una buena arquitectura.

Robot FW es una de las herramientas más valoradas junto a Selenium o Appium según estudios que se han llevado a cabo en diferentes países como España, Holanda, Finlandia, Rusia, Portugal, Estados Unidos o Brasil. También hay que destacar sus virtudes en otros ámbitos como el voluntariado tecnológico en donde puede llegar a ayudar a formar a mujeres en riesgo de exclusión social y lo usan para automatizar el testing, como hicieron en Finlandia (de donde es originario).

Checks Are Machine-Decidable; Tests Require Sapience

 

Imagen principal: Pexels

Autores:

Cristina Riveiro – Information & Knowlege Manager

Carlos Reigosa – Software QA Engineer

Las opiniones vertidas por el autor son enteramente suyas y no siempre representan la opinión de BBVA Next Technologies.

¿Quieres saber que más cosas hacemos en BBVA Next Technologies?

Utilizamos cookies propias y de terceros para mejorar nuestros servicios, brindarle una grata experiencia y mostrar a los usuarios publicidad relacionada con sus preferencias mediante el análisis de sus hábitos de navegación. Si continúa navegando por este sitio web, consideramos que acepta su uso. Puede cambiar la configuración u obtener más información accediendo a nuestra política de cookies aquí.