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

Principios

Me gustó esta lista de principios del libro "The People's Scrum" de @tobiasmayer.

Framework: nos comprometemos a seguir los principios ágiles utilizando Scrum.

Calidad: nos comprometemos a construir calidad en nuestros productos en todos los estados de su desarrollo. Así como también, revisar continuamente y mejorar nuestras técnicas para alcanzarla.

Personas: somos profesionales y tenemos la responsabilidad de respetar a los otros, actuar honestamente, comunicar abiertamente, y buscar y dar ayuda cuando sea necesario.

Proceso: nos comprometemos a trabajar con la organización para definir a proceso mínimo para guiar nuestras actividades durante la duración de una iteración, apoyando al equipo para lograr completar su trabajo.

Crecimiento: como individuos, nos comprometemos a mejorar y compartir nuestro conocimiento (en la compañía), cuando sea apropiado.

Germán

Read More

Bugs should be about behaviour enhancements

Hace un tiempo que venimos hablando de que hacer testing es capturar conocimiento y que una de las formas operativas de obtener este conocimiento, es a través de los bugs. Esto me lleva a pensar que, en realidad, los bugs no son algo negativo, para nada. Es verdad que tienen "mala fama" pero tanto para el que los encuentra como para el que los arregla, debería ser algo positivo y atractivo, además de habilitar nuevas discusiones sobre lo que realmente se espera del producto (en muchas ocasiones esto puede no aplicar para los incidentes productivos, pero el usuario también debería comprometerse con el software).

Dicho esto y basándome en el artículo de @gojkoadzic "User stories should be about behaviour changes", es que los "Bugs should be about behaviour enhancements".

Germán

Read More

Primera persona del singular

Llevo un tiempo trabajando con equipos y, pensando retrospectivamente, me doy cuenta que muchas veces me encuentro/nos encontramos dialogando con compañeros o clientes, anteponiendo el pronombre 'yo' o usando verbos en primera persona singular. Este hecho marca el sentido de no pertenencia a nuestro equipo y atenta contra los ambientes colaborativos. Creo que una de las maneras de mejorar la comunicación y la colaboración, y que debería ser trabajada en retrospectivas, es la erradicación de este tipo de pronombres y verbos cuando hablamos en nombre del grupo. Potenciará el sentido de equipo, la pertenencia y el compromiso hacia él.

Germán

Read More

Vacaciones

En la entrada anterior hablamos sobre la pausa. Aquella que nos predispone al pensamiento crítico. Esta pausa es sólo de unos segundos, para tomarnos un respiro, pensar en la información que tenemos y usarla racionalmente.

Hoy quiero hablar, brevemente, sobre otra pausa: las vacaciones. Es el tiempo en el cual deberíamos dejar de pensar en el trabajo. Tratar de no revisar mails (despreocuparse por el inbox zero) y dedicarse al ocio y al esparcimiento. Es el momento para viajar y retomar esos hobbies o actividades que tenemos relegados. Debería ser nuestra obligación.

Germán

Read More

Pausa

@michaelbolton, en su blog propone una nueva herramienta para los testers. Aunque también quiero hacerlo extensivo a desarrolladores y analistas. Dicha herramienta es la pausa.

El desarrollo de software es una actividad compleja y, cómo toda profesión que requiere de un despliegue intelectual diario, necesita de una pausa. Según Bolton, una pausa es el efecto de aplicar las siguientes cuatro palabras: Huh?, Really?, And? y So? Cada una de ellas da un respiro y predispone al pensamiento crítico.

Wait…huh? Did I hear that properly? 

Um…Really? Does that match with my experience and understanding of the world as it is, or how it might be? 

…And? What additional information might be missing?

Okay…So? What are some consequences or ramifications of those interpretations?

Germán

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

Never lose a BUG again

Sabios consejos [1]

• Controlá tus tests.
• Compartí tus bugs tal cómo los encontrás.
• Capturá tu pantalla, adjuntá al incidente y seguí trabajando. Los developers verán la aplicación exactamente como estaba cuando encontraste el bug.
• Eliminá las excusas: no digas más "Funciona en mi PC".

Germán

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

Equivocarse

Ayer leí este interesante artículo de Gustavo Bonalde, titulado ¿Siempre debemos fallar para lograr algo?

Transcribo aquí una frase que me parece interesante:

"Es muy cierto que en cada falla tenemos una oportunidad de mejora, de aprendizaje, pero hay ocasiones donde no hay espacio para fallar."

Y es verdad. Además, en aquellas ocasiones en las cuales no podemos fallar, y lo hacemos, seguro el "golpe" será más grande. Pero, a pesar de ellos, seguimos aprendiendo.

Para concluir, en cualquier profesión, trabajo, carrera, el aprendizaje es continuo y eso es lo mágico. Sólo hay que estar predispuesto.

Germán

Read More

Tengo un problema (2)

Luego del éxito sin precedentes del post sobre el patito de goma (¿?) y de algunos de los comentarios que me llegaron, quise hacer una remasterización del algoritmo de la técnica con el feedback que obtuve.

Si tenés un problema que no podés resolver y te está bloqueando, entonces:

          Si trabajás remoto:

                1. Buscá un compañero en el chat para contárselo;

          Sino:

                2. Contáselo a un compañero en persona;

Si no tenés más remedio y no tenés un compañero a mano:
                3. Buscá un Patito de Goma y/o cualquier otro;

En otro caso:

                4. Googlealo :)

Germán

Read More

No escribirás con errores ortográficos

Recuerdo que cuando estaba en la escuela primaria (6to grado), tenía una maestra que en una de las clases semanales de Lengua, nos tomaba un dictado. La dinámica era la siguiente: te dictaba 20 palabras elegidas al azar y, si tenías menos de 6 o 7 errores ortográficos, aprobabas. A medida que iba pasando el tiempo, la complejidad de las palabras se incrementaba y, para la calificación final de la materia, se ponderaba también cuántos dictados habías aprobado. Si bien era un examen y tenía un cierto nivel de stress, hoy en día, agradezco haber tenido la posibilidad de entrenar mi ortografía desde chico.

Esta anécdota es para introducir un tema que me parece muy importante, por no decir crítico. Digamos que podríamos seguir hablando sobre skills blandas, duras, etc. de un profesional (en este caso, informático, tester, developer, no viene al caso). Sin embargo, pienso que antes de entrenar cualquiera de estas habilidades (que obviamente son también importantes), tenemos que estar seguros de escribir sin errores de ortografía. En resumen, antes de entrenar cualquier otra habilidad, procura escribir sin errores de ortografía.

Les dejo algunos tips que me ayudan a mejorar mi redacción:

- Leer, leer, leer.

- Consultar la RAE o un diccionario físico.

- Tener a mano reglas de ortografía y gramática básicas.

- Usar sinónimos.

- Ejercitar la escritura.

- Seguir en Twitter a @DelCorrector (leer también su blog El Santo de la Pluma)

Por último, no sé si a ustedes les pasa, pero me molesta leer un texto que tiene errores. Además, tiene consecuencias varias. Por ejemplo:

- Si es un informe, pierde toda seriedad al momento de localizar el primer acento mal puesto.

- Si es un bug, tu reputación de buen tester está en duda.

- Si es un chat, sms o mail informal, puede zafar pero, de vez en cuando, una corrección no viene mal.

- Si es un CV, estás out.

- Si es una chica que tiene problemas con su ortografía, pierde inmediatamente todo su encanto.

- Si es este post, por favor, dejar un comentario. Gracias!

¿Es mucho?

Germán

[1] Imagen http://escribo-miguel.blogspot.com.ar/2013/02/avisos-ortograficos-cuidado.html

Read More

Publicación en el blog de PetroVR

Colaboré como autor, junto a mis compañeros de equipo de Pragma, en una entrada sobre Testing en el blog de PetroVR. En el post, hablamos un poco sobre una propiedad que me parece interesante para desarrollar y que es la "self-testability" de un producto software. Los invito a leerlo How is the Testing of PetroVR done? The self-testability of PetroVR

Gracias Caesar Systems por la invitación a participar y a +Leandro Caniglia y +Carlos Ferro por el feedback.

Germán

Read More

Tengo un problema

La técnica del patito de goma [1] (reformulada)

Muchas veces nos pasa que nos bloqueamos cuando tenemos que resolver un problema (en este caso, laboral). No podemos avanzar, nos volvemos menos productivos, incómodos y no disfrutamos de nuestro trabajo. Para evitar esto, lo que la técnica propone es, simplemente, contarle a alguien lo que nos pasa. Luego, en medio del proceso, nos daremos cuenta de lo que está fallando (eventualmente) y nos ayudará a resolver el tema que nos aqueja. Pero tiene un problema, hay que molestar a otra persona para que nos atienda. Es aquí dónde aparece el Patito de Goma. Cuando estés bloqueado usá el patito, contale lo que te ocurre y verás cómo, en muchas ocasiones, te ayudará.

Contado de esta manera, tiene algo que me hace ruido y que contradice el "espíritu" de este blog: atenta contra los ambientes colaborativos. Por lo tanto, mi propuesta es:

- Si tenés un problema que no podés resolver y te está bloqueando:

          1. Buscá un compañero para contárselo.

- Si no tenés más remedio y no tenés un compañero a mano:
          2. Buscá una Patito de Goma.

Germán

[1] http://developerscookbook.blogspot.com.ar/2010_11_01_archive.html

Read More

Mis razones para escribir

Este blog está cumpliendo un año desde que comencé a escribirlo. Cuando me dí cuenta de la fecha, me puse a pensar ¿por qué estoy escribiendo?, ¿cuáles son las razones? Entonces identifiqué las siguientes (más representativas):

1. Investigar: me gusta hacerlo y el blog ayuda a plasmarlo. La gente que trabaja en Informática debe investigar todo el tiempo. El constante avance en materia de Ciencia y Tecnología requiere que todo profesional esté actualizado para intentar llegar a la "cresta de la ola".

2. Aprender: El blog nos permite aprender sobre los temas que nos interesan, gestionarlo, escribirlo y  compartirlo. 

3. Hacer Comunidad: contactar gente con la que tengamos temas en común, que quiera compartir su conocimiento y que haga comunidad.

Cualquier motivación es válida para escribir. Sin embargo, creo que lo más importante y, lo que me motiva a seguir haciéndolo, es el feedback que se obtiene de los lectores (cualquiera sea la cantidad)

¡Gracias por leer!

Germán

Read More