So bauen Sie eine Rückverfolgbarkeitsmatrix für Anforderungen, die echte Abdeckungslücken findet

Eine Rückverfolgbarkeitsmatrix für Anforderungen verbindet jede Anforderung mit den Tests, die sie überprüfen. So sehen Sie, welche Anforderungen von keinem Test abgedeckt sind und welche Tests nichts abdecken. Gut gebaut ist sie ein Diagnosewerkzeug, das Sie während eines Releases nutzen. Schlecht gebaut ist sie eine Tabelle, die jemand in der Woche vor dem Audit aufräumt, und sie sagt Ihnen nichts, was Sie nicht ohnehin schon vermutet hätten.

Der Unterschied liegt in drei Entscheidungen: wie feingliedrig Ihre Anforderungsebene ist, ob Sie in beide Richtungen verfolgen, und ob Abdeckung bedeutet, dass ein Test existiert oder dass ein Test tatsächlich bestanden wurde. Wenn diese drei stimmen, findet die Matrix Lücken von selbst. Diese Anleitung geht jede Entscheidung durch und zeigt dann, was sich ändert, wenn die Matrix aus Ihren echten Testdaten erzeugt wird statt von Hand gepflegt.

Wofür eine Rückverfolgbarkeitsmatrix wirklich da ist

Die meisten Teams begegnen der Rückverfolgbarkeitsmatrix, oft als RTM abgekürzt, zuerst als Audit-Artefakt. Jemand verlangt einen Nachweis, dass die Software gegen ihre Anforderungen getestet wurde, und eine Matrix wird erstellt, um diese Person zufriedenzustellen. Genau diese Ausgangslage ist der Grund, warum so viele Matrizen nutzlos sind. Ein Artefakt, das einmal betrachtet werden soll, wird darauf optimiert, vollständig auszusehen, nicht darauf, wahr zu sein.

Eine funktionierende Matrix beantwortet zwei Fragen, die sonst kaum zu beantworten sind:

• Ist diese Anforderung überprüft?: für jede Anforderung im Umfang, welche Testfälle sie abdecken und ob diese Tests in einer echten Umgebung bestanden wurden.
• Warum existiert dieser Test?: für jeden Testfall in Ihrer Bibliothek, welche Anforderung die Kosten seiner Pflege rechtfertigt.

Der Audit-Nutzen ergibt sich nebenbei. Wenn die Matrix präzise genug ist, um zwei Tage vor einem Release eine ungetestete Anforderung zu finden, wird sie eine Prüferin oder einen Prüfer problemlos überzeugen. Umgekehrt gilt das nicht.

Schritt 1: Legen Sie die Anforderungsebene fest, bevor Sie einen einzigen Test schreiben

Eine Matrix ist nur so gut wie das, was auf ihrer linken Seite steht. Sind Ihre Anforderungen vage, erbt die Matrix diese Unschärfe und jede Abdeckungszahl wird zur Schätzung. Legen Sie deshalb eine Anforderungsstruktur fest, bevor Sie irgendetwas verknüpfen, und bleiben Sie dabei.

Zwei Ebenen genügen meist. Eine Gruppierungsebene für einen Block zusammengehöriger Funktionalität und eine Aussageebene für die einzelnen Verhaltensweisen, die Nutzende erwarten. In ISO Mate entspricht das Features als Container und User Stories darin. Features tragen eine Priorität aus Must Have, Should Have, Could Have oder Won’t Have, sodass Sie erkennen, welche Teile der Matrix am wichtigsten sind, und User Stories durchlaufen Draft, Ready, In Progress, Testing und Done, sodass Sie erkennen, welche Anforderungen überhaupt testreif sind.

Zwei Gewohnheiten zahlen sich sofort aus. Formulieren Sie jede Anforderung so, dass sie eine einzige Aussage macht, denn eine Anforderung mit dem Wort “und” muss fast immer in zwei geteilt werden. Und legen Sie Anforderungen nicht in einem Dokument ab, das außerhalb des Systems mit Ihren Tests liegt, denn sobald beide auseinanderlaufen, wird die Matrix zur Fiktion.

Schritt 2: Verknüpfen Sie auf Ebene des Akzeptanzkriteriums, nicht der User Story

Das ist die wirkungsvollste Entscheidung der ganzen Übung, und genau hier scheitern die meisten Matrizen unbemerkt.

Nehmen Sie eine User Story mit sechs Akzeptanzkriterien. Ein Testfall ist mit ihr verknüpft. Auf Story-Ebene meldet die Matrix diese Anforderung als abgedeckt, und sie erscheint in jedem Dashboard grün. In Wirklichkeit wurden fünf der sechs Verhaltensweisen nie überprüft. Die Matrix hat die Lücke nicht nur verpasst, sie hat sie aktiv hinter einer grünen Anzeige versteckt.

Auf Kriterienebene zu verknüpfen macht aus derselben Story ein ehrliches Bild: ein Kriterium abgedeckt, fünf offen. Teilabdeckung wird sichtbar, und genau diesen Zustand wollen Sie erkennen. ISO Mate unterstützt das direkt, denn jedes Akzeptanzkriterium einer User Story lässt sich einzeln mit Testfällen verknüpfen, sodass Abdeckung an der Anforderungsaussage gemessen wird und nicht an der Story, die sie umhüllt.

Ja, das Verknüpfen auf Kriterienebene macht am Anfang mehr Arbeit. Es ist auch die einzige Variante dieser Übung, die Erkenntnisse liefert. Wenn der Aufwand zu groß wirkt, ist das meist ein Hinweis darauf, dass Ihre Akzeptanzkriterien zu grob sind, und kein Hinweis darauf, weiter oben zu verknüpfen.

Schritt 3: Verfolgen Sie in beide Richtungen

Eine Matrix mit nur einer Richtung beantwortet die halbe Frage. Die beiden Sichten sehen im Diagramm ähnlich aus und verhalten sich in der Praxis völlig unterschiedlich.

• Von oben nach unten: beginnt bei der Anforderung und geht vorwärts zu den Tests. Das findet Anforderungen ohne Abdeckung, also die Lücke, durch die Fehler ausgeliefert werden.
• Von unten nach oben: beginnt beim Testfall und geht zurück zur Anforderung. Das findet Tests, die nichts rechtfertigen, also die Lücke, die Ihr Pflegebudget unbemerkt auffrisst.

In ISO Mate werden beide Sichten aus den Verknüpfungen erzeugt, die Sie bereits angelegt haben. Die Sicht von oben nach unten folgt Features, dann User Stories, dann Akzeptanzkriterien und Issues, dann Testfällen und dann Testausführungen, mit Abdeckungsabzeichen und dem Status der letzten Ausführung an jedem Knoten. Die Sicht von unten nach oben startet bei den Testfällen und zeigt die verknüpften User Stories und Akzeptanzkriterien bis zum übergeordneten Feature, mit einem Prozentwert für die umgekehrte Abdeckung und der Anzahl aller, verknüpfter und nicht verknüpfter Testfälle. Beide erreichen Sie über den Eintrag Rückverfolgbarkeit in der Gruppe Qualitätssicherung, und Sie wechseln mit einem Umschalter im Kopfbereich zwischen ihnen. Der Leitfaden zur Rückverfolgbarkeitsmatrix beschreibt die Bedienung im Detail.

Schritt 4: Suchen Sie beide Arten von Lücke

Sobald beide Richtungen existieren, hat die Matrix zwei konkrete Dinge zu berichten. Suchen Sie beide bewusst, statt darauf zu warten, dass sie von allein auffallen.

Ungetestete Anforderungen. Filtern Sie die Sicht von oben nach unten auf Anforderungen ohne Abdeckung und sortieren Sie nach Priorität. Ein Must-Have-Feature mit einem nicht abgedeckten Kriterium blockiert das Release. Ein Could-Have-Feature mit dünner Abdeckung kann eine völlig vertretbare Entscheidung sein, solange es eine Entscheidung ist und kein Versehen. Der Filter soll nicht jede Lücke auf null bringen, sondern sicherstellen, dass nichts Wichtiges versehentlich unabgedeckt bleibt.

Verwaiste Testfälle. Das sind Tests, die mit keiner Anforderung verknüpft sind, und jede gewachsene Testbibliothek sammelt einige davon an. Typische Ursachen sind Tests, die vor der Anforderungsstruktur entstanden sind, explorative Prüfungen, die in die Bibliothek aufgestiegen sind, und Tests, deren Anforderung später entfernt wurde, ohne den Test noch einmal anzusehen. Für jeden Verwaisten braucht es eine von drei Entscheidungen: mit der Anforderung verknüpfen, die er tatsächlich abdeckt, ihn ausmustern, oder ihn bewusst als Regressionstest behalten, der gegen einen früheren Defekt schützt und nicht gegen eine formulierte Anforderung. Was Sie nicht tun sollten, ist ihn unbetrachtet zu lassen, denn ein unerklärter Test ist ein Pflegeaufwand, dem niemand zugestimmt hat.

Schritt 5: Lassen Sie Abdeckung überprüft bedeuten, nicht geschrieben

Ein verknüpfter Testfall, der noch nie gelaufen ist, ist keine Abdeckung. Er ist eine Absicht. Eine Matrix, die Absichten als Abdeckung zählt, ist die gefährlichste Variante dieses Dokuments, weil sie beruhigend wirkt und Ihnen gleichzeitig nichts über den Zustand des Builds sagt.

Bringen Sie deshalb Ausführungsergebnisse in die Matrix, nicht nur Verknüpfungen. Für jede abgedeckte Anforderung wollen Sie wissen, wann der Test zuletzt gelaufen ist, wie das Ergebnis lautete und gegen welche Umgebung er lief. Ein bestandener Test auf einem alten Build und in einer anderen Umgebung ist etwas, das Sie wissen sollten, bevor Sie sich darauf verlassen.

Halten Sie blockierte Ergebnisse außerdem von Fehlschlägen getrennt. Ein fehlgeschlagener Test sagt Ihnen, dass die Software falsch ist. Ein blockierter Test sagt Ihnen, dass Sie es noch nicht wissen, und das ist ein anderes Problem mit einer anderen Zuständigkeit. ISO Mate erfasst Ergebnisse auf Schrittebene als Pass, Fail oder Blocked, erlaubt das Anhängen von Screenshots und Nachweisen und erlaubt das Blockieren einer ganzen Ausführung mit Begründung, wenn Vorbedingungen nicht erfüllt sind. Testumgebungen werden separat definiert und den Ausführungen zugeordnet, sodass die Matrix zeigt, woher jedes Ergebnis kam. Weil die Sicht von oben nach unten den Status der letzten Ausführung an jedem Knoten zeigt, kann eine Anforderung, deren einziger Test nie gelaufen ist, nicht abgedeckt aussehen.

Das Verknüpfen von Defekten schließt den Kreis. Wenn ein Test fehlschlägt, verbinden Sie den Defekt mit ihm, damit die Spur von der Anforderung über den Test bis zum aufgedeckten Fehler führt. In ISO Mate können Sie Issues aus einem fehlgeschlagenen Test anlegen, und die Detailseite des Issues zeigt Testabdeckung und Ausführungsergebnisse dazu, sodass sich die Verbindung von beiden Enden korrekt liest.

Schritt 6: Halten Sie die Matrix zwischen Releases lebendig

Anforderungen ändern sich, Tests werden ausgemustert und Stories werden geteilt. Eine von Hand gepflegte Matrix beginnt an dem Tag zu verfallen, an dem sie fertig ist, und deshalb ist die Tabellenversion immer die Momentaufnahme einer Lage, die es nicht mehr gibt.

Die Lösung ist strukturell. Erzeugen Sie die Matrix aus denselben Datensätzen, mit denen Ihr Team täglich arbeitet, sodass ein neues Akzeptanzkriterium in dem Moment als unabgedeckte Anforderung erscheint, in dem es entsteht, und ein ausgemusterter Test von selbst aus der Abdeckungszahl verschwindet. Legen Sie darüber einen leichten Prüfrhythmus: Sehen Sie sich den Abdeckungsfilter am Ende jedes Testzyklus an und noch einmal vor einem Release, wenn eine Überraschung am teuersten ist. Zwei geplante Blicke sind mehr wert als ein Neuaufbau pro Quartal.

Trendmetriken sind hier die sinnvolle Ergänzung. Abdeckung sagt Ihnen, wo Sie stehen, während Fehlerentdeckungsrate und Testwirksamkeit Ihnen sagen, ob die Tests hinter dieser Abdeckung ihr Geld verdienen. Hohe Abdeckung bei niedriger Entdeckungsrate bedeutet meist, dass viele Tests Dinge bestätigen, die ohnehin nie kaputtgegangen wären.

Fünf Fehler, die eine Matrix wertlos machen

• Sie für das Audit bauen: ein Dokument, das vollständig aussehen soll, wird darauf optimiert, vollständig auszusehen. Bauen Sie es, um Lücken zu finden, dann besteht es das Audit ohnehin.
• Auf Story-Ebene verknüpfen: grobe Verknüpfungen machen aus Teilabdeckung falsches Grün. Verknüpfen Sie am Akzeptanzkriterium.
• Verknüpft mit getestet verwechseln: ohne Ausführungsstatus meldet die Matrix Absichten. Führen Sie Ergebnis und Umgebung mit.
• Verwaiste Tests ignorieren: Tests ohne zugehörige Anforderung sind entweder falsch verknüpft oder unnötig, und beides kostet Sie.
• Sie in einer Tabelle halten: sobald Anforderungen und Tests woanders leben, ist die Matrix eine Kopie, die schon veraltet ist.

Wie ISO Mate die Matrix für Sie aufbaut

Jeder Schritt oben lässt sich heute im QA-Management von ISO Mate umsetzen, wo die Matrix aus Ihren echten Anforderungen und Testdaten erzeugt wird statt als separates Dokument gepflegt:

• Eine Anforderungsebene, die zur Matrix passt: Features als Container mit den Prioritäten Must Have, Should Have, Could Have und Won’t Have, und User Stories, die Draft, Ready, In Progress, Testing und Done durchlaufen.
• Verknüpfung auf Kriterienebene: jedes Akzeptanzkriterium wird einzeln mit Testfällen verknüpft, sodass Abdeckung an der Anforderungsaussage gemessen wird.
• Sichten von oben nach unten und von unten nach oben: verfolgen Sie Features, User Stories, Akzeptanzkriterien und Issues, Testfälle und Testausführungen, oder starten Sie bei einem Testfall und gehen Sie zurück bis zu seinem übergeordneten Feature, mit einem Prozentwert für die umgekehrte Abdeckung.
• Eingebaute Lückenerkennung: filtern Sie die Sicht von oben nach unten nach Feature, Status, Priorität und Abdeckung, und filtern Sie die Sicht von unten nach oben nach Verknüpfung, um nicht verknüpfte Testfälle zu isolieren. Zusammenfassungen zeigen Gesamtzahl, verknüpfte und nicht verknüpfte Tests.
• Ausführungsstatus im Baum: Abdeckungsabzeichen und das letzte Ausführungsergebnis stehen an jedem Knoten, gestützt auf Ergebnisse Pass, Fail und Blocked auf Schrittebene, Nachweisanhänge, Blockierungsgründe und benannte Testumgebungen.
• Defekt-Rückverfolgbarkeit: legen Sie Issues aus fehlgeschlagenen Tests an und sehen Sie Testabdeckung und Ausführungsergebnisse direkt auf der Detailseite des Issues im DevOps-Management.
• QA-Metriken: verfolgen Sie Fehlerentdeckungsrate, Testwirksamkeit, Wiederverwendbarkeit, Aufwandsabweichung und Pflegeindikatoren über die Zeit, um Abdeckung gemeinsam mit Qualität zu beurteilen.
• Auditfähige Ausgabe: exportieren Sie die Rückverfolgbarkeitsmatrix als PDF und Testfälle, Testzyklen, User Stories und Features als CSV oder PDF.

Ein großer Baum bleibt handhabbar, weil untergeordnete Elemente bei Bedarf geladen werden, und Alle ausklappen sowie Alle einklappen lassen Sie zwischen Überblick und Detail wechseln, ohne etwas neu aufzubauen.

Ein erster Durchgang für diese Woche

Sie müssen nicht Ihr gesamtes Backlog abbilden, um Nutzen zu haben. Nehmen Sie das eine Feature, das in Ihr nächstes Release geht. Schreiben Sie seine User Stories mit ausdrücklichen Akzeptanzkriterien, verknüpfen Sie Ihre vorhandenen Testfälle mit einzelnen Kriterien statt mit den Stories, öffnen Sie dann die Sicht von oben nach unten und filtern Sie auf unabgedeckte Anforderungen. Dieser eine Durchgang bringt meist zwei oder drei Verhaltensweisen zum Vorschein, die niemand getestet hatte, und das ist ein besserer Ertrag als die meisten Prozessänderungen in einer Woche liefern.

Öffnen Sie danach einmal die Sicht von unten nach oben und sehen Sie sich die Zahl der nicht verknüpften Tests an. Welche Zahl auch erscheint, sie ist der Teil Ihrer Testbibliothek, den derzeit niemand begründen kann, und die Entscheidung darüber ist meist ein kurzes Gespräch mit langem Nutzen.

Wenn Sie das an Ihren eigenen Anforderungen sehen möchten, schauen Sie sich das QA-Management von ISO Mate an oder starten Sie einen Test. Jedes Konto beginnt mit einer 14-tägigen kostenlosen Testphase, lang genug, um ein Feature abzubilden, seine Kriterien zu verknüpfen und Ihr erstes ehrliches Abdeckungsbild zu bekommen.