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!

Australia, Sydney, Atlassian… y yo.

El pasado 28 de Enero fue mi primera jornada laboral como QA Engineer en la oficina central de Atlassian, en Sydney (Australia). Ha sido un proceso muy largo y complicado en muchos sentidos, aunque tampoco esperaba que entrar a formar parte de una de las empresas más punteras en el desarrollo de software del mundo fuera fácil… 😉

photo (6)

Estoy muy contento por haber llegado hasta aquí aunque, tras tres semanas trabajadas, puedo decir que el nivel es altísimo, así como el volumen de información, lo que implica que me voy a tener que poner las pilas a muchos niveles para estar a la altura de mis nuevos y nombrosos compañeros.

Seguiremos informando desde Down Under, saludos!

Nace #SOFT #WAR #FAIR :-)

Los que me conocen, saben que siempre he estado en contra del eterno enfrentamiento entre testers y desarrolladores, ya que ambos perfiles “construyen” el software y lo hacen conjuntamente, así que un enfrentamiento a este nivel no hace más que estropear la dinámica del equipo y alejarse del objetivo común.

La pregunta es…

¿Qué haces tú para superar este tópico?

Personalmente, aparte de mantener cada día el objetivo común en mi mente y trabajar en pos de la harmonía dentro del equipo tecnológico, hoy mismo he hecho un paso más adelante para romper con esta lacra que no hace más que atrasarnos a nivel mundial como profesión:

He montado un blog colectivo de desarrollo y calidad!

Pues sí, nace #SOFT #WAR #FAIR, un blog de desarrollo de calidad y calidad del desarrollo, escrito de momento a seis manos, que espero que tenga una larga vida y lista de adeptos y colaboradores 🙂

Captura de pantalla 2013-10-26 a la(s) 12.06.52


Espero que lo disfrutéis!

http://softwarfair.wordpress.com/

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? 😉

De casos de test a mapas mentales: una experiencia personal

De casos de test a mapas mentales: una experiencia personal

La mecha que prendió este post fue este comentario en una de mis entradas de análisis de herramientas de test case management, preguntando por el resultado de la investigación en este tema realizada al principio del año 2011. La búsqueda terminó al cabo de algunos meses, a medida que me iba dando cuenta de que una herramienta de este tipo no encajaba en mi contexto actual, pero nunca concluí la investigación oficialmente. No la estoy concluyendo ahora con este post, a lo mejor la retomo en el futuro, pero dos años después de sus inicios, el hecho es que hemos vivido y testeado adecuadamente sin casos de test ni herramientas de gestión de los mismos. Así es como lo hicimos.

Antes de empezar, no estoy intentando afirmar cuál es la mejor solución en este aspecto, esto es el relato de una experiencia personal solamente, un caso de estudio si queréis. Simplemente food for thought, cosas a considerar si os encontráis en esta situación. Espero os sirva de ayuda 🙂

Nuestro contexto

Intentaré resumir nuestro contexto en unas pocas líneas, contáctadme si no es suficiente para entender la situación:

  • 2 aplicaciones web-based
  • Ambas aplicaciones son maduras, con más de 3 años de existencia cada una
  • +500 casos de uso (y creciendo!), desde simples CRUD a grandes y complejos casos de integración de sistemas con interpretaciones condicionales y reglas de negocio implicadas
  • Un departamento de 2 testers, emparejado con un equipo de 4-5 developers superlistos
  • Un promedio de 2-3 releases al mes
  • Sin automatización disponible (en el momento de iniciar la investigación)

El primer número que me vino a la mente fue que necesitábamos una herramienta que gestionara como mínimo +500 casos de test (digamos, el happy path de cada uno de esos casos de uso), ergo se supone que tendremos que desarrollar esos +500 casos de test, y también se supone que tendremos que mantener esos +500 casos de test, sin reclutar nuevos compañeros ni reducir la velocidad de releases que defendemos.

No podíamos realizar esa inversión, nuestro foco hubiera pasado de testear a crear y mantener casos de test, con la sensación de que se trata de una tarea interminable, ya que hay casos de uso nuevos cada mes, más revisiones de los ya existentes, implicando nuevos casos de test a redactar y casos de test viejos a mantener, más en algún momento explorar los unhappy paths si teníamos tiempo.

Qué hacíamos mientrastanto?

Al principio de todo, 2 años antes de que esta búsqueda empezara, intentaba crear los casos de test en Excel al principio de la fase de testing (desarrollábamos bajo waterfall por aquél entonces) antes de testear efectivamente, de lo que aprendí lo siguiente:

  1. Los casos de test evolucionan mientras testeas, por ello tu manera de pensar y la herramienta que uses tiene que estar preparada para esto.
  2. El mantenimiento y la reutilización de los casos de test es un tema candente, difícil de gestionar en un entorno cambiante como el nuestro, por las razones antes mencionadas.

Con este enfoque, descubrí que invertía más tiempo creando, editando y adaptando a la situación actual mis casos de test en Excel que testeando efectivamente. Progresivamente, fui abandonando ideas; primero, abandoné la idea de reusar casos de test (con lo que el asunto del mantenimiento desapareció también); y después, abandoné la idea de preparar todo el conjunto de casos de test antes de empezar el testing, abrazando un diseño de testing y una ejecución más dinámicos. Estaba haciendo testing exploratorio sin saberlo, pero no me sentía cómodo con la idea de no tener documentación de test. Por esto último empecé la investigación de una herramienta de gestión de casos de test.

Y… Apareció el mind mapping!

Mientras investigaba herramientas concretas, intenté averiguar qué hacían otros profesionales en situaciones similares a la nuestra, y descubrí que el testing exploratorio era real y muy respetado por testers muy influyentes; y descubrí el mind-mapping también.  Inmediatamente cambié el uso de Excel y Notepad en mis actividades exploratorias extraoficiales para usar Xmind como herramienta de soporte para las mismas.

Tan buen punto empecé a hacer esto tuve un momento de esos de “cómo no había hecho esto antes!”, ya que los mapas mentales son la herramienta perfecta para desarrollar y ejecutar pruebas mientras testeas, evolucionando tus ideas de testing mientras testeas efectivamente, disfrutando con el proceso y reforzando la parte creativa del testing, cosa que también tiene su gracia. Además de esto, el uso de mapas mentales nos permitió desarrollar un “mapa mental de ideas de testing” al inicio de los proyectos e iteraciones y evolucionarlo a medida que estas avanzaban y profundizábamos en su contenido, compartiéndolo con el resto del equipo, tanto desarrolladores como stakeholders, creando una gran compilación de ideas de pruebas justo antes de empezar efectivamente a testar, y pudiendo evolucionar esta compilación mientras el testing tenía lugar.

La búsqueda de una herramienta de test case management finalizó de facto…

…en el momento que me pregunté ¿por qué iba a querer invertir esa cantidad de tiempo en documentar esos casos de test cuando estamos cumpliendo razonablemente bien sin ellos? Las primeras respuestas que me vinieron a la mente se referían a registros de ejecución de pruebas, cobertura y reutilización. Así que las analicé profundamente.

El tener registros de ejecución de casos de test no es razón suficiente para implementar una herramienta de gestión de casos de test, por lo que seguí profundizando en las otras respuestas.

Sobre cobertura… somos principiantes en testing exploratorio, así que me sentía inseguro de que nos dejáramos areas importantes sin testear con un enfoque tan dinámico, pero la idea de implementar una herramienta de gestión de casos de test no me era suficiente, preferí pensar en mejorar como testers exploratorios; además, alimentar esas herramientas nos hubiera quitado tiempo de testing efectivo, por lo que la coberturase vería afectada también. Por otro lado, qué cobertura te ofrece una herramienta de gestión de casos de test? La cobertura sobre los casos de test que has sido capaz de introducir en ella, cosa que es una manera sesgada de ver la cobertura. Me sentí más seguro haciendo crecer la cobertura en las áreas importantes a medida que íbamos testeando.

La reutilización ha sido un hito reciente para nosotros, decidiendo no reutilizar nada hasta ahora, recreando y revisando las ideas de pruebas a medida que lo hemos ido necesitando, afilando nuestros sentidos y habilidades exploratorias en cada iteración, aunque probablemente modifiquemos esta conclusión pronto.

Próximos pasos (algunos ya ejecutados)

Habiendo decidido oficialmente que hacíamos testing exploratorio con mapas mentales y siendo felices con ello, empezamos a iterar esta idea para mejorar nuestro desempeño. Cosas que ya hemos hecho al respecto:

  • Invertir tiempo en automatizar validation checks, para combinar nuestra óptica exploratoria profunda con cobertura general y ligera en términos de checking.
  • Documentar formalmente algunos casos de test para los casos de uso más críticos (hablamos de unos 5 o así), creando una mini test-suite a ser ejecutada en cada ciclo de testing, antes de la instalación de una nueva versión. Esta suite no se automatizará nunca, ya que requiere unos 15 minutos de ejecución y quiero los 7 sentidos de un tester pensante en ella, y un robot no me ofrece esa seguridad. Los smoke tests son documentados formalmente también. Estas son pruebas sencillas que demuestran que el testing exploratorio y el documentado formalmente pueden coexistir.

Cosas que espero hagamos en el futuro cercano:

  • Repensar el tema de la reutilización. Quizás podríamos desarrollar un mapa mental con checklists para empezar esa recopilación de ideas de pruebas con algo ya hecho, actualizando estos documentos a medida que los vamos usando, aceptando que tienen que ser actualizados antes de evolucionarlos, pero tomando ventaja del conocimiento y esfuerzo mental ya aplicado.
  • Desarrollar una especie de testing low-tech dashboard, basado en mapas mentales, con la intención de comunicar más fácilmente el estado del testing al equipo et altri.

Finale

Pues ya está. Un proceso de 4 años resumido en menos de 1500 palabras. Espero poder escribir algo más al respecto en los próximos 4 años, a ver si mejoramos en este interminable y fantástico asunto!

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!!!

Juego de tronos: los testers de la noche

Juego de tronos: los testers de la noche

Aparte de fanático del testing, y entre otras muchas cosas, soy un adicto a las series de TV, lo confieso; y series como Juego de Tronos, la serie de la HBO basada en la saga de libros “A song of ice and fire” de George R.R. Martin no hacen más que agrandar esta adicción, para bien :-).

En el universo de Juego de Tronos hay una orden militar que me apasiona, la guardia de la noche, y como más voy sabiendo de ella, más similitudes le encuentro a nuestra ocupación, nuestra orden militar-laboral, los testers (o también, los testers de la noche 😉 ).

Intentaré explicarme en 5 #facts, a ver si lo consigo:

#1 – Objetivo:

El objetivo de la guardia de la noche es claro, defender el muro, protegiendo los reinos de los hombres de lo que haya tras del mismo (especialmente de salvajes y caminantes blancos).

El objetivo de los testers es el mismo, defender las aplicaciones, protegiendo a los usuarios de bugs y de los efectos terribles que estos pueden causarles.

#2 – Compromiso:

El juramento de la guardia de la noche es el siguiente…

La noche se avecina, ahora empieza mi guardia. No terminará hasta el día de mi muerte. No tomaré esposa, no poseeré tierras, no engendraré hijos. No llevaré corona, no alcanzaré la gloria. Viviré y moriré en mi puesto. Soy la espada en la oscuridad. Soy el vigilante del Muro. Soy el fuego que arde contra el frío, la luz que trae el amanecer, el cuerno que despierta a los durmientes, el escudo que defiende los reinos de los hombres. Entrego mi vida y mi honor a la Guardia de la Noche, durante esta noche y todas las que estén por venir.

Un miembro de la guardia de la noche lo es para siempre y su único y máximo compromiso es con la orden y su objetivo, rechazando cualquier otro vinculo afectivo.

Para poder hacer bien su trabajo, un tester no debe casarse con nada ni con nadie, no debe desarrollar dependencias “afectivas” con herramientas, lenguajes, metodologías… que puedan nublar su juicio y alejarlo de su objetivo primordial (ver #fact anterior). Estos instrumentos deben usarse para satisfacer el objetivo de la orden, pero no como objetivo en si mismo.

A su vez, creo humildemente que, un tester lo es para siempre: una vez has puesto tus capacidades analíticas al servicio de la calidad, encontrarás bugs y errores de especificación hasta en la sopa.

#3 – Procedencia:

Los miembros de la guardia de la noche presentan dos origenes muy diferenciados:

  • Convicción: miembros voluntarios de la orden, que consideran la pertenencia orden como un honor y símbolo de la dedicación al deber.
  • Escapatoria: lamentablemente, la guardia de la noche también se presenta como alternativa a la muerte para criminales, exiliados y demás renegados.

Esto nos ha pasado a nosotros también, ha habido testers de vocación y testers “por eliminación”. Por suerte, entre todos, a medida que la profesión gana en complejidad y peso específico, crece el número de testers convencidos y se disipa la tendencia de considerar el testing como una profesión de bajo nivel, cajón de sastre para perfiles desubicados o sin formación.

#4 – Estructura:

Existen tres roles dentro de la guardia, con funciones muy claras…

  1. Exploradores: cuerpo militar dentro de la orden. Defensores, guerreros, entrenados en supervivencia y encargados de patrullar más allá del muro.
  2. Constructores: mantienen y reparan el muro, los castillos y demás propiedades de la orden.
  3. Mayordomos: responsables de funciones criticas como el abastecimiento, comercio, alimentación, utillaje, reparación de armas, cocina…

Más allá de las similitudes con sub-roles que pueda haber dentro de nuestra profesión (los exploradores serían los bughunters o testers funcionales, los constructores podrían ser automatizadores o los encargados de los frameworks de testing y los mayordomos aquellos que se encargan de funciones intermedias como documentación, servir de enlace con helpdesk, producción o business…), me interesa más la idea de fragmentación, de especialización del trabajo según las capacidades y voluntades de cada uno. Todo cuerpo organizado consta de dicha fragmentación y nosotros no somos ni seremos menos. Adicionalmente, la fragmentación y especialización va en la línea de la mayor complejidad de la profesión, algo que apuntan todos los expertos del sector a la hora de reflexionar sobre el futuro del rol, como por ejemplo, en la pasada edición de ExpoQA.

#5 – Anonimato:

En el episodio 6 de la segunda temporada se da una conversación entre Jon Snow (mi favorito) y Qhorin Mediamano sobre lo que implica pertenecer a la guardia de la noche. Este es el corte (alrededor del minuto 1:50, lo siento, sin subtitular) en el que el veterano Qhorin le suelta al novato Snow…

Entiende esto chico: tu muerte será un regalo para los del otro lado del muro. Nadie va a saber nunca qué has hecho, nunca se va a saber cómo has muerto ni tan solo cuál era tu maldito nombre, pero los ciudadanos del reino estarán vivos porque algun bastardo sin nombre al norte del muro entregó su vida por ellos.

Fantástico. Fantástica idea, muy motivadora. Los tropecientos millones de usuarios de las aplicaciones testeadas por testers han podido hacer sus cosas (sus compras, sus ventas, sus registros…) porque, entre otras cosas por supuesto, ha habido una legión de testers que han velado por ellos, para que puedan hacerlo sin problemas, sin fallos de seguridad, sin encontrarse con bugs ni páginas que no existen o enlaces rotos, con una usabilidad aceptable y muchas cosas más, y nunca van a ser conscientes de ello, porque…

…Somos cuervos velando en la oscuridad por la seguridad de los ciudadanos del reino.