Inteligencia artificial en la automatización de pruebas: un proyecto de un cliente muestra lo que es posible
Cinco desafíos que la IA solo ha hecho visibles
¿Cuántas horas de tu proyecto de automatización de pruebas se dedican al mantenimiento en lugar de a la ampliación de la cobertura? ¿Y cuánto del conocimiento que sustenta tu proyecto reside en la mente de solo dos o tres personas?
Nos planteamos estas preguntas en un proyecto para un cliente del sector asegurador: cientos de transacciones comerciales automatizadas para múltiples clientes, probadas desde la interfaz de usuario hasta la base de datos, en un entorno regulado donde cada prueba influye en la aprobación del lanzamiento. Al implementar Claude Code, salieron a la luz cinco problemas que nos habían estado frenando durante mucho tiempo, pero que nadie había abordado abiertamente hasta entonces.
Situación inicial
Somos responsables de la automatización integral de las pruebas de esta plataforma de gestión de inventario: conjuntos de pruebas que verifican toda la cadena, desde la interfaz de usuario hasta la lógica de negocio y las interfaces con la base de datos. Los resultados deben documentarse de forma auditable.
Un proyecto como este crece. Y con él surgen problemas de los que rara vez se habla porque aparecen de forma inesperada. Precisamente estos problemas fueron los que nos hicieron perder tiempo, no escribir nuevas pruebas.
La primera constatación fue, por lo tanto, incómoda: un asistente de IA no acelera automáticamente un proyecto. Amplifica lo que ya existe: tanto el orden como el caos preexistentes.
Problema 1: Dependencia excesiva de personas individuales
El problema: En todo proyecto de pruebas desarrollado de forma orgánica, existen reglas que no están documentadas. Por qué ciertas suites de pruebas no deberían ejecutarse en paralelo. Por qué un reintento automático en un punto específico causa más daño que beneficio. Por qué un mensaje de error de la gestión de pruebas casi nunca significa lo que dice. Este conocimiento lo poseían solo dos o tres personas en nuestra empresa.
Todos los equipos conocen las consecuencias. La incorporación de nuevos compañeros lleva mucho tiempo. Los errores se repiten porque nadie los ha documentado. Y el proyecto depende de la disponibilidad de cada persona, lo cual supone un riesgo real en un entorno de consultoría.
Cómo lo solucionamos: Tuvimos que explicarle al asistente cómo funciona el proyecto. Y para explicárselo, primero tuvimos que definirlo claramente nosotros mismos. Esta necesidad nos llevó a crear un conjunto de reglas, que se almacena en el repositorio, está versionado y es visible para todos.
El resultado: La mayor ventaja no fue el asistente, sino la documentación que creamos gracias a él. Estas reglas son ahora lo primero que leen los nuevos miembros del equipo. Responden con precisión a las preguntas que, de otro modo, te harías en la tercera semana, después de haber cometido el error.
Problema 2: Pruebas verdes que no comprueban nada
El problema. Este es el tema más incómodo en la automatización de pruebas, y rara vez se aborda abiertamente. Una prueba fallida se muestra en rojo y destaca. Una prueba defectuosa se muestra en verde.
Si se aplica una prueba a un conjunto de resultados vacío, se ejecutará. La prueba permanece en el conjunto de pruebas, consumiendo tiempo de ejecución y generando una confianza injustificada. Para las decisiones de lanzamiento, esto es peor que no realizar ninguna prueba, ya que nadie la verifica.
Aquí reside precisamente el verdadero riesgo del soporte de IA en las pruebas. Un modelo de lenguaje prioriza la plausibilidad, no la exactitud. Ofrece una respuesta convincente, aunque no pueda determinar la correcta. En nuestro caso, se trataba de claves internas de negocio que no se pueden deducir de lo que se muestra en la superficie, aunque así lo parezca.
Cómo lo solucionamos: Formulamos una regla que no afecta al código, sino al comportamiento. Un valor se hereda de un caso de prueba comparable ya definido, o bien no se establece, sino que se marca como una pregunta abierta y se verifica en la primera ejecución. Un valor que activa una luz verde en una prueba sin estar definido se considera un defecto.
El resultado: El enfoque cambia de proporcionar siempre una respuesta a resaltar dónde falta la respuesta. Una prueba en rojo honesta vale más que una en verde engañosa. Esto se aplica independientemente de la IA, por cierto. El asistente simplemente nos obligó a anotarlo finalmente.
Problema 3: Costos de mantenimiento en lugar de mayor desarrollo
El problema: En muchos proyectos de automatización, el equilibrio termina por romperse. El equipo dedica más tiempo a mantener activas las pruebas existentes que a crear nuevas. Dos causas predominan: el acceso inestable a elementos de la interfaz de usuario que fallan con cada implementación y la duplicación de pruebas debido a que no se encuentran los componentes existentes y, por lo tanto, se compilan por segunda vez.
Las herramientas de grabación agravan ambos problemas. Sugieren preferentemente precisamente aquellos métodos de acceso que funcionan en el momento de la grabación y que fallarán más rápidamente después.
Cómo lo solucionamos: Definimos una jerarquía de enlaces que especifica qué método de acceso debe usarse en cada situación y declaramos explícitamente cuáles están prohibidos. Además, implementamos un requisito de verificación. Antes de crear un nuevo componente, se realiza una comprobación en cuatro pasos para determinar si ya existe.
El resultado: Las reglas tienen un doble efecto. El asistente las cumple y el equipo cuenta, por primera vez, con un estándar escrito para las revisiones. Antes, la mantenibilidad era una cuestión de experiencia. Ahora es verificable.
Problema 4: Solución de problemas que va en la dirección equivocada
El problema: Una prueba falla. El informe indica que no se encontró un objeto. Por lo tanto, se realiza una búsqueda del objeto faltante. En realidad, un token de acceso había caducado y la interfaz proporciona deliberadamente una respuesta engañosa por motivos de seguridad.
Además, nos topamos con un problema que nosotros mismos generamos. En el código antiguo, el rastro del error técnico se descartaba antes de que se informara del error. El informe mostraba entonces un error, pero sin ninguna información sobre su origen. Cada análisis comenzaba desde cero.
Estas dos cosas juntas suelen costar horas. Y un asistente que no tenga este conocimiento buscará de forma muy eficiente en la dirección completamente equivocada.
Cómo lo solucionamos: El registro de la falla técnica permanece intacto; es una regla estricta hoy en día. Además, los patrones de error engañosos conocidos están incluidos en el manual, cada uno junto con el paso de diagnóstico específico que aclara la causa real en un minuto.
El resultado: las horas recurrentes se convirtieron en minutos. Sin embargo, el verdadero avance reside en que este conocimiento ya no se pierde cuando la persona que lo poseía está de vacaciones.
Punto crítico 5: Cumplimiento y confidencialidad
El problema: En un entorno regulado, la cuestión de qué se puede copiar en una ventana de chat no es meramente teórica. Alguien que investiga un error de inicio de sesión podría, ante la duda, copiar toda la configuración en una herramienta, ya que la rapidez es fundamental. El riesgo reside en el comportamiento humano. Esto no se puede solucionar técnicamente mediante una reconfiguración.
Cómo lo solucionamos: Directrices claras y explícitas. No se permite el acceso a datos ni a la configuración en las solicitudes, registros, incidencias ni mensajes de confirmación. No se permite eludir los mecanismos de validación de control de versiones establecidos sin instrucciones explícitas. No se permiten modificaciones a los componentes centrales compartidos sin evaluar el impacto en todo el conjunto de pruebas.
El resultado: Cualquier persona que implemente soporte de IA en un entorno regulado necesita que estos puntos consten por escrito, no como un acuerdo verbal. Además, serán los primeros aspectos que se consultarán en una auditoría.
El hallazgo central
Un asistente de IA es tan bueno como el contexto que se le proporciona. Y ese contexto no surge por sí solo.
El ahorro de tiempo cuantificable que obtuvimos se produjo donde existía una base sólida basada en reglas. Esto incluía la creación de nuevos casos de prueba a partir de patrones existentes, la traducción de la documentación a código mantenible y el trabajo estructural recurrente. Donde faltaba esta base, era necesario rehacer el trabajo, a veces más que con la creación manual. Esa es la pura verdad, y por eso hablamos primero de la estructura y luego de las herramientas.
Cabe destacar que ninguno de los cinco puntos anteriores constituye un problema de IA. El conocimiento no documentado, los resultados de pruebas engañosamente positivos, el retraso en el mantenimiento, los patrones de error confusos y las normas de confidencialidad poco claras ya existían. El asistente simplemente los hizo visibles y urgentes.
¿Qué significa esto para tu proyecto?
Si estás considerando incorporar soporte de IA a tu automatización de pruebas, estas son, según nuestra experiencia, las preguntas iniciales adecuadas que debes hacerte:
¿En qué punto de tu proyecto podría surgir un problema sin que nadie se dé cuenta?
¿Qué conocimiento reside en los individuos y en ningún otro lugar?
- ¿Qué porcentaje de su capacidad se destina a mantenimiento en lugar de a nuevas cubiertas?
- ¿Cómo se puede saber, a partir de una reseña, si una prueba realmente comprueba lo que su nombre indica?
- ¿Qué información puede introducir un empleado en una herramienta de IA y dónde está documentada esta información?
Quien pueda responder a estas preguntas ya habrá hecho la mayor parte del trabajo. Encontrar la herramienta adecuada es, entonces, el paso más sencillo.
¿Quieres saber cómo se puede aplicar esto a tu situación? Habla con nosotros.
En un artículo posterior, analizaremos este tema desde la perspectiva del cumplimiento normativo. ¿Qué tipo de evidencia espera un auditor cuando se utiliza la inteligencia artificial en el proceso de pruebas?.
