AI og produktutviklingHafsteinn Runarsson · AI Konsulent01 Sept 2026 · 9 min

AI-testing: slik tester du både programvare og AI-systemer

AI-testing brukes om to forskjellige oppgaver: å bruke AI til å teste vanlig programvare, og å teste systemer som selv inneholder AI. Et godt testopplegg skiller mellom dem. Vanlig programvare trenger forutsigbare funksjons- og regresjonstester. AI-systemer trenger i tillegg evalueringssett, terskler for godkjent kvalitet, sikkerhetstester og overvåking i produksjon.

Kortversjonen:

• Start med risikoen i produktet, ikke med valg av verktøy.
• Behold deterministiske tester for kode, API-er og forretningsregler.
• Evaluer AI-svar mot tydelige kriterier og representative eksempler.
• La AI foreslå og prioritere tester, men krev menneskelig godkjenning når konsekvensen er høy.
• Mål feil som betyr noe for brukeren. En høy bestått-prosent er lite verdt hvis testene dekker feil ting.

Hva er AI-testing?

AI-testing er en samlebetegnelse for AI-støttet programvaretesting og kvalitetssikring av AI-systemer. Begrepene overlapper, men de har ulike mål og krever ulike metoder.

• AI i testarbeidet: AI hjelper med å skrive, kjøre, vedlikeholde eller prioritere tester for web, mobil, API-er og annen programvare.
• Testing av AI-systemer: Teamet undersøker om en modell, agent eller copilot gir gode, trygge og stabile resultater under relevante forhold.

Skillet avgjør hva en test faktisk skal måle. En betalingsregel kan testes med et eksakt forventet resultat. En AI-assistent kan formulere flere gode svar på samme spørsmål. Da må testen vurdere kvalitet innenfor avtalte rammer i stedet for å sammenligne én tekststreng med en annen.

NISTs AI Risk Management Framework legger evaluering inn som en del av arbeidet med pålitelighet gjennom hele livsløpet. Det er en nyttig grunntanke: AI-testing er ikke en kontroll som legges til rett før lansering.

Hva kan AI gjøre i vanlig programvaretesting?

AI kan redusere repetitivt testarbeid, men bør brukes på avgrensede oppgaver med synlig resultat. Verktøy i markedet dekker blant annet testgenerering, selvreparerende lokatorer, visuell regresjon, prioritering og feilanalyse. TestGrid beskriver disse brukstilfellene, mens den åpne oversikten Awesome AI Testing viser hvor mange ulike verktøykategorier som finnes.

Foreslå testtilfeller

En modell kan gjøre krav, brukerhistorier og tidligere feil om til forslag til testtilfeller. Det er særlig nyttig for å finne manglende grenseverdier og negative scenarioer.

Forslagene må fortsatt gjennomgås. Modellen kjenner ikke automatisk hvilke hendelser som gir økonomisk, juridisk eller operasjonell risiko i akkurat ditt produkt.

Skrive testkode

AI kan lage et førsteutkast til enhetstester, API-tester eller nettlesertester. Gevinsten kommer først når utkastet følger teamets rammeverk, navngivning og testdata-praksis. Testen skal også feile av riktig grunn. En test som alltid består, er bare ekstra kode.

Vedlikeholde grensesnitttester

Enkelte verktøy kan foreslå nye lokatorer når et grensesnitt endres. Det kan redusere vedlikeholdet av skjøre ende-til-ende-tester. Selvheling bør logges og godkjennes. Ellers kan verktøyet tilpasse testen til en faktisk feil og skjule regresjonen.

Prioritere regresjonstester

Når hele testpakken er treg, kan AI bruke kodeendringer, historiske feil og berørte komponenter til å foreslå hvilke tester som bør kjøre først. Den raske pakken gir tidlig signal. Den erstatter ikke en bredere kjøring før en kritisk lansering.

Gruppere og forklare feil

AI kan samle lignende feil og foreslå en sannsynlig rotårsak. Det kan gjøre store testkjøringer enklere å lese, særlig når mange tester feiler på grunn av samme tjeneste eller miljøproblem. Forslaget er et startpunkt for feilsøking, ikke fasiten.

Hvordan tester du et AI-system?

Et AI-system bør testes som et helt produkt. Teamet må kontrollere input, modellatferd, verktøykall, forretningsregler, grensesnitt og overvåking som én sammenhengende kjede.

Definer hva et godt svar er

Kvalitet må beskrives før den kan måles. Lag en kort vurderingsrubrikk med kriterier som passer oppgaven:

• Er svaret relevant for brukerens mål?
• Er påstander støttet av tilgjengelig kontekst?
• Følger svaret formatet og reglene produktet krever?
• Avstår systemet når det mangler grunnlag eller tillatelse?
• Er tonen og språket riktig for målgruppen?

Noen kriterier kan kontrolleres med kode. Andre trenger fagpersoner eller en modellbasert evaluator. Bruk flere signaler når vurderingen er skjønnsmessig.

Bygg et representativt evalueringssett

Evalueringssettet bør speile reelle oppgaver og feilbilder. Ta med normale forespørsler, sjeldne men viktige tilfeller, uklare instrukser, manglende data og bevisste forsøk på misbruk.

Hver test trenger:

• et konkret input
• relevant kontekst og tillatelser
• forventet atferd eller en vurderingsrubrikk
• alvorlighetsgrad hvis testen feiler
• eier for oppfølging

Ikke bruk produksjonsdata ukritisk. Fjern eller masker personopplysninger og andre sensitive felt før eksempler blir del av et testsett.

Kombiner faste kontroller og kvalitative evalueringer

Faste kontroller passer for forhold som kan avgjøres entydig:

• gyldig JSON eller annet avtalt format
• riktig verktøy og tillatte parametere
• ingen kall uten nødvendig tilgang
• korrekt kilde-ID eller påkrevd felt
• responstid og kostnad innenfor avtalte grenser

Kvalitative evalueringer passer bedre for relevans, nytte, tone og faglig kvalitet. De bør bruke en tydelig rubrikk og kalibreres mot menneskelige vurderinger. En modell som bedømmer en annen modell, kan være effektiv, men er ikke en uavhengig sannhetskilde.

Test angrep og uventet input

AI-funksjoner må tåle mer enn høflige demonstrasjoner. Test blant annet instruksjoner som prøver å overstyre systemregler, forgiftet innhold fra dokumenter, uautoriserte verktøykall, lekkasje av skjult kontekst og svært lange eller tvetydige samtaler.

For en agent må du også kontrollere konsekvensen av handlinger. Lesing, forslag, skriving og irreversible operasjoner bør ha ulike tillatelser og godkjenningsgrenser.

Kjør regresjon ved hver relevant endring

Modellversjon, systemprompt, søkeindeks, verktøy, temperatur og produktkode kan alle endre resultatet. Lagre derfor konfigurasjonen sammen med testresultatet. Kjør det samme evalueringssettet før og etter en endring, og undersøk både forbedringer og nye feil.

Et samlet gjennomsnitt kan skjule en alvorlig regresjon. Bryt resultatene ned etter oppgavetype, språk, risikonivå og brukergruppe der det er relevant.

Overvåk produksjon

Et evalueringssett er alltid ufullstendig. I produksjon trenger teamet signaler for avvisninger, mislykkede verktøykall, menneskelige overstyringer, klager og andre hendelser som viser at systemet ikke fungerer som planlagt.

Nye feil bør bli nye testtilfeller. Slik vokser evalueringssettet med produktet i stedet for å bli en statisk sjekkliste.

En praktisk prosess for AI-testing

En liten, sporbar prosess gir mer læring enn en stor verktøyanskaffelse. Følg denne rekkefølgen:

1. Velg én viktig arbeidsflyt. Start med en oppgave som har tydelig bruker- og forretningsverdi.
2. Kartlegg feil og konsekvens. Beskriv hva som kan gå galt, hvem som rammes og hvor alvorlig det er.
3. Skriv godkjenningskriterier. Gjør forventet atferd målbar før teamet velger evaluator.
4. Bygg et lite evalueringssett. Dekk normal bruk, kanttilfeller og misbruk.
5. Lag en referansemåling. Kjør dagens løsning og lagre konfigurasjon, resultat og kjente svakheter.
6. Koble testene til leveranseløpet. Raske, kritiske kontroller kan stoppe en endring. Bredere evalueringer kan kjøre planlagt.
7. Gjennomgå feil og oppdater settet. Fjern ubrukelige tester, legg til nye feilbilder og behold historikken.

Prosessen fungerer både når AI hjelper med tradisjonell testing og når AI-systemet selv er testobjektet.

Slik velger du AI-testverktøy

Det riktige verktøyet løser en navngitt flaskehals i den eksisterende prosessen. En demonstrasjon på leverandørens eksempelapp sier lite om hvordan verktøyet oppfører seg mot din kode, dine data og din pipeline.

Vurder disse punktene i en avgrenset pilot:

• Eksport og eierskap: Kan testene leses og kjøres utenfor leverandørens grensesnitt?
• Integrasjon: Fungerer verktøyet med dagens repo, CI/CD, nettlesere, enheter og testmiljøer?
• Sporbarhet: Kan teamet se hvorfor en test ble generert, endret, hoppet over eller feilet?
• Kontroll: Kan automatiske endringer kreve godkjenning?
• Databehandling: Hvilken kode, testdata og produksjonsinformasjon sendes til tjenesten?
• Stabilitet: Gjentar verktøyet resultatet godt nok til at feil kan undersøkes?
• Kostnad: Hvordan endres kostnaden med antall kjøringer, parallellitet og datamengde?

Produktet Momentic er et eksempel på en plattform som beskriver tester i vanlig språk og kjører dem i nettlesere og på enheter. Andre verktøy legger AI oppå etablerte rammeverk. Test begge tilnærmingene mot samme arbeidsflyt. Da sammenligner du faktisk nytte, ikke markedsføring.

Hva bør fortsatt være menneskestyrt?

Mennesker bør eie beslutninger der kontekst, konsekvens eller ansvar ikke kan reduseres til en enkel regel. Det gjelder særlig:

• valg av akseptabel risiko
• prioritering av kritiske brukerreiser
• vurdering av uklare eller omstridte svar
• godkjenning av nye verktøytillatelser
• håndtering av personopplysninger og sensitiv informasjon
• beslutningen om et produkt er klart for lansering

AI kan gi bedre testforslag og raskere sortering. Ansvaret for hva som er godt nok, ligger fortsatt hos teamet som leverer systemet.

Vanlige feil i AI-testing

De fleste svake opplegg feiler på styring og måling, ikke på mangel på verktøy.

• Teamet tester bare gode eksempler. Resultatet blir en demonstrasjon, ikke en kvalitetskontroll.
• Bestått-prosenten mangler risikovekt. En kosmetisk feil og en uautorisert handling teller likt.
• Testsettet lekker inn i utviklingen. Løsningen optimaliseres for kjente spørsmål og ser bedre ut enn den generaliserer.
• En evaluator får siste ord alene. Systematiske feil i evaluatoren blir usynlige.
• Selvheling skjer uten logg. Testen endres samtidig som produktet, og en reell regresjon kan forsvinne.
• Ingen lagrer konfigurasjonen. Teamet ser at resultatet endret seg, men kan ikke forklare hvorfor.
• Produksjonsfeil blir ikke regresjonstester. Den samme feilen kan komme tilbake.

Hvordan måler du om AI-testing virker?

Mål kvaliteten på beslutningene og tiden fra feil til forståelse. Velg noen få indikatorer som passer arbeidsflyten:

• andel kritiske scenarioer med testdekning
• antall alvorlige feil funnet før produksjon
• falske positiver og falske negativer
• tid brukt på å sortere og forklare feil
• andel automatiske testendringer som må reverseres
• kvalitet per oppgavetype, språk eller risikonivå
• responstid og kostnad per godkjent resultat

Sammenlign mot en referanse før piloten. Hvis verktøyet produserer flere tester, men også mer støy og vedlikehold, har testmengden økt uten at beslutningsgrunnlaget ble bedre.

Kan AI erstatte testere?

Nei. AI kan utføre deler av testarbeidet, men kan ikke alene definere forretningsrisiko, akseptabel kvalitet eller ansvar ved feil. Testere og fagpersoner trengs for å velge scenarioer, vurdere tvetydige resultater og avgjøre hva som er trygt å lansere.

Er AI-testing det samme som testautomatisering?

Nei. Testautomatisering kjører forhåndsdefinerte kontroller. AI-testing kan også foreslå tester, prioritere kjøringer, tilpasse enkelte testelementer og evaluere resultater som ikke har ett eksakt fasitsvar. Tradisjonell automasjon er fortsatt grunnmuren for deterministisk atferd.

Hvordan tester man svar fra en språkmodell?

Bruk et versjonert evalueringssett med representative spørsmål, relevant kontekst og en tydelig rubrikk. Kombiner maskinelle kontroller av format, kilder og tillatelser med faglig vurdering av relevans og korrekthet. Kjør settet på nytt ved endringer i modell, prompt, data eller verktøy.

Når bør en AI-test stoppe en lansering?

En test bør stoppe lanseringen når den avdekker en feil over teamets avtalte risikogrense. Det kan være brudd på tilgangskontroll, farlige handlinger, tap av data eller en tydelig kvalitetsregresjon i en kritisk arbeidsflyt. Grensen må defineres før testen kjøres.

Kom i gang med en avgrenset pilot

Velg én arbeidsflyt, ett sett med kvalitetskriterier og en kort liste over kjente feilbilder. Daia kan hjelpe med å utforme testopplegget som del av en AI-agent, copilot eller full-stack-produkt. Start en samtale om arbeidsflyten du vil kvalitetssikre.