Hvordan etablere en testorganisasjon – roller, ansvar og kvalitetssikring av IT-leveranser

1. Hvorfor trenger man en testorganisasjon?

Testing er en sentral del av kvalitetssikringen ved utvikling, anskaffelse og innføring av IT-systemer.

Likevel er testing ofte en aktivitet som får begrenset oppmerksomhet i planleggingsfasen. Prosjektet konsentrerer seg om behovsanalyser, kravspesifikasjoner, anskaffelsesprosesser og utvikling, mens testarbeidet først blir konkretisert når løsningen nærmer seg ferdigstillelse.

Dette kan få betydelige konsekvenser.

Dersom det ikke er etablert en testorganisasjon, risikerer virksomheten at:

• Det er uklart hvem som har ansvar for å gjennomføre testene.
• Testene ikke dekker alle relevante krav.
• Leverandøren i praksis kontrollerer og godkjenner sitt eget arbeid.
• Testmiljøer og testdata ikke er tilgjengelige når de trengs.
• Feil oppdages sent og blir kostbare å rette.
• Det oppstår uenighet om hvorvidt leveransen oppfyller kontrakten.
• Løsningen settes i produksjon med uakseptabel risiko.

En testorganisasjon skal sikre at testarbeidet gjennomføres systematisk, dokumenteres og gir et forsvarlig grunnlag for beslutninger.

Det betyr ikke nødvendigvis at virksomheten må etablere en permanent avdeling for testing.

En testorganisasjon kan være en midlertidig prosjektorganisasjon, et tverrfaglig team eller en kombinasjon av interne og eksterne ressurser.

Det avgjørende er at roller, ansvar, myndighet og arbeidsprosesser er tydelig definert.

2. Skillet mellom leverandørens og kundens testansvar

Et grunnleggende prinsipp ved anskaffelse av IT-systemer er at leverandørens kvalitetssikring og kundens akseptanse av leveransen har forskjellige formål.

Leverandørens kvalitetssikring

Leverandøren har normalt ansvar for å utvikle og levere løsningen i samsvar med kontrakten.

Som en del av dette må leverandøren gjennomføre nødvendig kvalitetssikring.

Dette omfatter typisk:

• Enhetstesting.
• Integrasjonstesting mellom egne komponenter.
• Systemtesting.
• Teknisk ytelsestesting.
• Sikkerhetstesting.
• Regresjonstesting.
• Dokumentasjon av testresultater.
• Retting av identifiserte feil.

Leverandøren skal med andre ord kunne dokumentere at løsningen er tilstrekkelig kvalitetssikret før den overleveres til kundens testing.

Det er normalt lite hensiktsmessig at kunden skal bruke egne ressurser på å identifisere feil som leverandøren burde ha avdekket gjennom sin interne kvalitetssikring.

Kundens kontroll og akseptansetesting

Kundens testing har et annet utgangspunkt.

Kunden skal kontrollere at leveransen oppfyller de avtalte kravene, fungerer i virksomhetens tekniske miljø og dekker de behovene anskaffelsen skulle løse.

Dette innebærer blant annet å undersøke:

• Om funksjonaliteten samsvarer med kravspesifikasjonen.
• Om løsningen støtter virksomhetens arbeidsprosesser.
• Om integrasjonene mot eksisterende systemer fungerer.
• Om ytelse, kapasitet og sikkerhet er tilfredsstillende.
• Om nødvendige drifts- og forvaltningsprosesser er etablert.
• Om leveransen oppfyller avtalte akseptansekriterier.

Kunden bør ikke uten videre legge leverandørens egne testresultater til grunn som tilstrekkelig dokumentasjon for godkjenning.

Samtidig er det verken nødvendig eller hensiktsmessig at kunden gjentar samtlige tester leverandøren allerede har gjennomført.

En risikobasert tilnærming innebærer at kunden gjennomgår leverandørens testdokumentasjon og gjennomfører egne tester der dette er nødvendig.

Det sentrale er at leverandøren skal dokumentere kvaliteten på sin leveranse, mens kunden må ha et selvstendig grunnlag for å vurdere om leveransen kan aksepteres.

Den konkrete ansvarsfordelingen må reguleres i kontrakten.

3. Testorganisasjonen bør etableres før utviklingen starter

En vanlig feil er å etablere testorganisasjonen først når leverandøren nærmer seg ferdigstillelse.

På dette tidspunktet kan viktige beslutninger allerede være tatt.

Kravspesifikasjonen kan inneholde krav som er vanskelige å teste, nødvendige testmiljøer kan mangle, og det kan være uklart hvilke kriterier som skal gjelde for godkjenning.

Testorganisasjonen bør derfor etableres tidlig.

Ved større offentlige IT-anskaffelser bør sentrale testressurser involveres allerede under arbeidet med kravspesifikasjonen.

Dette gjør det mulig å vurdere om kravene er:

1. Entydige.
2. Målbare.
3. Etterprøvbare.
4. Teknisk gjennomførbare.
5. Egnet som grunnlag for akseptansetesting.

Eksempel: Et krav om høy tilgjengelighet

En kravspesifikasjon kan inneholde følgende formulering:

«Systemet skal ha høy tilgjengelighet.»

Dette er vanskelig å teste fordi det ikke er definert hva høy tilgjengelighet betyr.

Et mer presist krav kan være:

«Tjenesten skal ha en tilgjengelighet på minst 99,9 prosent per kalendermåned, målt innenfor avtalt tjenestetid.»

Men også dette kravet krever nærmere avklaringer.

Det må blant annet defineres hvordan tilgjengeligheten måles, hvilke komponenter som omfattes, hvordan planlagt vedlikehold behandles, og hvilke hendelser som eventuelt er unntatt.

Det er også nødvendig å skille mellom testing av løsningens tilgjengelighetsmekanismer før produksjonssetting og måling av faktisk tilgjengelighet over tid.

En akseptansetest kan eksempelvis kontrollere at løsningen håndterer bortfall av en server uten tjenesteavbrudd. Den kan derimot ikke alene dokumentere at tjenesten vil oppnå 99,9 prosent tilgjengelighet gjennom et helt driftsår.

Dette illustrerer hvorfor testkompetanse bør involveres allerede når kravene utformes.

4. Hvordan bør testorganisasjonen organiseres?

Organiseringen bør tilpasses prosjektets størrelse, kompleksitet og risikoprofil.

For mindre IT-leveranser kan det være tilstrekkelig med en testansvarlig og noen fagressurser.

Ved større prosjekter kan det være nødvendig med en egen testorganisasjon som omfatter både tekniske spesialister, testutviklere, virksomhetsrepresentanter og sikkerhetsressurser.

Sentrale roller

Det er ikke nødvendig at alle rollene bemannes av forskjellige personer.

Det er imidlertid viktig å skille mellom ansvar for å gjennomføre tester og myndighet til å godkjenne leveransen.

Testlederens rolle

Testlederen har en sentral funksjon.

Vedkommende skal normalt sørge for at det foreligger en samlet testplan, at testene gjennomføres i riktig rekkefølge, og at resultatene dokumenteres.

Testlederen bør også ha ansvar for å:

• Følge opp testdekning.
• Koordinere testressurser.
• Sikre tilgang til testmiljøer.
• Følge opp feil og avvik.
• Rapportere risiko.
• Vurdere om testaktivitetene kan avsluttes.
• Utarbeide anbefalinger til prosjektledelsen.

Testlederen bør ha tilstrekkelig uavhengighet til å rapportere kritiske feil uten at fremdriftshensyn påvirker vurderingen.

Dette betyr ikke at testlederen alene skal avgjøre om løsningen kan godkjennes.

Godkjenning bør foretas av den rollen som har fått denne myndigheten i prosjektet og etter kontrakten.

5. Uavhengighet – hvem skal kontrollere leverandøren?

Et sentralt spørsmål er hvor uavhengig testorganisasjonen bør være.

I programvareutvikling er det vanlig at utviklerne selv gjennomfører enhetstesting og deler av integrasjonstestingen.

Dette er både naturlig og effektivt.

Utviklerne kjenner programkoden og kan raskt identifisere og rette tekniske feil.

Samtidig har utviklere ofte en annen tilnærming til testing enn sluttbrukere.

Utvikleren vet hvordan systemet er ment å fungere. En bruker kan derimot forsøke å gjennomføre arbeidsoppgaver på måter utvikleren ikke har forutsett.

Derfor er det viktig å kombinere ulike perspektiver.

Tre nivåer av kontroll

En hensiktsmessig modell kan være:

Nivå 1 – Leverandørens interne kvalitetssikring

Leverandøren gjennomfører tester for å kontrollere egen leveranse.

Nivå 2 – Kundens testorganisasjon

Kunden kontrollerer leveransen opp mot krav, behov og akseptansekriterier.

Nivå 3 – Uavhengig kvalitetssikring

Ved særlig komplekse eller kritiske leveranser kan en uavhengig tredjepart gjennomføre ytterligere kontroller.

Dette kan eksempelvis omfatte sikkerhetstesting, arkitekturgjennomgang eller kontroll av kritiske integrasjoner.

Det tredje nivået er ikke nødvendig i alle prosjekter.

Behovet bør vurderes ut fra risiko, kompleksitet og konsekvensene av feil.

6. Teststrategien – grunnlaget for organisert testing

Teststrategien beskriver hvordan virksomheten skal sikre at løsningen blir tilstrekkelig testet.

Den bør etableres tidlig og være førende for den mer detaljerte testplanleggingen.

En teststrategi bør som minimum omfatte følgende områder.

Omfang

Hvilke deler av løsningen skal testes?

Dette kan omfatte funksjonalitet, integrasjoner, infrastruktur, sikkerhet, ytelse, brukervennlighet og driftsprosesser.

Det bør også fremgå hva som ikke skal testes, og hvorfor.

Testnivåer

Hvilke testnivåer skal gjennomføres?

Det bør skilles mellom enhetstesting, integrasjonstesting, systemtesting og akseptansetesting.

Testmetoder

Hvilke metoder skal benyttes?

Dette kan eksempelvis være black-box-testing, white-box-testing, risikobasert testing og automatisert regresjonstesting.

Ansvar

Hvem har ansvar for å utforme, gjennomføre, dokumentere og godkjenne de ulike testene?

Testmiljøer

Hvilke tekniske miljøer kreves, og hvem har ansvar for å etablere og vedlikeholde dem?

Testdata

Hvordan skal testdata etableres, vedlikeholdes og beskyttes?

Avvikshåndtering

Hvordan skal feil registreres, klassifiseres, prioriteres og rettes?

Godkjenningskriterier

Hvilke krav må være oppfylt før løsningen kan aksepteres?

En teststrategi bør ikke være et statisk dokument.

Den må kunne oppdateres dersom prosjektets omfang, risikobilde eller tekniske forutsetninger endres.

Samtidig må endringer som påvirker kontraktsfestede testforpliktelser eller godkjenningskriterier, håndteres i samsvar med kontraktens endringsmekanismer.

7. Fra kravspesifikasjon til testtilfeller

En av de viktigste oppgavene for testorganisasjonen er å sikre sammenheng mellom krav og tester.

Hvert relevant krav bør kunne knyttes til ett eller flere testtilfeller eller andre egnede verifikasjonsaktiviteter.

Dette omtales gjerne som sporbarhet.

Eksempel

Anta at kravspesifikasjonen inneholder følgende krav:

KR-101: Systemet skal forhindre at en bruker uten godkjenningsmyndighet godkjenner en utbetaling.

Dette kan gi grunnlag for flere tester:

Eksemplet viser at ett krav kan gi opphav til flere tester.

Det illustrerer også hvorfor det ikke er tilstrekkelig å teste brukergrensesnittet alene.

Selv om en bruker ikke får tilgang til en godkjenningsknapp, kan det fortsatt være mulig å gjennomføre handlingen gjennom et API dersom tilgangskontrollen er mangelfull.

Sporbarhetsmatrise

En sporbarhetsmatrise kan brukes til å dokumentere sammenhengen mellom krav, testtilfeller og resultater.

En slik oversikt gjør det mulig å identifisere krav som ikke er testet, og hvilke avvik som fortsatt er åpne.

Dette er særlig viktig ved akseptansetesting.

8. Testmiljøer – en forutsetning for pålitelige resultater

Et testmiljø er den tekniske infrastrukturen som benyttes til å gjennomføre tester.

Testmiljøet kan bestå av programvare, databaser, servere, nettverk, integrasjoner og sikkerhetsmekanismer.

For at testresultatene skal være relevante, må testmiljøet i tilstrekkelig grad representere produksjonsmiljøet.

Det betyr ikke nødvendigvis at miljøene må være identiske.

Det avgjørende er at forskjellene er kjent og ikke gjør testresultatene misvisende.

Eksempel: Ytelsestesting

Et system skal kunne håndtere 5 000 samtidige brukere.

Dersom ytelsestestingen gjennomføres på en server med vesentlig høyere kapasitet enn produksjonsmiljøet, kan resultatene gi et feilaktig bilde av løsningens faktiske ytelse.

Tilsvarende kan et testmiljø med svært små datamengder skjule problemer som først oppstår når databasen inneholder flere millioner registreringer.

Testorganisasjonen må derfor vurdere om testmiljøet er representativt for den aktuelle testen.

Hvem skal ha ansvar for testmiljøet?

Dette bør avklares tidlig.

I noen prosjekter etablerer leverandøren alle testmiljøene.

I andre prosjekter etablerer kunden egne miljøer, særlig når løsningen skal integreres med eksisterende systemer.

Det bør fremgå tydelig hvem som har ansvar for:

• Infrastruktur og kapasitet.
• Installasjon og konfigurasjon.
• Tilgangsstyring.
• Integrasjoner.
• Testdata.
• Oppdateringer.
• Feilsøking.
• Tilbakestilling av miljøet.

Uklare ansvarsforhold kan føre til betydelige forsinkelser.

9. Testdata – ofte en undervurdert utfordring

Selv med gode testmiljøer kan testing være vanskelig dersom nødvendige testdata mangler.

Et saksbehandlingssystem kan eksempelvis kreve data som representerer forskjellige sakstyper, brukerroller, historiske hendelser og unntakssituasjoner.

Det er sjelden tilstrekkelig å teste med noen få enkle eksempler.

Testdata bør omfatte både normale situasjoner og mer krevende tilfeller.

Dette kan blant annet være:

• Manglende eller ugyldige opplysninger.
• Store datamengder.
• Historiske data.
• Uvanlige kombinasjoner av verdier.
• Feilaktige formater.
• Grenseverdier.
• Data som utløser bestemte forretningsregler.

Personvern og informasjonssikkerhet

Ved testing i offentlige virksomheter kan testdata inneholde personopplysninger eller annen beskyttelsesverdig informasjon.

Bruk av produksjonsdata i testmiljøer krever derfor særskilt oppmerksomhet.

Der det er mulig, bør virksomheten benytte syntetiske eller tilstrekkelig anonymiserte data.

Pseudonymiserte data er fortsatt personopplysninger dersom enkeltpersoner kan identifiseres ved hjelp av tilleggsinformasjon.

Det må også sikres at testmiljøer har tilstrekkelige sikkerhetstiltak.

Et testmiljø bør ikke bli en mindre beskyttet kopi av produksjonsmiljøet.

10. Feil- og avvikshåndtering

Testing vil normalt avdekke feil.

En viktig del av testorganisasjonens arbeid er derfor å sikre at feilene blir registrert, vurdert og håndtert systematisk.

Det bør etableres en felles prosess for avvikshåndtering.

Et avvik bør som minimum dokumenteres med:

• Unik identifikator.
• Beskrivelse av feilen.
• Fremgangsmåte for å gjenskape feilen.
• Forventet resultat.
• Faktisk resultat.
• Alvorlighetsgrad.
• Ansvarlig for oppfølging.
• Status.
• Referanse til berørte krav og testtilfeller.

Klassifisering av feil

En vanlig tilnærming er å klassifisere feil etter alvorlighetsgrad.

Klassifiseringen bør tilpasses prosjektet og fastsettes før testingen starter.

Det er også viktig å skille mellom alvorlighetsgrad og prioritet.

En feil kan ha høy alvorlighetsgrad, men lav umiddelbar prioritet dersom den gjelder en funksjon som ikke skal tas i bruk før senere.

Tilsvarende kan en mindre feil få høy prioritet dersom den hindrer gjennomføring av et stort antall tester.

Hvem bestemmer om en feil kan aksepteres?

Leverandøren bør ikke ensidig kunne avgjøre hvilke avvik kunden må akseptere.

Det bør etableres en prosess hvor kunden vurderer om åpne avvik er forenlige med kontraktens godkjenningskriterier.

Aksept av et avvik ved levering bør heller ikke automatisk innebære at leverandøren fritas fra å rette feilen.

Dette må håndteres i samsvar med kontraktens bestemmelser.

11. Akseptansetesting – når kan leveransen godkjennes?

Akseptansetesting er ofte den mest kontraktsmessig betydningsfulle delen av testarbeidet.

Formålet er å avgjøre om leveransen oppfyller de avtalte kriteriene for godkjenning.

Det er viktig å skille mellom teknisk ferdigstillelse og kontraktsmessig godkjenning.

En leverandør kan mene at løsningen er ferdig utviklet, uten at kunden dermed er forpliktet til å godkjenne leveransen.

Kriterier for godkjenning

Godkjenningskriteriene bør være fastsatt før testingen starter.

De kan eksempelvis omfatte:

1. Alle obligatoriske funksjonelle krav skal være verifisert.
2. Ingen åpne kritiske avvik.
3. Åpne avvik med høy alvorlighetsgrad skal være håndtert i samsvar med avtalte kriterier.
4. Avtalte ytelseskrav skal være oppfylt.
5. Sikkerhetstesting skal være gjennomført med tilfredsstillende resultat.
6. Nødvendig dokumentasjon skal være levert.
7. Avtalte integrasjoner skal fungere.
8. Eventuelle krav til driftsberedskap skal være oppfylt.

Dette er eksempler, ikke universelle godkjenningskriterier.

De konkrete kriteriene må tilpasses leveransen og kontrakten.

Testprotokoll

Resultatene fra akseptansetestingen bør dokumenteres i en testprotokoll.

Protokollen bør blant annet inneholde:

• Oversikt over gjennomførte tester.
• Resultater.
• Åpne avvik.
• Vurdering av testdekning.
• Eventuelle begrensninger i testgrunnlaget.
• Anbefaling om godkjenning eller avvisning.

En testprotokoll gir beslutningstakerne et dokumentert grunnlag for å avgjøre om leveransen kan aksepteres.

Den kan også få betydning dersom det senere oppstår uenighet om hvorvidt leveransen oppfylte kontrakten.

12. Testing og Statens standardavtaler

Ved offentlige IT-anskaffelser benyttes ofte Statens standardavtaler (SSA).

Hvilken avtale som benyttes, har betydning for hvordan testarbeidet bør organiseres.

Ved anskaffelse av et system som skal utvikles eller tilpasses, vil det normalt være nødvendig med en strukturert prosess for testing og godkjenning.

Ved kjøp av standard programvare eller løpende tjenester kan testbehovet og de kontraktsmessige mekanismene være annerledes.

Sammenhengen mellom krav og kontrakt

Et sentralt prinsipp bør være at det er sammenheng mellom:

Kundens behov → Kravspesifikasjon → Leverandørens løsningsbeskrivelse → Testtilfeller → Testresultater → Godkjenning

Dersom denne sammenhengen mangler, kan det oppstå betydelig usikkerhet om hva leverandøren faktisk har forpliktet seg til å levere.

Eksempel: Et integrasjonskrav

Kunden stiller følgende krav:

«Løsningen skal integreres med virksomhetens økonomisystem.»

Leverandøren bekrefter at kravet oppfylles.

Under akseptansetesting viser det seg imidlertid at integrasjonen bare støtter overføring av fakturadata, mens kunden også forventet overføring av betalingsstatus.

Hvem har ansvaret?

Svaret avhenger av kontrakten og hvordan kravet og leverandørens forpliktelser er beskrevet.

Eksemplet illustrerer hvorfor krav bør være presise, og hvorfor testtilfeller bør utformes tidlig.

Et mer presist krav kunne ha definert hvilke data som skal utveksles, i hvilken retning, med hvilken frekvens og hvordan feil skal håndteres.

Da ville det også vært enklere å avgjøre om leveransen oppfyller kontrakten.

Testing bør ikke brukes til å definere nye krav

En annen viktig problemstilling er at kunden under testing kan oppdage behov som ikke var beskrevet i kravspesifikasjonen.

Dette er ikke nødvendigvis feil ved leveransen.

Det kan være nye eller endrede behov.

Testorganisasjonen bør derfor skille mellom:

• Avvik fra avtalte krav.
• Feil ved løsningen.
• Endringsønsker.
• Nye behov.

Dette skillet er viktig både for prosjektstyringen og for den kontraktsmessige håndteringen.

I offentlige anskaffelser må endringer også vurderes opp mot anskaffelsesregelverkets begrensninger for endring av inngåtte kontrakter.

13. Testing av maskinvare og infrastruktur

Testorganisasjonen må tilpasses hva som faktisk skal leveres.

Ved anskaffelse av programvare vil testing i stor grad rette seg mot funksjonalitet, data og integrasjoner.

Ved anskaffelse av maskinvare og infrastruktur må andre forhold vektlegges.

Eksempel: Leveranse av serverinfrastruktur

En leveranse kan omfatte servere, lagringssystemer, nettverk og virtualiseringsplattform.

Testorganisasjonen må da kontrollere både de enkelte komponentene og den samlede løsningen.

Relevante tester kan omfatte:

Funksjonstesting: Fungerer komponentene som spesifisert?

Kapasitetstesting: Har løsningen tilstrekkelig kapasitet?

Ytelsestesting: Oppnår løsningen avtalte ytelsesnivåer?

Redundanstesting: Fungerer løsningen ved bortfall av enkeltkomponenter?

Gjenopprettingstesting: Kan data og tjenester gjenopprettes innenfor avtalte tidsrammer?

Sikkerhetstesting: Er tilganger, konfigurasjoner og sikkerhetsmekanismer tilfredsstillende?

Factory Acceptance Test og Site Acceptance Test

Ved større maskinvare- og infrastrukturløsninger kan det være aktuelt å benytte to forskjellige akseptansetestfaser.

Factory Acceptance Test (FAT) gjennomføres før utstyret leveres eller installeres hos kunden.

Formålet er å kontrollere at løsningen fungerer i et kontrollert miljø.

Site Acceptance Test (SAT) gjennomføres etter installasjon i kundens miljø.

Formålet er å kontrollere at løsningen fungerer under de faktiske tekniske forutsetningene.

Dette skillet kan være særlig nyttig ved anskaffelse av datasenterutstyr, nettverksinfrastruktur og andre komplekse tekniske løsninger.

FAT og SAT bør imidlertid ikke betraktes som obligatoriske testfaser ved alle IT-anskaffelser.

Behovet avhenger av leveransens karakter.

14. Testing ved overgang til ny leverandør

En særlig krevende situasjon oppstår når en offentlig virksomhet skal bytte leverandør av IT-drift eller andre kritiske tjenester.

Da er det ikke tilstrekkelig å kontrollere at den nye leverandørens tekniske løsning fungerer.

Virksomheten må også sikre at tjenestene kan overtas uten uakseptable avbrudd eller tap av informasjon.

Hva bør testes?

Ved en leverandørovergang kan testarbeidet blant annet omfatte:

• Migrering av data.
• Integrasjoner.
• Tilgangsstyring.
• Overføring av driftsdokumentasjon.
• Overvåking og hendelseshåndtering.
• Sikkerhetskopiering og gjenoppretting.
• Beredskapsprosedyrer.
• Tjenestenivåer.
• Tilbakeføringsprosedyrer dersom overgangen mislykkes.

Test av tilbakeføringsplan

Et viktig spørsmål er hva som skjer dersom overgangen til ny leverandør ikke lykkes.

Det bør derfor vurderes om det er mulig å gjennomføre en kontrollert tilbakeføring til tidligere løsning eller driftsoppsett.

Dette kan kreve egne tester.

En tilbakeføringsplan som bare eksisterer som dokumentasjon, gir begrenset trygghet dersom den aldri er verifisert.

Ansvarsfordeling mellom leverandørene

Ved leverandørbytte vil både eksisterende og ny leverandør kunne ha oppgaver knyttet til testing.

Kunden bør sikre at ansvarsfordelingen er tydelig.

Det bør blant annet avklares hvem som har ansvar for testdata, tekniske grensesnitt, feilretting, dokumentasjon og godkjenning av migreringsaktiviteter.

Uklare grensesnitt mellom leverandørene kan bli en betydelig risiko for prosjektet.

15. Automatisering og kunstig intelligens i testorganisasjonen

Automatisering har allerede endret hvordan mange testorganisasjoner arbeider.

I stedet for at testere manuelt gjennomfører de samme testene ved hver programvareoppdatering, kan automatiserte tester kjøres kontinuerlig.

Kunstig intelligens utvider mulighetene ytterligere.

KI-baserte verktøy kan blant annet bistå med:

• Analyse av kravspesifikasjoner.
• Generering av testtilfeller.
• Utvikling av automatiserte tester.
• Identifisering av manglende testdekning.
• Analyse av feilmeldinger.
• Prioritering av testaktiviteter.
• Oppsummering av testresultater.

KI endrer kompetansebehovet

Bruk av KI kan redusere behovet for enkelte manuelle og repetitive aktiviteter.

Samtidig øker behovet for kompetanse innen testdesign, risikovurdering og kvalitetssikring av automatiserte resultater.

En KI-assistent kan eksempelvis generere hundrevis av testtilfeller fra en kravspesifikasjon.

Det betyr imidlertid ikke at testene er relevante eller tilstrekkelige.

Hvis kravspesifikasjonen er mangelfull, kan KI generere et omfattende testsett som likevel ikke kontrollerer virksomhetens faktiske behov.

KI kan effektivisere gjennomføringen av testing, men kan ikke erstatte virksomhetens ansvar for å definere hva som skal testes, eller hvilke resultater som er akseptable.

For offentlige virksomheter er dette særlig viktig når testresultatene skal danne grunnlag for kontraktsmessig godkjenning.

16. Testorganisasjonens rapportering

Testorganisasjonen bør rapportere regelmessig til prosjektledelsen.

Rapporteringen bør ikke begrenses til antall gjennomførte tester.

Et høyt antall beståtte tester er ikke nødvendigvis et uttrykk for at løsningen har høy kvalitet.

Det avgjørende er blant annet hvilke krav som er testet, hvor kritiske disse kravene er, og hvilke feil som fortsatt eksisterer.

Relevante styringsindikatorer

Indikatorene bør suppleres med kvalitative vurderinger.

En løsning kan eksempelvis ha bestått 98 prosent av testene, men fortsatt inneholde en kritisk sikkerhetsfeil.

I en slik situasjon vil prosentandelen beståtte tester gi et misvisende bilde dersom den presenteres alene.

17. Når er løsningen klar for produksjon?

Det er viktig å skille mellom tre beslutninger:

1. Er testingen tilstrekkelig gjennomført?

Dette er en vurdering av testdekning, testresultater og gjenværende risiko.

2. Kan leveransen godkjennes etter kontrakten?

Dette er en vurdering opp mot de avtalte godkjenningskriteriene.

3. Er virksomheten klar til å ta løsningen i bruk?

Dette omfatter også forhold utenfor selve testingen.

Eksempelvis kan løsningen være teknisk godkjent, men virksomheten kan fortsatt mangle opplæring, driftsrutiner eller nødvendige organisatoriske forberedelser.

Det bør derfor etableres en egen beslutning om produksjonssetting.

Denne omtales ofte som en go/no-go-beslutning.

Beslutningen bør bygge på en samlet vurdering av blant annet:

• Testresultater.
• Åpne feil.
• Informasjonssikkerhet.
• Driftsberedskap.
• Brukeropplæring.
• Migreringsstatus.
• Beredskaps- og tilbakeføringsplaner.
• Gjenværende risiko.

Det er ikke nødvendigvis testlederen som skal fatte denne beslutningen.

Testlederens oppgave er å gi beslutningstakerne et tilstrekkelig og etterprøvbart beslutningsgrunnlag.

18. Konklusjon – testing må organiseres som en styringsfunksjon

En effektiv testorganisasjon handler ikke først og fremst om hvor mange testere virksomheten har.

Det handler om å etablere tydelige roller, ansvar, metoder og beslutningsprosesser som sikrer at IT-leveranser blir kontrollert på en systematisk måte.

For offentlige virksomheter er det særlig viktig å etablere et tydelig skille mellom leverandørens egen kvalitetssikring og kundens kontroll av leveransen.

Leverandøren må kunne dokumentere at løsningen fungerer som avtalt. Kunden må samtidig ha kompetanse og kapasitet til å vurdere om leveransen oppfyller virksomhetens behov og kontraktens krav.

Dette krever at testarbeidet planlegges tidlig, helst allerede under utarbeidelsen av kravspesifikasjonen.

Det må også sikres sammenheng mellom krav, testtilfeller, testresultater og godkjenningskriterier.

Automatisering og kunstig intelligens vil gjøre det mulig å gjennomføre stadig mer omfattende testing med mindre manuelt arbeid.

Men teknologien endrer ikke det grunnleggende ansvarsforholdet.

Det er fortsatt virksomheten som må avgjøre hvilke krav som skal stilles, hvilken risiko som kan aksepteres, og om en IT-leveranse er tilstrekkelig kvalitetssikret til å tas i bruk.

En godt organisert testfunksjon er derfor ikke bare et teknisk kvalitetstiltak. Den er også et viktig virkemiddel for kontraktsoppfølging, risikostyring og god forvaltning av offentlige midler.