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!

Verano para autodidactas

Tras terminar el semestre universitario (por si alguien no lo sabe, estoy estudiando el Grado en Ingenieria Informática en la UOC) empieza el mejor periodo del año para los autodidactas: el Verano! Una estación donde solamente hay que trabajar (o ni eso, si tienes vacaciones) y se abre casi un trimestre para estudiar, investigar y aprender lo que uno quiera!

Personalmente, me gusta marcarme unos objetivos claros para no caer en la dispersión y agotar el tiempo sin haber hecho nada concreto. Tener unos objetivos y un plazo claros también te ayuda a ser consciente de tus progresos y del grado de esfuerzo necesario en cada momento. Así pues, mis objetivos en este verano para autodidactas 2013 son los siguientes:

Reflexionando mucho sobre este tema quiero realizar las siguientes tareas para mejorar mi profundidad técnica en lo que al testing se refiere:

Realizar el curso “Technical web testing 101” → Completed!

Fantástico curso para entender las diferencias entre testing técnico y testing de la superfície. Gratuito, breve pero intenso, on-line, con un profesor de nivel como Alan Richardson (The Evil Tester) y repleto de información, este curso (alojado en la plataforma de aprendizaje on-line Udemy) es ideal para principiantes y testers cero-técnicos con interés en barnizar su trabajo con una capa de mayor profundidad técnica a la hora de testear aplicaciones web. Es un curso de básicos con muchos punteros a información, recursos, herramientas, trucos y demás material para investigar por cuenta própia, con una filosofía muy del DIY, de conocer las herramientas que tienes a tu disposición (especialmente los navegadores y los proxies HTTP) y de encontrar la motivación dentro de uno mismo para investigar y preguntar hasta entender todo aquello que desconocemos, olvidándonos de la frontera entre lo que es técnico o no, lo que es testing y lo que no, en pro del conocimiento.

Os dejo el link del curso, en inglés (of course) → https://www.udemy.com/technical-web-testing-101/

Completar el track de jQuery en Codecademy → In progress

En mi dominio, tener nociones de HTML, CSS, JavaScript y jQuery es esencial, por ello me valgo de la fantástica plataforma  codecademy para alimentar esos conocimientos. En concreto ahora estoy en plena track de jQuery, el último que me falta, a terminar muy en breve, como puedes ver en mi perfil.

Adquirir nociones de Java → To start

Siempre he querido tener nociones de lenguajes de programación, y en mi trabajo disecciono diáriamente aplicaciones basadas en Java, así que ¿por qué no profundizar en este lenguaje? Para ello, cuento con este libro electrónico (también de Alan Richardson) llamado Java for testers, que parece un muy buen punto de partida para el nivel que quiero alcanzar (que no es el de ser un superdesarrollador, más bien el de entender los fundamentos para poder jugar con ellos).

Por otro lado, hace tiempo que quiero investigar sobre las posibles especializaciones dentro del testing (usabilidad, rendimiento, seguridad…) y aprovecharé este verano para…

Profundizar en el testing de seguridad → To start

Unas nociones superbásicas de este tema apasionante ya se tocan en el curso de “Technical web testing 101” del que ya os he hablado antes, y para profundizar más, tomaré este otro curso también en Udemy: Whitehat hacking and penetration testing, a ver cómo evoluciona!

Para terminar, y pensando en la charla que daré en la próxima edición de la conferencia QA&TEST 2013, quiero…

Mejorar mi inglés hablado! → In progress

Para ello, me he apuntado a un grupo de conversación en inglés que hay en mi barrio, un día cada dos semanas, para quitarle el óxido a esta habilidad cuya precisión depende totalmente del nivel de práctica que lleves encima.

Este es mi plan, y el tuyo? Qué te vas a auto-enseñar durante este verano? Cuéntamelo en los comentarios 😉

Reportar defectos ES comunicarse!

The Testing Planet ha publicado un texto mío sobre el bug-reporting y como encajarlo dentro de nuestra estrategia de comunicación como testers para con el resto del mundo. Aquí lo tienes: http://www.ministryoftesting.com/2013/06/dude-pen/

Image

En el artículo, propongo un nuevo mnemotécnico para pulir nuestros reportes de defectos: DUDE, PEN!. Un buen defect report es (como mínimo y en inglés):

  • Direct
  • Unique
  • Documented
  • Entire
  • Prioritised
  • Easy to find
  • Neutral

Espero que te guste! Me dejas tu opinión 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!