¿Sabes que usos son los más adecuados para Gherkin y BDD?

A quien no conozca Gherkin, le podemos decir que es uno de los estándar para realizar pruebas escritas con un lenguaje muy sencillo y fácil de entender. Está basado en técnicas de BDD y se agrupa en:

•    Estado inicial: Nos preguntamos ¿Dónde?
•    Acción: Nos preguntamos ¿Cuándo?
•    Resultado esperado: Nos preguntamos ¿Entonces?

Toda esta información está agrupada en Escenarios. Este es un paso muy rápido sobre de que trata este lenguaje, de cara a hacerse una idea de lo que podemos llegar a hacer con él.

Cucumber, como herramienta, que está basada en Gherkin, tiene una muy buena perspectiva en una serie de situaciones, donde su utilización está más que recomendada:

•    Al dar de alta nuevas historias de usuario y sus criterios de aceptación, si utilizamos este tipo de lenguaje, podemos acordar con producto y desarrollo una serie de escenarios que sean válidos, completos y automatizables en un siguiente paso.

•    En algunas ocasiones, este tipo de lenguaje nos hará entender los motivos comerciales por los cuales se va a realizar o se ha realizado una funcionalidad en concreto. Es algo muy sencillo de entender, de llevar a la práctica y de trabajar para todos los perfiles que estén involucrados en el proyecto.

•    Es una manera muy sencilla de trazar los requisitos al código y a su vez a las pruebas realizadas, por lo tanto, podemos decir que estamos trabajando bajo una documentación viva que está actualizada en todo momento.

En ocasiones, tenemos que enfocar nuestras pruebas en el API y si ya tenemos Cucumber o alguna herramienta basada en Gherkin funcionando, que mejor que utilizarla para ello, algo que no es del todo recomendable.

Al realizar una prueba en el API, habitualmente llamamos a una URL y bajo una serie de parámetros, esperamos un resultado esperado positivo o negativo. En gran medida, no es de vital importancia como lleguemos a llamar a esa URL con esos parámetros, para ello hay herramientas como Postman que nos pueden ayudar a ello, pero en este caso, nos enfocamos en Gherkin.

En el caso de este tipo de pruebas, no es necesaria la filosofía de Gherkin con ese lenguaje natural ya que no aplica en la llamada a una URL que nos aporta un resultado. Si lo pensamos fríamente, no es relevante el manejar las preguntas expuestas más arriba para saber el resultado de una prueba de este tipo.

Cuando realizamos pruebas en un API, podemos tener dos objetivos principales, uno es la cobertura y otro es la funcionalidad (cosa que no debería de ser una prueba en un API).

Si por ejemplo, mandamos un dato vacio a un campo obligatorio, esperaremos un error que nos diga que hay que rellenar el campo, por lo tanto, no es necesario la realización de las preguntas: donde, cuando y entonces que usaremos en Gherkin.

Si estamos utilizando BDD para realizar nuestras pruebas, no solemos enfocarnos en una tecnología en concreto, si no más bien en la funcionalidad. Veamos algunos problemas típicos que podemos encontrarnos:

•    Si nos enfocamos en tecnología, esta puede cambiar a menudo, cosa que nos romperá las pruebas. Pero si nos enfocamos en la funcionalidad, las pruebas, seguramente no cambien con tanta frecuencia y el mantenimiento será menor.

•    Al escribir pruebas con Gherkin, solemos tratar el lenguaje de una manera demasiado prosaica, cosa que hace que sea accesible para todos, pero pierde el punto técnico, por lo tanto, debemos de enfocarnos a crear un tipo de lenguaje que ayude a que los desarrolladores entiendan las razones comerciales o de negocio de la funcionalidad que van a desarrollar.

•    En relación a las pruebas unitarias, las pruebas basadas en Gherkin, son más complejas de cerrar, ya que suelen llevar el estado entre métodos con variables, los IDE tienen una capacidad menor de depuración y en algunas ocasiones el trasladar ese lenguaje sencillo a código, es un poco complicado (a veces, juega en contra el como se entiende la frase en concreto).

Por último, diremos que Gherkin es un marco BDD integral, por lo que se debe de utilizar siempre en entornos de este tipo. En el caso de las pruebas API que hablábamos anteriormente, no tiene sentido que se realicen con este lenguaje, ya que se deben de orientar más a la solución técnica, en comparación con que al realizar BDD de este modo, nos enfocaremos más en funcionalidades de negocio.

Esperamos que os hayamos ayudado a tener una idea más clara de donde utilizar Gherkin y donde no para que sea realmente eficiente y su uso sea el adecuado, sin complicaros la vida en traducciones de lenguaje complejas a código y no invertir más tiempo de lo habitual.

Vuelve el Tester Funcional ¿o es que nunca se ha marchado?

Vuelve el tester funcional.

Efectivamente, has leído bien. En la época de la automatización, de los RPA, del DevOps, lo digo y lo reafirmo: el testing funcional ha vuelto con fuerza.

Puedo deciros, sin miedo a equivocarme, que jamás se fue. Éramos pocos los que seguíamos haciendo ese tipo de trabajo, pero ahora, es mas necesario que nunca.

Llevo meses viéndolo una y otras veces, empresas con unos procesos automáticos brutales, elaborados minuciosamente y con unas baterías dignas de los grandes, pero...con agujeros en producción. Errores graves y críticos que se cuelan y hacen que todo el esfuerzo invertido se quede en nada, además de que el cliente tenga una percepción negativa.

Os cuento lo que sucede.

Ahora todo es automatizar, hacer TDD, testing integrado en DevOps, incluso procesos completos con RPAs que se olvidan de las personas y manejan complejos proyectos de una manera ágil y especialmente rápida.

Viendo lo que se ha avanzado y lo que tienen algunas empresas montado, es digno de estudio y de, en algunos casos, hacerlos estándares y exportables de una empresa a otra.

Ahora bien, ¿que está sucediendo si estos procesos automáticos dejan estos agujeros en los productos que se elevan hasta el entorno de producción?

Pues, es tan sencillo como que la capa experta funcional se ha olvidado y no se cubren todos los caminos y se escapan. Mi experiencia, durante todo este tiempo, es que antes de hacer estos proyectos automáticos es que hay que hacer un análisis o un diagnóstico inicial, unido a un proyecto que realice una primera capa funcional en la que basarse todo.

Con este primer análisis, se realiza una batería completa, una documentación funcional y se crea la base total de lo que se tiene que automatizar con total garantía.

Además, aunque queramos realizar automatización de primeras en un proyecto, siempre, en la primera etapa, hay que apoyarse en, al menos, unas sesiones de pruebas exploratorias manuales que permitan cubrir, bajo el punto de vista de una persona, que todo está funcionando como debe de funcionar.

La realidad está ahí presente y no es la primera ni la segunda vez que encontramos esta situación y nos piden ayuda para averiguar que sucede con sus productos.

Volviendo a los orígenes.

La época de la automatización está presente y os digo que una persona dedicada a la calidad debe de saberla, casi por encima de cualquier otra cosa, pero también debe de aplicarse en formación procedimental, funcional y metodológica, ya que, si no, toda la fuerza que podamos aportar, acaba diluyéndose con estas situaciones inoportunas y engorrosas.

Ahora bien, nuestra intención no es decir que se tienen que hacer proyectos manuales, que la automatización es el demonio, ni nada por el estilo, si no que, es tan sencillo como que no se debe de olvidar el origen del testing y el conocimiento funcional o documental que hay que realizar, antes de nada.

El tester, debe de ser una persona metódica y concienzuda y muy enfocada a documentar todo, sobre todo, los casos de prueba (ya sea a nivel de código o en un documento). Estos casos de prueba deben de ser estudiados y extraídos de un documento funcional o requisitos que han sido entregados previamente.

Aquí, es donde se suele cojear, ya que en muchas ocasiones ni siquiera las personas que hacen esta batería de pruebas son tester, si no que son desarrolladores preocupados de la calidad o involucrados en equipos multidisciplinares.

Estos equipos, funcionan realmente bien en muchas ocasiones, pero como siempre se dice, no todo el mundo puede saber de todo y ser experto de ello, por lo tanto, una persona dedicada a una sola pata del amplio abanico del mundo tecnológico o informático, siempre aportará mucho más valor que una persona enfocada en varias cosas, que no puede llegar a ser experto de todo.

Desde aquí, hacemos un llamamiento a no olvidar ese conocimiento y labor funcional que puede salvarnos de más de un disgusto en nuestros proyectos.

Las cinco problemáticas principales que nos podemos encontrar al automatizar pruebas

No es la primera, ni la segunda vez que me pasa en un proyecto. Es escuchar "automatización" y aparece un brillo especial en los ojos de las personas responsables, tanto a nivel gestión como de la dirección.

Al principio de todo, la automatización se ve como un juguete nuevo que emociona a todo el mundo y plantea la posibilidad de que la carga de trabajo descienda y ayude a garantizar la calidad de manera sencilla. Después, poco a poco, la cosa suele ir enfriándose y las personas se van enfocando en otras prioridades o proyectos nuevos.

A nivel empresarial, solo hay un camino posible para que la automatización tenga éxito y todos los perfiles de gestión y dirección la vean como un valor importante: marcarse objetivos reales.

Además, también deben de plantearse objetivos como la actitud, aptitud y voluntad adecuada y correcta para que todas las capas de negocio empujen en el mismo sentido.

A lo largo de los años, he podido detectar una serie de problemas que se suelen repetir en muchos proyectos o empresas y que hacen que la automatización no llegue a buen puerto. En este caso, publicamos cinco ejemplos, que os pueden ayudar a no cometerlos y detectarlos de manera temprana, si sucediesen.

1. No se sabe que automatizar o por donde empezar.

La automatización no se trata de coger todos los casos de prueba manuales que tengamos y automatizarlos como si no hubiese mañana. Lo primero que hay que hacer, es saber que se va a automatizar, que funcionalidades deben de ser las primeras y que es lo más crítico.

El primer paso, que hay que tener claro, es comenzar a automatizar lo que ya está estable y que no tenga cambios (o los menos posibles), de esta manera, el ahorro de mantenimiento de las mismas será alto y podemos dedicarnos a otras tareas.

Además, lo ideal es seguir automatizando tareas repetitivas que puedan ahorrarnos aún más tiempo, enfocándonos en la realización de pruebas de humo o exploratorias.

2. Capacidad técnica del equipo

Otra problemática que nos podemos encontrar es el perfil técnico del equipo. Realizar un proyecto de automatización importante, necesita que se tenga cierta experiencia técnica. Para ello, lo ideal es capacitar a estas personas con formaciones, cursos e ir dejando tiempo para que practiquen. Esto es algo complicado, ya que no se suele tener ni presupuesto, ni tiempo para ello. 

Lo ideal, es el poder tener una persona experta en automatización y que se le permita tener un porcentaje de su tiempo para formar al resto del equipo con charlas y prácticas que puedan hacer crecer a todas las personas en ese sentido.

3. Falta de procesos adecuados para una automatización correcta

Este es uno de los problemas más comunes, tanto en automatización como en manual. No existen procesos, están mal definidos o son ineficientes. Otro punto, es que no se da una información integral del proceso, así que cada persona lo interpreta a su manera y acaba siendo un caos integral.

Cuanto más simple sea el proceso, más eficiente será y más sencillo tendremos el poder mostrarlo y formar a las personas del equipo.

Un buen proceso de automatización debe de seguir una premisa muy importante, que es la de crear tareas independientes que vayan automatizándose progresivamente, como si fuesen historias de usuario. Esto hará que tengamos un backlog completo que podemos priorizar y administrar adecuadamente.

4. Marcarse objetivos adecuados

Lo primero que se suele hacer, en papel, es el de montar un marco de automatización adecuado, integrado con el ciclo de integración continua, que sea realmente mantenible y se ejecute constantemente y de manera estable.

Esto, cuando lo pintamos, suele funcionar estupendamente. Ahora bien, para llegar a llevarlo a cabo, es necesario un nivel de madurez que no se suele encontrar rápidamente.

Cuando comenzamos un proyecto de automatización, tenemos que hacer algo sencillo, con una inversión, un tiempo y un coste moderados que permita ser todo lo sostenible que se debe de ser.

Debemos de identificar varias funcionalidades estables y automatizarlas, tal y como hemos comentado anteriormente. Una vez que tengamos eso, hay que hacer una ligera retrospectiva que nos de información de lo que ha ido mal y lo que ha salido bien, esto nos ayudará a que todo el resto de pruebas que vayamos automatizando no vengan implícitas con los mismos errores y podamos poner en práctica las cosas buenas que hemos realizado para ser eficiente y rápido.

5. Dificultad en verificar funcionalidades de manera automática

A menudo, nos encontramos con aplicaciones complejas y que no son fácilmente automatizables, ya sea por su arquitectura o por componentes que no se capturan adecuadamente por las herramientas de pruebas.

Para ello, debemos de crear un hilo conductor entre el equipo de desarrollo y las personas que automatizarán la plataforma para acordar que los nuevos desarrollos puedan realizarse de una manera más cómoda para poder realizar este tipo de pruebas o incluso, que las personas de desarrollo, puedan ayudar a encontrar una manera de automatizar los componentes que han construido ellos mismos.

También, debemos de hacer un estudio entre diferentes herramientas de automatización y comprobar cual es la que mejor encaja en nuestras necesidades y que sea la más sencilla de cara a invertir el menor tiempo y esfuerzo para llevar a cabo este tipo de tareas.

Estos cinco ejemplos de posibles problemas que podemos encontrarnos a la hora de automatizar, pueden llegar a ser solventados con las pautas que comentamos, pero, sobre todo, lo más importante, es usar el sentido común, no elevar las expectativas demasiado alto y, sobre todo, hacer las cosas paso a paso y con calma, meditando cada acción y no llevando al límite al equipo en relación al tiempo y al esfuerzo, pudiéndolos quemar si necesidad. Apostemos por una automatización sostenible y progresiva en nuestros proyectos.

9 trucos de Selenium que te ayudarán en tus pruebas automáticas

Si trabajas en QA y más concretamente en automatización de pruebas, tienes que conocer Selenium, ya sea de oídas o porque alguien lo ha utilizado (si es que no eres tu mism@).
 

Esta herramienta, a día de hoy, es una de las más usadas del mercado, quizá siendo la que más y con WebDriver, la facilidad y la compatibilidad con todos los navegadores, es más que espectacular.

Además, por si fuera poco, Selenium es una de las herramientas con más compatibilidad en lenguajes de programación, ya sea Python, Ruby, Java, PHP, .NET y muchos más.

No hace mucho, utilizamos Selenium junto con Python en un proyecto de gran envergadura y gracias al trabajo diario con grandes expertos en esta herramienta, pudimos detectar una serie de buenas prácticas, trucos o tareas que se pueden ejecutar y facilitar mucho la vida a personas que quieren comenzar a usar Selenium o ya llevan años haciéndolo y pueden mejorar sus procesos.

1.     Abrir una página web en una pestaña nueva con Selenium

En algunas ocasiones, nos encontramos con la necesidad de abrir páginas web en navegadores y, más concretamente, en pestañas nuevas. Para ello, utilizaremos execute_script.

Por ejemplo, usaremos un código tipo de este modo:

from selenium import webdriver

from selenium.webdriver.common.keys import Keys

from time import sleep

  

driver = webdriver.Firefox()

driver.get("http://www.google.com/")

  

driver.implicitly_wait(10)

  

#abrimos la nueva pestaña

driver.execute_script("window.open('https://www.qalovers.com', 'new tab')")

  

sleep(5)

driver.quit()

2.     Hacer Zoom con Selenium

En algunas ocasiones, debemos de hacer zoom (alejando y acercando) en una imagen o documento en concreto (ya sea para pulsar algo o para observar un texto más pequeño, por ejemplo). Para ello, usaremos la propiedad de transformación que permite hacer cualquier movimiento rotatorio o acercar y alejar la pantalla. En Firefox se puede usar MozTransform, tal y como vemos en el ejemplo:

from selenium import webdriver

from time import sleep

  

driver = webdriver.Firefox()

driver.get("https://www.qalovers.com/")

timeout = 10

  

''' Zoom en un 350% '''

driver.execute_script('document.body.style.MozTransform = "scale(2.0)";')

driver.execute_script('document.body.style.MozTransformOrigin = "0 0";')

  

sleep(10)

  

''' Zoom en un 100% '''

  

driver.execute_script('document.body.style.MozTransform = "scale(1.0)";')

driver.execute_script('document.body.style.MozTransformOrigin = "0 0";')

  

''' Añadimos un sleep para ralentizar la acción '''

sleep(10)

  

driver.quit()

3.     Trabajar con varios navegadores a la vez, para realizar pruebas de compatibilidad

Cuando realizamos pruebas de compatibilidad, tenemos que saltar de un navegador a otro o quizá probar algún tipo de pauta en diferentes navegadores para comprobar que ocurre o si en todos funciona exactamente igual. Para ello, Selenium nos permite identificar e incorporar, de manera selectiva, la utilización de diferentes navegadores o ejecutar código en cada uno de ellos, al mismo tiempo. Lo ideal es utilizar pytest, tal y como se muestra en el ejemplo:

# La importación de los módulos es obligatoria para una ejecutar el código de manera correcta

  

import pytest

from selenium import webdriver

from selenium.webdriver.chrome.options import Options

from selenium.webdriver.common.keys import Keys

from time import sleep

  

@pytest.fixture(params=["chrome", "firefox"],scope="class")

def driver_init(request):

    if request.param == "chrome":

    if request.param == "firefox":

    yield

    web_driver.close()

4.     Actualizar los navegadores mientras se realiza algún tipo de prueba

Tanto cuando realizamos pruebas manuales como automáticas, una de las acciones más repetidas, suele ser la de refrescar el navegador o página que estamos probando, ya sea para comprobar que el cambio se ha realizado correctamente o simplemente para volver a limpiar la información y comenzar de nuevo.

En Selenium, podemos realizar este refresco con driver.refresh()

from selenium import webdriver

  

driver = webdriver.Firefox()

driver.get("https://www.qalovers.com/")

driver.refresh() 

5.     Extraer datos tras ejecutar código de JS

En ocasiones, al ejecutar un código JS, debemos de capturar el resultado o extraer algún tipo de dato del mismo. Para ello, podemos utilizar “Return” y obtener el resultado del código. Lo podemos ver en un ejemplo sencillo:

from selenium import webdriver

from time import sleep

  

driver = webdriver.Firefox()

driver.get("https://www.qalovers.com")

  

driver.execute_script("document.getElementsByClassName('home-cta')[0].click()")

     

result = driver.execute_script("return 0")

print(result)

  

sleep(10)

  

driver.close() 

6.     Cerrar pestañas del navegador, cambiando el foco de una a otra

Al realizar algún tipo de prueba, nos podemos encontrar con la necesidad de cerrar pestañas del navegador sin tener que cerrarlo completamente (o si). Para ello, podemos usar driver.close()

from selenium import webdriver

import time

  

driver = webdriver.Firefox()

driver.get('https://www.google.com')

# Abrimos una nueva pestaña

driver.execute_script("window.open('');")

time.sleep(5)

# Cambiamos el foco a la nueva pestaña

driver.switch_to.window(driver.window_handles[1])

driver.get("https://qalovers.com")

time.sleep(5)

# Ahora, cerramos la pestaña actual

driver.close()

time.sleep(5)

# Volvemos a cambiar el foco a la primera pestaña

driver.switch_to.window(driver.window_handles[0])

driver.get("https://www.qaglobal.es")

time.sleep(5)

# Cerramos la última pestaña, y por lo tanto, cerraremos el navegador.

#driver.close()

7.     Hacer scroll en el navegador

Otro movimiento típico que se suele realizar cuando estamos haciendo pruebas, es el scroll. Para ello, Selenium nos ayuda con el código window.scrollTo().

Lo que hemos realizado, es un ejemplo de como descender hasta el final de la página:

from selenium import webdriver

from time import sleep

  

driver = webdriver.Firefox()

driver.get("https://www.qalovers.com/")

timeout = 10

  

''' Hacemos scroll complete en toda la página '''

driver.execute_script("window.scrollTo(0, document.body.scrollHeight);")

  

sleep(10)

  

driver.quit()

8.     Guardar un recorte de la pantalla

A la hora de dar de alta un defecto o el poder comprobar algún tipo de situación, guardando una evidencia, podemos Pillow desde Selenium.

El primer paso es instalarlo con pip installa pillow.

Básicamente, lo que haremos, será el capturar toda la pantalla y con Pillow, capturar la sección que queramos.

from selenium import webdriver

''' Instalamos pillow '''

from PIL import Image

from io import BytesIO

  

driver = webdriver.Firefox()

driver.get('http://google.com/')

  

# Buscamos el logotipo de Google

element = driver.find_element_by_id('hplogo')

image_location = element.location

size = element.size

  

png = driver.get_screenshot_as_png()

  

''' La captura es correcta, por lo que salimos del navegador '''

driver.quit()

  

''' Abrimos la imagen con la librería de PIL '''

crop_image = Image.open(BytesIO(png))

  

''' Extraemos las coordenadas (x,y) '''

  

left = image_location['x']

top = image_location['y']

right = image_location['x'] + size['width']

bottom = image_location['y'] + size['height']

  

crop_image = crop_image.crop((left, top, right, bottom))

crop_image.save('captura-logotipo.png')

9.     Capturar el código fuente HTML de una página web

En ocasiones, una prueba básica que podemos hacer es capturar el HTML de una página web para buscar algo en concreto o comprobar que una acción se esté realizando correctamente. Para ello utilizamos la propiedad innerHTML.

En el siguiente ejemplo lo comprobamos:

from selenium import webdriver

from selenium.webdriver.chrome.options import Options

from selenium.webdriver.common.keys import Keys

from time import sleep

import io

  

driver = webdriver.Firefox()

driver.get("https://www.qalovers.com")

  

elem = driver.find_element_by_xpath("//*")

source_code = elem.get_attribute("innerHTML")

  

filename = open('qalovers_codigo_fuente.html', 'w')

filename.write(source_code)

filename.close()

     

sleep(10)

  

driver.close()

Básicamente, lo que hemos realizado es recopilar una serie de acciones que utilizamos y que pensamos que son válidas y extrapolables a cualquier tipo de proyecto o situación.

Esperemos que esto os pueda ayudar y solventar dudas que os surjan en vuestros proyectos o pruebas de concepto que hacéis en casa, facilitándoos la vida un poquito más.