Zum Inhalt springen

Arbeiten

27 Testbefunde aus einem Beratungsreview, abgearbeitet

Torn StudioKunde: Eine nordische Beratung für digitale Transformation

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.

Zum Namen

Die Beratung hat einer Namensnennung nicht zugestimmt, also beschreibt die Seite sie und lässt den Firmennamen weg. Die Beschreibung ist wahr und reicht, um einzuordnen, woher das Material stammt.

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.

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

27Tickets 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 / 2behoben, 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 / 1Tests 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.
4Tickets, 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.

Belege

Worauf dieser Artikel beruht — eine Messung von uns, eine datierte Quelle oder eine Entscheidung und ihr Preis.

  • Messung

    Wie viele der 27 Tickets bei der Prüfung behoben waren

    Messobjekt: Die Statustabelle im Korrekturplan des KI-Planers

    Methode: Die Statusmarkierungen der Tabelle zählen und die Zeilen auflösen, die mehrere Tickets abdecken.

    Ergebnis: 22 behoben, 3 teilweise, 2 zurückgestellt

  • Entscheidung

    Einen Analysedurchgang über die gesamte Ticketliste fahren, bevor Code geändert wird, und die Tickets nach Ursache gruppieren.

    Was sie gekostet hat: Der Durchgang kostete Zeit, bevor irgendetwas behoben aussah, was gegenüber einem wartenden Auftraggeber schwer zu vertreten ist.

  • Entscheidung

    Der Assistent weist Vorschläge als nicht ausgeführt aus, bis ein Mensch die Schaltfläche drückt.

    Was sie gekostet hat: Jede Änderung braucht nun einen zusätzlichen Klick, und das Objekt muss zuerst ausgewählt sein, was den Ablauf langsamer macht, als das Modell direkt schreiben zu lassen.

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.

Erzählen Sie uns, was Sie bauen wollen

Dreißig Minuten, kostenlos, und eine klare Antwort, ob wir das richtige Studio dafür sind.

Antwort innerhalb eines Tages, ein schriftliches Angebot mit Festpreis innerhalb von drei Tagen, und Sie entscheiden in Ruhe.

Zufriedenheitsgarantie