---
{
  "title": "Agentic Testing: Vom Bug-Report zum Testbericht in 10 Minuten",
  "description": "Bug-Report → vollständiger Testbericht in 10 Minuten. Erfahren Sie, wie LLM-Agenten Fehler reproduzieren, Tests generieren und Aidbox automatisch validieren.",
  "date": "2026-03-04",
  "author": "Marat Surmashev",
  "reading-time": "10 minutes",
  "tags": [
    "Infrastructure",
    "AI / Agents"
  ]
}
---
Was wäre, wenn der Zyklus von einem Bug-Report bis zu einem vollständigen Testbericht mit Testfällen 10 Minuten statt mehrerer Stunden dauern würde? Wir haben diesen Ansatz bei [Aidbox](https://www.health-samurai.io/aidbox) ausprobiert – und er hat funktioniert.

In einem [früheren Beitrag](https://www.health-samurai.io/articles/agentic-coding-on-fhir-building-dashboards) haben wir [Agentic Coding](/blog/agentic-coding-on-fhir-building-dashboards) beschrieben und erläutert, wie LLMs beim Aufbau von Anwendungen auf Basis von FHIR helfen. Coding ist jedoch nur ein Teil des Produktlebenszyklus. Wir sind einen Schritt weiter gegangen und haben begonnen, LLM-Agenten in die Test- und Supportprozesse für Aidbox zu integrieren.

Unser erster Schritt war BugBot. Er prüft Pull Requests und erkennt potenzielle Probleme im Code. Er bewertet Code zuverlässig, und wir sind damit zufrieden. BugBot betrachtet einen isolierten PR oder Commit jedoch aus der Perspektive eines Programmierers. Er sieht nicht das Gesamtbild. Aufgabenkontext, Konformität mit Spezifikationen und End-to-End-Verhalten können ihm entgehen.

Dies warf eine grundlegendere Frage auf: Können LLMs nicht nur beim Schreiben von Code helfen, sondern auch bei der Pflege und Weiterentwicklung des Produkts als Ganzes?

## Warum das Testen eines komplexen Produkts so aufwendig ist

Aidbox ist ein umfangreiches Produkt mit einer großen Codebasis und einer komplexen FHIR-Domäne, die Such-APIs, Validierung und Terminology-Verarbeitung, Sicherheit und Performanceaspekte umfasst. Manchmal kostet allein das Reproduzieren eines Fehlers oder einer Kundenanfrage enorm viel Zeit. Beispiele:
- Validierung gegen einen bestimmten Satz von Profilen und IGs
- Ausführung von FHIR-Suchen auf spezifischen Daten
- Testen der Integration mit einem externen Dienst

Nicht jeder Fehler oder jede Anfrage erfordert eine so detaillierte Reproduktion, aber weitaus zu viele Aufgaben beanspruchen unverhältnismäßig viel Zeit.

Nach der Implementierung eines Features oder der Behebung eines Fehlers muss beim Testen nicht nur die Korrektheit des Codes geprüft werden, sondern auch die Konformität mit der FHIR-Spezifikation, die Genauigkeit der Dokumentation, das Verhalten in Grenzfällen und die Sicherheit (XSS, SQL-Injection usw.). Unit-Tests helfen, Regressionen zu verhindern, sind aber kein Ersatz für eine umfassende Validierung. End-to-End-Tests bleiben notwendig und zeitintensiv.

## Unser Ansatz: Agentic Testing

Wir haben einen GitHub-Bot entwickelt, der die Aufgabenbewertung und das Testen übernimmt. Wir nennen ihn `[Agentic](/blog/agents-are-not-humans) Testing`.

Der Bot hat zwei zentrale Aufgaben:
- **Bewertung eingehender Anfragen**: Reproduzieren und Bestätigen von Fehlern oder Kundenanfragen, Erstellen eines Testplans, Analysieren von Code und Empfehlen von Korrekturen.
- **Verifizierung von Aufgaben**: Analyse von PRs und Commits im Kontext, Generierung von Grenzfalltests, deren Ausführung sowie Überprüfung der Dokumentationsgenauigkeit.

Wenn eine Aufgabe im `Inbox`-Status ohne verknüpfte Commits eingeht, versucht der Bot, das Problem selbstständig zu reproduzieren. Handelt es sich wirklich um einen Fehler oder um ein erwartetes Verhalten? Er gleicht dies mit der Aidbox-Dokumentation und der FHIR-Spezifikation ab.

Wenn die Aufgabe bereits einen verknüpften PR hat und den Status `QA` trägt, analysiert der Bot die Codeänderungen, generiert Grenzfalltests und führt diese aus.

In beiden Fällen erfolgt das Testen als Black-Box-API-Tests:
- Der Bot startet eine Aidbox-Instanz basierend auf der Aufgabe oder den Codeänderungen.
- Er führt Anfragen sequenziell aus und vergleicht die Ergebnisse mit den erwarteten Ergebnissen.
- Wenn die Aufgabe unterschiedliche FHIR-Versionen oder konfigurierbare Sätze von Konfigurationen und Profilen vorgibt, startet der Bot mehrere Aidbox-Instanzen und führt Tests über diese hinweg aus.
- Er erstellt einen Testbericht.

Während der Bot eine Aufgabe reproduziert, analysiert er auch den Code und schlägt vor, wo und warum das Problem auftreten könnte. Für den Entwickler bedeutet das: Wenn er mit der Fehlerbehebung beginnt, liegen bereits Reproduktionsschritte und ein grober Hinweis auf die Ursache vor.

Die Fähigkeit umfasst etwa 500 Zeilen Markdown. Sie enthält keine Anwendungslogik, nur Anweisungen. Dies sind dieselben Anweisungen, die Sie in einem internen Wiki für ein neues Teammitglied verfassen würden – einschließlich der Einrichtung der Umgebung, der Lokalisierung des Codes, der Ausführung von Tests und der Formatierung des Berichts. Claude Code übernimmt den Rest: das Nachdenken über Grenzfälle, das Zusammenstellen von Anfragen und die Interpretation von Antworten.

## Wie der Bot entscheidet, was ein Fehler ist

Bei der Arbeit mit dem Bot stießen wir auf eine zentrale Frage: Was gilt als Fehler?

Beispiel: Es ging eine Anfrage ein, dass die FHIR-Suche in Aidbox nicht korrekt funktioniere. Der Bot reproduzierte und bestätigte das Problem. Eine weitergehende Analyse zeigte jedoch, dass Aidbox tatsächlich korrekt gearbeitet hatte – in vollständiger Übereinstimmung mit der FHIR-Spezifikation.

Der Bot verwendet die Aidbox-Codebasis, die Dokumentation und die FHIR-Spezifikation als Kontext. Bei einer Entscheidung prüft er zunächst gegen die Dokumentation und die Spezifikation. Wir haben eine Regel festgelegt: Ein Fehler ist ein Aidbox-Verhalten, das von der FHIR-Spezifikation abweicht **und nicht in der Aidbox-Dokumentation beschrieben ist.**

Wir haben dem Bot-Kontext außerdem OWASP-Richtlinien hinzugefügt, damit er potenzielle Schwachstellen und Sicherheitsprobleme erkennen kann.

## LLM-Einschränkungen und Halluzinationen

LLMs sollten nicht für bare Münze genommen werden. Halluzinationen kommen vor. Der Bot kann eine Aufgabe missverstehen und beginnen, etwas völlig anderes zu testen als vom Autor beabsichtigt. Insbesondere dann, wenn die Aufgabe schlecht formuliert ist oder Fehler enthält.

Um dem zu begegnen, haben wir die Möglichkeit hinzugefügt, mit Klarstellung erneut zu testen. Sie „rufen" den Bot einfach in einem Aufgabenkommentar mit dem Befehl `\qa` auf und geben an, was genau geprüft werden soll. Manchmal fehlen in der eingehenden Anfrage Details: Die FHIR-Version ist nicht angegeben, die Aidbox-Version fehlt, oder das Verhalten muss über mehrere Konfigurationen hinweg verifiziert werden. All das lässt sich klären, und der Bot startet die entsprechenden Instanzen, erstellt die notwendigen Ressourcen, lädt die erforderlichen IG-Versionen, führt die Tests durch und erstellt einen konsolidierten Bericht.

## Nicht besser, sondern mehr und schneller

Der Bot tut nichts Außergewöhnliches im Vergleich zu einem QA-Ingenieur. Er macht es nicht besser – er macht es mehr und schneller.

Ein aktuelles Beispiel veranschaulicht dies. Im Januar-Release von Aidbox wurde ein Fehler mit der minimalen Kardinalität von FHIR-Profilen gefunden. Ein Pflichtfeld wurde durch die Bedingung `element.min == 1` bestimmt, obwohl Profile `min` gleich 2, 3 und so weiter angeben können. Die Korrektur war buchstäblich eine Änderung eines einzelnen Zeichens: Ersetzen von `min == 0` durch `min >= 1`.

Ein Entwickler kann den Diff überfliegen und feststellen, dass die Korrektur korrekt ist. Dennoch möchten wir gründlich validieren. Unit-Tests decken die Hauptfälle ab, aber wir möchten End-to-End über verschiedene Kombinationen von Minimal- und Maximalwerten hinweg validieren.

Das manuell zu tun ist nicht schwer, nur langsam: mehrere Profile erstellen und verschiedene Testdatensätze vorbereiten. Das kostet viel Zeit, und menschliche Fehler sind immer möglich.

Wir haben den Bot beauftragt. Er verstand die Aufgabe, generierte Fälle mit jeder möglichen Kombination und testete alles in **5 Minuten**.

Hier ist ein Auszug aus dem Bericht des Bots.

### Testfälle

#### Gruppe 1: Profilerstellung und FHIRSchema-Verifizierung
| ID | Status | Beschreibung | Erwartet | Ergebnis |
| --- | --- | --- | --- | --- |
| TC- 01 | PASS | StructureDefinition mit min:2 für Observation.category erstellen | 200 | 200 |
| TC- 02 | SKIP | FHIRSchema verifizieren: category in required, min=2 | FHIRSchema enthält required und min=2 | FHIRSchema nicht über API zugänglich (interner Mechanismus), Validierung in TC-03..TC-06 verifiziert |

#### Gruppe 2: Validierung mit min:2-Profil
| ID | Status | Beschreibung | Erwartet | Ergebnis |
| --- | --- | --- | --- | --- |
| TC- 03 | PASS | Observation ohne category (0 Einträge) | 422, required-Fehler | 422, required-key: "The property 'category' is required" |
| TC- 04 | PASS | Observation mit 1 category (unter min:2) | 422, Kardinalitätsfehler | 422, invalid-cardinality: "Current count is '1', expected between '2' and 'Infinity'" |
| TC- 05 | PASS | Observation mit 2 categories (genau min:2) | 201 | 201 |
| TC- 06 | PASS | Observation mit 3 categories (über min:2) | 201 | 201 |

#### Gruppe 3: Regression, min:1-Profil
| ID | Status | Beschreibung | Erwartet | Ergebnis |
| --- | --- | --- | --- | --- |
| TC- 07 | PASS | StructureDefinition mit min:1 für Observation.category erstellen | 200 | 200 |
| TC- 08 | PASS | Observation ohne category (meta.profile mit min:1) | 422, required-Fehler | 422, required-key: "The property 'category' is required" |
| TC- 09 | PASS | Observation mit 1 category (meta.profile mit min:1) | 201 | 201 |

#### Gruppe 4: Profil mit min:3, max:5
| ID | Status | Beschreibung | Erwartet | Ergebnis |
| --- | --- | --- | --- | --- |
| TC- 10 | PASS | StructureDefinition mit min:3, max:"5" für Observation.category erstellen | 200 | 200 |
| TC- 11 | PASS | Observation mit 2 categories (unter min:3) | 422, Kardinalitätsfehler | 422, invalid-cardinality: "Current count is '2', expected between '3' and '5'" |
| TC- 12 | PASS | Observation mit 3 categories (genau min:3) | 201 | 201 |
| TC- 13 | PASS | Observation mit 6 categories (über max:5) | 422, Kardinalitätsfehler | 422, invalid-cardinality: "Current count is '6', expected between '3' and '5'" |

**PASS** — Die Korrektur funktioniert korrekt.

- `element.min: 2` macht das Feld korrekt zu einem Pflichtfeld und prüft die minimale Kardinalität

- `element.min: 1` funktioniert weiterhin wie zuvor (keine Regression festgestellt)

- `element.min: 3, max: 5` prüft sowohl die minimale als auch die maximale Kardinalität korrekt

- Validierungsfehlermeldungen sind informativ und enthalten korrekte min/max-Werte

Die Möglichkeit, ein Feature vor der Veröffentlichung auf diese Weise zu testen, vereinfacht den gesamten Entwicklungsprozess erheblich. Wir vertrauen dem Bot noch nicht blind und prüfen weiterhin manuell. Wir tun dies jedoch deutlich effizienter und decken dabei zusätzliche Grenzfälle sowie Performance- und Sicherheitsprüfungen ab.

## Dokumentationsvalidierung

Der Bot gleicht kontinuierlich mit der [Aidbox-Dokumentation](https://www.health-samurai.io/docs/aidbox) ab. Wenn er Unklarheiten oder offensichtliche Dokumentationsfehler feststellt, erstellt er automatisch eine Aufgabe, in der vermerkt ist, was wo korrigiert werden muss. Dies trägt erheblich dazu bei, die Dokumentationsgenauigkeit bei Änderungen sowie bei der Entwicklung neuer Features aufrechtzuerhalten. Beispielsweise fand der Bot bei der Implementierung des Features [External Secrets](https://www.health-samurai.io/docs/aidbox/configuration/secret-files) wiederholt Abweichungen zwischen Dokumentation und Implementierung und half uns, eine gute Dokumentation zu verfassen.

## Wie wir unseren Backlog mit dem Bot abgebaut haben

Ein unerwarteter Bonus stellte sich heraus: Mit Hilfe des Bots haben wir unseren umfangreichen Backlog abgebaut. Wir haben etwa 30 Aufgaben zur Bewertung und Reproduktion eingereicht. Etwa die Hälfte davon – Aufgaben, die lange unbearbeitet geblieben waren – stellte sich als bereits im Rahmen anderer Änderungen behoben heraus. Die verbleibenden Aufgaben bestätigten ihre Relevanz. Einige wurden für schnelle Korrekturen priorisiert und umgesetzt. Der Bot ist nicht nur für das tägliche Testen nützlich, sondern auch für die Priorisierung und das Grooming des Backlogs.

In den letzten Wochen hat der Bot über hundert Aufgaben in rund 250 Durchläufen getestet. Ein vollständiger Testzyklus dauert 5 bis 10 Minuten, bei komplexen Aufgaben bis zu 20 Minuten. Das alles läuft auf einer virtuellen Maschine, die 8 US-Dollar pro Monat kostet. Wir sind von den Ergebnissen beeindruckt. Aufgaben, die einen QA-Ingenieur früher ein bis zwei Stunden gekostet haben, werden jetzt in Minuten erledigt.

Der Bot ersetzt keinen QA-Ingenieur. Er missversteht manchmal eine Aufgabe, und er erfordert menschliche Überprüfung. Aber er übernimmt die Routine: Reproduktion, Generierung von Testfällen, Ausführung von Kombinationen, Dokumentationsprüfungen. Das gibt dem Team Zeit für das frei, was wirklich menschliche Aufmerksamkeit erfordert.

Haben Sie LLMs bereits in Ihre Entwicklungs- oder Wartungs-Workflows integriert? Wir würden gerne von Ihren Erfahrungen hören. [Treten Sie unserem Zulip-Chat bei](https://connect.health-samurai.io/), um die Diskussion fortzusetzen.

Marat Surmashev, VP of Engineering