La crisis de identidad del tester en nuestros días

El jueves pasado fue la última reunión del grupo Meetup Management 3.0 – Peopleware – Agile Management (grupo que, por cierto, cumple ya un año, supongo que ya sabes de qué va, sino leete antes este post Grupo en Madrid sobre Liderazgo Técnico – Management 3.0 – Peopleware).
La charla, muy interesante, y muy bien expuesta, fue impartida por Pedro Sebastián Mingo. Y más allá del propio contenido de la misma, que trataba de las cualificaciones de los tester en un entorno ágil, la charla, más el posterior debate al que conllevó, volvieron a escenificar la situación de indeterminación, crisis de identidad, ser o no ser, que en nuestros tiempos vive uno de los perfiles tecnológicos más emblemáticos: el tester.
Hace ya casi 2 años de aquel post de probable futuro del desarrollo software y consejos para orientar tu profesión, desde mucho antes, en aquel post, y ahora siempre que puedo, no me canso de decir que aquel “viejo” perfil de Tester al que nadie hacía caso, que estaba porque no se podía ir a los clientes diciendo que “no teníamos testing”, que se pasaba el día haciendo papeles, casos de prueba, que nunca se llegaban a pasar, que en la mayoría de las ocasiones no tenía ninguna cualificación técnica, aquellos tiempos en se buscaba la fuerza bruta más que la inteligencia y la técnica, aquel testing… se acabó, es pasado. Y quien continue hoy en ese testing… es porque también es pasado.
Tampoco es que yo sea un visionario, ni mucho menos, es que es de perogrullo, vamos, que lo ve hasta un gato de yeso. Si la agilidad ha llegado a muchas empresas por la necesidad que se ha creado en su negocio de entregar más y más rápido valor, de manera fiable, en forma de software, a sus clientes, si eso lleva a cuestionarse todo lo que sea un freno para ello, como las relaciones con operaciones, en referencia a pasos a producción, hablo de DevOps, y si testing está en medio de todo como garante de que no se pasan “bombas nucleares” en forma de código y aplicaciones basura… estaba claro que el cambio del Testing, y los tester, tenía que acabar llegando a las empresas, y que aquellas cosas de cómo hacer bien y buen software, y las pruebas, que se llevaban diciendo desde hace muchos años (acuérdate de aquello de “Utilizamos la novedosa técnica de TDD”… ¿Cómo? ¿Novedosa? ¿Seguro?)… acabarían llegando.
Claro que todo cambio llega con dolor para algunos, miedos, inseguridades, rechazos y crisis de identidad. Aunque estos nuevos tiempos hayan traído aire fresco a una de las profesiones clave en tecnología, la están saneando, devolviéndole su pureza, en el nuevo reparto de “cartas”, hay quienes no saben dónde está su lugar.
Es por ello que si en estos tiempo asistes a un debate sobre Testing, verás como la mayoría de las inquietudes giran entorno a cómo encajar los nuevos tiempos en los viejos esquemas, escucharas cosas como…
-Pero, en esta nueva manera de trabajar… ¿El tester está dentro del equipo de desarrollo o está fuera? Porqué nosotros es que trabajamos con una fábrica de testing, caja negra, no sabemos ni quien prueba.
-Pero, en esta nueva manera de trabajar… ¿El tester es un desarrollador, con conocimientos técnicos, pero que prueba o no debe saber de desarrollo? Porqué nosotros es que tenemos tester funcionales que no saben nada de tecnología.
-Pero, en esta nueva manera de trabajar… ¿el operaciones es el que hace las pruebas de carga? ¿Quién hace pruebas de carga? ¿El tester funcional? Uff.
Quizá deberíamos ya empezar a romper con el pasado, quizá así nos sería más fácil entenderlo, ver la foto global, quizá así sea más fácil que intentar estar encajonando el futuro, digo el presente, en nuestros esquemas del pasado, con sus roles, estructuras empresariales y formativas.
Y démonos prisa, porque ahí fuera hay otros que ni se plantean tales cuestiones, quizá nunca conocieron esa antigua manera de trabajar, y que mientras pensamos en cómo meter el presente en el pasado ellos están sacando cada día, a toda velocidad, valor en forma de software a los que aún son tus clientes.