Requirements Traceability Matrix (RTM) — це матриця трасування вимог, тобто спеціальна таблиця, яка пов’язує вимоги з відповідними тестами (а іноді й з дефектами).
У контексті тестування ПЗ RTM — це інструмент контролю повноти тестування, який дозволяє переконатися, що всі вимоги замовника перевірені хоча б одним тест-кейсом.
Простіше кажучи:
RTM — це документ, який допомагає відповісти на запитання: «Чи протестували ми все, що було потрібно?»
Основна мета RTM
- Забезпечити повне покриття вимог тестами
(жодна вимога не залишилася неперевіреною) - Відстежувати зміни у вимогах
(якщо вимога змінюється — легко зрозуміти, які тести потрібно оновити) - Підвищити прозорість і контроль якості
(менеджери, тестувальники й замовники бачать зв’язок між вимогами, тестами та дефектами)
Типова структура RTM
| ID вимоги | Опис вимоги | Джерело (BRD/SRS) | ID тест-кейсу | Статус тесту | Примітки |
| BR-01 | Авторизація користувача | BRD v1.2 | TC-01, TC-02 | Passed | |
| BR-02 | Перегляд балансу | BRD v1.2 | TC-03 | Failed | Відображається некоректна сума |
| BR-03 | Переказ коштів | BRD v1.2 | TC-04, TC-05 | In Progress | |
| NFR-01 | Час відгуку < 3 сек | SRS v1.4 | TC-06 | Passed | Нефункціональна вимога |
Роль RTM у тестуванні
Тестувальники використовують RTM для:
- Перевірки покриття — чи всі вимоги BRD/SRS мають тест-кейси.
- Відстеження дефектів — якщо тест не пройшов, можна відразу побачити, яку вимогу це стосується.
- Регресійного тестування — легко знайти, які тести потрібно оновити при зміні вимоги.
- Звітування — менеджери QA можуть швидко оцінити готовність проєкту до релізу.
Типи трасування
| Тип трасування | Опис |
| Forward Traceability | Від вимог → до тестів (чи всі вимоги протестовані) |
| Backward Traceability | Від тестів → до вимог (чи всі тести мають сенс і перевіряють реальні вимоги) |
| Bi-directional Traceability | У два боки — забезпечує повний контроль над змінами |
Формат RTM
RTM може бути:
- у вигляді Excel / Google Sheets;
- у Jira / TestRail / Zephyr як звіт;
- у Confluence у вигляді таблиці.