AU's testpolitik

Nedenstående testpolitik er 26/4/2019 godkendt i AU IT's ledelse.

Testpolitikken er opdateret af Testenheden 15/2/2023 (tilretning til hybrid udgave af V-modellen)

AU IT vil levere software, der lever op til den kvalitet, der er aftalt med systemejer, hvad enten der er tale om projekter eller udviklingsopgaver i systemforvaltningen. AU IT definerer kvalitet som værende to ting: AU IT udvikler det aftalte – og AU IT udvikler det aftalte rigtigt.

For at imødekomme dette implementerer AU IT systematisk test i udviklingsprocessen. Systematisk test tilbyder netop metodik og værktøjer til at måle kvaliteten i den komponent eller det system, der udvikles. Ambitionen er at fange fejl i leverancerne så tidligt som muligt – og dermed sikre grundlaget for hurtigt at rette fejl/misforståelser, så det videre udviklingsarbejde sker på rette grundlag.

Herudover vil AU IT automatisere test i videst muligt omfang, særligt mhp. sikring af effektiv og nyttig regressionstest, hvilket er en helt nødvendig forudsætning for agil udvikling med continuous integration og continuous delivery.

Det er væsentligt, at testindsatsen i det enkelte projekt/den enkelte udviklingsopgave tilpasses projektets/opgavens størrelse og risiko. Omend test er en integreret del af udviklingsprocessen, er behovet for testomfang forskelligt fra opgave til opgave – og indsatsen skal stå mål med det konkrete behov. Det er dog helt nødvendigt at tage stilling til, hvorledes man sikrer rette kvalitet i enhver leverance.

AU IT anlægger et helhedssyn på testarbejdet for at kunne understøtte komplet og effektiv test. AU IT’s testproces, som er baseret på den internationale standard, ISTQB (International Software Testing Qualifications Board), omfatter derfor det samlede testforløb:

Testplanlægning og kontrol
Testanalyse og design
Implementering og afvikling af test
Evaluering af udgangskriterier og rapportering
Testlukningsaktiviteter

Det er en grundlæggende tanke i AU IT, at ansvaret for kvaliteten i produktet ligger hos projektgruppen/forvaltningsgruppen – men at systematisk test bidrager til løbende, uafhængig og dækkende måling af produktets kvalitet ift. det aftalte.

AU IT’s testprogram udmønter følgende principper:

Vores tilgang til testplanlægning og test er baseret på en systematisk risikovurdering mhp at sikre, at komponenter får den rette testdækning. dvs. høj risiko får høj testdækning. og lav risiko får lav eller ingen dækning.
Omend test er en integreret del af udviklingsprocessen, er behovet for testomfang forskelligt fra opgave til opgave – og indsatsen skal stå mål med det konkrete behov.
Testplanlægning og test tager (med mindre der er tale om et rent vandfaldsprojekt) udgangspunkt i en hybrid udgave af V-modellen (se Demand/supply-model), da udviklingsmetoden som hovedregel er agil og iterativ. Dette sikrer at alle relevante testniveauer tilgodeses.
Vi anvender både statisk og dynamisk test.
Planlægningen af testaktiviteterne sker sammen med planlægningen af øvrige aktiviteter ved projektstart/opstart af udviklingsopgaven i forvaltningen. Test er således en del af planen fra start.
De lavere niveauer af den samlede test skal forberedes og gennemføres tidligt og isoleret – afkoblet fra andre, senere og mere integrerede tests. Drivers og stubbe/mocks kan anvendes ligesom en høj grad af automatisering tilstræbes.
Da en test skal efterprøve, om en given leverance lever op til den aftalte kvalitet, betyder det, at der skal være et testbart kravgrundlag at designe og gennemføre testen på. Er dette ikke tilfældet, skal der planlægges med at lave en tilstrækkelig modning af kravgrundlaget. Dette kan ske i et samarbejde mellem kravstiller og AU IT.
Mhp. at sikre tilstrækkelig og dækkende test designer vi testcases og identificerer test data, der dækker både positiv og negativ test. Dette gælder for komponent-, komponentintegration- og systemtest-niveau.
Test skal i videst muligt omfang være objektiv, og derfor tilstræbes det, at testen planlægges og gennemføres af personer, der er forskellige fra dem, der har produceret det, der skal testes.
De dokumenter og artefakter, der skabes i fbm. testen, og som skal overdrages til drift/-forvaltning efterfølgende, designes på en måde, der gør dem anvendelige til fremtidig brug.