Что умеет SaveTest: мигратор тест-кейсов — переход с другой TMS без потери структуры

Смена TMS почти всегда выглядит одинаково: выгрузка Excel, ручная правка колонок, копипаст в новый инструмент и недели на «причёсывание» дерева. По пути теряются шаги, приоритеты, теги и иерархия папок. Команда продолжает тестировать по старым таблицам, пока новая база ещё не готова.

В SaveTest эту задачу закрывает мигратор: вы загружаете файл экспорта из Test IT, TestRail, Zephyr Scale, Qase или произвольный XLSX/CSV — и получаете наборы и кейсы уже в формате платформы. Тот же сценарий доступен и в Git-проекте прямо из IDE через расширение SaveTest для VS Code: кейсы сразу ложатся в репозиторий как YAML, Gherkin или Python.


Зачем команде отдельный мигратор
Миграция нужна не только при полном переезде. Типичные ситуации:

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

Главное отличие от «просто импортировать Excel»: мигратор понимает структуру экспорта конкретной TMS — в том числе многострочные кейсы, где один сценарий разбит на несколько строк (шаг за шагом), а ID заполнен только в первой.


Что поддерживает:
Test IT - Готовый пресет под типовую выгрузку
TestRail - Готовый пресет
Zephyr Scale - Готовый пресет
Qase - Готовый пресет
Свой формат - Ручной маппинг колонок под любой табличный файл

Форматы файла: XLSX, XLS, CSV. В ручном режиме вы сами указываете, какая колонка отвечает за название, шаги, ожидаемый результат, приоритет, теги, путь в дереве и группировку строк.


Классический проект на платформе: пошаговый сценарий
Мигратор открывается из настроек проекта.

1. Откройте классический проект.
2. Перейдите в Настройки → Синхронизация.
3. В блоке миграции нажмите «Миграция».

Откроется мастер из четырёх шагов: Источник → Файл → Сопоставление → Превью.

1) Выбор источника
На шаге «Источник» выберите пресет или Свой формат. Пресет подставляет типовое сопоставление колонок; Ручной режим оставляет поля пустыми для ручной настройки.

2) Загрузка файла
На шаге «Файл» перетащите выгрузку в область загрузки или выберите файл вручную. Если в книге несколько листов — укажите нужный.

3) Маппинг полей
На шаге «Маппинг» проверьте (или задайте) сопоставление:

• Группировка многострочных кейсов — «одна строка = один кейс» или группировка по колонке ID;
• Колонка ID и колонка расположения/пути — для сборки дерева папок и наборов;
• Разделитель пути (часто ->);
• поля платформы: название, предусловия, шаги, ожидаемый результат, постусловия, приоритет, теги, длительность, итерации;
• при необходимости — разбиение ячейки шагов по переносам строк;
• целевая директория в проекте (по умолчанию — корень).

Для пресетов чаще достаточно беглого просмотра. Для Custom — обязательно сопоставьте хотя бы колонку названия.

4) Превью и импорт
На шаге «Превью» система показывает, сколько наборов и кейсов найдено, а также список с названием, числом шагов и приоритетом. Если что-то выглядит неверно — вернитесь к маппингу или исправьте файл и загрузите его снова.
Подтвердите импорт. После завершения кейсы появятся в реестре проекта в выбранной директории — со структурой пути из исходной выгрузки.


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

Как запустить

1. Откройте папку Git-проекта SaveTest в VS Code (структура с tests/test-case/ уже должна быть инициализирована);
2. Скопируйте исходный файл в проект;
3. Нажмите ПКМ по табличному файлу в иерархии → подменю «Миграция из другой TMS» и сразу выберите источник: Test IT, TestRail, Zephyr Scale, Qase или Custom.

Пресет: быстрый путь
Для готовых систем:

1. Выберите формат сохранения: YAML, Gherkin или Python.
2. Дождитесь разбора файла — расширение создаст наборы в tests/test-case/, сохранив иерархию пути из колонки расположения.
3. Дерево тест-кейсов в сайдбаре обновится автоматически.

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


Ручная настройка в IDE
Если формат выгрузки нестандартный, выберите Custom. Откроется панель «SaveTest: Маппинг миграции» — по смыслу тот же шаг сопоставления, что на платформе:

• Группировка строк;
• колонки ID и пути;
• сопоставление полей;
• превью наборов и кейсов;
• выбор формата сохранения и импорт в tests/test-case/.

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


Практика: как мигрировать без сюрпризов

• Сделайте пробный прогон на небольшом файле — 20–50 кейсов, чтобы проверить дерево и шаги до полной выгрузки.
• Сверьте группировку. Если в исходной TMS шаги идут отдельными строками — нужен режим группировки по ID, иначе каждый шаг станет отдельным кейсом.
• Проверьте разделитель пути (-> или другой) — от него зависит, как соберутся папки и наборы.

1. В Custom сопоставьте минимум: название + шаги + ожидаемый результат; остальное — по необходимости.
2. В Git-проекте сразу выберите целевой формат команды (YAML для визуального редактора, Gherkin/Python — если так принято в репозитории).
3. После импорта пройдитесь по критичным сценариям: общие блоки, приоритеты, теги, ссылки на исходный ID — и только потом запускайте массовые правки.

Итог: мигратор SaveTest убирает ручной этап «переписать библиотеку с нуля». На платформе вы переносите кейсы в классический проект через мастер с превью; в IDE — сразу получаете файлы в Git-проекте в нужном формате. Один подход к выгрузкам Test IT, TestRail, Zephyr, Qase и Свой формат — два удобных входа под то, как ваша команда уже привыкла работать с тест-кейсами.