Зачем нужна прослеживаемость
Прослеживаемость требований отвечает на три вопроса:
- Каждое ли требование протестировано? (Forward)
- Каждый ли тест имеет цель? (Backward)
- Если требование изменится, какие тесты обновить? (Анализ влияния)
Матрица прослеживаемости
Базовая структура
| Req ID | Требование | Тест-кейсы | Покрытие | Статус |
|---|---|---|---|---|
| REQ-001 | Регистрация по email | TC-001, TC-002 | Полное | Пройдено |
| REQ-002 | Сложность пароля | TC-010, TC-011 | Полное | 1 провал |
| REQ-003 | Двухфакторная авторизация | — | Нет | Не тестировано |
Двунаправленная прослеживаемость
Forward (Требование → Тест): Каждое требование имеет хотя бы один тест. Backward (Тест → Требование): Каждый тест связан с требованием.
| Направление | Находит | Действие |
|---|---|---|
| Forward-пробелы | Непротестированные требования | Написать тест-кейсы |
| Backward-пробелы | Тесты-сироты | Удалить или связать |
Инструменты
Таблицы (ручной метод), Jira + Xray/Zephyr (нативно), Azure DevOps (встроенное), TestRail.
Упражнение: Постройте RTM
Для 8 требований приложения обмена файлами создайте RTM и выявите пробелы покрытия.
Решение
Критические пробелы: Истечение ссылок (R3), шифрование (R7) и аудит-лог (R8) имеют нулевое покрытие. Нужно немедленное создание тест-кейсов, особенно R7 (безопасность) и R8 (compliance).
Ключевые выводы
- RTM связывает требования с тест-кейсами, выявляя пробелы покрытия
- Двунаправленная прослеживаемость ловит и непротестированные требования, и тесты-сироты
- Требования без тест-кейсов — слепые пятна, приоритизируйте по рискам
- Поддерживайте RTM как живой документ
- Используйте инструменты для автоматизации прослеживаемости