La T de Testing

Continuo con los posts sobre habilidades. Esta vez, me gustó la idea de T-Shaped Testers ya que es un buen resumen de lo que comenzó aquí y luego siguió con esta entrada y por último, aquí.

Imaginemos una letra T. La linea vertical de la letra representa las habilidades centrales y la experiencia de una persona. En el caso del testing, pueden cambiar según el contexto, la persona, su trabajo, etc. por lo tanto, cada uno piense las habilidades que le parezcan centrales para un tester.


Por otro lado, la parte horizontal de la T representa la capacidad de la persona para poder trabajar en múltiples disciplinas, usar sus habilidades centrales en otros dominios/roles y también de obtener nuevas desde otras áreas.

A modo de primera conclusión, claramente, aquellas personas T-Shaped pueden verse beneficiadas en su lugar de trabajo dado que pueden cumplir (o potencialmente) múltiples roles.

Sin embargo, quiero hacer un poco más de hincapié en testing y remarcar la importancia que tiene este enfoque en el contexto del testing de software tal cómo venimos comentando hace un tiempo en este blog.

1. Testers T-Shaped son necesarios en la práctica de Testing Agile. Testers involucrados en el producto y en dar valor desde el primero momento, desplegando sus habilidades en T para soporte en múltiples tareas y roles.

2. Testers T-Shaped son más flexibles y se adaptan más rápidamente al contexto y al dominio.

3. Testers T-Shaped comprenden sus responsabilidades.

4. Testers T-Shaped son Testers World-Class.


Testing no es sólo encontrar bugs.

Mind Mapping en Testing

En este último tiempo, en mi trabajo, hemos comenzado a usar mind maps para plantear estrategias y derivar pruebas funcionales. Nos parece una herramienta muy potente para tratar la complejidad del testing y del software.

Un mind map (o mapa mental) es una técnica gráfica que permite representar y relacionar ideas alrededor de una idea central. La característica principal, por la cuál son muy utilizados, es que organizan la información de la misma manera que funciona nuestro cerebro, trabajando sobre sus hemisferios y creando diagramas que son fácilmente recordables.

Para hacer un mapa mental, hay que tener en cuenta lo siguiente:

1. Escribir la idea principal en el centro del diagrama.
2. Los temas importantes debe ser graficados como branches (o ramas), asociados a la idea principal. Cada nueva rama es agregada en el sentido de las agujas del reloj.
3. A cada rama debe asociarse una imagen o una palabra clave.
4. Los temas/conceptos de menor relevancia son incluídos en el mapa como subramas de las ramas principales.

Mind maps para estrategias y diseño de tests


Como ya he comentado, generar un buen plan de pruebas es complejo debido a que no sólo debemos tener en cuenta la funcionalidad a testear sino también cómo ésta se relaciona con otras y su impacto en el software. Aquí, la explosión de combinaciones y escenarios puede ser aún mayor.

Un mapa mental nos permitirá abordar todas estas cuestiones de una manera rápida y simple. Para esto, es esencial que el mind map sea desarrollado, cómo mínimo, de a pares. En caso de ser necesario se puede incluir en el grupo, a algún analista funcional o developer pero sólo para evacuar dudas funcionales puntuales y así mantener a salvo la objetividad de la estrategia.

Pasos:

1. Reunir al equipo.
2. Elegir un moderador.
3. Utilizar una pizarra o alguna herramienta software. Esto último es preferible para mantener la documentación. También es deseable tener un template para no tener que comenzar el mapa desde el scratch.
4. Escribir la funcionalidad a testear en el centro del mapa.
5. Agregar como ramas principales, las categorías para dividir y priorizar la funcionalidad (ej, ABM, seguridad, performance, datos, funcionalidades relacionadas, etc)
6. Empezando por la rama prioritaria, agregar las condiciones de cada prueba como ramas secundarias.
7. Marcar branches prioritarios con colores, números, imágenes.

Algunos beneficios que se obtienen cuando se utiliza esta técnica:

1. Inducción para todos los testers participantes y otros testers.
2. Mayor visibilidad sobre la funcionalidad, su relación con otras y sobre el software en general.
3. Flexibilidad ante cambios en requerimientos.
4. Incremento del coverage.
5. Identificación y priorización de escenarios importantes.
6. Soporte al ciclo de ejecución de pruebas.
7. Documentación.
8. Aumento de la creatividad del equipo.

En resumen, los mapas mentales son muy poderosos, flexibles y bondadosos, no sólo para testing, sino también para tomar notas, hacer presentaciones, tomar decisiones y hasta gestionar tareas.

Fuentes:


Responsabilidad, cambios y motivación: mi carrera

Buscando videos en Youtube, me encontré con un keynote de Alan Cyment en el Scrum Gathering 2012. Lo comencé a ver y la verdad que me enganche.

Cyment comienza dando un enfoque interesante sobre Scrum, cuál es su definición y su espíritu. La charla continua, y luego de contar algunas otras experiencias, hablar sobre las culturas organizacionales, Scrum fingido y otras yerbas, introduce un tema que me pareció muy importante y que me inquieta hace rato. Tiene que ver con el rol del las personas en las organizaciones y puntualmente, en los equipo de trabajo. Aquí es donde me quiero detener ya que, además, coincido bastante en lo que Cyment dice, más allá de alguna que otra postura extrema o solución propuesta. Algo al respecto ya había mencionado aquí.

Lo resumo en las siguientes tres bullets:

1. Debería ser responsable de mi laburo. Un tema que aquí se presenta es: "el problema siempre lo tiene el otro" y, si algo tiene que cambiar, ese no soy yo.

2. Debería poder gestionar mis cambios. Si algo no me gusta, trato de de cambiarlo introduciendo mejoras parciales y continuas o tratando de dar un cambio brusco para que la cosa cambie radicalmente.

3. Debería poder identificar qué me motiva. Cada uno puede tener motivaciones distintas por las cuales está en ese trabajo/empresa/equipo. En general, son casi las mismas (ambiente laboral, estabilidad, dinero, etc) aunque pueden estar en distinto orden de consideración.

Por último, y a modo de apreciación personal, creo que cada uno de nosotros comienza a crecer profesionalmente cuando se hace cargo y responsable de su propia carrera.

Tester World-Class

Luego de haber hablando un poco sobre las responsabilidades y habilidades de un tester, encontré por ahí un tweet que hacia referencia al siguiente post Becoming a World-Class Tester. Me gustó lo siguiente. 

Primero, la definición de Tester World-Class: 

"My definition of a world-class tester is a person who is able to rapidly discover highly relevant information about the product, who makes the most use of any resource that is available to him/her, and who has the respect of people involved in a project. It is a person who can be trusted."

Segundo, habla sobre las skills y mindset de un tester world-class de las cuales quiero rescatar 2 para agregar a la lista publicada aquí:

1. Voluntad para aprender. Testers trabajan con conocimiento. El conocimiento no es estático, por lo tanto, el aprendizaje constante es esencial para mejorar la interacción humano-software.

2. Humor. El humor ayuda a mantener la cordura, principalmente, en ambientes estresantes. También, ayuda a enfocarse sólo en lo que se quiere hacer.