La AI está reivindicando el rol del Software Tester

Figura 1. Imagen generada por AI.

English translation, here.

En las últimas semanas he leído y escuchado de todo acerca de la AI (en el desarrollo de software), tanto cosas buenas como cosas malas. Es cada vez más notorio quienes están en favor de la AI y quienes están en contra de ella (aunque pareciera que los primeros están ganando). Si alguien me preguntara mi postura acerca del tema, yo respondería que miro con cierto recelo el asunto, pero también con cierto optimismo (no me puedo quedar atrás en algo que afecta a toda mi carrera profesional y que además uso diario en el trabajo). Sobre mis opiniones personales acerca de la AI puedo hablar en otra entrada.

Hoy quiero enfocarme en algo que vengo rumiando desde hace tiempo. Y es que con todo el alarmismo que se ha hecho en torno al desarrollo de software con AI, veo con mucha claridad lo siguiente: La AI está convirtiéndonos a todos en testers de software.

Sí, leyeron bien: La AI está convirtiéndonos a todos en testers de software.

Espero no liarme tanto con esto, pero empezaré desde el principio. Desde que se liberaron los primeros agentes de AI, las personas (técnicas y no técnicas) empezaron a experimentar con ellos y a desarrollar aplicaciones de diversa índole. A su vez, empezó a ser muy evidente que muchas de estas creaciones tenían bugs críticos (además de serias vulnerabilidades de seguridad). Con el tiempo se fueron estandarizando las prácticas de desarrollo de software con los agentes y se empezaron a desarrollar aplicaciones un poco más robustas (aunque no libres de defectos y de vulnerabilidades de seguridad). En Internet existe una amplia literatura acerca de cómo crear prompts perfectos para pedirle a los agentes de AI que generen soluciones a problemas técnicos o empresariales de nuestro día a día. Estos nos ayudan a eficientizar más el trabajo de los agentes y a gastar menos tokens.

Se habla mucho ahora de que como developers y testers pasaremos la mayor parte del tiempo (al menos por ahora) orquestando lo que los agentes de AI hacen. Y no están equivocados. Hay muchas cosas involucradas en esta orquestación: Análisis de requerimientos, planeación, diseño, configuración de ambientes, ejecución, monitorización y finalización (reporte). ¿Les suena familiar todo esto?

La AI de poco a poco nos está convirtiendo a todos en testers de software, aunque a muchos (no digo que todos porque hay excepciones) de nuestros colegas developers no les encante la idea de hacer pruebas de software. Y todo este proceso es «manual» (aunque lo más correcto sería llamarlo «exploratorio»).

Si hemos tomado la ola de la AI, ahora pasamos la mayor parte del tiempo analizando si ésta ejecuta lo que le hemos pedido, y corregimos o ajustamos en donde sea necesario. Claro, esto no quita que en alguna parte del proceso de desarrollo de software tengamos que meter nuestras manos para escribir código (o para resolver algo que la AI no puede).

Pero hay algo más que me gustaría mencionar. He visto que hay demasiado revuelo acerca de que la AI va a quitarnos los puestos de trabajo a todos los que nos dedicamos a hacer pruebas de software ya que ésta hace las tareas que nosotros hacemos. Tomaría esta afirmación con pinzas ya que he visto todo lo contrario.

He trabajado con varios developers (y alguna vez fui uno de ellos) y sigo a varios de ellos en redes sociales. He visto cómo la mayoría de ellos se fascinan cuando salen herramientas al mercado que pareciera que de manera mágica hacen las pruebas que no quieren hacer. Ese fenómeno lo observé cuando salió Cypress y después cuando salió Playwright con todas las funcionalidades que lo caracterizan. Y el mismo fenómeno observo cuando dicen que la AI hace las pruebas por ellos.

Existe un sesgo muy grande entre los developers al momento de comprender lo que hace el tester de software. Muchos piensan que automatizar es probar, y no es así. También muchos piensan que haciendo pruebas automatizadas de e2e cubren lo que su código debería hacer (haciendo a un lado los unit tests y otros tipos de pruebas que ellos deberían hacer). Cualquier persona sensata con conocimientos en desarrollo de software sabe que no hacer pruebas desde las primeras etapas sale más costoso y contraproducente, y que al principio el proceso siempre será exploratorio, no automatizado.

Michael Bolton, referente en la industria del testing desde hace décadas, lo resume bien cuando dice que hacer pruebas es un proceso de análisis, intuición, reflexión, crítica y retroalimentación, y que el uso de herramientas para automatización es algo que nos ayuda a eficientizar de cierta manera nuestro trabajo.

Existe un riesgo muy grande al momento de querer delegar la parte de pruebas de software a la AI. Los agentes aprenden de nosotros (los seres humanos). Los developers son seres humanos (aún). Si los agentes están aprendiendo de nosotros, ¿quién nos asegura que la AI hará bien las pruebas de software? Muchos sabemos que los developers tienen sus trucos para hacer que las pruebas pasen «exitosamente» y que todo en el dashboard o reporte aparezca de color verde. Así también, tienen sus sesgos al momento de hacer sus pruebas. Hace ya varios años, Blanca Moreno (colega tester de la comunidad de QA Minds) nos dijo a modo de chascarrillo: «Los developers tratarán su código como si fuera su bebé. Lo verán hermoso siempre. Pero la tarea de los testers es demostrar todo lo contrario».

La AI nos puede hacer caer en la ilusión de que todo lo que ha generado es correcto (cuando muchas veces no es así). Debemos analizar detenidamente lo que los agentes nos están generando. La experiencia nos ayuda a evitar la mayor cantidad de errores posibles en el desarrollo (y a no confiarnos durante el proceso).

Recientemente vi esto en LinkedIn. Esto es algo que se veía venir.-

En conclusión. La AI nos está convirtiendo a todos en testers de software, y eso es algo muy bueno. No hay que dar por muertas las áreas de QA/QC (y no deberíamos hacerlo. ¡Ahora más que nunca los roles del software tester y del cybersecurity engineer son más necesarios que antes!). Automatizar no es probar. Debemos seguir evangelizando a la comunidad acerca de la importancia de hacer pruebas (y lo que es hacer pruebas). La experiencia nos ayuda a escribir buenos prompts que le podemos mandar a los agentes y así obtener software de mejor calidad. Debemos ser más críticos con lo que la AI nos genera y a no confiar ciegamente en ella. Y no olvidemos tomar agua (es importante estar bien hidratados).

Bibliografía sugerida.-

• Bolton, M. (2024, June 25). Sharper Terms for “Manual Testing.” Developsense.com. https://developsense.com/blog/2024/06/sharper-terms-for-manual-testing.
• Bolton, M. (2021, August 24). Alternatives to “Manual Testing”: Experiential, Interactive, Exploratory. Developsense.com. https://developsense.com/blog/2021/08/alternatives-to-manual-testing-experiential-attended-exploratory.
• ‌Bolton, M. (2013, February 24). “Manual” and “Automated” Testing. Developsense.com. https://developsense.com/blog/2013/02/manual-and-automated-testing.