Welche Daten in Frage kommen
| Datenquelle | Beispiel | Was sie über Fehler verrät |
|---|---|---|
| Fehlerhistorie | Tickets aus Jira, ALM oder Xray, zugeordnet zu Modulen | Wo früher Fehler waren, entstehen oft wieder welche |
| Code-Änderungen | Commits, geänderte Zeilen und Dateien je Release aus Git | Viel Änderung in kurzer Zeit erhöht das Risiko |
| Komplexität | Größe, Verschachtelung, Abhängigkeiten | Komplexer Code ist fehleranfälliger |
| Schnittstellen | Zahl der angebundenen Systeme, geänderte Verträge | Übergänge zwischen Systemen sind typische Fehlerquellen |
| Konfiguration | Geänderte Parameter, Tarife, Regeln | Fehler entstehen oft in Daten, nicht im Code |
| Testergebnisse | Instabile oder häufig fehlschlagende Tests | Hinweise auf unruhige Bereiche |
| Nutzungsdaten | Aufrufe je Funktion in Produktion | Wichtig für die Gewichtung, eher Auswirkung als Wahrscheinlichkeit |
Die Daten müssen einem Modul zugeordnet werden können. Das ist in der Praxis oft der größte Aufwand.
Wie ein Modell daraus eine Wahrscheinlichkeit macht
Häufig reichen klassische Verfahren des maschinellen Lernens, etwa logistische Regression oder Entscheidungsbäume. Sie lernen aus vergangenen Releases, welche Merkmale vor Fehlern auftraten.
Sprachmodelle helfen dort, wo Text im Spiel ist. Sie ordnen Fehlerbeschreibungen Modulen zu, fassen Änderungen zusammen oder erkennen ähnliche frühere Fehler.
Das Ergebnis ist ein Wert je Modul, der auf die Stufen 1 bis 5 der Risikomatrix übertragen wird. Wie die Matrix aufgebaut ist, erklärt der Artikel Risikobasiertes Testen: Testaufwand mit einer Risikomatrix priorisieren.
Wie man prüft, ob die Schätzung taugt
Der erste Test ist ein Blick zurück: Hätte das Modell bei vergangenen Releases die Module mit tatsächlichen Fehlern vorn gesehen? Daraus ergibt sich eine Trefferquote, also der Anteil der später gefundenen Fehler, der in den Modulen der obersten Stufen lag.
Aufschlussreich ist auch der Vergleich mit der Schätzung des Teams. Wo Modell und Team weit auseinanderliegen, lohnt sich die Frage nach dem Grund. Nach jedem Release werden Schätzung und Ergebnis gegenübergestellt und das Modell angepasst.
Grenzen
Ohne Historie gibt es keine Schätzung. Neue Module oder Systeme haben keine Vergangenheit, dort bleibt die Einschätzung der Fachleute. Auch schlechte Daten führen zu schlechten Schätzungen, etwa falsch zugeordnete Tickets oder fehlende Commits.
Das Modell sieht nur, was gemessen wird. Fachliche Neuerungen, neue Vorschriften oder ein neues Team stehen in keinem Log. Und die Auswirkung bleibt eine menschliche Bewertung: Was ein Fehler für Kunden, Geld und Aufsicht bedeutet, entscheidet der Fachbereich.
Für Revision und Aufsicht muss nachvollziehbar sein, welche Daten zu welcher Einstufung geführt haben und wer sie freigegeben hat. Modelle, deren Ergebnis niemand erklären kann, sind dafür ungeeignet. Fehlertickets und Code können außerdem vertrauliche Inhalte enthalten und gehören nicht in öffentliche KI-Dienste.
So arbeitet Cubio
Wir beginnen mit dem, was in Ihrem Projekt schon vorliegt: Fehlertickets, Commits und Testergebnisse der letzten Releases. Zuerst prüfen wir, ob sich diese Daten den Modulen zuordnen lassen und ob sie für eine Schätzung reichen. Reichen sie nicht, bleibt es bei der Bewertung durch das Team, gestützt auf klare Kriterien je Stufe.
Reichen die Daten, setzen wir zuerst einfache, erklärbare Verfahren ein und prüfen sie am Rückblick auf vergangene Releases. Erst wenn die Schätzung dort trägt, nutzen wir sie für das nächste Release. Die Auswirkung bewertet Ihr Fachbereich, die Einstufung geben Testmanagement und Fachbereich gemeinsam frei.
Für die KI gelten dieselben Leitplanken wie bei KI im Testing: keine Kundendaten in öffentlichen Modellen, Betrieb in der EU oder auf Ihren Servern, jede Einstufung dokumentiert und prüfbar. Wie die Matrix für Ihre Module aussehen könnte, zeigt der Risikomatrix-Rechner.
