--- title: "27 testfynd från en konsultgranskning, avverkade" description: "En nordisk konsultbyrå testade en AI-planerare och rapporterade en lång lista brister. Så blev listan 27 ärenden med rotorsak, verifierade mot en körande stack." url: https://torn.studio/sv/arbete/konsultgranskning-27-testfynd locale: sv published: 2026-09-01 updated: 2026-06-25 --- # 27 testfynd från en konsultgranskning, avverkade > **Kort svar:** En nordisk konsultbyrå testade en AI-driven planeringsduk och rapporterade den som opålitlig. Torn Studio gjorde om rapporten till 27 spårbara ärenden, analyserade rotorsakerna före första kodrad, åtgärdade och verifierade mot en körande stack. Vid verifieringen den 25 juni 2026 var 22 åtgärdade, 3 delvis och 2 uppskjutna. **Kund:** En nordisk konsultbyrå inom digital transformation · **Levererat:** 2026-06-25 **Studions relation till kunden:** Byrån är en fristående part som utvärderade planeringsduken i Changemkr, en plattform Torn Studio äger en del av och hade produktrollen i. Studion tog emot byråns underlag och gjorde arbetet som följde. ## Uppdraget En konsult hos byrån hade testat planeringsduken och dess AI-assistent i skarpt läge och sammanfattat resultatet i en presentation. Uppdraget var att göra den berättelsen till något som gick att arbeta av, och att kunna visa vad som faktiskt blev åtgärdat. ## Det som gjorde det svårt - Underlaget var en berättelse om en session i den ordning saker gick fel, med 27 klagomål som kunde vara färre fel eller fler — vilket det var gick inte att se på listan. - Det allvarligaste fyndet var att assistenten skrev att den hade utfört ändringar som aldrig gjordes, vilket gör resten av verktyget oanvändbart oavsett hur många layoutfel som rättas. - Flera ärenden berodde på modellsvar som varierar mellan körningar, så de gick inte att verifiera med ett vanligt test som förväntar sig samma utdata varje gång. ## Siffror som går att räkna efter | Siffror som går att räkna efter | | | | --- | --- | --- | | 27 | ärenden ur ett testunderlag | TP-01 till TP-27 i åtgärdsplanen i repot, var och en med testarens egen formulering och en kopplad rotorsak. | | 22 / 3 / 2 | åtgärdade, delvis, uppskjutna | Räknebart i statustabellen i åtgärdsplanen, daterad 25 juni 2026. Två rader täcker flera ärenden var, vilket är varför 24 rader bär 27 ärenden. | | 11 / 1 | test som passerade och hoppades över | Verifieringsrapporten i repot anger de sju specifikationsfiler som kördes mot stacken och kommandot som kör om dem. | | 4 | ärenden som var produktbeslut | Lyfta ur ärendelistan och avgjorda som beslut i planen, med valet och dess konsekvens utskrivna. De har ingen kodrättning alls. | | 1 | bugg utöver rapporten | Ärende TP-15: en ogiltig omkoppling raderade den befintliga kopplingen. Hittad under åtgärdsarbetet och beskriven i statustabellen. | ## Så gjordes det ### Berättelsen blev spårbara ärenden Presentationens klagomål översattes till 27 numrerade ärenden, TP-01 till TP-27. Varje ärende bär den formulering testaren använde, så att det går att gå tillbaka och läsa vad personen faktiskt såg. Det är den delen som avgör om ett testvarv leder någonstans. ### Analys före första kodrad Ett helt pass gjordes där koden lämnades orörd. Varje ärende kopplades till en bekräftad eller antagen rotorsak, ärenden med gemensam orsak grupperades, och fyra som visade sig vara produktbeslut lyftes ur och avgjordes som beslut. Att gruppera först gör att en rättning stänger flera symtom. ### Det farligaste ärendet först Att assistenten påstod utförda ändringar togs före allt annat, eftersom en användare som blivit lurad en gång slutar lita på nästa svar. Prompten förbjuder numera formuleringen, och gränssnittet visar förslaget som ogenomfört tills en människa trycker på knappen. ### Verifiering mot en körande stack Åtgärderna kördes mot hela stacken i containrar, med Playwright mot webben, affärs-API:et och AI-tjänsten samtidigt. Elva test passerade och ett hoppades över, det sista på grund av en gest som inte går att driva i en huvudlös webbläsare. Rapporten säger vilket och varför. ### Kvarstående brister skrevs ut per ärende Varje rad i rapporten har en kolumn för vad som fortfarande inte är löst. Ett ärende där testarens fall är åtgärdat men en kant kvarstår är märkt delvis, med kanten beskriven. Ett testvarv som redovisas som helt grönt går inte att lita på nästa gång. **Teknik:** Next.js, React Flow, FastAPI, LangGraph, Playwright, Podman, PostgreSQL ## Vad beviset räcker till Det här visar att ett spretigt testunderlag går att göra till en plan som går att följa upp per rad. Det visar ingenting om att produkten blev lyckad: två ärenden sköts upp med skäl, tre är delvis åtgärdade med kanten kvar, och de tre stora skapandeflödena kördes aldrig igenom från början till slut eftersom de bygger på modellsvar som varierar. ## Vanliga frågor ### Varför namnges inte byrån? Företaget har inte gått med på att namnges, och då står namnet inte här. Beskrivningen — en nordisk konsultbyrå inom digital transformation — är sann och tillräcklig för att läsaren ska förstå vem underlaget kom från. Den dag ett företag går med på att namnges står namnet där. ### Varför gjordes en analyspass med koden orörd? För att 27 symtom sällan är 27 fel. Gruppering efter rotorsak visar var samma orsak ger flera symtom, så att en rättning stänger flera rader. Passet lyfte också ut fyra ärenden som visade sig vara produktbeslut, och de har ingen kodrättning alls. ### Vad var det allvarligaste fyndet? Att assistenten skrev att den hade utfört ändringar som aldrig gjordes. Ett layoutfel syns och går att arbeta runt, medan ett falskt kvitto får användaren att sluta lita på hela verktyget. Det ärendet togs först, och lösningen är både en promptregel och en synlig märkning i gränssnittet. ### Vad betyder delvis åtgärdad i rapporten? Att fallet testaren rapporterade fungerar, medan en angränsande kant kvarstår. Rapporten beskriver kanten på raden. Märkningen finns för att ett testvarv som redovisas som helt grönt gör nästa varv värdelöst — den som läser rapporten måste kunna se var gränsen går. ### Hur lång tid tog varvet? Mottagande, analys, åtgärd och verifiering låg inom juni 2026, med verifieringsrapporten daterad den 25 juni. Det är takten en person med AI-verktyg håller på ett avgränsat underlag där ärendena redan är beskrivna av någon som använt produkten. ### Går ett sådant här varv att köpa? Ja. Det ligger under Product Management när underlaget är användarrapporter som ska bli en prioriterad plan, och under AI och automation när felen sitter i ett AI-lager. Studion sätter fast pris på varvet efter att ha läst underlaget.