Anforderungsverfolgbarkeitsmatrix: Struktur und Anwendung im QA-Bereich
Die Anforderungsverfolgbarkeitsmatrix (RTM) ist eine Tabelle, die die Beziehungen zwischen Anforderungen, Testfällen und Fehlern über alle Phasen des Softwarelebenszyklus dokumentiert. Sie liefert Antworten auf Schlüsselfragen: Was wurde getestet, was bleibt ungedeckt und warum wird ein bestimmter Test durchgeführt.
Ohne eine RTM verliert das Testen an Transparenz; mit ihr wird das Testen zu einem messbaren Prozess mit klaren Abdeckungsmetriken.
Ziele der Matrixnutzung
Die RTM adressiert folgende Aufgaben:
- Bewertung der Vollständigkeit der Anforderungsabdeckung durch Tests.
- Identifizierung von Lücken in der Testdokumentation.
- Analyse der Auswirkungen von Anforderungsänderungen auf bestehende Tests.
- Nachverfolgung des Wegs von der Anforderung zum Fehler.
- Erstellung von Berichten für Stakeholder mit quantitativen Kennzahlen.
Diese Funktionen machen die RTM in mittleren und großen Projekten mit umfangreichen Anforderungen unverzichtbar.
Arten der Verfolgbarkeit in der RTM
Es gibt verschiedene Ansätze zum Aufbau von Beziehungen:
| Typ | Richtung der Verknüpfung | Anwendung |
|------|-------------------|-------------|
| Vorwärts | Anforderung → Testfall | Überprüfung, ob Tests für eine Anforderung existieren |
| Rückwärts | Testfall → Anforderung | Begründung der Notwendigkeit eines Tests |
| Bidirektional | Anforderung ⇄ Testfall | Vollständige Kontrolle in beide Richtungen |
| Vertikal | Anforderung → Design → Code → Test | End-to-End-Verfolgbarkeit über Phasen hinweg |
| Horizontal | Test → Fehler → Fix → Retest | Verfolgbarkeit innerhalb des Testens |
Die Wahl des Typs hängt von der Projektkomplexität und Entwicklungsphase ab.
Spaltenstruktur in der RTM-Tabelle
Eine Standardmatrix umfasst folgende Felder:
- Anforderungs-ID — eindeutiger Bezeichner (REQ-AUTH-01).
- Anforderungsbeschreibung — kurze Beschreibung (E-Mail-Autorisierung).
- Testfall-ID — Liste zugehöriger Testfälle (TC-LOGIN-01, TC-LOGIN-02).
- Teststatus — Ausführungsstatus (Bestanden/Nicht bestanden/Geblockt/Nicht ausgeführt).
- Fehler-ID — Fehlerbezeichner (BUG-101).
- Fehlerstatus — Fehlerstatus (Offen/Behoben/Geschlossen).
- Abdeckungsstatus — Abdeckungsstatus (Abgedeckt/Nicht abgedeckt/Teilweise).
- Abdeckung % — Abdeckungsprozentsatz (100%/0%/50%).
Beispiele für RTM-Tabellen
Grundtabelle (Anforderungen und Testfälle)
| REQ ID | Anforderung | Priorität | Testfall-ID | Teststatus | Fehler-ID | % Abdeckung |
|--------|-------------|----------|--------------|-------------|-----------|------------|
| REQ-01 | Autorisierung | Hoch | TC-LOGIN-01, TC-LOGIN-02, TC-LOGIN-03 | Bestanden, Bestanden, Nicht bestanden | BUG-101 | 100% |
| REQ-02 | Passwortwiederherstellung | Mittel | TC-REC-01, TC-REC-02 | Bestanden, Nicht ausgeführt | — | 50% |
| REQ-04 | Preis-Filterung | Niedrig | — | — | — | 0% |
Erweiterte Tabelle mit Entwicklungslinks
| REQ ID | Anforderung | Testfall-ID | Ergebnis | Fehler-ID | Entwicklungsaufgabe | Komponente |
|--------|-------------|--------------|--------|-----------|----------|-----------|
| REQ-01 | Login | TC-AUTH-01 | ✅ Bestanden | — | TASK-101 | Auth-Modul |
| REQ-01 | Login | TC-AUTH-03 | ❌ Nicht bestanden | BUG-001 | TASK-101 | Auth-Modul |
Solche Tabellen ermöglichen eine schnelle Lokalisierung problematischer Bereiche.
Textuelle Verfolgbarkeitsschemata
Klassische Vorwärtsverknüpfung
┌──────────────┐ ┌──────────────┐ ┌──────────────┐
│ ANFORDERUNG │ │ TESTFALL │ │ FEHLER │
│ REQ-01 ──────┼─────▶│ TC-01 ───────┼─────▶│ BUG-101 │
└──────────────┘ └──────────────┘ └──────────────┘End-to-End-Vertikale Verfolgbarkeit
┌─────────────────────┐
│ GESCHÄFTSANFORDERUNG│
└──────────┬──────────┘
▼
┌─────────────────────┐ ┌─────────────┐
│ FUNKTIONALE │───▶│ TEST │
│ ANFORDERUNGEN │ │ FÄLLE │
└──────────┬──────────┘ └──────┬──────┘
│ │
▼ ▼
┌─────────┐ ┌─────────────────────┐
│TECHNISCHE│ │ TESTAUSFÜHRUNG │
│AUFGABEN │ └──────────┬──────────┘
└────┬────┘ │
│ ▼
└────────────────────┬───────┘
│
┌─────────────────────┐
│ FEHLER │
└─────────────────────┘Analyse der Abdeckungsstatistiken
Ein typischer RTM-Bericht enthält:
| Metrik | Wert | Formel |
|--------|-------|---------|
| Gesamtanforderungen | 50 | — |
| Mit Tests | 45 | — |
| Ohne Tests | 5 | — |
| % Abdeckung | 90% | (45/50)×100% |
| Tests pro Anforderung (Durchschnitt) | 3,6 | 180/50 |
Häufige Fehler: veraltete Matrix, formale Verknüpfungen, fehlende Fehlerlinks, doppelte Tests.
Checkliste für QA-Ingenieure
- Jede Anforderung hat mindestens einen Testfall.
- Keine "verwaisten" Testfälle ohne Verknüpfungen.
- Verwandte Tests werden bei Anforderungsänderungen aktualisiert.
- Jeder Fehler ist mit einer Anforderung verknüpft.
- Die Matrix wird nach jedem Sprint/Release aktualisiert.
- Analyse von Fehlerursachen ist über RTM möglich.
RTM-Automatisierungstools
| Tool | Typ | Funktionen |
|------|------|----------|
| Jira + Xray/Zephyr | Plugins | Agile Verfolgbarkeit |
| TestRail | Testmanagement | Native RTM |
| Qase | Testmanagement | Einfache Verknüpfungen |
| Excel/Google Sheets | Manuell | Für kleine Projekte |
| Polarion/Azure DevOps | ALM | Enterprise-Level |
Wann RTM zu vermeiden ist
Die Matrix ist nicht geeignet für:
- Projekte mit <20 Anforderungen.
- Teams mit <3 Personen.
- Kurze Sprints (1-2 Wochen).
- Ad-hoc-Tests oder MVPs mit häufigen Änderungen.
Nachteile: hoher Aktualisierungsaufwand, Risiko des Formalismus, Overhead für Startups.
Regel: RTM lohnt sich bei >20 Anforderungen und Teams mit 3+ Personen.
Wichtige Erkenntnisse
- RTM gewährleistet 90%+ Anforderungsabdeckung durch Tests in großen Projekten.
- Bidirektionale Verfolgbarkeit minimiert Risiken bei Regressionen.
- Die Relevanz der Matrix ist entscheidend für ihren Wert; Aktualisierung nach jeder Änderung.
- Nutzen Sie ALM-Tools zur Automatisierung auf Enterprise-Level.
- Analysieren Sie Metriken: Abdeckungslücken und Testfälle pro Anforderung.
— Editorial Team
Noch keine Kommentare.