Знаете ли вы про версионирование требований и трейсинг
Что проверяют
Умеете ли вы управлять изменениями требований, а не просто их записывать. Интервьюер хочет понять, ответите ли вы на вопросы «что затронет правка этого требования» и «какая версия согласована с заказчиком». Следом часто просят показать, как у вас связаны требование, задача и тест.
Как отвечать
- версионирование: у требования есть идентификатор, статус (черновик, на согласовании, утверждено) и история изменений с автором и причиной. Согласованный набор фиксируется как базовая версия (baseline), и дальше меняется только через запрос на изменение с оценкой влияния;
- где это живёт: в Confluence и его аналогах есть история страниц, но базовую версию там приходится фиксировать вручную, копией или меткой релиза. Подход docs-as-code хранит требования в Git в Markdown или AsciiDoc: правки идут через merge request с ревью, релизы отмечаются тегами. В регулируемых отраслях берут специализированные системы вроде IBM DOORS или Polarion;
- трассировка: связь требования в обе стороны. Вперёд: бизнес-цель, пользовательская история, системное требование, контракт API, задача, коммит, тест-кейс. Назад: от упавшего теста или дефекта к требованию и цели;
- матрица трассировки: таблица требований и связанных артефактов. На практике её собирают из ссылок в трекере и системе управления тестами, а не ведут вручную в Excel.
Главная польза трассировки в анализе влияния: при изменении требования сразу видно, какие экраны, сервисы и тесты затронуты.
Сильнее всего звучит свой пример: какой инструмент, сколько требований, какую ошибку поймали благодаря связям. Если опыта мало, так и скажите, опишите, как вели историю изменений хотя бы в Jira, и чего вам не хватало.
Где спотыкаются
Называют историю правок страницы версионированием. Без зафиксированной базовой версии невозможно ответить, что именно заказчик согласовал в прошлом месяце.
Строят матрицу на сотни строк, которую никто не обновляет. Трассировать стоит только до уровня, который реально нужен для анализа влияния.
Ведут связи только в одну сторону: тесты привязаны к задачам, а задачи к требованиям нет. При изменении требования никто не знает, какие тесты переписывать.