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:
Nota: Originalmente publicado en excelza el 18/10/2009
No hay comentarios:
Publicar un comentario