Что умеет SaveTest: Git-проекты и классические проекты — какой формат выбрать?

При создании проекта в SaveTest нужно выбрать формат библиотеки: Git или классический. Оба живут на одной платформе — те же прогоны, аналитика, Wiki и роли. Разница в том, где хранятся тест-кейсы и как команда их меняет.

Git-проект здесь более универсальный: библиотека становится частью репозитория и может жить рядом с кодом, ревью и автотестами. Классический проект при этом никуда не делся — это полноценный формат для работы в интерфейсе, в том числе с ветками. А если позже захочется вести кейсы как код, классику можно выгрузить и перенести в репозиторий.


Два формата на одной платформе

В классическом проекте тест-кейсы создаются и редактируются непосредственно в браузере. Отдельный репозиторий для этого не требуется.

В Git-проекте библиотека синхронизируется с Git-репозиторием. SaveTest может подтягивать ее из GitHub, GitLab, Bitbucket, Azure DevOps или другого Git-совместимого сервиса.

После этого привычная работа с TMS никуда не исчезает. Команда по-прежнему видит реестр кейсов, запускает тест-раны и работает с отчетами. Меняется прежде всего источник, из которого формируется библиотека.


Почему Git-проект более универсальный

Git-проект заточен под команды, которым важно держать тестовую документацию рядом с разработкой.

Тест-кейсы как код. Сценарии лежат в репозитории. История правок и ветки идут через Git — как у обычного кода.

Быстрые локальные правки. Кейсы меняются в IDE без ожидания синхронизации и без лишних кликов в браузере. Сохранили файл — изменения уже в рабочей копии, на платформу они попадут после push и синхронизации.

Ревью как у кода. Правки уходят через merge request: комментарии, approve, понятная история. В библиотеку на платформе попадает то, что команда уже просмотрела, а не «тихая» правка в интерфейсе.

Агенты рядом с файлами. Локальные AI-агенты читают и правят YAML, Gherkin и Python прямо в репозитории — без MCP-подключения к платформе. Сценарии для них обычные файлы проекта, а не сущности за API.

Несколько форматов. YAML — рекомендуемый путь, плюс Gherkin и Python. Можно писать кейсы так, как уже принято в команде.

Работа в IDE. Плагин SaveTest для VS Code даёт визуальный редактор: те же карточки и шаги, что на платформе, только файл сохраняется в репозиторий.

Ветки из Git. Ветки приходят из самого репозитория и синхронизируются на платформу. Документацию можно вести параллельно с фича-ветками разработки.

Один источник правды. Ручные кейсы и автотесты не разъезжаются: YAML, сценарии Gherkin или метаданные Allure в коде собираются в ту же библиотеку на платформе.

Коротко: Git-проект удобен, если команда уже живёт в репозитории и хочет, чтобы TMS не была отдельным островом.


Классический проект тоже сильный формат

Классика — это не «урезанный Git». Это отдельный полноценный режим для команд, которым проще вести библиотеку в интерфейсе.

Всё в браузере. Кейсы, наборы и папки создаются прямо в реестре. Git ставить и настраивать не нужно.

Ветки уже есть. В классическом проекте ветки — независимые копии каталога: директории, наборы, кейсы, вложения и Wiki. Можно завести ветку под релиз, изолированно доработать набор и переключиться в реестре одним кликом.

Wiki в интерфейсе. Страницы документации правятся на платформе, без коммитов в репозиторий.

Мигратор из другой TMS. Можно приехать из Test IT, TestRail, Zephyr, Qase или произвольного Excel/CSV — и сразу получить дерево кейсов в классическом проекте.

Классика хорошо заходит на старте, для ручных команд и для ситуаций, когда репозиторий пока не нужен, но ветвление тестовой документации уже хочется.


Что выбрать: короткое сравнение

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


Можно начать с классики, а потом уйти в репозиторий

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

Команда может сначала собрать библиотеку в классическом проекте, вручную или с помощью мигратора. Когда появится потребность вести тест-кейсы как код, проект можно выгрузить в ZIP в структуре репозитория с YAML, Gherkin или Python. Получившийся архив импортируется в Git-проект через расширение SaveTest в IDE. После этого источником библиотеки становится уже репозиторий, с которым и синхронизируется платформа.

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


Вместо вывода

Git-проект в SaveTest подходит командам, которые хотят держать тест-кейсы рядом с кодом: редактировать их локально, проводить ревью через Git, работать с ветками разработки и давать доступ к файлам локальным агентам без отдельного подключения к платформе.

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

И это, пожалуй, главное различие двух подходов. Выбирать приходится не между «простым» и «продвинутым» SaveTest, а между двумя способами организации работы. А если требования команды изменятся, библиотеку можно перенести из классического проекта в Git и продолжить работу уже с другой моделью хранения.