Power of Three

Algo que tienen que empezar a suceder para que los testers se involucren en el software desde el principio, es participar en las discusiones entre los desarrolladores y product owner. Para darle impulso a esto se puede aplicar la regla denominada Power of Three. Básicamente, significa que todas las discusiones sobre una nueva funcionalidad necesitan de un desarrollador, un tester y el product owner. Es responsabilidad del equipo que siempre haya un representante en este grupo.

Germán

ref: Agile Testing: A Practical Guide for Testers and Agile Teams

Read More

Principio #3 - Enable face-to-face communication

Principio de Testing Agile #3 [1]

Ningún equipo puede trabajar bien sin una buena comunicación. Principalmente en estos tiempos en los cuales se tiende al trabajo distribuido. Aquí la comunicación es aún más importante y más desafiante.

Para un tester ágil, la comunicación es crítica. En todo momento, el tester se hace preguntas (es parte de su esencia) sobre cómo una funcionalidad debe trabajar o cómo una interface debe ser mostrada. Entonces, se deben habilitar canales con los desarrolladores y los expertos del negocio. Los testers deben hablar en estos dos idiomas y deben colaborar para que todos compartan un lenguaje común.

Finalmente, si bien la comunicación "cara a cara" nunca podrá sustituirse, hay que buscar formas "creativas" en caso que nuestro equipo esté distribuido.

Germán

[1] Agile Testing: A Practical Guide for Testers and Agile Teams

Read More

Principio #2 - Entregar valor

Principio de Testing Agile #2 [1]

Como sabemos, una de las prioridades del desarrollo ágil es entregar valor al cliente en pequeñas iteraciones. Este valor es software funcionando y compuesto por las funcionalidades que se han priorizado recientemente. En este contexto, es fácil ceder ante los deseos del cliente para ciertas features y, si bien cualquiera en el equipo puede cuestionar estos puntos, es el tester ágil quién debe reconocer los impactos dentro de las stories, debido que debe pensar sobre las repercusiones del testing.

Los testers ágiles deben ver el todo al momento de analizar las stories para identificar los caminos críticos. Las funcionalidades entregadas pueden crecer entre iteraciones y, si se pierde de vista la funcionalidad core sobre el "camino feliz", se corre el riesgo de no entregar nada. Si bien una de las habilidades de un tester es identificar casos más allá de este "camino feliz", es NECESARIO asegurarse que el camino funcione correctamente. SIEMPRE considerando lo que agrega más valor al cliente y entendiendo su contexto.

Por último, y no menos importante, es el tiempo de testing. Tiene que ser considerado durante el proceso de estimación para asegurarse que haya suficiente espacio en la iteración para entregar una funcionalidad correcta.

Germán

[1] Agile Testing: A Practical Guide for Testers and Agile Teams

Read More

Testing y Scrum en el libro "The People's Scrum"

Leyendo el libro de Tobias Mayer, me topé con un par de párrafos que relacionan al testing con la cultura de Scrum. Me pareció interesante para compartir. 

"The discipline of testing requires a lot more humility than the discipline of development. Testers tend to be more humble than developers; it is the nature of the role. There are different energies at play: development is characterized by the energy of creation, testing by the energy of service".

"The mission of scrum is to change the way we work. This is not process change, this is cultural change. People inside a scrum/agile process (we hope) behave differently. We now have test-infected developers. That's great. We have developers who see the value in testing, and do it. They don't push it off to QA people at the end of process"

"I want to see testers passionate about create new software, no just validating someone else's software. I want to see testers weave themselves into the creative process from requirements all the way through to release"

Yo quiero lo mismo!

Germán

Read More

Hasta dónde hemos llegado...

Hace unas semanas, una persona me contacto por LinkedIn para que le comente sobre testing (en general). Aquí dejo algunas reflexiones de mi respuesta.

Recuerdo que +Ernesto Kiszkurno  (socio de la consultora en la cual trabajo), siempre me decía que cuando empezaron a trabajar en testing, a ofrecer y vender servicios, los miraban como "personas extrañas". Nadie entendía lo que querían hacer y, obviamente, había una resistencia importante. Esto hace ya unos 15 años. Esta resistencia, era normal. Alguien te venía a decir que tu software "estaba mal". ¿Cómo es esto?

Hoy en día, el testing ya está totalmente aceptado y es indispensable para el desarrollo de un producto. Como consecuencia, la responsabilidad de los testers también se ha potenciado. Deben dar soporte a la captura del conocimiento y gestionarlo. No sólo deben detectar ciertos desvíos funcionales o errores triviales que pueden tener cualquier software, sino hay que involucrarse mucho más en el dominio. Las prácticas ágiles (TDD, ATDD, BDD, DDD) que involucran desarrollo basado en pruebas, son también un punto de encuentro entre developers y testers que potencia su relación y realza la necesidad de trabajar con foco en la calidad.

Finalmente, creo que el próximo paso es aceptar y dejar de lado (definitivamente) el famoso "developers vs testers" para pasar a ser un grupo homogéneo de profesionales trabajando en pos de entregar valor. Un equipo multidisciplinario que tiene como único objetivo, construir software de calidad. La gente depende cada vez más del software y se debe dar soporte a esto. Superar este obstáculo dará impulso para concretar e imponer un meta-enfoque que podríamos llamarlo algo así como Quality-Driven Development (QDD)

En resumen, enumero algunos hitos que se fueron sucediendo y otros, que espero, puedan concretarse y aceptarse definitivamente. 

1. Resistencia al testing.

2. Aceptación como la última etapa de un proceso de desarrollo cascada (waterfall)

3. Necesidad de incluir prácticas de calidad más temprano en el ciclo.

4. Surgimiento de testing agile (TDD, BDD, ATDD) para trabajar sobre el desarrollo gestionado con pruebas.

5. Testing como actividad que retroalimenta la captura del conocimiento del software.

6. Fin de la rivalidad "developers vs testers"
7. Imposición de un nuevo concepto QDD (Quality-Driven Development)

Germán

Read More

Principio #1 - Dar feedback continuo

Principio de Testing Agile #1 [1]

En el contexto de un equipo ágil, el tester está involucrado en el producto desde los inicios. Desde bien temprano, en la primer iteración. Muchos proyectos ágiles están "manejados" por tests y, en consecuencia, el feedback juega un rol importante en ellos. En principio, el feedback comienza trabajando con el product owner o cliente para articular las stories mediante ejemplos y tests. Luego, los testers trabajan junto con sus otros miembros del equipo para generar escenarios ejecutables a partir de los requerimientos relevados. La ejecución de estos tests es otra fuente continua de feedback. Por último, los testers pueden mostrar su progreso dando una vista global de tests creados/ejecutados/OK así como del cubrimiento funcional de sus pruebas.

En cualquiera de estas situaciones, el feedback es una manera de ayudar a remover obstáculos y promover la cultura del trabajo colaborativo.

Germán

[1] Agile Testing: A Practical Guide for Testers and Agile Teams

Read More

Principios esenciales para Automatización de Pruebas Funcionales

La última Testing Experience tiene un interesante artículo sobre principios para tener en cuenta al momento de automatizar tests funcionales. Los quería compartir aquí ya que me parece importante tenerlos bien presentes.

1. Primero, diseñar los tests. Evitar la creación de tests on the fly. Nuestra suite de tests debe crecer orgánicamente.

2. No automatizar todo. Ciertos tests pueden ser fácilmente ejecutados en forma manual, evitando así el alto costo de automatización.

3. Escribir tests cortos. En situaciones en las que uno o más tests fallen, cualquier miembro del equipo debe ser capaz de trackear la causa del error. Es recomendable usar BDD (Behaviour-Driven Development) 

4. Crear tests independientes. Evitar el acomplamiento y aumentar la cohesión de los tests.

5. Enfocarse sobre su readability. El código fuente de cada test debería estar self-documenting. Comentarios en el código deben ser evitados.

6. Tests deben ser rápidos. El testing funcional automatizado debe ser un indicador rápido de la calidad de la aplicación. Además, en un ambiente de continuous delivery, el tiempo de ejecución debe ser de unos pocos minutos.

7. Crear tests resistentes al cambio. Quizás esta es una de las principales desventajas de los tests funcionales automatizados. Los tests debería verificar sólo funcionalidad. Dependiendo del contexto también puede ser posible aplicar DDT (Data-Driven Testing)

8. Los tests automatizados no pueden reemplazar a los humanos. Este no debe ser el único testing que se ejecuta. Otras técnicas, con la intervención de los testers humanos, deben ser aplicadas sobre el software en pos de generar más conocimiento.

Germán

Read More

What’s a Tester without a QA Team? (hacia un entorno ágil)

Luego de escribir sobre "Así comienza el camino...", encontré un interesante artículo escrito por Lisa Crispin y Janet Gregory, titulado "What's a Tester without a QA Team?". Quería remarcar una serie de bullets que me parecen interesantes para llevar a la práctica cuando un equipo de testing transiciona de un esquema tradicional a uno ágil.

• Preparándose para el éxito. Inducir y dar soporte para que la persona no se aísle. Ahora, en este nuevo enfoque, se debe reportar a otras personas, otros roles y los testers deben aprender a colaborar con otros miembros del equipo.
• El enfoque "Whole Team". En los equipo ágiles exitosos, todos sus miembros tienen un claro enfoque en la calidad y son responsables de ella. La buena noticia para los testers es que ahora ellos van a estar involucrados en el proyecto desde el principio. Su tarea comienza con los clientes o product owner definiendo los tests de aceptación y continúa con la revisión de user stories junto con los developers.
• Comunidad de Práctica de Testing. Construir comunidades de práctica que faciliten la integración del equipo. El fin principal es compartir conocimientos y experiencias. Esta comunidad puede tener un test manager (responsable del equipo de testing en el enfoque tradicional) quien sea el encargado de asegurar la inducción y el soporte a los testers. El equipo debe también estar orientado a hacer comunidad.
• Compartir Conocimiento. Cuando el equipo tiene el sentido de comunidad, se genera un núcleo de conocimiento muy poderoso que favorece el intercambio. Proactivamente, los integrantes comienzan a intercambiar conocimiento de manera desinteresada y totalmente natural.
• Ampliar tus horizontes. Todos los software makers deben estar enfocados en el aprendizaje continuo. Cada vez que una nueva funcionalidad es pensada y desarrollada, se produce una explosión de nuevo conocimiento que involucra y retroalimenta a todo el equipo.

Germán

Read More

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

Read More

Basta de "Dev vs. QA"

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

Read More

Hacer testing es también capturar conocimiento - otra vuelta

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

Read More

Hacer testing es también capturar conocimiento

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/

Read More