El boom del Testing, y de la automatización de pruebas, desde hace ya unos años es más que evidente. De la mano de la agilidad, del TDD (no escribas ni una línea de código sin tener antes un Test), del ATDD, desarrollo dirigido por las pruebas de aceptación, del BDD – Cucumber – Especificaciones con ejemplos, etc.
En un mundo que busca cómo poder hacer prototipos lo más frecuentemente posible, el Testing, en tiempos, “ya olvidados”, el hermano pobre del desarrollo, se ha convertido en un protagonista principal del ciclo de vida: Sino hay buen Testing no hay prototipado frecuente, pasos a producción frecuentes, etc.
Así que el desarrollo y mantenimiento de pruebas se ha convertido en un desafío, siempre lo fue, pero cada vez más. Sino fíjate en estas cifras:
– Microsoft, «más de un millón de casos de prueba automatizados para Microsoft Office 2007» (esto y más datos los puedes leer en How We Test Software at Microsoft).
– La versión 2.1 de Android, tenía 357.933 LOC (Líneas de código) de JUnit, que son el 17,1% del total del código Java, es decir, 2.090.904 LOC (si necesitas desesperadamente leer más sobre este dato, sigue por aquí Test Cost-Effectiveness and Defect Density: A Case Study on the Android Platform)
– En una “Google Tech Talk”, Jeff Feldstein, entonces manager en Cisco, hablando sobre las pruebas automatizadas para el software de los router: «Hemos diseñado un sistema de pruebas que probablemente es tan complicado como el propio sistema» (si ya te has leído las anteriores referencias, te toca ampliar esta, esta vez es un vídeo, el de la charla).
La “Software Test Code Engineering”
Bueno, ya sabes, esta es una profesión de contrastes, tan pronto te puedes encontrar con los datos anteriores como puedes escuchar “que las pruebas son una perdida de tiempo y una burocracia” (lo escuché hace unas semanas) o ver gente tirar horas y dinero metiéndose en procesos absurdos de automatización de pruebas (véase aquella historia de Automatizar las pruebas puede ser lo peor que hagas en tu vida. Te lo explico con una mala experiencia real).
En cualquier caso, volviendo al tema de la automatización, la creación de pruebas automatizadas, el desarrollo de scripts de prueba, su mantenimiento, etc., es un tema de tal complejidad, a tomar tan en serio como el propio desarrollo, para hasta incluso para tener nombre propio, algunos le están llamando “Software Test Code Engineering” (STCE).
Los profundos retos
Vistos los datos, la realidad del día a día es mas dura, o, al menos la que yo me voy encontrando en un sitio y otro. La realidad es que si bien nuestro entorno tecnológico más cercano ha ido asumiendo la importancia del Testing en global y de la automatización en particular, el lastre de años trabajando de maneras bastante alejadas a esta idea… es difícil de cambiar en dos días.
Modelos de Testing caja negra externalizado, equipos de desarrollo y Testing trabajando de manera separada, arquitecturas software no pensadas para facilitar el testeo, modelos de contratación basados en el caso de prueba en papel, etc., son algunos de los retos que con celeridad tenemos que ir superando antes para poder centrarnos en, realmente, testear de manera eficiente.
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