Модуль управления требованиями
Общая информация
Требования не создаются в DoQA. Они загружаются из внешнего трекера и живут в пространстве как локальные копии: ключ, заголовок, статус в трекере и ссылка на исходный тикет.
Раздел отвечает на два вопроса: какие требования покрыты тестами, а какие нет — и где тесты устарели после того, как требование изменили.
Пример использования функционала командой разработки
Рассмотрим типичный сценарий работы команды разработки.
Команда использует Jira для управления разработкой продукта. В Jira создаются эпики, пользовательские истории, задачи и подзадачи. Именно они выступают источником требований, на основе которых разработчики реализуют функциональность, а тестировщики готовят тестовую документацию.
После настройки связи между Jira и DoQA требования автоматически синхронизируются в систему управления тестированием. Каждое требование появляется в модуле «Требования», где его можно сразу начать покрывать тестами, не дожидаясь завершения разработки.
Тестировщик может:
- связать требование с существующими тест-кейсами и чек-листами;
- сгенерировать один тест-кейс, набор тест-кейсов или чек-лист с помощью ИИ на основе содержания требования. Сгенерированные тесты автоматически сяжутся с требованием.
После создания связи информация синхронизируется обратно в Jira. В карточке требования автоматически появляются ссылки на связанные тест-кейсы и чек-листы из DoQA. Благодаря этому аналитики, разработчики и менеджеры всегда видят, какие тесты покрывают конкретное требование, не открывая систему управления тестированием.
Когда разработка завершена и задача переходит в тестирование, тестировщику не нужно вручную искать необходимые проверки. Достаточно открыть требование в DoQA и выбрать «Создать прогон». В новый прогон автоматически будут добавлены все тест-кейсы и чек-листы, связанные с данным требованием.
Во время выполнения тестов DoQA автоматически рассчитывает статус проверки требования. Система показывает:
- какие требования уже покрыты тестами;
- какие требования еще не проверялись;
- по каким требованиям все проверки успешно пройдены;
- по каким требованиям есть непройденные тесты;
- какие требования требуют актуализации.
Это позволяет быстро оценить готовность функциональности к выпуску.
Через некоторое время бизнес-аналитик вносит изменения в требование. Поскольку изменения влияют на ожидаемое поведение системы, он вручную устанавливает в Jira статус «Требуется актуализация» в специальном кастомном поле. Такой подход позволяет избежать ложных уведомлений при незначительных изменениях, например исправлении опечаток или форматирования.
DoQA получает уведомление через вебхук, определяет все связанные тест-кейсы и чек-листы и автоматически отправляет уведомления ответственным тестировщикам. Требование получает статус «Требуется актуализация», а предыдущие результаты проверки перестают учитываться до тех пор, пока тестовая документация не будет обновлена.
После актуализации тест-кейсов тестировщик отмечает их как актуализированные и повторно запускает прогон. После успешного выполнения обновленных тестов требование снова получает актуальный статус проверки.
На протяжении всего проекта руководитель тестирования может контролировать состояние требований с помощью дерева требований или матрицы покрытия. В них отображаются ключевые показатели:
- процент требований, покрытых тестами;
- процент покрытых требований, успешно прошедших проверку.
При необходимости матрицу покрытия можно экспортировать в формат XLSX или CSV для подготовки отчетности.
Запросите коннектор для вашего трекера
На текущий момент поддерживается синхронизация требований с Jira Server. Напишите в службу поддержку, если вы используете другой трекер и мы добавим новый коннектор в ближайшем релизе.
Настройка модуля
Шаг 1. Создание интеграции с трекером
Перед использованием модуля необходимо создать интеграцию между DoQA и системой управления задачами.
Подробная инструкция по созданию интеграции приведена в разделе Интеграция с трекерами.
Модуль требований умеет работать с Jira Server. Остальные трекеры, которые DoQA умеет подключать для баг-репортов (Jira Cloud, Yandex Tracker, Bitrix24, Redmine, GitLab), источником требований быть не могут — при попытке сохранить коннектор на них DoQA ответит «Этот трекер не поддерживается модулем требований».
Коннектор не хранит логин и токен: он ссылается на уже существующую интеграцию DoQA-трекер. При удалении интеграции будут также удалены настройки коннектора.
Шаг 2. Настройка трекера
Создайте кастомные поля в трекере:
Результатом выполнения этого шага будет создание в трекере двух кастомных полей:
- DoQA Tests для связанных тестов DoQA Tests
- DoQA Coverage status для статуса проверок требования
Шаг 3. Настройка коннектора требований
Где настраивается
Пространство → «Настройки» в боковом меню → вкладка «Коннектор требований». Вкладка доступна тем, кто может создавать и редактировать тест-кейсы, чек-листы или прогоны в этом пространстве. Из пустого списка требований туда же ведёт кнопка «Настроить коннектор».
Рядом с заголовком «Коннектор требований» — состояние подключения:
| Значок | Что означает |
|---|---|
| «Не настроено» | Коннектор ещё не сохранён. |
| «Подключено» | Последний обмен с трекером прошёл без ошибок. |
| «Поле не найдено» | Указанного кастомного поля в трекере нет (трекер ответил HTTP 400). Исправьте поле и сохраните заново. |
| «Трекер недоступен» | Подключиться к трекеру не удалось; DoQA показывает данные из кэша. |
Настройка
Трекер и проект-источник
- «Трекер» — выберите подключённую интеграцию. Пока трекер не выбран, остальные настройки не показываются: набор полей зависит от интеграции.
- «Проект-источник» — выберите проект трекера. DoQA подтягивает список проектов из трекера сама.
- Запрос-фильтр под списком проектов — «JQL-запрос» для Jira Server. Работает как дополнительный фильтр внутри выбранного проекта: например,
type = Story. Требования, не попавшие под фильтр, в пространство не загружаются, а уже загруженные уходят в «Архивные записи».
Поле для ID кейсов
Кастомное поле трекера, в которое DoQA списком пишет ID связанных проверок. Именно оно делает связь двусторонней: открыв тикет, аналитик видит, какие проверки его покрывают.
Пример: поле DoQA Tests
Статус покрытия
DoQA вычисляет состояние покрытия и отражает его в трекере. Настройка «Куда писать статус покрытия» определяет способ:
- «Кастомное поле» (рекомендуется) — статус пишется в отдельное select-поле трекера. Не требует настройки workflow.
- «Системный статус (workflow)» — DoQA двигает тикет по статусам/переходам проекта. Подходит, если в проекте трекера уже настроены нужные статусы и переходы.
Переключатель показывается, только если трекер поддерживает оба варианта.
При выборе «Кастомное поле» задайте «Поле статуса покрытия» — это отдельное поле, не то же самое, что «Поле для ID кейсов». Без него коннектор не сохранится.
Пример: поле DoQA Coverage status
Маппинг статусов покрытия
Таблица сопоставляет пять состояний покрытия DoQA со значениями в трекере. Что подставлять в правую колонку, зависит от выбранной цели: при «Кастомном поле» — опция выбранного поля, при «Системном статусе» — статус или переход workflow. Состояние без сопоставления («— не задано —») в трекер не пишется.
Четыре состояния DoQA пишет в трекер: «Нет тестов», «Все прошли», «Не все прошли», «Не прогонялись». У них в таблице стрелка вправо.
Состояние «Требуется актуализация» — единственное, которое DoQA читает из трекера. У него стрелка влево и подсказка «Этот статус выставляет аналитик в трекере — DoQA слушает его и снимает пометку». Как только значение в трекере совпадает с этим маппингом, DoQA помечает все связанные проверки требования и замораживает запись статуса в трекер до подтверждения актуализации. Подробнее — цикл актуализации.
Если маппинг пуст
Без маппинга «Требуется актуализация» цикл актуализации не запустится: DoQA не поймёт, какой статус в трекере означает «требование изменилось».
Вебхуки
Вебхук доставляет в DoQA события «требование изменилось» из трекера, не дожидаясь ручного обновления. Свитчер «Принимать вебхуки» включает приём.
Настройка исходящего вебхука выполняется на стороне трекера.
Шаг 4. Настройка вебхука
После сохранения коннектора DoQA сгенерирует URL вебхука с секретным токеном.
Скопируйте этот URL и создайте в трекере исходящий (Outgoing) Webhook.
Вебхук необходим для того, чтобы DoQA автоматически получала уведомления об изменении требований.
Шаг 5. Синхронизация требований
Запустите синхронизацию из настроенного коннектора, нажав на кнопку "Обновить из трекера".
Во время синхронизации DoQA:
- получает актуальный список требований из трекера;
- обновляет уже существующие требования.
После завершения синхронизации требования становятся доступны в модуле управления требованиями.
Лента операций
Под формой коннектора — «Лента операций»: что DoQA отправляла в трекер и что получала оттуда. Индикатор справа показывает «синк в норме» либо число ошибок.
Записи фильтруются по «Статусу» («Все», «OK», «Ошибки», «Пропущено») и «Операции»:
- «Получение» — «Получение требования» (загрузка требований из трекера);
- «Отправка» — «Отправка ID проверок в тикет» и «Отправка статуса покрытия»;
- «Вебхук» — «Принят вебхук об изменении».
Отдельным цветом выделены записи «Актуализация».
Строки со статусом «Пропущено» объясняют, почему DoQA ничего не сделала:
| Причина | Что это значит |
|---|---|
| «Коннектор не настроен» | В пространстве нет коннектора. |
| «Коннектор выключен» | Приём вебхуков выключен в коннекторе DoQA. |
| «Заморожено до актуализации» | Требование ждёт подтверждения актуализации — статус покрытия в трекер не пишется. |
| «Статус не сопоставлен или переход недоступен» | В маппинге нет значения для этого состояния либо трекер не даёт нужный переход. |
| «Повторное событие» | Вебхук с тем же событием уже обработан. |
Очистка данных требований
Внизу вкладки — «Очистка данных требований». Кнопка «Очистить данные» безвозвратно удаляет из базы все загруженные в это пространство требования и все связи тест-кейсов и чек-листов с ними.
Действие необратимо
Восстановить связи после очистки нельзя — их придётся расставлять заново вручную. В трекер DoQA при этом ничего не пишет: очистка убирает локальные данные, а не отвязывает проверки в тикетах.
Не удаляются: настройки коннектора, сама интеграция и сами тест-кейсы и чек-листы. После очистки можно синхронизироваться заново.
Кнопка доступна только администраторам — остальным она заблокирована с подсказкой «Действие доступно только администраторам». В диалоге подтверждения кнопка «Удалить» разблокируется через несколько секунд. По завершении DoQA сообщит, сколько требований и связей удалено.
Очистка нужна, если синхронизировались не с тем проектом или делали синхронизацию для теста. Чтобы просто перестать загружать часть требований, поменяйте фильтр коннектора: лишние записи уйдут в «Архивные записи», а связи и история сохранятся.
Гайд по использованию модуля требований
Как открыть
Откройте пространство и выберите «Требования» в боковом меню. Кнопка «Матрица покрытия» в шапке ведёт на отдельную страницу — матрицу покрытия.
Что показывает список
| Колонка | Что в ней |
|---|---|
| «Ключ» | Ключ тикета в трекере. Рядом — значок трекера; клик по ключу открывает тикет в трекере. |
| «Заголовок» | Заголовок требования, как он записан в трекере. |
| «Статус в трекере» | Статус тикета. DoQA его не меняет — только показывает. |
| «Покрытие» | Одно из пяти состояний, см. ниже. |
| «Проверки» | Число связанных проверок и полоса с разбивкой по последним результатам. Наведите курсор — увидите, сколько из них кейсов и сколько чек-листов. |
| «Актуализация» | Сколько связей уже актуализировано из скольких. Колонка появляется, только когда в списке есть требования с пометкой «Требуется актуализация». |
Внизу списка — счётчик «Показано N из M». Следующая страница подгружается по мере прокрутки.
Раскрытие строки
Клик по строке раскрывает панель связанных проверок. Для каждой проверки видно её ID, тип (кейс или чек-лист), дату привязки, последний результат прогона и кнопку отвязки. Клик по проверке открывает её в DoQA, клик средней кнопкой мыши — в новой вкладке браузера.
Здесь же кнопки «Добавить кейс» и «Добавить чек-лист». Если требование еще не имеет связей с тестами, дополнительно отображается кнопка "Сгенерировать тесты с помощью ИИ". У архивных требований этих кнопок нет.
Состояния покрытия
| Состояние | Когда возникает |
|---|---|
| «Нет тестов» | С требованием не связана ни одна проверка. |
| «Не прогонялись» | Связи есть, но ни у одной проверки нет засчитанного результата прогона. |
| «Все прошли» | У всех связанных проверок последний результат — «Пройден». |
| «Не все прошли» | Есть проверки с результатом «Провален», «Сломан», «Заблокирован» или «Пропущен» — либо часть проверок вообще не прогонялась. |
| «Требуется актуализация» | Хотя бы одна связь помечена как требующая актуализации. |
Три правила, которые объясняют неожиданные значения в колонке:
- «Требуется актуализация» перебивает всё остальное. Пока пометка висит хотя бы на одной связи, требование показывает именно это состояние, даже если все тесты пройдены.
- Последним результатом считается последний прогон, в котором статус проверки был реально выставлен. Если проверку добавили в новый прогон, но ещё не прошли (статус не проставлен), DoQA берёт результат из предыдущего прогона, а не считает, что прогона не было.
- Прогоны, сделанные до подтверждения актуализации, не засчитываются. После того как вы нажали «Актуализировано», старый результат перестаёт учитываться, и требование возвращается в «Не прогонялись» — пока проверку не прогонят заново.
Метрики «Покрытие» и «Успешность»
В шапке списка — два показателя.
- «Покрытие» — доля требований, у которых есть хотя бы одна связанная проверка: (все требования − требования в состоянии «Нет тестов») ÷ все требования.
- «Успешность» — доля покрытых требований в состоянии «Все прошли», от числа покрытых. Знаменатель здесь — покрытые требования, а не все.
Из-за разных знаменателей цифры расходятся: если из 100 требований покрыто 20 и все 20 в состоянии «Все прошли», «Покрытие» покажет 20%, а «Успешность» — 100%. Это не ошибка.
Обе метрики и счётчики на чипсах состояний считаются по всем активным требованиям пространства. Поиск, фильтр «Связь» и выбранный чипс на них не влияют, архивные записи в них не входят. Если требований нет (или нет покрытых), вместо процента стоит прочерк.
Срезы и фильтры
Список делится на три вкладки.
- «Все требования» — активные требования, загруженные из трекера.
- «Архивные записи» — требования, которых больше нет в выгрузке трекера: удалённые или ушедшие из-под фильтра коннектора. DoQA их не удаляет, а гасит, чтобы не потерять связи и историю; в списке они отображаются зачёркнутым заголовком. Фильтров у этой вкладки нет.
- «Несвязанные проверки» — обратный срез: не требования, а проверки без единой связи. Для каждой строки доступны «Открыть» (в новой вкладке) и «Привязать требование». Есть свой поиск (по названию или ID проверки) и фильтр «Тип» — «Все», «Кейсы», «Чек-листы».
Фильтры вкладки «Все требования»:
- строка поиска — ищет по ключу и заголовку требования;
- фильтр «Связь» — «Все», «Связанные», «Несвязанные»;
- чипсы состояний покрытия со счётчиками. Клик по чипсу оставляет в списке только требования в этом состоянии, повторный клик снимает фильтр.
Когда фильтры активны, рядом появляется «Сбросить фильтры». Выбранный срез и фильтры остаются в адресе страницы — ссылку можно отправить коллеге.
Связывание требований с проверками
Связь двусторонняя. При её создании DoQA дописывает ID проверки в поле тикета в трекере — какое именно поле, задаёт администратор в настройке «Поле для ID кейсов» коннектора. Связь M:N: одну проверку можно привязать к нескольким требованиям и наоборот.
Привязать можно из четырёх мест.
- Из списка требований. Раскройте строку и нажмите «Добавить кейс» или «Добавить чек-лист». Откроется тот же диалог выбора, что и при добавлении в прогон, — можно выбрать сразу набор. Результат: «Привязано проверок: N». Если всё выбранное уже было привязано — «Новых привязок нет — выбранные проверки уже были привязаны».
- Из редактора тест-кейса или чек-листа. Таб «Требования» → «Привязать требование» → поиск по ключу или заголовку, можно отметить несколько требований сразу.
- Из среза «Несвязанные проверки». Кнопка «Привязать требование» в строке проверки.
- Отвязка. Кнопка с разорванной связью в панели связанных проверок или в табе «Требования» редактора.
Удаление проверки и связь
Помещение тест-кейса или чек-листа в корзину связь не разрывает — она переживает восстановление. Связь рвётся только при окончательном удалении; тогда же DoQA переписывает список ID в поле тикета.
Актуализация: что делать, когда требование изменилось
Это основной сценарий раздела. Он работает так.
- В трекере ответственный переводит требование в статус, сопоставленный состоянию «Требуется актуализация». Это единственное состояние, которое DoQA читает из трекера, а не пишет в него.
- DoQA получает вебхук (или узнаёт об изменении при обновлении из трекера), помечает все связанные проверки, и требование переходит в «Требуется актуализация». Ответственные за связанные тест-кейсы и чек-листы получают уведомление.
- Пока пометка висит, DoQA не пишет вычисленный статус покрытия в трекер. В «Ленте операций» такие записи помечены как «Заморожено до актуализации».
- Тестировщик правит проверку и подтверждает актуализацию — кнопкой «Актуализировано» в карточке кейса или чек-листа, либо «Актуализировать» / «Актуализировать все» в панели связанных проверок.
- После подтверждения проставляется дата актуализации. Прогоны, сделанные до неё, перестают учитываться: требование покажет «Не прогонялись», пока проверку не прогонят заново.
Пометку снимает только человек. Правка тест-кейса сама по себе её не снимает.
Прогресс виден в колонке «Актуализация» списка («сколько актуализировано из скольких») и в шапке раскрытой панели: «N из M тестов требуют актуализации», а после подтверждения всех — «Все тесты актуализированы».
Генерация тестов с помощью ИИ
DoQA может забрать текст требования из трекера и создать по нему тестовую документацию.
Кнопка «Сгенерировать тесты с помощью ИИ» находится в панели связанных проверок и показывается, только пока у требования нет ни одной связи.
В диалоге «Генерация тестов с помощью ИИ» выберите:
- «Вид тестовой документации» — «Тест-кейс», «Набор тест-кейсов» или «Чек-лист».
- «Папка для сохранения» — существующая папка или новая, её можно создать прямо в диалоге кнопкой «Создать папку».
Нажмите «Сгенерировать». Генерация асинхронная: в строке требования крутится индикатор, панель показывает «ИИ создаёт тестовую документацию…» и предупреждает, что это может занять несколько минут. Со страницы можно уйти. По завершении появится «Тестовая документация сгенерирована», а созданные проверки будут автоматически привязаны к требованию.
Кнопки не будет, если:
- требование архивное;
- коннектор выключен или требование загружено не той интеграцией, которая указана в коннекторе сейчас;
- у вас нет доступа к AI-функциям.
Генерация расходует AI-коины, как и остальные AI-функции либо использует ваши токены при подключении кастомного провайдера. Подробнее — в настройках ИИ.
Создать прогон из требования
Нажмите «…» в строке требования и выберите «Создать прогон». В прогон попадут все связанные с требованием проверки — и тест-кейсы, и чек-листы одним смешанным набором. Откроется обычная форма создания прогона; после создания DoQA сразу перейдёт на страницу нового прогона.
Пункт неактивен, если с требованием не связана ни одна проверка.
Обновление из трекера
Кнопка «Обновить из трекера» в шапке списка запускает синхронизацию: DoQA перечитывает требования по фильтру коннектора, обновляет заголовки и статусы, добавляет новые и гасит те, которых в выгрузке больше нет. По завершении — «Требования обновлены из трекера».
Кнопка недоступна, пока не настроен коннектор: подсказка «Подключите коннектор требований в настройках спейса».
Вебхуки доставляют изменения сами, ручное обновление нужно, когда вебхук не настроен или события были пропущены.
Если требований нет
- «Требований пока нет» и «Настройте коннектор трекера, чтобы загрузить требования» — коннектор ещё не настроен. Кнопка «Настроить коннектор» ведёт в настройки пространства; она видна тем, у кого есть доступ к настройкам.
- «Требований пока нет» и подсказка про проверку фильтра (JQL или проект) в настройках коннектора — коннектор настроен, но выгрузка пуста. Скорее всего, фильтр коннектора не выбирает ни одного тикета.
- «Не удалось загрузить требования» и «Трекер недоступен или вернул ошибку» — проблема на стороне трекера или подключения. Состояние подключения видно на вкладке «Коннектор требований», подробности — в «Ленте операций».
Матрица покрытия
Матрица показывает пересечение требований и проверок: строки — требования, столбцы — тест-кейсы и чек-листы, ячейки — последний результат прогона. Так видно, какие требования держатся на одной проверке, какие проверки покрывают сразу несколько требований и где в покрытии дыры.
Откройте раздел «Требования» в пространстве и нажмите «Матрица покрытия» в шапке. Кнопка «Дерево требований» возвращает к списку.
В матрицу попадают только активные требования. Архивные записи в ней не показываются — их видно на одноимённой вкладке списка.
Как читать таблицу
Слева три закреплённых колонки: «Ключ», «Название» и «Покрытие» — состояние покрытия требования. Дальше идёт по колонке на каждую проверку среза; в шапке колонки — значок типа (кейс или чек-лист) и ID. Клик по ID открывает проверку в новой вкладке.
Границу между «Название» и остальной таблицей можно потянуть мышью, двойной клик по ней сбрасывает ширину. Ширина запоминается в браузере.
Наведение подсвечивает строку и колонку целиком. Клик по ячейке открывает полосу под шапкой: результат, тип и ID проверки, её название, ключ требования и кнопка «Открыть кейс» либо «Открыть чек-лист».
Строки подгружаются по мере прокрутки. Внизу — счётчик размера среза вида «N × M».
Легенда
Заливка ячейки — последний результат прогона проверки по этому требованию.
| Значок | Результат |
|---|---|
| «Пройден» | Последний засчитанный прогон пройден. |
| «Провален» | Проверка провалена. |
| «Сломан» | Проверка сломана. |
| «Заблокирован» | Проверка заблокирована. |
| «Пропущен» | Проверка пропущена. |
| «Нет прогона» | Связь есть, но засчитанного результата нет. |
Пустая ячейка — проверка с этим требованием не связана.
Про то, какой прогон считается последним и почему после актуализации результат обнуляется, — в разделе Состояния покрытия.
Фильтры
- Чипсы состояний покрытия со счётчиками. Клик оставляет в матрице только требования в этом состоянии, повторный клик снимает фильтр. Счётчики на чипсах от выбранного чипса не зависят.
- «Только связанные требования» — тумблер. Включён по умолчанию: в матрице только требования, у которых есть хотя бы одна связь. Выключите его, чтобы увидеть непокрытые требования — они добавятся пустыми строками.
Когда фильтр активен, появляется «Сбросить фильтры» — над таблицей и в её подвале.
Метрики
В шапке — те же «Покрытие» и «Успешность», что и в списке требований, плюс полоса с разбивкой по пяти состояниям. Формулы описаны в разделе Метрики «Покрытие» и «Успешность».
«Покрытие» здесь считается по срезу
Метрики матрицы учитывают свитчер «Только связанные требования». Пока он включён — а это состояние по умолчанию, — в срез попадают только требования со связями, поэтому «Покрытие» показывает 100%. Чтобы увидеть реальное покрытие пространства, выключите тумблер или смотрите метрику в списке требований.
Выбранный чипс состояния на метрики, наоборот, не влияет.
Экспорт
Кнопка «Экспорт» предлагает два формата: «Экспорт в CSV» и «Экспорт в Excel».
Ведут они себя по-разному:
- CSV и не больше 1000 строк — файл скачивается сразу.
- Excel в любом размере или CSV длиннее 1000 строк — DoQA готовит файл в фоне. Над таблицей появляется полоса «Подготовка экспорта…», затем «Экспорт…» с процентами; по готовности файл скачается сам. Со страницы в это время лучше не уходить: прогресс отслеживает открытая вкладка.
Что попадёт в файл
Экспорт игнорирует тумблер «Только связанные требования»: в файл выгружаются все активные требования пространства, включая те, у которых нет ни одной проверки. Фильтр по состоянию покрытия (чипс) при этом учитывается.
Поэтому файл почти всегда длиннее того, что вы видите на экране.
Структура файла: колонки Requirement key, Requirement title, Coverage, дальше по колонке на проверку. Заголовок колонки — #ID Название для тест-кейса и CL#ID Название для чек-листа (префикс нужен, чтобы кейс и чек-лист с одинаковым ID не слились). В ячейках — результат прогона на латинице (passed, failed, broken, blocked, skipped) либо пусто, если связи нет или проверка не прогонялась. Имя файла — coverage-matrix_s<ID пространства>_<метка времени>.
Экспорт матрицы не связан с экспортом тестовой документации — это другая выгрузка и другой формат.
Если матрица пустая или не строится
- «Нет данных для матрицы» и «Свяжите требования с кейсами или чек-листами, чтобы построить покрытие» — связей ещё нет. Как их создать — в разделе Связывание требований с проверками.
- «Ничего не найдено. Попробуйте изменить или сбросить фильтры.» — под выбранный чипс не попало ни одного требования.
- «Не удалось построить матрицу» и «Превышено время ожидания прогонов» — расчёт не уложился в отведённое время. Нажмите «Повторить»; если повторяется, сузьте срез чипсом состояния.
- «Матрица отображает кешированные данные и будет пересчитана после восстановления связи с трекером» — трекер недоступен. Числа в матрице верные, но заголовки и статусы требований могли устареть; состояние подключения смотрите в коннекторе.