---
title: "27 Testbefunde aus einem Beratungsreview, abgearbeitet"
description: "Eine nordische Beratung testete einen KI-Planer und meldete eine lange Fehlerliste. So wurden daraus 27 Tickets mit Ursache, geprüft gegen einen laufenden Stack."
url: https://torn.studio/de/arbeiten/beratungsreview-27-testbefunde
locale: de
published: 2026-09-01
updated: 2026-06-25
---

# 27 Testbefunde aus einem Beratungsreview, abgearbeitet

> **Kurze Antwort:** Eine nordische Beratung testete eine KI-gestützte Planungsfläche und meldete sie als unzuverlässig. Torn Studio machte aus dem Bericht 27 nachverfolgbare Tickets, ermittelte die Ursachen vor der ersten Codezeile, behob sie und prüfte gegen einen laufenden Stack. Bei der Prüfung am 25. Juni 2026 waren 22 behoben, 3 teilweise und 2 zurückgestellt.

**Kunde:** Eine nordische Beratung für digitale Transformation · **Übergeben:** 2026-06-25

**Das Verhältnis des Studios zum Kunden:** Die Beratung ist eine unabhängige Partei, die die Planungsfläche in Changemkr bewertet hat — einer Plattform, an der Torn Studio beteiligt ist und in der es die Produktrolle hatte. Das Studio nahm ihr Material entgegen und leistete die anschließende Arbeit.

## Der Auftrag

Ein Berater des Hauses hatte die Planungsfläche und ihren KI-Assistenten im Ernstfall getestet und das Ergebnis in einer Präsentation zusammengefasst. Die Aufgabe war, diese Erzählung in etwas Abarbeitbares zu überführen und zeigen zu können, was tatsächlich behoben wurde.

## Was es schwierig machte

- Das Material war die Erzählung einer Sitzung in der Reihenfolge, in der Dinge schiefgingen, mit 27 Beanstandungen, die weniger Fehler sein konnten oder mehr — was davon galt, war der Liste nicht zu entnehmen.
- Der schwerwiegendste Befund war, dass der Assistent schrieb, er habe Änderungen ausgeführt, die nie geschahen, was den Rest des Werkzeugs unbrauchbar macht, gleich wie viele Layoutfehler behoben werden.
- Mehrere Tickets hingen an Modellausgaben, die zwischen Läufen schwanken, sodass sie sich mit einem gewöhnlichen Test, der jedes Mal dieselbe Ausgabe erwartet, nicht prüfen ließen.

## Zahlen zum Nachzählen

| Zahlen zum Nachzählen | | |
| --- | --- | --- |
| 27 | Tickets aus einem Testdokument | TP-01 bis TP-27 im Korrekturplan des Repositorys, jedes mit der eigenen Formulierung des Testers und einer zugeordneten Ursache. |
| 22 / 3 / 2 | behoben, teilweise, zurückgestellt | In der Statustabelle des Korrekturplans zählbar, datiert auf den 25. Juni 2026. Zwei Zeilen decken je mehrere Tickets ab, weshalb 24 Zeilen 27 Tickets tragen. |
| 11 / 1 | Tests bestanden und übersprungen | Der Prüfbericht im Repository nennt die sieben Spezifikationsdateien, die gegen den Stack liefen, und den Befehl, der sie erneut ausführt. |
| 4 | Tickets, die Produktentscheidungen waren | Aus der Ticketliste herausgenommen und im Plan als Entscheidungen geklärt, mit ausgeschriebener Wahl und Folge. Sie haben überhaupt keine Codekorrektur. |

## So wurde es gemacht

### Aus der Erzählung wurden nachverfolgbare Tickets

Die Beanstandungen der Präsentation wurden in 27 nummerierte Tickets übersetzt, TP-01 bis TP-27. Jedes trägt die Formulierung des Testers, sodass jeder zurückgehen und lesen kann, was die Person tatsächlich sah. Genau dieser Teil entscheidet, ob eine Testrunde irgendwohin führt.

### Analyse vor der ersten Codezeile

Ein ganzer Durchgang lief mit unberührtem Code. Jedes Ticket wurde einer bestätigten oder vermuteten Ursache zugeordnet, Tickets mit gemeinsamer Ursache gruppiert, und vier, die sich als Produktentscheidungen erwiesen, herausgenommen und als Entscheidungen geklärt. Erst zu gruppieren ist das, was eine Korrektur mehrere Symptome schließen lässt.

### Das gefährlichste Ticket zuerst

Die Behauptung ausgeführter Änderungen wurde vor allem anderen angegangen, weil ein einmal getäuschter Nutzer auch der nächsten Antwort nicht mehr traut. Der Prompt verbietet die Formulierung nun, und die Oberfläche zeigt den Vorschlag als nicht ausgeführt, bis ein Mensch die Schaltfläche drückt.

### Prüfung gegen einen laufenden Stack

Die Korrekturen liefen gegen den gesamten Stack in Containern, mit Playwright auf Web-App, Geschäfts-API und KI-Dienst zugleich. Elf Tests bestanden, einer wurde übersprungen, der letzte wegen einer Geste, die kein Browser ohne Anzeige ausführen kann. Der Bericht nennt welcher und warum.

**Technik:** Next.js, React Flow, FastAPI, LangGraph, Playwright, Podman, PostgreSQL

## Was dieser Beleg trägt

Das zeigt, dass sich ein weitläufiges Testmaterial in einen Plan überführen lässt, der sich Zeile für Zeile nachhalten lässt. Über einen Produkterfolg sagt es nichts: zwei Tickets wurden begründet zurückgestellt, drei sind teilweise behoben mit verbliebenem Randfall, und die drei großen Erstellungswege wurden nie durchgängig gefahren, weil sie an schwankender Modellausgabe hängen.

## Häufige Fragen

### Warum wird die Beratung nicht genannt?

Das Unternehmen hat einer Namensnennung nicht zugestimmt, und dann steht der Name hier nicht. Die Beschreibung — eine nordische Beratung für digitale Transformation — ist wahr und reicht, damit Sie verstehen, woher das Material stammt. An dem Tag, an dem ein Unternehmen zustimmt, steht der Name dort.

### Warum lief die Analyse mit unberührtem Code?

Weil 27 Symptome selten 27 Fehler sind. Die Gruppierung nach Ursache zeigt, wo eine Ursache mehrere Symptome erzeugt, sodass eine Korrektur mehrere Zeilen schließt. Der Durchgang nahm außerdem vier Tickets heraus, die sich als Produktentscheidungen erwiesen und gar keine Codekorrektur haben.

### Was war der schwerwiegendste Befund?

Dass der Assistent schrieb, er habe Änderungen ausgeführt, die nie geschahen. Ein Layoutfehler ist sichtbar und umgehbar, während eine falsche Bestätigung dazu führt, dass ein Nutzer dem ganzen Werkzeug nicht mehr traut. Dieses Ticket kam zuerst, und die Lösung ist eine Prompt-Regel und eine sichtbare Kennzeichnung in der Oberfläche.

### Was heißt teilweise behoben im Bericht?

Dass der vom Tester gemeldete Fall funktioniert, während ein angrenzender Randfall bleibt. Der Bericht beschreibt diesen Randfall in der Zeile. Die Kennzeichnung gibt es, weil eine als vollständig grün gemeldete Runde die nächste wertlos macht — wer den Bericht liest, muss sehen, wo die Grenze verläuft.

### Wie lange dauerte die Runde?

Annahme, Analyse, Korrektur und Prüfung lagen im Juni 2026, der Prüfbericht ist auf den 25. datiert. Das ist das Tempo, das eine Person mit KI-Werkzeugen bei abgegrenztem Material hält, in dem die Tickets bereits von jemandem beschrieben sind, der das Produkt benutzt hat.
