Accepttest af forretningssoftware: formål, roller og godkendelse

Formål og afgrænsning: accepttest som forretningens overtagelsesprøve

Formålet med en user acceptance test (UAT) er at verificere brugen. Brugerne skal validere, at løsningen opfylder deres behov, og at de kan gennemføre forretningsarbejdsprocesser med et minimum af udfordringer, omkostninger og risici. Testen skal også bekræfte, at alle aftalte krav er opfyldt. Sådan beskriver Aarhus Universitet UAT: forretningens perspektiv, ikke tekniske detaljer.

Accepttest er ikke fejlfinding. Fejl kan dukke op undervejs, men det er ikke hovedformålet; ifølge AU kan et stort antal fejl på dette tidspunkt få alvorlige konsekvenser for projektets succes. Fejl skal ikke ties ihjel, men accepttesten ligger for sent til at være den primære kvalitetssikring. Den skal bekræfte, at løsningen kan bruges — ikke afprøve, om den grundlæggende virker.

UAT gennemføres af forretningen som afslutning på udviklingen og inden officiel overtagelse. Den sikrer forretningens brugermæssige accept af det leverede produkt. I prøvesammenhæng svarer UAT til en overtagelsesprøve, og en endelig godkendt UAT er betingelse for, at en eventuel driftsprøve kan starte og/eller for, at leverancen kan idriftsættes. Skriv derfor i acceptkriterierne, hvad der skal være opfyldt, før løsningen må sættes i drift — ikke kun hvad der skal testes.

Generelt afgør en acceptance test, om produktet eller systemet opfylder de stillede kriterier — fx brugerbehov, krav og forretningsprocesser. Den afgør også, om brugeren, kunden eller en anden autoritet vil acceptere slutproduktet, som det er. Den ligger sidst i rækken af tests, før løsningen er klar til slutbrugeren.

Roller og ansvar før testen

Placer ansvaret, før scenarierne skrives. Hos AU har forretningens test manager hovedansvaret for UAT. Testen udføres af forretningstestere og eventuelt kommende brugere og godkendes af produktejer eller projektleder. Navngiv rollerne i testplanen, så det står klart, hvem der kan standse en idriftsættelse, og hvem der bærer beslutningen.

Key2Quality stiller tre forberedelsesspørgsmål i sin beskrivelse af den gode accepttest: Har I styr på jeres user stories og acceptkriterier; kender teamet til de arbejdsgange og processer, systemet skal supportere; og er forretningen en hyppig gæst i teamet? Spørgsmålene viser, at ansvaret ikke kun er formelt, men også handler om forretningens daglige tilstedeværelse i udviklingen.

Aftal beslutningsvejene sammen med acceptkriterierne: Hvem kan godkende med forbehold, hvem kan acceptere en afvigelse, og hvem kan udskyde idriftsættelsen? Træffes beslutningen først, når testen er kørt og tidsplanen strammer, er den sværere at holde saglig. Mandatet bør være givet, mens der endnu ikke er noget på spil.

Testgrundlag: fra kravdokument til virkelige arbejdsgange

Ifølge Key2Quality kommer alt for mange fejl, der opdages under accepttest og i produktion, af misforståede krav — eller af krav, som projektet slet ikke kendte til. Konsekvensen er velkendt: Forretningen kan konstatere, at brugerne ikke mener, de kan bruge løsningen i praksis. Løsningen er ikke fit for purpose og understøtter ikke deres arbejdsgange og behov, selv om kravene formelt er opfyldt.

En lang liste af krav i et kravdokument eller regneark er derfor ikke et tilstrækkeligt testgrundlag. Kravdokumentet beskriver, hvad der er aftalt, ikke hvordan arbejdet faktisk udføres. Tjek, at testgrundlaget også indeholder dokumenterede arbejdsgange, brugerbehov og de data, som brugerne arbejder med til daglig.

Key2Quality anbefaler at identificere og dokumentere de arbejdsgange, løsningen skal understøtte, og bruge dem som udgangspunkt for testen. Det gælder især ved formelle accepttests og afleveringsforretninger, men også i den løbende test i teamet. Det er for sent at opdage, at løsningen ikke er fit for purpose, når man står til accepttest lige før produktion.

Kontrollér, at UAT-grundlaget kan verificere, at alle aftalte krav er opfyldt. Kravene skal være entydigt formuleret med tilhørende acceptkriterier. Det skal efterfølgende kunne afgøres, om et udfald er bestået eller ej, uden at kravteksten fortolkes på ny.

Scenariecheckliste: dæk forretningsprocesser, data og integrationer

AUs fokus for UAT dækker fem områder: funktionalitet, forretningsprocesser, brugerbehov, krav og data. Brug dem som overordnet dækningskontrol. Sikr mindst ét scenarie for hver forretningskritisk proces — ikke kun ét scenarie pr. krav.

Flowdiagrammer kan bruges både som dokumentation og som udgangspunkt for testteknikken procescyklustest (PCT), hvor man følger processens forgreninger og undtagelser. Det giver typisk scenarier for alternative veje og fejlveje, som en ren kravgennemgang ikke afdækker.

Medtag end-to-end-scenarier, hvor løsningen indgår i samspil med andre systemer. Involverer end-to-end-testen integrationer til andre systemer, kan det være relevant at gennemføre den i sammenhæng med det integrerede testmiljø. Så valideres samspillet — og ikke kun den enkelte løsning.

For data: dæk både typiske transaktioner og de kanttilfælde, forretningen møder i praksis — data fra et andet system, ældre data, ufuldstændige registreringer og data i de mængder, driften forventes at håndtere. Scenarierne bør beskrive, hvilke data der skal være til stede, før scenariet kan gennemføres.

Miljø, data og adgang

UAT afvikles i systemets testmiljø. Ved en end-to-end-test med integrationer til andre systemer kan det være relevant at teste i sammenhæng med det integrerede testmiljø. Aftal derfor tidligt i planlægningen, hvilke miljøer testen kræver, hvem der etablerer dem, og hvornår de er tilgængelige. Så udskyder miljøet ikke testen.

AU arbejder på at sikre grundlaget for, at flere parallelle testmiljøer, herunder integrerede testmiljøer, kan etableres efter behov. Tag det med i planlægningen, hvis flere testspor eller flere integrationer skal køre samtidig.

Testdata skal være repræsentative for den daglige drift og stilles til rådighed for dem, der skal teste. Gennemgå konkret, at datagrundlaget dækker arbejdsgangene i scenarierne. Aftal, hvem der må se og ændre data i miljøet. Sikr, at forretningstestere og kommende brugere kan logge på med de roller og rettigheder, de får i drift, og at data kan gendannes, så et scenarie kan køres igen efter en fejl.

Adgang er en selvstændig opgave på tjeklisten. Brugernes konti, roller og rettigheder i testmiljøet skal svare til driften. De personer, der skal udføre testen, skal have adgang i hele testperioden — også når der testes uden for normal arbejdstid eller på tværs af organisatoriske enheder.

Accepttest i agile og trinvise leverancer

I agil og inkrementel udvikling skal UAT-fasen brydes op. Testen udføres løbende, efterhånden som de enkelte inkrementer opfylder done-kriterierne. I Scrum placerer AU typisk UAT i eventet Sprint Review, hvor relevante brugere kan inviteres til at deltage.

Hvis inkrementerne ikke idriftsættes enkeltvis efter hvert sprint, kan det give mening at udføre en UAT på en samling af inkrementer forud for deres egentlige idriftsættelse. Formålet er at sikre, at forretningsarbejdsprocesser på tværs af inkrementerne kan udføres og opfylder krav og behov. Processen gentages, indtil det sidste inkrement er udviklet og accepttestet.

Færdiggøres inkrementerne til et før-produktionsmiljø og idriftsættes samlet sidst i projektet, bør der foretages en samlet og tværgående UAT. Dens godkendelse er betingelse for idriftsættelsen. Den samlede test er ikke en ekstra formalitet oveni de løbende tests. Den er den prøve, der afgør, om de enkelte inkrementer tilsammen udgør en brugbar forretningsløsning.

Sikkerhedscheck: uønsket funktionalitet og sårbarheder

Brugertest, user acceptance test, integrationstest og lignende har fokus på softwarens forventede funktionalitet. Sikkerhedstestning har fokus på uønsket funktionalitet. Den funktionelle accepttest bør derfor suppleres med sikkerhedsrelevante tjek. Ellers står uønsket eller ubrugt funktionalitet uafprøvet hen, når løsningen tages i brug.

Et produkt kan indeholde uønsket eller utilsigtet funktionalitet, som der er mindre fokus på hos både kunden og leverandøren. Uønsket funktionalitet er samtidig unødig og generelt ikke anvendt funktionalitet. Fordi den typiske bruger ikke anvender den, kan skjulte sikkerhedsmæssige problemer eksistere i årevis, mens personer med onde hensigter målrettet søger efter den for at misbruge den. Spørg derfor leverandøren, hvilke dele af funktionaliteten der ikke er tiltænkt brugerne, og hvordan de er beskyttet.

Stadig mere komplekse it-systemer og integrationer mellem dem øger sandsynligheden for fejl og sårbarheder, også selv om der arbejdes med sikkerhed under udviklingen. Meget software udvikles ved brug af færdige komponenter, der er en del af et developer tool eller udviklet af en tredjepart, hvis sikkerhedsmæssige fokus man ikke kender. Gennemgå derfor, hvilke tredjepartskomponenter og integrationer løsningen bygger på, og hvordan de vedligeholdes.

Test er både en forebyggende foranstaltning, der mindsker sandsynligheden for fejl inden idriftsættelse, og en opdagende foranstaltning, der kan afdække sårbarheder i allerede ibrugtagne it-systemer — egne applikationer såvel som styresystemer, tredjepartssoftware og systemkonfigurationer. Sårbarheder kan have været der siden ibrugtagningen og først blive aktuelle senere, fx hvis hackere viser, at de kan udnyttes. Gentag derfor sikkerhedsrelevant test ved ændringer. Sørg for, at fejl rettes hurtigt, inden de udnyttes ondsindet.

Vigtige sikkerhedsaspekter i accepttest

Godkendelse, afvigelser og overtagelse

Dokumentér resultatet pr. scenarie og pr. acceptkriterium. Det skal fremgå, hvad der er testet, med hvilke data, af hvem og med hvilket udfald. Godkendelsen ligger hos produktejer eller projektleder. Det er den rolle, AU angiver som godkendende for UAT.

Afvigelser skal håndteres efter en aftalt fremgangsmåde, før godkendelsen gives. Registrér afvigelsen med henvisning til det krav eller den arbejdsgang, den rammer. Vurder, om den blokerer forretningsprocessen, og beslut, om den skal rettes før idriftsættelse eller accepteres med kendt konsekvens. Sæt en dato for, hvornår afhjælpningen senest er på plads; en accepteret afvigelse er en forretningsbeslutning, ikke en teknisk.

UAT svarer i prøvesammenhæng til en overtagelsesprøve. En endelig og godkendt UAT er betingelsen for, at en eventuel driftsprøve kan starte, og/eller for at leverancen kan idriftsættes. Da accepttesten samtidig er den sidste test, der afgør, om løsningen er klar til slutbrugeren, bør den godkendte accepttest indgå som en betingelse i idriftsættelsesplanen. Den bør ikke ligge som en aktivitet ved siden af.