Marc Hage Chahine siempre ha trabajado en pruebasy ha querido compartir sus experiencias. Tiene la suerte de poder hacerlo en su trabajo diario, pero también escribiendo artículos sobre la¡Tiene la suerte de poder hacerlo en su trabajo diario, pero también escribiendo artículos en el blog Tester's Tavern o en revistas como Programmez! Marc Hage Chahine también tiene el placer de participar en la organización de grandes eventos de pruebas como el STLS (en Sophia Antipolis) y el JFTL.
Hace más de veinte años que se habla de la automatización de pruebas como el futuro próximo. La gente sigue hablando de él como sustituto de las pruebas manuales. Pero está claro que no sustituye ni sustituirá a las pruebas manuales, y también está claro que su aplicación es compleja. Si nos fijamos en las últimas encuestas del CFTL, la automatización de las pruebas no ha progresado en los dos últimos años, a pesar de que nos encontramos en contextos ágiles en los que la automatización es cada vez más necesaria.
Durante mucho tiempo, la automatización siguió siendo muy técnica, con código y desarrollo. Pero desde hace unos años, vemos herramientas sin código ni scripts, que han surgido con el Keyword Driven Testing*, cuyo principal representante es Robot Framework®. Esta es la generación cero de pruebas para personas no técnicas. Tenemos Gherkin® que hará la automatización según el mismo principio. Tenemos otras herramientas que empiezan a ser cada vez más maduras, más accesibles y funcionales. Pero aunque sean accesibles, siguen siendo herramientas bastante técnicas y se basan en código y scripts.
Desde entonces, salen nuevas herramientas: Keysight® con Eggplant, Tosca® de Tricentis o la última versión de UFT®, donde se intenta añadir IA, bloques, módulos, para que la gente pueda utilizarlos más fácilmente. También hay mucho reconocimiento de imágenes, lo que te permite ser agnóstico en cuanto al código y tener un solo script para ejecutar tu prueba en diferentes teléfonos (iOS, Android), tabletas, PCs e incluso incrustados. La próxima evolución será la IA. Estamos asistiendo a la aparición de herramientas como Gravity®, de Smartesting, que analizan los registros para proponer rutas y automatizarlas.
Cuidado, que existan todas estas herramientas no significa que se vayan a utilizar todas. Hay barreras de precio, tanto para hacer esta inversión como para no hacerla. Los equipos encargados del desarrollo de los productos también deben contar con la política adecuada, la estrategia de pruebas correcta y la capacidad de gestionar la calidad. No debemos olvidar que para tener buenas pruebas automatizadas, primero debemos tener buenas pruebas. Esta necesidad de automatización debe ser sentida por los equipos, y la automatización no debe dejarse sólo en manos del probador.
Para mí, la IA está ahí para facilitar la decisión, las acciones. No es más que automatización más allá de la automatización de la ejecución. Debería ayudar a tomar decisiones, pero la IA no lo hará todo. Se necesitan datos, se necesita información y se necesita gente detrás. Con la IA se puede vencer a campeones de Go o de ajedrez, pero la IA de ajedrez no va a vencer a un campeón de Go. Es muy específico y, por tanto, en un caso concreto será más eficaz que nosotros y nos permitirá progresar. Hay muchos casos de uso con la IA, especialmente en la priorización de pruebas, que llevará a la selección. Por ejemplo, tenemos 500 pruebas de regresión, ¿cuáles debemos hacer primero para encontrar el mayor número de errores? Pero al final, puede que solo podamos hacer 400 o 450, así que tenemos que determinar cuáles no haremos.
La IA puede ayudar de varias maneras: puede ayudar con el análisis, especialmente de las pruebas fallidas, puede ayudar con los casos de uso planteados por los editores, cuáles están fallando, por qué, e incluso conseguir que vuelvan a funcionar y arreglar los scripts directamente. La IA también ayudará al mantenimiento y la conservación al permitir una mejor gestión del repositorio de pruebas. Por ejemplo, si hay pruebas duplicadas, la IA nos dirá que debemos pensar en eliminarlas porque no tienen interés, o nos dirá que debemos rehacer los datos de ciertas pruebas, etc. Y la IA también ayudará en la construcción: decimos lo que queremos hacer y el scripting se hace después, que es lo que ya hacen las herramientas sin scripting.
El único límite real de la IA será lo que imaginemos hacer con ella. Los otros límites van a ser los costes de implementación y también el interés por hacerlo, porque no por haber imaginado hacer algo es realmente interesante. Por ejemplo, los coches voladores se llevan imaginando desde hace 50 años y se podrían hacer muy bien, pero al final no sirven para nada, no aportan valor y consumen demasiada energía. Tiene que haber una necesidad.
La IA conlleva muchos riesgos. El primero es un sesgo de exceso de confianza: si la IA lo dice, la IA tiene razón, así que hago lo que dice la IA. Esto suele estar relacionado con el hecho de que no hay tiempo. La IA debe ser una herramienta de apoyo a la decisión, pero la IA no debe tomar la decisión. Si no tenemos tiempo para pensar, para ver los indicadores, para ver los datos, ya no estamos en el apoyo a la decisión, estamos en la toma de decisiones. Y ese es el verdadero riesgo de la IA, saber que la IA no es perfecta. Vive de datos, datos que, aunque estén actualizados, sean relevantes y representativos, pueden cambiar de un día para otro. Pongamos un ejemplo muy actual, las encuestas de las elecciones presidenciales: Macron estaba al 20/25% en las encuestas, luego hay un nuevo dato, la guerra de Ucrania, y pasa al 30/35, luego hay un nuevo dato, las consultorías, y vuelve al 25%. La verdad de un día no es la verdad del día siguiente y la IA no es capaz de anticiparlo.
Por defecto, no tengo confianza. Veo potencial, posibilidades, contextos en los que funcionará. Por ejemplo, en el caso de Gravity®, tenemos dos opiniones sobre las API que se darán en el JFTL (Día de la Prueba del Software en Francia). En este contexto, en este marco, funciona bien y, por lo tanto, tendré confianza, para un contexto similar, para lograr implementar una solución que ahorre tiempo. De lo contrario, no hay confianza mientras no haya retroalimentación, por defecto, no funciona.
El contexto ideal va a ser todo tareas repetitivas y aburridas, cosas que no son necesariamente difíciles pero sí fáciles y poco interesantes de hacer. Van a requerir que hagas muchas cosas fáciles, pero la secuencia va a ser agotadora y se va a volver difícil. Todo esto será objeto de automatización, y así ha sido a lo largo de la historia de la humanidad: las herramientas se hicieron porque era más fácil romper un coco con una piedra afilada. Y cada vez se liberaba más tiempo.
¿Qué le ha parecido esta entrevista? Aproveche la oportunidad de descubrir nuestras otras entrevistas con Bruno Legeard y Xavier Blanc.