От требования до решения о релизе

DoQA не хранит требования — они живут во внешнем трекере, а в пространство попадают как локальные копии. Этот сценарий проходит весь цикл одного требования: от подключения трекера до ответа на вопрос «можно ли релизить». Отдельные разделы описаны на своих страницах; здесь они собраны в один рабочий процесс.

🎯 Задача

Провести требование от загрузки из трекера до решения о релизе: покрыть его тестами, прогнать, завести баги на провалах и оценить покрытие цифрами, а не на глаз.

💡 Решение

Настроить коннектор требований, загрузить требование, сгенерировать по нему проверки с помощью AI, собрать из них прогон, завести баг-репорты на провалах и посмотреть метрики «Покрытие» и «Успешность» в списке требований и матрице покрытия.

📝 Что понадобится

  • Роль с правом редактировать тест-кейсы, чек-листы или прогоны в пространстве — этого достаточно, чтобы генерировать проверки, связывать их с требованиями и создавать прогоны. Настройка коннектора открывается на тех же правах либо на правах администратора проекта.
  • Подключённая интеграция-трекер: источником требований может быть только Jira Server или YouTrack. Другие трекеры (Jira Cloud, Yandex Tracker, Bitrix, Redmine, GitLab) годятся для баг-репортов, но не для требований.
  • Для AI-генерации — коины на балансе (облачная версия) или настроенный LLM-провайдер (серверная версия). См. AI-функции.

⏱ Время: от часа до дней (полный цикл)

В этом сценарии «проверка» — это тест-кейс или чек-лист: оба привязываются к требованию и оба считаются в покрытии.

Шаг 1. Настроить коннектор требований

Один раз на пространство. Если коннектор уже подключён, переходите к шагу 2.

Пространство → «Настройки» → вкладка «Коннектор требований». Выберите трекер и «Проект-источник», при необходимости сузьте выгрузку запросом-фильтром (JQL для Jira Server, запрос YouTrack). Затем задайте два поля трекера — «Поле для ID кейсов» (куда DoQA пишет ID связанных проверок) и «Поле статуса покрытия» — и заполните маппинг статусов. Включите «Принимать вебхуки»: этот тумблер работает как выключатель всего коннектора, без него ни загрузка, ни генерация тестов по требованию не запустятся.

Как настроить каждое поле, чем «Кастомное поле» отличается от «Системного статуса (workflow)» и как поставить вебхук на стороне трекера — в разделе Коннектор требований.

✅ Результат: рядом с заголовком «Коннектор требований» стоит «Подключено», а кнопка «Обновить из трекера» разблокирована.

Шаг 2. Загрузить требование из трекера

Откройте раздел «Требования» в пространстве и нажмите «Обновить из трекера». DoQA перечитает требования по фильтру коннектора, подтянет заголовки и статусы, а те, что ушли из выгрузки, погасит в «Архивные записи».

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

✅ Результат: требования появились в списке. У свежезагруженного требования, с которым ещё не связана ни одна проверка, в колонке «Покрытие» стоит «Нет тестов».

Шаг 3. Сгенерировать тесты по требованию с помощью AI

Раскройте строку требования — откроется панель связанных проверок. Пока к требованию не привязано ни одной проверки, в ней есть кнопка «Сгенерировать тесты с помощью ИИ» (как только появится хотя бы одна связь, кнопка исчезает).

В диалоге выберите вид тестовой документации — «Тест-кейс», «Чек-лист» или «Набор тест-кейсов» — и папку для сохранения (новую можно создать прямо здесь). Нажмите «Сгенерировать».

DoQA возьмёт текст требования из трекера — вводить контекст вручную не нужно — и создаст проверки в фоне за несколько минут. Со страницы можно уйти. Генерация расходует AI-коины (тест-кейс и чек-лист — 6, набор тест-кейсов — 30); при ошибке списание возвращается.

Подробности диалога и условия, при которых кнопки нет, — в разделе Генерация тестов с помощью ИИ и в описании AI-функций.

✅ Результат: созданные тест-кейсы или чек-листы лежат в выбранной папке и уже привязаны к требованию. Состояние покрытия ушло из «Нет тестов» в «Не прогонялись» — проверки есть, но результата прогона у них ещё нет.

Не генерировать, а привязать

Если проверки на это требование уже написаны, генерация не нужна — свяжите их вручную кнопкой «Добавить кейс» или «Добавить чек-лист» в той же панели. Способы связывания разобраны в разделе Связывание требований с проверками.

Шаг 4. Собрать прогон и пройти его

Нажмите «…» в строке требования и выберите «Создать прогон». В прогон попадут все связанные с требованием проверки — тест-кейсы и чек-листы одним смешанным набором, — и DoQA сразу перейдёт на страницу нового прогона. Пункт неактивен, пока с требованием не связана ни одна проверка.

Пройдите прогон в плеере: проставьте каждому шагу или чеку результат — «Пройден», «Провален», «Сломан», «Заблокирован» или «Пропущен». Порядок прохождения кейсов, чек-листов и автотестов — в разделе Прохождение прогона.

✅ Результат: у проверок появился засчитанный результат. Требование, у которого все связанные проверки прошли, показывает «Все прошли»; если хотя бы одна провалена, сломана, заблокирована, пропущена или не прогонялась — «Не все прошли».

Шаг 5. Завести баги на провалах

На провале не выходя из прогона заведите баг-репорт: на шаге тест-кейса, на чеке чек-листа или на автотесте. Название можно сформировать по описанию проблемы кнопкой AI рядом с полем «Имя дефекта». Как именно завести баг-репорт — в разделе Создание баг-репортов.

Баг-репорт хранит ссылку на прогон и на проверку, при прохождении которой он найден, поэтому позже его видно и в разделе «Баги», и на вкладке «Баги» самого прогона, и в редакторе тест-кейса или чек-листа.

✅ Результат: каждая проблема зафиксирована баг-репортом со ссылкой на прогон и проверку. Провал в прогоне теперь не «где-то что-то упало», а конкретный баг с автором, приоритетом и статусом.

Шаг 6. Оценить покрытие и принять решение о релизе

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

В шапке списка требований — два показателя, и считаются они по-разному:

  • «Покрытие» — доля требований, у которых есть хотя бы одна связанная проверка. Отвечает на вопрос «что мы вообще проверяем».
  • «Успешность» — доля требований в состоянии «Все прошли» среди покрытых. Отвечает на вопрос «из проверенного что зелёное».

Знаменатели разные, поэтому числа расходятся — это не ошибка. Формулы и разбор на примере — в разделе Метрики: Покрытие и Успешность.

Где именно дыры, видно в матрице покрытия (кнопка «Матрица покрытия» в шапке): строки — требования, столбцы — проверки, пустая ячейка — связи нет. Выключите тумблер «Только связанные требования», чтобы непокрытые требования добавились в матрицу пустыми строками.

Решение о релизе собирается из трёх сигналов:

  1. «Покрытие» ниже целевого — есть требования без тестов. Ищите их по чипсу «Нет тестов» или в матрице с выключенным тумблером и возвращайтесь к шагу 3.
  2. «Успешность» ниже 100% — есть проваленные проверки. Каждой должен соответствовать баг-репорт из шага 5; по ним и принимается решение «блокеры или можно жить».
  3. Есть требования в состоянии «Требуется актуализация» — аналитик изменил требование в трекере, и старые результаты по нему больше не считаются. Это состояние перебивает все остальные, даже если тесты были зелёными: пока пометка висит, требование считается непроверенным. Что с этим делать — в разделе Актуализация.

✅ Результат: решение о релизе опирается на две метрики и список открытых баг-репортов, а не на ощущение готовности. Каждое требование либо покрыто и зелёное, либо у него есть понятная причина не быть таким.

⚠️ Возможные трудности

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

Пункт «Создать прогон» неактивен. С требованием не связана ни одна проверка — сначала сгенерируйте или привяжите тесты (шаг 3).

«Покрытие» в матрице показывает 100%, хотя в пространстве есть непокрытые требования. Матрица по умолчанию учитывает тумблер «Только связанные требования»: пока он включён, в срез попадают лишь требования со связями. Выключите тумблер или смотрите метрику в списке требований — там она считается по всем активным требованиям пространства.

Требование пропало из списка. Скорее всего, оно ушло в «Архивные записи»: его удалили в трекере или оно перестало проходить фильтр коннектора. Связи и история при этом сохраняются — DoQA не удаляет такие требования, а гасит.

Все зелёное, но «Успешность» не 100%. Проверьте чипс «Требуется актуализация»: пока хотя бы одно требование в этом состоянии, оно не считается пройденным, потому что результаты по нему заморожены до подтверждения актуализации.

📚 Смотрите также

Последнее обновление: