Fejllister og fejlklassifikation i en projekttvist

Forside · Gennemgået oktober 2026 · Af John Nielsen

I mange IT-projekttvister er fejllisten det centrale bevis. Kunden siger, at systemet havde for mange kritiske fejl til at kunne godkendes. Leverandøren siger, at fejlene var små, blev rettet, eller var ændringsønsker forklædt som fejl. Begge parter peger på den samme liste, men læser den forskelligt. Den tekniske gennemgang handler om at finde ud af, hvordan listen er blevet til: hvem registrerede fejlene, hvem satte kategorien, hvornår blev den ændret, og hvad skete der, før en fejl blev lukket.

Hvordan ændringshistorikken trækkes ud af Jira, ServiceNow og lignende, er beskrevet i ticketsystemer og ændringshistorik. Denne artikel handler om analysen af selve fejllisten.

Kategorierne kommer fra kontrakten, ikke fra systemet

Ticketsystemets felter for alvorlighed og prioritet er værktøjets egne. Kontrakten har ofte sin egen definition af fejlkategorier, fx med kategorier for fejl, der forhindrer drift, fejl med væsentlige gener og mindre fejl, og den definition er sjældent identisk med systemets felter. Det første skridt er derfor at oversætte:

Kategori for driftsforhindrende fejl · Fx alvorlighed “Blocker” eller “Kritisk”
Kategori for væsentlige fejl · Fx “Major” eller “Høj”
Kategori for mindre fejl · Fx “Minor”, “Lav” eller “Kosmetisk”

Hvis systemet har både et alvorlighedsfelt og et prioritetsfelt, skal det afklares, hvilket af dem parterne brugte som udtryk for kontraktens kategori. De kan være udfyldt forskelligt i samme sag, og det skaber let to forskellige tællinger af “kritiske fejl”.

En fælles terminologi for klassifikation af fejl findes i IEEE 1044, som skelner mellem observerede afvigelser, deres årsag og deres virkning. Standarden bruges sjældent direkte i danske kontrakter, men den er nyttig, når en skønsmand skal forklare, hvorfor en fejlrapport ikke nødvendigvis svarer til én fejl i koden.

Registreringen: hvem, hvornår og hvordan

For hver fejl bør gennemgangen kunne svare på:

Hvem oprettede sagen, og i hvilken rolle?
Hvornår blev den oprettet i forhold til testfasen, overdragelsen eller godkendelsesfristen?
Er den knyttet til en testcase, et krav eller et miljø?
Er der dokumentation i form af skærmbilleder, logs eller trin til gentagelse?

Mønstre i registreringen kan være vigtige. Mange fejl oprettet på samme dag kort før en godkendelsesfrist kan skyldes en samlet testrunde, men kan også være masseoprettelse fra et regneark. Ændringshistorikken og auditloggen viser, om sagerne er oprettet enkeltvis i brugerfladen eller via import.

Omklassificering

Det mest omstridte er ofte, når en fejl skifter kategori. En kritisk fejl, der nedgraderes til mindre, eller en fejl, der omdøbes til ændringsønske, kan ændre hele billedet af, om leverancen kunne godkendes.

Ændringshistorikken pr. sag viser hver ændring af felterne med tidspunkt og bruger. Gennemgå for hver omklassificering:

Hvem foretog ændringen, og tilhørte personen kunden eller leverandøren?
Var der en begrundelse i en kommentar, i et mødereferat eller i en mail?
Skete ændringen før eller efter en kontraktuel frist?
Blev mange sager ændret samtidigt, fx ved en masseopdatering?

Masseopdateringer er ikke i sig selv mistænkelige. De sker ved oprydning efter et møde. Men de bør kunne kobles til en beslutning, og de bør tælles særskilt, så de ikke forsvinder i en samlet opgørelse.

Lukning og genåbning

En lukket fejl er ikke nødvendigvis en rettet fejl. Statusfeltet kan have værdier som “løst”, “lukket”, “kan ikke genskabes”, “dublet”, “fungerer som tilsigtet” eller “afvist”, og systemer kan være sat op, så flere af dem tæller som afsluttet. Del de lukkede sager op efter løsningstype.

For de sager, der er markeret som rettet, bør det kunne vises:

Hvilken commit eller hvilket build der indeholdt rettelsen.
Hvornår rettelsen blev installeret på det miljø, hvor fejlen blev fundet.
Om fejlen blev gentestet, og af hvem.
Om sagen senere blev genåbnet.

Sammenhængen mellem tickets, commits og testkørsler er beskrevet i CI/CD-logs og testdokumentation. Genåbnede sager er særligt interessante, fordi de viser, at en rettelse ikke holdt.

Dubletter og sammenlægning

Flere rapporter om samme fejl kan blive lagt sammen, og én rapport kan dække flere fejl. Begge dele påvirker optællingen. Gennemgå de sager, der er lukket som dublet, og kontrollér, at de faktisk peger på den samme årsag. Omvendt kan en sag med en lang kommentartråd indeholde flere selvstændige fejl, som kun er registreret én gang.

Fejl eller ændringsønske?

Grænsen mellem fejl og ændringsønske afhænger af, hvad der var aftalt. Den tekniske gennemgang kan ikke afgøre den, men den kan skaffe grundlaget: kravets ordlyd på det tidspunkt, hvor fejlen blev registreret, og eventuelle senere ændringer i kravet. Det kræver sidehistorikken fra wikien eller versionerne af kravdokumentet. Se wiki og kravdokumenter.

Fejl uden for ticketsystemet

Ikke alle fejl ender i ticketsystemet. Under en accepttest registrerer kunden ofte fund i et regneark, en testprotokol eller et mødereferat, og først senere bliver de overført, måske i sammenskrevet form. Sammenhold derfor fejllisten med testprotokollerne fra samme periode. Fund i protokollen, der aldrig blev oprettet som sag, og sager, der ikke kan føres tilbage til en testaktivitet, bør begge opgøres. Er regnearket delt i OneDrive eller SharePoint, kan versionshistorikken vise, hvornår fund blev tilføjet eller fjernet, og af hvem. Det samme gælder supportsager efter idriftsættelse, som kan ligge i et andet system end projektets fejlliste.

Optælling og præsentation

En skønsmand eller en dommer har brug for tal, men tallene skal kunne efterprøves. Lav optællingen fra eksporten, ikke fra systemets dashboards, og angiv for hvert tal:

Den dato, optællingen gælder for, fx overdragelsesdatoen, med fejlenes kategori og status, som de var på det tidspunkt, rekonstrueret fra historikken.
Hvilke statusværdier der tæller som åben og lukket.
Hvilke kategoriværdier der er regnet som kontraktens kategorier.
Hvordan dubletter og omklassificeringer er behandlet.

En tidslinje over antal åbne fejl pr. kategori over hele projektforløbet viser ofte mere end et enkelt tal. Den viser, om fejlniveauet faldt mod overdragelsen, eller om det faldt, fordi sager blev nedgraderet. Hvis parterne er uenige om reglerne for optællingen, kan begge varianter vises side om side.

Fejlkilder

Arbejdsgange, der ændrer sig: felter og statusværdier kan være omdefineret undervejs i projektet. Tjek systemets konfigurationshistorik, hvis den findes.
Slettede sager: sletning fjerner ofte sagen helt fra eksporten. Auditloggen kan vise, at sletning er sket.
Rettigheder: den konto, der eksporterer, ser måske ikke alle sager, fx interne sager hos leverandøren.
Tidszoner: historikken kan være eksporteret i brugerens tidszone, mens kontraktens frister er angivet i dansk tid.

Hvem gennemgår listen

En fejlliste bliver ofte gennemgået af projektets egne folk, som har stærke holdninger til hver enkelt sag. Det er nyttigt for forståelsen, men svækker troværdigheden af optællingen. I en tvist bør optælling og rekonstruktion laves eller efterprøves af en uvildig, mens projektets folk bidrager med forklaringer. Rammerne for syn og skøn i IT-projekter er beskrevet på digital-bevissikring.dk, og en generel indføring i IT-projekttvister findes på digitalbevissikring.dk.

Kilder og versioner

Senest gennemgået: oktober 2026.

Næste skridt

Læs også: Bevaringsplan for et IT-projekt i krise · AI-kodeassistenter i kildekodetvister

→ Uvildig IT-sagkyndig med forensic-baggrund · For IT-projekter i tvist · 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