Tester vs Desarrolladores?

Generalmente se tiene la idea errónea de que el Tester o proceso de testing es encontrar los errores del desarrollador, y no es así. Antes de empezar a describir en detalle el trabajo en equipo, se deben tener en cuenta los siguientes ítems:

  • Ambos trabajan para con un objetivo en común
  • Ambos son parte de un mismo equipo no hay bandos
  • La comunicación es clave en cualquier equipo que persigue un mismo objetivo
  • La colaboración es otro pilar en los equipos de trabajo

Y así podemos seguir enumerando una larga lista de ítems que van a ayudar al equipo a alcanzar nuestro objetivos. Como siguiente paso vamos a describir algunas de las tareas del tester con relación al desarrollador:

  • Colaborar con el entendimiento de la funcionalidad de la aplicación
  • Adelantarse a posible escenarios que generen confusión y que lleguen a resultar en errores en la aplicación o funcionalidad
  • Escribir si es posible los test cases antes de que se empiece el proceso de desarrollo

Las tareas en conjuntos de Testers y Desarrolladores

  • Entregar un producto que cumpla con los requerimientos establecidos
  • Entregar un producto de calidad
  • Entregar el producto a tiempo
  • Etc

Incluso teniendo en cuenta todo lo repasado anteriormente surgen las siguientes situaciones:

  • Un defect se encontró en Producción (ambiente de usuario) generalmente se suele pensar que paso QA entonces el error no fue encontrado por los testers. En estos casos es útil identificar el root cause del defect, ya que si es un defect que no se detecto durante el testing tampoco se considero durante el desarrollo.
  • Una user story tiene muchos defect, se asume erróneamente que la culpa es del desarrollador y en este caso tampoco es acertado, ya que lo que si el tester y el desarollador se reunieron previamente y revisaron la user story deberían estar en el mismo lugar desde lo que implica el desarrollo, en estos casos la comunicación es clave ya sea porque ambos tiene un entendimiento diferente de la user story o ya sea que los requerimientos cambiaron y no están al tanto.
  • Una user story no tiene defects, entonces se asume que el tester no hizo bien su trabajo o falto testing, lo cual tampoco es acertado. En este caso puede ser que ambos tuvieron un entendimiento de lo que la user story debiera incluir y lo que no, etc.

testervsdev

Pueden surgir muchas situaciones como las anteriores en las que se suele buscar culpables lo cual no debiera ser el camino a seguir, como en cualquier trabajo de equipo la responsabilidad es de todo el equipo y tener más o menos defects no mide la cantidad y calidad de trabajo de nadie, el producto final es lo importante y para obtener un producto con calidad se debe trabajar COLABORATIVAMENTE.

Responder

Introduce tus datos o haz clic en un icono para iniciar sesión:

Logo de WordPress.com

Estás comentando usando tu cuenta de WordPress.com. Cerrar sesión /  Cambiar )

Google photo

Estás comentando usando tu cuenta de Google. Cerrar sesión /  Cambiar )

Imagen de Twitter

Estás comentando usando tu cuenta de Twitter. Cerrar sesión /  Cambiar )

Foto de Facebook

Estás comentando usando tu cuenta de Facebook. Cerrar sesión /  Cambiar )

Conectando a %s

Blog de WordPress.com.

Subir ↑

A %d blogueros les gusta esto: