Проблема покрытия
У вас 150 требований и 500 тест-кейсов. Как узнать, что каждое требование покрыто хотя бы одним тестом? Как узнать, что нет «осиротевших» тест-кейсов, тестирующих функции, которых больше не существует? Когда требование меняется, какие тест-кейсы нужно обновить?
Без систематического способа связать требования с тестами на эти вопросы практически невозможно ответить. Матрица трассировки требований (RTM) и есть эта систематическая связь.
Что такое матрица трассировки требований?
RTM — это документ, обычно таблица или электронная таблица, которая связывает требования с тест-кейсами, а часто и с результатами тестов и дефектами. Она создаёт прослеживаемую цепочку от бизнес-потребности до верификации.
Ключевая идея — двунаправленная трассировка: можно проследить вперёд от требований к тестам (все ли требования покрыты?) и назад от тестов к требованиям (каждый ли тест обоснован требованием?).
Типы трассировки
Прямая трассировка (Forward Traceability)
Связывает требования с тест-кейсами. Отвечает: «Каждое ли требование протестировано?»
| ID требования | Требование | ID тест-кейсов |
|---|---|---|
| REQ-001 | Пользователь может войти по email и паролю | TC-101, TC-102, TC-103 |
| REQ-002 | Пользователь может сбросить пароль через email | TC-104, TC-105 |
| REQ-003 | Сессия истекает после 30 мин неактивности | TC-106 |
| REQ-004 | Пользователь может включить 2FA | Нет |
Сразу видно, что REQ-004 не имеет тест-кейсов — это пробел в покрытии, который необходимо устранить.
Обратная трассировка (Backward Traceability)
Связывает тест-кейсы с требованиями. Отвечает: «Каждый ли тест обоснован?»
| ID тест-кейса | Тест-кейс | ID требования |
|---|---|---|
| TC-101 | Вход с валидными учётными данными | REQ-001 |
| TC-102 | Вход с неверным паролем | REQ-001 |
| TC-103 | Вход с пустыми полями | REQ-001 |
| TC-104 | Запрос на сброс пароля | REQ-002 |
| TC-105 | Сброс пароля по просроченной ссылке | REQ-002 |
| TC-106 | Таймаут сессии по неактивности | REQ-003 |
| TC-107 | Вход со спецсимволами в имени пользователя | Нет |
TC-107 не имеет привязанного требования — это может быть валидный тест граничного случая или тестирование чего-то за пределами скоупа. В любом случае, требуется ревью.
Двунаправленная трассировка
Объединяет оба направления в одной матрице. Это наиболее полная и наиболее часто используемая форма.
Структура полной RTM
Полная RTM обычно включает следующие колонки:
| Колонка | Описание | Пример |
|---|---|---|
| ID требования | Уникальный идентификатор | REQ-001 |
| Описание требования | Что должна делать система | «Пользователь может войти по email/паролю» |
| Приоритет | Бизнес-приоритет | Высокий |
| ID тест-кейсов | Связанные тест-кейсы | TC-101, TC-102, TC-103 |
| Статус тест-кейса | Текущий статус выполнения | Pass / Fail / Not Run |
| ID дефектов | Найденные дефекты | BUG-042 |
| Статус дефекта | Текущий статус дефекта | Open / Fixed / Verified |
| Комментарии | Дополнительный контекст | «Требует ревью безопасности» |
Пример: RTM корзины интернет-магазина
Вот реалистичный пример для функции корзины покупок:
| ID Req | Требование | Приоритет | Тест-кейсы | Статус | Дефекты |
|---|---|---|---|---|---|
| CART-01 | Добавить товар в корзину | Высокий | TC-201, TC-202, TC-203 | Pass, Pass, Pass | — |
| CART-02 | Обновить количество товара | Высокий | TC-204, TC-205 | Pass, Fail | BUG-089 |
| CART-03 | Удалить товар из корзины | Средний | TC-206 | Pass | — |
| CART-04 | Применить код купона | Средний | TC-207, TC-208, TC-209 | Pass, Pass, Not Run | — |
| CART-05 | Корзина сохраняется между сессиями | Низкий | TC-210 | Not Run | — |
| CART-06 | Показать оценку стоимости доставки | Средний | — | — | — |
Анализ:
- CART-02 имеет проваленный тест-кейс с открытым дефектом — требует внимания
- CART-04 имеет один ещё не выполненный тест-кейс
- CART-05 вообще не протестирован
- CART-06 не имеет тест-кейсов — это пробел в покрытии
Преимущества использования RTM
1. Выявление пробелов покрытия
Как показано выше, сканирование RTM мгновенно выявляет требования без тест-кейсов. Без RTM этот пробел мог бы остаться незамеченным до продакшна.
2. Анализ влияния
Когда требование меняется, RTM точно показывает, какие тест-кейсы затронуты. Без неё пришлось бы вручную просматривать сотни тест-кейсов.
Пример: Если CART-01 меняется с «добавить один товар» на «добавить один или несколько товаров», RTM показывает, что TC-201, TC-202 и TC-203 нуждаются в обновлении. Возможно, потребуется добавить новые тест-кейсы.
3. Отчётность о полноте тестирования
Менеджеры проекта и стейкхолдеры могут видеть с одного взгляда:
- Какой процент требований имеет тест-кейсы (покрытие)
- Какой процент тест-кейсов выполнен (прогресс)
- Сколько требований имеет пройденные тесты (уверенность)
4. Регуляторное соответствие
В регулируемых отраслях (здравоохранение, финансы, авиация) RTM часто обязательна. Аудиторы используют её для проверки, что каждое регуляторное требование протестировано и верифицировано.
5. Обнаружение расползания скоупа
Если обнаружены тест-кейсы, не привязанные ни к одному требованию, это может указывать на неофициальные функции или расползание скоупа, которое нужно обсудить со стейкхолдерами.
Создание RTM: пошаговое руководство
Шаг 1: Собрать требования
Соберите все требования из спецификаций, user stories, критериев приёмки, регуляторных документов и любых других источников. Присвойте каждому уникальный ID.
Шаг 2: Разработать тест-кейсы
Напишите тест-кейсы, покрывающие каждое требование. Стремитесь к минимум одному позитивному и одному негативному тест-кейсу на требование.
Шаг 3: Связать требования с тест-кейсами
Создайте матрицу, связывающую каждое требование с его тест-кейсами. Здесь устанавливается прямая трассировка.
Шаг 4: Проверить обратную трассировку
Убедитесь, что каждый тест-кейс связан хотя бы с одним требованием. Исследуйте любые «осиротевшие» тест-кейсы.
Шаг 5: Выполнять и обновлять
По мере выполнения тестов обновляйте колонку статуса. Когда обнаруживаются дефекты, привязывайте их и к тест-кейсу, и к требованию.
Шаг 6: Регулярно пересматривать
Пересматривайте RTM на ключевых этапах: после разработки тестов, во время выполнения тестов и перед принятием решений о релизе.
Инструменты для создания RTM
| Инструмент | Сложность | Лучше всего для |
|---|---|---|
| Электронные таблицы (Excel, Google Sheets) | Низкая | Небольшие проекты, команды новые в RTM |
| Jira + Xray / Zephyr | Средняя | Agile-команды, использующие Jira |
| TestRail | Средняя | Выделенное управление тестами |
| Azure DevOps Test Plans | Средняя | Команды в экосистеме Microsoft |
| HP ALM / Micro Focus | Высокая | Крупные предприятия, регулируемые отрасли |
| Doors (IBM) | Высокая | Системы критической безопасности |
Для большинства команд в начале хорошо структурированная электронная таблица вполне подходит. Переходите на специализированный инструмент, когда проект вырастет за пределы 200-300 требований.
RTM в Agile-проектах
В Agile концепция RTM по-прежнему применима, но адаптируется к итеративной природе спринтов:
- Требования = User Stories + критерии приёмки
- Трассировка часто ведётся в инструментах вроде Jira (связывание stories с тест-кейсами)
- Скоуп — на уровне спринта, а не всего проекта
- Обновления происходят каждый спринт, а не на этапах проекта
Многие Agile-команды поддерживают лёгкое соответствие «story-тест» в рамках своей спринт-доски, достигая той же цели без накладных расходов формального документа RTM.
Распространённые ошибки с RTM
- Создать один раз и не обновлять — RTM — это живой документ. Устаревшие RTM создают ложную уверенность.
- Слишком детальная трассировка — Трассировка каждого подтребования к каждому подтесту создаёт накладные расходы на поддержку без пропорционального выигрыша.
- Нет обратной трассировки — Только прямая трассировка пропускает «осиротевшие» тест-кейсы.
- Игнорирование нефункциональных требований — Требования производительности, безопасности и доступности тоже нуждаются в трассировке.
- Неучастие разработчиков — Разработчики могут помочь определить требования, которым нужно больше покрытия тестами, исходя из сложности кода.
Упражнение: создайте RTM
Сценарий: Вы создаёте RTM для функции регистрации пользователя. Ниже приведены требования и тест-кейсы. Ваша задача — создать двунаправленную RTM и проанализировать её на наличие пробелов.
Требования:
| ID | Требование |
|---|---|
| REG-01 | Пользователь может зарегистрироваться с email, паролем и именем |
| REG-02 | Пароль должен быть не менее 8 символов с одной заглавной буквой и одной цифрой |
| REG-03 | Система отправляет email подтверждения после регистрации |
| REG-04 | Пользователь не может зарегистрироваться с существующим email |
| REG-05 | Пользователь может зарегистрироваться через Google OAuth |
| REG-06 | Условия использования должны быть приняты перед регистрацией |
Тест-кейсы:
| ID | Тест-кейс |
|---|---|
| TC-301 | Регистрация с валидным email, паролем и именем |
| TC-302 | Регистрация с паролем короче 8 символов |
| TC-303 | Регистрация с паролем без заглавной буквы |
| TC-304 | Регистрация с паролем без цифры |
| TC-305 | Регистрация с уже существующим email |
| TC-306 | Проверка получения email подтверждения |
| TC-307 | Регистрация через аккаунт Google |
| TC-308 | Регистрация без принятия условий |
| TC-309 | Регистрация с пустым полем имени |
| TC-310 | Регистрация с SQL-инъекцией в поле email |
Задания:
- Создайте двунаправленную RTM (свяжите требования с тест-кейсами И тест-кейсы с требованиями)
- Выявите пробелы покрытия (требования без тестов)
- Выявите «осиротевшие» тест-кейсы (тесты без требований)
- Предложите дополнительные тест-кейсы для закрытия пробелов
Подсказка
- Свяжите каждый тест-кейс с требованием, которое он проверяет. Некоторые тест-кейсы могут быть связаны с несколькими требованиями.
- Ищите требования, у которых вообще нет тест-кейсов.
- Ищите тест-кейсы, которые не привязаны ни к одному перечисленному требованию.
- Подумайте, какие дополнительные сценарии могут потребоваться для каждого требования.
Решение
Двунаправленная RTM
| ID Req | Требование | ID тест-кейсов | Покрытие |
|---|---|---|---|
| REG-01 | Регистрация с email, паролем, именем | TC-301, TC-309 | Покрыто |
| REG-02 | Требования к паролю | TC-302, TC-303, TC-304 | Покрыто |
| REG-03 | Email подтверждения | TC-306 | Частично покрыто |
| REG-04 | Нельзя регистрироваться с существующим email | TC-305 | Покрыто |
| REG-05 | Регистрация через Google OAuth | TC-307 | Частично покрыто |
| REG-06 | Принять условия перед регистрацией | TC-308 | Покрыто |
Обратная трассировка
| ID TC | Тест-кейс | ID Req |
|---|---|---|
| TC-301 | Регистрация с валидными данными | REG-01 |
| TC-302 | Пароль слишком короткий | REG-02 |
| TC-303 | Пароль без заглавной | REG-02 |
| TC-304 | Пароль без цифры | REG-02 |
| TC-305 | Существующий email | REG-04 |
| TC-306 | Email подтверждения | REG-03 |
| TC-307 | Google OAuth | REG-05 |
| TC-308 | Условия не приняты | REG-06 |
| TC-309 | Пустое имя | REG-01 |
| TC-310 | SQL-инъекция в email | Нет (осиротевший) |
Анализ
Пробелы покрытия:
- REG-03 имеет только один тест-кейс. Отсутствует: email подтверждения не получен, email содержит корректные данные регистрации, ссылка подтверждения работает.
- REG-05 имеет только один тест-кейс. Отсутствует: ошибка Google OAuth, аккаунт Google без email, отменённый OAuth-флоу.
«Осиротевшие» тест-кейсы:
- TC-310 (SQL-инъекция) не привязан ни к одному перечисленному требованию. Это на самом деле валидный тест безопасности — его следует привязать к неявному или явному требованию безопасности. Если такого требования нет, рекомендуется добавить (напр., REG-07: «Система должна санитизировать все поля ввода»).
Предложенные дополнительные тест-кейсы:
- TC-311: Email подтверждения содержит корректное имя пользователя (REG-03)
- TC-312: Ссылка подтверждения истекает через 24 часа (REG-03)
- TC-313: Google OAuth отменён пользователем (REG-05)
- TC-314: Google OAuth с аккаунтом без email (REG-05)
- TC-315: Регистрация с паролем, удовлетворяющим всем критериям (REG-02, позитивный тест)
- TC-316: Регистрация со спецсимволами в имени (REG-01)
Ключевые выводы
- RTM связывает требования с тест-кейсами, создавая прослеживаемую цепочку от бизнес-потребности до верификации
- Прямая трассировка гарантирует, что каждое требование протестировано; обратная — что каждый тест обоснован
- RTM выявляет пробелы покрытия, поддерживает анализ влияния и обеспечивает аудит соответствия
- Начните просто с электронной таблицы и переходите к специализированным инструментам по мере роста проекта
- Относитесь к RTM как к живому документу — обновляйте её на протяжении всего жизненного цикла проекта