Av Kjell Omdal Erichsen, Testify
Jeg har brukt forskjellige KI-verktøy hver dag i over halvannet år nå til test og testutvikling. Ikke som en erstatning for testing, men for å teste mer og raskere. Der hvor KI-verktøy virkelig har hjulpet er typisk i situasjoner der alternativet ganske enkelt ville vært å ikke teste i det hele tatt. Gjennom tre korte historier vil jeg forsøke å dele litt praktisk erfaring fra min nye testhverdag.
#1 Integrasjonsproblemet
Når man jobber med kunder i komplekse integrasjonslandskaper, er flaskehalsen sjeldent selve testingen. Det er alt rundt: Å få tak i riktige testdata, sette opp riktig tilstand i miljøet og koble sammen de riktige verktøyene raskt nok; før muligheten forsvinner fordi neste utfordring har rykket forbi på listen over prioriteringer og behovet for testing plutselig er større et annet sted.
En morgen i mars kom testlederen på et stort og viktig prosjekt bort til meg. Han var frustrert. QA-miljøet for den eldre databasen hadde vært nede i to uker på grunn av en oppgradering. Han hadde ingen testdata og prosjektet hans sto fast. Spørsmålet da var ikke «Hvordan designer vi en god testsuite?», men snarere: «Hvordan skal vi få testet noe i det hele tatt før brukerne skal på? Vi skulle vært ferdige i forrige uke.»
Jeg satte meg ned ved siden av ham, startet Claude, og så begynte vi å bygge. I løpet av noen timer hadde vi et fungerende verktøy som tok CSV-eksporter fra en eldre database og publiserte dem som meldinger på et Azure Service Bus-emne, i nøyaktig det formatet systemet under test forventet, med relevante testdata. Testlederen kunne fortsette arbeidet og følge planen sin.
Dagen etter trengte han et annet meldingsformat. Vi utvidet verktøyet. Dette gjentok seg påfølgende dag, han trengte en tredje utvidelse. Innen utgangen av uken hadde han fått en skrivebordsapplikasjon som kunne kjøres med ett klikk. Han kunne kjøre den selv, logge inn med sin egen bruker, uten at han måtte bygge, kompilere eller deploye.
Her fungerte KI ikke som en erstatning for å tenke på test og testbarhet, men som en måte å korte ned avstanden mellom «Jeg vet hva jeg trenger» og «Jeg har et verktøy som gjør det». Ikke perfekt, men brukbart nok for formålet.
#2 Pseudonymiseringsløpet
Noen uker senere trengte et annet team å flytte testdata fra produksjon til et QA-miljø. Dataene inneholdt personopplysninger. Prosessen med å hente ut dataene, pseudonymisere dem og laste dem inn på riktig sted hadde vært manuell, langsom og full av feilkilder. Det betydde at prosessen sjelden ble gjennomført. Og dermed var QA-miljøet så godt som alltid utdatert.
Jeg brukte tretti minutter sammen med utvikleren som hadde ansvaret for systemet, der vi skisserte hvordan løsningen burde se ut. En Function App skulle lese fra produksjon, pseudonymisere dataene underveis og skrive dem til QA via Service Bus. Han syntes det hørtes bra ut. Dagen etter hadde jeg en fungerende versjon.
Så støtte vi på problemer med utrullingen: Tilgangsrettigheter, tillatelser til GitHub-repositoriet og Azure-konfigurasjon. Vi hadde en ny designøkt. Tretti minutter, to personer. Vi splittet applikasjonen: én Function App for pseudonymisering og separate lasteapplikasjoner for hver datatype. Dagen etter var den nye versjonen klar, og utviklerteamet tok det derfra.
Den totale tiden fra «Vi har et problem» til «Vi har en løsning som kan rulles ut» var under én uke. Den totale tiden jeg brukte i møter, var under to timer. Resten av tiden gikk til bygging, der Claude utførte selve kodingen, mens jeg jobbet med arkitekturen, domenespesifikke vurderinger og testingen av selve verktøyet.
#3 Feilsøking av sertifikat
Ikke alle KI-assisterte gevinster handler om store byggeprosjekter. Noen ganger dreier det seg om en feilsøkingsøkt på to timer, som ellers kunne ha tatt to dager.
Et prosjekt hadde vært blokkert i flere måneder på grunn av et problem med sertifikat og API-nøkkel i en Altinn-integrasjon. Symptomene var tydelige: autentiseringsfeil. Men etter hvert viste det seg at rotårsaken lå skjult i hvordan virksomhetssertifikatene ble kodet og sendt videre.
Sammen med Claude bygget jeg et lite diagnostikkverktøy i Python. Det inspiserte sertifikatkjeden, dekodet nøkkelmaterialet og sammenlignet dette med det API-endepunktet forventet. Blokkeringen var så fjernet 48 timer etter at problemet ble eskalert. Aktiv feilsøkingstid var under 2 timer.
Det er til utvikling av denne typen raske og målrettede verktøy jeg opplever KI som mest konsekvent nyttig, og at det leverer en umiddelbar og tydelig verdi for kundene. Ikke for store automatiseringsrammeverk, men for små, presise instrumenter som bygges for et konkret problem, brukes én eller to ganger og deretter legges bort, eller brukes som prototyper eller innspill til et prosjekt eller system som skal videreføre hele eller deler av funksjonaliteten.
Kostnaden ved å bygge slike verktøy er lav nok til at det nesten alltid er verdt å forsøke. I verste fall har man kastet bort en time eller to. De fleste kan koste på seg den tiden til å prøve.
Valideringsbyrden
Det finnes også en kostnad som ikke vises i tallene for hvor raskt noe kan bygges, og det er viktig å være åpen og ærlig om den: Når KI genererer kode, må noen validere den. Ikke bare kjøre den for å se om den fungerer, men faktisk lese den, forstå den og bekrefte at den gjør det den skal under alle relevante forhold.
Denne valideringsbyrden er reell, og den vokser med kompleksiteten i det som bygges. Jeg har begynt å kalle dette “comprehension debt”, eller “forståelsesgjeld” på norsk. Når du bygger noe med hjelp fra KI, kan du ende opp med kode som fungerer, men som ingen fullt ut forstår.
Dette kan være helt greit for et diagnostikkprogram som bare skal brukes og deretter kastes. Men det er ikke greit for et pseudonymiseringsløp som håndterer personopplysninger i produksjon.
Jo større konsekvenser verktøyet kan få, desto viktigere er det å bremse ned og faktisk forstå det du har bygget. Og ikke minst: Behandle det som all annen programvare. Legg til tilstrekkelig testdekning og KI-lesbar dokumentasjon, slik at KI-agenten ikke introduserer nye feil senere.
Dette er ikke et nytt problem, men det samme problemet som oppstår med all kode som skrives raskere enn den blir forstått. KI akselererer skrivingen, men det akselererer ikke forståelsen. Denne asymmetrien må alle testere som bruker slike verktøy ha i bakhodet.
Fra spesifikasjon til kode: Hva endrer seg, og hva er som før?
I artikkelen LLMs Are Just Another Compiler. And That’s a Good Thing! har Erik Arisholm skrevet om store språkmodeller som kompilatorer; verktøy som oversetter en spesifikasjon fra én notasjon til en annen. Kvaliteten på resultatet er begrenset av kvaliteten på utgangspunktet. Det er en innfallsvinkel som stemmer svært godt med det jeg opplever i praksis.
Når jeg bruker Claude til å bygge et testverktøy, beskriver jeg ikke vage intensjoner og håper på det beste. Jeg spesifiserer presist: Hvilken datastruktur skal inn? Hvilken transformasjon skal utføres, for eksempel pseudonymisering? Hva skal komme ut? Hvilke feilsituasjoner skal håndteres?
Jo bedre jeg spesifiserer, desto bedre blir resultatet. Hullene jeg etterlater, fyller Claude ut i stillhet. Og det er nettopp i disse stille antakelsene som feilene oppstår.
Heller ikke dette er et nytt problem, men den samme utfordringen testere alltid har hatt med krav. KI gjør det raskere å gå fra spesifikasjon til kjørende kode. Det gjør det ikke enklere å skrive en god spesifikasjon. Om noe, gjør hastigheten spesifikasjonsproblemet mer synlig, fordi du kommer raskere frem til feil svar.
Så det som ikke har endret seg, er at du fortsatt må forstå systemet. KI håndterer den mekaniske oversettelsen, men du må fortsatt vite hvordan en god test ser ut. Du må fortsatt kunne lese resultatet og vurdere om det faktisk er korrekt, eller bare ser overbevisende ut.
Hva betyr dette for testing som fagdisiplin?
I Verdien av testfaget, argumenterer vi i Testify for at testing er en fagdisiplin og ikke bare en aktivitet. Uavhengig verifikasjon avdekker forhold som utviklerens egen gjennomgang strukturelt sett ikke kan fange opp. Bærekraftig testautomatisering krever tekning rundt arkitektur, ikke bare skripting.
KI endrer ikke på noe av dette. Det som endrer seg, er hvor den erfarne testeren bruker tiden sin. Det mekaniske arbeidet med å skrive standardkode, koble sammen datatransformasjoner, lage testkjørere og kjøre tester parallelt går raskere nå. Det er bra.
Det betyr mer tid til arbeidet som faktisk krever vurderingsevne:
- å utforme god testdekning
- å analysere mulige feil i integrasjoner
- å avgjøre hva som bør automatiseres, og på hvilket nivå
- å validere at verktøyene du har bygget, faktisk gjør det du tror de gjør
Etter min erfaring er det testere med et sterkt faglig fundament som får mest ut av KI-verktøy. De vet hva de spesifiserer. De vet hvordan et godt resultat ser ut. De vet når de kan stole på resultatet, og når de må undersøke nærmere. Verktøyene forsterker det som allerede finnes. De erstatter det ikke.
Hvordan blir fortsettelsen?
Jeg har ikke tenkt til å prøve å forutsi hvor KI-verktøyene er om to år. Det jeg kan si, er at mønsteret jeg har beskrevet virker robust: Testeren er arkitekt og validator. KI er en rask, mekanisk utøver.
Men spesifikasjonsproblemet forsvinner ikke. Behovet for uavhengig verifikasjon forsvinner ikke. Vurderingsevnen som kreves for å utforme gode tester, forsvinner ikke. Når du bygger flere verktøy og løser mer komplekse problemer, blir evnen til å verifisere og validere mer verdifull – ikke mindre.
Det som forsvinner, er unnskyldningen om at det ikke var tid til å bygge de riktige verktøyene. Spørsmålet er nå om man har ferdighetene som trengs for å bruke tiden godt.
Tilbake til blogg