domingo, 18 de octubre de 2009

Sobre nuestra misión como testers

Seguramente lo primero que se nos ocurre es que nuestra misión es encontrar defectos, y/o lograr entregar aplicaciones libres de defectos. Pero esto es sólo un pedacito, y es una visión muy acotada del aporte de valor que nuestro trabajo puede hacer a la 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 nosotros quienes nos contratan o convocan.

  • 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 específicos, seguridad, performance, otros.
    • ….
    • Todas o algunas de las 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. Y esto es a mi entender uno de los orígenes de la "resistencia" que encontramos en algunos proyectos, o 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, y 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 objetivos del cliente / interesados (pueden ser diferentes).
  • Cuestionar y evaluar el producto.
  • Focalizar los riesgos, entender y gestionar los cambios.
  • Investigar, explorar, proveer feedback.
  • Confirmar, comunicar.
  • Aprender, seguir capacitándonos.


En relación a estos puntos, habría mucho más que decir, pero mientras tanto, pueden ver una discusión interesante sobre este tema en

http://www.satisfice.com/blog/archives/61

(James Bach's blog, Question: Tester's Freedom of Thought)

y en el seminario
 http://www.rmya.com.ar/Download/RMyA%20-%20Workshop%20Testing%20-%202009%20-%20v1.0.pdf

Que lo disfruten!

No hay comentarios:

Publicar un comentario