Иван Кузин о SaveTest: «Мы не хотели делать еще одну TMS с красивыми кнопками»

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

SaveTest появился именно из этого раздражения. Идея была не в том, чтобы сделать еще одну панель управления качеством. Хотелось вернуть тест-менеджмент туда, где реально живет разработка. Мы поговорили с Иваном Кузиным (создатель SaveTest) о том, почему команде SaveLink понадобился собственный продукт и почему тест-кейсы все чаще должны вести себя как инженерный артефакт.

Иван, с чего началась идея SaveTest?
С накопленного дискомфорта. Команда строит современный процесс: Git, CI/CD, код-ревью, автотесты, релизные пайплайны. А тестовая документация живет в отдельной TMS, которая по логике ближе к CRM, чем к инженерному инструменту.

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

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

Что в существующих решениях особенно раздражало?
Самый главный недостаток не в интерфейсе. Интерфейсы у многих решений вполне приличные. Проблема в модели процесса. Классическая TMS часто исходит из того, что тестирование это отдельный производственный участок. Там есть свои сущности, статусы, отчеты. Но современная разработка так уже не работает. QA встроен в поток изменений, а не стоит в конце конвейера с печатью «годно».

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

Третий момент — разрыв между ручным и автоматизированным тестированием. У команды есть ручные сценарии, автотесты, результаты прогонов, дефекты, требования, Allure-отчеты, CI. Но в TMS все это часто склеивается интеграциями, которые напоминают мосты через болото. Формально связь есть, а управлять качеством как единой системой трудно.

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

Подход «тест-кейсы как код» хорош не потому, что все тестировщики должны срочно стать разработчиками. Смысл в другом: тестовая модель должна наследовать лучшие практики инженерной разработки. История изменений, ветвление, pull request, ревью, прозрачная связь с релизом, возможность хранить тесты рядом с кодом продукта или рядом с автотестами.

В SaveTest тест-кейсы можно описывать в YAML, хранить в Git и синхронизировать с платформой. Для технических QA это естественный сценарий. Для команд, которым удобнее классический веб-интерфейс, он тоже остается. Мы не противопоставляем кодовый и визуальный режимы. Задача продукта — дать команде общий контур, где ручные проверки, автотесты и документация не расходятся по разным мирам.

Какие гипотезы при разработке оказались неверными?
Одна из первых гипотез была такой: если мы дадим технически правильную модель, команда сама быстро перестроит процесс. На практике все сложнее. TMS это не просто инструмент. Это часть привычек: как пишут кейсы, кто их ревьюит, как собирают регрессию, кто отвечает за актуальность, какие отчеты ждет менеджмент.

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

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

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

ИИ может анализировать изменения, подсказывать зоны риска, находить дубли, генерировать черновики проверок. Но ответственность за модель качества останется у команды.

Если бы вы могли изменить одну вещь в современном тестировании?
Я бы убрал отношение к тестовой документации как к неизбежной бюрократии. Плохая документация превращается в кладбище кейсов. Но хорошая тестовая модель это не бумажка для отчета, а инженерная карта продукта. Она помогает быстрее вводить людей в проект, безопаснее менять функциональность, осознанно строить автоматизацию и говорить с бизнесом на языке рисков.

Тестировщик не должен быть хранителем табличек. Он должен быть инженером качества, который понимает продукт, архитектуру, пользовательские сценарии и стоимость ошибки. SaveTest мы делаем именно под эту роль.