Что такое матрица трассировки требований?

Что такое матрица трассировки требований?

Матрица трассировки требований (Requirements Traceability Matrix, RTM) — это таблица, которая связывает требования с тест-кейсами, чтобы убедиться, что каждое требование покрыто тестами и каждый баг связан с требованием.

Суть

RTM отвечает на вопрос: "Какое требование проверяет каждый тест и какой тест проверяет каждое требование?"

Структура RTM

Элементы RTM

Требование (Requirement):

• Уникальный ID: REQ-001
• Описание: что должна делать система
• Статус: Approved, In Development, Ready for Test, Done

Тест-кейс:

• ID: TC-001
• Линк на требование: REQ-001
• Статус: Passed, Failed, Not Run

Баги:

• ID: BUG-XXX
• Какое требование нарушает
• Статус: Open, Fixed, Closed

Примеры использования

Пример 1: Проверка покрытия

Требование: "Пользователь может редактировать свой профиль"

Я ищу в RTM, есть ли тест-кейсы для этого требования:

• TC-050: edit profile name ✓
• TC-051: edit profile email ✓
• TC-052: edit profile picture ✓
• TC-053: edit profile bio ✓

Все подпункты покрыты. Хорошо.

Но я замечу, что нет теста для:

• Сохранение при отключённом JavaScript
• Сохранение при потере интернета
• Сохранение при upload большого файла

Я добавлю эти тест-кейсы.

Пример 2: Баги и требования

Найден баг BUG-101: "При редактировании профиля теряются данные при очень длинном имени"

Я связываю его с требованием REQ-015: "Поле имени должно принимать до 100 символов"

Tested: TC-054 (вводим 100 символов) — найдена проблема.

Пример 3: Статус требования

Требование REQ-020: "Экспорт данных в CSV"

Статус: Ready for Test Тест-кейсы: TC-070, TC-071, TC-072 Все тесты прошли? Да Баги? Нет

Вывод: Требование ГОТОВО к продакшену.

Зачем нужна RTM?

1. Покрытие: убедиться, что каждое требование тестируется
2. Трассировка: узнать, какой тест проверяет требование
3. Управление багами: связать баги с требованиями
4. Метрики: измерить, сколько требований готово
5. Регрессия: при изменении требования найти все связанные тесты

Как я создаю и поддерживаю RTM

Шаг 1: Список требований Получаю документ с требованиями (от Product Manager):

• REQ-001: Login
• REQ-002: Create Account
• REQ-003: Forgot Password
• ...

Шаг 2: Создать тест-кейсы Для каждого требования пишу тест-кейсы:

• REQ-001 → TC-001, TC-002, TC-003 (разные сценарии)

Шаг 3: Заполнить RTM

REQ-001 | Login | TC-001, TC-002, TC-003 | Ready | -

Шаг 4: Запустить тесты Все тесты прошли? Требование готово. Тесты упали? Нужно исправить код или уточнить требование.

Шаг 5: Баги и регрессия Если найден баг BUG-050:

• Какое требование нарушает? REQ-001
• Какой тест должен был это ловить? TC-001
• Почему тест не упал? Возможно, тест слабый
• Улучшить тест

Сложные сценарии

Сценарий 1: Одно требование, много тестов

REQ: "Payment должна работать на всех браузерах"

Тесты:

• TC-200: Payment в Chrome
• TC-201: Payment в Firefox
• TC-202: Payment в Safari
• TC-203: Payment в Edge
• TC-204: Payment на мобильном

Сценарий 2: Один тест, несколько требований

TC-300: "Полный жизненный цикл заказа"

Проверяет:

• REQ-050: Create Order
• REQ-051: Add Items
• REQ-052: Checkout
• REQ-053: Payment
• REQ-054: Confirmation Email

Сценарий 3: Требование без тестов

REQ-100: "Поддержка 10 языков"

Тесты? Нет!

Это проблема. Нужно либо:

• Написать тесты для каждого языка
• Или отметить, что требование не готово к тестированию

Инструменты для RTM

Excel/Google Sheets:

• Простой, всем понятен
• Можно поделиться
• Недостатки: версионирование, большие файлы

Jira:

• Встроена трассировка (через links)
• Удобно для Agile
• Интеграция с другими инструментами

TestRail/QTest:

• Специальные инструменты для QA
• Встроена RTM
• Красивые отчёты

Git (README.md):

• Можно хранить в коде
• Версионирование встроено
• Для agile команд

Мой опыт

На большом enterprise проекте я вёл RTM в Excel. 500+ требований, 2000+ тест-кейсов.

Данные:

• 95% требований имели тест-кейсы
• 5% требований не были покрыты (причина: слишком старые)
• 12 багов было найдено при пересмотре RTM
• Быстро определили, что тесты упускали edge cases

На Agile проекте вели RTM в Jira (через links requirement → test → bug).

• Упрощало жизнь
• Автоматические отчёты
• Легче масштабировать

Совет QA

RTM не должна быть идеальной с первого дня. Это живой документ:

• Обновляю регулярно (раз в спринт)
• Убираю старые требования
• Добавляю новые тесты
• Связываю баги
• Проверяю покрытие

Хорошая RTM экономит часы при отладке, регрессии и принятии решений о готовности к релизу.