Guía para utilizar WebElementHighlighter

WebElementHighlighter es una librería python que nos permite resaltar WebElements de Selenium. La principal finalidad de esta librería es poder mostrar al tester que elementos de una página están fallando.

Sus funcionalidades actuales son:

• Hacer parpadear WebElements.
• Cambiar estilos como fondo y bordes de WebElements.

Instalación.

pip install webelement_highlighter

Ejemplo de uso.

from webelement_highlighter import WebElementHighlighter
from selenium import webdriver

driver = webdriver.Chrome()
driver.get("https://www.w3schools.com/js/default.asp")

wh = WebElementHighlighter(driver)

we = driver.find_element_by_id("topnavbtn_references")
wes = driver.find_elements_by_class_name("w3-col")

wh.make_it_blink(we)
wh.make_them_blink(wes, times=20)

wh.highlight_element(we)
wh.highlight_elements(wes, stop=True)

Nota.

Para ejecutar el ejemplo es necesario tener instalada la librería selenium.

Enlaces.

Repositorio: https://github.com/rtorres90/webelement_highlighter

Configuración de webdriver para manejar descarga de PDFs.

Uno de los grandes problemas al momento de crear tests para una aplicación web que entregue PDFs como resultado en algunas de sus funcionalidades,  es controlar el comportamiento por defecto que tendrá el navegador frente a dichos archivos. Según mi experiencia como QA de automatización los principales problemas son los siguientes:

• Ventanas de confirmación de descarga. ¡Un verdadero dolor de cabeza!, es imposible interactuar con ellas porque son parte del navegador y no de la página web.

• Ubicación del archivo a descargar. Un gran problema si no es manejado en la configuración de tu driver porque el navegador por defecto intentará usar sus carpetas ocultas en los lugares más oscuros de tu pc, ten en cuenta que además las rutas para dichos directorios son diferentes por sistema operativo, por lo tanto buscar manualmente o hardcodear una ruta es casi imposible sin previa investigación.

• Plugins por defecto del navegador. Actualmente los navegadores son capaces de leer los PDFs sin ningún tipo de plugin de terceros. Esto es un problema bastante recurrente, intentas descargar un pdf, pero ¡pum! el navegador mágicamente lo abre, rompiendo totalmente con el flujo de tu test.

Para poder resolver estos problemas es necesario modificar las configuración de los navegadores y guardar estos cambios dentro de un perfil.

A continuación listaré y explicaré los pasos para crear estos perfiles con sus configuraciones necesarias para los drivers de Firefox y Chrome utilizando Python.

Firefox.

profile = webdriver.FirefoxProfile() #1

profile.set_preference("browser.download.folderList", 2)#2
profile.set_preference("browser.download.dir", cfg.temp_pdf)#3
profile.set_preference("browser.download.useDownloadDir", True)#4
profile.set_preference("browser.download.manager.showWhenStarting", False)#5
profile.set_preference("browser.helperApps.neverAsk.saveToDisk", "application/pdf")#6
profile.set_preference("browser.download.manager.showAlertOnComplete", False)#7
profile.set_preference("browser.download.manager.useWindow", False)#7
profile.set_preference("pdfjs.disabled", True)#9
self.driver = webdriver.Firefox(profile)#10

Configuración para firefox.

1. Se crea un perfil de firefox vacío.
2. Con el número 2 le indicamos a firefox que debe utilizar la carpeta especificada en el paso 3.
3. Acá le proporcionaremos a firefox la carpeta que queremos utilizar como directorio de descarga.
4. Ahora activamos el uso del directorio asignado en el paso 3.
5. Apagamos la animación de comienzo de descarga. (Opcional)
6. Este paso es muy importante, acá le pasaremos como parámetro los MIME type que queremos descargar sin preguntar. Más info sobre MIME types.
7. Desactivamos animación de descarga completa. (Opcional)
8. Deshabilitamos la ventana de descarga de firefox.
9. Apagamos el plugin por defecto de firefox para leer archivos PDF.
10. Instanciamos el driver de Firefox pasando como parámetro nuestro profile recién creado.

Chrome

chrome_profile = webdriver.ChromeOptions()#1
profile = {"download.default_directory": cfg.temp_pdf,
           "download.prompt_for_download": False,
           "download.directory_upgrade": True,
           "safebrowsing.enabled": True,
           "plugins.always_open_pdf_externally": True}#2
chrome_profile.add_experimental_option("prefs", profile)#3
chrome_profile.add_argument("--disable-extensions")#4
chrome_profile.add_argument("--disable-print-preview")#5
self.driver = webdriver.Chrome(chrome_options=chrome_profile)#6

Configuración para Chrome.

1. Se crea un perfil de chrome vacío.
2. Acá creamos un diccionario con las siguientes configuraciones.
1. Directorio por defecto para las descargas de chrome.
2. Acá apagamos  la ventana que pregunta donde ubicar y como llamar el archivo por descargar.
3. Opción para que chrome pueda crear la ruta de descarga si es que no existe.
4. Navegación segura activada. (Opcional)
5. Para abrir el pdf externamente.
3. Se añade el diccionario recién creado como las preferencias del perfil.
4. Desactiva todas las extensiones de Chrome para evitar que algún plugin del navegador intente abrir los archivos PDF.
5. Acá desactivamos la vista de impresión para evitar nuevamente que algo intente abrir los PDFs.
6. Finalmente instanciamos el chromedriver pasando como parámetros el perfil de chrome recién creado.

Tal como pudimos apreciar, la configuración para evitar la interrupción de tests que contengan PDFs es un tanto compleja, ya que se debe tener en consideración muchas variables como lugar de descarga, desactivación de plugins, etc. Como comentario profesional siempre recomiendo descargar los pdfs utilizando código para no crear tests completamente dependientes de la máquina en que se están corriendo los tests, debido a que estos tipos de tests no van a funcionar al 100% en drivers provistos por saucelabs.

Downgrade de Firefox para no perder la compatibilidad con webdriver.

Uno de los últimos grandes problemas que me he enfrentado como QA de automatización ha sido el problema de compatibilidad de webdriver con Firefox. A partir de la versión 47 de Firefox,  no será posible utilizar webdriver con este navegador. Es decir, ya no podremos simplemente llamar a webdriver.Firefox() para hacer uso de él.

Las solución actual ante esto es instalar marionette. Suena fácil, pero créanme que no lo es. Es necesario hacer diferentes tipos de instalaciones por sistema operativo, lo cual no es lo ideal si estamos trabajando en testing multiplataforma.

Como notaran por mis palabras, no fui capaz de instalar marionette en el framework de automatización en el que trabajo. Me niego rotundamente a hacer una instalación ad hoc para cada sistema operativo, esto rompe totalmente la filosofía de mi trabajo. Por lo tanto, decidí hacer un downgrade de Firefox y esperar por una mejor solución al instalar marionette.

En sistemas operativos como OSX o Windows se puede desactivar las actualizaciones fácilmente mediante las opciones de configuración de Firefox. Por lo tanto, ahora compartiré la solución que utilicé para Ubuntu. Dicha solución es la siguiente:

1. Abrir un terminal.

2. Después debes correr este comando para instalar la versión 45 de Firefox:

sudo apt-get install firefox=45.0.2+build1-0ubuntu1

Nota: Puede que el sistema te advierta de que se llevará a cabo un downgrade, da tu consentimiento para continuar. 3. Para mantener la versión de Firefox sin permitir updates, se debe usar este comando:

sudo apt-mark hold firefox

Nota: Esto excluirá Firefox de cualquier actualización. Si quieres remover este cambio, es decir, volver a aceptar actualizaciones en Firefox, utiliza estos comandos para revertir el estado actual.

sudo apt-mark unhold firefox
sudo apt-get upgrade

Conclusión. Con estos cambios Firefox no volverá a ser actualizado, por lo cual podremos continuar usando sin problemas webdriver con Firefox, mientras esperamos por una versión más madura de marionette.

El costo de los bugs

El software no es un producto que aparece por arte de magia. Generalmente es planeado y pasa por varias etapas antes de ser lanzado. Por lo tanto, pasando por su planificación, desarrollo, testeo y lanzamiento, existe la posibilidad de encontrar bugs en cualquiera de estas etapas. En la siguiente figura se grafica qué tan caro es arreglar un bug dependiendo de la etapa de desarrollo en donde es encontrado.

El costo de arreglar un bug tiende a aumentar de manera exponencial como se puede apreciar en la figura. Dicho esto, si encontramos un bug en la etapa de diseño el costo de arreglarlo será bajo. ¿Pero que pasa si ese problema aparece en la etapa de testeo? dependiendo del proceso de desarrollo que se está utilizando esto puede variar. Trabajando con scrum, la tarea con problemas puede ser devuelta fácilmente a desarrollo, pero ésta de todas formas consume tiempo, pero no es lo mismo en el caso de un proceso de desarrollo más lento en donde los cambios se pasan a un servidor de prueba una vez al día.

Otro caso para analizar es cuando el cliente se encuentra cara a cara con un bug, como muestra la figura, el costo es 100 veces mayor a que si este hubiese sido encontrado en diseño. ¿Por qué será tan caro? La respuesta es simple, un bug encontrado por el cliente debe ser arreglado de manera inmediata en la mayoría de los casos, por lo tanto, la característica recién lanzada será retornada al proceso de desarrollo, en consecuencia a esto, la carga de trabajo aumentará considerablemente para el equipo. Además en algunos casos será necesario enviar el arreglo a producción antes de la fecha en que regularmente se hace, lo cual agrava más este escenario, ya que se debe aplicar todo el esfuerzo de un lanzamiento en una fecha no prevista.

Como pudimos apreciar, encontrar errores en etapas avanzadas del proyecto pueden ser perjudiciales para el equipo en términos de tiempo, esfuerzo e incluso dinero. Para evitar estos problemas es necesario utilizar estrategias preventivas como tests de regresión o unit testing en el lado de los desarrolladores. En síntesis, es esencial esforzarse desde el comienzo del proyecto en la búsqueda o prevención de bugs, para así poder capturar la mayor cantidad de errores en las etapas de diseño y desarrollo. 

Definición de un bug.

Llamar bugs a todos los problemas encontrados en un software puede ser la manera más simple de hacerlo, pero en definitiva no es una definición completa. Para entregar la definición correcta es necesario comprender qué es un problema y cómo estos se presentan dentro del software.

El primer término que nos ayudará con esto es especificación de producto: Una especificación de producto, comúnmente mencionado como especificación o spec, es un acuerdo entre todo equipo de desarrollo de software. Esto define el producto que se está creando, detalla qué debe ser, cómo debe actuar, qué debe y que no debe hacer. Este acuerdo puede ir desde un entendimiento verbal hasta un documento formal.

Ahora que hemos definido que es un spec, detallaremos las cinco principales reglas que ocurren cuando un bug aparece:

1. El software no hace algo que la especificación del producto dice que debe hacer.
2. El software hace algo que el la especificación del producto dice que no debe hacer.
3. El software hace algo que el la especificación del producto no menciona.
4. El software no hace algo que que la especificación del producto no menciona, pero debería.
5. El software es difícil de entender o usar, lento o simplemente incorrecto.

Para comprender mejor estas reglas, las pondremos en práctica testeando las funcionalidades de una supuesta calculadora que se está desarrollando.

El spec principal de nuestra calculadora es que en ella se pueda sumar, restar, dividir y multiplicar sin ningún problema. Si al momento de testear la calculadora descubrimos que estos cálculos no se están haciendo correctamente, por ejemplo: restas con resultados negativos congelan la aplicación. En este caso estaremos enfrente de un bug causado por la primera regla.

Otro spec del producto dice que la calculadora nunca se debe congelar, crashear o bloquear. Si al momento de apretar teclas de manera aleatoria, creando cálculos aritméticos sin sentido, la calculadora se bloquea. Estamos ante un bug causado por la segunda regla.

Como indicamos en el primer problema, la calculadora debe poder sumar, restar dividir y multiplicar. Supongamos que el desarrollador agregó la funcionalidad para obtener la raíz cuadrada de un número  porque pensó que sería una característica genial. El problema es que esto nunca fue especificado, por lo tanto, esta nueva característica se convierte en un bug siguiendo la tercera regla.

El caso de la cuarta regla es un poco especial, debido a que estamos ante un enunciado que posee doble negativo. Supongamos que nuestra calculadora funciona correctamente cuando se hacen divisiones que tienen resultados con pocos decimales. pero al momento de testear exhaustivamente las divisiones nos damos que cuando el resultado tiene más de 10 dígitos en su decimal la fuente de la calculadora se torna pequeña e ilegible. En este caso estamos ante un problema de usabilidad que obviamente nunca se mencionó en la especificación del producto. Dicho bug es causado por la cuarta regla.

En el caso de que nuestra calculadora sea difícil de utilizar, posea teclas muy pequeñas, su texto sea ilegible, su configuración sea muy compleja, etc. En síntesis, cualquier problema que no luzca correcto, afecte su usabilidad o arruine la experiencia del usuario final será bug causado por la quinta regla.

Como pudimos ver con los ejemplos mencionados, los bugs pueden aparecer de diferentes formas en un software, por lo tanto un bug es una falla, algo no especificado, inconsistencias o problemas que afectan la experiencia del usuario al utilizar el software.