Teknisk mangelsvurdering af software: metode for den sagkyndige

Forside · Gennemgået oktober 2026 · Af John Nielsen

En teknisk mangelsvurdering besvarer et snævert spørgsmål: afviger softwaren fra det aftalte, og i givet fald hvorfor og hvor meget? Metoden har fem led: fastlæg kravgrundlaget, fastlæg den version, der vurderes, genskab den påståede fejl under kontrollerede forhold, find årsagen, og vurdér konsekvensen ud fra de kategorier, aftalen bruger. Om afvigelsen er en mangel i juridisk forstand, afgør retten eller voldgiftsretten, ikke den sagkyndige.

Artiklen er skrevet til den, der skal udføre eller efterprøve en teknisk vurdering i en tvist om et IT-projekt. Den juridiske side af mangelsbegrebet er beskrevet på digital-bevissikring.dk.

Spørgsmålet kommer før undersøgelsen

En mangelsvurdering starter med de spørgsmål, den sagkyndige er bedt om at besvare, fx i et skønstema. Et spørgsmål som “er systemet mangelfuldt?” kan ikke besvares teknisk. Et spørgsmål som “opfylder funktionen til månedsafslutning krav 4.2 i kravspecifikationen version 1.3, og hvis ikke, hvad er årsagen?” kan. Er spørgsmålene for brede, bør den sagkyndige sige det tidligt og foreslå en præcisering, frem for selv at vælge en fortolkning. Om formulering af spørgsmål i IT-sager, se syn og skøn i IT-sager.

Led 1: kravgrundlaget

Den tekniske vurdering måles mod et grundlag, og grundlaget skal være entydigt. Typiske kilder:

kravspecifikation og løsningsbeskrivelse i den version, der var gældende på det relevante tidspunkt
godkendte ændringsanmodninger og referater, der ændrer kravene
user stories med acceptkriterier i et agilt projekt
testspecifikationer, hvis aftalen henviser til dem som målestok

Kravdokumenter ændres undervejs, og wikier og ticket-systemer viser den nyeste udgave. Den gældende version skal derfor findes via sidehistorik eller ændringslog, se sidehistorik og kravændringer. Er parterne uenige om, hvilken version der gælder, bør vurderingen udføres mod begge og resultatet angives for hver.

Hvor kravene er tavse, kan generelle kvalitetsbegreber give et sprog for vurderingen. ISO/IEC 25010 beskriver en kvalitetsmodel med karakteristika som funktionel egnethed, ydeevne, pålidelighed, sikkerhed og vedligeholdbarhed. Modellen er et fagligt referencepunkt, ikke en målestok, parterne har aftalt, og det skal fremgå af rapporten.

Led 2: den version, der vurderes

En påstået fejl skal knyttes til en præcis version: et commit-id, et build-nummer eller en udgivelse. Det afgør, om fejlen fandtes i den leverance, der blev overtaget eller afvist, eller først opstod ved en senere ændring. Den sikrede tilstand af kode, builds og miljøer er udgangspunktet, se leverancens tilstand på overdragelsestidspunktet. Har leverandøren rettet fejlen siden, skal både den oprindelige og den rettede version være tilgængelig.

Notér versionsnumre for platform, database, styresystem og afhængigheder. En fejl kan ligge i samspillet mellem en korrekt kode og en ændret komponent.

Led 3: reproduktion

Den stærkeste dokumentation for en fejl er, at den kan genskabes. Det kræver:

et testmiljø, der svarer til det relevante miljø i version og konfiguration
data, der svarer til de data, fejlen optrådte med, eller en anonymiseret kopi med samme egenskaber
en trinvis fremgangsmåde, som en anden kan følge

Hver reproduktion registreres med tidspunkt, miljø, version, input, forventet resultat ud fra kravet og faktisk resultat. Skærmoptagelse og logudtræk fra samme kørsel styrker dokumentationen.

Fejl, der ikke kan genskabes, er ikke dermed afvist. Fejl afhængige af belastning, tidspunkt eller samtidighed kan være svære at fremkalde. Her må vurderingen bygge på produktionens logs, overvågning og fejlrapporter fra perioden, og rapporten skal tydeligt skelne mellem genskabte og ikke genskabte fejl. Data om produktionen på fejltidspunktet bør være sikret, før nogen retter, se sikring af produktion ved påstået fejl.

Led 4: årsagen

Samme symptom kan have mange årsager, og årsagen afgør ofte, hvem afvigelsen kan henføres til. En systematisk årsagsanalyse skelner mellem:

Fejl i leveret kode · Fejlen følger koden på tværs af miljøer og kan peges ud i en bestemt ændring
Konfiguration · Fejlen forsvinder med en anden indstilling, og indstillingens historik viser, hvem der satte den
Data · Fejlen optræder kun med bestemte poster, fx migrerede data
Driftsmiljø · Fejlen afhænger af kapacitet, netværk eller versioner af platformen
Tredjepart · Fejlen ligger i en integration eller komponent uden for leverancen
Brug · Funktionen bruges anderledes end beskrevet i krav og vejledning
Ændret krav · Softwaren gør det, der var aftalt, men ikke det, der senere blev ønsket

Når årsagen er fundet i koden, bør den konkrete ændring identificeres i versionsstyringen, så det kan ses, hvornår fejlen blev indført, og i hvilken leverance den indgik. Om fortolkning af historikken, se kildekode og Git som bevis.

Led 5: konsekvens og kategori

Mange IT-kontrakter og testplaner opdeler fejl i kategorier efter alvor, fx kritisk, alvorlig og mindre. Kategorierne er defineret i aftalen og ikke i værktøjet. Den sagkyndige bør derfor vurdere hver afvigelse mod aftalens egne definitioner og begrunde placeringen med de konkrete konsekvenser: hvilke forretningsgange stopper, findes der en omgåelse, hvor mange brugere eller poster er berørt. Hvordan fejllister omklassificeres og lukkes i ticket-systemet, er beskrevet i fejllister og fejlklassifikation.

Stikprøver ved mange fejl

En fejlliste kan rumme hundredvis af punkter. Gennemgås kun et udvalg, skal udvælgelsen beskrives og begrundes: alle fejl i højeste kategori, en tilfældig stikprøve af resten, eller de fejl, parterne selv har udpeget. Rapporten må kun konkludere om de fejl, der er undersøgt, og bør ikke generalisere fra en stikprøve uden at sige det.

Begge parter skal kunne følge med

Reproduktioner bør så vidt muligt ske, så begge parter kan være til stede eller få samme materiale bagefter: version, testdata, fremgangsmåde og resultat. En vurdering, som kun den ene part har kunnet se udført, er lettere at anfægte, også selv om den er korrekt. Det gælder særligt, når testmiljøet stilles til rådighed af en af parterne, og konfigurationen derfor bør kontrolleres og registreres, før arbejdet begynder.

Typiske fejlkilder

Vurderingen sker mod den nyeste kravversion i stedet for den gældende.
Fejlen genskabes i et miljø med en anden version end den leverede.
En fejl i en integration tilskrives systemet, fordi symptomet ses dér.
Kategorien fra ticket-systemet overtages uden selvstændig vurdering.
Fejl rettet efter overtagelsen tælles med, uden at det fremgår.
Konklusioner om kvalitet generelt drages fra enkelte fund.

Dokumentation

Rapporten bør for hver vurderet afvigelse angive kravet med version og kilde, softwareversionen, fremgangsmåden ved reproduktion med resultat, den fundne årsag og begrundelsen for kategorien. Hertil kommer en beskrivelse af testmiljø, data og værktøjer, så en anden sagkyndig kan gentage vurderingen. Alt, der ikke er undersøgt, nævnes som en begrænsning.

En uvildig IT-sagkyndig kan vurdere de tekniske spørgsmål og skelne mellem det, der er påvist, og det, der er sandsynliggjort. Se uvildig IT-sagkyndig med forensic-baggrund og IT-skøn i tvister om IT-projekter.

Kilder og versioner

Senest gennemgået: oktober 2026.

Næste skridt

Læs også: SBOM og byggeartefakter som dokumentation · Kravsporbarhed: fra kravspecifikation til test som bevis

→ 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