# Матрица трассировки требований(RTM)

<figure><img src="https://i0.wp.com/testengineer.ru/wp-content/uploads/2023/03/1-1.png?resize=696%2C399&#x26;ssl=1" alt="Матрица трассируемости требований" height="399" width="696"><figcaption><p>Матрица трассируемости требований</p></figcaption></figure>

Документ табличного вида, предназначенный для контроля выполнения требований к продукту. В RTM-матрице требования «прикреплены» к соответствующим тест-кейсам.&#x20;

Данный QA-термин — абсолютный рекордсмен по количеству русскоязычных названий. Их не меньше десяти:

* Матрица отслеживания требований
* Матрица прослеживаемости требований
* Матрица сверки требований
* Матрица слежения за требованиями
* Матрица соответствия требований
* и просто матрица требований&#x20;

Также встречаются названия:&#x20;

* Матрица трассировки требований
* Матрица трассируемости (и именно это название одобрено ISTQB)
* и матрица трассабилити.&#x20;
* Также называют просто RTM-матрицей.

Отслеживание требований может быть как *прямое* («от требований к коду»), так и *обратное* («от кода к требованиям»).&#x20;

В матрице сопоставляем все требования с соответствующими тест-кейсами, убеждаясь, что для каждого требования есть хотя бы один тест-кейс.

RTM-матрица наполняется тестировщиками, отвечающими за функцию/модуль/часть приложения, и передается менеджеру или лиду. Лид проверяет репозитории, и если соответствующие тест-кейсы существуют, утверждает матрицу. В общем виде это простая стандартная worksheet-таблица, создаваемая по шаблону.

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

#### Нюансы <a href="#tips" id="tips"></a>

* Матрица создается до утверждения требований и перед выполнением тест-кейсов
* Матрицу пишут с учетом, что какой-то тест-кейс может быть отменен
* Задача матрицы отслеживания — чтобы каждое требование имело хотя бы один тест-кейс, не обязательно чтобы на одно требование было много тест-кейсов

### Пример матрицы отслеживания требований <a href="#examples" id="examples"></a>

<figure><img src="https://i0.wp.com/testengineer.ru/wp-content/uploads/2023/03/2-1.png?resize=696%2C372&#x26;ssl=1" alt="Матрица отслеживания требований" height="372" width="696"><figcaption><p>Матрица отслеживания требований</p></figcaption></figure>

### Роль матрицы в тестировании <a href="#role" id="role"></a>

Тестировщик должен хорошо понять требования клиента и позаботиться, чтобы в финальном продукте не было багов. Он создает позитивные и негативные тест-кейсы по отдельным требованиям.&#x20;

Вопрос: как гарантировать, что каждое требование протестировано по всем потенциальным сценариям и кейсам, что ни одно требование не пропущено? Проще всего и быстрее — сопоставлением в таблице-матрице. Указывается также текущий статус тест-кейсов, то есть прошел / не прошел. Это помогает команде оценивать продвижение с требованиями.

#### Дополнительная польза RTM <a href="#h-rtm" id="h-rtm"></a>

* Помогает отслеживать тестовую документацию (артефакты), созданную в [SDLC-цикле](https://testengineer.ru/zhiznennyj-cikl-testirovaniya-prilozhenij/).
* Качественный контроль выполнения требований
* Помогает лучше отслеживать причины багов и их [кластеризацию](https://testengineer.ru/sem-glavnyh-principov-testirovaniya/#:~:text=%D0%9A%D0%BB%D0%B0%D1%81%D1%82%D0%B5%D1%80%D0%B8%D0%B7%D0%B0%D1%86%D0%B8%D1%8F%20%D0%B4%D0%B5%D1%84%D0%B5%D0%BA%D1%82%D0%BE%D0%B2%20%E2%80%94%20%D0%BF%D1%80%D0%B8%D0%BD%D1%86%D0%B8%D0%BF%2C%20%D0%BA%D0%BE%D1%82%D0%BE%D1%80%D1%8B%D0%B9%20%D0%BF%D1%80%D0%B5%D0%B4%D0%BF%D0%BE%D0%BB%D0%B0%D0%B3%D0%B0%D0%B5%D1%82,%D0%BB%D0%B5%D0%B3%D0%BA%D0%BE%20%D0%BE%D0%BF%D1%80%D0%B5%D0%B4%D0%B5%D0%BB%D0%B8%D1%82%D1%8C%20%D1%8D%D1%82%D0%B8%20%D0%BF%D1%80%D0%BE%D0%B1%D0%BB%D0%B5%D0%BC%D0%BD%D1%8B%D0%B5%20%D0%BC%D0%BE%D0%B4%D1%83%D0%BB%D0%B8.)

### Типы матрицы <a href="#types" id="types"></a>

Существует три типа матрицы сверки требований:

* Прямая
* Обратная
* Двунаправленная

#### Прямое отслеживание <a href="#forward" id="forward"></a>

Помогает проверить, что каждое бизнес-требование корректно имплементировано и качественно протестировано, что разработка продукта идет правильно.&#x20;

Требования сопоставляются с тест кейсами в таком виде:

<figure><img src="https://i0.wp.com/testengineer.ru/wp-content/uploads/2023/03/3-1.png?resize=696%2C455&#x26;ssl=1" alt="Матрица трассабилити - прямая" height="455" width="696"><figcaption><p>Матрица трассабилити — прямая</p></figcaption></figure>

#### Обратное отслеживание <a href="#backward" id="backward"></a>

Обратное отслеживание применяется, когда есть вероятность, что время и средства уходят на улучшение необязательных элементов дизайна, бесконечное совершенствование кода, или тестирование вещей, которых нет в бизнес-требованиях. Главная цель — «удерживать проект на нужном пути».&#x20;

Требования сопоставляются с тест-кейсами в таком виде:

<figure><img src="https://i0.wp.com/testengineer.ru/wp-content/uploads/2023/03/4.png?resize=696%2C258&#x26;ssl=1" alt="Матрица трассабилити - обратная" height="258" width="696"><figcaption><p>Матрица трассабилити — обратная</p></figcaption></figure>

#### Двусторонняя Матрица <a href="#h" id="h"></a>

Комбинация перечисленных выше подходов. Помогает оценить изменения в требованиях, возникающие в результате дефектов.

### Компоненты RTM-матрицы  <a href="#components" id="components"></a>

* ID требования
* Тип и описание требования
* Статус тест-кейса

Например, RTM-матрица приложения заказа билетов:

| ID или Номер требования | Описание требования | ID тест-кейса                       | Статус                                          |
| ----------------------- | ------------------- | ----------------------------------- | ----------------------------------------------- |
| 172                     | Логин в приложение  | TC01,TC02,TC03                      | TC01-PassTC02-Pass                              |
| 456                     | Создание билета     | TC04,TC05,TC06,TC07,TC08,TC09,TC010 | TC04-PassTC05-PassTC06-PassTC06-FailTC07-No Run |
| 676                     | Поиск билета        | TC011,TC012,TC013,TC014             | TC011-PassTC012-FailTC013-PassTC014-No Run      |

RTM-матрица — общепринятая вещь в QA. Кроме тест-кейсов и требований, могут быть и другие, дополняющие, параметры:

* Количество тест-кейсов, нужных для покрытия всех требований
* По специфическим тест-кейсам — статус их создания + статус выполнения
* Если проводится приемочное тестирование, регистрируется приемочный статус
* Фиксируются ошибки и примечания

В простейшем случае матрица представляет собой просто excel-файл, а чаще ссылку в Google Sheets, а иногда команда пользуется инструментами, автоматически формирующими RTM-матрицу. Это проще, однако такие инструменты чаще всего платные.

### Инструменты <a href="#tools" id="tools"></a>

Если Excel (Google Sheet) не нравится, есть альтернативы:

#### Visure Requirements <a href="#h-visure-requirements" id="h-visure-requirements"></a>

От компании, специализирующейся на обслуживании проектов, связанных с медициной и безопасностью.

[Сайт](https://visuresolutions.com/requirements-management-tool/)

#### Modern Requirements4DevOps <a href="#h-modern-requirements4devops" id="h-modern-requirements4devops"></a>

Интегрирован с Microsoft Azure DevOps, TFS, и VSTS, удобен для менеджеров

[Сайт](https://www.modernrequirements.com/)

#### ReQtest <a href="#h-reqtest" id="h-reqtest"></a>

Полное отслеживание требований. Облачный инструмент. Гибко настраивается.

[Сайт](https://reqtest.com/)

<figure><img src="https://i0.wp.com/testengineer.ru/wp-content/uploads/2023/03/5.png?resize=696%2C487&#x26;ssl=1" alt="Матрица трассируемости в ReQtest" height="487" width="696"><figcaption><p>Матрица трассируемости в ReQtest</p></figcaption></figure>

### Требования и тест-кейсы в матрице <a href="#traceability" id="traceability"></a>

#### Уточнение требований

Например, **требование**: имплементировать функцию *Написать письмо* в email-приложении.

**Имплементация**: уточнение, где кнопка *Написать письмо* будет расположена на главной странице?

#### Обязательно ли это требование?

Например,

**Требование**: только указанные пользователи могут видеть функцию *Написать письмо* в этом приложении.

**Имплементация**: если папка *Входящие* временно поставлена пользователем в статус «Закрыта на запись», кнопка *Написать письмо* не обязательна в данный момент.

#### Требования могут быть многоступенчатыми

Например,&#x20;

**Требование**: добавить кнопку *Написать письмо с особыми шрифтами и прикреплениями* в email-приложении.

**Имплементация**: какие функции будут доступны после нажатия кнопки *Написать письмо*?

* Нужен доступ к телу письма, возможность создавать и редактировать текст, а также изменять шрифты и стили в том числе жирный, курсив, и подчеркивание.
* Прикрепления многих типов: рисунки, документы, другие письма, архивы.
* Оценка объема прикрепления (не больше максимального объема)

Как видим, требования могут делиться на дополнительные/вложенные требования.

#### Имплементация требований возможна разными путями <a href="#h--1" id="h--1"></a>

Например,&#x20;

**Требование**: все папки в почтовом ящике, типа *Входящие, Отправить, Черновики, Спам, Корзина*, должны быть видимы и доступны.&#x20;

**Имплементация**: все эти элементы должны быть иметь формат Дерева (Tree) или Вкладок (Tabs)

#### Требования могут зависеть от других требований <a href="#h--2" id="h--2"></a>

Например,

**Требование:** в email-приложении должна быть Корзина.

**Имплементация**: если опция *Корзина* в приложении доступна, сначала должно быть имплементировано (и значит протестировано) требование *Удалить письмо*. Если требование (функция) работает нормально, удаленные письма будут отправляться в *Корзину*, и требование наличия и доступности *Корзины* можно имплементировать.


---

# Agent Instructions: Querying This Documentation

If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter:

```
GET https://igor-19.gitbook.io/qa/ocenka-pokrytie-test-keisami-ui-avtotestami-coverage/matrica-trassirovki-trebovanii-rtm.md?ask=<question>
```

The question should be specific, self-contained, and written in natural language.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.