Содержание

Что такое матрица трассируемости (RTM)?
Основные цели RTM
Типы трассируемости
Из чего состоит RTM (колонки таблицы)
Примеры таблиц RTM
Схемы
Отчёт по RTM (статистика покрытия)
Чек-лист QA по RTM
Инструменты для ведения RTM
Когда RTM не нужна?
Итог
Заключение

1. Что такое матрица трассируемости (RTM)?

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

Простыми словами:

RTM позволяет ответить на три ключевых вопроса тестирования:

Без RTM — тестирование становится менее управляемым и прозрачным. С RTM — осознанное и измеримое тестирование.

2. Основные цели RTM

3. Типы трассируемости

4. Из чего состоит RTM (колонки таблицы)

5. Примеры таблиц RTM

Пример 1. Базовая матрица (Требования ↔ Тест-кейсы)

Пример 2. Расширенная матрица (с привязкой к коду)

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 (статистика покрытия)

Типичные ошибки при работе с RTM

На практике даже при наличии RTM команда часто сталкивается со следующими проблемами:

8. Чек-лист QA по RTM

• [ ] Каждое требование имеет хотя бы 1 тест-кейс?

• [ ] Есть ли “висящие” тест-кейсы без привязки к требованию?

• [ ] При изменении требования обновлены ли связанные тесты?

• [ ] Каждый ли дефект привязан к конкретному требованию?

• [ ] Можно ли ответить на вопрос: “Почему этот тест не пройден?” — через RTM?

• [ ] Обновляется ли RTM после каждого релиза/спринта?

9. Инструменты для ведения RTM

10. Когда RTM не нужна? (и её минусы)

Минусы RTM

Когда RTM не нужна (альтернативы)

Простое правило: Если в проекте больше 20 требований и команда от 3+ человек — RTM окупается. Если меньше — можно обойтись без неё.

11. Итог

Что даёт RTM на практике

Коротко о главном

1. RTM — это не самоцель, а инструмент. Её ценность не в таблице, а в ответах, которые она даёт.

2. Не нужна на всём подряд. Если проект маленький или требования меняются каждый день — пропустите. Если требований 20+ и команда от 3 человек — RTM сэкономит нервы.

3. Главное — актуальность. Мёртвая матрица хуже, чем её отсутствие. Договоритесь с командой обновлять её при каждом изменении требований.

4. Начните с малого. Не нужно сразу строить сложную связанную систему с кодом и дизайном. Начните с простой таблицы: Требование → Тест-кейс. Остальное добавите позже.

RTM — это инструмент навигации в тестировании.
Она не отвечает на вопрос «как тестировать?», но отлично отвечает на вопросы «что?», «зачем?» и «что пропустили?».

Чек-лист перед внедрением RTM

• [ ] В проекте больше 20 требований?

• [ ] Команда больше 3 человек?

• [ ] Требования меняются не каждый день?

• [ ] Есть кто-то, кто будет обновлять матрицу?

• [ ] Вы готовы тратить 15–30 минут в спринт на поддержку RTM?

Если ответили «да» на 3+ пункта — внедряйте. Если нет — возможно, RTM пока не нужна.

Одна фраза, которую стоит запомнить

RTM — это не бюрократия, а навигатор тестировщика.

12. Заключение

RTM — это не серебряная пуля и не панацея. Это инструмент навигации, который помогает тестировщику, разработчику и менеджеру говорить на одном языке.

Она не заменит навыки тестирования, не напишет тест-кейсы и не найдёт дефекты. Но она ответит на три главных вопроса:

1. Что мы уже проверили?

2. Что ещё не проверено?

3. Почему мы вообще это тестируем?

Если вы работаете над проектом, где требования исчисляются десятками, а команда — больше трёх человек — попробуйте внедрить RTM. Начните с простой таблицы в Google Sheets. Это займёт час, а сэкономит дни.

А если проект маленький или требования меняются каждый день — не усложняйте процесс. RTM подождёт.

Главное правило: инструмент должен работать на вас, а не вы на него.

Спасибо, что дочитали до конца. Успешных вам релизов и никаких багов в прод!