В большинстве TMS тест-кейсы создаются и хранятся внутри самой системы. Это привычная модель, содержащая интерфейс, разделы, наборы кейсов, тест-раны, статусы, назначения, отчеты. Она закрывает базовые задачи управления тестированием, но плохо стыкуется с инженерным процессом, если разработка уже живет в Git. Проблема не в том, что командам негде вести тест-кейсы. Обычно у них уже есть решение: в TMS, Jira, Confluence, Google Sheets, Markdown-файлах или самописном ПО. Вопрос состоит в том, насколько тестовая база контролируема, версионируема и связана с реальным жизненным циклом продукта.

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

SaveTest сделан вокруг другого принципа: тест-кейсы хранятся в Git-репозитории в формате YAML(Python, Gherkin и др.). Git становится источником тестовой документации, а TMS — рабочим слоем поверх него: с визуальным редактором, тест-ранами, назначениями, статусами, результатами, аналитикой и аудитом.

Идея не в том, чтобы заменить одну TMS другой. Идея в том, чтобы вернуть тестовую базу в инженерный контур команды.

Тест-кейсы как код

Ключевой принцип SaveTest — test cases as code.

Тест-кейс в SaveTest — это структурированный YAML-файл. В нем можно описывать идентификатор, название, предусловия, шаги, ожидаемый результат, теги, параметры, ссылки, вложения и другие поля, необходимые для работы с тестовой базой. За счет этого тестовая документация становится не набором записей в закрытом интерфейсе, а нормальным проектным артефактом. Ее можно хранить в репозитории, изменять через ветки, ревьюить через pull request, связывать с задачами, релизами и изменениями в продукте.

Это особенно важно для команд, где тестовая база развивается вместе с системой. Если функциональность меняется постоянно, тест-кейсы не должны актуализироваться «где-то отдельно» перед релизом. Они должны проходить тот же жизненный цикл, что и остальные инженерные артефакты: изменение, проверка, ревью, слияние, история.

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

Что меняется для команды

Хранение тест-кейсов в Git дает не абстрактную «прозрачность», а вполне конкретные вещи.

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

Ветки. Можно вести разные состояния тест-кейсов для релизной ветки, активной разработки, hotfix-ветки или долгоживущего контура поддержки.

Ревью. Изменения в тестовой документации можно проверять до попадания в основную ветку. Это полезно, когда сценарии затрагивают критичные бизнес-процессы или должны согласовываться между QA, аналитиками и разработкой.

История. По каждому изменению остается технический след: кто правил, когда, что именно изменилось и с каким контекстом.

Восстановление. Ошибочные изменения можно откатить штатными Git-механизмами.

Переносимость. Тестовая база остается у команды в репозитории, а не растворяется внутри конкретного инструмента.

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

Это не только для автоматизаторов

У подхода test cases as code есть очевидный риск. Он может выглядеть слишком техническим для ручного QA. Если тестировщику каждый день приходится руками редактировать YAML(Python, Gherkin и др.), следить за синтаксисом и разбираться с Git-конфликтами, польза быстро превращается в сопротивление команды.

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

То есть SaveTest поддерживает две модели работы.

Для технических специалистов доступен инженерный сценарий: IDE, YAML(Python, Gherkin и др.), Git, ветки, ревью, валидация. Для ручных тестировщиков и QA-лидов доступен обычный TMS-сценарий: визуальный редактор, реестр кейсов, тест-раны, назначения, результаты и отчеты. Это важная часть архитектуры продукта: хранение тест-кейсов как кода не отменяет привычный интерфейс работы с тестированием.

VS Code-плагин

Для команд, которые хотят работать ближе к репозиторию, в SaveTest есть расширение для Visual Studio Code. Плагин помогает создавать сущности по шаблонам, редактировать тест-кейсы, выполнять валидацию и работать с Git напрямую из IDE. Это снижает объем ручной работы с YAML(Python, Gherkin и др.) и делает подход test cases as code более прикладным.

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

TMS-слой поверх Git

Git хорошо решает задачи хранения, ветвления, истории и ревью. Но он не заменяет TMS. Команде все равно нужно планировать тестирование, собирать тест-раны, назначать проверки, фиксировать результаты, видеть прогресс, работать с дефектами, вложениями, ссылками, итерациями и отчетами. Эту операционную часть берет на себя SaveTest.

В платформе можно вести проекты, синхронизировать их с репозиторием, работать с реестром тест-кейсов, выбирать ветку, запускать тест-раны, распределять проверки между исполнителями и отслеживать выполнение.

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

Получается простое разделение ответственности:

• Git хранит тестовую базу как инженерный артефакт.
• SaveTest управляет тестированием как процессом.

Именно в этой связке находится главное отличие платформы. SaveTest не делает TMS единственным источником тестовых артефактов. Он работает поверх репозитория и использует его как основу.

Аналитика и аудит

TMS нужна не только для выполнения проверок. В какой-то момент команде важно ответить на более управленческие вопросы:

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

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

Для кого это имеет смысл

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

Платформа имеет смысл, если:

• разработка уже живет в Git;
• есть релизные ветки, несколько версий продукта или несколько контуров поставки;
• ручное и автоматизированное тестирование должны опираться на общую тестовую модель;
• тестовую базу нужно ревьюить, версионировать и восстанавливать;
• важны аудит, история изменений и контроль над тестовыми артефактами;
• команда хочет работать в привычном TMS-интерфейсе, но не хранить кейсы только внутри TMS;
• требуется решение, которое можно развернуть в собственном контуре.

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

Не “еще одна TMS”, а другая модель владения тестовой базой

У большинства систем управления тестированием похожий верхний слой: тест-кейсы, наборы, тест-раны, статусы, отчеты, пользователи, роли. Это ожидаемый функциональный минимум для TMS.

SaveTest отличается не тем, что в нем тоже есть эти функции. Отличие ниже — на уровне модели хранения.

В классической TMS тестовая база живет внутри продукта. В SaveTest она остается в Git-репозитории команды. Это меняет не внешний сценарий работы, а принцип владения тестовой документацией.

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

Если коротко, то SaveTest — это TMS поверх Git, а не TMS вместо Git.

Классический подход

Save Test поддерживает не только Git-ориентированную модель, но и классические проекты – привычный сценарий для пользователей TMS. Работа с тест-кейсами и структурами остается в знакомом формате, без резких изменений.

Как попробовать SaveTest

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

Также доступна бесплатная лицензия: 1 проект, 1 пользователь и 10 тестовых прогонов.

Этого достаточно, чтобы проверить базовый сценарий: создать или импортировать тестовую базу, связать ее с репозиторием, запустить тест-ран и оценить, насколько подход test cases as code применим к процессу вашей команды.

Запустите демо-доступ платформы, чтобы ознакомиться с SaveTest.

Знакомая ситуация: у вас есть полсотни тест-кейсов, и в каждом из них первые три шага — это авторизация, подготовка тестового окружения или генерация данных. Вы послушно копируете этот блок из кейса в кейс. Но что происходит, когда флоу авторизации немного меняется? Правильно: вам приходится вручную обновлять десятки сценариев. Библиотека раздувается, а риск забыть обновить значительно возрастает.

Чтобы навсегда закрыть эту проблему, в SaveTest реализован механизм Общих кейсов. В этой статье мы детально разберем, как они работают под капотом и как помогают навести порядок в тестовой документации.

По сути это переиспользуемые фрагменты тестовых сценариев. Вы описываете типовую последовательность действий один раз и сохраняете ее как общий кейс. Во всех остальных сценариях вы просто оставляете на него ссылку, например <Авторизация под админом>.

Когда тестировщик открывает кейс для просмотра или запускает тест-ран, система на лету подставляет реальные шаги на место этой ссылки. Механизм универсален: он работает как в классических проектах с UI-интерфейсом, так и при подходе «тест-кейсы как код» — в Git-проектах через YAML-файлы, где такие кейсы хранятся в каталогах common-case или .common-case.

Чтобы не создавать путаницу в реестре, мы реализовали четкое разделение сущностей:

Процесс подключения общих кейсов сделан максимально бесшовным.

В репозитории с тест-кейсами в YAML общие кейсы лежат отдельно от обычных наборов — обычно в tests/common-case/. После команды инициализации проекта эта папка появляется вместе с tests/test-case/ и tests/attach/. Если использовать визуальный редактор, создание и подключение общего кейса мало чем отличается от классического проекта.

1. Создаем общий кейс. Есть два удобных способа:

2. В обоих случаях заполните title и блок steps, затем сохраните файл.

3. Подключаем к сценарию. Откройте test-suite.yaml, включите визуальный редактор и в шагах, предусловиях или постусловиях нажмите «Общий кейс» — выберите файл и нужный кейс. В YAML появится ссылка <Имя общего кейса> и блок метаданных:

pre-conditions:
- action: <Предусловие авторизации>
common_cases:
- case_id: "uuid"
name: Предусловие авторизации
path: tests/common-case/common-case.yaml

Внедрение общих кейсов решает сразу несколько инфраструктурных задач QA-отдела:

Чтобы инструмент работал предсказуемо, важно помнить несколько правил:

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

И главное правило: перед тем как радикально переписать или удалить существующий общий кейс, учитывайте все сценарии, куда он уже подключен.