Lo que la 6ta edición del TestingUy nos dejó

Posted on by Federico

En este post te comparto las palabras de Diego Gavilanes, uno de los abstracteros que más entusiasmo demostró por toda su participación en esta 6ta edición del TestingUy, incluyendo el taller de Janet y Lisa (y Melissa) que se hizo al otro día.

Diego nos dejó una reseña de algunas charlas a las que asistió, dejando ver así los principales aprendizajes o aspectos para debatir que nos dejó esta 6ta edición del TestingUy.

Opening Keynote: Agile Testing in Context – Janet Gregory

El evento comenzó con la charla de Janet Gregory, una de las autoras del famoso libro “Agile testing”. No fue una charla de agilismo en sí, sino que habló sobre el impacto que tiene la cultura organizacional de cada empresa y las interacciones entre las personas en aplicar metodologías ágiles en diferentes contextos.

Hizo énfasis en la cultura organizacional y mencionó algunos conflictos que ella ha observado principalmente en empresas grandes, como ser la mala gestión y la burocracia.

Algo a destacar que mencionó Janet fue que es importante saber identificar a qué se deben los problemas de calidad; es decir, si el problema es del equipo de testing o viene desde otro lado. Por ejemplo, cuando se quieren hacer muchas cosas al mismo tiempo, hay muchos proyectos en paralelo pero pocos testers y se le asignan varios proyectos a cada tester. Esto es algo poco eficiente ya que promueve el cambio de contexto. No saber asignar prioridades es un problema organizacional.

Existen también otros problemas que se le presentan al equipo de testing como ser: integración del sistema que estoy probando con muchos otros sistemas, demasiadas dependencias, equipos de testing separados, asumir o no saber a quién preguntarle ciertas cosas.

Janet destacó la importancia y el valor que tiene la planificación, y mencionó dos herramientas que le han ayudado a resolver algunos inconvenientes cuando existen o conviven varios equipos de testing:

  • Un mindmap de testing: este mindmap puede incluir funcionalidades a probar y sus características, condiciones de prueba, y los tipos de testing que se podrían hacer para cada funcionalidad. Sugirió hacerlo colaborativo con integrantes de varios equipos y luego extenderlo. Te permite visualizar, por ejemplo, qué tipos de testing se necesitan para probar determinadas cosas.
  • Una tabla en la cual se agregan las funcionalidades que deben ser testeadas en una columna a la izquierda, y en varias columnas a la derecha los tipos de testing que se podrían hacer, condiciones de prueba, etc. (cada una en una columna diferente). Luego colorea para cada funcionalidad qué tipo de testing o condición de prueba es aplicable o no, y usa colores diferentes para representar el cubrimiento de las pruebas para cada funcionalidad. A continuación se muestra un ejemplo de esta tabla tomado de la charla de Janet:

También comentó ciertos aspectos importantes que hacen la diferencia a la hora de trabajar y ayudan a conseguir los objetivos, como ser:

  • La colaboración entre equipos.
  • La interacción entre las personas de los diferentes equipos.
  • Que todos los equipos entiendan cómo se va a trabajar con los otros equipos. Equipos que no necesariamente son de testing, como puede ser el equipo de desarrollo, otro equipo de testing, el equipo de bases de datos, etc.
  • Compartir el conocimiento, compartir los problemas, compartir la información.

Al final de la charla le preguntaron a Janet cuál es el mayor desafío que ha tenido a la hora de implementar metodologías ágiles, a lo cual respondió que fue hacerle entender a sus clientes que los problemas de calidad no siempre están asociados a un problema en los testers, sino que generalmente las causas de esos problemas residen en el proceso o en algún otro aspecto. Por ejemplo, podría ser que las historias son muy grandes, o que las historias no son testeables, dando lugar así a que los testers tengan complicaciones a la hora de probar. Añadió que le ha pasado que algún cliente la llamó para trabajar con el equipo de testing diciéndole “¿puedes venir a arreglar nuestros testers?”.

Con esta charla me sentí un tanto identificado, ya que me ha tocado estar en organizaciones que cumplen al pie de la letra todas las falencias o problemas que Janet mencionó.

Una charla muy interesante que recomiendo principalmente a personas que se encargan de la gestión de equipos de testing o de cualquier otra gerencia, ya que en cierto modo siempre están relacionadas con el testing en algún punto.

Lo bueno, lo malo y lo feo de trabajar con agile – Alexis Monroy y Marcelo Brinkerhoff

Esta charla me generó muchas dudas y muchas preguntas. En lo personal no me gustó el enfoque que le dieron. Estuvimos conversando bastante sobre el contenido planteado en la charla con distintos colegas, y quizá este fue uno de los mayores aportes: el haber generado debate y reflexión.

Primero que nada, fue un enfoque bastante negativo hacia las metodologías ágiles, en especial contra Scrum, planteando pocos aspectos positivos. Creo que llegaron a conclusiones genéricas a partir de una mala experiencia que tuvieron, y para peor en su discurso queda claro que las cosas negativas que mencionan fueron provocadas por no haber aplicado la metodología en forma adecuada, o por desconocimiento sobre lo que realmente propone la metodología. Una observación muy acertada que realizó un compañero sobre esta charla fue: si la metodología está mal aplicada, entonces no va a funcionar. Si no sé usar un martillo y termino torciendo los clavos que intento clavar, ¿puedo afirmar que los martillos no sirven para clavar clavos?

Por ejemplo, hablaron de sobrecomunicación, o de reuniones que no son productivas. La metodología no plantea tener reuniones no productivas, está en uno generar reuniones eficientes. Está en uno pulir los canales de comunicación. De hecho la metodología lo que plantea es que el equipo debe estar reflexionando continuamente sobre la forma de trabajo y apuntar a mejorarla.

Hablaron en particular de este aspecto cuando alguna persona trabaja en remoto, como que esto ya era un problema que no permitía trabajar en Scrum. Conozco muchos casos de éxito de trabajo remoto o equipos distribuidos. Tal vez lo más recomendable sea que todos los integrantes del equipo trabajen en el mismo lugar físico, sí; pero el hecho de que algún integrante del equipo esté físicamente en otro lugar, no quiere decir que la metodología se vaya a aplicar mal, o que el proyecto vaya a fracasar. Claramente esto trae otros desafíos, pero son los mismos desafíos que hay al trabajar remoto en otras metodologías, como puede ser al trabajar en cascada.

Mencionaron ejemplos no muy claros al hablar de roles de Kanban y de Scrum. Comentaron que la idea es que “todos sean dueños del producto”, cuando en realidad esto no es así. Sí es verdad que todos los integrantes del equipo trabajan para generar un producto de mejor calidad, pero Scrum propone que haya un solo PO (product owner / dueño del producto). La guía de Scrum no menciona nada sobre roles dentro de los equipos, lo único que podría tener que ver es uno de los principios del manifiesto ágil: “Los responsables de negocio y los desarrolladores trabajamos juntos de forma cotidiana durante todo el proyecto”.

Me pareció excelente que resaltaran que “Agile” no es “Scrum”. Es decir, cuando se habla de metodologías ágiles lo primero que se piensa es en Scrum, pero en realidad no es la única metodología ágil, sino que existen otras como Kanban, Extreme Programming, Scrumban, Lean; y ciertos marcos de trabajo como ser DevOps, CI, CD o BDD que complementan si se quiere, a las metodologías ágiles.

Creo que lo que hay que entender para aplicar metodologías ágiles, lo que cada miembro del equipo debe entender, es que se necesita compromiso, integración y comunicación fluída entre cada uno de los miembros del equipo. Lo más importante no son las prácticas sino los valores y los principios (me gustó cómo está explicado en este artículo).

Al final dijeron que “todo lo comentado en la charla, aplicado más o menos bien, en general produce resultados”. No me gustó que se hayan hecho generalizaciones, o que se hayan comentado “cosas malas o feas” de agile en base a malas experiencias. Creo que cualquier tester con experiencia puede discernir entre qué cosas están bien y qué cosas no, pero ¿qué pasa con todos esos chicos jóvenes que recién están arrancando y ven que alguien arriba de un escenario cuenta todo esto? Como comenté más arriba: si aplicamos mal la metodología, entonces no podemos sacar conclusiones sobre qué tan bien o mal funciona.

Testing en tiempos revueltos: técnicas de autogestión – Federico Toledo

Esta charla me resultó super interesante, pero, si bien se comentó que se trataba de un tema tangente al testing, aun así creo que le faltó más contenido relacionado, simplemente por el evento en el nos encontrábamos. Incluso hablando con algunos colegas que asistieron a esta charla me comentaron lo mismo.

Fede nos compartió una variedad de técnicas que nos pueden ayudar a detener la vorágine y a empezar a ordenarse con el fin de ser más productivos y que esa productividad impacte positivamente en nuestra calidad de vida.

Creo que algunas de esas técnicas son aplicables a corto plazo, otras a largo plazo, algunas más difíciles de aplicar que otras, y además serán aplicables o no dependiendo de la realidad de cada persona. Veamos esto con un poco más de detalle:

Técnica que creo aplicable a corto plazo:

  • Reducir distracciones para lograr entrar en estado de flow: el estado de flow es un estado mental (muy productivo) en el que estamos motivados, concentrados y tan inmersos en una actividad que incluso perdemos la noción del tiempo y de lo que ocurre a nuestro alrededor. Para lograr el estado de flow es necesario no tener distracciones. Las diferentes herramientas/artefactos/cosas que nos pueden sacar del estado de flow pueden ser, por ejemplo, las notificaciones del celular, mirar el mail a cada rato, entre otras cosas. Para esto Fede nos recomendó desactivar notificaciones y poner el celular en silencio. Con respecto al celular en particular, me gusto el siguiente comentario que hizo Fede: lo importante es que el celular no me diga “che, préstame atención”, sino que yo decido cuándo ir al celular.

Técnica aplicable a largo plazo:

  • Planificación a largo plazo (anual): creo planificar a largo plazo puede ser difícil por un tema de idiosincrasia principalmente. El propio orador lo menciona en la charla: “no está en nuestra cultura la planificación personal a largo plazo”. A mi criterio, la mejor manera de adoptar esta técnica es hacerlo paulatinamente. Es decir, comenzar a planificar a corto plazo, para luego ir escalando de a poco hasta que seamos capaces de planificar nuestra vida para el año entero.
    • Una estrategia para lograr la planificación a largo plazo es ponerse objetivos en base a propósitos (lo que me motiva), y revisar cada cierto tiempo el avance logrado.
    • Otra estrategia es revisar semanalmente los logros importantes alcanzados en la última semana. La forma de hacerlo sería anotar los logros importantes cuando se alcanzan, y revisar esas notas una vez a la semana. Esto podría revelar si estoy lo suficientemente enfocado para lograr cosas importantes.

Técnica difícil de aplicar:

  • Haciendo que las cosas sucedan: “Getting Things Done” es un método de gestión de las actividades para organizarse con eficacia. La idea de esta técnica es que una persona no tenga que retener en la cabeza todo lo que tiene para hacer.

La técnica consiste en ir tomando notas de las tareas que se tienen para hacer y luego pasarlas a listas, para ordenarlas y poder abordarlas de la mejor manera.

Otra cosa que plantea esta técnica es no tener tiempos muertos, sino tener siempre algo para aprovechar ese tiempo en hacer algo productivo.

Creo que esta técnica es muy buena si se aplica bien, pero a mi criterio es difícil de aplicar debido a los siguientes puntos:

  • Falta de costumbre.
  • Utilizar la técnica requiere mucha disciplina .
  • Tener identificados los métodos que se van a utilizar para tomar las notas y apegarse a ellos (por ejemplo, si decido usar alguna aplicación de notas del celular, o un cuaderno, luego tengo que sistematizar la revisión de estas notas).
  • Procesar sistemáticamente todas las notas que fueron registradas para ponerlas en las listas adecuadas.
  • Saber priorizar las tareas de las listas.
  • No hacer multitasking (demasiadas tareas al mismo tiempo) ya que es ineficiente.
  • Saber identificar lo “no importante” para reducir las listas.
  • Reducir los tiempos muertos.

Además de estas 3 técnicas que mencioné, Fede nos compartió otras también interesantes como ser:

  • Inbox cero (en la casilla de correo).
  • Hacer tareas pequeñas en bloques (como al hacer las compras, conviene hacerlas una vez por semana y no cada dos días comprar unas pocas cosas).
  • Ir “contra-corriente” para ahorrar tiempo (evitar tráfico de horas pico, evitar ir al shopping cuando hay ofertas, etc.).
  • No procrastinar (no dejar lo importante para después).
  • Definir tiempo sin compromisos (por ejemplo: definir un día a la semana libre de reuniones).

Me quedo con la frase “toda optimización que no es sobre el cuello de botella, es una ilusión de mejora“. Vaya si será verdad.

Ready Tester One? Go! – Melissa Eaden

Esta charla de Melissa Eaden me pareció increíble. Me encantó. Según ella misma, la charla está basada en su post Ready, Tester One? *Go!*, el cual invito a que lean ya que está super interesante.

El tema central es sobre el desarrollo de la carrera de un tester y los niveles de habilidades que se pueden tener; de dónde venimos y a dónde vamos.

Por lo general, los testers trabajamos en algún departamento relacionado al producto o al negocio, pero no directamente en testing. Y habitualmente, luego de pasar por testing y adquirir ciertas habilidades, terminamos siendo desarrolladores, gerentes de producto o similar. Esto sucede porque cuando alguien es muy bueno en testing termina recibiendo alguno de los cargos mencionados como una “promoción de cargo”; como si fuera un paso más en la carrera laboral. Pero ¿por qué no puedo continuar mi carrera siendo tester si eso es lo que me gusta?

Melissa planteó la cuestión general sobre “si no se codificar, entonces no soy un tester técnico”. Según ella esa es una visión errada ya que existen muchas otras habilidades técnicas como por ejemplo saber interpretar un código de error http.

En su post Ready, Tester One? *Go!* describe los 5 niveles (y las respectivas habilidades necesarias) que ella cree existen en la carrera de un tester.

Hace bastante tiempo tenía una pregunta rondando en mi cabeza, que resurgió no hace mucho charlando con algunos compañeros del equipo de testing en el que trabajo. Esta pregunta fue la que le formulé a Melissa al final de su charla: “¿Cualquiera puede ser tester?”. La respuesta de Melissa fue muy buena: “Cualquiera puede hacer testing, pero solo un tester puede hacer un buen testing”.

Diego con Melissa luego del workshop

Testers as Test Consultants: how to learn the skills? – Lisa Crispin

Tal y como lo dice su título, la charla de Lisa se centró en los testers como consultores en testing; qué habilidades son necesarias para ser un consultor, cómo aprenderlas, cómo compartirlas y cómo ayudar a otros a que las aprendan. Por ejemplo: habilidades de comunicación, saber compartir ideas, facilitar la comunicación entre los integrantes del equipo, entre otras.

Para aprender estas habilidades recomendó el autoaprendizaje (leer libros, ir a conferencias o meetups relacionadas al tema, aprender enseñando) y también acercarse a los compañeros de equipo para conocer sus habilidades, acercarse a los especialistas técnicos, a los diseñadores y a los Product Owners.

Lisa mencionó algunos inconvenientes y desafíos comunes que se tienen en los equipos de trabajo y cómo nosotros podemos ayudar a superarlos oficiando de consultores, compartiendo y transfiriendo nuestros conocimientos, incluso a personas del equipo que no son testers.

Dio algunas ideas de ciertas habilidades que podemos transferir al equipo oficiando de consultores, como por ejemplo: tener una charla sobre calidad de software, hablarle al equipo sobre el Definition Of Done, enseñar sobre el lenguaje que se utiliza en testing (terminología), enseñar sobre “la curiosidad del tester”, el dominio que se debe tener sobre el negocio, y todos esos menesteres que a los testers nos viene bien saber a la hora de ejecutar pruebas para medir la calidad de un producto de software.

También mencionó algunas habilidades propias de testing que se pueden transferir, como ser: testing exploratorio, creación de escenarios, planificación, cubrimiento y datos de prueba.

Otros aspectos que podemos transferir a nuestro equipo como consultores en testing son “maneras de construir calidad” como ser: planificar la implementación de nuevas funcionalidades, análisis del uso del software con el fin de mejorarlo, o analizar riesgos para identificar dónde enfocar las pruebas.

Una técnica que mencionó Lisa como forma efectiva de trabajo fue la técnica “3 amigos” para generar entendimiento compartido. Esta técnica se puede aplicar en la pre-planning (refinement, grooming o como le suelan llamar), por ejemplo. Los “3 amigos” podrían ser integrantes del equipo de desarrollo, del equipo de negocio (business), y del equipo de testing, aunque si es necesario podrían participar integrantes de otros equipos como diseño o infraestructura.

Una habilidad de la que Lisa habló y me llamó la atención fue la “observación”. Esta habilidad consiste en que cuando  surge un inconveniente en el equipo de trabajo, ya sea de la metodología, de tecnología, de los procesos utilizados, etc., es útil “observar el problema desde afuera” (esto quiere decir, por ejemplo, escuchar las diferentes opiniones dentro del equipo al respecto) y  luego dar feedback para ayudar a resolver el problema. Me di cuenta de que esto lo he hecho por inercia, y en ocasiones ha sido un valor agregado importante al equipo.

Compartiendo el Sombrero del Testing – Claudia Badell

Claudia nos habló sobre los distintos desafíos que se presentan (y 5 lecciones aprendidas) cuando se quiere incorporar testing en un equipo interdisciplinario y adoptar las pruebas de software como parte de la cultura.

Los desafíos:

  • Por dónde empezar; qué hacer para poder comenzar a incorporar testing en mi equipo interdisciplinario.
  • Descubrir cuáles son las habilidades del equipo y cómo potenciarlas para aprovecharlas al máximo.

Las lecciones:

  1. Construir un entendimiento común sobre testing a nivel de equipo: es importante tener un mismo lenguaje para que exista buena comunicación.
  2. Adaptar las estrategias de pruebas a estrategias de equipo: adaptar las estrategias de testing a todo el equipo para que, para quienes su área de expertise no es testing, puedan ejecutarlas y disfrutarlas.
  3. Tener un entendimiento común sobre el criterio “Done”: que el equipo esté alineado para saber cuándo algo está hecho. El equipo de Claudia basa su criterio “Done” en: Complejidad de la funcionalidad, riesgo de la solución y valor de la funcionalidad desde la perspectiva del negocio.
  4. Ser dueño de tu proceso de trabajo: que cada integrante del equipo conozca el proceso de trabajo, vea las oportunidades de mejora y las aplique según las necesidades del equipo.
  5. El testing es una responsabilidad del equipo y no solo de quien ocupa el rol de tester: el tester es un facilitador y evangelizador de las pruebas.

En esta charla Claudia ofició de consultora y nos dió ciertos tips que podremos aplicar según nuestra realidad.

Hay que tener en cuenta que estas lecciones fueron aprendidas por Claudia en su experiencia como tester, pero a la vez tener en cuenta que tiene 13+ años de experiencia en el área y un alto nivel de seniority. Si lo dijo Claudia, entonces es verdad y funciona.

Me encantó la frase con la que Claudia terminó su presentación: Keep calm and enhance your team testing culture.

Misceláneas

En términos generales ¡el evento fue un éxito! Tuvimos un abanico de talleres y charlas para todos los gustos.

Creo que las charlas de Janet Gregory, Melissa Eaden, Lisa Crispin y Claudia Badell se complementan a la perfección debido a su contenido.

Personalmente el evento me encanta, me deja muy emocionado, me motiva, me alienta y me dice que elegí el camino correcto dentro de la informática.

Tuve la oportunidad de aprender un montón, de conocer colegas de otros países, de encontrarme con compañeros de Abstracta que aún no conocía personalmente, y de re-encontrarme con ex-compañeros de trabajo, para charlar sobre esto que tanto nos gusta y nos apasiona: el Testing.

Si no tuviste oportunidad de asistir a la 6ta edición del TestingUy este año, asegurate de planificar tu calendario para asistir a la 7ma edición el año que viene.

Afortunadamente todos pueden ver las charlas impartidas en el evento en el canal de YouTube de TestingUy. En las próximas semanas estarán disponibles los videos de cada charla por separado.

Para más información sobre TestingUy podés visitar testinguy.org.

Posts relacionados:

Comentarios sobre la primera edición del Taller de Técnicas de Testing para Equipos Ágiles Nueva edición del Taller de Testing para Equipos Ágiles – Montevideo, Uruguay Bug: Falla informática dejó a unos 8.000 jubilados sin cobrar Salto presente en TestingUy

Leave a Reply

Your email address will not be published. Required fields are marked *