Как не потерять связь между требованиями и тестами: матрица трассировки на практике

Есть довольно неприятная проблема с тестовой документацией: тест работает, успешно проходит и при этом уже проверяет не совсем то, что нужно.

Например, несколько месяцев назад поменяли бизнес-логику. Требование обновили в трекере, разработку сделали, а связанный тест-кейс никто не пересмотрел.

На очередном регрессе он снова зелёный.

Формально всё хорошо. Но зелёный результат подтверждает старую проверку, а не обязательно текущее требование.

На небольшом проекте такие связи ещё можно частично держать в голове. Когда требований и тестов становятся тысячи, появляется отдельная задача: как понять, какие требования какими проверками покрыты и актуальны ли эти проверки сейчас?

Для этого и нужна трассировка требований.

Что вообще такое трассировка требований

В самом простом виде это явная связь:

требование ↔ тест-кейсы, чек-листы, автотесты

Например:

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 можно сгенерировать:

• тест-кейс;

• набор тест-кейсов;

• чек-лист.

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

В этом сценарии ИИ в первую очередь сокращает ручную работу: не нужно переносить описание требования в отдельный промпт, а затем вручную связывать получившиеся тесты с исходной задачей.

Сгенерированные проверки при этом всё равно нужно ревьюить. Наличие связи с требованием не гарантирует, что модель предложила достаточный или правильный набор тестов.

Что матрица не решает

Матрица хорошо показывает:

• есть ли у требования связанные тесты;

• какие именно;

• помечены ли они как требующие актуализации;

• с каким результатом они запускались.

Но она не может определить:

• достаточно ли этих тестов;

• насколько хорошо они спроектированы;

• учтены ли основные риски.

Например, с требованием можно связать один позитивный сценарий, и оно уже попадёт в число покрытых тестами. При этом негативные сценарии, граничные значения или интеграционные проверки могут отсутствовать.

Поэтому матрица трассировки не заменяет тест-дизайн и анализ рисков. Она решает другую задачу: помогает не потерять связь между требованием и проверками, которые должны его покрывать.

Где матрица становится полезной

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

В какой-то момент даже простой вопрос «Какими тестами сейчас проверяется это требование?» уже требует отдельного поиска.

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

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

Наличие теста и актуальный результат его выполнения - разные вещи.

Если эта публикация вас вдохновила и вы хотите поддержать автора — не стесняйтесь нажать на кнопку