Sherlock ist ein KI-gestützter Testassistent, der Mitarbeitenden in Fachbereichen hilft, normgerechte Testfälle nach ISO 29119 zu erstellen. Er läuft auf MUCGPT, dem eigenen GPT-Abzug der Landeshauptstadt München. Fachleute ohne Testwissen beschreiben ihre Anwendung, Sherlock generiert strukturierte Testfälle mit Vorbedingungen, Testschritt und erwartetem Ergebnis, die sich direkt in Tools wie TestLink oder Jira X-Ray importieren lassen.
Das Wichtigste in Kürze
- Fachbereichsmitarbeiter haben tiefes Domainwissen, aber kaum Testwissen: Sherlock setzt genau dort an und ermöglicht normgerechte Testfälle nach ISO 29119 ohne vorherige Testing-Schulung.
- Prompt Engineering ist der entscheidende Erfolgsfaktor: Wer Sherlock die Rolle “Testanalyst” zuweist, bekommt Grenzwertanalysen und Äquivalenzklassen, wer es nicht tut, landet in der Mathematik.
- Sherlock exportiert fertige Testfälle als XML für TestLink oder als CSV für X-Ray, sodass Fachbereichsmitarbeiter die Ergebnisse direkt importieren können, ohne manuell zu tippen.
- Watson, das Gegenstück zu Sherlock, generiert aus eingegebenen Testdaten automatisch einen ersten Testbericht auf Basis einer bestehenden Vorlage der Landeshauptstadt München.
- MUCGPT hat kein internes Wissen über die Landeshauptstadt München, daher müssen Nutzer Fachspezifikationen oder Systemdokumente manuell in den Chat laden, bis ein RAG-Anschluss realisiert ist.
Warum Fachbereiche an der Testfallerstellung scheitern
Fachbereiche bringen tiefes Domainwissen mit, aber kaum Testwissen. Genau diese Lücke macht das Schreiben von Testfällen für sie schwierig. Sie kennen ihre Anwendung im Detail, stehen aber vor einem weißen Blatt, sobald daraus strukturierte Testfälle werden sollen.
Im technischen Bereich sieht das anders aus. Wer den Softwareentwicklungsprozess kennt, weiß auch, wie ein Testfall aufgebaut ist. Je näher man aber an die Fachbereiche rückt, desto größer wird der Abstand zum Testhandwerk.
Der naheliegende Weg, alle Beteiligten zu schulen, scheitert oft an der Realität. Schulungen kosten Zeit und Geld, und Fachbereichsmitarbeiter haben ein Tagesgeschäft zu erledigen. Testen läuft nebenher. Ein Foundation Level lässt sich nicht flächendeckend über eine Organisation kippen, in der hundert Projekte pro Jahr umgesetzt werden.
Ein KI-Testassistent als Einstiegshilfe statt als Ersatz
Die Landeshauptstadt München begegnet dieser Lücke mit Sherlock, einem Testassistenten auf Basis ihres eigenen GPT-Abzugs MUCGPT. Sherlock erstellt Testfälle nach der ISO-Norm 29119 und dient Fachbereichen als Einstiegspunkt ins Testen.
Der Ablauf ist bewusst dialogisch gehalten. Wer Sherlock fragt, wer er ist, bekommt eine Antwort samt Beispiel-Testfall. Daran erkennen Fachanwender, wie ein normgerechter Testfall überhaupt aussieht, und beginnen dann selbst zu iterieren: einen Testfall für eine bestimmte Funktion anfordern, nachschärfen, wiederholen.
Sherlock liefert das Format gleich mit. Vorbedingung, Testschritt, erwartetes Ergebnis und Nachbedingung sind nach Norm vorstrukturiert. Der Name ist Programm. Sherlock ist der Ermittler mit der Lupe, der untersucht und Testfälle erstellt.
Wichtig bleibt die Rollenverteilung. Die KI ist Assistent, der Mensch bleibt Entscheider. Ob ein generierter Testfall übernommen oder verfeinert wird, entscheidet der Fachbereich.
Output ist nur so gut wie der Input
Ein Testassistent ohne Kontext liefert generische Ergebnisse. MUCGPT kennt die Stadt München bislang nicht, deshalb muss man ihm für ein konkretes Fachverfahren erst die Fach- oder Systemspezifikation mitgeben. Innerhalb dieses Chats kann er dann passende Testfälle erstellen.
Fehlt dieser Kontext, erfindet das Modell. Eine Frage nach der Organisationsstruktur der Landeshauptstadt München liefert zwar eine Antwort, aber nicht zwingend die richtige. Wer Sherlock nutzt, sollte das einkalkulieren und die Ergebnisse fachlich prüfen.
Eine Anbindung an Retrieval-Augmented Generation ist geplant. Damit könnten Fachbereiche eigene Daten, Fachkonzepte, Systemspezifikationen und User Stories einspeisen sowie interne Intranet-Seiten anschließen, statt Spezifikationen manuell in den Chat zu kopieren.
KI ist nicht deterministisch, und das ist nutzbar
Wer fünfmal denselben Prompt eingibt, bekommt nicht fünfmal denselben Testfall. Das liegt in der Natur der Sache, denn ein KI-Modell variiert seine Ausgaben.
Statt dagegen anzukämpfen, lässt sich die Variation produktiv nutzen. Fordere gleich mehrere Testfälle auf einmal an, etwa fünf, und sichte sie gemeinsam. So erkennst du schnell, welche Varianten passen, und kannst von dort aus feinjustieren.
Prompt Engineering ist die eigentliche Schlüsselkompetenz
Vor dem Tool steht das Prompten. In den Schulungen der Landeshauptstadt München beginnt die Arbeit mit Sherlock nicht beim Assistenten selbst, sondern beim Prompt Engineering.
Die mitgegebene Rolle entscheidet über das Ergebnis. Bekommt das Modell die Rolle Testanalyst, kennt es Grenzwertverfahren und Äquivalenzklassenanalyse. Ohne diese Rolle landet eine Frage nach dem Grenzwert in der Mathematik statt im Test.
Genau das macht Sherlock greifbar: ein Systemspezialist für eine bestimmte Aufgabe. Neben der Rolle zählen Kontext, Hintergrundinformationen und Formatierungsvorgaben. Die Formatierung nach ISO-Norm bringt Sherlock bereits mit.
Der Medienbruch zum Testmanagement-Tool bleibt eine Hürde
Die generierten Testfälle müssen ins Testmanagement-Tool, und genau hier entsteht für Fachanwender neuer Reibungsverlust. Bei der Landeshauptstadt München gibt es drei gesetzte Tools: TestLink als Open-Source-Produkt, X-Ray aus der Jira-Welt und den SAP Solution Manager.
Sherlock exportiert für TestLink eine importierbare XML-Datei und für X-Ray eine CSV-Datei. Aktuell liegt das Limit bei maximal zehn Testfällen pro Import. Der SAP Solution Manager ist noch nicht angebunden.
Für Fachanwender ist schon das Tool selbst eine Hürde. Wo finde ich meine Testfälle? In TestLink stehen sie unter Testspezifikation, weil das Tool sie so nennt. Der automatische Import nimmt diesen Schritt ab, weil die Fachanwender die Testfälle nicht mehr selbst schreiben oder eintragen müssen.
Die Grenze von zehn Testfällen hat einen technischen Grund. Je nach Modell gilt eine maximale Token-Ausgabelänge, ab der die Ausgabe abgeschnitten wird.
Watson schreibt den Testbericht
Wo Sherlock ermittelt, dokumentiert Watson. Der zweite Assistent ist in Entwicklung und erstellt aus eingegebenen Kennzahlen automatisch einen Testbericht.
Watson arbeitet mit einem Systemprompt, in den man die relevanten Daten einträgt: Anzahl durchgeführter Testfälle, erfolgreich und fehlgeschlagen, gefundene Bugs mit Nummern und die Projektnummer. Auf Basis einer bestehenden Testberichtvorlage entsteht daraus ein erster Entwurf.
Final ist dieser Entwurf nicht. Die Kerndaten sind aber bereits enthalten, was den Aufwand für den Bericht spürbar senkt.
Anforderungen wachsen aus der Nutzung
Die nützlichsten Funktionen entstehen aus dem Feedback der Fachbereiche, nicht am Reißbrett. Die erste Version lieferte einen einzelnen normgerechten Testfall, doch aus den Fachbereichen kam der Wunsch nach gleich zehn. So entstand die Mehrfachausgabe.
Ein weiterer Schmerzpunkt ist das Erstellen von Fehlerreports. Welcher Tickettyp, welche Felder, wie ausfüllen? Geplant ist deshalb, dass Anwender den Fehler beschreiben, der Assistent die Angaben mappt und das Ticket nach Mantis oder X-Ray importiert.
Konkrete Nutzungszahlen lassen sich derzeit kaum erheben. Rückmeldungen kommen punktuell, etwa über interne Open-Space-Formate. Künftig sollen die Assistenten abonnierbar sein, sodass sich über die Zahl der Abonnenten zumindest die Verbreitung ablesen lässt.
Mehr Eigenverantwortung durch ein Rollen- und Rechtesystem
Bislang mussten Anpassungen an den Assistenten von den Entwicklern des KI-Kompetenzzentrums vorgenommen werden. Mit MUCGPT 2.0 ändert sich das durch ein Rollen- und Rechtesystem.
Künftig ist der fachliche Verantwortliche Owner seines Assistenten. Er kann den Systemprompt ändern, Beispielantworten anpassen und auf Feedback reagieren, ohne jedes Mal zurück zu den Entwicklern zu gehen. Das entlastet das KI-Kompetenzzentrum und verkürzt den Weg von der Idee zur Funktion.
Am Ende ist die KI der Assistent, und der Mensch immer noch der Entscheider. — Mark Menzel
Innovation hängt an Menschen und an einem Enabler
Eine Verwaltung gilt schnell als verstaubt, doch dieses Bild trägt nicht. Treiber sind hier konkrete Menschen, vom KI-Kompetenzzentrum bis zu dual Studierenden, die Themen wie Watson in Abschlussarbeiten umsetzen.
Der eigentliche Enabler war die frühe Entscheidung. Die Landeshauptstadt München installierte ihren MUCGPT bereits im April 2023 und sprang damit auf den Trend auf, statt ihn auszusitzen. Die Akzeptanz ist breit: Vorne dabei sind das Sozialreferat, das Baureferat und das Referat für Bildung und Sport, nicht nur die IT.
Der Maßstab bleibt der Nutzen. Innovation rechtfertigt sich nicht durch sich selbst, sondern durch den Mehrwert, den sie für die Arbeit und die Stadt bringt.
