BLOG
SOFTWARETEST

Blog: Effektiv test i offentlige IT-projekter

Testen i offentlige IT-projekter er helt central for kvaliteten af det leverede produkt. Fra en række offentlige projekter er det erfaringen, at test - og i forbindelse hermed også overtagelsesprøven - ikke organiseres optimalt. Overtagelsesprøven, og dermed leverancekontrollen, overlades til leverandøren. Dette medfører, at overtagelsesprøven enten nedvurderes, eller at der ikke foretages tilstrækkelig modtagekontrol.

[29. marts 2016] Anbefalinger vedrørende test og overtagelsesprøver er en integreret del af K-kontrakterne. Disse standardkontrakter er udarbejdet af en arbejdsgruppe bestående af Videnskabsministeriet, Økonomistyrelsen, Kammeradvokaten, Dansk IT og IT-Brancheforeningen, som har gjort et rigtigt godt stykke arbejde i at udarbejde tre standardkontrakter for indkøb af IT-systemer. Arbejdet var foranlediget af ønsket om, at gøre det nemmere at indgå kontrakter om indkøb af IT-systemer, både for kunde og for leverandør, samt at skabe et fælles paradigme for udarbejdelse af IT-kontrakter.

I alle tre kontrakter står imidlertid følgende ordlyd i forbindelse med overtagelsesprøven: ”Overtagelsesprøven gennemføres af Leverandøren med Kundens aktive deltagelse”. Dette har medført, at mange offentlige organisationer vælger at lave udbud, hvori det er et mindstekrav, at leverandøren står for overtagelsesprøven og dermed også implicit accepttesten.

Idet kravet om overtagelsesprøven er et mindstekrav, er leverandøren nødt til at skrive med i deres tilbud, at de vil forestå overtagelsesprøven. Leverandøren har dog pga. manglende indsigt i kundens arbejdsgange, ikke forudsætning for at forestå accepttesten, uden at bruge meget store mængder af ressourcer.

Ydermere kan leverandørens incitament til at gennemføre en tilstrækkelig accepttest diskuteres, da leverandøren som oftest gerne vil have afsluttet projektet, så det kan overgå til drift. Dette er der flere årsager til. For det første vil leverandørens projektleder gerne have afleveret projektet til drift, og dermed fuldføre sin opgave som projektleder - at få identificeret fejl, og efterfølgende få rettet op på disse, trækker på projektets tid og budget, og dermed på hvor succesfuld projektet opfattes i langt de fleste organisationer. For det andet har leverandøren ofte solgt sit projekt således, at de fejl der identificeres efter idriftsættelse betragtes som ændringsanmodninger, og det betyder, at kunden skal betale for at få dem rettet. For det tredje så oplever leveranceprojektet ofte at være under pres, og når vi er pressede, så vil vi løse problemet her og nu og tænker knapt så langsigtet.

Jeg har talt med mange offentlige udbydere om dette. Langt de fleste af disse finder denne organisering af testen hensigtsmæssig. De har ikke selv hverken erfaring eller ressourcer til at gennemføre en accepttest. Men det er her meget vigtigt at huske, at når leverandøren bliver bedt om at levere noget som et mindstekrav, så skriver de med i tilbuddet, at de leverer det, samtidig hermed tilføjer de en linje i estimeringsarket, og det tal der tilføjes her er højt, for jo mere usikker man er på hvad en opgave indeholder, jo større bliver estimatet for løsning af opgaven.

Ud fra min erfaring sker der en af følgende tre ting i forbindelse med accepttesten, når det er leverandøren der skal gennemføre den:

a)     Der foretages enten slet ikke en accepttest, eller der foretages kun en meget minimal accepttest

b)     Kunden ansætter en til at sørge for at leverandøren leverer det aftalte

c)     Kunden forestår selv opgaven evt. med hjælp fra testkonsulenter

Dette betyder at kunden enten betaler for en ydelse, de ikke modtager (Jf. pkt. a) eller betaler for den samme ydelse flere gange (Jf. pkt. b og c).

Jeg vil derfor anbefale, at man som offentlig udbyder ikke beder leverandøren om at forestå accepttesten, men at man i stedet enten sammensætter et team med professionelle testere internt, eller søger hjælp eksternt.

Den eksterne hjælp kan enten være som Time Material eller udbydes som en delleverance til projektet, hvor der stilles krav til hvilke opgaver leverandøren af test skal løfte og hvilket ansvar der hører med opgaven.

Lige meget hvilken form der vælges er det vigtigt, at der også stilles krav til leverandørens test og ikke kun til accepttesten. Accepttestens formål er, at fastlægge om systemet opfylder acceptkriterierne som er sat i forhold til kravene, ligegyldigt om kravene har form af funktionelle og non-funktionelle krav, use cases, user stories eller andet. Det er altså ikke formålet at afdække fejl i systemet i denne fase, det skal leverandørens egen test have afdækket. Men alt for tit ser vi desværre, at den offentlige kunde får leveret et system til accepttest, som er alt for fejlfyldt.

Selvom det nemmeste som kunde er, at give leverandøren alt ansvar for test, og blot forvente at få et næsten fejlfrit system, hvorfor så ikke sætte krav til leverandørens test som sikrer, at der modtages et testet system – i stedet for blot at håbe?

Du kan høre meget mere om det her i vores kommende event: Test i offentlige IT-projekter

Margit Sejerkilde
Margit Sejerkilde
Senior Test Management Consultant
+45 52189787
todo todo