Qualitätsberichte mit GenAI

Qualitätsberichte mit GenAI

0:00 Beim Stichwort Qualitätsberichterstattung denken die meisten an Dashboards und Release-Zusammenfassungen. Doch Berichterstattung beginnt viel früher — nämlich bei der Qualität der Informationen, die überhaupt ins System kommen. Und der uneinheitlichste Punkt dabei ist der Eingang einer Fehlermeldung. In diesem letzten Modul gehen wir den Weg von dort bis zum Release-Fazit: von der unklaren Meldung über die automatisierte Triage bis zu einem Bericht, der eine Frage beantwortet, die zählt — ist dieses Release gesund oder riskant?

Defekte triagieren und kategorisieren

0:29 Fangen wir ganz vorn an, beim Eingang. Eine Fehlermeldung kann aus fünf Richtungen kommen und in fünf Qualitäten — und bevor jemand entscheidet, was damit passiert, muss sie erst einmal verstanden werden. Genau diese Verstehensarbeit kostet Teams erstaunlich viel Zeit, und sie ist der Punkt, an dem sich die Qualität aller späteren Berichte entscheidet.

0:49 Denn was hier unstrukturiert hereinkommt, lässt sich später nicht sinnvoll auswerten. Fehlermeldungen kommen aus der QA, aus der Entwicklung, aus Support-Tickets, aus dem Monitoring — oder als Screenshot ohne einen Satz Erklärung. Manche sind vorbildlich, andere unvollständig, doppelt oder falsch einsortiert. Und wenn das oft passiert, verbringt ein Team einen erstaunlichen Teil seiner Zeit damit, überhaupt zu verstehen, worum es geht.

1:16 Genau hier setzt die KI an — nicht als Entscheider, sondern als Triage-Assistenz. Das Bild dazu: Sie ist die Aufnahme in der Notfallambulanz. Sie erfasst, ordnet vor, kennzeichnet Lücken. Behandelt wird woanders. Diese vier Felder haben unterschiedliches Gewicht. Das Extrahieren von Feldern ist Fleißarbeit und schnell erledigt.

1:37 Der Schweregrad ist interessanter — hier kommt es auf ein Wort an: mit Begründung. Ein Label allein bringt nichts, ein Satz wie „hoch, weil der Bezahlvorgang für betroffene Nutzer blockiert ist" ist eine Diskussionsgrundlage. Die Kategorisierung beschleunigt vor allem das Weiterleiten. Und das vierte Feld ist das, was Menschen am schlechtesten können: Dubletten über Bedeutung finden.

2:00 Dieselbe Störung wird in fünf verschiedenen Formulierungen gemeldet — Stichwortsuche findet das nie, ein Sprachmodell schon. Worauf es hier ankommt, ist die Art der Frage. „Ist dieser Fehler kritisch?" liefert ein Wort, dem Sie nicht ansehen, wie es zustande kam. Der bessere Auftrag verlangt vier Dinge auf einmal: Felder extrahieren, Lücken benennen, Schweregrad vorschlagen — und begründen, mit Belegen aus der Meldung selbst.

2:26 Diese Begründung ist Ihr Prüfmittel. Wenn das Modell nicht erklären kann, woraus es seinen Vorschlag ableitet, dürfen Sie ihn getrost verwerfen. Und der letzte Halbsatz ist der wichtigste: nichts selbst schließen. Vorschlagen ja, entscheiden nein. Das Prinzip dieser Gegenüberstellung ist einfach und trotzdem leicht zu verletzen: Jede Zeile links ist eine Information, jede Zeile rechts eine Handlung.

2:50 Vorschläge kosten nichts und lassen sich prüfen. Handlungen verändern den Zustand — und wenn sie falsch waren, merkt es oft niemand. Am deutlichsten wird das beim Dublettenfall: Ein Kandidat mit Begründung ist hilfreich. Eine automatisch geschlossene Meldung, die in Wahrheit ein anderer Fehler war, ist schlicht verloren.

3:09 Ziehen Sie diese Grenze bewusst, bevor Sie automatisieren — danach ist es schwerer. Nehmen Sie eine der schlechteren Meldungen aus Ihrem Ticketsystem — jedes Team hat davon reichlich. Die Fähigkeit, die Sie hier üben, ist das Umwandeln von Unklarheit in eine prüfbare Struktur. Ihr Ergebnis nennt drei Dinge: die Kernfelder, die fehlenden Angaben und eine belegte Schweregrad-Empfehlung. Achten Sie besonders auf den mittleren Punkt.

3:35 Zu wissen, was fehlt, ist im Alltag oft wertvoller als jede Einschätzung — denn es sagt Ihnen, welche Rückfrage Sie stellen müssen, statt das Ticket zwei Wochen liegen zu lassen. Der erste Punkt ist der ernsteste des ganzen Moduls: Fehlermeldungen enthalten Logs, Screenshots, Stacktraces, URLs — und darin stecken Kundendaten, Tokens und interne Architekturdetails.

3:57 Was hier verarbeitet wird, gehört ausschließlich in freigegebene Werkzeuge. Der zweite Punkt ist Ihr Qualitätsfilter: Eine Empfehlung ohne Begründung ist keine Empfehlung. Und der dritte betrifft die Form — KI-generierte Fehlerberichte neigen zur Ausführlichkeit. Ein guter Bericht ist aber kein Aufsatz. Er soll jemandem helfen, den Fehler nachzustellen und zu beheben. Kürze ist hier ein Qualitätsmerkmal.

Triage automatisieren

4:23 Was wir eben von Hand gemacht haben, lässt sich verankern — direkt im Ticketsystem, ausgelöst in dem Moment, in dem eine Meldung entsteht. Das ändert mehr, als es zunächst klingt: Die Einschätzung liegt vor, bevor jemand das erste Mal draufschaut, und sie liegt in einer Form vor, die sich später auswerten lässt. Schauen wir uns an, wie so eine Automation aufgebaut ist — und wo die entscheidenden Stellschrauben sitzen.

4:47 Die Idee ist unspektakulär und wirkungsvoll: Sobald ein Fehler angelegt wird, läuft eine Automation. Sie sammelt bestehende Meldungen aus demselben Projekt als Referenz, baut daraus zusammen mit dem neuen Fehler einen Prompt, holt die Einschätzung und hängt sie als Kommentar an das Ticket. Der Effekt: Die Triage passiert nicht mehr drei Tage später im Meeting, sondern in dem Moment, in dem die Information noch frisch ist.

5:10 Und die Referenzmeldungen sind der Grund, warum so etwas überhaupt Dubletten finden kann — ohne sie fehlt der Vergleichsmaßstab. Zwei Schritte in dieser Kette verdienen einen zweiten Blick. Der vierte: Temperatur null. Das ist der Regler, der bestimmt, wie viel Variation ein Modell sich erlaubt — und bei einer Automation, die hundertmal am Tag läuft, wollen Sie Konsistenz statt Kreativität.

5:33 Und der Protokollschritt, der in der Liste fast überflüssig wirkt: Für die Triage selbst braucht ihn niemand, beim Einrichten und Fehlersuchen ist er Gold wert. Denn wenn die Ausgabe unerwartet aussieht, wollen Sie sehen, was tatsächlich im Prompt stand. Worauf es hier ankommt, sind nicht die Feldnamen, sondern die erlaubten Werte dahinter.

5:53 „Vorhanden oder fehlend." „Klar, fehlt oder verbesserungswürdig." Erst diese Aufzählung macht die Antwort maschinell auswertbar — und ermöglicht später Auswertungen wie „bei sechzig Prozent unserer Meldungen fehlen die Reproduktionsschritte". Ohne erlaubte Werte formuliert das Modell jedes Mal etwas leicht anderes, und aus hundert Kommentaren lässt sich nichts aggregieren.

6:15 Es ist derselbe Gedanke wie beim Testfall-Export aus Modul drei: Struktur vorgeben schlägt Struktur hinterher herstellen. Diese Übung beginnt nicht beim Werkzeug, sondern bei einer Frage: Warum brauchen Sie Triage überhaupt? Zu viele Meldungen ohne Schweregrad? Unklar, welche Bereiche betroffen sind? Berichte in einem bestimmten Format? Die Antwort bestimmt alles Weitere. Genau das ist die Fähigkeit, die Sie hier üben — vom Bedarf zur technischen Umsetzung, nicht umgekehrt.

6:45 Ihr Entwurf benennt vier Dinge: Auslöser, gesammelte Referenzdaten, Prompt-Struktur und Zielfelder. Wer Zeit hat, probiert das auf einem Übungsboard aus. Die Ernüchterung kommt erfahrungsgemäß beim ersten echten Ticket. Diese drei Punkte fassen das Kapitel zusammen. Ohne erlaubte Werte je Feld bekommen Sie Text, den kein Bericht auswerten kann — die Automation läuft, aber sie erzeugt keine Daten.

7:10 Ohne Referenzmeldungen findet sie keine Dubletten, weil ihr schlicht der Vergleich fehlt. Und der dritte Punkt ist der, der am meisten Zeit spart, wenn man ihn beherzigt: erst den Bedarf klären, dann automatisieren. Eine Automation, die etwas löst, das Sie gar nicht als Problem hatten, erzeugt nur einen weiteren Kommentar, den niemand liest.

Qualitätsberichte und Dashboards

7:31 Im letzten Kapitel gehen wir eine Ebene höher. Wir haben inzwischen alles zusammen: strukturierte Defekte, laufende Tests, Coverage-Werte, geprüfte Pull Requests, Analysebefunde. Nur liegt das alles in verschiedenen Systemen — und aus dieser Sammlung muss eine Aussage werden, mit der jemand tatsächlich entscheiden kann.

7:50 Das ist die Aufgabe der Qualitätsberichterstattung, und damit schließt sich der Kreis dieses Seminars. Das Problem der meisten Teams ist nicht fehlende Daten, sondern verstreute. Testergebnisse liegen im einen System, Defekte im nächsten, Coverage im dritten, Review-Aktivität im vierten. Also schaut jemand hier nach, jemand anders dort, Zahlen wandern in eine Folie, und am Ende diskutiert das Team darüber, ob das Release gesund ist.

8:17 Berichterstattung führt diese Signale zusammen. Wichtig dabei: Die KI erzeugt keine Wahrheit. Die kommt weiterhin aus Tests, Defekten, Analysen und dem Urteil des Teams. Was sie kann, ist zusammenfassen, vergleichen und erklären. Diese vier Fragen sind der Prüfstein für jeden Qualitätsbericht. Wenn Ihr Dashboard sie nicht beantwortet, ist es eine Sammlung von Diagrammen, kein Bericht.

8:41 Beachten Sie die Reihenfolge — sie führt von der Beobachtung zur Handlung. Was hat sich geändert, was ist gescheitert, wo liegt das Risiko, was blockiert, was tun wir als Nächstes? Die letzte Frage ist die, an der die meisten Berichte scheitern. Zahlen zu zeigen ist einfach. Eine Empfehlung auszusprechen verlangt eine Einschätzung — und genau dabei kann die KI erstaunlich gut zuarbeiten.

9:05 Hier steckt der Kern des ganzen Kapitels. „Siebenundachtzig fehlgeschlagene Tests" ist eine Zahl, die niemandem hilft — sie erzeugt Betriebsamkeit, aber keine Richtung. „Die Fehler häufen sich im Checkout, dreiundzwanzig davon gehen auf ein Auth-Timeout zurück" ist eine Aussage, mit der ein Team sofort arbeiten kann. Dasselbe gilt für Coverage: Ein Prozentwert allein beweist nichts, die Zuordnung zu Akzeptanzkriterien schon.

9:31 Merken Sie sich diese Übersetzung als Anspruch an jeden Bericht — vom Wert zur Bedeutung. Alles andere ist Zahlenverwaltung. Der rote Faden hier: aufhören, Zahlen von Hand zu kopieren. Das ist der Schritt, der in vielen Teams eine halbe Person beschäftigt, ohne Erkenntnis zu erzeugen. Interessant ist Schritt vier — Empfehlungen einfordern, aber priorisiert. Eine Liste aller Funde ist wieder nur eine Liste.

9:56 Und der fünfte Schritt öffnet ein Feld, an das man zunächst nicht denkt: die Retrospektive. Ein Modell erkennt Muster über Wochen hinweg — wiederholte Fehlschläge in einer Komponente, wiederkehrende Nacharbeit nach Reviews. Was diese Muster bedeuten, ergänzt das Team. Mustererkennung ist keine Ursachenanalyse. Zum Abschluss die anspruchsvollste Übung des Seminars, weil sie alles zusammenführt.

10:21 Nehmen Sie die Signale, die Ihnen tatsächlich zur Verfügung stehen — Testlage, offene Defekte, Analysebefunde — und verdichten Sie sie zu einer Aussage. Die Fähigkeit dahinter ist Entscheidungsfähigkeit: nicht alles berichten, sondern das, was die Freigabe beeinflusst. Ihr Fazit nennt vier Dinge: Testlage, offene Risiken, blockierende Defekte und eine begründete Empfehlung.

10:43 Genau diese vier Punkte braucht jemand, der am Ende die Freigabe unterschreibt. Der erste Punkt ist die Grenze, die dieses ganze Seminar durchzieht: Die KI darf nicht zur Quelle der Wahrheit werden. Die Daten bleiben in Ticketsystem, Pipeline, Fehlerverwaltung — sonst berichten Sie irgendwann über Zusammenfassungen von Zusammenfassungen.

11:04 Der zweite ist eine alte Kennzahlen-Falle: Coverage allein belegt keine Qualität, sie belegt nur, dass Code durchlaufen wurde. Und der dritte betrifft die Retrospektive: Ohne den Kontext des Teams bleibt eine erkannte Häufung eine Beobachtung. Ob dahinter fehlende Schulung, ein unklarer Standard oder eine schwache Prüfung steckt, wissen nur Menschen.

11:24 Schauen wir zurück auf den Weg. Bei Strategie und Testfällen ging es vor allem um Tempo — schneller zu einem belastbaren Entwurf. Bei Automatisierung und nichtfunktionalen Tests ging es um Zugang: Bereiche, die vorher an fehlender Zeit oder fehlendem Spezialwissen scheiterten, werden machbar. Bei Review und Berichten geht es um Verteilung der Aufmerksamkeit — weniger Mechanik, mehr Urteil.

11:47 Und durch alle sieben Module zieht sich derselbe Satz: Die KI liefert Entwürfe, die QA verantwortet das Ergebnis. Wer diese Rollenverteilung beibehält, gewinnt am meisten und riskiert am wenigsten.

Danke!

11:59 Damit sind wir am Ende. Generative KI beschleunigt die QA-Arbeit spürbar — beim Erzeugen, beim Erkennen von Lücken, beim Übersetzen von Daten in Aussagen. Die Entscheidungen aber bleiben menschlich, und das ist keine Übergangslösung, sondern die sinnvolle Aufteilung. Drei Dinge nehmen Sie mit: Belege einfordern, Kontext geben, Ergebnisse gegenprüfen. Wer das beherzigt, holt aus diesen Werkzeugen mehr heraus als mit jedem Prompt-Trick.

12:26 Die Materialien finden Sie in der Freigabe, bei Fragen erreichen Sie uns unter der genannten Adresse. Vielen Dank für Ihre Aufmerksamkeit.