Sobre nuestra misión como testers

Seguramente lo primero que nos han transmitido o se nos ocurre es que nuestra misión es encontrar defectos y/o  lograr entregar aplicaciones libres de defectos. 

Pero esto es sólo una pequeña parte y es una visión muy acotada del aporte de valor que nuestro trabajo puede brindar a una Organización si es bien entendido y encarado (y recordemos que no existen aplicaciones libres de defectos, a lo sumo, si hacemos bien nuestro trabajo, estarán libres de los defectos importantes y relevantes para los interesados).

Por otra parte, fuera de considerar únicamente lo que nosotros pensamos que es testear, tenemos que tener en cuenta qué esperan de nuestro servicio o actividad quienes nos contratan o convocan, qué expectativas tienen:

• ¿Por qué una organización cree que es valioso tener un área de testing o contratar ese servicio en un proyecto?
• ¿Qué espera obtener como retorno de su inversión en el área o el servicio?
• Mejor calidad en sus productos
• Clientes o usuarios satisfechos
• Software “cero defectos”
• ….
• Todas las respuestas anteriores…
• ¿Qué espera que hagamos?
• Prueba durante el ciclo de vida de desarrollo de un producto
• Prueba de homologación de un producto adquirido
• Pruebas de atributos de calidad específicos, seguridad, performance, otros
• ….
• Todas o algunas de las respuestas anteriores…

Difícilmente podamos cumplir los objetivos de quienes nos convocan o contratan, sean clientes internos o externos a nuestra organización, si no identificamos claramente nuestra misión:

Qué tipo de testing tenemos que ejecutar, en qué contexto, en qué momento del proyecto / ciclo de vida del producto, con qué restricciones y recursos, con qué objetivos, ….

En otras palabras, si no entendemos para qué nos llaman, mal vamos a poder cumplir las expectativas. Las expectativas y las percepciones del cliente y otros interesados podrían entonces diferir mucho, con lo que podrían concluir que hacer testing no aporta valor, o que nuestros servicios no aportan valor.

Y esto es también uno de los orígenes de la “resistencia” que encontramos en algunos proyectos y una posible fuente de malos entendidos o conflictos entre los integrantes de un equipo de proyecto. 

El “no pensé que iban a probar a este nivel de detalle” o “no pensé que iban a probar esto” o frases similares, son objeciones que típicamente aparecen cuando algunos miembros del equipo de proyecto no entienden por qué estamos ahí, pero también reflejan que los  primeros que tenemos que tener clara nuestra misión somos nosotros, para aplicar nuestras mejores técnicas, prácticas, herramientas, imaginación, conocimientos, ética, para lograr cumplir esa misión.

El testing es un servicio. Dada esa definición, para poder brindarlo “con calidad” (o sea cumpliendo las expectativas del cliente) necesitamos:

• Entender expectativas y objetivos del cliente y otros interesados (pueden ser diferentes).
• Cuestionar y evaluar el producto.
• Focalizar los riesgos, entender y gestionar los cambios que afecten al servicio (en el proyecto, el producto, el contexto).
• Investigar, explorar, proveer feedback.
• Confirmar, comunicar.
• Aprender, seguir capacitándonos.

Así ayudaremos a completar el proyecto entregando un producto útil y exitoso para todas las partes. Para lograrlo es fundamental una buena comunicación y relación con todos los interesados por parte del equipo de proyecto, así como lo es entender el beneficio que brindará al negocio.

La buena comunicación ayudará a lograr que los interesados transmitan mejor sus expectativas y necesidades, se involucren más en el día a día del servicio y reciban finalmente un producto que perciban como de calidad, sin tantos tropiezos.

En relación a estos puntos, habría seguramente mucho más que decir y cada uno puede tener su propia visión.

Pueden ver también si les interesa el tema una discusión en el blog de James Bach, que aunque siendo de 2006, considero muy valioso leer:  

Question: Tester’s Freedom of Thought

Nota: Originalmente publicado en excelza el 18/10/2009

¿Cambio? ¿Qué cambio? (*)

Algunas preguntas típicas que nos hacemos durante un proceso de mejora, son:
- ¿Hasta dónde está incorporado el cambio?
- ¿Continuará en práctica cuándo quienes lo están llevando adelante dediquen menos esfuerzo o se retiren?

- ¿Lo habrán incorporado realmente aquéllos que toman decisiones que pueden impactar a los nuevos procesos?

Las mismas preguntas se hace la Dirección, normalmente aquél que respaldó la mejora, o bien se las hace a quienes están incorporando el cambio.

Son preguntas difíciles y tienen respuestas sólo aproximadas.

Posibles guías

Creo que una manera clara de explicar los alcances de un cambio, prácticamente de cualquier tipo, que afecte a los procesos que las personas ejecutan normalmente en su día a día, es mostrar los cambios que realmente ocurren o se espera que ocurran.

Para ello, el siguiente diagrama extraído del trabajo de Andrews y Stalick⁽¹⁾, es bastante claro.

Haciendo una interpretación libre del trabajo de los autores, veamos si coincide con nuestra experiencia.

La visión integral del cambio

Los cambios se pueden agrupar por complejidad desde lo operativo y “sencillo” hasta lo cultural y “complejo”. 

Otra dimensión es la visibilidad, donde lo sencillo es lo más visible y lo complejo menos.

El gráfico no debe dar la sensación de secuencialidad; los cambios ocurren simultáneamente en varios niveles. Analicemos cada uno de los niveles.

Cambios de Primer Nivel – Operativos

Comprende todo lo conocido y rápidamente visible para el equipo de trabajo. 
Nuevos procesos, nueva organización, o cambios en ella, así como nuevas herramientas y tecnología para soportarlo.

Los Procesos comprenden nuevos modelos de trabajo, basados en algún modelo de mejora estándar, si se utilizó alguno, buenas prácticas, o bien en la experiencia de la Organización y del equipo de trabajo.

La Organización se refiere a nuevos roles creados para soportar el nuevo proceso, o bien nuevas funciones en los roles existentes.

La Tecnología comprende a las herramientas de soporte que se utilizan para hacer más eficiente la operación de los nuevos procesos.

Bien, hasta aquí, se puede haber gastado dinero en herramientas, personas, cursos, consultoría, etc. y esto da la sensación de avance.

¿Pero lo hay?...

Sí hay avance, ya que son pasos que hay que dar, pero es sólo el comienzo.

Podríamos decir que lo que hicimos es “inofensivo”, no molestamos, o molestamos poco, a quienes serán impactados por el cambio y tienen el poder para detenerlo.

Si el proceso de mejora termina en este punto, el consultor, si hubo alguno, habrá cobrado su factura o se habrá logrado un objetivo si somos parte de la Organización, pero en unos pocos meses…

• el proceso se habrá olvidado,
• la organización se habrá reacomodado a la versión anterior a la mejora,
• y las herramientas posiblemente tendrán otro uso o bien estarán en desuso.

Las mejoras son procesos de única vez, un falso arranque produce desánimo.

Cuando las personas se han motivado pero ven que se vuelve a la forma de trabajo anterior, no será sencillo volverlas a interesar y difícilmente admitan sinceramente encarar otra vez una mejora de ese tipo. 
Para utilizar una expresión conocida, “otra vez sopa”.

Cambios de Segundo Nivel – en la Administración

Aquí comienza el cambio profundo, el que tiene que ver con la alteración de los factores de poder de la Organización que se está mejorando. 
Tal vez "Administración" sea un nombre que no traduce todo lo que implica este nivel. Pero la idea es ésa.

¿Pero, qué amenaza a esos cambios?...

A la delegación

• conocer / retener información privilegiada que hace que todo deba moverse alrededor de un grupo pequeño de personas,
• no delegación de decisiones. El nuevo proceso puede amenazar ciertas posiciones, y por lo tanto podrá ser rechazado. Este rechazo puede ser activo, con un rotundo no, o pasivo con una sonrisa. El efecto es finalmente el mismo.
• el temor a salir de la “zona de confort” ^(2y3) donde estamos seguros y con bajo riesgo, y terminar en un lugar desconocido donde nos volverán a evaluar. Los modelos mentales son muy difíciles de cambiar

¿Qué hacer?...

• Explicar y convencer que la pérdida de poder antes mencionada no es tal, por ejemplo que se harán nuevas actividades con mayor nivel de decisión, en lugar de estar tan involucrados en lo operativo.

A las recompensas

•  Las valoraciones o recompensas motivan. La gente se esfuerza por lo que se la reconoce. Si el nuevo proceso contiene actividades que no se valoran o recompensan, difícilmente la persona lo cumpla.

¿Qué hacer?...

• Trabajar con la Organización, reconocer y premiar a quienes están llevando adelante las actividades segúnel nuevo proceso indica, y con ello está  logrando resultados, aunque sean mejorables.
• Oír las quejas.

-  

  A los Indicadores ⁽⁴⁾

• Posiblemente los indicadores anteriores, formales o informales,  ya no sirvan.

¿Qué hacer?...

• Las mejoras más exitosas son aquéllas que acercan a la gente al negocio de la Organización.
• Hay que desarrollar lo más rápidamente posible un sistema de medición de los procesos nuevos, de modo de mostrar logros y evitar las viejas medidas pensadas para evaluar un trabajo distinto.
• Deben mostrar el efecto del trabajo de las personas para el negocio lo más claramente posible y permitir corregir desvíos.

Muchas veces las amenazas en este nivel se asocian a objeciones y resistencias en los mandos medios.

No siempre es así. Estos bloqueos pueden aparecer en cualquier nivel de la jerarquía, incluso proveedores, ya que el poder concebido como lo planteamos en los párrafos anteriores, no es privativo de una posición determinada en la Organización.

La “bajada de órdenes” no es útil en un proceso de mejora.
La situación debe ser explicada y debemos evangelizar entre aquéllos que se ven afectados por los nuevos procesos. 

Cambios de Tercer Nivel – en la Cultura

Cultura, estructura y actitudes de la Organización

La cultura establecida es difícil de cambiar. El peso del “acá siempre se hizo así” probablemente surgirá. 

La organización formal, siguiendo (o simulando seguir) el proceso, convivirá con la informal y establecida. 

Aquí el desafío es que el cambio que está en marcha demuestre que es mejor seguirlo que saltearlo. 

Las urgencias, la impaciencia, el escepticismo, la rigidez y el tiempo en cambiar son los grandes enemigos.

La zona de confort aplica a todos, desde la Dirección hasta el último empleado. Obviamente también, a más tiempo de la persona en la Organización, mayor esa zona.

¿Qué hacer?...

• Dejar que la Organización digiera el nuevo esquema, y lo tome como propio. 

• Acompañar y apoyar el cambio desde la Dirección, teniendo presente que la Dirección también  tiene que cambiar.

Conclusión

Como dijimos al principio, cambiar es complejo. El poder, la rutina, las personalidades, etc. hacen que el cambio dependa en gran medida (si no totalmente) de las personas. 

Como tal hay que verlo. Los procesos escritos son valiosos y necesarios, así como los nuevos roles, tecnología y todo el resto. 

Pero al final del camino está la gente que se sumará al cambio realmente, o no.
Y de ellos depende el éxito.

Material mencionado

1. Business Reengineering: The Survival Guide by Dorine C. Andrews, Susan K. Stalick.

2. Zona de confort Caso 1

3. Zona de Confort Caso 2

4. Calidad de Producto

5. Leading change. John Kotter.

6. Managing e-Business/ Internet-Time Projects, Ed Yourdon May 2001. (Esta es una presentación bastante extensa de Yourdon, donde explica también este modelo, entre muchas otras cosas).

(*)Basado en nuestra entrada original en Excelza 2010.

La vieja y querida WBS

Al ser la creación de la WBS una práctica tan básica y con un resultado tan útil, es justo rendirle un pequeño tributo 
recordando su historia y algunos detalles de la misma. Tómese este post como ese sencillo tributo.

Si bien en la literatura de administración de proyectos prácticamente todo libro  tiene un apartado para el tema WBS, quiero recordar algunas publicaciones y algunos párrafos de autores que han escrito exclusivamente sobre ella:

1. El nombre de los componentes de la WBS ⁽¹⁾

El nombre de la WBS y sus componentes, sustantivos y no verbos. Este tema no es menor.

• Sustantivo - implica algo, un sistema, una casa, etc.
  
  Los niveles siguientes al nombre del proyecto, nos muestran un producto y cómo se va descomponiendo en sus partes.

• Verbo - implica proceso.
  
  Los niveles siguientes a un verbo nos muestran sus actividades y cómo se refinan.

Al Cliente posiblemente le interese más la primera visión, Sustantivo, ya que le resulta más sencillo “ver” los productos, que entender qué parte de ellos está construida al terminar una actividad de la WBS.

2. La regla del 100% ⁽²⁾

Enuncia:

“El próximo nivel de descomposición de un componente de la WBS (hijo) debe representar el 100% del trabajo aplicable al componente de nivel superior próximo (padre)”.

Asegura:

Que a medida que se va descomponiendo la jerarquía, no se pierde ningún componente del Alcance.

• Cada nivel de descomposición incluye el 100% de los entregables del componente padre.
• El resultado final de la WBS es un conjunto de paquetes de trabajo que definen completamente todos los entregables requeridos.

3. El PMI y la WBS ⁽³⁾

PMBOK

El PMI fue variando con el tiempo la definición  de la WBS dada en el PMBOK.
Veamos cómo, según lo resumen Norman y Brotherton y ampliado con el PMBOK 2013 (5ta edic.).

• 1987: Un “árbol genealógico” orientado a actividades.
• 1996 / 2000: Un agrupamiento de los elementos del proyecto, orientado a entregables, que organizan y definen el alcance total del proyecto.
• 2004: Una descomposición jerárquica, orientada a entregables, del trabajo a ejecutar por el equipo de proyecto para lograr los objetivos del proyecto y crear los entregables requeridos. Organiza y define el alcance total del proyecto.
• 2008: Ídem 2004.
• 2013: Una descomposición jerárquica del alcance total del trabajo, a ejecutar por el equipo de proyecto para lograr los objetivos del proyecto y crear los entregables requeridos. (esto parece un reordenamiento de los términos, en esencia se dice lo mismo)

Es interesante observar el cambio, desde la primera definición a la última, reconociendo a medida que pasa el tiempo la visibilidad del entregable (producto intermedio o final) por sobre la actividad, sobre todo a los ojos del cliente.


4. Estándar de WBS⁽4)

Muy recomendable el Practice Standard for Work Breakdown Structures – 2006 del PMI.
Utiliza como ejemplo la construcción de una bicicleta. Excelente explicación del tema.


Resumiendo:

Es una práctica muy útil, una herramienta muy visual para mostrar los límites del proyecto, estimar, planificar, etc..

Sin embargo, al menos en mi experiencia personal, no es algo demasiado conocido formalmente fuera del entorno de la comunidad de Proyectos (miembros de equipos de proyecto, capacitadores, consultores, etc.). 
Notable, no es así?

Bibliografía:

(1) Work Breakdown Structure - the foundation for project management excellence.Norman, Brotherton y Fried.

(2) Effective work breakdown structures. Haugan, G.
(3) PMBoK(R) 5th edition. 
(4) Practice Standard for Work Breakdown Structures. PMI.


Parte de este material fue publicado en Excelza en el año 2010.

Sobre la belleza

Algo que los testers hemos aprendido, a veces duramente, es que "LA BELLEZA ESTÁ EN LOS OJOS DEL OBSERVADOR", y de igual manera, la calidad de un sistema o producto de software puede medirse con una vara que tiene diferente medida según el interesado al que consultemos.

Para nosotros, entonces, el dicho pasa a ser "LA CALIDAD ESTÁ EN LOS OJOS DEL OBSERVADOR".

Relacionado con la belleza, también hemos aprendido que no siempre nuestra profesión o nuestras actividades son consideradas bellas, ya sea por otros miembros de los equipos de proyecto en que trabajamos, o incluso por estudiantes y futuros profesionales, que miran el testing como una actividad de segunda categoría.

Sin embargo, para nosotros el testing ES BELLO, ES interesante, ES desafiante.

Buscando bibliografía, di hace un tiempo con este libro, que si bien no es un libro técnico, es muy interesante por la diferente y sin embargo común temática y por las definiciones de muchos especialistas de qué es BEATIFUL TESTING para ellos. O qué encuentra bello cada uno, en relación a nuestra tarea de todos los días.

Beautiful Testing: Leading Professionals Reveal How They Improve Software (Theory in Practice) by Tim Riley and Adam Goucher (Paperback - Oct. 22, 2009)

Según aclaran los editores, el libro no es una colección de how-to's, ni una colección de case-studies, y las regalías por su venta son donadas a una campaña de Naciones Unidas para la lucha contra la malaria en África.

Recopila ensayos de diversos profesionales, agrupados a lo largo de tres temáticas; cada ensayo es un capítulo. Las temáticas son:

·                     Los Testers, sus características y su interacción con otras áreas (capítulos 1 a 4);

·                     El Proceso, qué hace el tester y por qué (capítulos 5 a 17);

·                     Las Herramientas que ayudan a los testers a hacer su trabajo más eficazmente (capítulos 18 a 23).

Considero interesantes a nivel general, los capítulos siguientes y las definiciones de BELLEZA de sus autores:

Capítulo	Autor(es)	Título	La Belleza del Testing está en…
1	Linda Wilkinson	"Was it good for you?"	…La alegría de la exploración y el placer de la caza; Mantener esto siempre vivo en los testers, fomentarlo y premiarlo adecuadamente.
2	Rex Black	"Beautiful Testing Satisfies Stakeholders"	…Conocer a los interesados; Conocer sus objetivos y expectativas; Establecer métricas para medir objetivos y expectativas de los interesados (belleza externa); Establecer métricas para medir objetivos y expectativas de las pruebas (belleza interna).
6	Emily Chen y Brian Nitz	Bug Management and Test Case Effectiveness"	…Administrar los bugs, y medir la efectividad de los casos de prueba, de la forma más simple posible.
11	Murali Nandigama	"Change-Centric Testing"	…La eficiencia, no en el esfuerzo: entender qué se debería probar, y saber que eso es lo que se está probando.
12	Karen N. Johnson	"Software In Use"	…Que en este mundo imperfecto, la gente hace sus mejores esfuerzos para generar productos que importan, y cada uno de esos productos necesita gente que los sepa probar. (Este artículo se refiere en particular a software embebido en dispositivos médicos).
13	Chris McMahon	"Software Development is a Creative Process"	…La naturaleza artística de este trabajo: La construcción de software es un proceso estético, es la labor de interpretación de un artista, y el testing es la evaluación de esa interpretación. Por eso es bello.
18	Andreas Zeller y David Schuler	"Seeding Bugs to Find Bugs: Beautiful Mutation Testing"	…Poder experimentar con las herramientas disponibles para hacer test de mutaciones, y con ellas analizar la calidad de las pruebas automáticas utilizadas (poder hacer QA del QA).

Y en particular, creo que el Capítulo 1, de Linda Wilkinson, "Was it good for you?", debería ser leído por todos los líderes involucrados en proyectos, sean o no líderes de testing, y por los responsables de áreas funcionales de QA/QC.

Otros capítulos pueden resultar igualmente interesantes, en función al tema / proceso / herramienta que particularmente tratan y nuestro contexto inmediato.

¿Qué más encuentran bello en nuestro trabajo como testers?

Post originalmente publicado en excelza - 21-04-2010