История о том, как избавить команду от боли работы с классическими TMS (Test Management System) и перенести тестовую документацию туда, где ей самое место — в код.

Дано:

• Растущее количество ручных тестов (иногда переваливающее за тысячи), которые сложно поддерживать.

• Отсутствие нормального переиспользования шагов в стандартных системах, из‑за чего приходится постоянно дублировать общие шаги.

• Рассинхронизация между автотестами и ручными кейсами, приводящ к спорам о том, какой тест считать актуальным (главным).

• Сложности с параллельной работой в ветках, ревью изменений и плохой аудит удалений, где один клик может снести целую группу тестов.

Найти:

• Единый источник правды для всех тестов на проекте.

• Механизм, обеспечивающий прозрачный процесс работы с разными ветками, ревью изменений и так далее

Начнем сначала. Что такое «классические» ТМС системы? Классические ТМС системы (Например TestRail, Test‑it, DoQa, TestOps и так далее) это системы, в которых тестировщик (один или несколько)

• Создают списки тест‑кейсов, прописывают в них проверочных шаги и ожидаемый результат, вешают на них теги, устанавливают приоритет, в идеале еще и скриншотик прикрепляют.

• Далее эти тест‑кейсы объединяются в тестовые прогоны (тест ран) для прохождения нужного этапа тестирования. Регресс, Приемка, Тестирование новой фичи (нужное подчернуть)

• Внутри тест рана мы устанавливаем результаты, чтобы можно было отслеживать текущий прогресс, ничего не забыть и отчитаться о проделанной работе

• По окончанию прохождения тест рана формируются отчеты для руководства или для истории.

  Всем тестировщикам, которые работали в командах от 2х и более человек это полностью знакомо.

Что-то как то все старо выглядит. А где автотесты? Мы в 2026 году, у каждого уважающего себя проекта должны быть автотесты, а в идеале уже и AI агент, который умеет или писать автотесты или выполнять их, или чинить. А может и все сразу

Тут начинается не очень приятная часть. Маппинг автотестов с ручными (кто делал это хотя бы 1 раз с нуля, тот понимает как неприятно это делать даже с 1к тестов). В современных ТМС системах есть инструменты для маппинга автотестов с ручными. И по наименованию и по ИД и автоматически. Но принцип все равно не меняется — автотесты лежат отдельно, ручные тесты лежат отдельно. Это порождает целый ворох проблем

• Потеря единого источника правды. Автотесты и ручные тесты могут расходится. Когда количество тестов переваливает за 1000 отслеживать актуальность шагов в ручном тесте нереально (да и незачем). По моему мнению автоматизированный ручной тест вообще должен уйти из репозитория. Зачем он?

• Ад при работе с ветками. Если у нас есть 3 стенда (dev, stage, predProd), мы прогоняем автоматическое и ручное тестирование на predProd, а тест‑кейсы/код автотестов кто то уже переписал под dev стенд

• ... Я думаю тут можно дописать еще сколько то проблем, но статья не об этом)

Вернемся немного назад. Мы перечислили основные этапы работы с ручными тест‑кейсами. Может что-то забыли? Да. Забыли важный и самый противный этап — Поддержка тест‑кейсов

Самое неприятное это поддерживать тест‑кейсы в актуальном состоянии. Особенно если их много, особенно если мы писали их подробно, особенно если мы не писали их подробно)))
Изменение базовой функциональности требует обновления десятков, а то и сотен тестов. И вот тут классические ТМС с их веб‑интерфейсами раскрывают свою неприятную сторону.

• Массовые изменения — Боль и тыкание мышкой

• Отсутствие нормальных «общих шагов» — безусловно в той или иной мере они есть во всех ТМСках. Но почему то их так мало используют...

• Снова потеря единого источника правды между ручными и автотестами

• Неготовность к AI (А мы ведь в 2026-м!) — Это конечно немного я преувеличиваю. Формально Test it и DoQa имеют интеграцию с AI для генерации тестов. Но я немного не про то. Получается чтобы сгенерировать тесты через AI агента нужно использовать API системы и обращаться к нему для передачи тест‑кейсов, при этом AI будет перезапрашивать тест‑кейсы из API для того чтобы поддерживать контекст. Не совсем то, что хочется. Хочется чтобы тест‑кейсы генерировались на машине — чтобы агенту было проще читать контекст файлов и ориентироваться в ситуации

• .. Снова поставлю многоточие. Т.к. боли у каждого свои

А что если уже все придумано за нас? Тестировщики часть ИТ мира, давайте использовать достижения других специальностей) Я говорю про Everything as Code

Разработчики додумались до этого первыми, потому что код продукта, который перекидывали зипниками по почте, расинхронизировался. Так появилась система контроля версий. Потом туда мигрировала сборка (Jenkins, GitLab CI). Потом установка продукта (Ansible). Потом документация — сейчас во многих проектах документация лежит в репозитории рядом с кодом.

И при этом — важный момент — никто не потерял UI. Откройте GitLab: те же кнопочки, те же переменные, всё то же самое. Просто конфигурация уехала в код. UI остался.

Очень надеюсь, тест‑кейсы повторят этот путь. Мы сформулировали несколько требований к формату кейсов: человекочитаемый, стандартизированный, чтобы AI мог работать с ним напрямую без API‑вызовов. Хранить ручные тест‑кейсы нужно точно так же как храним код автотестов — в репозитории git. А самое вкусное — в том же самом репозитории что и код автотестов.

В каком формате? Для начала мы начали использовать yaml (потом добавили python и gherkin). Почему yaml, потому что это с одной стороны человекочитаемый формат, а с другой стороны четко стандартизированный.

Уже выглядит супер, мы смогли открыть наши кейсы в VS Code! Что это нам дает? Это значительно облегчает нам задачу по поддержке актуальности этих тестов, так как в IDE многими годами были отшлифованы функции массового редактирования, быстрое переключение git веток, а также в IDE живут AI ассисенты, которые могут помогать нам в разработке тест‑кейсов или делать это полностью автономно. Так же если код автотестов живет в этом же репозитории, то автотестировщик реализует автотест и удалит ручной (избегаем дублирования)

Чуть не забыл про общие кейсы. Общие кейсы ведутся просто в отдельной директории в том же yaml формате. В основных тест‑кейсах можно вставлять ссылку на него, тем самым переиспользуя общие шаги

Но что-то не давало нам покоя и мы решили добавить визуальный плагин для тех тестировщиков, которые не готовы вручную редактировать yaml файл

Прямо внутри IDE мы реализовал плагин, который вернул тестировщикам привычные кнопки и списки. Т.о. мы и в yaml перешли и тестировщиков не сильно напугали. Единственное осталось научить их пользоваться GIT (хотя бы на базовом уровне). Разумеется это не все функции плагина — Плагин валидирует тест‑кейсы на предмет структуры, позволяет раставлять uuid по ПКМ в любом файле и так далее (подробнее в savetest‑tms‑plugin)

Когда мы подумали об этом нашли еще один из неочевидных плюсов — У каждого локально есть полная копия базы тест‑кейсов, получается какой никакой бекап. Никто теперь не удалит всю базу бесследно, всегда можно откатиться в GIT по истории.

Супер. У нас теперь есть тесты в Git, мы можем работать как взрослые разработчики. Можем проводить ревью тест‑кейсов в гитлабе (оставлять комментарии на исправление), можем делать работу с разными ветками, может выполнять массовые изменения и подключать AI агентов. Круто — но помним, что тесты нужно объединять в тест‑раны и запускать, формировать отчеты, прикреплять куда то результаты автотестов. Для этого есть 2 пути

• или использовать существующие ТМС системы и прослойку между гитлабом и этой системой

• или реализовать свою ТМСку, которая из коробки умеет синхронизировать данные из Git

Вне зависимости от пути общая схема выглядит так:

• Создаем/Редактируем тест‑кейсы в IDE

• пушим изменения в Git хранилище, проводим ревью и др

• Синхронизация в платформу

• Выполнение тестов

• Отчетность

Мы пошли по второму пути. Реализовали платформу SaveTest. Система умеет синхронизировать данные из gitlab, github и др git совместимых хранилищ. Про функционал системы можно почитать на сайте. По сути там есть все для современных ТМС систем (тест‑раны, отчеты, фильтры, классические проекты для староверов и загрузка allure отчетов для результатов автотестов)

Что в итоге. Тест‑кейсы — такой же артефакт разработки, как код и документация или автотесты. Они точно так же меняются, точно так же требуют ревью, точно так же должны жить рядом с тем, что описывают. Код продукта давно переехал в Git. Сборки переехали. Инфраструктура переехала. Документация переезжает. Тест-кейсы тоже должны ехать.

ТМС системам нужно оставить то, что у них получается лучше всего — Установка результатов + отчеты

P.S. Вдохновлено выступлением Артёма Ярошенко (Heisenbug) 2021г (ссылка на видео)