ProgramvareutviklingHafsteinn Runarsson · AI Konsulent29 Sept 2026 · 10 min

QA testing: guide til kvalitet i programvare og KI

QA testing er den systematiske kvalitetssikringen som følger et digitalt produkt fra krav og design til kode, lansering og drift. Målet er ikke bare å finne feil, men å forebygge dem, prioritere risiko og gi teamet et tydelig grunnlag for å avgjøre om produktet er klart for bruk.

En god QA-strategi kombinerer raske automatiserte tester med manuell utforskning. For KI-agenter og copiloter må den også håndtere varierende svar, sikkerhetsgrenser og overvåking etter lansering.

Hva er QA testing?

QA testing, eller quality assurance testing, er arbeidet med å bygge kvalitet inn i hele utviklingsprosessen. Det omfatter krav, akseptansekriterier, testdesign, testmiljøer, automatisering, feiloppfølging og lanseringskriterier.

Begrepene brukes ofte om hverandre, men det er nyttig å skille dem:

• Kvalitetssikring (QA): Prosessene som skal forebygge feil og gjøre kvalitet målbar.
• Software testing: Selve kontrollen av om programvaren oppfører seg som forventet.
• Kvalitetskontroll (QC): Vurderingen av om resultatet oppfyller avtalte krav og standarder.

Testing er dermed en del av QA, ikke hele QA-faget. Et team kan ha mange tester og fortsatt ha svak kvalitetssikring hvis kravene er uklare, testmiljøet avviker fra produksjon eller ingen har definert hva som skal stoppe en lansering.

Hvor i utviklingsløpet hører QA hjemme?

QA bør starte før første kodelinje og fortsette etter lansering. Jo tidligere teamet avklarer risiko og forventet oppførsel, desto mindre blir behovet for kostbar feilsøking sent i løpet.

Et praktisk QA-løp ser slik ut:

1. Avklar risiko og krav. Beskriv kritiske brukerreiser, dataflyt, integrasjoner og hva som kan gå galt.
2. Skriv testbare akseptansekriterier. En formulering som "skal være rask" kan ikke godkjennes før teamet har bestemt hva rask betyr i den aktuelle situasjonen.
3. Velg testnivå. Legg kontrollen så nær feilkilden som mulig: enhetstest for lokal logikk, integrasjonstest for samspill og ende-til-ende-test for hele brukerreisen.
4. Bygg testdata og miljø. Testene må bruke realistiske tilstander uten å eksponere personopplysninger eller produksjonshemmeligheter.
5. Kjør tester kontinuerlig. Raske kontroller bør kjøres ved hver endring. Tyngre regresjons-, sikkerhets- og ytelsestester kan kjøre før sammenslåing, lansering eller etter en fast plan.
6. Vurder lanseringskriteriene. Teamet må se på risiko, åpne feil og observasjoner, ikke bare antallet grønne tester.
7. Følg produktet i drift. Logger, alarmer, tilbakemeldinger og hendelser viser om antakelsene fra testmiljøet holdt.

QA er et lagarbeid. Produktansvarlig avklarer ønsket effekt, designeren dekker brukeropplevelse og tilgjengelighet, utvikleren tester implementasjonen, og QA-kompetansen hjelper teamet med risiko, testdesign og uavhengig utforskning.

Hvilke typer tester trenger et produktteam?

Et robust testoppsett har flere lag fordi én testtype ikke kan avdekke alle feil. Teamet bør velge kombinasjonen ut fra konsekvens og sannsynlighet, ikke kopiere en standardliste ukritisk.

Enhets-, komponent- og integrasjonstester

Enhetstester kontrollerer små deler av logikken raskt og presist. Komponenttester undersøker en avgrenset modul, mens integrasjonstester sjekker at databaser, API-er, køer og eksterne tjenester samarbeider som forventet.

Disse testene er ofte det beste stedet å dekke kanttilfeller. Når en integrasjon kan returnere tomme verdier, tidsavbrudd eller ugyldige data, bør testene vise hvordan systemet reagerer på hver tilstand.

API- og kontraktstester

API-tester kontrollerer input, output, autentisering, feilrespons og tilgangsregler uten å gå gjennom brukergrensesnittet. Kontraktstester fanger opp brudd mellom tjenester før en endring når produksjon.

Test både normal flyt og feiltilstander. En vellykket respons sier lite om hva som skjer ved dupliserte forespørsler, brutt nettverk eller manglende rettigheter.

Ende-til-ende- og regresjonstester

Ende-til-ende-tester følger en kritisk brukerreise gjennom hele systemet. De kan for eksempel kontrollere registrering, betaling eller innsending av et skjema. Regresjonstester bekrefter at eksisterende funksjoner fortsatt virker etter en endring.

Disse testene gir høy tillit, men de er tregere og mer sårbare for miljøproblemer. Bruk dem på de viktigste reisene, ikke på alle tenkelige detaljer.

Ytelses-, sikkerhets- og tilgjengelighetstester

Et produkt kan være funksjonelt riktig og likevel være ubrukelig eller farlig. Derfor må QA også dekke:

• Ytelse: responstid, kapasitet, ressursbruk og oppførsel under belastning.
• Sikkerhet: autentisering, autorisasjon, datavalidering og kjente angrepsflater. OWASP ASVS kan brukes som grunnlag for verifiserbare sikkerhetskrav.
• Tilgjengelighet: tastaturnavigasjon, fokus, kontrast, semantikk og hjelpemiddelteknologi. WCAG gir et felles rammeverk for tilgjengelig webinnhold.
• Kompatibilitet: relevante nettlesere, skjermstørrelser, operativsystemer og enheter.

Automatiske skanninger finner en del av problemene. De erstatter ikke manuell vurdering av brukerflyt, språk eller om produktet faktisk er forståelig.

Hva bør automatiseres, og hva bør testes manuelt?

Automatiser tester som skal gjentas ofte og gir et entydig resultat. Bruk mennesker når vurderingen krever nysgjerrighet, kontekst eller skjønn.

Gode kandidater for automatisering er:

• enhets- og integrasjonstester som kjøres ved hver kodeendring
• stabile, kritiske brukerreiser
• API-kontrakter og tilgangsregler
• regresjonstester med tydelig forventet resultat
• kontroller som skal kjøres på mange nettlesere eller datasett

Manuell testing er særlig nyttig for:

• utforskende testing av nye eller komplekse funksjoner
• brukervennlighet og språklig kvalitet
• visuelle avvik som er vanskelige å beskrive med regler
• sjeldne hendelser og ukjente feilmodeller
• vurdering av om produktet løser brukerens faktiske behov

Ikke automatiser en ustabil prosess bare fordi den tar tid. Først må teamet forstå forventet oppførsel, rydde i testdata og redusere unødvendige variasjoner. Ellers får dere en kostbar samling tester som feiler uten å fortelle om produktet er i fare.

En risikobasert testmatrise

Risikobasert testing prioriterer der en feil både er sannsynlig og har stor konsekvens. Det gjør testplanen forståelig for produkt, teknologi og virksomhet.

Vurder hver brukerreise eller systemdel etter disse spørsmålene:

• Hva kan gå galt?
• Hvem rammes, og hvor alvorlig er konsekvensen?
• Hvor ofte endres denne delen?
• Hvor vanskelig er feilen å oppdage i drift?
• Kan problemet reverseres uten tap av data eller tillit?
• Hvilken test gir tidligst og tydeligst signal?

Del deretter arbeidet inn i nivåer:

• Kritisk risiko: Test ved hver relevant endring. Krev tydelige lanseringskriterier, observability og en plan for tilbakeføring.
• Høy risiko: Dekk med automatiserte tester og målrettet manuell utforskning før lansering.
• Moderat risiko: Test sentrale scenarier og følg med på signaler i drift.
• Lav risiko: Bruk stikkprøver eller aksepter risikoen eksplisitt.

En betalingsflyt, sletting av data eller tildeling av tilgang krever normalt mer kontroll enn en kosmetisk tekstendring. Matrisen bør oppdateres når arkitekturen, brukergruppen eller konsekvensbildet endrer seg.

QA i CI/CD: et praktisk oppsett

En god CI/CD-pipeline gir rask tilbakemelding først og kjører dyrere kontroller senere. Da slipper utviklere å vente på hele testpakken for å oppdage en enkel feil.

En enkel rekkefølge er:

1. Kjør formattering, statisk analyse og enhetstester lokalt og ved hver kodeendring.
2. Kjør komponent-, API- og integrasjonstester før endringen kan slås sammen.
3. Kjør utvalgte ende-til-ende-tester mot et produksjonslikt miljø.
4. Kjør sikkerhets-, tilgjengelighets- og avhengighetskontroller der de gir mening.
5. Kjør en bredere regresjonspakke før lansering eller etter en fast plan.
6. Bruk gradvis utrulling, hendelseslogging og alarmer for å oppdage problemer som bare viser seg i drift.

Verktøyet er mindre viktig enn påliteligheten. Playwright, Cypress, Selenium og Appium dekker ulike behov for web- og mobiltesting. Velg ut fra produktets plattformer, teamets språk, integrasjon med eksisterende pipeline og hvor lett testene kan feilsøkes.

En test som feiler tilfeldig mister raskt troverdighet. Flaky tester bør få en eier, en frist og en synlig status. Å kjøre testen om igjen til den blir grønn skjuler problemet.

Hvilke QA-målinger er nyttige?

Gode QA-målinger viser risiko og læring, ikke bare aktivitet. Antall testtilfeller eller antall rapporterte feil sier lite alene.

Følg heller et lite sett signaler:

• Feil som når brukerne: Hvilke feil slapp gjennom, og hvilken konsekvens fikk de?
• Gjenåpnede feil: Hvor ofte viste en rettelse seg å være ufullstendig?
• Flaky tester: Hvor stor del av testfeilene kan ikke gjentas pålitelig?
• Tid til oppdagelse: Hvor raskt oppdager teamet en feil etter at den introduseres?
• Tid til trygg retting: Hvor raskt kan feilen rettes, verifiseres og leveres?
• Dekning av kritiske reiser: Har de viktigste risikoene faktisk en egnet kontroll?
• Hendelser etter lansering: Hvilke feilmodeller manglet i teststrategien?

Kodedekning kan være et hjelpesignal, men høy dekning beviser ikke at testene er gode. En test kan kjøre en kodelinje uten å kontrollere riktig resultat. Koble derfor målingene til risiko, brukerreise og læring fra reelle hendelser.

Når trenger teamet en egen QA-rolle?

En egen QA-rolle er nyttig når risikoen, produktbredden eller lanseringstakten gjør kvalitet vanskelig å koordinere som en delt bioppgave. Rollen bør styrke teamets samlede praksis, ikke bli en kontrollpost på slutten.

Tegn på at dedikert QA-kompetanse kan være nødvendig:

• de samme feilene kommer tilbake etter retting
• kritiske brukerreiser mangler eier eller teststrategi
• utviklere bruker mye tid på tilfeldig manuell regresjon
• testmiljø og testdata er ustabile
• produktet har komplekse integrasjoner, tilgangsregler eller regulatoriske krav
• teamet mangler uavhengig utforskning før lansering

Små team kan klare seg uten en egen stilling hvis ansvaret er tydelig og noen har tid og kompetanse til å drive teststrategien. "Alle har ansvar" fungerer bare når konkrete oppgaver, kriterier og eiere er synlige.

Hvordan tester man KI-agenter og copiloter?

KI-funksjoner krever både vanlig software testing og evalueringsmetoder for svar som kan variere. API-er, tilgangsstyring, brukergrensesnitt og integrasjoner testes fortsatt på vanlig måte. I tillegg må teamet vurdere kvaliteten på modellens oppførsel.

Start med et representativt evalueringssett:

1. Samle reelle oppgavetyper og forventninger uten å bruke sensitive produksjonsdata ukritisk.
2. Ta med normale saker, kanttilfeller, tvetydige instrukser og forsøk på misbruk.
3. Definer vurderingskriterier som korrekthet, relevans, kildebruk, sikker handling og riktig eskalering.
4. Bestem hvilke kriterier som kan sjekkes automatisk, og hvilke som trenger menneskelig vurdering.
5. Kjør det samme settet når modell, instruks, verktøy eller kunnskapsgrunnlag endres.
6. Logg feiltypen, ikke bare en samlet poengsum, slik at teamet kan se hva som ble bedre eller dårligere.

En agent som kan utføre handlinger trenger strengere kontroll enn en ren tekstassistent. Test rettigheter, godkjenning før irreversible handlinger, håndtering av tidsavbrudd, duplikater og hva som skjer når et verktøy returnerer uventede data.

Sikkerhetstesting bør også dekke instruksjoner som prøver å omgå reglene, hente data brukeren ikke har tilgang til eller få agenten til å utføre en uønsket handling. NIST AI Risk Management Framework er et nyttig utgangspunkt for å strukturere ansvar, måling og risikohåndtering rundt KI-systemer.

Produksjonsovervåking er en del av testen. Følg med på avviste handlinger, eskaleringer, kostnad, responstid og mønstre i brukerfeil. Nye feil bør inn i evalueringssettet, slik at den samme svakheten ikke kommer tilbake ubemerket.

Lanseringskriterier som teamet kan bruke

Et produkt er klart for lansering når den gjenværende risikoen er forstått og akseptert, ikke når alle tester er grønne. Kriteriene må avtales før presset om å lansere blir størst.

Bruk denne sjekklisten:

• Kritiske brukerreiser er testet i et produksjonslikt miljø.
• Åpne feil er vurdert etter konsekvens og har en navngitt eier.
• Sikkerhet, tilgang og behandling av data er kontrollert for den aktuelle endringen.
• Ytelse og kapasitet er vurdert mot forventet bruk.
• Tilgjengelighet er kontrollert både automatisk og manuelt der det er relevant.
• Logger, alarmer og dashbord kan oppdage de viktigste feilene.
• Teamet har en konkret plan for gradvis utrulling, tilbakeføring eller deaktivering.
• For KI-funksjoner er evalueringssett, sikkerhetsgrenser og menneskelig eskalering testet.

Dokumenter avvik. Et bevisst unntak med eier og oppfølging er bedre enn et skjult avvik som oppdages av brukerne.

Hva er forskjellen på QA testing og software testing?

QA testing omfatter prosessene som skal forebygge feil og sikre kvalitet gjennom hele utviklingsløpet. Software testing er de konkrete aktivitetene som kjører programvaren og sammenligner resultatet med en forventning.

Kan alt testes automatisk?

Nei. Automatisering passer best for repeterbare kontroller med tydelige resultater. Utforskende testing, brukervennlighet, språk og ukjente feil krever fortsatt menneskelig vurdering.

Når bør QA starte?

QA bør starte når problemet og kravene blir definert. Tidlig gjennomgang av risiko og akseptansekriterier kan avdekke uklarheter før de blir bygget inn i design og kode.

Er QA bare QA-testerens ansvar?

Nei. Hele produktteamet påvirker kvaliteten. En QA-rolle kan lede teststrategien og tilføre uavhengig vurdering, men produkt, design, utvikling og drift må eie kvalitet sammen.

Hvordan vet vi om testene er gode nok?

Testene er gode nok når de gir raskt og troverdig signal om de viktigste risikoene. Se på feil som når brukerne, flaky tester, tid til oppdagelse og dekning av kritiske brukerreiser. Ikke bruk antall tester som eneste mål.

Fra sjekkliste til kvalitetssystem

QA fungerer best som en løpende beslutningsprosess. Start med de mest kritiske brukerreisene, gjør risikoen synlig, automatiser det repeterbare og bruk hendelser fra drift til å forbedre testene.

Trenger dere en teststrategi for et full-stack-produkt, en KI-agent eller en copilot? Start en samtale.