Есть довольно неприятная проблема с тестовой документацией: тест работает, успешно проходит и при этом уже проверяет не совсем то, что нужно.
Например, несколько месяцев назад поменяли бизнес-логику. Требование обновили в трекере, разработку сделали, а связанный тест-кейс никто не пересмотрел.
На очередном регрессе он снова зелёный.
Формально всё хорошо. Но зелёный результат подтверждает старую проверку, а не обязательно текущее требование.
На небольшом проекте такие связи ещё можно частично держать в голове. Когда требований и тестов становятся тысячи, появляется отдельная задача: как понять, какие требования какими проверками покрыты и актуальны ли эти проверки сейчас?
Для этого и нужна трассировка требований.
Что вообще такое трассировка требований
В самом простом виде это явная связь:
требование ↔ тест-кейсы, чек-листы, автотесты
Например:
REQ-142 → TC-501, TC-502, AT-84
Причём связь может быть many-to-many: один тест покрывает несколько требований, а одно требование проверяется несколькими тестами.
Из этого уже можно получить полезную информацию:
у каких требований вообще нет связанных проверок;
какие тесты относятся к конкретному требованию;
какие проверки используются сразу для нескольких требований;
что нужно пересмотреть после изменения требования.
В некоторых системах поверх этого добавляют ещё результаты прогонов.
Например, так сделано в матрице покрытия DoQA: кроме самой связи там отображается последний засчитанный результат каждой проверки.
То есть можно увидеть не только «тест существует», но и: «его последний результат - Passed / Failed / Broken / Blocked / Skipped».
Здесь важно не путать разные виды покрытия.
Если с требованием связан хотя бы один тест, в терминах матрицы оно уже считается покрытым. Но это ничего не говорит о том, достаточно ли этих проверок и насколько хорошо они спроектированы.
Матрица показывает наличие связи между требованием и тестами, но не оценивает качество самого тестирования.
Где обычно возникает проблема
Требования и тесты часто живут в разных системах. Аналитик меняет задачу в трекере. QA работает с кейсами в TMS. Разработчик смотрит задачу и код.
Само по себе изменение задачи никак не гарантирует, что кто-то вспомнит про связанные тесты. Особенно если тест написали год назад, автор уже работает в другой команде, а само требование с тех пор менялось несколько раз.
Саму трассировку при этом можно вести и без специальных возможностей в TMS. Для этого используют Excel, Google Sheets, Confluence или внутреннюю документацию: сохраняют ID требования, связанные с ним тест-кейсы, иногда добавляют статус покрытия и результаты проверок.
Проблема такого подхода в ручном обновлении. Если требование изменилось, нужно не только поправить задачу и тесты, но и не забыть обновить саму матрицу. Чем больше требований и проверок, тем проще этой таблице разойтись с реальным состоянием проекта.
В DoQA 4.2 для этого появился отдельный модуль требований. Требования при этом не становятся ещё одной копией документации, которую нужно вручную поддерживать в TMS.
Источник остаётся в трекере. В DoQA загружаются данные требования: его ключ, название, статус и ссылка на исходную задачу. После этого требование можно связать с тест-кейсами и чек-листами.
Как выглядит сама матрица
В DoQA есть два представления: список требований и матрица покрытия.
В матрице:
строки - требования;
столбцы - тест-кейсы и чек-листы;
ячейки - связь и последний засчитанный результат прогона.
Пустая ячейка означает, что конкретная проверка с этим требованием не связана. По такой таблице достаточно быстро видно несколько типов проблем. Например, требования без тестов. Или требование, которое держится на одной проверке. Или один большой тест, связанный сразу с кучей требований.
Или тесты, которые есть, но ещё ни разу не прогонялись.
У самого требования при этом может быть одно из состояний:
нет тестов;
не прогонялись;
все прошли;
не все прошли;
требуется актуализация.
Получается довольно простой способ посмотреть не только наличие документации, но и её текущее состояние.
Что происходит при изменении требования
Если реагировать на любое изменение задачи в трекере, уведомлений будет слишком много. Исправили опечатку или форматирование - связанные тесты уже якобы нужно пересматривать.
Поэтому в DoQA изменение требования само по себе не запускает актуализацию тестов.
Если правка влияет на ожидаемое поведение системы, ответственный за требование выставляет в специальном поле трекера значение «Требуется актуализация». DoQA получает это изменение по вебхуку или при следующей синхронизации и помечает связанные тест-кейсы и чек-листы как требующие пересмотра. Ответственные тестировщики получают уведомления.
То есть DoQA не пытается самостоятельно определить, насколько существенно изменилось требование. Это решение остаётся за человеком.
QA проверяет связанные тесты и при необходимости редактирует их. После этого актуализацию нужно подтвердить отдельно. Простое редактирование тест-кейса не снимает пометку автоматически.
Что происходит со старыми результатами
Допустим, до изменения требования связанный тест успешно проходил. Требование изменили, тест-кейс актуализировали.
Старый результат после этого больше не учитывается. Для актуализированной проверки нужно получить новый результат, а до повторного запуска она считается непрогнанной.
Это важно: иначе после изменения требования и обновления тест-кейса в матрице мог бы остаться старый Passed, хотя новую версию теста ещё никто не выполнял.
Получается такой цикл:
требование → связанная проверка → изменение требования → актуализация проверки → новый прогон
После подтверждения актуализации прогоны, выполненные до неё, перестают учитываться.
Связь работает не только внутри TMS
DoQA может работать с требованиями из Jira Server и YouTrack и передавать часть информации обратно в трекер: например, данные о связанных проверках и статус покрытия требования.
Поэтому аналитику или разработчику не обязательно открывать TMS, чтобы посмотреть, есть ли у требования связанные проверки и в каком они состоянии.
Есть и обратный сценарий: из требования в DoQA можно создать прогон, в который попадут все связанные с ним тест-кейсы и чек-листы. Не нужно отдельно искать и собирать их перед проверкой требования.
А что с автотестами
В DoQA 4.3 требования можно связывать напрямую с автотестами.
Раньше для такой связи нужен был ручной тест-кейс: автотест связывали с ним, а уже тест-кейс - с требованием. Теперь этот промежуточный шаг не нужен.
Связанный автотест учитывается при расчёте покрытия, а посмотреть такие проверки можно прямо из карточки требования.
Это пригодится, например, если требование проверяется только автотестами. Создавать для него отдельный ручной тест-кейс только для трассировки больше не нужно.
А если тестов на требование ещё нет
Если с требованием пока не связано ни одной проверки, в DoQA можно сгенерировать:
тест-кейс;
набор тест-кейсов;
чек-лист.
Для генерации используется контекст самого требования из трекера, а созданные проверки автоматически связываются с ним.
В этом сценарии ИИ в первую очередь сокращает ручную работу: не нужно переносить описание требования в отдельный промпт, а затем вручную связывать получившиеся тесты с исходной задачей.
Сгенерированные проверки при этом всё равно нужно ревьюить. Наличие связи с требованием не гарантирует, что модель предложила достаточный или правильный набор тестов.
Что матрица не решает
Матрица хорошо показывает:
есть ли у требования связанные тесты;
какие именно;
помечены ли они как требующие актуализации;
с каким результатом они запускались.
Но она не может определить:
достаточно ли этих тестов;
насколько хорошо они спроектированы;
учтены ли основные риски.
Например, с требованием можно связать один позитивный сценарий, и оно уже попадёт в число покрытых тестами. При этом негативные сценарии, граничные значения или интеграционные проверки могут отсутствовать.
Поэтому матрица трассировки не заменяет тест-дизайн и анализ рисков. Она решает другую задачу: помогает не потерять связь между требованием и проверками, которые должны его покрывать.
Где матрица становится полезной
Пока требований и тестов немного, связи между ними ещё можно отслеживать вручную. С ростом продукта это становится сложнее: требования меняются, тестов становится больше, а одна проверка может быть связана сразу с несколькими требованиями.
В какой-то момент даже простой вопрос «Какими тестами сейчас проверяется это требование?» уже требует отдельного поиска.
Матрица позволяет увидеть эту связь напрямую: какие требования остались без тестов, какие проверки с ними связаны, что запускалось и где после изменения требования тесты нужно пересмотреть.
И здесь особенно полезен механизм актуализации: если изменение требования было отмечено как существенное, старый успешный прогон не продолжает считаться подтверждением новой версии требования.
Наличие теста и актуальный результат его выполнения - разные вещи.