Testdata, testrapporter og testmiljøer som bevis i IT‑tvister

Forside · Gennemgået oktober 2026 · Af John Nielsen

Et testresultat er kun så meget værd som det miljø, de data og den version, det blev opnået med. I en IT-tvist er testdokumentationen ofte det centrale bevis for, om en leverance virkede ved overtagelsen, men en “bestået” eller “fejlet” uden oplysninger om miljø, data og version kan sjældent bære en konklusion. Artiklen handler om den planlagte test: testplaner, testcases, testlogs, fejlrapporter og afslutningsrapporter, herunder test, der udføres manuelt af brugere eller testere.

Automatiserede tests i byggepipelinen er beskrevet i CI/CD-logs og testdokumentation, og koblingen mellem krav og test i kravsporbarhed.

Testdokumentationens dele

ISO/IEC/IEEE 29119-3 beskriver skabeloner for testdokumentation, og selv om få projekter følger standarden til punkt og prikke, er dens opdeling nyttig som tjekliste over, hvad der kan findes:

Testplan og teststrategi · Hvad der skulle testes, hvordan, i hvilket miljø og med hvilke kriterier for at bestå
Testcases og testprocedurer · De konkrete trin, input og forventede resultater
Testlog og testresultater · Hvem der udførte hvilken test, hvornår, mod hvilken version, og med hvilket udfald
Hændelses- eller fejlrapporter · Afvigelser fundet under testen med beskrivelse, alvor og status
Afslutningsrapport · Samlet resultat, afvigelser fra planen, resterende risici

I en tvist er det særligt vigtigt at finde de kriterier, testen skulle bestås efter, og at kunne vise, hvilke tests der faktisk blev udført, i modsætning til dem, der var planlagt.

Hvor dokumentationen ligger

Testdokumentation kan ligge i et testværktøj, i et ticket-system, i regneark, i dokumenter på et fællesdrev eller i en kombination. I Azure DevOps ligger testplaner, testsuiter og testkørsler i Azure Test Plans. Microsofts dokumentation om opbevaring angiver, at manuelle testresultater ikke slettes af opbevaringspolitikken, mens opbevaringen af automatiserede testkørsler styres i projektets indstillinger. I Jira håndteres test ofte i tilføjelser fra Atlassian Marketplace, og deres historik og eksport afhænger af den konkrete tilføjelse.

Regneark med testresultater er udbredte og problematiske: de har sjældent ændringshistorik, og flere versioner cirkulerer ofte på mail. Find den version, der blev sendt eller godkendt på det relevante tidspunkt, og sikr mailen, den blev sendt med.

Testmiljøet

Testmiljøet er den del, der oftest mangler i dokumentationen, og som modparten oftest angriber. Miljøet bør beskrives med:

Version af den software, der blev testet, helst et build-nummer eller commit-id
Infrastruktur: servere, databaser, kapacitet og netværk, sammenlignet med produktion
Konfiguration: indstillinger, funktionsflag og integrationer, der var slået til eller fra
Integrationer: om eksterne systemer var rigtige, testudgaver eller simuleret
Tidspunkt for opsætning og ændringer i perioden, hvor testen kørte

Et testmiljø, der er ændret under testperioden, kan forklare, hvorfor samme test først fejlede og siden bestod, eller omvendt. Miljøets egne logs og konfigurationshistorik kan vise det. Er miljøet stadig til stede, bør det sikres som beskrevet i leverancens tilstand på overdragelsestidspunktet, før det ryddes eller genbruges.

Testdata

Testdata påvirker resultatet mere, end man skulle tro:

Mængde. En funktion, der virker med hundrede poster, kan fejle med en million. Testdata i lille skala siger lidt om ydeevne.
Kvalitet. Rene, syntetiske data afslører ikke fejl, der opstår med migrerede data med mangler og særtilfælde.
Anonymisering. Anonymiserede produktionsdata kan miste netop de egenskaber, der fremkalder en fejl, fx særlige tegn eller sammenhænge mellem poster.
Tilstand. Mange tests forudsætter en bestemt tilstand i databasen. Er tilstanden ikke dokumenteret, kan testen ikke gentages.

Testdata bør sikres sammen med resultaterne, med hashværdi. Indeholder de persondata, skal sikringen og den videre håndtering tilrettelægges derefter.

Sikring

Eksportér testplaner, testcases og testkørsler fra testværktøjet med historik og vedhæftede filer, fx skærmbilleder og optagelser.
Sikr fejlrapporterne med fuld ændringshistorik, se ticket-systemer: ændringshistorik.
Sikr regneark og dokumenter i deres oprindelige format, med de mails, de blev sendt eller godkendt med.
Dokumentér testmiljøet: versioner, konfiguration og infrastruktur, og tag snapshots eller eksporter, hvor det er muligt.
Sikr testdata og eventuelle scripts, der opretter dem.
Hash alle filer, og registrér kilde, metode og tidspunkt.

Fortolkning

Ved gennemgangen af testdokumentation går disse spørgsmål igen:

Var det den leverede version, der blev testet? Testlogs uden versionsangivelse er svage. Tidspunktet kan nogle gange kobles til udrulningshistorikken for testmiljøet.
Hvad betyder “bestået med bemærkning”? Mellemkategorier skal læses mod testplanens kriterier, ikke mod værktøjets standardværdier.
Genkørsler. En test, der fejlede og senere bestod, kan skyldes en rettelse, et ændret miljø eller en ændret testcase. Historikken skal vise hvilken.
Blokerede og ikke udførte tests. En høj beståelsesprocent kan dække over, at mange tests aldrig blev kørt.
Hvem testede? Test udført af leverandøren og test udført af kunden kan give forskellige resultater af gode grunde, fx forskellige data eller arbejdsgange. Forskellen er i sig selv en oplysning, der bør undersøges, ikke bortforklares.

Fejlrapporternes klassifikation og lukning er behandlet i fejllister og fejlklassifikation.

Brugertest og skærmbilleder

Ved accepttest udført af kundens medarbejdere består dokumentationen ofte af skærmbilleder, korte noter og mails. Skærmbilleder er nyttige, men de viser sjældent version, miljø og tidspunkt. Kan de kobles til applikationens egne logs fra samme tidspunkt, fx via brugerkonto og handling, styrkes de betydeligt. Optagelser af hele forløbet er bedre end enkeltbilleder, fordi de viser de trin, der førte til fejlen. Originalfilerne bør sikres med deres metadata, ikke kun som kopier indsat i et dokument.

Når testen skal gentages

Er en ny test nødvendig i tvisten, fx som led i et skøn, bør den så vidt muligt gentage den oprindelige test i et miljø og med data, der svarer til de oprindelige, så resultaterne kan sammenlignes. Afvigelser fra de oprindelige forhold skal beskrives. En ny test i et andet miljø kan være relevant, men den besvarer et andet spørgsmål: hvordan softwaren opfører sig nu, ikke hvordan den opførte sig ved overtagelsen.

Hvad testdokumentationen kan og ikke kan bevise

Velført testdokumentation med versioner, miljøbeskrivelse og data kan vise, hvordan en bestemt version opførte sig under bestemte forhold på et bestemt tidspunkt. Den kan ikke uden videre vise, hvordan softwaren opførte sig i produktion, og den kan ikke vise mere, end testcases dækkede. Mangler miljø eller version, svækkes værdien betydeligt, men dokumentationen kan stadig indgå sammen med andre kilder. Den juridiske ramme for mangler ved IT-leverancer er beskrevet på digital-bevissikring.dk, og hvordan en virksomhed dokumenterer en klage over en leverance, på bevissikring-digitalt.dk.

Kilder og versioner

Senest gennemgået: oktober 2026.

Næste skridt

Læs også: Kravsporbarhed: fra kravspecifikation til test som bevis · Jira, Azure DevOps og backlog-data: sikring og analyse

→ Uvildig IT-sagkyndig med forensic-baggrund · For IT-afdelingen · Tlf. 70 13 63 23 · Digital bevissikring hos Nielco IT

Skrevet af John Nielsen, IT‑sagkyndig og indehaver af Nielco IT. Selvstændig siden 2009 og mere end 30 års erfaring med IT‑sikkerhed. Har været IT‑sagkyndig i danske retskredse og ved Den Fælles Europæiske Patentdomstol (UPC). Om John Nielsen · LinkedIn · Redaktionel politik