Macierz śledzalności wymagań: struktura i zastosowanie w QA
Macierz śledzalności wymagań (Requirements Traceability Matrix, RTM) to tabela, która rejestruje powiązania między wymaganiami, przypadkami testowymi i defektami na wszystkich etapach cyklu życia oprogramowania. Zapewnia odpowiedzi na kluczowe pytania: co zostało przetestowane, co pozostało bez pokrycia, dlaczego wykonuje się konkretny test.
Bez RTM testy tracą przejrzystość, z nią – stają się mierzalnym procesem z jasnymi metrykami pokrycia.
Cele stosowania macierzy
RTM rozwiązuje następujące zadania:
- Ocena kompletności pokrycia wymagań testami.
- Identyfikacja luk w dokumentacji testowej.
- Analiza wpływu zmian wymagań na istniejące testy.
- Śledzenie ścieżki od wymagania do defektu.
- Tworzenie raportów dla interesariuszy z ilościowymi wskaźnikami.
Te funkcje czynią RTM niezastąpioną w średnich i dużych projektach z dużą liczbą wymagań.
Typy śledzalności w RTM
Istnieją różne podejścia do budowania powiązań:
| Typ | Kierunek powiązania | Zastosowanie |
|-----|-------------------|------------|
| Prosta (Forward) | Wymaganie → Przypadek testowy | Sprawdzenie obecności testów dla wymagania |
| Odwrotna (Backward) | Przypadek testowy → Wymaganie | Uzasadnienie potrzeby testu |
| Dwukierunkowa (Bidirectional) | Wymaganie ⇄ Przypadek testowy | Pełna kontrola w obie strony |
| Pionowa | Wymaganie → Projekt → Kod → Test | Kompleksowe śledzenie po etapach |
| Pozioma | Test → Błąd → Naprawa → Retest | Śledzenie w ramach testowania |
Wybór typu zależy od złożoności projektu i etapu rozwoju.
Struktura kolumn w tabeli RTM
Standardowa macierz obejmuje następujące pola:
- Requirement ID – unikalny identyfikator (REQ-AUTH-01).
- Requirement Description – krótki opis (autoryzacja przez email).
- Test Case ID – lista powiązanych przypadków testowych (TC-LOGIN-01, TC-LOGIN-02).
- Test Status – status wykonania (Pass/Fail/Blocked/Not Run).
- Defect ID – identyfikatory defektów (BUG-101).
- Defect Status – status błędu (Open/Fixed/Closed).
- Coverage Status – status pokrycia (Covered/Not Covered/Partial).
- Coverage % – procent pokrycia (100%/0%/50%).
Przykłady tabel RTM
Podstawowa tabela (wymagania i przypadki testowe)
| REQ ID | Wymaganie | Priorytet | Test Case ID | Status testu | Defect ID | % pokrycia |
|--------|------------|-----------|--------------|--------------|-----------|------------|
| REQ-01 | Autoryzacja | Wysoki | TC-LOGIN-01, TC-LOGIN-02, TC-LOGIN-03 | Pass, Pass, Fail | BUG-101 | 100% |
| REQ-02 | Odzyskiwanie hasła | Średni | TC-REC-01, TC-REC-02 | Pass, Not Run | — | 50% |
| REQ-04 | Filtrowanie po cenie | Niski | — | — | — | 0% |
Rozszerzona tabela z powiązaniem do rozwoju
| REQ ID | Wymaganie | Test Case ID | Wynik | Defect ID | Zadanie dev | Komponent |
|--------|------------|--------------|-----------|-----------|----------|-----------|
| REQ-01 | Logowanie do systemu | TC-AUTH-01 | ✅ Pass | — | TASK-101 | Moduł Auth |
| REQ-01 | Logowanie do systemu | TC-AUTH-03 | ❌ Fail | BUG-001 | TASK-101 | Moduł Auth |
Takie tabele pozwalają szybko zlokalizować problematyczne obszary.
Schematy tekstowe śledzenia
Klasyczne proste powiązanie
┌──────────────┐ ┌──────────────┐ ┌──────────────┐
│ WYMAGANIE │ │ PRZYPADEK │ │ DEFEKT │
│ REQ-01 ──────┼─────▶│ TEST. TC-01 ─┼─────▶│ BUG-101 │
└──────────────┘ └──────────────┘ └──────────────┘Kompleksowe pionowe śledzenie
┌─────────────────────┐
│ WYMAGANIE BIZNESOWE │
└──────────┬──────────┘
▼
┌─────────────────────┐ ┌─────────────┐
│ WYMAGANIA │───▶│ PRZYPADKI │
│ FUNKCJONALNE │ │ TESTOWE │
└──────────┬──────────┘ └──────┬──────┘
│ │
▼ ▼
┌─────────┐ ┌─────────────────────┐
│ZADANIA │ │ WYKONANIE TESTOW │
│TECHNICZ.│ └──────────┬──────────┘
└────┬────┘ │
│ ▼
└────────────────────┬───────┘
│
┌─────────────────────┐
│ DEFEKTY │
└─────────────────────┘Analiza statystyk pokrycia
Typowy raport RTM zawiera:
| Wskaźnik | Wartość | Formuła |
|------------|----------|---------|
| Wszystkie wymagania | 50 | — |
| Z testami | 45 | — |
| Bez testów | 5 | — |
| % pokrycia | 90% | (45/50)×100% |
| Testów na wymaganie (śr.) | 3.6 | 180/50 |
Częste błędy: nieaktualna macierz, formalne powiązania, brak powiązania defektów, duplikaty testów.
Checklista dla inżynierów QA
- Każde wymaganie ma co najmniej jeden przypadek testowy.
- Nie ma "wiszących" przypadków testowych bez powiązania.
- Przy zmianie wymagania aktualizowane są powiązane testy.
- Każdy defekt jest powiązany z wymaganiem.
- Macierz jest aktualizowana po sprincie/wydaniu.
- Możliwa analiza przyczyn niepowodzeń przez RTM.
Narzędzia automatyzacji RTM
| Narzędzie | Typ | Cechy |
|------------|-----|-------------|
| Jira + Xray/Zephyr | Wtyczki | Śledzenie Agile |
| TestRail | Zarządzanie testami | Natywna RTM |
| Qase | Zarządzanie testami | Proste powiązania |
| Excel/Google Sheets | Ręczne | Dla małych projektów |
| Polarion/Azure DevOps | ALM | Poziom enterprise |
Kiedy rezygnować z RTM
Macierz nie nadaje się dla:
- Projektów z <20 wymaganiami.
- Zespołów <3 osób.
- Krótkich sprintów (1-2 tygodnie).
- Testowania ad-hoc lub MVP z częstymi zmianami.
Wady: wysoki nakład pracy przy aktualizacjach, ryzyko formalizmu, obciążenie dla startupów.
Zasada: RTM opłaca się przy >20 wymaganiach i zespole od 3 osób.
Co jest ważne
- RTM zapewnia 90%+ pokrycie wymagań testami w dużych projektach.
- Śledzenie dwukierunkowe minimalizuje ryzyka przy regresji.
- Aktualność macierzy – klucz do jej wartości; aktualizuj po każdej zmianie.
- Używaj narzędzi ALM do automatyzacji na poziomie enterprise.
- Analizuj metryki: luki w pokryciu i przypadki testowe na wymaganie.
— Editorial Team
Brak komentarzy.