Содержание
Что такое матрица трассируемости (RTM)?
Основные цели RTM
Типы трассируемости
Из чего состоит RTM (колонки таблицы)
Примеры таблиц RTM
Схемы
Отчёт по RTM (статистика покрытия)
Чек-лист QA по RTM
Инструменты для ведения RTM
Когда RTM не нужна?
Итог
Заключение
1. Что такое матрица трассируемости (RTM)?
RTM (Requirements Traceability Matrix) — это документ (чаще всего таблица), который устанавливает и отслеживает связи между требованиями, тест-кейсами и дефектами на протяжении всего жизненного цикла продукта.
Простыми словами:
RTM позволяет ответить на три ключевых вопроса тестирования:
Вопрос | Как отвечает RTM |
|---|---|
Что мы протестировали? | Показывает требования, у которых есть тест-кейсы |
Что мы НЕ протестировали? | Подсвечивает требования без тестов (пробелы) |
Почему мы тестируем именно это? | Обеспечивает обратную связь: тест → требование |
Без RTM — тестирование становится менее управляемым и прозрачным. С RTM — осознанное и измеримое тестирование.
2. Основные цели RTM
Цель | Описание |
|---|---|
Оценка покрытия | Проверка, что все требования покрыты тестами |
Выявление пробелов | Обнаружение требований без тест-кейсов или тестов без требований |
Анализ влияния изменений | Понимание, какие тесты нужно перезапустить при изменении требования |
Прослеживаемость | Возможность отследить путь от требования до дефекта и наоборот |
Отчётность | Доказательство полноты тестирования перед стейкхолдерами |
3. Типы трассируемости
Тип | Связь | Назначение |
|---|---|---|
Прямая (Forward) | Требование → Тест-кейс | Проверка, что требование протестировано |
Обратная (Backward) | Тест-кейс → Требование | Понимание, зачем нужен этот тест |
Двунаправленная (Bidirectional) | Требование ⇄ Тест-кейс | Полная прослеживаемость в обе стороны |
Вертикальная | Требование → Дизайн → Код → Тест | Сквозная трассировка по этапам разработки |
Горизонтальная | Тест-кейс → Баг → Исправление → Ретест | Трассировка внутри этапа тестирования |
4. Из чего состоит RTM (колонки таблицы)
Колонка | Описание | Пример |
|---|---|---|
Requirement ID | Уникальный идентификатор требования | REQ-AUTH-01 |
Requirement Description | Краткое описание требования | Авторизация по email/паролю |
Test Case ID | Список тест-кейсов, покрывающих требование | TC-LOGIN-01, TC-LOGIN-02 |
Test Status | Статус выполнения тестов | Pass / Fail / Blocked / Not Run |
Defect ID | Баги, найденные при тестировании этого требования | BUG-101 |
Defect Status | Статус бага | Open / Fixed / Closed / Reopened |
Coverage Status | Статус покрытия требования тестами | Covered / Not Covered / Partial |
Coverage % | Процент покрытия требования тест-кейсами | 100% / 0% / 50% |
5. Примеры таблиц RTM
Пример 1. Базовая матрица (Требования ↔ Тест-кейсы)
REQ ID | Требование | Приоритет | Test Case ID | Статус теста | Defect ID | % покрытия |
|---|---|---|---|---|---|---|
REQ-01 | Авторизация пользователя | High | TC-LOGIN-01, TC-LOGIN-02, TC-LOGIN-03 | Pass, Pass, Fail | BUG-101 | 100% |
REQ-02 | Восстановление пароля | Medium | TC-REC-01, TC-REC-02 | Pass, Not Run | — | 50% |
REQ-03 | Поиск товаров по названию | High | TC-SEARCH-01, TC-SEARCH-02 | Pass, Pass | — | 100% |
REQ-04 | Фильтрация товаров по цене | Low | — | — | — | 0% (отсутствует покрытие) |
REQ-05 | Добавление товара в корзину | High | TC-CART-01, TC-CART-02, TC-CART-03 | Fail, Blocked, Pass | BUG-102, BUG-105 | 100% |
Пример 2. Расширенная матрица (с привязкой к коду)
REQ ID | Требование | Test Case ID | Результат | Defect ID | Dev Task | Компонент |
|---|---|---|---|---|---|---|
REQ-01 | Вход в систему | TC-AUTH-01 | ✅ Pass | — | TASK-101 | Auth Module |
REQ-01 | Вход в систему | TC-AUTH-02 | ✅ Pass | — | TASK-101 | Auth Module |
REQ-01 | Вход в систему | TC-AUTH-03 | ❌ Fail | BUG-001 | TASK-101 | Auth Module |
REQ-02 | Регистрация | TC-REG-01 | ✅ Pass | — | TASK-102 | User Service |
REQ-02 | Регистрация | TC-REG-02 | ⛔ Blocked | BUG-002 | TASK-102 | User Service |
6. Схемы (текстовые диаграммы)
Схема 1. Классическая RTM (прямая связь)
┌──────────────┐ ┌──────────────┐ ┌──────────────┐ │ ТРЕБОВАНИЕ │ │ ТЕСТ-КЕЙС │ │ ДЕФЕКТ │ │ │ │ │ │ │ │ REQ-01 ──────┼─────▶│ TC-01 ───────┼─────▶│ BUG-101 │ │ REQ-02 ──────┼─────▶│ TC-02 │ │ BUG-102 │ │ REQ-03 ──────┼─────▶│ TC-03 │ │ │ │ REQ-04 ──────┼─────▶│ TC-04 │ │ │ └──────────────┘ └──────────────┘ └──────────────┘ КЛЮЧ: ──▶ Прямая связь (Forward) ◀── Обратная связь (Backward)
Схема 2. Полная сквозная трассировка (вертикальная)
┌─────────────────────┐ │ БИЗНЕС-ТРЕБОВАНИЕ │ │ (User Story) │ └──────────┬──────────┘ │ ▼ ┌─────────────────────┐ │ ФУНКЦИОНАЛЬНЫЕ │ │ ТРЕБОВАНИЯ (SRS) │ └──────────┬──────────┘ │ ┌─────┴─────┬─────────────┐ │ │ │ ▼ ▼ ▼ ┌─────────┐ ┌─────────┐ ┌─────────────┐ │ТЕХНИЧ. │ │ ДИЗАЙН │ │ ТЕСТ- │ │ЗАДАЧИ │ │ (UI/UX) │ │ КЕЙСЫ │ │(Dev Task)│ │ │ │ │ └────┬────┘ └────┬────┘ └──────┬──────┘ │ │ │ └─────┬─────┘ │ │ │ └─────────┬─────────┘ │ ▼ ┌─────────────────────┐ │ ВЫПОЛНЕНИЕ ТЕСТОВ │ │ (Test Execution) │ └──────────┬──────────┘ │ ▼ ┌─────────────────────┐ │ ДЕФЕКТЫ │ │ (Bugs) │ └─────────────────────┘
Схема 3. Анализ влияния изменений (зачем это нужно)
ИЗМЕНИЛИ ТРЕБОВАНИЕ REQ-01 (Авторизация) │ ▼ ┌─────────────────────────────────────────────────────────────┐ │ RTM показывает: │ │ │ │ REQ-01 связан с: │ │ • TC-LOGIN-01 (Pass) → Нужно перезапустить │ │ • TC-LOGIN-02 (Pass) → Нужно перезапустить │ │ • TC-LOGIN-03 (Fail → BUG-101) → Баг требует ретеста │ │ │ │ Также REQ-01 влияет на REQ-02 (Восстановление пароля) │ └─────────────────────────────────────────────────────────────┘ │ ▼ → QA знает, какие тесты запускать → Dev понимает, какой код может сломаться
7. Отчёт по RTM (статистика покрытия)
Показатель | Значение | Формула |
|---|---|---|
Всего требований | 50 | — |
Требований с тестами | 45 | — |
Требований БЕЗ тестов | 5 | — |
Процент покрытия | 90% | (45 / 50) × 100% |
Требований с дефектами | 12 | — |
Тест-кейсов всего | 180 | — |
Тест-кейсов на 1 требование (сред.) | 3.6 | 180 / 50 |
Типичные ошибки при работе с RTM
На практике даже при наличии RTM команда часто сталкивается со следующими проблемами:
Ошибка | Почему это плохо |
|---|---|
RTM не обновляется | Быстро устаревает и перестаёт отражать реальное состояние проекта |
Формальная привязка тестов | Создаёт ложное ощущение покрытия без реальной проверки требований |
Нет связи с дефектами | Сложно анализировать проблемные области и приоритизировать баги |
Дублирование тестов | Искажает метрики и увеличивает время прогона без пользы |
Нет обратной трассируемости | Появляются “висящие” тесты без понятного назначения |
Игнорируется частичное покрытие | Требования считаются покрытыми, хотя проверены не полностью |
8. Чек-лист QA по RTM
[ ] Каждое требование имеет хотя бы 1 тест-кейс?
[ ] Есть ли “висящие” тест-кейсы без привязки к требованию?
[ ] При изменении требования обновлены ли связанные тесты?
[ ] Каждый ли дефект привязан к конкретному требованию?
[ ] Можно ли ответить на вопрос: “Почему этот тест не пройден?” — через RTM?
[ ] Обновляется ли RTM после каждого релиза/спринта?
9. Инструменты для ведения RTM
Инструмент | Тип | Особенность |
|---|---|---|
Jira + Xray/Zephyr | Плагины | Встроенная трассировка, удобно для Agile |
TestRail | Тест-менеджмент | Нативная поддержка RTM |
Qase | Тест-менеджмент | Простая связь требований и тестов |
Excel / Google Sheets | Ручной | Бесплатно, но трудоёмко на больших проектах |
Polarion | ALM | Промышленное решение для Enterprise |
Azure DevOps | ALM | Встроенная трассировка |
10. Когда RTM не нужна? (и её минусы)
Минусы RTM
Минус | Описание |
|---|---|
Трудоёмкость поддержки | Каждое изменение требования → нужно обновлять матрицу. На больших проектах это отдельная работа |
Оверхед на маленьких проектах | Если у вас 5-10 требований и команда из 2 человек — RTM будет лишней бюрократией |
Риск формального подхода | Можно заполнить RTM «для галочки», но реальной пользы не получить |
Зависимость от актуальности | Если матрицу не обновлять — она превращается в мусор, которому нельзя доверять |
Входной порог | Новички в команде могут не понимать, зачем это нужно, и игнорировать |
Когда RTM не нужна (альтернативы)
Ситуация | Что делать вместо RTM |
|---|---|
Стартап с 5-10 требованиями | Достаточно простого списка в Trello / Notion / Google Sheets без жёстких связей |
Проект на 1-2 недели | RTM просто не успеет окупить затраты на её ведение |
Команда из 1-2 человек | Вся трассировка у тебя в голове — документ будет лишним |
Исследовательское тестирование (Ad-hoc) | Нет чётких требований — нет и RTM |
Прототип / MVP | Требования меняются каждый день — RTM будет устаревать быстрее, чем ты её заполняешь |
Простое правило: Если в проекте больше 20 требований и команда от 3+ человек — RTM окупается. Если меньше — можно обойтись без неё.
11. Итог
Что даёт RTM на практике
Было без RTM | Стало с RTM |
|---|---|
Тестируешь непонятно что | Чётко видишь покрытие |
Изменение в требовании = хаос | Знаешь, какие тесты перезапускать |
Баги висят без привязки | Каждый баг → требование → приоритет |
Стейкхолдерам нечем отчитаться | Есть цифры и проценты |
Тесты дублируются или устарели | Видно, какие тесты можно удалить или объединить |
После релиза страшно: «А вдруг что-то пропустили?» | Есть доказательство: «Вот матрица, всё проверено» |
Коротко о главном
RTM — это не самоцель, а инструмент. Её ценность не в таблице, а в ответах, которые она даёт.
Не нужна на всём подряд. Если проект маленький или требования меняются каждый день — пропустите. Если требований 20+ и команда от 3 человек — RTM сэкономит нервы.
Главное — актуальность. Мёртвая матрица хуже, чем её отсутствие. Договоритесь с командой обновлять её при каждом изменении требований.
Начните с малого. Не нужно сразу строить сложную связанную систему с кодом и дизайном. Начните с простой таблицы: Требование → Тест-кейс. Остальное добавите позже.
RTM — это инструмент навигации в тестировании.
Она не отвечает на вопрос «как тестировать?», но отлично отвечает на вопросы «что?», «зачем?» и «что пропустили?».
Чек-лист перед внедрением RTM
[ ] В проекте больше 20 требований?
[ ] Команда больше 3 человек?
[ ] Требования меняются не каждый день?
[ ] Есть кто-то, кто будет обновлять матрицу?
[ ] Вы готовы тратить 15–30 минут в спринт на поддержку RTM?
Если ответили «да» на 3+ пункта — внедряйте. Если нет — возможно, RTM пока не нужна.
Одна фраза, которую стоит запомнить
RTM — это не бюрократия, а навигатор тестировщика.
12. Заключение
RTM — это не серебряная пуля и не панацея. Это инструмент навигации, который помогает тестировщику, разработчику и менеджеру говорить на одном языке.
Она не заменит навыки тестирования, не напишет тест-кейсы и не найдёт дефекты. Но она ответит на три главных вопроса:
Что мы уже проверили?
Что ещё не проверено?
Почему мы вообще это тестируем?
Если вы работаете над проектом, где требования исчисляются десятками, а команда — больше трёх человек — попробуйте внедрить RTM. Начните с простой таблицы в Google Sheets. Это займёт час, а сэкономит дни.
А если проект маленький или требования меняются каждый день — не усложняйте процесс. RTM подождёт.
Главное правило: инструмент должен работать на вас, а не вы на него.
Спасибо, что дочитали до конца. Успешных вам релизов и никаких багов в прод!
