¿Por qué los testers necesitan aprender continuamente?

Últimamente estoy leyendo mucho a Lisa Crispin y Janet Gregory. Esta vez, encontré el artículo "Why Testers and QA Engineers Need to Learn Continuously?". Me parece atinado verter aquí algunos de sus conceptos ya que hacer un tiempo venimos diciendo que los testers trabajan con conocimiento.

1) Expandir tu conocimiento y tus capacidades te posibilitará incrementar tus oportunidades, tanto dentro como fuera de tu organización.

2) Testers quienes eligen aprender, abrir su mente y probar nuevas cosas, son más valiosos para sus equipos. Los buenos testers entienden tanto el negocio como los aspectos técnicos de su producto.

3) El aprendizaje reduce el stress. Invertir tiempo en adquirir nuevo conocimiento permite aumentar la confianza en cómo hacer tu trabajo y, además, hacerlo correctamente.

4) Cuando tu compartes nuevo conocimiento con tu equipo, "desafías" a tus compañeros a pensar nuevas y mejores maneras de hacer las cosas.

5) La sabiduría que da la experiencia combinada con el aprendizaje, el perfeccionamiento de tus skills y la constante actualización sobre las nuevas ideas que surgen desde la industria (y la academia), no sólo te vuelven más "vendible" sino que también te hacen más valorable dentro del equipo en el que trabajas.

6) El aprendizaje continuo te da la posibilidad de formar parte de una comunidad de pensadores que comparten experiencias e ideas que pueden crecer orgánicamente.

Más allá de todos estos puntos, debe existir una motivación intrínseca orientada a comprender las responsabilidades del tester y sus habilidades y a desafiar el status quo.

Germán

Hacer, Equivocarse, Aprender




"Si no te equivocás de vez en cuando, quiere decir que no estás aprovechando todas tus oportunidades."


— Woody Allen


Esta podría ser nuestra motivación para el nuevo año que comienza.


¡Felicidades!

Germán

"We don't know exactly where we'll go but small steps ensure we do not fall down" [1]

Ver el todo de un proyecto es algo que puede parecer simple, pero que necesita de sus herramientas y recursos para poder hacerlo de manera controlada y efectiva.

Hasta aquí, hemos estado hablando mucho sobre agilidad y sus bondades. Sin embargo, aparece el siguiente efecto colateral: perdemos de vista "el todo" del proyecto. Es decir, ¿estamos haciendo lo que realmente debemos hacer?, ¿hacia dónde vamos? ¿dónde estamos parados actualmente luego de finalizar determinadas tareas? Si lo trasladamos a un proyecto de testing, ¿todas las funcionalidades están cubiertas por nuestras pruebas? ¿dónde nos está faltando testing? ¿cómo está el semáforo del proyecto?

Gojko Adzic, en su libro "Impact Mapping: Making a big impact with software product and projects", se encarga de tratar este tema usando los mapas mentales. Adzic, nota que una causa común de la desconexión entre el negocio y el delivery es que los equipos que trabajan en un esquema iterativo, lo hacen sobre pequeñas funcionalidades que tienden a ir por un pipeline sin tener en cuenta su valor para el negocio. Con el foco puesto principalmente en el delivery, los mapas de impacto facilitan esta vista tanto para el negocio como para el equipo técnico y se adaptan bien a los modelos iterativos. Usando mapas de impacto podemos reportar progreso, comprometernos sobre impactos a ser logrados, dar visibilidad y permitir una implementación más flexible.



Para Janet Gregory y Lisa Crispin, "look at the big picture" es uno de los factores claves de éxito según definen en su libro "Agile Testing: A Practical Guide for Testers and Agile Teams". Para ellas, todos los software makers deben mirar el todo del proyecto y usualmente desde el punto de vista del cliente. ¿Qué sucede si una nueva funcionalidad causa que otras no relacionadas rompan? Es necesario considerar el impacto sobre el sistema completo y llamar la atención del equipo sobre esto. Enfocándose puntualmente en testing, Crispin y Gregory proponen evaluar cómo las actuales stories se insertan en el esquema del negocio y preguntarnos a nosotros mismos cómo podemos hacer un mejor trabajo para poder entregar valor real. Usar el cuadrante de testing agile, guiar el desarrollo con tests, hacer testing exploratorio para aprender sobre el negocio, hacer un ambiente de pruebas tan similar al productivo como sea posible, usando datos reales y recrear situaciones en producción, tales como el testing de carga, son algunas de las herramientas que se proponen en el libro.

Personalmente, he puesto en práctica varias de estas herramientas y consejos en mis proyectos. Algunas ya las hemos charlado en el blog y otras las vamos a ir desarrollando en entradas posteriores. Sin embargo, antes de seguir avanzando, creo que es necesario ponernos a pensar si estamos viendo el todo de nuestros proyectos.

¿Ustedes lo están haciendo?

Germán

[1] Frase extraída del libro "Impact Mapping: Making a big impact with software product and projects"
[2] Imagen de http://blog.pablojimeno.com/blog/2013/03/13/london-2013-experience-part-i-impact-mapping-with-gojko-adzic/

Scrum is a Platonic Ideal

Así comienza el camino...

"Scrum: learn from a new start. Kanban: learn from where we are now". 


Si queremos transicionar de una esquema "más Waterfall" a un entorno ágil y no estamos del todo preparados, es recomendable empezar por Kanban. Si bien ya he hablado de esta herramienta en varias ocasiones, me parece importante definir qué debemos tener en cuenta a la hora de aventurarnos en la agilidad desde cero.

¿Se puede combinar Kanban con mi proceso actual? 

Si, y podemos empezar de la siguiente manera.

  • Tablero: comenzamos visualizando nuestro trabajo. ¿Dónde están nuestros cuellos de botella?
  • WIP (Work in Progress): ¿cuánto trabajo podemos tomar en cada etapa de nuestro proceso?

[Video] How do I find the next idea?

Ideas on how to make new questions... Muy buen keynote de Leandro Caniglia en la Smalltalks 2013.




Germán

Kanban Maturity Chart

Hace un tiempo encontré este Kanban Maturity Chart que me pareció muy piola para mediar a nuestro equipo y usarlo en retrospectivas.


Visualize Work:  How well does the team consistently use visualization tools to make the flow of work through the system visible?

Limit WIP: Does the team set WIP limits and use them as a tool for managing flow? Do they review WIP limits, adjust them, and respect them (which is not the same as blindly obeying them)

Manage Flow: How well does the team consistently observe the flow of work using relevant measures as guides in a continuing process of reducing waste, variability, and improving the flow of work through the system?

Explicit Policies: Does the team make policies relevant to the handling of tasks clear and explicit and review those policies as needed?

Improve Collaboratively: How well does the team use models and experiments to test ideas in order to introduce improvements to the process?

Feedback Loops: How well does the team create feedback loops to give both the team and individuals actionable feedback on quality and process?


¿Ya lo probaron? ¿Lo conocían? Espero los comentarios.

Germán