En els darrers anys, la indústria del programari ha viscut una febre per la generació automàtica de proves amb intel·ligència artificial. Cada demo promet desenes de casos de prova extrets d'un document de requisits, i el públic assentix convençut. No obstant, qui ha treballat en entorns reals d'integració contínua sap que escriure tests mai ha estat el coll d'ampolla. El veritable problema apareix l'endemà al matí, quan l'equip s'enfronta a seixanta errors vermells i ha de decidir què signifiquen. Aquest procés de triatge consumeix hores diàries i, en la majoria dels casos, la causa no és un error de codi sinó un entorn inestable, un fixture desactualitzat o un dispositiu que no va acabar de reiniciar-se. Necessitem una intel·ligència artificial que llegeixi errors, no que els generi.
A Q2BSTUDIO, empresa especialitzada en aplicacions a mida i solucions tecnològiques avançades, hem observat que el veritable valor de la IA no està en escriure més tests, sinó en diagnosticar els que ja existeixen. Els nostres equips treballen amb clients que mantenen suites amb milers de proves que s'executen cada nit. Amb una taxa de fallada del tres per cent, això suposa seixanta incidències diàries. D'elles, el vuitanta per cent no són defectes reals: són col·lisions de temporització, dades seed que es desvien, o una màquina que no respon. Un enginyer triga uns deu minuts per fallada a revisar logs i decidir si és rellevant. Això suma un dia complet de treball perdut cada jornada. És una càrrega que es podria automatitzar, i tanmateix la majoria d'eines d'IA se centren a generar més proves, no a alleujar aquesta sobrecàrrega.
El problema s'agreuja quan el sistema sota prova inclou hardware físic. Una única fallada en un rig de dispositius pot tenir quatre causes: una regressió en el codi, un canvi en el firmware, una deriva del propi rig (calibració, cablejat, temperatura) o una condició de carrera física. Només la primera és un bug real; les altres tres fan que l'equip perdi la confiança en la suite al cap d'uns mesos. Un stack trace no distingeix entre elles, i tampoc ho fa un model de llenguatge mirant aquest stack trace. Per això, abans de construir un agent d'intel·ligència artificial que intenti diagnosticar, cal assegurar-se que la canonada de dades recull tota l'evidència necessària. A Q2BSTUDIO anomenem això el 'paquet de fallada': un objecte únic que agrupa l'identificador de l'execució, l'historial de les últimes vint execucions del test, la versió del firmware, l'ID del rig, els artefactes associats (logs, captures de pantalla, mètriques del host) i qualsevol canvi en el codi des de l'última vegada que va passar. Només amb aquesta informació, un humà pot detectar en segons si la fallada és per una actualització de firmware o per un problema de calibració. L'agent ha de fer el mateix, però de forma sistemàtica i sense intervenció humana.
El següent pas és estructurar el veredicte perquè sigui enrutable, no llegible. No volem un paràgraf que ningú llegirà, sinó un objecte amb categories clares: regressió, entorn, inestable o desconegut. Cada categoria té una ruta d'acció: si és regressió, bloqueja el merge i avisa a l'equip propietari; si és entorn, s'envia a la cua d'infraestructura amb l'ID del rig; si és inestable, es registra contra la puntuació d'estabilitat del test i, en creuar un llindar, s'obre un bug. El important és incloure un camp d'evidència contradictòria, que mostri quines dades l'agent va haver de descartar per arribar a la seva conclusió. Això permet a un revisor entendre el raonament i corregir errors. L'agent no ha de tancar la porta per si sol: la seva funció és recomanar i anotar, però la decisió final que bloqueja un release o aïlla un test ha de passar per un humà. Si un agent massa confiat classifica una regressió real com a inestable, aquest bug viatjarà a producció sense que ningú el detecti.
El veritable valor apareix quan cada veredicte confirmat o corregit per un humà es converteix en un exemple etiquetat que retroalimenta el sistema. Un classificador supervisat aprèn ràpidament els patrons repetitius: si el rig quatre deriva constantment, al tercer incident ja no cal que l'agent raoni des de zero. En aquest punt, el sistema és eficient: un model barat gestiona les signatures comunes, l'agent només intervé en les noves, i els humans veuen únicament els casos residuals. Mesurem l'èxit no per la 'precisió de l'agent', sinó pel temps mitjà de triatge i pel percentatge de fallades que cap ésser humà necessita obrir. També vigilem el nombre de regressions reals que es van etiquetar erròniament com a inestables, mostrejant periòdicament aquell grup per calibrar el risc.
A Q2BSTUDIO integrem aquestes capacitats en les nostres solucions d'automatització de processos, aprofitant la nostra experiència en intel·ligència artificial i cloud computing amb AWS i Azure. També apliquem principis de ciberseguretat per garantir que les dades de diagnòstic no es converteixin en vectors d'atac, i utilitzem eines de BI i Power BI per visualitzar les tendències d'estabilitat de les suites de proves. El nostre enfocament no és generar més tests, sinó construir sistemes que redueixin la fatiga de l'equip i accelerin la detecció de problemes reals. Perquè al final, el que importa no és quants tests s'escriuen, sinó quantes fallades s'interpreten correctament i es resolen abans que arribin al client.
La demo de la generació de tests és seductora perquè produeix artefactes visibles. Però un sistema de diagnòstic genera absència de treball, i això no s'aplaudeix en una presentació. No obstant, l'equip que deixa de perdre els seus matins en triatge sap que aquest és el veritable avenç. A Q2BSTUDIO apostem per una intel·ligència artificial que llegeixi errors, no que escrigui tests. Aquesta és la direcció que realment necessita la indústria del programari.
