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).
Primera vez que me tocó hacer una gestión Ágil en una empresa... año 2001. Desde entonces he trabajado en, o para, más de 90. Y he formado a más de 2000 alumnos.
También soy profe de la Universidad Rey Juan Carlos.
- Las 3 matrices de priorización Ágil - 19 octubre, 2023
- Etapas del Agile Product Management - 12 octubre, 2023
- Agile Product Management: DINÁMICA «Árbol Solución Oportunidad» + «Valores Esperados» - 5 octubre, 2023
La empresa que nos ha vendido el software pasa directamente el testing al cliente. Es decir, a nosotros. Cómo lo ves?
No tienen departamento de testing y desarrollan en cascada
En mi opinión el equipo de testing no sólo debe formar parte del equipo de desarrollo, sino que desde el comienzo del mismo, desde que se empieza a esbozar la arquitectura del software se han de tener en cuenta los test. Es un error diseñar y luego, cuando está todo implementado, empezar a pensar cómo testearlo. Una buena arquitectura favorece el testeo posterior. Los que realizan tests y los desarrolladores están todos en el mismo barco.
Esto no quiere decir que sean las mismas personas ni que tengan los mismos intereses. Pero tienen que trabajar en equipo.
Javier, yo parto de un enfoque diferente: considerando la función que cumple el testing. Es decir, si yo tengo un proveedor externo (o varios) que me entregan software y yo lo tengo que aceptar, creo que el equipo de testing de aceptación debe ser independiente del desarrollo. En ese mismo proveedor el testing que le hagan a su código debe correr con la codificación, por dos cuestiones. por un lado le aporta valor al desarrollo (orientando por donde pueden venir los problemas) y por otro para convertir las entregas en un mero trámite (lejos de en una fuente de conflictos).
Saludos
desarrollo y testimg son etapas diferentes , pueden estar en el mismos departamento , pero ejecutado por personas diferentes, desarrollo toca códigos , testing debe probar y garantizar que funcione la aplicación integralmente
Buen dia, el testing debe estar en un cluster para que los testers estén actualizados, se apoyen y obtengan mejoras, pero ese tester debe estar con su equipo desde el invio hasta el final de cada proyecto, aporta muy buenas ideas.
O como la ves javier?
Saludos.
Trabajo en un banco de argentina. Nuestra regulacion norma q deben ser areas que quede bien clara la segregacion de funciones y responsab. Por lo tanto, deben estar separados. En mi opinion es correcto, mejora la calidad, vista gorda en defectos, mitiga riesgos. Si es cierto que hay que trabajar mucho para poder tratar proyectos con metodologia Ágil. Saludos, excelente el blog, sumamente util.
Estoy de acuerdo en las nuevas tendencias. Esta nueva manera de organizarse tiene que ver con la capacidad polifuncional que tienen las personas para formar equipos o Grupos de Alto Rendimiento (GAR); esto trae algunos beneficios, el principal es el costo; luego la velocidad de hacer el trabajo a tiempo y finalmente la productividad. A caso esto, no resulta interesante para el gobierno de TI. Sin embargo, no quiero dejar de lado el aspecto normativo que debe observar cada organización, y que desde mi punto de vista está sobre toda nueva idea de organizarse pero no imposible de reinvertarse.
Saludos y muy buen blog
Soy de la misma opinión de Pedro Sebastián. No es una cuestión de elegir entre un enfoque u otro sino de complementarlos.
Lo que no puede ser es que si un desarrollo ha llevado, digamos, 4 meses luego te pases 1 mes entre testing y modificaciones.
¿Testing trabajando como soporte de Desarrollo?, el deseo cumplido de todo programador. Siento no compartir las opiniones, mi experiencia dice que trabajando en conjunto ambos departamentos, Testing termina subvencionando el trabajo de Desarrollo, incluso termina documentando lo que Desarrollo no hizo. Finalmente los desarrolladores terminan haciendo muy mal la pega confiando en que como Testing tiene que verificar y validar toda línea de código que ellos escriben, no revisan nada. Terminan programando lineas de código sin siquiera ejecutar lo que desarrollaron y los issues detectados se terminan disparando en el tiempo, eso es así es la realidad y al final los proyectos retrasan mucho más.
Los desarrolladores también puede hacer entregas parciales por iteraciones de proyecto para reducir riesgos, por tanto, no es del todo cierto que Testing va a probar siempre todo el proyecto al final de trabajar de forma independientes.
Además el testeador no tiene que tener ninguna relación con lo realizado por el desarrollador para no bloquear su juicio desde el punto de vista del usuario. Yo creo que la mejor solución para mejorar el desempeño de las entregas de Desarrollo es asumir otro recurso como un Revisor de Par, pero que pertenezca a Desarrollo, nunca de Testing.
Es mi opinión personal.