В большинстве 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 в ручной таск-трекер.
Получается простое разделение ответственности:
Именно в этой связке находится главное отличие платформы. SaveTest не делает TMS единственным источником тестовых артефактов. Он работает поверх репозитория и использует его как основу.
Аналитика и аудит
TMS нужна не только для выполнения проверок. В какой-то момент команде важно ответить на более управленческие вопросы:
В SaveTest для этого предусмотрены отчеты по тест-ранам, аналитика проекта, сравнение тест-ранов, контроль качества, результаты команды, настраиваемый дашборд и аудит. Аудит здесь важен не как формальная галочка. Если тестовая база и результаты проверок участвуют в релизном процессе, команда должна понимать, что происходило в конкретном цикле: какие кейсы использовались, какие результаты были получены, кто выполнял проверки, какие изменения вносились и когда.
Для кого это имеет смысл
SaveTest в первую очередь рассчитан на команды, которым тесно в таблицах, неудобно в классической 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 сделан вокруг другого принципа: тест-кейсы хранятся в 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.