SaveTest помогает команде не только хранить тест-кейсы и запускать прогоны. Он особенно полезен там, где начинается рутина: один и тот же сценарий гоняют на разных наборах данных, а проверки повторяют на нескольких окружениях. В итоге библиотека раздувается клонами, а метаданные прогонов становятся не консистентными.
Система решает проблему через явное разделение двух плоскостей: «что тестируем с разными входными данными» и «на каком окружении тестируем». Команда получает нормализованную библиотеку кейсов, предсказуемые прогоны и отчеты, которые однозначно связываются с конкретными сценариями и стендами. Ключевую роль тут играют две сущности, которые решают разные задачи, но в связке формируют прозрачный процесс: параметризация тест-кейсов и конфигурации тест-рана.
Параметризация тест-кейсов: Один кейс – десятки сценариев данных без копипаста
Параметризация позволяет описать логику проверки один раз, а варианты входных данных (логин, роль, сумма и т.д.) задать отдельной таблицей. Каждый вариант данных становится отдельной итерацией.
Как это работает просто:
- Параметры в шагах подставляются сами во время прогона. В описании шагов используются подстановки вида «логин пользователя», и система автоматически подставляет значения текущей итерации.
- В тест-ране кейс «раскладывается». При добавлении в прогон он появляется столько раз, сколько задано итераций — это удобно для назначения, отметки статусов и построения отчета по каждому варианту.
- Для классики и Git-проектов. Настраивайте параметры в интерфейсе библиотеки (Классический проект) или подтягивайте итерации из привычных форматов автотестов: таблиц Examples в Gherkin, @pytest.mark.parametrize в Python или блока iterations в YAML (Git-проект).
- Связь с автотестами. Импорт результатов Allure и синхронизация с кодом учитывают итерации, благодаря чему ручной и автоматический прогоны не «разъезжаются» по смыслу.
Зачем это вашей команде:
- Меньше дублирования: не нужно клонировать десятки почти одинаковых кейсов «под каждый логин» — это снижает рутину и упрощает поддержку актуальности.
- Прозрачное покрытие: видно, что сценарий прогнан по всем важным комбинациям данных, а не просто «для галочки».
- Корректная отчетность: статистика, дефекты и история результатов привязаны к конкретной итерации, что делает отчёты точными.
Конфигурации тест-рана: Сохраните окружение один раз — выбирайте при каждом ране
Конфигурация — это сохраненный набор параметров всего прогона: стенд, браузер, ОС, версия сборки, тип БД и т.д.. Вместо ручного ввода этих полей при каждом запуске, вы выбираете готовую конфигурацию.
Как это работает просто:
- Справочник на уровне проекта. Конфигурации живут в проекте и переиспользуются. Вы можете посмотреть, сколько прогонов на них завязано, прежде чем удалять или редактировать.
- Подстановка в кейсах. Если в шагах тест-кейса используются плейсхолдеры с именами из конфигурации, они подсвечиваются и показывают значение окружения. Тестировщик видит контекст прогона прямо в сценарии.
- Гибкая структура. Параметры могут быть сгруппированы (например, «Окружение», «База данных») для сложных стендов.
Зачем это вашей команде:
- Стандартизация прогонов: запуск «Регресса на staging, Chrome» происходит в один клик, без риска опечататься в названии стенда.
- Сравнимость результатов: раны с одинаковой конфигурацией легко сопоставлять, что помогает быстро определить окружение, на котором падал баг.
- Понятный контекст для исполнителей: в шагах видно не только «что проверять», но и «где и чем проверяли» — меньше ложных дефектов и вопросов к лиду.
- Меньше ошибок из-за «забыли указать стенд».
Почему SaveTest? Разделяя – управляй
Система предоставляет вам две мощные функции, которые работают независимо, но вместе создают полную картину:
Для QA-лида это означает меньше дублей, более прозрачное покрытие и отчетность, которую легче защищать перед менеджментом. Для тестировщика — меньше повторяющихся действий, подстановки в шагах и более понятный контекст выполнения. Для команды, где есть автотесты и Git, — одну и ту же модель параметров можно использовать и в TMS, и в репозитории, сокращая рассинхрон между ручным и автоматическим тестированием.
В итоге SaveTest работает не только как хранилище тестовой документации и трекер статусов прогонов. Он нормализует сам процесс тестирования: отдельно управляет тестовыми данными сценария и отдельно – параметрами окружения, на которых выполняется прогон. За счет этого прогоны становятся более предсказуемыми, а отчетность однозначно привязывается к конкретным сценариям и конфигурациям. По сути, функциональность убирает шум из процесса: и для QA-команды, и для стейкхолдеров, которым нужно понимать, что именно и где было проверено.
SaveTest разделяет «что» и «где» мы тестируем, превращая россыпь кейсов и прогонов в управляемую систему, по которой легко понять, какой сценарий с какими данными гоняли и на каком окружении он упал.