martes, 12 de noviembre de 2013

Testers, el Sombrero Negro y los riesgos

Varias veces en mi carrera he tomado el rol de tester, ya sea como miembro de equipo o como consultor, y con ese rol me ha tocado participar en reuniones en las que se analizaban las estrategias de pruebas y la relación con los riesgos.

En algunas de las reuniones en las que participé sentí que mis preguntas y comentarios generaban incomodidad, incredulidad o incluso enojo. De alguna manera, la forma en que estaba planteada la reunión o la forma en la que yo participaba de la misma, no facilitaban la exploración de ideas o caminos alternativos.

Origen de la incomodidad

En mi última retrospectiva personal (hansei) estuve pensando en el origen de esta situación, y que podría hacer para cambiarla la próxima vez que estuviera en esa situación.

Posibles fuentes de incomodidad

  • Mezclar en la reunión diferentes momento del proceso creativo que lleva a un plan de prueba:
    • La instancia de identificación y exploración de los riesgos 
    • La evaluación del impacto y probabilidad de los riesgos
    • La ideación de mitigaciones
    • La evaluación de riesgos secundarios.
  • Percepción de que alguna persona en la reunión está evaluando el trabajo pasado en vez de estar trabajando en los próximos pasos.
  • Falta de práctica de los asistentes con técnicas de innovación. Por ejemplo criticando las ideas desde el mismo momento en que se plantean, y no aplicar resonancia (utilizar si... pero, en vez de si... y además).

Mi lista de accionables


  • Validar al inicio de la reunión el objetivo, dinámica y agenda. Marcar a lo largo de la reunión donde estamos, y si nos apartamos reevaluar si volvemos a la agenda original o la modificamos.
  • Siendo que últimamente participo como consultor, explicitar que tengo poco contexto, y que por favor tomen mis intervenciones como disparadores de ideas.
  • Facilitar gráficamente la charla, para ayudar a que todos estemos en la misma página.
  • Ser el primero en seguir las recomendaciones: no juzgar las ideas cuando las generamos, construir sobre las ideas de los demás (resonancia), manter en foco en las seleccionadas.

Riesgos secundarios

No todas las reuniones tienen las estructura "generar ideas y luego converger a solución". 
En algunas grupos o reuniones se espera que el experto diga "cómo deben hacer las cosas" y por más que yo crea que sea mejor construir entre todos, debo escuchar lo que se espera de mí, y al menos explicitar la tensión. Muy ligado a Cynefin, sólo sirve buscar "la mejor forma" de hacer las cosas cuando estamos en un contexto Simple (algo de eso en mi post sobre La mejor forma de Probar).
En otros grupos, "no hay tiempo" para analizar las alternativas, debemos pasar directamente a definir la acción. Lo mejor es detectar esto antes de la reunión, hablando con los participantes para entender las expectativas y, como último momento responsable, se puede aclarar en el inicio de la reunión, cuando se plantea la agenda.

jueves, 7 de noviembre de 2013

¿Automatizamos las pruebas de regresión?

Trabajo en una aplicación en la que cada vez que mis usuarios piden un cambio, el costo de hacer el cambio es mucho menor que el costo de probar. La aplicación no tiene automatizada la prueba y no es modular.

Esta situación la he escuchado y vivido muchas veces en mi carrera. Ante esa situación, hay varias acciones posibles:

  1. Tenemos que hacer de nuevo el sistema, y esta vez lo haremos bien.
  2. Redefinamos el sistema para que sea más fácil probar.
  3. Automaticemos la prueba.
  4. Contratemos más testers.
  5. Sigamos sin cambiar durante algún tiempo.

No puedo en este post analizar todas las alternativas, pero voy a seguir una linea de razonamiento posible, asumiendo algunas creencias, básicamente que las prácticas de desarrollo ágil me pueden ayudar en este caso (Más información sobre estrategias en Working Effectively with Legacy Code). 

Entonces, la secuencia de pensamientos sería:
  • Me gustaría hacerlo bien, pero no puedo tirarlo y empezar de nuevo, el negocio debe seguir operando y la aplicación se debe seguir adaptando. Entonces, trabajaremos en hacerlo bien, pero en forma incremental
  • Para redefinir el sistema sin romperlo, y dado que trabajaremos incrementalmente (muchos pequeños cambios) necesitamos pruebas automatizadas, al menos de nivel funcional. Esto permitirá que probemos a bajo costo cada versión del sistema con un nivel aceptable de calidad. No reemplazamos las pruebas manuales, pero al menos distribuimos las pruebas entre dos ciclos: uno automatizado, rápido y frecuente, otro manual, costoso y que corremos antes de liberar versiones.
  • Hacer bien la aplicación implica modularizar, tener pruebas automatizadas unitarias y calidad interna. Estas importantes ideas y prácticas no las estoy tratando en este post, pero suelen tener como precondición las pruebas funcionales automatizadas a las que me refierno en este post.
Vemos muchas equipos y empresas que siguen esta linea de pensamiento. Entonces el problema se puede reeplantear.

Quiero automatizar las pruebas de regresión, ¿cómo lo hago?

Quiero automatizar las pruebas de regresión, ¿cómo lo hago? ¿Qué herramientas uso? ¿lo hago con personas del equipo o contrato fuera? ¿cómo cambian los roles, que tenemos que aprender? ¿qué y cuánto tengo que probar para lograr confianza?

La respuesta a estas preguntas: Depende. 
Bien, pero ¿de qué depende?

El equipo ¿tiene cultura de calidad?

Algunos miembros del equipo se ocupan de la calidad, dedican tiempo a pensar como probar y manejar los riesgos. Ya se hacen pruebas, y el problema es como automatizarlas.

¿Cómo es la estructura y cuales son los conocimiento del equipo?

La prueba manual la realiza un grupo externo, o los testers del equipo (hay personas cuyo puesto o posición es Tester), o las pruebas las realizan varias personas que cubren el rol de tester, pero también otros roles (analistas, programadores, diseñadores gráficos).
Los que cumplen rol de tester, ¿tienen conocimientos sobre programación o les interesa adquirirlos?
Funciona el equipo como un Whole Team en el que todos toman responsabilidad sobre el resultado conjunto y no sobre un subconjunto ("yo pruebo, no programo" o viceversa)

¿Cómo es la tecnológicamente la aplicación?

Para disminuir la curva de aprendizaje y mejorar la aceptación de las nuevas herramientas, es conveniente que la tecnología de la prueba automática sea cercana a la utilizada para la aplicación. ¿El equipo trabaja con .Net, Java, Ruby, Python?

Nuestra respuesta

Cada equipo debe explorar qué organización, herramientas y conocimientos les servirán para su caso.
Lo que encontramos desde Kleer (en este caso Nicolás Páez, Juan Gabardini, Carlos Peix), es que solemos repetir, al inicio de las consultoría de estos temas, una mínima nivelación de conocimientos y del abanico de posibilidades en cuanto a prácticas y herramientas, para facilitar a los equipos tomar decisiones. Pensamos que sería útil extraer esto en una serie de talleres cortos (medio día cada uno):