Блог

Как связать требования с тестом в ТестОпс

2026-02-20 13:00
Требования часто не связаны с тестами. То, что мы хотим сделать, записывается в одном месте, а проверки проводятся в другой системе. Из-за этого непонятно, какие функции уже проверены, какие остались без проверки, а какие изменения могут нарушить работу других частей программы.
Платформа ТестОпс помогает управлять процессами тестирования в одном месте и поддерживает жизненный цикл ручных и автоматизированных тестов. В экосистеме тестовые артефакты связаны друг с другом и с внешними источниками, обеспечивая управляемую трассируемость.

Что означает связь требований из внешней системы с тест‑кейсом в контексте TMS ТестОпс

Интеграция = сущность ТестОпс, которая позволяет взаимодействовать с внешними системами, например: CI-системами, таск-трекерами, сторонними TMS. Каждая интеграция специфична для определенной системы.
Связь требований = привязка требования из внешней системы к ручному тест‑кейсу в TMS ТестОпс.
Для требований это означает, что источник требований находится вне ТестОпс, а связь появляется через интеграцию, которая задаёт правила доступа и список доступных объектов.

Зачем связывать требования и тест‑кейсы

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

Преимущества в управлении изменениями

Связка работает как список «затронутых проверок». При изменении требования быстрее находится набор тест‑кейсов, который влияет на релиз, и яснее видна зона регресса. В релизных циклах часто всплывает вопрос «зачем нужен тест-план»: связка требований помогает делать тест‑план (test plan) конкретным и проверяемым, потому что он собирается из тестов, уже связанных с требованиями.

Упрощенная коммуникация между QA и продуктом

Связка требований в процессе тестирования значительно упрощает коммуникацию между командами QA и разработки.
Когда результаты тестирования формулируются на основе связанных требований, это позволяет обеим сторонам говорить на одном языке. В центре обсуждения качества оказываются «требования» и «пользовательские истории» — ключевые элементы, которые помогают четко определить, что именно было проверено. Это устраняет необходимость в ручной интерпретации данных, делая процесс более прозрачным и эффективным.
Таким образом, система управления тестированием обеспечивает точное понимание того, какие аспекты продукта были проверены, что способствует более слаженной работе и улучшению качества конечного продукта.

Отличия между связью с требованиями и ссылкой в тест‑кейсе

В тест‑кейсе можно хранить ссылку на любой внешний ресурс — это способ держать рядом дополнительный контекст. В TMS ТестОпс доступны ссылки на любые внешние URL и поддерживаются ссылки на задачи и требования из внешних систем. Главное отличие: «требование» в модели требований участвует в фильтрации тестов и результатов и проявляется на уровне запуска, а не остаётся просто справочной ссылкой.
Для привязки тест-кейса к внешним требованиям нужна:
  1. Настроенная интеграция с системой, с задокументированными и отслеживаемыми требованиями. Подробнее см. Интеграции с внешними системами → Настройка интеграции.
  2. Ссылка на требования из настроенной интеграции в тест-кейс.

Результат связки: фильтрация, результаты, запуски

Фильтрация по требованиям

После добавления требований к тест‑кейсам доступна фильтрация тест‑кейсов и результатов тестов по требованиям. Это удобная точка входа для аналитики: одна выборка собирает «все проверки по требованию» и показывает их статус.

Виджет «Требования» в запуске

Связка проявляется и на уровне запусков. В описании карточки запуска указано, что на вкладке «Обзор» есть виджет «Требования»: он показывает требования, участвовавшие в запуске, и результаты связанных с ними тестов. Это даёт наблюдаемость прогресса по требованиям там же, где анализируются результаты, ошибки и связанные артефакты.

Какие данные используются в интеграциях

Глобальный уровень учётных данных

Интеграции используют глобальные и проектные учётные данные внешних систем. Они определяют, от имени какого пользователя и с какими разрешениями ТестОпс обращается к внешнему источнику. Глобальные учётные данные добавляются администратором на уровне инстанса и могут использоваться в любом проекте — это основа для единых настроек и централизованного контроля доступа.

Проектный уровень учётных данных

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

Глобальные роли в ТестОпс

Глобальные роли определяют возможности пользователя на уровне инстанса ТестОпс. В документации перечислены три роли: «Администратор», «Пользователь» и «Гость». Также отмечается, что настройка интеграций на уровне инстанса доступна только администратору.

Как сохранить трассируемость

Для обеспечения качества и контроля изменений в процессе разработки необходимо учитывать несколько ключевых факторов:
  • Поддержка требований зависит от типа интеграции.
  • Интеграция опирается на учётные данные и права. При недостаточных разрешениях связка оказывается неполной: требования видны не все или видны с ограничениями.
  • Действия с интеграциями влияют на данные. При удалении интеграции на уровне инстанса связи между сущностями ТестОпс и внешней системой удаляются необратимо; при удалении на уровне проекта данные сохраняются, но новые связи создавать нельзя, и синхронизация отключается.
  • Итоговая ценность связки зависит от дисциплины case management (управления тест‑кейсами): если тест‑кейсы не обновляются под изменения требований, связь фиксирует историю, но не гарантирует актуальность проверок.

Как связка требований встраивается в контур CI/CD и отчётов Allure Report

CI/CD (непрерывная интеграция и доставка) сокращает расстояние между изменением кода и релизом. В ТестОпс запуск открывается карточкой с данными по результатам и ошибкам, которые помогают анализировать проблемные места проекта; в описании продукта также упоминаются регистрация дефектов для упавших тестов и связывание упавших тестов с задачами в таск‑трекере. В этот момент практично звучит и «что такое баг-репорт»: баг‑репорт (bug report) фиксирует дефект и контекст падения, и его проще собирать, когда требование связано с тестами и результатами.

Как AQL-разметка помогает формализовать выборки и метрики

Разметка на AQL (allure query language) позволяет выбирать нужные тест‑кейсы, результаты тестов или запуски в разделах вроде дашбордов и при использовании API, так фильтры можно превратить в воспроизводимые правила и закрепить метрики без ручной сборки списков.

Чем может помочь AI Ассистент

AI Ассистент ТестОпс поставляется вместе с основным продуктом. Для него есть пополняемая библиотека навыков и возможность создавать собственные навыки. В связке «требование → тест‑кейс → результат» ассистент логично использовать там, где важна скорость обработки формулировок и согласованность метаинформации в тестовой базе, это проявляется следующим образом:
  • Анализ контекста и данных: благодаря MCP-серверу ассистент способен видеть контекст тест-кейсов и анализировать данные внутри проектов. Это позволяет лучше понимать требования, поступающие из внешних систем, и устанавливать связи между ними и тест-кейсами.
  • Обработка формулировок: ассистент ускоряет обработку текстовых данных, что особенно полезно при работе с требованиями, поступающими из внешних источников. Он помогает быстро преобразовать и структурировать требования для дальнейшего использования в тестировании.
  • Согласованность метаинформации: при интеграции требований из внешних систем ассистент обеспечивает согласованность метаинформации в тестовой базе. Это гарантирует, что все требования корректно учитываются и анализируются в процессе тестирования.
  • Адаптация под нужды проекта: благодаря возможности создавать собственные навыки и использовать библиотеку готовых, ассистент можно настроить так, чтобы он оптимально работал с конкретными форматами и источниками требований.
  • Интеграция с внешними системами через LLM: возможность подключения большой языковой модели (LLM) в закрытом контуре позволяет эффективно обрабатывать и анализировать требования, поступающие из различных внешних систем, сохраняя при этом безопасность данных.

FAQ

Почему требования связываются с ручными тест‑кейсами?

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

Что важно проверить, если требования не отображаются или покрытие выглядит неполным?

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

Что происходит со связями при удалении интеграции?

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

Коротко о главном

Связь требований из внешней системы с тест‑кейсами в TMS ТестОпс делает трассируемость частью процесса, а не отдельным документом. Она помогает фильтровать тесты и результаты по требованиям, видеть покрытие и прогресс, и обсуждать качество через понятные продукту сущности. Итог: «Централизованное управление тест-кейстами» становится измеримым, когда требования, запуски, AQL‑разметка и отчёты Allure Report сходятся в единую модель контроля изменений и рисков.
Связка даёт управляемые точки контроля. QA‑лид получает единый способ объяснить риски по требованиям. Руководителю проще согласовывать решение о выпуске по наблюдаемым данным как переход от хранения артефактов к управлению качеством по измеримым правилам.