В больших компаниях есть специальные базы данных для тестов, которые помогают всем командам работать по одним и тем же правилам. Эти базы данных позволяют сохранять результаты тестов в разных системах, что иногда усложняет управление.
Чтобы упростить работу, разные части системы могут обмениваться тестовыми данными. Например, если нужно провести проверку или объединить опыт разных команд, данные из одной системы можно перенести в другую. Это позволяет централизованно управлять тестами и уменьшает необходимость вручную проверять каждую деталь.
Интеграция между инстансами закрывает практическую задачу: переносит тестовую базу и связанную историю запусков в нужный контур — например, в «центральный» инстанс для аудита, отчётности или консолидации практик. В таком подходе «Централизованное управление тест-кейстами» становится не лозунгом, а рабочей моделью: единые сущности, единые правила, меньше ручной сверки.
В этой статье разобраны типовые сценарии, границы синхронизации, роль AQL-разметки, маппинг метаданных и риски.
Интеграция между инстансами ТестОпс и что именно переносится
Интеграция с ТестОпс позволяет автоматически экспортировать тест-кейсы и запуски из одного проекта в другой, включая проекты на разных инстансах. Основная цель переноса данных — обеспечить совместимость между двумя уровнями информации.
Первый слой — «содержание»: тест-кейс (test case) как единица проверки, которая участвует в планировании, ревью и исполнении, а также в построении покрытия.
Второй слой — «факт выполнения»: запуски и результаты, которые позволяют анализировать результат тест кейса и динамику качества по времени. В реальных процессах этот слой тесно соседствует с CI/CD (непрерывная интеграция и доставка): прогоны идут часто, а ценность появляется только тогда, когда история сохраняется и сопоставляется.
Перенос тест-кейсов и запусков между инстансами
Интеграция становится полезной, когда тестовая база перестает быть изолированным ресурсом одной команды. Её главная ценность — снижение объема ручной работы. Это достигается за счет уменьшения дублирования при описании проверок, сокращения расхождений между ветками процессов и упрощения передачи знаний между проектами. Кроме того, интеграция упрощает работу с отчетами о дефектах. Контекст находится быстрее, когда проверки и история прогонов доступны в одном месте.
Интеграция повышает прозрачность качества. Объединение описаний проверок и результатов запусков в одной системе упрощает обсуждение рисков релиза, улучшает оценку стабильности и планирование работ. Отчётность становится частью процесса, а не отдельным проектом.
Возникает предсказуемая модель масштабирования. При нескольких инстансах по организационной структуре, географии или уровням доступа используется стандартный механизм переноса тестовых данных. Это уменьшает избыточность процессов и упрощает поддержку.
Как в интеграции управляется объём данных и границы синхронизации
Граница синхронизации задаётся правилами экспорта: они определяют целевой проект и то, какие тест-кейсы и запуски попадут в перенос.
Ключевой регулятор здесь — AQL (Allure Query Language). В интеграции AQL используется, чтобы выбрать нужный набор данных для экспорта. Это и есть практический смысл термина «AQL-разметка» в контексте интеграции: правила отбора описываются запросами, а не ручными списками.
В типовой конфигурации встречаются три управляемых решения:
- Экспортировать только часть тестовой базы, привязанную к конкретной области или типу проверок, через Test Case AQL.
- Экспортировать только нужную историю прогонов по выбранным тест-кейсам через Launches AQL.
- Исключить перенос запусков целиком, если нужен только каталог тестов, без истории выполнения.
Такой контроль объёма данных особенно важен, когда в одном контуре живут и тест-план (test plan), и разные уровни зрелости процессов: у части команд есть плотный поток запусков, у части — фокус на структуре тестов.
Важность согласования метаданных тест-кейсов
Метаданные часто становятся причиной скрытых проблем между инстансами. Структура и значения статусов, воркфлоу, тестовых слоев, кастомных полей и ролей участников могут различаться. Документация прямо говорит, что тест-кейсы на разных инстансах могут иметь разные метаданные. Пример со статусом показывает, что целевой инстанс может не обработать значение, которого у него нет.
Главное отличие интеграции здесь в том, что по умолчанию она игнорирует значения метаданных тест-кейсов (в том числе встроенные), и перенос метаданных требует явного маппинга.
Какие типы маппинга учитываются
В правилах экспорта предусмотрен маппинг для нескольких групп метаданных: статусы, воркфлоу, тестовые слои, кастомные поля и роли участников.
Маппинг выступает в роли «переводчика» между инстансами. Он определяет, как значение на входе преобразуется в значение на выходе, и что делать, если соответствия нет.
Как маппинг помогает избежать потери данных
В логике маппинга есть две ключевые концепции.
Во-первых, можно сохранять встроенные значения без ручной настройки соответствий. Это удобно для системных сущностей.
Во-вторых, предусмотрена управляемая деградация. Если у значения нет соответствия и не установлено значение по умолчанию, оно может быть удалено при экспорте. Это предпочтительнее некорректной подмены, так как расхождение становится очевидным и контролируемым.
Во-первых, можно сохранять встроенные значения без ручной настройки соответствий. Это удобно для системных сущностей.
Во-вторых, предусмотрена управляемая деградация. Если у значения нет соответствия и не установлено значение по умолчанию, оно может быть удалено при экспорте. Это предпочтительнее некорректной подмены, так как расхождение становится очевидным и контролируемым.
Какие права и учётные данные участвуют в интеграции
Интеграции в ТестОпс относятся к административной плоскости. Для настройки или удаления интеграции с внешней системой в документации указана необходимость глобальной роли «Администратор» в инстансе ТестОпс. В сценарии «ТестОпс ↔ ТестОпс» это по сути означает: интеграция контролируется на уровне инстанса и требует соответствующих прав.
Аутентификация опирается на API-токен, который служит учётными данными для связи с целевым инстансом. Важно отметить типы учётных данных. Интеграция работает с глобальными и/или проектными учётными данными, выбор которых определяет модель доступа.
Контроль надёжности синхронизации и рисками остановки
Синхронизация не является «вечным фоном». В документации описан механизм автоматического отключения синхронизации, если API-токен недействителен, отозван или имеет недостаточный уровень доступа.
Чтобы такие события не превращались в «тихую» деградацию, в правилах экспорта предусмотрен email для уведомлений, когда синхронизация автоматически отключается.
Отдельная зона риска — удаление интеграции. В документации различаются два уровня:
- Удаление на уровне инстанса приводит к удалению связей с тест-кейсами целевого инстанса из сущностей текущего инстанса; восстановление удалённых ссылок не предполагается.
- Удаление на уровне проекта сохраняет существующие связи, но отключает возможность создавать новые связи для проекта и отключает синхронизацию с целевым инстансом.
Ключевая идея в том, что интеграция это не только канал переноса данных, но и договорённость о том, как именно данные связаны между собой. Поэтому администрирование интеграции напрямую связано с управлением рисками, аудитом изменений и контролем доступа.
Как интеграция поддерживает централизованный контур качества и работу с CI/CD
Платформа ТестОпс в таких сценариях выступает как система управления тестированием: общий слой для test case management, аналитики и согласования факта выполнения. Когда тест-кейсы и запуски собираются в одном контуре, меньше усилий уходит на ручную сверку между командами и средами, а обсуждение качества опирается на согласованные сущности, а не на разрозненные отчёты.
В практическом плане интеграция помогает удерживать два параллельных режима:
- «Рабочие» инстансы, где идёт активное тестирование ПО, прогоняются проверки и фиксируются баг репорт (bug report).
- «Центральный» инстанс, где строится «Централизованное управление тест-кейстами», согласуются метаданные и сохраняется репрезентативная история запусков.
AI Ассистент в этом контуре уместен как отдельный слой работы с информацией на платформе, когда требуется быстро формулировать сводки, извлекать контекст или унифицировать описание артефактов. Эта роль не подменяет правила интеграции и маппинг, но дополняет работу с большим объёмом текста и связей.
FAQ
Можно ли экспортировать данные между проектами внутри одного инстанса?
В описании сценариев интеграции отдельно отмечается, что экспорт возможен и в пределах текущего инстанса, например между проектами.
Что происходит, если на целевом инстансе нет нужного статуса или другого значения метаданных?
Разные инстансы могут иметь разные наборы метаданных, и без маппинга часть значений может не обрабатываться на целевой стороне.
Можно ли ограничить перенос только тест-кейсами без истории запусков?
В настройках правила экспорта предусмотрена опция отключить экспорт запусков, что оставляет перенос тестовой базы без истории прогонов.
Почему синхронизация иногда останавливается «сама»?
Синхронизация автоматически отключается, если используемый API-токен недействителен, отозван или не имеет достаточного уровня доступа.
Коротко о главном
Интеграция тест-кейсов и запусков в TMS ТестОпс объединяет тестовую базу и историю выполнения между проектами и инстансами. Она позволяет отслеживать качество тестируемого продукта и сравнивать процессы между командами.
Основные элементы интеграции включают AQL-разметку для управления объемом данных, маппинг метаданных для совместимости и модель доступа через роли и API-токены. Платформа ТестОпс с этой структурой обеспечивает централизованное управление тест-кейсами, уменьшая ручной труд, расхождения и улучшая контроль над результатами тестирования.
