Si pasamos de externalizar el Testing a integrarlo en los equipos… ¿Qué va a pasar con las testing factories?

Pues mala pinta tiene, no te voy a engañar. Pero vamos que, por suerte o por desgracia, según en el lado que te pille, no va a “llegar la sangre al río”, como dice el refrán, no creo yo que vayan a desaparecer así tan pronto las “Testing Factories”. Lo que sí que está claro es que, en un modelo ágil, el modelo puro de factoría de testing, aquel en el que una empresa mediana o grande iba y contrataba a otra un saco de horas de testing, ahí, para ir tirando, “kilos” de testers que en su vida veía, se podría incluso dudar de su existencia, ese modelo, en agilidad… tiene sentido nulo.
No tiene sentido, porque el testing de “testing factory” es normalmente testing en cascada, y como te contaba en su día,  no se puede ser ágil si se prueba en cascada (aunque uses Scrum, iteraciones o Sprints). Las razones son decenas, otra, con una “testing factory” no puedes ser ágil porque entonces no tienes un equipo multifuncional. Más, el uso de una “testing factory” suele implicar pruebas después de desarrollo, y en agilidad las pruebas empiezan antes que el desarrollo. Otra, con una “testing factory” no puedes ser ágil porque el Testing se convierte en una fase, o en un proyecto en sí, y en agilidad el testing es más una tarea codo con codo con desarrollo. Más, porque el Testing se hace dentro del Sprint y dime cómo “se come eso” con una “testing factory”. Creo que no hace falta seguir.
Pero que  no cunda el pánico o la euforia. Porque, por desgracia, no todo el mundo va a ser ágil. No, y no porque no quiera, sino porque no todo el mundo puede. Demasiados años, cultura y gente en el lado oscuro. Demasiados equipos gigantes. Jerarquías gigantes. Demasiado código de mordor que sólo conoce quien lo hizo. Demasiada consultora bodyshopeadora rancia. Y por ello… seguirá habiendo demasiada “Testing Factory”.
Pero no pierdas la esperanza, no del todo, será por ello, será porque muchas organizaciones son un dinosaurio intentando salir de un charco de arenas movedizas mediante la agilidad (ayudándome del símil de Brooks), que quizá  por ello con los años se irán, bueno esto ya es presente más que futuro, creándose dos grupos, uno mayoritario cuya misión en el mundo es mantener sistemas y estructuras organizativas obesas, porque hay que mantenerlas, manteniendo a macro proveedores succionadores sustituibles, centenares de personas ayudando a mantener esos sistemas, sistemas que algunos, finamente, llaman «legacy», todo ello haciéndolo como se ha hecho de toda la vida (demasiadas veces mal, por cierto). Y luego habrá, hay, un grupo menor más en la élite tecnológica… que digo, en la élite de los negocios basados en tecnología y que no está sólo formado por empresas pequeñas, por mucho que alguno sólo quiera encajonar ahí la agilidad.
Yo que sé que tú eres un chico, o chica, listo, o lista, creo que no necesitas que te escriba en qué lado debes ir situandote. Y creo que también sobran pistas para reconocer en qué lado está, o va a estar en unos años, una organización. Así que, cuanto antes mejor, ves moviendo ficha.

6 comentarios en “Si pasamos de externalizar el Testing a integrarlo en los equipos… ¿Qué va a pasar con las testing factories?”

  1. Desde hace un año trabajo en un proyecto bajo SCRUM para una gran organización; hago parte del equipo de desarrollo y mi habilidad es el testing; sin embargo, el Cliente tiene su propia fábrica de Testing (tercero) y manejamos sprint de 4 semanas; las dos primeras semanas son de desarrollo y pruebas unitarias y en las dos últimas semanas la fábrica de testing realiza sus pruebas. Esto realmente no es ágil, pues estamos incluyendo las pruebas dentro del mismo sprint pero en cascada; dando lugar a que la fábrica de testing tenga iempos muertos en las dos primeras semanas y el equipo de desarrollo los tiene en las dos últimas semanas del sprint.
    Actualmente estamos analizando la mejor manera de incorporar la fábrica de testing a nuestro equipo de desarrollo para evitar estos tiempos muertos; sin embargo creo que seguiremos siendo no ágiles pues el equipo no sería totalmente multifuncional. Por eso comparto tu opinión, en el mundo ágil el tester deben se también multifuncionales.

  2. Hola Javier, qué tal?
    Te escribo desde Uruguay, desde una fábrica de testing (tal vez estoy errado, no había escuchado el concepto antes, pero imagino que sí somos una, en el sentido que la empresa entera se dedica a dar servicios de testing, desde funcional, automatizado, performance, seguridad, etc.).
    Creo que las fábricas de testing también están viviendo un proceso de adecuación. En particular nosotros lo que hacemos es adaptarnos a la metodología del cliente. Muchas veces probamos en cascada, pero en la gran mayoría de los casos nos metemos completamente integrados al equipo de desarrollo, ya sea trabajando aquí con empresas de Montevideo, como con empresas en el exterior.
    Espero aportar con el comentario, ya que creo que una cosa es pensar que la «fábrica de testing» no tiene futuro, cuando en mi humilde opinión, lo que debería suceder es un replanteo de aquellas que se dedican sólo a hacer su trabajo en cascada.
    No sé si me explico, me gustaría conocer sus opiniones al respecto.
    Saludos!!

  3. Un gran artículo Javier. Tan sólo me gustaría saber tu opinión sobre las diferencias entre las labores de testing y las de QA en entornos ágiles. Como bien comentó Ana en uno de los post de esta página son tareas muy distintas y me gustaría saber si el rol de QA lo ves dentro del equipo o es una responsabilidad más externa al mismo. En ocasiones hay requisitos de auditoría externa que deben ser certificados por alguien que no esté en el equipo. Por desgracia creo que los procesos de auditoría frenan el desarrollo del agilismo en algunas empresas y no es por ellas sino por entorno regulatorio.
    Un saludo

  4. Bueno, estamos a 2018 e igual me suenas, alarmista, muy fanatico de la metodologia agil, yo he visto entrevistas con los padres del manifiesto agil y ni ellos los veo tan fanatico como tu, es como que, agil te abrio los ojos y no existe nada mas y bueno, no ha resultado muy bien agil, en algun momento se sostendra con palitos de fosforos, y que haras?, todo va cambiando… y antes no habia testing y antes no existian las metodologías y antes solo existia DOS/windows 3.11 y paramos de contar…. no me pongo la camiseta por ninguna nueva tendencia, porque voy con el cambio continuo… asi enfrento la informatica..

  5. Hola Javier, muy buen post, y además dando de lleno en uno de los principales dilemas en el desarrollo de SW, y que es uno de los «caballos de batalla» en la transicción a un cambio de mentalidad en el diseño y desarrollo.
    Mi duda, al respecto del Testing, es que tenemos diferentes especializaciones, personas que saben programar y codifican testing scripts orientado a la automatización, personas especialistas en herramientas y pruebas de performance, personas especialistas en herramientas y pruebas de accesibilidad, personas especialistas en pruebas de UX, personas especilistas en QA (aunque esto no es Testing), etc, y lógicamente, no todo el mundo saber hacer de todo. Al final el Team, tiene que contar con todos estos profesionales para tener una Testing & QA «completo» y poder garantizar la calidad del producto. Pero claro, al final la dedicación de cada especialista varía, y en algunos casos, la dedicación al producto, puede ser muy pequeña, por que no hace falta más. Bueno… después de todo este rollo, mi pregunta es: en los casos que las dedicaciones de ciertos especialistas al equipo, no se requiera una dedicación/recurrencia media-alta, ¿es necesario que formen parte del Team, participando en todas las ceremonias?, ya en este caso, cada uno de esos especialistas tendría que hacerlo y el Team puede ser enorme, además que estos recursos especializados pueden estar «compartidos» por varios Teams…. no sé si me he explicado bien… Gracias por tus consejos y enhorabuena por tu site.

Deja un comentario

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *

Share This
Ir arriba