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 a mi criterio uno de los orígenes de la “resistencia” que encontramos en algunos proyectos y una posible fuente de malentendidos 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, brindar y facilitar la retroalimentación.

• Confirmar, comunicar.

• Proveer información relevante para la toma de decisiones, a distintos niveles de interesados.

• 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.

A quienes les interese reflexionar más sobre este tema, les recomiendo la discusión “Question: Tester’s Freedom of Thought” [1] en el blog de James Bach, que aunque es de 2006, sigue siendo muy valiosa.

Referencias

1. J. Bach. “Question: Tester’s Freedom of Thought”. http://www.satisfice.com/blog/archives/61