Testing av IT-systemer – fra tradisjonell kvalitetssikring til kunstig intelligens

1. Hva er testing, og hvorfor er det viktig?

Testing handler om å undersøke og evaluere om et IT-system oppfyller definerte krav, fungerer som forventet og har et akseptabelt risikonivå.

Et sentralt skille går mellom verifikasjon og validering:

• Verifikasjon: Er løsningen utviklet i samsvar med spesifikasjonene og kravene?
• Validering: Dekker løsningen det faktiske behovet den er ment å løse?

Et system kan oppfylle alle tekniske krav uten å være egnet til formålet. Eksempelvis kan et nytt saksbehandlingssystem fungere nøyaktig slik kravspesifikasjonen beskriver, men likevel ha så kompliserte arbeidsprosesser at saksbehandlerne bruker vesentlig lengre tid enn tidligere.

Testing skal derfor ikke bare avdekke tekniske feil. Den skal også bidra til å dokumentere at løsningen har tilstrekkelig kvalitet til å tas i bruk.

Testing er ikke det samme som feilretting

Det er viktig å skille mellom tre aktiviteter:

1. Testing: Identifisere feil, avvik og risiko.
2. Feilretting: Analysere og korrigere identifiserte feil.
3. Retesting: Kontrollere at feilene er rettet, og at endringene ikke har introdusert nye problemer.

Testing kan påvise feil, men kan normalt ikke bevise at et system er fullstendig feilfritt. Dette er et grunnleggende prinsipp innen programvaretesting.

2. Black-box-testing – testing uten kjennskap til den interne løsningen

Black-box-testing, eller svartbokstesting, er en metode hvor testeren undersøker systemets funksjonalitet uten å ta utgangspunkt i hvordan systemet er programmert eller bygget opp internt.

Testeren kjenner kravene til systemet og kontrollerer om resultatene samsvarer med forventningene.

Eksempel: Et offentlig saksbehandlingssystem

Et system skal beregne en søknadsfrist basert på datoen en søknad mottas.

Testeren registrerer ulike datoer og kontrollerer at systemet beregner riktig frist.

Testeren trenger ikke kjenne algoritmen som benyttes. Det avgjørende er om systemet gir riktig resultat.

Vanlige teknikker

Ekvivalensklasseinndeling

Inndata deles inn i grupper som forventes å behandles likt. I stedet for å teste alle mulige verdier velges representative verdier fra hver gruppe.

Grenseverdianalyse

Mange feil oppstår ved grensene mellom tillatte og ikke-tillatte verdier.

Hvis et system tillater maksimalt 100 brukere, kan det være relevant å teste 99, 100 og 101 brukere.

Beslutningstabeller

Brukes når resultatet avhenger av flere betingelser, eksempelvis kombinasjoner av brukerrettigheter, beløpsgrenser og godkjenningsnivåer.

Tilstandsovergangstesting

Undersøker hvordan systemet oppfører seg når det beveger seg mellom ulike tilstander, eksempelvis når en søknad går fra «Mottatt» til «Under behandling», «Godkjent» eller «Avslått».

Fordeler og begrensninger

Black-box-testing har flere fordeler:

• Testeren trenger ikke ha programmeringskompetanse.
• Testene kan utformes direkte fra funksjonelle krav.
• Metoden egner seg godt til akseptansetesting.
• Testingen kan utføres av personer som representerer brukerne eller oppdragsgiveren.

En begrensning er at metoden ikke nødvendigvis avdekker feil i kode eller interne prosesser som ikke påvirker de testede resultatene.

3. White-box-testing – testing med innsikt i systemets oppbygning

White-box-testing, eller hvitbokstesting, tar utgangspunkt i systemets interne struktur.

Testeren har kjennskap til kildekode, programlogikk, arkitektur eller interne prosesser og bruker denne informasjonen til å utforme testene.

Målet er blant annet å undersøke om ulike deler av programkoden og de logiske beslutningsveiene fungerer korrekt.

Eksempel: Beregning av merverdiavgift

Anta at et system inneholder en funksjon som beregner merverdiavgift.

Funksjonen har forskjellige behandlingsregler avhengig av hvilken avgiftskategori som benyttes.

Ved white-box-testing kan testeren undersøke om alle relevante beslutningsgrener i koden blir utført og testet.

Dette kan avdekke feil som ikke nødvendigvis ville blitt oppdaget gjennom et begrenset utvalg funksjonelle tester.

Vanlige teknikker

Statement coverage (setningsdekning)

Måler hvor stor andel av de kjørbare programsetningene som blir utført under testing.

Branch coverage (grendekning)

Måler om de ulike utfallene av beslutninger i programkoden blir testet.

Path testing (stidekning)

Undersøker ulike gjennomføringsveier i programmet. Fullstendig stidekning kan være upraktisk eller umulig i komplekse systemer.

Statisk kodeanalyse

Automatiserte verktøy analyserer kildekoden uten å kjøre programmet. Dette er ikke dynamisk white-box-testing, men en beslektet kvalitetssikringsaktivitet som kan avdekke blant annet usikker programmering, potensielle feil og brudd på kodestandarder.

Fordeler og begrensninger

White-box-testing gir mulighet til å undersøke implementasjonen mer systematisk og måle strukturell testdekning.

Metoden har imidlertid også begrensninger.

Selv om alle programsetninger er utført under testing, betyr ikke det at systemet fungerer korrekt. Koden kan eksempelvis implementere en forretningsregel feil eller mangle en funksjon som aldri ble utviklet.

Derfor bør white-box-testing kombineres med black-box-testing.

4. Grey-box-testing – en kombinasjon av metodene

Mellom black-box og white-box finnes grey-box-testing, eller gråbokstesting.

Her har testeren delvis kjennskap til systemets interne oppbygning, men tester i hovedsak systemets eksterne funksjonalitet.

Dette er særlig relevant ved integrasjonstesting.

Eksempelvis kan en tester kjenne til hvordan et saksbehandlingssystem kommuniserer med et eksternt register gjennom et API, uten å ha tilgang til kildekoden til noen av systemene.

Testeren kan da undersøke både funksjonaliteten og hvordan systemene utveksler informasjon.

Gråbokstesting er ofte nyttig i offentlige IT-prosjekter, hvor oppdragsgiver har innsikt i arkitektur og grensesnitt, men ikke nødvendigvis tilgang til leverandørens kildekode.

5. Testnivåer – hva skal testes, og når?

Black-box og white-box beskriver hvordan tester utformes. Testnivåer beskriver derimot hvilken del av løsningen som testes.

Disse dimensjonene må ikke forveksles.

I tillegg gjennomføres ulike testtyper på flere av nivåene.

Funksjonell testing

Kontrollerer at løsningen utfører de funksjonene som er spesifisert.

Ytelsestesting

Undersøker blant annet responstid, kapasitet og ressursforbruk.

Dette omfatter eksempelvis belastningstesting, stresstesting og testing av systemets evne til å håndtere mange samtidige brukere.

Sikkerhetstesting

Undersøker sårbarheter, tilgangskontroll, autentisering, autorisasjon og andre sikkerhetsegenskaper.

Regresjonstesting

Kontrollerer at endringer i systemet ikke har ødelagt eksisterende funksjonalitet.

Regresjonstesting er særlig egnet for automatisering fordi de samme testene ofte må gjennomføres gjentatte ganger.

Brukervennlighetstesting

Undersøker om løsningen er forståelig og effektiv for brukerne, og om den støtter de faktiske arbeidsprosessene.

Gjenopprettings- og kontinuitetstesting

Kontrollerer hvordan løsningen håndterer feil, driftsavbrudd og gjenoppretting etter hendelser.

Dette er spesielt viktig for samfunnskritiske systemer.

6. Testing av programvare og maskinvare – ulike utfordringer

Selv om mange testprinsipper er felles, er det vesentlige forskjeller mellom testing av programvare og maskinvare.

Programvaretesting

Programvaretesting handler i hovedsak om funksjonalitet, logikk, databehandling, integrasjoner og systemets oppførsel under ulike forhold.

Eksempler inkluderer:

• Kontroll av beregninger og forretningsregler.
• Testing av API-er og integrasjoner.
• Testing av brukergrensesnitt.
• Testing av tilgangsstyring.
• Belastnings- og ytelsestesting.
• Testing av sikkerhetsmekanismer.
• Regresjonstesting etter programvareoppdateringer.

Programvare kan normalt kopieres og kjøres i flere testmiljøer. Dette gjør det mulig å automatisere store deler av testarbeidet.

Maskinvaretesting

Maskinvaretesting har andre utfordringer fordi fysiske komponenter påvirkes av blant annet temperatur, strømforsyning, mekanisk belastning og slitasje.

Aktuelle tester kan omfatte:

Funksjonstesting: Kontroll av at komponentene fungerer i samsvar med spesifikasjonene.

Ytelsestesting: Måling av kapasitet, gjennomstrømming, responstid og ressursforbruk.

Belastningstesting: Kontroll av hvordan utstyret fungerer ved høy belastning over tid.

Miljøtesting: Undersøkelse av hvordan temperatur, fuktighet, vibrasjoner og andre miljøforhold påvirker utstyret.

Pålitelighets- og utholdenhetstesting: Undersøkelse av feilrater og funksjon over lengre tidsperioder.

Kompatibilitetstesting: Kontroll av samspillet mellom maskinvare, operativsystemer, drivere og tilkoblet utstyr.

Testing av kombinerte løsninger

Moderne IT-systemer består sjelden utelukkende av programvare eller maskinvare.

Et datasenter kan eksempelvis omfatte servere, lagringssystemer, nettverksutstyr, virtualiseringsprogramvare, operativsystemer og applikasjoner.

Hver komponent kan fungere korrekt isolert sett, samtidig som den samlede løsningen har alvorlige feil.

Derfor er system- og integrasjonstesting avgjørende.

Et eksempel er et lagringssystem som fungerer tilfredsstillende ved normal belastning, men som gir uakseptable responstider når flere virtuelle servere samtidig utfører store databehandlingsoperasjoner.

Slike feil oppdages ikke nødvendigvis gjennom isolert testing av komponentene.

7. Hvordan etablere en testorganisasjon?

En effektiv testorganisasjon krever tydelig ansvarsfordeling, kompetanse, prosesser og beslutningsmyndighet.

Det er ikke tilstrekkelig å opprette et testteam dersom det er uklart hvem som bestemmer hva som skal testes, hvilke feil som kan aksepteres, og når løsningen er klar for produksjon.

Teststrategi

Teststrategien bør etableres tidlig i prosjektet.

Den bør blant annet beskrive:

1. Hva som skal testes.
2. Hvilke testnivåer og testmetoder som skal benyttes.
3. Hvordan testene skal prioriteres ut fra risiko.
4. Hvilke testmiljøer som skal etableres.
5. Hvem som har ansvar for de ulike testaktivitetene.
6. Hvordan feil skal registreres, prioriteres og håndteres.
7. Hvilke kriterier som må være oppfylt før løsningen kan godkjennes.

Teststrategien bør bygge på systemets kritikalitet og konsekvensene av feil.

Et system som behandler interne reiseregninger, vil normalt ha andre krav til testing enn et system som styrer kritisk infrastruktur.

Roller og ansvar

En større testorganisasjon kan organiseres med følgende roller:

Rollene behøver ikke være separate stillinger. I mindre prosjekter kan én person ivareta flere funksjoner.

Det sentrale er at ansvaret er definert.

Uavhengighet i testarbeidet

Det er en fordel at deler av testarbeidet gjennomføres av andre enn dem som har utviklet løsningen.

Utviklere har inngående kjennskap til systemet og er ofte best egnet til enhetstesting og teknisk integrasjonstesting.

Samtidig kan utviklere ha en tendens til å teste løsningen ut fra hvordan den er ment å fungere, fremfor hvordan en faktisk bruker vil benytte den.

En viss uavhengighet bidrar til å redusere denne risikoen.

Uavhengighet betyr imidlertid ikke at testerne skal arbeide isolert fra utviklingsmiljøet. Tett samarbeid er nødvendig for å avdekke og rette feil effektivt.

8. Testmiljøer og testdata

En testorganisasjon er avhengig av egnede testmiljøer.

Det kan være nødvendig å etablere separate miljøer for utvikling, integrasjonstesting, systemtesting og akseptansetesting.

Testmiljøene bør i tilstrekkelig grad representere produksjonsmiljøet.

Dette gjelder særlig:

• Programvareversjoner og konfigurasjon.
• Nettverk og sikkerhetsmekanismer.
• Databaser og datamengder.
• Integrasjoner mot andre systemer.
• Maskinvarekapasitet og infrastruktur.

Et system som fungerer tilfredsstillende i et testmiljø med 100 registreringer, vil ikke nødvendigvis fungere like godt i produksjon med flere millioner registreringer.

Bruk av produksjonsdata

Produksjonsdata kan være verdifulle ved testing fordi de representerer reelle datamønstre og kompleksitet.

Samtidig kan bruk av slike data medføre risiko knyttet til personvern, informasjonssikkerhet og konfidensialitet.

Bruk av produksjonsdata må derfor ha et gyldig behandlingsgrunnlag og være underlagt nødvendige sikkerhetstiltak.

Der det er mulig, bør syntetiske eller tilstrekkelig anonymiserte testdata benyttes.

9. Automatisert testing

Tradisjonelt har mye testing vært manuelt arbeid.

Testere har gjennomført forhåndsdefinerte testtilfeller, registrert resultater og dokumentert eventuelle avvik.

Automatisering gjør det mulig å gjennomføre mange av disse aktivitetene uten manuell involvering.

Automatiserte tester kan eksempelvis kjøres hver gang det gjøres en endring i programkoden.

Dette er en sentral del av moderne utviklingsmetodikk, særlig kontinuerlig integrasjon og kontinuerlig leveranse (CI/CD).

Hva bør automatiseres?

Automatisering er spesielt nyttig når tester:

• Gjennomføres ofte.
• Har tydelige og etterprøvbare forventede resultater.
• Er tidkrevende å utføre manuelt.
• Må gjennomføres med mange ulike datasett.
• Skal kontrollere at eksisterende funksjonalitet fortsatt virker.

Ikke all testing bør automatiseres.

Utforskende testing, brukervennlighetstesting og vurdering av komplekse faglige problemstillinger kan fortsatt kreve betydelig menneskelig involvering.

10. Hvordan kunstig intelligens endrer testing

Kunstig intelligens er i ferd med å endre både hvordan tester utvikles, hvordan de gjennomføres, og hvordan resultatene analyseres.

Tradisjonell testautomatisering forutsetter i stor grad at mennesker på forhånd definerer testtilfeller og forventede resultater.

KI-baserte verktøy kan i større grad bistå med å identifisere hva som bør testes, generere testtilfeller og analysere resultatene.

Det er imidlertid viktig å skille mellom bruk av KI til testing og testing av systemer som selv benytter KI.

Dette er to forskjellige problemstillinger.

10.1 KI-genererte testtilfeller

Generativ KI kan analysere kravspesifikasjoner, brukerhistorier og programkode for å foreslå relevante tester.

Eksempelvis kan en KI-assistent analysere en kravspesifikasjon for et saksbehandlingssystem og foreslå:

• Positive testtilfeller hvor systemet skal akseptere inndata.
• Negative testtilfeller hvor systemet skal avvise inndata.
• Grenseverditester.
• Tester av ulike brukerroller.
• Tester av feil- og unntakssituasjoner.

Dette kan redusere tiden som brukes på testdesign.

Samtidig kan KI generere tester basert på feilaktige antakelser eller overse viktige krav. Testtilfellene må derfor kvalitetssikres.

10.2 KI-generering av automatiserte tester

KI kan også benyttes til å skrive testkode.

En utvikler kan eksempelvis be en KI-assistent om å generere enhetstester for en Python-funksjon.

Assistenten kan foreslå tester som dekker normale situasjoner, ugyldige inndata og ulike beslutningsgrener.

Dette kan effektivisere utviklingsarbeidet betydelig.

En utfordring er at KI kan gjenta feilaktige forutsetninger fra kildekoden.

Hvis programkoden inneholder en feil i en beregningsregel, kan KI generere tester som bekrefter den samme feilaktige beregningen.

Testene kan dermed bestås uten at systemet oppfyller det opprinnelige behovet.

10.3 KI-basert analyse av testresultater

Store IT-systemer kan generere omfattende mengder logger, feilmeldinger og testresultater.

KI kan brukes til å analysere denne informasjonen og identifisere mønstre som ellers ville vært vanskelige å oppdage.

Eksempelvis kan KI bidra til å:

• Gruppere feilmeldinger som sannsynligvis har samme årsak.
• Identifisere unormale endringer i ytelse.
• Foreslå hvilke komponenter som bør undersøkes nærmere.
• Prioritere feil basert på historiske data og mulig konsekvens.
• Oppsummere testresultater for prosjektledelsen.

KI kan dermed fungere som beslutningsstøtte for testleder og tekniske spesialister.

10.4 Selvtilpassende testautomatisering

En utfordring ved tradisjonell testautomatisering er at testskript kan slutte å fungere når brukergrensesnitt eller andre deler av systemet endres.

En knapp kan eksempelvis få et nytt navn eller flyttes til en annen del av skjermbildet.

KI-baserte testverktøy kan i enkelte tilfeller identifisere slike endringer og foreslå eller gjennomføre tilpasninger av testskriptene.

Dette omtales gjerne som self-healing test automation.

Teknologien kan redusere vedlikeholdsbehovet, men innebærer også risiko.

Hvis et testverktøy automatisk tilpasser seg en endring som egentlig representerer en feil, kan testen fortsette å bestås selv om systemet ikke lenger oppfører seg som forutsatt.

Slike tilpasninger bør derfor være sporbare og underlagt kontroll.

11. Testing av kunstig intelligens – en ny utfordring

Når et IT-system selv benytter KI, oppstår det utfordringer som ikke alltid lar seg håndtere gjennom tradisjonelle testmetoder.

Tradisjonell programvare er i stor grad deterministisk: Gitt samme inndata og samme systemtilstand vil programmet normalt gi samme resultat.

Generative KI-modeller kan derimot gi ulike svar på samme spørsmål.

Dette gjør det vanskeligere å definere entydige forventede testresultater.

Hvordan tester man et system uten ett riktig svar?

Anta at en offentlig virksomhet benytter en KI-assistent til å oppsummere saksdokumenter.

To forskjellige oppsummeringer kan begge være korrekte, selv om formuleringene er ulike.

Testing kan derfor ikke bare handle om hvorvidt resultatet er identisk med et forhåndsdefinert svar.

Det kan være nødvendig å evaluere resultatene etter kriterier som:

Faktisk korrekthet: Inneholder svaret uriktige opplysninger?

Fullstendighet: Er vesentlig informasjon utelatt?

Relevans: Besvarer systemet den faktiske problemstillingen?

Etterprøvbarhet: Kan opplysningene spores til pålitelige kilder?

Robusthet: Hvordan påvirkes resultatet av små endringer i spørsmålsformuleringen?

Sikkerhet: Kan systemet manipuleres til å avsløre informasjon eller utføre uautoriserte handlinger?

Likebehandling: Gir systemet systematisk forskjellige resultater i sammenlignbare situasjoner uten saklig grunn?

Testing av KI-agenter

Utfordringene blir større når KI-systemer ikke bare produserer tekst, men også kan utføre handlinger.

En KI-agent kan eksempelvis ha tilgang til å lese dokumenter, opprette saker, oppdatere databaser eller sende meldinger.

Da må testingen omfatte mer enn kvaliteten på svarene.

Det må også undersøkes om agenten:

• Handler innenfor sine fullmakter.
• Benytter riktige datakilder.
• Håndterer feil og usikkerhet forsvarlig.
• Unngår utilsiktede endringer.
• Kan stoppes eller korrigeres.
• Logger handlingene på en etterprøvbar måte.

For systemer som kan gjennomføre handlinger med rettslige, økonomiske eller operative konsekvenser, kan det være nødvendig med menneskelig godkjenning før handlingene utføres.

KI som tester KI

KI kan også brukes til å evaluere andre KI-systemer.

En modell kan eksempelvis vurdere svar fra en annen modell opp mot definerte kvalitetskriterier.

Dette omtales ofte som LLM-as-a-judge.

Metoden kan effektivisere evalueringen av store mengder svar, men introduserer en ny utfordring: Evalueringsmodellen kan selv gjøre feil.

Derfor bør slike evalueringer kontrolleres mot menneskelig vurderte referansedata og suppleres med andre testmetoder.

12. Testing i offentlige IT-anskaffelser

For offentlige virksomheter er testing ikke bare et teknisk spørsmål. Det er også et spørsmål om kontraktsoppfølging, risikostyring og dokumentasjon av leveranser.

Dette gjelder særlig ved anskaffelse av komplekse IT-systemer og tjenester.

Kravene må kunne testes

En vanlig utfordring i IT-anskaffelser er at kravspesifikasjonen inneholder formuleringer som er vanskelige å verifisere.

Eksempelvis:

«Systemet skal ha høy ytelse.»

Hva betyr høy ytelse?

Et mer etterprøvbart krav kan være:

«Systemet skal håndtere minst 1 000 samtidige brukere, og 95 prosent av de definerte søkeoperasjonene skal ha en responstid på maksimalt to sekunder under angitt belastningsprofil.»

Et slikt krav gjør det mulig å etablere konkrete testtilfeller og akseptansekriterier.

Det bør også defineres hvordan målingen skal gjennomføres, hvilke forutsetninger som gjelder, og hvordan resultatene skal dokumenteres.

Testansvar må reguleres i kontrakten

Ved større IT-anskaffelser bør kontrakten tydelig regulere:

• Hvilke tester leverandøren skal gjennomføre.
• Hvilke tester kunden skal gjennomføre.
• Hvem som har ansvar for testmiljøer og testdata.
• Hvilken dokumentasjon leverandøren skal fremlegge.
• Hvordan avvik skal klassifiseres og håndteres.
• Hvilke kriterier som gjelder for godkjenning.
• Hvilke konsekvenser det får dersom testene ikke bestås.

Det bør også avklares hvordan testing av integrasjoner mot tredjepartssystemer skal håndteres.

En leverandør kan eksempelvis ha levert en løsning som fungerer isolert sett, men hvor integrasjonen mot et eksisterende system ikke fungerer tilfredsstillende.

Uten tydelig ansvarsfordeling kan dette føre til uenighet om hvem som skal rette feilen, og om leveransen kan godkjennes.

Akseptansetesting og godkjenning

Akseptansetesting har en særlig betydning fordi testresultatene kan danne grunnlaget for kundens kontraktsmessige godkjenning.

Det er derfor viktig å skille mellom:

1. At en test er gjennomført.
2. At testen er bestått.
3. At eventuelle avvik er akseptert.
4. At leveransen er formelt godkjent.

Disse hendelsene er ikke nødvendigvis sammenfallende.

En løsning kan eksempelvis ha bestått de fleste testene, men fortsatt inneholde kritiske feil som hindrer godkjenning.

Tilsvarende kan kunden, dersom kontrakten åpner for det, akseptere mindre avvik uten at leverandøren fritas fra plikten til å rette dem.

Ved bruk av Statens standardavtaler (SSA) må testregimet tilpasses den aktuelle avtaletypen og bestemmelsene om prøving, godkjenning, levering og mislighold.

Det er særlig viktig at kravspesifikasjon, testplan, akseptansekriterier og kontraktens godkjenningsmekanismer henger sammen.

13. Fra testorganisasjon til kontinuerlig kvalitetssikring

Tradisjonelt har testing ofte vært organisert som en egen fase mot slutten av et utviklingsprosjekt.

Moderne utviklingsmetodikk har i økende grad flyttet testarbeidet tidligere i utviklingsprosessen.

Dette omtales gjerne som shift-left testing.

Formålet er å identifisere feil så tidlig som mulig, før de forplanter seg til andre deler av løsningen.

Samtidig har økt bruk av automatisering og kontinuerlig overvåking gjort det mulig å videreføre deler av testarbeidet etter produksjonssetting.

Dette omtales tidvis som shift-right testing.

Testing blir dermed ikke bare en aktivitet som gjennomføres før produksjonssetting, men en kontinuerlig prosess gjennom systemets levetid.

Hva betyr dette for testorganisasjonen?

Testorganisasjonen må i større grad kombinere tradisjonell testkompetanse med kompetanse innen:

• Programvareutvikling og automatisering.
• Infrastruktur og systemarkitektur.
• Informasjonssikkerhet.
• Dataanalyse.
• Kunstig intelligens.
• Virksomhetsprosesser og faglige krav.
• Kontraktsoppfølging og risikostyring.

Samtidig endres testlederens rolle.

Der testledelse tidligere i stor grad handlet om planlegging og koordinering av manuelle tester, vil fremtidens testledelse i økende grad handle om å styre en kombinasjon av automatiserte tester, KI-baserte analyser og menneskelige kvalitetsvurderinger.

14. Konklusjon – testing blir viktigere, ikke mindre viktig

Kunstig intelligens og automatisering gjør det mulig å gjennomføre testing raskere og i større omfang enn tidligere.

Det betyr imidlertid ikke at behovet for testkompetanse forsvinner.

Tvert imot øker betydningen av å forstå hva som skal testes, hvorfor det skal testes, og hvilke resultater som er nødvendige for å kunne konkludere med at en løsning har akseptabel kvalitet.

Black-box-testing og white-box-testing vil fortsatt være sentrale metoder, men de må kombineres med andre testteknikker og tilpasses stadig mer komplekse IT-løsninger.

For offentlige virksomheter er det særlig viktig at testing ikke behandles som en isolert teknisk aktivitet.

Testing bør være en integrert del av hele anskaffelses- og utviklingsprosessen, fra behovsanalyse og kravspesifikasjon til kontraktsoppfølging, akseptanse og videre forvaltning.

Kunstig intelligens kan effektivisere store deler av dette arbeidet, men teknologien kan ikke overta ansvaret for å definere hva som er riktig, hvilke risikoer som kan aksepteres, eller når en løsning er god nok til å tas i bruk.

Det ansvaret ligger fortsatt hos menneskene og virksomhetene som utvikler, anskaffer og benytter teknologien.