¿Por qué los testers necesitan aprender continuamente?

Posted by German on 31.12.13 with 2 comments
Ú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

Posted by German on 30.12.13 with No comments



"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]

Posted by German on 26.12.13 with 2 comments
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

Posted by German on 9.12.13 with No comments

Así comienza el camino...

Posted by German on 7.12.13 with No comments
"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?

Así comienza el camino...


Germán

[Video] How do I find the next idea?

Posted by German on 4.12.13 with 2 comments
Ideas on how to make new questions... Muy buen keynote de Leandro Caniglia en la Smalltalks 2013.




Germán

Kanban Maturity Chart

Posted by German on 2.12.13 with No comments
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

LEAN

Posted by German on 28.11.13 with No comments

Necesitamos tener un tablero y una metodología, como sea!

Posted by German on 5.11.13 with No comments
A menudo sucede que me encuentro hablando con gente que piensa que hacer algo agile es implementar un tablero y con eso ya está (me ha pasado mucho en los últimos 3 o 4 meses). Verdaderamente, están haciendo algo: visualizando su trabajo en curso, sus lista de tareas y sus desvíos. Lo cual no es poco, pero...

El furor por las metodologías ágiles es tal que por momentos algunas organización necesitan aplicarlas a cualquier precio, cómo sea. Quizás sea un problema de "vacío metodológico" en dichas organizaciones, potenciado por el hecho de que algunos frameworks tiene pocas reglas, son "relativamente simple" y el tiempo de aplicación es corto. También, muchas veces existe una especie de "bajada de línea" de las gerencias sin permitir a sus equipo madurar y hacer crecer organicamente su necesidad de trabajar en un esquema colaborativo, iterativo y con todo lo que eso significa.

En conclusión, las metodologías ágiles son fáciles de aprender (son frameworks con pocas reglas) pero difíciles de aplicar correctamente. Sin embargo, pienso que también se han vuelto populares debido a que las organizaciones (no todas, pero bastantes) tienen este "vacío" que muchas veces atenta contra su buen uso.

Germán


Basta de "Dev vs. QA"

Posted by German on 28.9.13 with 12 comments
Uso Feedly para gestionar los post de los blogs que sigo. Diariamente, hago una selección de artículos para leer en el momento y otros los guardo para chusmearlos luego. Esta selección la hago por categoría, nombre de autor (algunos leo con más frecuencia que otros) y también hago selección por título. 

En este contexto, todos los días me encuentro con que aún se sigue escribiendo (bastante) sobre la "rivalidad", "diferencia", importancia de los testers por sobre los developers o viceversa. A esta altura del partido, creo que este debería ser ya un tema superado. Por esta razón, es que he decidido no leer más artículos con estos contenidos. Títulos tales como "Developers vs. Testers", "¿Por qué los programadores 'odian' a los testers?", "El espíritu destructivo de los testers" están para mi obsoletos. Opino que ambos (devs y testers) deberían estar bajo un mismo rótulo: software makers, o simplemente software developers. Ya no tiene mucho sentido volver sobre lo mismo y debería ser un tema superado en la comunidad del software. Hay que pasar al siguiente nivel de la discusión.

Germán

¡Feliz día del Tester!

Posted by German on 9.9.13 with No comments

Hacer testing es también capturar conocimiento - otra vuelta

Posted by German on 19.8.13 with 4 comments
El post anterior sobre este tema hizo bastante ruido. Recibí muchos comentarios/opiniones al respecto y me pareció interesante dar "otra vuelta". En realidad, esta vez es para dividir en un par de tracks los comentarios que recibí y "generar más conocimiento":

1. Testing Agile: hace un tiempo escribí sobre los principios propuestos en este libro, y efectivamente, de alguna manera, la idea expuesta en el post tiene implícitos estos principios.

2. Cualquiera puede hacer Testing: sinceramente, me cuesta creer en esto. He trabajado con gente que no es del palo y han tenido un excelente desempeño. Sin embargo, hay cuestiones técnicas, de análisis, gestión, etc. en las cuales hay una clara ventaja del informático. Seguramente en testing funcional es más factible,  pero si queremos ir en esta dirección deberíamos apuntar a gente informática, sin dudas. En otro momento, retomaré el tema.

3. El Testing no puede automatizarse completamente: No puedo estar más de acuerdo con esta afirmación. No hay dudas. Lo que sí surge aquí es, ¿qué automatizar y qué no?, ¿qué herramientas son las adecuadas?

4. Un fail como puerta de entrada hacia más conocimiento: Un bug permite a los developers explorar escenarios, situaciones, y código aún no explorado y con un fuerte impacto (potencial) en la funcionalidad de software. La forma operativa de capturar conocimiento en testing es a través de un bug.

Para terminar, no deja de sorprenderme la cantidad de comentarios y de gente que tiene las mismas inquietudes. Los lectores son como los testers que ayudan a generar más conocimiento en este blog!

Les dejo unos links a los comentarios que recibí -> 1, 2, 3, 4

Talent Pool

Posted by German on 15.8.13 with 5 comments
Hace unos días, en mi trabajo, estuve presenciando una charla interesante sobre NoSQL. El orador era Cristobal Pedregal Martín. Sinceramente, no conocía mucho sobre el tema y, por lo tanto, no voy a entran mucho en detalle sobre el concepto en este post. Más allá del tema en cuestión (del cuál podemos tener una vaga idea o no saber nada al respecto), estas exposiciones son oportunidades para abrirse a nuevos conocimientos y relacionarlos con otros ya existentes. Personalmente, en estas charlas me fijo mucho en cómo está estructura la presentación, qué ejemplos se usan para explicar los conceptos y cómo el orador se dirige a la audiencia. Cómo hacer una buena presentación no es un tema que esté en condiciones de abordar profundamente, sin embargo, creo que hay que entrenarse al respecto para saber hablar delante de una audiencia.


Volviendo a la charla, y a lo que motivó esta entrada, quería mencionar lo que Pedragal Martín nombró como Talent Pool. La traducción es simple. Sin embargo, me interesó el contexto en el cuál lo comentó. Promediando la presentación, Martín repasaba algunos riesgos asociados a implementar un sistema NoSQL. Decía que es necesario tener en cuenta el costo capital (Capex), el costo operativo (Opex), si el sistema es propietario o si es Open Source y, por último, si existe gente capacitada en esta tecnología o si es necesario atraer a jóvenes promesas para capacitarlas. Inmediatamente, relacioné esto último a un tema actual, complejo y crítico, y que tiene que ver con la poca gente especializada que existe en el ámbito de la Informática. Lo digo en relación a la necesidad actual de profesionales informáticos y cómo de ellos depende el desarrollo de una "identidad tecnológica" como país. Claramente, esto no es algo nuevo y en estos enlaces hay algunas muestras de ello:

Estudiar Computación,
Las posiciones de trabajo más dificiles de cubrir,
La escasez de profesionales, y
Hay que estudiar informática

Como conclusión, está claro que para desarrollar nuevas tecnologías e innovar, es necesario tener este talent pool impulsado por la "profesionalización" de la Informática como disciplina y por la necesidad de definir esta "identidad tecnológica". Es también nuestra responsabilidad promover esta especialización.


Imagen: http://www.insightfororganisations.co.uk/talent-management/

Hacer testing es también capturar conocimiento

Posted by German on 27.7.13 with 5 comments
Varias veces he escuchado la siguiente frase: "Los desarrolladores tiene un pensamiento constructivo y los testers tienen un pensamiento destructivo". Esta falacia se está derrumbando con el paso del tiempo (por suerte). Los testers también construyen, nada más ni nada menos que calidad. Ernesto Kiszkurno ya habló de esto en su blog.

En esta dirección, la dependencia de la gente en el software es cada vez mayor y, por lo tanto, este tiene que ser cada vez más confiable. Debe resolver el problema para el cual fue construido. Leandro Caniglia siempre me dice que para él, construir software es capturar conocimiento y que los testers son el complemento indispensable en la cadena de valor. Es decir, los testers también participan en la captura del conocimiento tan importante a la hora de modelar dominios reales y, por lo tanto, complejos.

En conclusión, es hora de integrar definitivamente a los testers y a los developers para que ambos colaboren desde las fases tempranas de un producto. El testing NO debe ser una etapa en el ciclo de construcción de software sino que debe ser una actividad parte del criterio de "Done".

"Tested is part of 'Done'"

 [1] La imagen fue extraída del blog http://www.agilebuddha.com/

No revisaré mails al inicio del día

Posted by German on 18.7.13 with No comments
Aquí les dejo la justificación científica de por qué es interesante tratar de implementar el lema "Stop Starting, Start Finishing". 

El video "La razón sobrevaluada", de Estanislao Bachrach en la TEDxRíoLimay del 2012 (en Septiembre de 2013 es la segunda edición), deja algunas perlitas:

1. Revisar mails al inicio del día consume mucha energía.
2. Dejar las actividades que nos consumen más energía para cuando estamos más descansados.
3. Priorizar
4. Visualizar
5. Escribir nuestros proyectos/ideas/compromisos para no tenerlos en nuestra cabeza constantemente.
6. Querer ser más productivos, nos hace improductivos.




Limitar nuestro WIP en pos de tomar mejores decisiones.

Mapas de Impacto

Posted by German on 13.7.13 with No comments
Estoy leyendo el libro de Gojko Adzic, "Impact Mapping: Making a big impact with software product and projects". Me tiene bastante entretenido. Es un tema que está haciendo mucho ruido.

Personalmente, estoy intentando trabajar con mapas mentales desde hace un tiempito. Creo que es una herramienta potente que puede aplicarse a diversos dominios, tareas y/o problemas que tengamos que resolver. Sobre una aplicación puntual ya he escrito aquí.

Un mapa de impacto es un mapa mental que permite a los equipos y a las organizaciones visualizar alcance y asunciones relacionadas a algún objetivo que se intente lograr. Supongamos que, en nuestro contexto, es construir un producto software. Estos mapas son creados de manera colaborativa por todos los involucrados e interesados en lograr la meta que los convoca (obviamente, esto es una situación ideal). La gran ventaja de estos mapas: permiten tener controlada la big picture de nuestro proyecto, tener en claro a dónde queremos ir, cómo llegar y a quiénes debemos involucrar.

Durante la creación de una mapa es necesario responder a las siguientes preguntas:

  • WHY? Es el centro del mapa.  Es la meta que se está tratando de lograr. Una buena meta debería ser SMART (Specific, Measurable, Action-oriented, Realistic and Timely) y presentar el problema ha ser resuelto.
  • WHO? Este nivel indica quienes son los actores que pueden influenciar el resultado. Quién puede producir el efecto deseado, quién puede obstruirlo y quién será impactado. Debe ser lo más específico posible.
  • HOW? Explicita el impacto que se trata de crear. Cómo debe cambiar la conducta de los actores y cómo pueden ayudar a lograrlo. Especificar estos impactos permite priorizar e identificar riesgos. 
  • WHAT? El último nivel del mapa es el nivel de los entregables. Qué puede hacer el equipo o la organización para dar soporte al impacto. Puede contener varios niveles más y no necesariamente deben completarse desde el inicio. Puede ser refinado de manera iterativa.

A modo de ilustración, hice el siguiente mapa de impacto usando la herramienta MindMup. Espero que se animen a aplicarlo y a compartir la experiencia :) Voy a seguir escribiendo sobre el tema a medida que avance con el libro.


Tener +500 visitas en una entrada sobre Mapas de Impacto on MindMup

Stop Starting, Start Finishing

Posted by German on 10.7.13 with 6 comments

Hace tiempo que encontré este slide de Henrik Kniberg. Traté de implementarlo (y aún lo intento) pero algunas cuestiones son un poco más complejas. En el día a día, uno tiende mucho al multitasking y a salir corriendo atrás de las cosas que deberían haberse hecho para ayer. 


En fin, admiro a la gente que sabe decir NO y que puede tener su WIP controlado...

Algunas fotos del curso CSM

Posted by German on 16.6.13 with No comments
Los días Lunes 10 y Martes 11 de Junio hice el curso para la certificación Scrum Master (CSM). ¡Estuvo excelente! Muchas cosas para masticar...

Muchas gracias Alan Cyment, Diego Fontdevila y Verónica Sack. Aquí algunas fotos:

Una experiencia aplicando Kanban en Testing [Parte 1]

Posted by German on 21.5.13 with 4 comments
Hace unos días rearmamos el tablero Kanban de un proyecto de testing en el que estoy actualmente trabajando. La experiencia fue interesante ya que debíamos explicar el tablero y los conceptos principales de esta metodología a integrantes nuevos del equipo. Esto nos obligó a repasar, hacernos preguntas, definir nuevos criterios y generar discusiones en el grupo.


Proyecto


Servicio: Testing Funcional
Equipo: 3 personas (1 diseñador de casos y 2 ejecutores)
Objetivo: Agregar valor al producto manteniendo el equipo asignado a tareas productivas

Implementado Kanban


Hicimos una reunión con el equipo en la que discutimos los siguientes puntos (notar que algunos pueden ser muy generales y otros quizás más específicos del proyecto):

1. ¿Qué es Kanban?

Como definición general, es una técnica que se usa para gestionar el proceso de desarrollo de software de una manera eficiente. Kanban es una palabra japonesa que puede traducirse como tablero visual o sistema de tarjetas. 

2. ¿Cuáles son las reglas de la metodología?

- Visualizar el flujo de trabajo: dividir el trabajo en tareas/items/funcionalidades/necesidades, escribirlas en una tarjeta (post-it) y pegarlas en un tablero. Usar columnas etiquetadas con las etapas de nuestro proceso para indicar dónde, cada item, está en dicho proceso.

- Limitar el trabajo en progreso (WIP): asignar un límite explícito a cuántas asignaciones pueden estar en progreso en cada etapa del workflow.

- Medir el "lead time": (tiempo promedio para completar un item) optimizar el proceso para hacer el lead time tan pequeño y predecible como sea posible.

3. ¿Para qué armamos un tablero? ¿Qué información nos brinda?

El tablero es la foto del proyecto. Necesitamos visualizar su estado actual, tareas en curso, manejo de asignaciones, limitaciones, "cuellos de botella", problemas y mejoras para optimizar el proceso. Además queremos favorecer la autogestión del team, balancear necesidades e incentivar la participación, colaboración y expresión de todos sus miembros.

4. ¿Lo hacemos?

Las columnas etiquetadas con las etapas del proceso dependen del proyecto. En este caso, diseñamos el tablero de la siguiente manera:

- Backlog: lista de necesidades que deben ser testeadas, ordenadas por prioridad.

- En Definición: features en esta etapa están en definición de estrategia y diseño de casos de prueba.

- En Cola de Ejecución: los casos para la funcionalidad fueron definidos y están esperando la ejecución.

- En Ejecución: la ejecución de casos comenzó.

- Finalizado: la funcionalidad ya fue testeada (*)

5. ¿Cómo lo mejoramos?

- Fila EXPRESS: puede darse el caso de que nuevas funcionalidades tengan prioridad por sobre las planificadas inicialmente. Esto (a veces) implica dejar de trabajar sobre las que están en proceso y, por lo tanto, es necesario definir un segmento express por donde "circulen" estos items con mayor prioridad.

- Fila BLOQUEADOS: por aquí van las features que no pueden avanzar en nuestro proceso. Esto puede deberse a falta de documentación (bloqueado en definición de casos), funcionalidad no implementada (bloqueada esperando ejecución) o bugs invalidantes (bloqueado en ejecución). Además, este segmento funciona como segundo ciclo de pruebas con funcionalidades que pueden volver a priorizarse cuando son desbloqueadas.


Por último, luego de haber diseñado el tablero del proyecto, el equipo comenzó a discutir sobre cómo trabajar con el workflow definido, qué información debemos registrar para mantener trazabilidad, cómo medir, el work-in-progress y algunos criterios de aceptación (*). Todos estos puntos son motivo de la Parte 2 de esta experiencia.

Fuentes:

 Foto: http://blog.crisp.se

1. http://www.kanbanblog.com/explained/
2. http://www.fuerzatres.com/2011/07/trabajar-sin-estres-kanban.html
3. http://www.fuerzatres.com/2011/03/kanban.html
4. http://www.xqa.com.ar/visualmanagement/tag/kanban/
5. "Kanban and Scrum: making the most of both" Henrik Kniberg y Mattias Skarin

Agile is in the air

Posted by German on 12.5.13 with No comments
Ayer 11 de Mayo participé en el segundo encuentro del "Agile is in the air". La filosofía de estos encuentros es, básicamente, hablar de agilidad al aire libre. En el caso de ayer, la temática era "Juegos para transmitir la agilidad".

Comenzó con un Open Space para definir los temas a tratar. De aquí salieron 3 tracks con es el siguiente orden luego de una votación tipo twister: "Scrum con el cuerpo", "Gamification de Scrum" y "Juegos para retrospectivas". Sólo se trataron las dos primeros.

Les dejo el video del primer track "Scrum con el cuerpo" (faltan los subtítulos) . La idea de esta sesión era representar los roles, artefactos y encuentros de Scrum usando el cuerpo y la voz de manera que sea más fácil trasmitir y recordar las reglas del framework.




Finalmente, durante el segundo track se delineó una aplicación para gamificar equipos ágiles.

Estuvo muy bueno. Espero poder participar del próximo.

El condensador de flujo para nuestros proyectos

Posted by German on 13.4.13 with No comments
Sin bien la película no aclara cómo funciona exactamente, el condensador de flujo consiste en una caja con tres pequeñas lámparas incandescentes centelleantes (nuestras prácticas QA, ágiles y de desarrollo), colocadas en forma de "Y", y situada detrás entre los asientos de la máquina del tiempo. Cuando el automóvil (nuestro proyecto) se aproxima a una velocidad de 88 millas por hora (140 km/h), la luz que emiten las lámparas del condensador de flujo destellan con más rapidez, hasta emitir una luz constante (flujo constante de prácticas). Entonces el condensador se activa posibilitando el viaje en el tiempo.

Si logramos incorporar buenas prácticas a nuestro equipo y a nuestros procesos a medida que el proyecto alcanza 88 millas por hora, vamos a viajar al tiempo del "buen" software. Es el espacio/tiempo donde habitan los productos de calidad, aquellos que realmente aportan valor y desarrollados por equipos altamente motivados y skilled.

En cambio, si no logramos incorporar estas buenas prácticas a nuestro equipo y a nuestros procesos, viajaremos al tiempo del software de baja calidad, con equipos estresados y con poco valor para aportar.


Condensador de Flujo


Nota 1 (para nostálgicos): aquí dejo el momento en el que el Doc le hablaba a Marty sobre cómo viajar en el tiempo y por qué es posible aplicar esto al desarrollo de software :)




Nota 2: No creo que existan las "mejores prácticas" ya que su aplicación efectiva depende 100% del contexto en el cual serán aplicadas. Prefiero usar el concepto de "buenas prácticas" e involucrar el concepto de "contexto". Algunas prácticas pueden ser buenas para un determinado contexto y no tanto para otro.

Agile: 6 preguntas a Thomas Wallet de Pragma Consultores

Posted by German on 5.4.13 with 1 comment

Último post de la serie de entrevistas que comenzó con Leandro Caniglia, sobre desarrollo de software, y siguió con Ernesto Kiszkurno, sobre testing. Esta vez estuve charlando con Thomas Wallet, de Pragma Consultores, sobre "el mundo de la agilidad".

German Braun (GB): ¿Podría decirme, en pocas palabras, qué es "ser ágil"?

Thomas Wallet (TW): Para mi, ágil es una búsqueda, más que un estado. "Ser ágil" es estar buscando constantemente la mejora del trabajo en equipo, cuidando particularmente el compromiso con la transparencia, la auto-gestión, el desarrollo de las personas, la entrega frecuente y el feedback constante. 

GB: ¿Por qué usa y pregona el uso de metodologías ágiles?

TW: Primero, estoy personalmente muy alineado y convencido de los valores que suelen sostener las prácticas ágiles que conozco. Y segundo, porque estoy íntimamente convencido que muchas empresas funcionan mal y/o no permiten un desarrollo sano de las personas, problema al cual, la implementación de ciertas prácticas y valores ágiles, puede dar buenas respuestas. 

GB: ¿Cuáles son los mayores desafíos a la hora de implementar una metodología ágil?

TW: La resistencia al cambio de paradigma es una característica humana que suele ser la principal dificultad de las implementaciones de prácticas ágiles que he vivido. En particular, la cultura organizacional que suelen tener muchas empresas choca con los principios de transparencia y auto-gestión.

GB: ¿En qué ambientes considera que son más exitosas estas metodologías?

TW: No veo límites para la aplicación de las prácticas ágiles  Si bien son más usadas y conocidas en el desarrollo de software, se extienden cada vez más en otros dominios. Suelen ser exitosas en ambientes dinámicos con mucha presión sobre el time-to market (startups, proyectos de desarrollo en crisis, etc.). Si nos referimos al modelo de cultura organizacional de William Schneider, suele ser más sencilla la implementación de prácticas ágiles en organizaciones de Colaboración y/o Crecimiento que en organizaciones de Control y/o Capacidad.

GB: ¿Cuál es el futuro del "movimiento ágil?

TW: Creo que vamos a vivir en la próxima década una explosión de la aplicación del agilismo en otras especialidades que el desarrollo de software, al mismo tiempo que las prácticas van a ser cada vez más mainstream en el desarrollo. 
Creo que es necesario que se re-inventen nuevas metodologías ágiles, ya que las principales (Scrum, XP) rondan los 20 años de existencia. Me atrevo a predecir el futuro nacimiento de metodologías ágiles minimalistas (pocas reglas), centradas en la gestión de MMFs (Minimum Marketable Feature) y en la mejora continua. 

GB: Por último, ¿podría recomendarnos algunos blogs, podcast o libros para lectores interesados?

TW: Últimamente me interesan mucho los blogs de Tobias Mayer (http://businesscraftsmanship.com/), John Somez (http://simpleprogrammer.com/) e Yves Hanouille (http://www.hanoulle.be/).

Y dos libros que fueron mi puerta de entrada al mundo de la agilidad (aunque no sean reconocidos como libros ágiles): 
- Peopleware: Productive Projects and Teams, de Tom DeMarco y Timothy Lister
- Project Retrospectives: A Handbook for Team Reviews , de Norman Kerth



Sobre Thomas Wallet

Thomas es consultor en Pragma Consultores, con amplia experiencia en aplicación de metodologías ágiles en diferentes proyectos. Además, es autor del blog "el próximo paso".


¡Gracias Thomas!

La T de Testing

Posted by German on 28.3.13 with No comments
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

Posted by German on 17.3.13 with 4 comments
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

Posted by German on 11.3.13 with 4 comments
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

Posted by German on 2.3.13 with 2 comments
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.

Testing + Pensamiento Lateral = "Testing Lateral"

Posted by German on 23.2.13 with No comments
El testing es un proceso intelectual desafiante y por ende requiere, entre otras cosas, de una dosis importante de creatividad. Esto se practica, se entrena.

Un tester que entrena sus habilidades e incorpora nuevas se diferencia claramente del resto. Todos en el equipo podríamos testear sin problemas, pero aquel con una mayor actitud y predisposición para responder ante las diferentes situación, incluso aquellas triviales, es quién llevará la delantera.

Pensamiento Lateral


En vacaciones, leí "El Pensamiento Lateral" de Edward De Bono. El libro es muy recomendable, y tiene una serie de técnicas que ayudan a "practicar" el pensamiento lateral además de incluir algunos ejercicios para tal fin.

De Bono afirma que usar pensamiento lateral no implica dejar de lado el pensamiento lógico/vertical, sino que es un complemento de este y que, además, nos ayuda a romper con ciertos modelos preestablecidos. Algo así como "barajar y dar de nuevo" nuestros modelos mentales. El pensamiento lateral de aplica en una fase anterior a la acción del pensamiento vertical. Se usa para reestructurar los enfoques de una situación determinada y las ideas que sirven de base. Luego estos enfoques e ideas pueden ser desarrolladas por el pensamiento vertical.

Me pregunto si será posible aplicar alguna de estas técnicas para entrenar y fortalecer las skills de los testers, por ejemplo, en algún Dojo de Testing. Lo voy a intentar exponiendo técnicas y profundizando sobre este enfoque en sucesivas entradas. Espero que resulte algo novedoso e interesante como para experimentarlo.

Testing Lateral


Llamemos a este enfoque: "Testing Lateral". Se trata, principalmente, de aplicar técnicas del pensamiento lateral para mejorar las habilidades de los testers. Este enfoque no intenta cubrir todo el rango de posibles habilidades que se consideren ya que para las habilidades que son técnicas o muy especializadas, se requiere de la aplicación de conocimientos adquiridos.

El testing lateral intenta trabajar sobre algunos aspectos soft de los tester, es decir, aquellas habilidades que hacen a su mindset, a su creatividad y su meticulosidad (algunas otras habilidades las detallamos aquí). Esto les permitirá considerar diferentes enfoques al momento de resolver cualquier situación que se presente. 

Como notarán, el enfoque es simple. De ahora en más, sólo resta conocer algunas técnicas y ejercicios para ver si funciona. Las siguientes son algunas de las técnicas (un subconjunto de las propuestas por De Bono es su libro) que vamos a probar bajo este enfoque, siempre tratando de poner en práctica las habilidades de los testers: 

1. Revisión de supuestos
2. Alternativas
3. Ejercicios de dibujo
4. Fraccionamiento o división
5. Inversión
6. Brainstorming
7. Analogías


Técnica 1: Revisar Supuestos


La primer técnica que vamos a ver es la revisión de supuestos. Es simple y está relacionado a la manera en la que axiomatizamos los conceptos y las ideas. Dar algo por supuesto (supuestos lógicos que se aceptan por válidos en sí mismos), nos ayuda a construir un modelo sobre esto sin preocuparnos, muchas veces, por las cuestiones triviales. Además, la aceptación de que una idea sea correcta, no garantiza su corrección. 

Práctica para el dojo:

Ejercicio: El siguiente problema ilustra muy bien el factor restrictivo de los supuestos. Consiste en unir los nueves puntos mediante sólo 4 líneas rectas pero sin levantar el lápiz del papel.




Ayuda: El factor que bloquea la solución es que las líneas rectas han de unir los puntos sin exceder los límites de los propios puntos. Los invito a que intenten resolver el ejercicio.

En testing, hacer muchas suposiciones puede ser peligroso. Estas pueden estar asociadas, por ejemplo, a la estandarización de ciertos sistemas. La interface de una aplicación es la misma para todas las ventanas, funciona de la misma manera que el resto y, por ende, lo hace bien. En conclusión, la revisión intenta demostrar que cualquier supuesto puede ser sometido a examen. Claramente, esta técnica no intenta revisar todos los supuestos posibles. No sería aplicable y rentable para ningún proyecto. Sin embargo, para un tester, tener este pensamiento crítico es fundamental. Como ya dijo Jerry Weinberg: "A tester is someone who knows that things could be different". 

Habilidades de un tester: el quid de la cuestión...

Posted by German on 18.2.13 with No comments
Según la RAE, habilidad es la capacidad y disposición de una personal para hacer algo. Generalmente, esto es resultado de experiencia, entrenamiento y, en algunos casos, sólo es una capacidad natural.

Un tester debe tener ciertas habilidades para desarrollar su trabajo, algunas habilidades técnicas (también las vamos a llamar hard) para ejecutar cuestiones básicas de su trabajo y otras habilidades soft que tienen que ver con su enfoque hacia el trabajo. Estas últimas van más allá de los límites de la profesión y alcanzas otros aspectos de la vida. Son habilidades que hacen a su comunicación interpersonal, negociación y resolución de conflictos, efectividad y creatividad, por nombrar algunas.

A partir de esta diferenciación y teniendo en cuenta la importancia de cada una, podemos definir 3 grupos:

1. Aquellas profesiones que necesitan de las habilidades técnicas y pocas habilidades soft.
2. Aquellas profesiones que necesitan ambas habilidades
3. Aquellas profesiones que necesitan mayormente habilidades soft, pero no así de tantas hard.

Pienso que la profesión de tester está contenida en el segundo grupo y, a continuación, justifico mi elección.

Las habilidades técnicas son aquellas que implican "meterse en el barro", hacer una estrategia de pruebas, definir/programar y ejecutar casos y generar los respectivos reportes e informes. También, incluyo aquí la aplicación de metodologías para la gestión de los proyectos, entendimiento del dominio/negocio, procedimientos generales y adopción de estándares.

Por último, dejé para el final las habilidades soft ya que son las más difíciles de observar, cuantificar y medir y, por lo tanto, quiero hacer especial hincapié sobre ellas. Esto no hace más importantes a estas habilidades por encima de las técnicas (de hecho, un tester no sobreviviría sin habilidades técnicas). El tema pasa por como las habilidades pueden ser adquiridas. Las hard, pueden entrenarse con mayor facilidad ya que en cierta medida se aprenden el la escuela, Universidad, cursos, etc. Mientras que las habilidades soft están relacionadas a los patrones de conducta de las personas y, en general, se mejorar/modifican (y entrenan también) haciendo camino al andar.

A continuación detallo las habilidades soft que un tester debería tratar de atender, mejorar y entrenar para ser un tester "completo":

1. Disciplina y perseverancia
2. Meticulosidad
3. Comunicación (oral y escrita)
4. Curiosidad
5. Observación (fundamental!)
6. Priorización de esfuerzo y gestión del tiempo
7. Actitud positiva
8. Pensamiento negativo
9. Pensamiento crítico

Quizás, en estas últimas, esté el quid de la cuestión...

Fuentes:

[1] Stickyminds
[2] Así no se hacen las cosas
[3] Cartoon Tester

Mantenerse creativo (4)

Posted by German on 13.2.13 with No comments



                              #4. Visitá nuevos lugares





Este último fin de semana visité Villa Pehuenia. Un centro turístico con cultura milenaria, dotada de bosques de Araucarias Araucanas. Esta aldea de montaña está enclavada en la cordillera de los Andes a la vera de los lagos Aluminé y Moquehue, a 310 Km. de la capital neuquina y a 1200 m.s.n.m. UN LUGAR PERFECTO.

 Aquí, mi foto del lugar:



Fuente: 33 tips para mantenerse creativo.

Testing: 6 preguntas a Ernesto Kiszkurno de Pragma Consultores

Posted by German on 7.2.13 with 1 comment

Siguiendo con mi serie de entrevistas, estuve charlando con Ernesto Kizskurno, de Pragma Consultores, sobre testing de software.

German Braun (GB): ¿Cuál es su definición de calidad?

Ernesto Kiszkurno (EK): Tengo 10 definiciones. Pero la que más me gusta es: “La calidad no es un arte, es un hábito” de Aristóteles. El resto las pueden encontrar en mi blog.

 GB: ¿Cuál piensa que es, actualmente, el rol del testing en un proceso de desarrollo u organización?

 EK: Hace unos días publiqué en twitter algo relacionado con esto. El testing no tiene valor en si mismo para una organización. No es ni bueno ni malo en sí mismo. Es una herramienta para medir el nivel de calidad del software que desarrollamos. Eso no quiere decir que no sea fundamental su uso en un montón de ámbitos. Lo que me parece clave es entender el contexto del proceso de desarrollo de software y en base a eso decidir cuanto invertimos en testing.

Dicho esto y, dado el nivel de penetración que tiene el software en nuestra vida cotidiana, creo que tendremos testing para rato. Sobre esto también comenté algo aquí.

 GB: ¿Cuáles piensa que son las principales skills que un tester debería tener?

 EK:
1. Meticulosidad.
2. Curiosidad para buscar los errores, para entender la funcionalidad.
3. Buenas habilidades de comunicación (escrita y oral). 
4. Solvencia técnica (para poder hablar con el desarrollador, entre otras cosas).
5. Entendimiento del negocio (para poder hablar con los usuarios).
6. Mindset diferente.
GB: ¿Es el testing una "profesión" con futuro?

 EK: He escrito sobre esto aquí. Creo que el testing como actividad debe seguir re-inventándose a medida que la práctica de desarrollo de software vaya cambiando. Pero no me imagino un futuro inmediato donde hay desarrollo de software pero no hay testing.

Por otro lado, el paradigma de compartimentos estancos entre el grupo de desarrollo de software y el equipo de testing se va agotando.

GB: ¿Cuáles son los 2 o 3 hitos más importantes de su carrera como tester profesional?

EK: Es difícil esta pregunta porque en la época donde yo empecé con los temas de calidad eramos pocos. Creo que los hitos más importantes en mi carrera fueron los momentos donde dí saltos de magnitud en el tipo de responsabilidades que asumía. Por ejemplo el cambio de ser liderado a liderar o el cambio de liderar un pequeño equipo a muchos equipos.

GB: ¿Qué consejo le daría a un tester principiante que desea seguir el camino de la calidad de software?

EK: Que cuide su empleabilidad, aprenda continuamente y que no se concentre sólo en los aspectos técnicos. Lo más complicado es el manejo de las cuestiones soft.



Sobre Ernesto Kiszkurno

 Ernesto es socio en Pragma Consultores. También es docente en la Facultad de Ciencias Exactas y Naturales de la UBA y autor del blog "Así no se hacen las cosas".
¡Gracias Ernesto!
Suscribirse a: Entradas (Atom)