¿Debe ser Testing un departamento separado, e independiente, de desarrollo? ¿O quizá no?

Sin duda, es la visión clásica, la manera más usada de estructurar una organización de desarrollo: ubicar a las personas de pruebas en un departamento separado, aparte, independiente de desarrollo. Un clásico.

La idea detrás de la anterior visión: aquello de no ser “juez y parte”, es decir que quien revisa si “algo está bien” no sea quien lo ha hecho. Más técnicamente, algunos a esto le denominan “segregación de responsabilidades”.

De dicha separación vienen los históricos desencuentros entre desarrollo software y testing, qué si “testing es quien pone palos en las ruedas de desarrollo”, “que si desarrollo intenta saltarse el trabajo de testing”, etc. Lo típico.

En organizaciones grandes es lo que yo más (siempre) me he encontrado, testing separado de desarrollo. Pero últimamente veo cada vez más, normalmente en empresas medianas o pequeñas, otra manera de organizarse, que va muy de la mano de la tendencia a ir a equipos multifuncionales (recuerda aquel post de los equipos modernos de desarrollo son multifuncionales, así disparan la velocidad y la productividad) y que consiste en que testing y desarrollo trabajen juntos en un mismo equipo.

¿Qué ventaja tiene pasar de tener un departamento de testing a tener testers que trabajan dentro de los equipos de desarrollo (como uno más, codo con codo, y no esperando a que desarrollo termine su trabajo)?

Principalmente… eliminar tiempos muertos (aquellos de “déjame una persona de testing para el día X») y evitar que el testing se realice en cascada (lo que hablamos en aquel post de no se puede ser ágil si se prueba en cascada), es decir, que las pruebas sean al final del proyecto, cuando casi no queda tiempo y cuando ya la mayoría de lo que testing detecta “es demasiado tarde para ser solucionado, o no llegamos a la fecha de proyecto”.

Soy consciente de que hay empresas que cuando escuchan esto, lo de que testing puede ser mucho más eficiente trabajando dentro del equipo, y no fuera, tiemblan los cimientos de su edificio, el día se hace noche, aparece un ojo de fuego en la torre de Barad-dûr, etc. Pero que queréis que os diga, yo cada vez lo veo y experimento más y los resultados hablan por si solos.

No obstante, hacer que testing trabaje dentro del equipo de desarrollo no implica necesariamente eliminar el departamento de testing, no, lo que implica es que ahora testing es transversal, u horizontal,  dando servicios con personas ubicadas en cada uno de los equipos de desarrollo.

¿Opiniones? ¿Cómo se estructura testing en tu organización?

Ah, y si quieres ampliar este tema, te dejo el post de el testing ha muerto y los dos organigramas típicos en empresas tecnológicas (pros y contras).