¿Área de testing o testers independientes?

Me encuentro muchas veces ante la pregunta de si es mejor tener un área (o grupo) de testing independiente o tener gente que hace testing formando parte de los distintos equipos de desarrollo.

La idea detrás de la pregunta es que optando por alguna de las opciones (o estrategias) el problema de medir y controlar la calidad está resuelto. El razonamiento me parece equivocado y la razón es que ambas estrategias tienen fines diferentes.

El objetivo de un área independiente de testing dentro de un área de sistemas es controlar la calidad con la que liberan software los distintos equipos de desarrollo. Ellos están para medir el nivel de calidad a la salida del proceso de desarrollo. Tener un área permite lograr una visión independiente de la calidad, que no está sesgada por la agenda del equipo de desarrollo, optimizar costos, tener mayor especialización en el tema y hacer más foco en la calidad.

El objetivo de tener gente que hace testing formando parte de los equipos de desarrollo es tener dentro del equipo alguien especializado en la actividad de testing. En lugar de poner a un desarrollador a probar, ponemos a un tester que en teoría tiene una visión independiente, está mejor preparado y también más motivado para hacer la tarea. Ellos están para controlar la calidad durante el proceso de desarrollo.

Veo por supuesto puntos de intersección entre ambas estrategias pero creo que en realidad son complementarias y, aplicadas simultáneamente, se potencian.

Si tenemos gente dentro de los equipos especializada en testing, los desarrollos saldrán mejor de la fase de programación y entraran mejor a la fase de pruebas. Lográndose seguramente una menor cantidad de ciclos desarrollo-testing. Tener una fase de pruebas independientes nos permite medir todos los desarrollos con la misma vara y de esta forma entender los problemas de cada equipo más fácilmente.

Como cierre creo que la pregunta no es si una opción o la otra, sino más bien cómo ensamblar ambas estrategias de forma de no solaparse y por el contrario, multiplicarse.

Seguimos pensando..

Comentarios

  1. Apuesto fuertemente a que sea ambas opciones obligatorias incluso. Un tester (no programador) en el grupo de desarrollo va a limar detalles gruesos del desarrollo. El equipo de testing independiente podrá pulir errores, bugs y demases yerbas. Mi duda en cuanto al tester en el grupo de desarrollo: tiene todas las facultades y herramientas que el mismo equipo de testing independiente?

    ResponderBorrar
  2. Para cierto tipo de testing, me gusta el "test driven development", de las metodologías ágiles: se empieza escribiendo el código de test de caja negra, luego se ejecuta para verificar que, efectivamente, nuestro codigo no cumple con lo esperado (o sea el test detecta correctamente la falla), luego se escribe el código necesario para satisfacer el test.

    Debo reconocer, sin embargo, que nunca vi un equipo de desarrollo ejecutar esta metodología en forma estricta, ni se me ocurre una forma de garantizarlo. Lo mismo pasa con peer programming o code reviews. Son todas técnicas probadamente efectivas, pero no tiene sentido, en mi opinión, aplicarlas rígidamente.

    Yo se que nada de esto contradice lo que planteás en el post, pero cuando no tenés el lujo de disponer de testers especializados, tenés que ser flexible y creativo. Y mientras voy leyendo tus posts me voy embalando y quiero dar mi punto de vista sobre todo. Mejor paro aca ;)

    ResponderBorrar
  3. Gracias por tu punto de vista Jorge y bienvenidos tus comentarios!

    ResponderBorrar

Publicar un comentario

Muchas gracias por comentar. Por favor deja tu nombre y/o email, los comentarios son mucho más valiosos cuando se sabe quien los hace.

Entradas más populares de este blog

10 definiciones de calidad

¿Qué es time and material?

Teoría Económica y Outsourcing