--- title: "27 testfund fra en konsulentgennemgang, arbejdet af" description: "Et nordisk konsulenthus testede en AI-planlægger og meldte en lang liste fejl. Sådan blev listen 27 sager med rodårsag, verificeret mod en kørende stak." url: https://torn.studio/da/arbejde/konsulentgennemgang-27-testfund locale: da published: 2026-09-01 updated: 2026-06-25 --- # 27 testfund fra en konsulentgennemgang, arbejdet af > **Kort svar:** Et nordisk konsulenthus testede et AI-drevet planlægningslærred og meldte det upålideligt. Torn Studio lavede rapporten om til 27 sporbare sager, fandt rodårsagerne før første kodelinje, rettede og verificerede mod en kørende stak. Ved verificeringen den 25. juni 2026 var 22 rettet, 3 delvist og 2 udskudt. **Kunde:** Et nordisk konsulenthus inden for digital transformation · **Leveret:** 2026-06-25 **Studiets forhold til kunden:** Huset er en uafhængig part, der vurderede planlægningslærredet i Changemkr, en platform Torn Studio ejer en del af og havde produktrollen i. Studiet tog imod deres grundlag og udførte arbejdet, der fulgte. ## Opgaven En konsulent i huset havde testet planlægningslærredet og dets AI-assistent i skarp drift og samlet resultatet i en præsentation. Opgaven var at gøre den fortælling til noget, der kunne arbejdes af, og at kunne vise, hvad der faktisk blev rettet. ## Det der gjorde det svært - Grundlaget var en fortælling om én session i den rækkefølge, tingene gik galt, med 27 klager, der kunne være færre fejl eller flere — hvilket det var, kunne ikke læses af listen. - Det alvorligste fund var, at assistenten skrev, at den havde udført ændringer, der aldrig skete, hvilket gør resten af værktøjet ubrugeligt, uanset hvor mange layoutfejl der rettes. - Flere sager hvilede på modelsvar, der varierer mellem kørsler, så de kunne ikke verificeres med en almindelig test, der venter samme uddata hver gang. ## Tal der kan tælles efter | Tal der kan tælles efter | | | | --- | --- | --- | | 27 | sager fra ét testgrundlag | TP-01 til TP-27 i handlingsplanen i repoet, hver med testerens egen formulering og en koblet rodårsag. | | 22 / 3 / 2 | rettet, delvist, udskudt | Tælleligt i statustabellen i handlingsplanen, dateret 25. juni 2026. To rækker dækker flere sager hver, og derfor bærer 24 rækker 27 sager. | | 11 / 1 | tests bestået og sprunget over | Verificeringsrapporten i repoet nævner de syv specifikationsfiler, der kørte mod stakken, og kommandoen, der kører dem igen. | | 4 | sager der var produktbeslutninger | Løftet ud af sagslisten og afgjort som beslutninger i planen, med valget og dets konsekvens skrevet ud. De har slet ingen kodrettelse. | ## Sådan blev det gjort ### Fortællingen blev sporbare sager Præsentationens klager blev oversat til 27 nummererede sager, TP-01 til TP-27. Hver sag bærer den formulering, testeren brugte, så man kan gå tilbage og læse, hvad personen faktisk så. Det er den del, der afgør, om en testrunde fører nogen steder hen. ### Analyse før første kodelinje En hel runde forløb med koden urørt. Hver sag blev koblet til en bekræftet eller formodet rodårsag, sager med fælles årsag blev grupperet, og fire, der viste sig at være produktbeslutninger, blev løftet ud og afgjort som beslutninger. At gruppere først er det, der lader én rettelse lukke flere symptomer. ### Den farligste sag først At assistenten påstod udførte ændringer blev taget før alt andet, fordi en bruger, der er ført bag lyset én gang, holder op med at stole på næste svar. Prompten forbyder nu formuleringen, og grænsefladen viser forslaget som uudført, indtil et menneske trykker på knappen. ### Verificering mod en kørende stak Rettelserne blev kørt mod hele stakken i containere, med Playwright mod webappen, forretnings-API-et og AI-tjenesten på én gang. Elleve tests bestod, og én blev sprunget over, den sidste på grund af en gestus, ingen hovedløs browser kan drive. Rapporten siger hvilken og hvorfor. **Teknologi:** Next.js, React Flow, FastAPI, LangGraph, Playwright, Podman, PostgreSQL ## Hvad beviset rækker til Dette viser, at et spredt testgrundlag kan gøres til en plan, der kan følges op række for række. Det viser intet om, at produktet blev en succes: to sager blev udskudt med begrundelse, tre er delvist rettet med kanten tilbage, og de tre store skabelsesforløb blev aldrig kørt fra ende til anden, fordi de hviler på modelsvar, der varierer. ## Ofte stillede spørgsmål ### Hvorfor nævnes huset ikke ved navn? Virksomheden har ikke sagt ja til at blive nævnt, og så står navnet ikke her. Beskrivelsen — et nordisk konsulenthus inden for digital transformation — er sand og tilstrækkelig til, at læseren forstår, hvor grundlaget kom fra. Den dag en virksomhed siger ja, står navnet der. ### Hvorfor blev analysen lavet med koden urørt? Fordi 27 symptomer sjældent er 27 fejl. Gruppering efter rodårsag viser, hvor samme årsag giver flere symptomer, så én rettelse lukker flere rækker. Runden løftede også fire sager ud, der viste sig at være produktbeslutninger, og de har slet ingen kodrettelse. ### Hvad var det alvorligste fund? At assistenten skrev, at den havde udført ændringer, der aldrig skete. En layoutfejl er synlig og kan omgås, mens en falsk kvittering får brugeren til at holde op med at stole på hele værktøjet. Den sag blev taget først, og løsningen er både en promptregel og en synlig markering i grænsefladen. ### Hvad betyder delvist rettet i rapporten? At det tilfælde, testeren meldte, virker, mens en tilstødende kant står tilbage. Rapporten beskriver kanten på rækken. Markeringen findes, fordi en runde, der meldes helt grøn, gør næste runde værdiløs — den, der læser rapporten, skal kunne se, hvor grænsen går. ### Hvor lang tid tog runden? Modtagelse, analyse, rettelse og verificering lå inden for juni 2026, med verificeringsrapporten dateret den 25. Det er den takt, én person med AI-værktøjer holder på et afgrænset grundlag, hvor sagerne allerede er beskrevet af en, der har brugt produktet.