Матрица трассировки требований

• Описание
  • Нюансы
• Пример матрицы
• Роль матрицы в тестировании
• Типы RTM-матриц
  • Прямая
  • Обратная
• Компоненты матрицы
• Инструменты создания RTM-матрицы
• Требования и тест-кейсы

Описание

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

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

• Матрица отслеживания требований
• Матрица прослеживаемости требований
• Матрица сверки требований
• Матрица слежения за требованиями
• Матрица соответствия требований
• и просто матрица требований 

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

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

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

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

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

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

Нюансы

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

Пример матрицы отслеживания требований

Роль матрицы в тестировании

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

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

Дополнительная польза RTM

• Помогает отслеживать тестовую документацию (артефакты), созданную в SDLC-цикле.
• Качественный контроль выполнения требований
• Помогает лучше отслеживать причины багов и их кластеризацию

Типы матрицы

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

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

Прямое отслеживание

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

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

Обратное отслеживание

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

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

Двусторонняя Матрица

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

Компоненты RTM-матрицы 

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

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

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

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

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

Инструменты

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

Visure Requirements

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

Сайт

Modern Requirements4DevOps

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

Сайт

ReQtest

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

Сайт

Требования и тест-кейсы в матрице

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

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

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

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

Например,

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

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

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

Например, 

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

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

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

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

Имплементация требований возможна разными путями

Например, 

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

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

Требования могут зависеть от других требований

Например,

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

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

***

Источники 1,2

Бизнес-аналитиком стать проще, чем тестировщиком?