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!

Mi primer EuroSTAR

Después del refrescante QA&TEST Bilbao 2013 llegaron palabras mayores. A raiz de mi colaboración periódica en el blog de la conferencia internacional de software testing EuroSTAR, la organización de la misma me invitó a asistir al evento (realizado entre el 4 y el 7 de Noviembre en Gotemburgo, Suecia) a cambio de escribir algunos posts sobre lo que estaba pasando en ella (por ejemplo este o este otro).

Para el que no lo sepa, EuroSTAR está entre las 3 conferencias más importantes de testing en Europa, y puede ser la que tenga más historia (con 20 ediciones a su espalda). Este año han asistido más de 1000 personas al evento y ha consistido de un día y medio de tutoriales (11 en total, 5 de un día, 6 de medio día), 3 workshops y 47 charlas en 4 tracks con la crème de la crème del testing europeo y mundial debatiendo sobre el tema de este año: “Questioning testing”.

El nivel de las charlas ha sido bastante alto, pero lo que más me ha llamado la atención es que es un evento en el que constantemente pasan cosas, mucho más allá de las charlas. La conferencia facilita la generación espontánea de charlas informales, demostraciones, workshops improvisados y sesiones de testing colectivo proporcionando el espacio y el tiempo para ello. Hay incluso quién dice que este aspecto es lo mejor de todo el evento! También hay que decir que la comunidad internacional está muy acostumbrada a la vertiente social del testing, quien más quien menos asiste con regularidad a testing social meetups en sus países de orígen, y eso se nota en estas situaciones.

Chilling out at EuroSTAR 2014

Chilling out at EuroSTAR 2014

Mucha información tengo ahora que procesar, del más alto nivel y de las más variadas fuentes; pero más allá de la infoxicación que pueda sufrir ahora mismo, mantengo mi opinión sobre la asistencia a eventos de este tipo, son un subidón de adrenalina testeadora importante, además de permitirte estar en contacto con lo más avanzado de esta profesión que no se acaba nunca. 100% recomendable!

La edición del 2014 es en Dublín y el tema es “Diversity, innovation & leadership”. Nos vemos allí? 😉

[Encuesta – Resultados] Demuestra tus asunciones!

[Encuesta – Resultados] Demuestra tus asunciones!

Siempre me ha preocupado la sobrevaloración de las capacidades técnicas en la carrera del tester, probablemente debido a mi falta de bagaje académico en este aspecto. He dejado constancia de mi opinión (que son importantes per se sobrevaloran a veces) en diversos sitios, por ejemplo aquí mismo y, recientemente, en una conversación en LinkedIn al respecto, por decir dos de ellas.

Cuando vi los resultados de la encuesta sobre el liderazgo en el número de Marzo del “The Testing Planet” me sentí aliviado: las habilidades técnicas / de programación son posicionadas en sexto lugar (de siete) como respuesta a la pregunta “¿Qué habilidades crees que se necesitan para ser un líder influyente y eficaz en el sector del software testing?”, y la comunicación es la primera. Estos son los resultados completos a la pregunta:

The Testing Planet - Leadership survey results

Después de ver esto, sentí la urgencia de escribir sobre ello, sobre cuán diferentes son las prioridades por aquí, donde las habilidades técnicas se valoran mucho más que las comunicativas, analíticas o estratégicas. Pero antes de hacerlo, decidí poner a prueba esta presunción, así que hice una encuesta yo mismo, con esta pregunta solamente, a la comunidad Hispana que me sigue, para probar mi teoría. Traduje la pregunta, la posteé y la distribuí a través de las redes sociales para obtener algunas respuestas.

He dicho antes que no tengo bagaje técnico, pero sí que tengo una licenciatura en Investigación de Mercados (escépticos: lo podéis ver en mi perfil en LinkedIn ;-)), entonces estoy al corriente de algunos de los sesgos derivados de comparar los resultados a ambas preguntas: las muestras no tienen el mismo tamaño ni los mismos rasgos demográficos, hay matices en la traducción al castellano que hacen que las preguntas o su interpretación no sean 100% equivalentes, puede haber duplicidad en las muestras… y, sobretodo, las encuestas no son una ciencia exacta, pero te pueden ayudar a entender una tendencia. Así pues, más allá de los números, estaba interesado en el ranking de las capacidades, y los resultados fueron… EXACTAMENTE LOS MISMOS!

Resultados de la encuesta sobre habilidades en este mismo blog

Las habilidades técnicas o de programación están posicionadas en sexto lugar de siete y las de comunicación e interpersonales en primer lugar. Estoy realmente sorprendido (y encantado) con estos resultados, ya que me han ayudado a consolidar dos átomos de aprendizaje:

  1. Demuestra tus asunciones, puesto que pueden estar completamente equivocadas

  2. Potencia tus habilidades comunicativas!

Así pues, qué has hecho hoy para ser un mejor comunicador en lo que al testing se refiere?

[Encuesta] Las habilidades de un “software testing leader”

Hagamos un ejercicio, responde a la siguiente pregunta…

Y, cuando haya reunido suficientes resultados para decir algo fundamentado al respecto, lo publicaré en este blog. Hay trato? 🙂

PS: sí, me encanta el misterio…

Update: ya he plasmado unas reflexiones sobre esta pequeña encuesta, puedes leerlas aquí.

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!

QA&Test 2012

QA&Test 2012

Por segunda vez este año, he tenido la suerte de ganar una entrada gratis para la conferencia QA&TEST 2012 celebrada en Bilbao los días 17, 18 y 19 de Octubre. Quiero reiterar el tema de “la suerte”, porque ahora que hace menos de 72 horas que se ha terminado el evento puedo decir oficialmente (de nuevo) que ha sido una experiencia…

FANTÁSTICA!

Amantes del testing de España y de todo el mundo, sintámonos afortunados de tener en nuestro territorio un evento de orfebrería como éste, una auténtica delicatessen de conferencia.

Honestamente, el QA&TEST 2012 me ha robado el corazón, por muchas razones, por ejemplo:

  • El pequeño formato que defiende la organización. El total de asistentes entre ponentes y público roza las 100 personas y se organiza en 2 tracks simultáneos que van cambiando de temática durante la conferencia, esto hace que sea un evento en el que impera la…
  • Cercanía. Hay algo en el ambiente de esta conferencia que te hace sentirte bien, como en família, la calidez está por todas partes, de principio a fin, desde la organización hasta los…
  • Contenidos. Un poco de todo, tocando todos los palos, ponentes de todo tipo, ponencias muy concretas junto a otras más generales, rigurosidad en la selección y mucha información que requiere de una correcta…
  • Duración. 3 días de conferencia, suficientes para cubrir temas con holgura, sin que sea corto y estresante ni largo e injustificable, para tratar los temas con todo lujo de…
  • Detalles. La calidad está en los detalles, el trabajo se nota en los detalles. Las cosas, los eventos, no salen a la perfección si no hay mucho trabajo detrás y no se atiende a las pequeñas cosas, por ejemplo los cuadernos con los slides de las ponencias impresos, las comidas fantásticas en los que se podía catar lo mejor de la cocina Vasca, el banquete en la histórica sociedad bilbaina con una copa posterior pagada por la organización, y un largo etcétera.

En resumen, un 10 para la organización 🙂

Entrando más en profundidad en lo que al testing se refiere, el QA&TEST de Bilbao no tiene nada que envidiar al “cartel” más mediático de ponentes de su pariente lejana ExpoQA, como prueba de ello están las ponencias y keynotes de Lynn Mckee, Nancy Kelln, Derk-Jan De Grood, Jan Jaap Cannegieter, Julian Harty, Shmuel Gershon… Pero no depende todo de eso; sin presentaciones de “relleno”, todos los temas de la conferencia se tocaban con mucha profesionalidad y la variedad de las temáticas de los tracks (QA, management, el testing en sectores industriales, automatización, mobile, organización de equipos, nuevas técnicas…) permite que, en global (y seguro en particular), sea una conferencia interesante y de valor añadido para todos los asistentes con interés en el testeo de software, la calidad y relacionados.

Mesa redonda sobre el futuro del testing con Bryan Bakker, Jan Jaap Cannegieter y Lynn Mckee

Me quedo con toda la experiencia, con todas las ponencias y keynotes, con todas las charlas e interacciones, creo que he aprendido muchas cosas en esta conferencia y, para resumirlo en citas sin cansar al personal, sugiero que pensemos seriamente en las siguientes ideas, puesto que pueden cambiar nuestra visión de la profesión:

“El testing se puede llevar a cabo sin casos de test” @nkelln

“Puedes transformar tu organización” @lynn_mckee

“Concéntrate en aportar valor a la gente de business@derkjandegrood

“Puedes hacer más de lo que te crees capaz” @jjcannegieter

“Porque el futuro del testing está en nuestras manos” @mauri_edo

Nos vemos en el QA&TEST 2013!!!