In diesem Beitrag
Canary AI QA: Fehlererkennung statt Benchmark-Punkte prüfen
Quellenbasis: Dokumentation am 8. Oktober 2026 geprüft. Dies ist ein recherchierter Implementierungsleitfaden. Der folgende Pilot ist ein Vorschlag; wir haben diese Herstellerprüfungen nicht durchgeführt und ihre Leistung nicht gemessen.
Was belegt Canarys QA-Benchmark?
Canarys Methodik von QA-Bench v0 bewertet Prüfausgaben zu 35 PRs in vier Repositories. Ein LLM bewertet Relevanz, Abdeckung und Kohärenz. Die Einschränkungen nennen den Unterschied zwischen groben Testplänen und konkreten Skripten und halten ausgeführte Pass-Fail-Tests für einen faireren Vergleich.
Ein Gesamtwert wie 83,1 bedeutet deshalb nicht „Canary findet 83,1 Prozent der Fehler“. Er belegt auch nicht die Leistung deiner aktuellen Claude-Code- oder Codex-Konfiguration. Nutze den Benchmark, um die Prüffrage zu verstehen, und miss anschließend das tatsächlich benötigte Ergebnis.
Was sollte ein Einführungspilot stattdessen messen?
Prüfe je bekanntem Defekt, ob der erzeugte und ausgeführte Test auf der fehlerhaften Version scheitert und auf der reparierten aus dem richtigen Grund besteht. Trenne Ablaufidentifikation, Testerstellung, Ausführung und Fehlerreproduktion. Ein guter Plan kann nützlich sein, ohne bereits ein ausführbarer Regressionstest zu sein.
Canarys veröffentlichte Einrichtungsreferenz ist der Ausgangspunkt für aktuelle Integrationen. Fixiere getestete Version und unterstützten Ablauf; ein Modellname im alten Benchmark belegt keine heutige Kompatibilität. Trenne möglichst den feature-erstellenden Agenten von der Abnahmeevidenz.
Welche Fehler gehören in die Testanwendung?
Nutze eine isolierte Anwendung mit zwei Mandanten und einer bekannten korrekten Referenzversion. Baue jeweils einen Defekt ein, halte seine Kennzeichnung vor dem geprüften Agenten verborgen und ergänze fehlerfreie Kontrolländerungen. Die Tabelle ist ein vorgeschlagener Korpus, kein Canary-Ergebnis.
| Defekt | Erforderliche Assertion | Nützliche Kontrolle |
|---|---|---|
| Fehlende Mandantenprüfung | A kann B's Datensatz nicht lesen | A kann eigene Daten lesen |
| Doppelte Übermittlung | Ein logischer Request erzeugt einen Datensatz | Zwei verschiedene Requests erzeugen zwei |
| Rechte nur in UI geprüft | Direkter Backend-Schreibzugriff wird verweigert | Berechtigte Rolle kann schreiben |
| Fehler als Erfolg angezeigt | Anzeige und gespeicherter Zustand zeigen Fehler | Normaler Ablauf speichert korrekt |
| Zu breites Löschen | Nur ausgewählte Daten werden gelöscht | Andere Daten bleiben lesbar |
| Abgelaufene Session | Kein privilegierter Schreibzugriff | Gültige Session funktioniert |
Absichtliche Sicherheitsdefekte gehören ausschließlich in lokale oder isolierte synthetische Daten. Baue sie nicht in geteilte Produktion ein, um realistische Ergebnisse zu erhalten.
Wie bewertest du Ergebnisse ohne Selbsttäuschung?
- Nutze dieselbe Ausgangsapp, PR-Kontext und Zeitgrenze für alle Konfigurationen.
- Sichere Pläne, Tests, Befehle, Logs und Zielzustand.
- Reproduziere gemeldete Defekte unabhängig und klassifiziere Infrastrukturfehler separat.
- Führe jeden Kandidatentest gegen fehlerhafte und reparierte Version aus.
- Zähle bestätigte Erkennungen, übersehene bekannte Defekte, Fehlalarme bei Kontrollen und Review-Minuten.
Nenne Ergebnisse je Fehlerklasse und Stichprobengröße. Scheitert die App beim Start, ist das keine erfolgreiche Fehlererkennung. Scheitert der Test auch nach Reparatur, belegt er keine brauchbare Regression. Wiederhole Läufe, damit Schwankungen sichtbar bleiben.
Kann Canary die bestehende Testsuite ersetzen?
Entscheide das nicht anhand eines Herstellerscores. Behalte deterministische Tests für geschäftliche Invarianten und kritische Integrationen. Generierte explorative Tests können zusätzliche Abläufe erschließen. Übernimm einen Test erst nach Prüfung von Assertions, Testdatenverantwortung und Stabilität in die gepflegte Suite.
Definiere eigene Stop-Kriterien für Datenlecks und destruktive Fehler. Ein hoher Durchschnitt darf einen übersehenen kritischen Mandantenfehler nicht ausgleichen. Lege diese Grenze vor der Auswertung fest.
Wie budgetierst du KI-QA?
Miss Kosten pro akzeptierter Prüfung inklusive Infrastruktur, Wiederholungen und menschlicher Nachprüfung. Mehrfachmeldungen sind ein Defekt. Erfasse, welche Tests nach Reparatur und nächster Produktänderung weiter nützlich sind. Niedrige Erstellungskosten können durch Fehlalarme pro PR teuer werden.
Wann solltest du Canary ergänzen?
Wenn ein isolierter Pilot zusätzliche brauchbare Defekte oder gepflegte Regressionstests zu tragbarem Prüfaufwand zeigt. Liegt der Nutzen in der Ablaufplanung, nutze und benenne ihn so. Mit Defektkorpus und Abnahmeregeln kannst du eine unabhängige QA-Evaluation eingrenzen.
Weiterführende Umsetzungshilfe
Greptile Base, Plus oder Apex: PR-Reviews sinnvoll budgetieren. Arga Labs oder Archal: Zustandsbasierte Integrationstests.
Geprüfte Quellen
Unabhängigkeit und Marken: Wavect veröffentlicht diese Seite und ist selbst Anbieter, wir haben also ein wirtschaftliches Interesse daran. Mit den hier genannten anderen Unternehmen sind wir weder verbunden noch von ihnen beauftragt oder empfohlen, und alle Firmennamen, Marken und Warenzeichen Dritter gehören ihren jeweiligen Inhabern. Aussagen über andere Anbieter stammen aus öffentlich zugänglichen Quellen, vor allem aus deren eigenen veröffentlichten Seiten, mit Stand des auf dieser Seite genannten Prüfdatums, und können sich seither geändert haben. Bitte prüfe sie vor einer Entscheidung selbst. Diese Seite wurde nach bestem Wissen und Gewissen erstellt, mit dem Ziel, möglichst objektiv zu bleiben. Wenn dir etwas falsch oder unfair erscheint, schreib uns und wir korrigieren es: [email protected]