Når et nyt system ikke består overtagelsesprøven, er det vigtigste at holde fast i to ting: godkend ikke noget, I ikke kan stå inde for, og dokumentér prøven grundigt, mens den stadig er frisk. Resultatet af prøven er ofte det mest konkrete bevis i en senere tvist, men kun hvis testplan, testresultater og fejlkategorier er gemt og forståelige for en udenforstående.
Artiklen er til IT-chefen, projektlederen og den leder, der skal skrive under på godkendelsen. Den beskriver kundens praktiske håndtering. Hvordan prøven bruges som bevis i en retssag, er en sag for advokaten.
Hvad er en overtagelsesprøve?
En overtagelsesprøve er den test, hvor kunden afprøver, om leverancen opfylder de aftalte krav, før den overtages. Navnet varierer: overtagelsesprøve, accepttest, leveringsprøve. Flere af statens standardkontrakter til IT-projekter opererer med en overtagelsesprøve, ofte efterfulgt af en driftsprøve, hvor systemet afprøves i drift i en periode. Private aftaler bruger tit samme opbygning.
Prøven har typisk retsvirkninger. Når den er bestået, kan risikoen gå over til kunden, betalinger kan forfalde, og fristen for at reklamere kan begynde at løbe. Derfor er det en stor beslutning at erklære prøven bestået, og det er lige så vigtigt at kunne dokumentere, hvorfor den ikke blev det.
De første dage efter prøven
- Gem testplanen i den version, der blev brugt, inklusive testcases og acceptkriterier.
- Gem testresultaterne, som de blev registreret undervejs. Ret ikke i dem bagefter.
- Lav en fejlliste med nummer, beskrivelse, testcase, dato, version og fejlkategori.
- Optag de vigtigste fejl på video, mens de kan genskabes i testmiljøet.
- Notér testmiljøets tilstand: version, data, konfiguration og integrationer.
- Send leverandøren en skriftlig meddelelse om, at prøven ikke er bestået, med fejllisten vedlagt. Lad advokaten se den først, hvis tvisten er tæt på.
- Find fristerne frem i aftalen: hvornår skal der gives besked, og hvornår skal prøven gentages?
Fejlkategorierne afgør meget
Mange aftaler inddeler fejl i kategorier, fx kritiske, alvorlige og mindre fejl, og fastsætter, hvor mange af hver der må være, før prøven ikke er bestået. Uenighed om kategoriseringen er en af de mest almindelige tvister efter en prøve.
- Hvilken definition af kategorierne der gjaldt · Så kategoriseringen kan efterprøves
- Hvorfor hver fejl fik sin kategori · Leverandøren vil ofte nedgradere fejl
- Hvem der kategoriserede, og hvornår · Viser, at det skete undervejs, ikke bagefter
- Konsekvensen for jeres forretning · Underbygger alvoren
Skriv begrundelsen ned i fejllisten samtidig med kategorien. En kort sætning er nok: “Kritisk, fordi lønkørsel ikke kan gennemføres.”
Leverandøren er uenig
Det er almindeligt, at leverandøren mener, at fejlene skyldes testdata, brugerfejl, krav, der ikke var aftalt, eller jeres egne systemer. Svar konkret. Henvis til kravspecifikationen og til testcasen. Er en fejl reelt et nyt ønske, så indrøm det, og tag den ud af listen. Det gør resten af listen mere troværdig.
Gem også leverandørens egne testrapporter, hvis de findes. Leverandøren har ofte testet før overleveringen, og forskelle mellem leverandørens og jeres resultater kan sige noget om, hvor fejlen ligger.
Når prøven skal gentages
Mange aftaler giver leverandøren ret til at rette fejlene og gentage prøven inden for en frist. Notér datoen for hver ny prøve, hvilken version der blev testet, og hvilke fejl der blev rettet, og hvilke der kom igen. Fejl, der går igen gennem flere prøver, er tunge i en tvist, men kun hvis I kan vise forløbet. → Skabelon: tidslinje over hændelsen
Pas på med at teste i et miljø, hvor leverandøren løbende ændrer koden under prøven. Aftal, at der testes på en fastlåst version, og notér versionsnummeret.
Testdata og testmiljø
Mange uenigheder efter en prøve handler ikke om koden, men om rammerne. Var testdata repræsentative? Var integrationerne til jeres andre systemer sat op korrekt? Kørte testmiljøet på den hardware og med de rettigheder, der var aftalt? Dokumentér rammerne lige så omhyggeligt som fejlene:
- hvilke testdata der blev brugt, hvem der leverede dem, og en kopi af dem,
- hvilke integrationer der var aktive under prøven,
- hvem der havde administratoradgang til testmiljøet, og om nogen ændrede opsætningen undervejs,
- logs fra testmiljøet for prøvens periode.
Er det leverandøren, der driver testmiljøet, så bed skriftligt om, at det bevares uændret, til fejlene er afklaret. Spørg også, hvor længe logs gemmes. De kan forsvinde efter få uger.
Hvis driftsprøven fejler
Består systemet overtagelsesprøven, men fejler det senere under en driftsprøve, gælder det samme: dokumentér hver hændelse med tidspunkt, konsekvens og meldingen til leverandøren. Her er jeres egne målinger af oppetid og svartider vigtige, fordi fejlene ofte viser sig som ustabilitet frem for enkeltstående fejl. → Leverandøren overholder ikke SLA: mål og dokumentér selv
Godkendelse med forbehold
Det sker, at kunden er presset til at tage systemet i brug, selv om prøven ikke er bestået, fordi det gamle system skal lukkes. Gør I det, så tal med advokaten først, og få det skriftligt, at ibrugtagningen ikke er en godkendelse, og at fejllisten fortsat står åben. En ibrugtagning uden forbehold kan blive læst som en accept.
Hvem gør hvad
- Testleder eller projektleder · Fører fejllisten og gemmer testresultater
- Testere og superbrugere · Registrerer fejl præcist med tid og eksempel
- IT-chef · Sikrer testmiljø, version og logs
- Ledelse · Beslutter om godkendelse, forbehold eller afvisning
- Advokat · Vurderer frister, meddelelser og forbehold
- IT-sagkyndig · Vurderer omstridte fejl uvildigt
Det må I ikke gøre
- Skrive under på en godkendelse for at få projektet videre.
- Rette i testresultaterne, når I kender udfaldet.
- Lade leverandøren slette eller nulstille testmiljøet, før det er dokumenteret.
- Melde fejl mundtligt på et statusmøde uden at skrive dem ind i listen.
- Kategorisere fejl højere, end I kan begrunde. Overdrivelser bliver brugt mod jer.
Hvornår skal I have hjælp udefra?
Når I og leverandøren er uenige om, om fejlene findes, hvor alvorlige de er, eller hvad de skyldes. En uvildig IT-sagkyndig kan gennemgå testplan og testresultater, efterprøve de omstridte fejl og sikre testmiljøet, så det kan vurderes senere. Bliver sagen til en retssag eller en voldgift, kan en skønsmand blive bedt om at vurdere det samme. → IT-skøn i tvister om IT-projekter og software
Nielco IT er uvildig og har ingen leverandørpartnerskaber. Den tekniske side af testdokumentation er beskrevet for teknikere. → Kildekode og Git som bevis
Læs også: Før I ophæver IT-kontrakten: det skal være dokumenteret · Ændringsønsker og ekstraregninger: hold styr på beviserne undervejs
→ Tvist med en IT-leverandør eller en kunde · Tlf. 70 13 63 23 · Digital bevissikring hos Nielco IT
