Få kontroll på KI-basert kode

De to mest krevende problemene er nå på hver sin side av KI-en: presise spesifikasjoner på vei inn og uavhengig verifikasjon på vei ut:

• Spesifikasjonen setter taket. En språkmodell er en kompilator for naturlig språk. Den gjengir det du uttrykte, og gjetter på det du utelot.

• KI fyller hullene i stillhet. En kompilator stopper ved tvetydighet. En språkmodell lager noe som virker rimelig, og hullet forblir usynlig til det når produksjon.

• Å kontrollere eget arbeid er ikke uavhengig verifikasjon. Enten forfatteren er en utvikler eller en agent, må noen utenfor løypa stille spørsmålene forfatteren ikke kan stille.

• Testautomatisering er arkitektur, ikke skripting. Mer generert kode betyr mer regresjonsrisiko, og testsettene som skal fange den, må tåle stadig endring.

• KI endrer hvor fagfolk bruker tiden sin, ikke hvilken kompetanse som teller. Vi bruker KI i arbeidet vårt, samtidig som vi holder fast ved grunnferdighetene som lar oss vurdere det den produserer.

Med KI-assistanse og -agenter opplever stadig flere utviklingsteam at kode blir produsert raskere og i større omfang enn det som kan håndteres med tradisjonelle prosesser for manuell kodegjennomgang og test. Kvalitetskontrollen glipper, og feilene dukker opp i produksjon i stedet for i utvikling.

Hvert verktøy i utviklingskjeden er i bunn og grunn en kompilator: det tar en spesifikasjon i ett språk og gjør den om til noe kjørbart i et annet.

• En kompilator tar Java eller C, som selv er en spesifikasjon av tiltenkt oppførsel, og produserer maskinkode.

• En modellbasert generator tar en formell modell og produserer testskript, testdata eller kode.

• En språkmodell (LLM) tar en prompt, et krav eller en brukerhistorie og produserer kode, tester eller data.

Tre notasjoner for det som går inn, én begrensning på det som kommer ut: ingenting i midten kan tilføre korrekthet som ikke fantes i spesifikasjonen.

Forskjellen ligger i hvordan de håndterer tvetydighet. En kompilator stopper og sier fra. En språkmodell fyller hullet med en plausibel gjetning som kompilerer, passerer kodegjennomgang og bærer med seg en antakelse ingen har tatt stilling til.

Det flytter den vanskelige tenkingen oppstrøms, til å vite presist hva du vil ha og si det presist nok til at en generator ikke kan misforstå.

Og det flytter kvalitetskontroll nedstrøms: når ingen på teamet kjenner hver linje, er den eneste måten å vite at systemet virker, å teste det utenfra, mot det det skulle gjøre.

Ja, og de uavhengige betyr mer enn før.

Når utviklere tester sin egen kode, verifiserer de sin egen forståelse av kravene og sine egne implementasjonsvalg. En KI-agent som tester koden den nettopp skrev, gjør det samme, bare raskere. Begge deler er nyttig. Ingen av delene er uavhengig. En uavhengig tester spør om kravene er forstått riktig, og om løsningen holder i samspill med andre systemer, under last, ved feilgrenser og i reell bruk.

Fageksperter og sluttbrukere er fortsatt avgjørende for valideringen, og bærekraftig automatisering hviler fortsatt på arkitekturvalg om hva som skal automatiseres, og på hvilket nivå. KI har ikke endret noen av delene. Den har gjort dem mer synlige. Det KI endrer, er ikke hvilken kompetanse som teller, men hvor fagfolk bruker tiden sin.

Hver av tjenestene våre er det samme faget sett gjennom dette resonnementet: spesifikasjonen på vei inn, uavhengig verifikasjon på vei ut, og automatisering som tåler endring imellom.

• Uavhengig verifikasjon av KI-utviklede systemer. Black-box-testing styrt av kravene i stedet for koden, sporbarhet fra krav til test, og modellbaserte teknikker som genererer dekning systematisk i stedet for å plukke stikkprøver for hånd.

• Spesifikasjoner som fungerer for både mennesker og maskiner. Strukturerte krav som både mennesker og maskiner kan lese, for eksempel i Gherkin, som alltid rommer hele den gjeldende intensjonen og gir deg akseptansekriterier en agent kan holdes til.

• Testautomatisering som tåler endring, agenter inkludert. Automatisering designet som arkitektur. Der KI-agenter kan skrive eller kjøre tester, bruker vi dem, og vi verifiserer det de rapporterer i stedet for å stole blindt på det.

• Test av systemer som inneholder KI. Å definere akseptabel oppførsel for et system som ikke oppfører seg likt to ganger, måle den over mange kjøringer og verifisere modellens resultater systematisk.

• Ytelse, robusthet og gjenoppretting. Under last og ved feilgrenser er der generert kode gjerne knekker først. Vi tester det for virksomheter som ikke har råd til å finne det ut i produksjon.

Vi bruker KI-assistenter og agenter i alle deler av testarbeidet vårt, og vi stiller samme krav til dem som vi stiller til kundenes kode.

• Testanalyse og testplanlegging. Assistenter lager utkast til testidéer, risikolister og planer. Testerne våre avgjør hva som blir med.

• Testutvikling. Assistenter og agenter skriver og vedlikeholder automatiserte tester som vi gjennomgår, og kjører dem der det går raskere enn å gjøre det selv.

• Våre egne verktøy. I Tomato gjør en KI-assistent krav og skjermbilder om til en modell, og en deterministisk generator gjør modellen om til testtilfeller og testdata. Språkmodellen er den tilgjengelige inngangen; generatoren gjør den uttømmende, repeterbare delen. Det lagdelte mønsteret er slik vi mener KI hører hjemme i en verktøykjede.

• Tradisjonelle prosesser også. Der organisasjonen din ikke er klar for KI i utviklingsløypa, jobber vi på tradisjonelt vis. Metoden er den samme; bare verktøyene er annerledes.

Vi delegerer arbeid til KI, ikke ansvar.

• Erfarne testere vurderer resultatet. Alt KI produserer, blir vurdert og verifisert av folk som kunne gjort jobben selv, før det når deg.

• Dine regler gjelder. Vi jobber innenfor de verktøyene og modellene du har godkjent, og innenfor dine krav til sikkerhet og personvern. Vi forteller deg hvor KI er brukt i det vi leverer.

• Vi holder grunnferdighetene ved like. Praktisk koding og testmetodikk er det som lar oss vurdere det KI produserer. Vi lar den ikke tenke for oss.

• Vi verifiserer det agentene rapporterer. En grønn hake fra en agent er en påstand, ikke et resultat, inntil noen har sjekket hva den faktisk kjørte.

Hos Testify er det denne kombinasjonen vi tilbyr. Vi har utspring fra Simula Research Laboratory, flere av oss har doktorgrad innen software testing, og vi underviser og holder workshops ved universitetene. Testerne våre har reell utviklerbakgrunn, og det er det som gjør at vi kan lese generert kode, vurdere hva en agent har gjort og bygge automatisering som varer. Tomato og Test Data Generator er der vi prøver ut ideene våre om KI i testing før vi tar dem med til deg.

Vi er et lite selskap med langvarige kunder i krevende offentlige og private virksomheter, og vi snur oss raskt når faget beveger seg. Vi holder også foredrag om testing i KI-basert utvikling, på konferanser og internt hos virksomheter.

Fortell oss hvor KI sitter i utviklingsprosessen deres, så forteller vi hvor vi ville begynt.