Matrice sledovatelnosti požadavků: struktura a využití v QA
Matrice sledovatelnosti požadavků (Requirements Traceability Matrix, RTM) je tabulka, která zaznamenává vazby mezi požadavky, testovacími případy a defekty ve všech fázích životního cyklu softwaru. Poskytuje odpovědi na klíčové otázky: co je otestováno, co zůstalo nepokryto, proč se provádí konkrétní test.
Bez RTM se testování stává netransparentním, s RTM se mění na měřitelný proces s jasnými metrikami pokrytí.
Cíle použití matrice
RTM řeší následující úkoly:
- Hodnocení úplnosti pokrytí požadavků testy.
- Identifikace mezer v testovací dokumentaci.
- Analýza dopadu změn požadavků na existující testy.
- Sledování cesty od požadavku k defektu.
- Tvorba reportů pro stakeholdery s kvantitativními ukazateli.
Tyto funkce činí RTM nepostradatelnou ve středních a velkých projektech s velkým objemem požadavků.
Typy sledovatelnosti v RTM
Existují různé přístupy k vytváření vazeb:
| Typ | Směr vazby | Použití |
|-----|-------------------|------------|
| Přímá (Forward) | Požadavek → Testovací případ | Kontrola existence testů pro požadavek |
| Zpětná (Backward) | Testovací případ → Požadavek | Zdůvodnění nutnosti testu |
| Obousměrná (Bidirectional) | Požadavek ⇄ Testovací případ | Úplná kontrola v obou směrech |
| Vertikální | Požadavek → Design → Kód → Test | Průběžná sledovatelnost napříč fázemi |
| Horizontální | Test → Bug → Oprava → Retest | Sledovatelnost v rámci testování |
Výběr typu závisí na složitosti projektu a fázi vývoje.
Struktura sloupců v tabulce RTM
Standardní matice obsahuje následující pole:
- Requirement ID — jedinečný identifikátor (REQ-AUTH-01).
- Requirement Description — stručný popis (autorizace přes email).
- Test Case ID — seznam souvisejících testovacích případů (TC-LOGIN-01, TC-LOGIN-02).
- Test Status — stav provedení (Pass/Fail/Blocked/Not Run).
- Defect ID — identifikátory defektů (BUG-101).
- Defect Status — stav bugu (Open/Fixed/Closed).
- Coverage Status — stav pokrytí (Covered/Not Covered/Partial).
- Coverage % — procento pokrytí (100%/0%/50%).
Příklady tabulek RTM
Základní tabulka (požadavky a testovací případy)
| REQ ID | Požadavek | Priorita | Test Case ID | Stav testu | Defect ID | % pokrytí |
|--------|------------|-----------|--------------|--------------|-----------|------------|
| REQ-01 | Autorizace | High | TC-LOGIN-01, TC-LOGIN-02, TC-LOGIN-03 | Pass, Pass, Fail | BUG-101 | 100% |
| REQ-02 | Obnova hesla | Medium | TC-REC-01, TC-REC-02 | Pass, Not Run | — | 50% |
| REQ-04 | Filtrování podle ceny | Low | — | — | — | 0% |
Rozšířená tabulka s vazbou na vývoj
| REQ ID | Požadavek | Test Case ID | Výsledek | Defect ID | Dev Task | Komponenta |
|--------|------------|--------------|-----------|-----------|----------|-----------|
| REQ-01 | Přihlášení do systému | TC-AUTH-01 | ✅ Pass | — | TASK-101 | Auth Module |
| REQ-01 | Přihlášení do systému | TC-AUTH-03 | ❌ Fail | BUG-001 | TASK-101 | Auth Module |
Takové tabulky umožňují rychle lokalizovat problematické oblasti.
Textové schémata sledovatelnosti
Klasická přímá vazba
┌──────────────┐ ┌──────────────┐ ┌──────────────┐
│ POŽADAVEK │ │ TESTOVACÍ │ │ DEFEKT │
│ REQ-01 ──────┼─────▶│ PŘÍPAD │ │ BUG-101 │
│ │ │ TC-01 ───────┼─────▶│ │
└──────────────┘ └──────────────┘ └──────────────┘Průběžná vertikální sledovatelnost
┌─────────────────────┐
│ BYZNYS-POŽADAVEK │
└──────────┬──────────┘
▼
┌─────────────────────┐ ┌─────────────┐
│ FUNKČNÍ │───▶│ TESTOVACÍ │
│ POŽADAVKY │ │ PŘÍPADY │
└──────────┬──────────┘ └──────┬──────┘
│ │
▼ ▼
┌─────────┐ ┌─────────────────────┐
│TECHN. │ │ PROVEDENÍ TESTŮ │
│ÚKOLY │ └──────────┬──────────┘
└────┬────┘ │
│ ▼
└────────────────────┬───────┘
│
┌─────────────────────┐
│ DEFEKTY │
└─────────────────────┘Analýza statistik pokrytí
Typický report podle RTM obsahuje:
| Ukazatel | Hodnota | Vzorec |
|------------|----------|---------|
| Celkem požadavků | 50 | — |
| S testy | 45 | — |
| Bez testů | 5 | — |
| % pokrytí | 90% | (45/50)×100% |
| Testů na požadavek (prům.) | 3.6 | 180/50 |
Časté chyby: neaktuální matice, formální vazby, absence vazby defektů, duplicitní testy.
Kontrolní seznam pro QA inženýry
- Každý požadavek má minimálně jeden testovací případ.
- Neexistují "visící" testovací případy bez vazby.
- Při změně požadavku se aktualizují související testy.
- Každý defekt je spojen s požadavkem.
- Matice se aktualizuje po sprintu/releasu.
- Možná analýza příčin selhání prostřednictvím RTM.
Nástroje pro automatizaci RTM
| Nástroj | Typ | Specifika |
|------------|-----|-------------|
| Jira + Xray/Zephyr | Pluginy | Agile sledovatelnost |
| TestRail | Test management | Nativní RTM |
| Qase | Test management | Jednoduché vazby |
| Excel/Google Sheets | Ruční | Pro malé projekty |
| Polarion/Azure DevOps | ALM | Enterprise úroveň |
Kdy se vzdát RTM
Matrice není vhodná pro:
- Projekty s <20 požadavky.
- Týmy <3 osob.
- Krátké sprintech (1-2 týdny).
- Ad-hoc testování nebo MVP s častými změnami.
Nevýhody: vysoká pracnost aktualizací, riziko formalismu, overhead pro startupy.
Pravidlo: RTM se vyplatí při >20 požadavcích a týmu od 3 osob.
Co je důležité
- RTM zajišťuje 90%+ pokrytí požadavků testy ve velkých projektech.
- Obousměrná sledovatelnost minimalizuje rizika při regresi.
- Aktualita matice je klíčem k její hodnotě; aktualizujte po každé změně.
- Používejte ALM nástroje pro automatizaci na enterprise úrovni.
- Analyzujte metriky: mezery v pokrytí a testovací případy na požadavek.
— Editorial Team
Zatím žádné komentáře.