SaveTest: мы выпустили TMS, в которой тест-кейсы живут ближе к коду
2026-05-12 10:01
У большинства QA-команд уже есть инструмент для тест-кейсов. Это может быть классическая TMS, Jira, Confluence, Google Sheets, Markdown в репозитории или внутренняя разработка. Поэтому вопрос “нужна ли команде система управления тестированием” давно не стоит.
Вопрос в другом: насколько тестовая база встроена в реальный инженерный процесс.
Код меняется через Git, автотесты запускаются в CI/CD, задачи проходят через трекер, релизы собираются по понятному воркфлоу. А ручные тест-кейсы, чек-листы и регрессионные наборы часто остаются в отдельном инструменте, который приходится синхронизировать с разработкой вручную.
На небольшом проекте это терпимо. На продукте с частыми релизами, несколькими командами и растущим количеством проверок такой разрыв быстро становится операционным долгом. В какой-то момент команда начинает тестировать не только продукт, но и актуальность собственной тестовой базы.
SaveTest строится вокруг другой идеи: тест-кейсы должны быть ближе к тому месту, где уже живет инженерный процесс. То есть к Git.
Не “еще одна база тест-кейсов”
Классическая TMS часто становится отдельным хранилищем тестовой документации. Это удобно для ручного тестирования, тест-ранов
и отчетности, но у такого подхода есть ограничение: тест-кейсы начинают жить отдельно от кода, автотестов и привычного процесса изменения продукта. В результате команда получает дополнительный контур синхронизации.
Если изменилась бизнес-логика, то нужно отдельно обновить сценарии.
Если изменился API, то нужно понять, какие проверки затронуты.
Если появился новый пользовательский путь, то нужно не забыть включить его в регресс.
Если ушел старый функционал, то нужно удалить или переписать устаревшие тесты.
Проблема не в том, что тест-кейсов нет. Проблема в том, что они не всегда управляются как инженерный артефакт. Тест-кейс описывает ожидаемое поведение системы, фиксирует проверяемую логику и влияет на решение о готовности релиза. Поэтому к нему логично применять те же принципы, которые давно используются в разработке: версионирование, прозрачная история изменений, ревью и связь с изменениями в продукте.
Git как источник тестовой базы
В SaveTest тест-кейсы могут храниться в Git-репозитории. Репозиторий становится источником тестовой базы, а сама TMS становится слоем для синхронизации, выполнения тест-ранов, назначения исполнителей, фиксации результатов и аналитики. Это важное разделение ответственности.
Git хорошо решает задачи хранения, истории изменений и контроля версий. TMS хорошо решает задачи организации тестирования. Понятно кто выполняет проверки, что вошло в тест-ран, какие сценарии пройдены, где блокеры, какие зоны продукта остаются непроверенными.
SaveTest не пытается заменить Git там, где Git уже является стандартом для команды. Вместо этого платформа использует Git-подход как основу и добавляет поверх него рабочий слой для QA-процесса. Такой подход особенно полезен там, где тестовая документация должна быть не статичной базой, а частью жизненного цикла продукта.
Как это выглядит в работе
Команда хранит тест-кейсы в репозитории. SaveTest синхронизирует их и позволяет работать с ними в интерфейсе TMS: собирать тест-раны, назначать ответственных, фиксировать статусы, отслеживать прогресс и анализировать результаты.
Для QA-инженера это означает, что тест-кейсы остаются структурированными и доступны в понятном рабочем процессе.
Для QA Lead — что состояние тестирования видно не по устным апдейтам и ручной сборке статусов, а через тест-раны, прогресс, результаты и аналитику.
Для разработчика — что тестовая документация становится ближе к коду и изменениям в продукте.
Для технического руководителя — что тестирование перестает быть отдельной “черной коробкой” и становится более прозрачной частью релизного процесса.
Работа с тест-кейсами в VS Code
Git-подход не должен превращаться в требование вручную редактировать сложные YAML-файлы и помнить структуру каждого поля. Поэтому для SaveTest предусмотрен плагин для VS Code.
Он нужен, чтобы работать с тест-кейсами в привычной среде, чтобы создавать и редактировать сценарии, использовать подсказки, проверять корректность структуры и снижать количество ошибок при описании тестовой базы. Это важная часть продукта. Если тест-кейсы хранятся в Git, то инструменты работы с ними должны быть удобны не только в веб-интерфейсе TMS, но и там, где команда уже работает с кодом и репозиторием.
Ручные проверки, автотесты и парсеры
В реальных проектах ручное и автоматизированное тестирование редко живут изолированно. Часть проверок автоматизирована, часть остается ручной, часть зависит от бизнес-контекста, интеграций, данных или пользовательских сценариев. Поэтому TMS не должна быть только интерфейсом для ручных тест-кейсов.
В SaveTest предусмотрена плагинная архитектура для парсинга тестовых файлов. Это позволяет расширять поддержку разных форматов и фреймворков без жесткой привязки к одному способу описания тестов.
С практической точки зрения это дает команде пространство для развития: можно связывать тестовую базу, автотесты, тест-раны и аналитику в одном процессе, не заставляя всех работать строго в одном формате.
Тестраны и аналитика без ручной сборки картины
Перед релизом команде важно быстро ответить на несколько простых вопросов.
Что вошло в проверку?
Что уже пройдено?
Где блокеры?
Какие сценарии упали?
Какие зоны продукта не покрыты?
Можно ли двигаться дальше?
Если ответы собираются из TMS, баг-трекера, CI/CD, отчетов, таблиц и переписок, решение о готовности релиза становится слишком зависимым от ручной агрегации. SaveTest закрывает эту часть через тест-раны, статусы, назначение исполнителей, дашборды и отчеты.
Графики сами по себе никого не спасают. Ценность появляется только тогда, когда по ним можно принять решение: релизим, откладываем, добираем регрессию или разбираем блокеры. Поэтому аналитика в SaveTest — это не декоративный слой, а инструмент управления рисками в текущем тестовом цикле.
Для QA Lead это способ контролировать процесс без постоянного ручного сбора статусов. Для руководителя проекта появляется возможность получить понятную картину качества без погружения в каждую отдельную проверку.
Корпоративный контур и контроль над данными
Для многих компаний выбор TMS — это не только вопрос интерфейса и функций. Важны размещение, доступы, модель эксплуатации, интеграции, безопасность и контроль над данными. Не всем подходит внешний SaaS. Не все готовы выносить тестовую базу, связанную с продуктовой логикой, во внешний контур. В ряде компаний инструменты тестирования должны устанавливаться внутри инфраструктуры и соответствовать внутренним требованиям безопасности.
Платформа рассчитана на работу в корпоративном контуре и подходит командам, которым важно сохранять контроль над тестовой документацией, результатами проверок и связанными процессами. Для части компаний это еще и вопрос закупки, поддержки и эксплуатации. Инструмент должен быть доступен для внедрения во внутреннем контуре, с понятной командой разработки и без зависимости от внешнего SaaS.
Классический подход
SaveTest не ограничивается только Git-подходом – он подходит не всем и не всегда сразу. Поэтому здесь есть и классический формат работы с проектами, знакомый по другим TMS. Можно вести тестовую документацию и сценарии в привычной логике, без перестройки процессов.
Кому будет полезен SaveTest
SaveTest в первую очередь рассчитан на команды, у которых тестирование уже есть как процесс, но инструментальная среда стала слишком разрозненной. Платформа будет особенно полезна, если:
Git уже является основой инженерного воркфлоу;
тест-кейсы нужно версионировать и хранить под контролем команды;
ручные проверки и автотесты должны быть связаны в едином процессе;
текущая TMS живет отдельно от разработки;
перед релизом приходится вручную собирать картину качества;
внешний SaaS не подходит из-за требований безопасности или корпоративного контура;
QA-команде важно видеть не просто список тест-кейсов, а состояние тестирования в конкретном цикле.
Это не история про “заменить все одним инструментом”. Скорее про то, чтобы убрать разрыв между тестовой базой, разработкой и релизным процессом.
Что можно посмотреть уже сейчас
Лучший способ оценить такой подход – проверить его на реальном сценарии. Попробовать подключить репозиторий, синхронизировать тест-кейсы, собрать тест-ран, назначить исполнителей и посмотреть, насколько прозрачнее становится картина тестирования.
SaveTest можно изучить через сайт продуктаидемо-проект. Там можно посмотреть, как устроена работа с тест-кейсами, Git-синхронизацией, тест-ранами, аналитикой и командным процессом.
Также доступна бесплатная лицензия: 1 проект, 1 пользователь и 10 тестовых прогонов.
Если вам близок подход “test cases as code”, то SaveTest стоит смотреть именно с этой стороны. Не как очередную TMS с интерфейсом для тест-кейсов, а как слой управления тестированием поверх Git-процесса.