Как собрать план тестирования на основе требований и не терять тесты

Тестирование новой функциональности часто начинается с разрыва между требованиями и тестами. Задачи есть в трекере, тесты — в библиотеке, но связи между ними приходится искать вручную. Сборка занимает больше времени: часть тестов теряется, а актуальность покрытия остаётся под вопросом. В Test IT этот сценарий можно упростить: план тестирования собирается от требований, статусы настраиваются под процессы команды, а покрытие тестами становится прозрачным. Разберем и покажем, как это работает.

Наглядная демонстрация от команды Test IT 

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

Проблема: оторванность тестирования от требований

В большинстве команд требования и тесты живут отдельно. Это приводит к ручной работе и постоянным потерям — часть тестов не попадает в прогон, часть остаётся неактуальной, а понять реальное покрытие требований сложно.

Дополнительно усложняют работу статусы. Фиксированные статусы не учитывают специфику команд: базовые варианты вроде «Пройден» или «Провален» не отражают текущий процесс. В работе появляются промежуточные состояния: тест остановлен, отложен, не выполнен из-за окружения. Когда этого нет в системе, страдает как контроль, так и аналитика.

Пользовательские статусы: под процессы команды

Теперь в Test IT можно создавать собственные наборы статусов и применять их к проектам — как на один конкретный, так и на несколько сразу. Это позволяет привести систему в соответствие с тем, как команда действительно работает, а не подстраиваться под фиксированную модель. 

Подробнее — в документации:
https://docs.testit.software/user-guide/work-with-projects/customize-test-point-statuses.html

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

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

Каждая категория имеет свой цвет: от насыщенного (высокий приоритет) к бледному (низкий приоритет). Цвета подобраны так, чтобы корректно отображаться и в светлой, и в тёмной теме интерфейса. Любой пользовательский набор можно установить как набор по умолчанию для всех новых проектов.

В Test IT существует два типа наборов: системный и пользовательские:

1. Системный набор — это те статусы, которыми пользовались раньше. Они остались для обеспечения обратной совместимости. Редактировать его нельзя, но и использовать необязательно.

2. Пользовательские наборы — собственные комбинации статусов, которые создаются с нуля или на основе системных.

У каждого статуса есть название и код. Название можно менять сколько угодно раз — изменения автоматически применятся ко всем результатам, включая исторические. Код менять нельзя: он нужен для идентификации статуса в системе.

Сбор от требований: от задачи к тестам за пару кликов

Основное изменение — сам подход к сборке плана тестирования. Раньше тесты приходилось искать и добавлять вручную. Теперь логика строится от требований.

Достаточно указать задачи из трекера, и система сама находит связанные тесты. Их можно добавить сразу без ручного поиска. Подробнее — в документации:
https://docs.testit.software/user-guide/manual-testing-workflow/create-test-plan.html

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

Покрытие требований: где есть пробелы

Когда библиотека разрастается, становится неочевидно, какие требования действительно покрыты тестами. Часть тестов может быть не связана ни с чем, часть — наоборот, перегружена связями.

Для этого в Test IT появился виджет покрытия требований. Он даёт возможность находить пробелы, пересматривать устаревшие тесты и избегать дублирования. При необходимости данные можно выгрузить и проанализировать детально уже вне системы.

Подробнее про работу с тест-кейсами(сценариями тестирования):
https://docs.testit.software/user-guide/test-cases-and-checklists/test-cases.html

И фильтрацию и поиск:
https://docs.testit.software/user-guide/test-cases-and-checklists/filter-and-search.html

Как это используют в Test IT

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

Попробуйте сами

Функциональность доступна:

• В облачной версии — уже сейчас (14 дней бесплатного доступа)

• В серверной версии — с апреля 2026 (30 дней пробного периода)