Los tests automáticos tienen sentimientos

…y no solo sentimientos, también pueden tener bugs. Incluso peor, pueden fallar ocasionalmente (flaky tests en anglosajón) y ello puede llevar a ponerlos en cuarentena en la ejecución de los builds bajo el lema “ya arreglaremos los tests más tarde”, un “más tarde” que no llega nunca, perdiendo cobertura de pruebas lenta y dolorosamente.

Ignorar temporalmente tests que fallan a veces para conseguir un “green build” es válido, pero no arreglar o eliminar esos tests que no son de confianza no lo es. Con esta idea en mente escribí esta carta en nombre de un test ignorado, publicada en el blog de desarrollo de Atlassian.

Espero que te guste 🙂

De testers y code reviews

Hola, me llamo Mauri y yo también he ignorado las revisiones de código con la excusa de que son “terreno de los desarrolladores”.

¡Pero ya no! Desde que trabajo en Atlassian que me he dado cuenta que, para que la calidad escale con el desarrollo, hay que invertir esfuerzos en la prevención por delante del control o la mitigación, y un buen lugar para prevenir son las revisiones de código, que acostumbran a ocurrir antes de cualquier testing hands-on.

STASH13_PRactivity

Y no quiero oir a nadie diciendo cosas del estilo “pero yo no soy desarrollador” o “es que no sé leer código”, porque no hace falta ser un developercon213añosdeexperiencia para mirarse una revisión de código. Además, leer código es más fácil de lo que aparenta, y las revisiones de código son un buen lugar por donde empezar, ya que los cambios estan asociados a una funcionalidad o bugfix, de tal manera que el código se puede vincular fácilmente a su objetivo.

Listado de 5 cosas al azar que te interesan, como tester, de las revisión de código:

  1. Mayor conocimiento de los sistemas y aplicaciones: como tester más funcional, seguro que ya te conoces todos los recovecos de la interfaz de usuario, ¿por qué no ampliar ese conocimiento con nociones del funcionamiento de la cara interna de las aplicaciones?
  2. Inspiración para futuras fases de pruebas: dependencias inesperadas, secciones complejas, condicionales gigantes, dudas sin resolver expresadas en los comentarios… Este tipo de cosas son pistas invaluables para exprimir las aplicaciones durante la fase de pruebas. Este conocimiento, bien usado y con práctica, hace que el testing sea como jugar al Trivial Pursuit consultando la Wikipedia.
  3. Mejores tests automáticos: el input de un tester en las pruebas automatizadas que vengan con el código (tests unitários, de integración o de lo que sea) puede ser muy útil para que las nuevas funcionalidades nazcan con una cobertura exhaustiva e útil, más allá de los happy paths.
  4. Se cazan bugs también! Que sí, que sí, que se puede! Y no solo bugs, también comentarios confusos, errores de formato, secciones poco claras, tests unitarios que no testean nada… Las revisiones de código son el momento idóneo para corregir este tipo de problemas.
  5. Respeto: también puedes ganarte (más) el respeto de los desarrolladores con tu participación e interés en las revisiones de código, gracias a tus consejos y aportaciones en las mismas. Sabrás que estás por el buen camino cuando tu input sea solicitado en ellas o (todavía mejor) cuando algún desarrollador te pida consejo sobre qué casos de prueba automatizar ¡en la fase de codificación!

Estas son las mías, pero hay muchas más razones por las que, como tester, puede ser interesante participar en las revisiones de código. ¿Cuáles son las tuyas? ¡Cuéntamelo en los comentarios!

Trucos de Selenium IDE – Intro, recording, waiting

Trucos de Selenium IDE – Intro, recording, waiting

Hasta ahora, Selenium IDE me ha salvado mi vida de tester suficientes veces como para decidir lo siguiente:

  1. Profundizar en esta herramienta esencial para los testers, con la intención de entender propiamente qué es, qué es lo que he estado haciendo con Selenium IDE, cómo puedo sacar mayor beneficio de la misma, etc.
  2. Difundir la palabra sobre esta herramienta (a veces) minusvalorada, defendiendo su honor y ayudando y animando a otros a profundizar, aprender e inspirarse de ella.

Qué mejor manera de hacer esto que blogear? Así que he desarrollado una pequeña serie de posts sobre Selenium IDE, explicando algunos trucos que hago servir, escribiendo porqué y cómo los uso, ya que… To blog is to learn!

Este primer post pretende introducir la serie, explicándonos qué es Selenium IDE y algunos conocimientos básicos sobre la misma. Allá vamos!

Qué es Selenium IDE?

Según SeleniumHQ (el site oficial del proyecto), Selenium IDE es un “add-on para Firefox que hace un sencillo Record-and-playback de interacciones con el navegador”. A partir de esta definición, concentrémonos en algunos conceptos:

  • IDE: IDE son las inciales de “Integrated Development Environment”, y esto quiere decir que estamos delante de una aplicación que nos ayudará a desarrollar utilidades relacionadas con el software.

  • Firefox: sí, Selenium IDE solamente está disponible para Firefox, así que no nos va a ayudar en la ejecución de cross-browser testing, pero es una herramienta ligera e inestimable para automatizar testing funcional de carácter general en navegador.

  • Add-on: un add-on para un navegador (también llamado una extensión del mismo) es un complemento instalable que añade funcionalidades o amplía las que tiene el navegador por defecto. Esto es lo que Selenium IDE nos ofrece, añade funcionalidades de record-and-playback de interacciones con el navegador a nuestro Firefox.

  • Record-and-playback: esto quedaría mejor com record and/or playback. Puedes grabar o no, pero en lo que estamos interesados es en el playback, en la reproducción, porque es lo que realmente nos porporciona capacidades automatizadoras, la reproducción de…

  • Interacciones con el navegador: este es el tema, esto es lo que Selenium IDE hace fantásticamente. Con este add-on podemos grabar, generar, gestionar y ejecutar interacciones von el navegador, simulando los clicks, selecciones, movimientos, escritura… de un usuario real en páginas web y su contenido.

Pues, para resumir esta sección con palabras sencillas, Selenium IDE es un pequeño complemento para nuestro navegador Firefox que nos permite simular interacciones de usuario vía navegador en páginas web. Con él, seremos capaces, entre otras cosas, de ejecutar testing funcional automatizado en navegador web.

Cuándo es Selenium IDE una buena elección para testing automático?

Con Selenium IDE podemos almacenar y organizar casos de test y suites, así que es posible tener una suite de suites automatizada a ejecutar con esta herramienta. Selenium IDE es potente (más de lo que parece), pero limitada; es una gran herramienta para casos de test sencillos pero no tan apropiada para casos más complejos (con muchas ramas, condicionales, casos y demás). Además, tal y como hemos dicho antes, sólo funciona con Firefox, así que si se necesita una herramienta para cubrir casos más complejos y/o funcionando en distintos navegadores, es mejor echarle un vistazo a Selenium Webdriver o Watir. Hay herramientas comerciales que también podrán satisfacer estas necesidades.

Personalmente, yo la uso para ejecutar testing automático ligero, para repetir tareas tediosas pero simples durante una iteración o proyecto, pero sin el objetivo de almacenar o mantener esta automatización; haciendo esto, las pruebas se pueden desarrollar más rápido (aunque seguramente de forma sub-óptima), pero muy efectivas para el coste que implican. Además, Selenium IDE es un fantástico “facilitador” de testing no automático, ya que te puede ayudar en ejecutar rápida y robóticamente pasos tediosos y largos que dejan tu aplicación web lista para ser testeada, en un estado que  sea aburrido de conseguir. Automatizando el camino hasta este punto no estarás cansado ni enfadado, pero sí listo para ejecutar tu mejor testing en él! 🙂

El recording como inicio fácil…

La manera más fácil de empezar un caso de test con Selenium IDE es ejecutarlo manualmente con el botón de grabado a “on”; lamentablemente, hay muchas cosas que se escaparán de este grabado (eventos en background, esperas implicitas que ejecutamos como humanos sin darnos cuenta, cosas así). Por ejemplo, vamos a grabar una simple búsqueda en un motor de búsquedas, buscaremos el término “Software Testing” y veremos si luego aparece un link a la página de la Wikipedia sobre Software Testing en los resultados. Este es el código que obtengo tras grabar esto con Selenium IDE: 

open http://duckduckgo.com/
type id=search_form_input_homepage Software Testing
clickAndWait id=search_button_homepage
verifyElementPresent link=More at Wikipedia

Este test se puede reproducir sin ninguno de los problemas antes mencionados, ya que el grabado de Selenium IDE es suficientemente listo como para convertir mi gesto de “click” en el botón de búsqueda en un comando “clickAndWait”. La referencia implícita (esta pestaña se encuentra en la consola del IDE) de este comando dice…

clickAndWait(locator)

Generated from click(locator)

Arguments:

     * locator – an element locator

Clicks on a link, button, checkbox or radio button. If the click action causes a new page to load (like a link usually does), call waitForPageToLoad. 

Así que, virtualmente, el ejemplo anterior se corresponde al siguiente…

open http://duckduckgo.com/
type id=search_form_input_homepage Software Testing
click id=search_button_homepage
waitForPageToLoad 30000
verifyElementPresent link=More at Wikipedia

…donde el 30000 es simplemente un número arbitrário de milisegundos para llamar a un timeout una vez se hayan superado y la página no se haya cargado aún. El comando “clickAndWait” usa el timeout por defecto especificado en el menú “Options” del IDE, mientras que en “click” + “waitForPageToLoad” tenemos que especificarlo manualmente, luego puede ser mayor o menor que el timeout por defecto.

Podemos alcanzar algo similar usando el comando “pause” del siguiente modo: 

open http://duckduckgo.com/
type id=search_form_input_homepage Software Testing
click id=search_button_homepage
pause 30000
verifyElementPresent link=More at Wikipedia

Ejecutando este trozo de código podemos ver que la ejecución de este test SIEMPRE se espera 30 segundos (30000 milisegundos), sin importar si la página se cargó hace 20 segundos, cosa que suena mucho menos eficiente que las anteriores versiones. El tema es que necesitamos que se haga algo justo después de accionar el botón que nos asegure que la página (o recurso, o botón…) se haya cargado antes de seguir en nuestras comprobaciones, puesto que si tuviéramos el siguiente caso de test…

open http://duckduckgo.com/
type id=search_form_input_homepage Software Testing
click id=search_button_homepage
verifyElementPresent link=More at Wikipedia

…nuestro test seguramente fallaría ejecutándolo a la máxima velocidad, ya que le estamos diciendo a Selenium IDE que verifique justo después de hacer click, cuando resulta que este click provoca la carga de una página nueva, entonces verificar inmediatamente cosas sin esperar a que la página esté completamente cargada nos llevará fácilmente a que Selenium IDE verifique algo que todavía no puede encontrar, retornando un mensaje…

[error] false

…en la pestaña de log de la consola del IDE mientras ejecutaba el comando “verifyElementPresent”, puesto que cuando Selenium IDE está ejecutando este comando no hay link a la Wikipedia en la página (ya que esta no se ha cargado completamente todavía).

Final learnings

Grabar la ejecución de nuestros test cases nos ayudará a definir su esqueleto. Una vez hayamos hecho esto, conviene hacer debugging sobre los mismos (los breakpoints y las ejecuciones paso a paso nos ayudarán con ello) haciéndolos suficientemente robustos como para ser ejecutados a la máxima velocidad sin problemas, sin importar si la red de la oficina parece más lenta de lo normal.

Gracias por leer hasta el final y… nos vemos en el siguiente post de esta serie sobre Selenium IDE!