Трассировка: как связать требование, реализацию и проверку

На проде дефект. Вопрос «какое требование нарушено» звучит просто, но ответить на него нельзя: требование было, его помнят, а где именно записано и что по нему проверяли — уже нет.

Трассировка обычно подаётся как документ: матрица, где строки — требования, столбцы — тесты, на пересечении галочки. Такую матрицу заводят на старте проекта, ведут полтора месяца и бросают, потому что она отдельная от работы и потому устаревает быстрее, чем обновляется.

Работающая трассировка документом не является. Это свойство рабочих артефактов: по любому месту цепочки можно дойти до соседних, не спрашивая живых людей.

Два вопроса, которые её проверяют

Не нужно оценивать зрелость процесса. Достаточно попробовать ответить.

Возьмите пункт постановки. Где код, который его реализует, и где проверка, которая его подтверждает?
Возьмите дефект из последнего релиза. Какое требование он нарушает?

Если на оба вопроса отвечает конкретный человек по памяти — трассировки нет, есть человек. Он уйдёт в отпуск, и цепочка порвётся вместе с ним.

Зачем это аналитику, а не тестировщику. Трассировка — единственный механизм, превращающий изменение требования в изменение проверки. Без неё правка постановки доезжает до кода и не доезжает до теста, и через релиз тест начинает подтверждать поведение, которое уже отменили.

Где рвётся цепочка

Разрывов немного, и они узнаваемы.

Требование живёт в двух местах

Есть документ с описанием и есть задача в трекере, куда его переписали своими словами. Дальше правят одно из двух. Через месяц они расходятся, и никто не знает, какое из них главное — а значит, по какому судить дефект.

Лечится не дисциплиной, а решением: один источник, остальное — ссылки. Какой именно источник, неважно; важно, что он назван и что второго нет.

Тест написан по реализации

Самый тихий разрыв. Тестировщик открывает готовую функциональность, смотрит, как она работает, и описывает это как ожидаемое поведение. Тест зелёный и бесполезный: он подтверждает, что система делает то, что делает.

Признак — тест невозможно написать до разработки. Если он опирается на конкретные подписи кнопок и порядок полей, он описывает экран, а не критерий приёмки.

Дефект закрыт без ссылки на требование

Разработчик поправил поведение, тестировщик проверил, задача закрыта. Чего не произошло: никто не посмотрел, что написано в постановке. Если постановка говорила иначе — она осталась неверной, и следующая правка вернёт дефект.

Поэтому дефект полезно закрывать с одной строкой: какое требование нарушено, или — «требования не было, добавлено такое-то».

Минимальный рабочий набор

Трассировка не требует новой системы. Она требует идентификатора и четырёх ссылок в местах, где работа идёт и так.

Что связываем	Чем	Признак, что связь жива
Требование → задача	Идентификатор требования в задаче	По задаче видно, что она реализует
Задача → код	Номер задачи в коммите	По файлу можно узнать, зачем он менялся
Требование → проверка	Идентификатор в названии теста	Поиск по идентификатору находит тест
Дефект → требование	Ссылка при закрытии	Видно, было требование или его не было

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

REQ-114   подписка закрывается по истечении срока
  задача    TASK-2071
  коммит    "TASK-2071: close access on expiry"
  тест      test_REQ_114_access_closes_within_hour
  дефект    BUG-388 → нарушает REQ-114

Такая схема не требует инструмента: она работает на поиске по строке в любом трекере и любом репозитории.

Не заводите отдельную систему трассировки. Любой артефакт, который надо обновлять руками после каждой правки, устаревает — вопрос месяцев. Связь должна ставиться там, где человек и так пишет: в коммите, в названии теста, в поле задачи.

Что делать, когда трассировки нет

Внедрять её задним числом по всему продукту бессмысленно — работа большая, а польза отложенная. Разумнее начать с мест, где уже больно.

С дефектов. Каждый разбираемый дефект получает строку «какое требование нарушено». За месяц накопится карта самых мутных мест.
С нефункциональных требований. Они чаще всего не имеют ни одного теста, и обнаруживается это в инциденте.
С того, что меняется чаще всего. Правила расчётов, доступы, статусы — там, где правка приходит раз в квартал, цена потерянной связи максимальна.

Признак, что цепочка порвалась давно: чтобы понять, как система должна себя вести, все читают код.

Проверка за пятнадцать минут

Возьмите последний закрытый дефект и пройдите его назад: тест → задача → требование. Отметьте, на каком шаге пришлось спросить человека. Этот шаг и есть место, с которого стоит начинать.

Что дальше

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