Блог

Версионирование тест-кейсов: история и откат | ТестОпс

2026-08-07 16:00

Обновление сценариев и сохранение достоверной истории проверок тест-кейса

Версионирование фиксирует состояния тела ручного тест-кейса, журнал изменений — операции над карточкой, а история результатов — обстоятельства и итог выполнения.
В автоматизированных сценариях трассируемость обычно строится вокруг состояния репозитория и версии сборки: тестовую логику можно связать с commit hash, тегом или веткой релиза, а конкретный запуск — с commit hash, build ID, номером workflow, артефактом сборки или метаданными CI. Однако commit не всегда полностью описывает проверяемую логику: для воспроизводимости могут потребоваться версии тестового набора, зависимостей и конфигурации, lock-файл, Docker-образ, тестовые данные, браузер, операционная система и версия тестируемого сервиса.
Ручной кейс и автотест могут храниться в разных системах, развиваться независимо и иметь разные жизненные циклы; при этом автотест может покрывать только часть ручного сценария или проверять другой уровень системы. Поэтому для трассируемости важен не обязательно единый идентификатор, а устойчивая и однозначная связь между требованием, ручным кейсом, автотестом, сборкой и результатом — например, через requirement ID, test case ID, annotation, метаданные CI, импорт результатов или другой согласованный процесс.

Тест прошёл, а сценарии поменялись

Перед релизом тестировщик проверяет восстановление пароля. На следующий день сценарий обновляют под новую авторизацию, а через неделю QA-лиду требуется установить, что именно проверялось перед выпуском. Если результат содержит снимок сценария, шаги, фактические результаты и ссылку на сборку, необходимый контекст уже сохранён. Если зафиксирован только статус запуска, его связь с конкретной редакцией тест-кейса может оставаться недоказанной.
Для следующего прогона нужна актуальная редакция тест-кейса. Для воспроизведения выполненной проверки — сохранённый вместе с результатом снимок сценария, параметров, тестовых данных, окружения и версии продукта. История изменений решает другую задачу: объясняет происхождение сценария и помогает восстановить контекст, но без прямой связи или снимка не доказывает, какая редакция использовалась при запуске. Для аудита дополнительно требуется подтвердить неизменяемость этих данных. Поэтому сначала разделим источники, которые показывают развитие кейса, обстоятельства выполнения и достоверность доказательств.

Три сущности: версия, журнал изменений и история результатов

В ТестОпс сведения о прошлом состоянии ручного тест-кейса распределены между историей версий, журналом изменений и историей результатов. Это не универсальная модель: другие процессы могут сохранять снимок сценария вместе с результатом, напрямую связывать запуск с версией либо восстанавливать контекст автотеста по commit hash и идентификатору сборки. Если такой связи нет, три источника ТестОпс помогают сопоставить состояние кейса, внесённые правки и обстоятельства выполнения.
Пока проверяемый смысл сохраняется, команда может обновлять тест-кейс без смены его идентификатора. Новый риск или самостоятельный сценарий обычно требуют отдельного кейса. Поэтому статус Passed подтверждает результат выполнения, но без снимка или прямой привязки не указывает, какая редакция тела использовалась при запуске. Карточка объединяет текущее состояние, историю правок и результаты, однако связь между ними не всегда зафиксирована технически.
Содержимое тест-кейса, его классификация и результаты выполнения относятся к разным слоям данных. Чтобы восстановить контекст проверки, важно понимать назначение каждого из них.
Сущность ТестОпс
Что хранит или отражает
На какой вопрос отвечает
Тело ручного тест-кейса
Комбинации параметров, описание, предусловие, сценарий, ожидаемый результат и постусловие
Что команда должна проверить сейчас?
История версий
Сохранённые состояния тела ручного тест-кейса
Как выглядел сценарий и какое состояние можно восстановить?
Метаданные карточки
Название, статус воркфлоу, теги, тестовый слой, кастомные поля, участников, требования и другие атрибуты
Как классифицирован кейс и с какими объектами он связан?
Журнал изменений
Дату, время, автора и сведения об изменениях карточки; создание и восстановление версий
Кто, когда и какое действие выполнил?
Папки
Заданное командой положение кейса в иерархической структуре
Где кейс расположен в тестовой базе?
Группировка по кастомным полям
Представление кейсов по значениям полей, например Suite → Feature
К какой функциональной категории относится кейс?
AQL-запрос
Не данные, а условия отбора тест-кейсов, результатов или запусков по их полям
Какие сущности соответствуют заданным критериям?
Тест-план
Статический либо сформированный по фильтрам и AQL набор тест-кейсов
Какие проверки должны выполняться вместе?
Запуск
Набор результатов, статус запуска, время открытия и закрытия, окружение, теги, ссылки и связанные задачи
В рамках какого прогона выполнялись тесты?
Результат теста
Отдельную попытку выполнения, её статус, шаги, вложения, параметры, метаданные и окружение
Что произошло при конкретном выполнении?
История результатов
Список выполнений кейса со статусами, запусками, датами, исполнителями и параметрами
Как кейс выполнялся ранее?
В документации ТестОпс термин «AQL-разметка» не используется. AQL — язык запросов, который отбирает сущности по уже сохранённым данным. Например, запрос tag = "security" and cf["Feature"] = "Password recovery" найдёт кейсы с указанным тегом и значением кастомного поля, но не зафиксирует их состояние на момент запуска.
Под деревом тест-кейсов также могут подразумеваться разные способы организации. Папки образуют самостоятельную иерархию, а группировка по кастомным полям строит категории из значений полей. Если изменить такое значение, кейс переместится в другую категорию. Для результатов уже созданных запусков прежняя структура категорий при этом сохраняется.

Различие между слоями видно на примере изменения сценария восстановления пароля:
Состояние
Шаг
Ожидаемый результат
Метаданные и дерево группировки
Тело ручного тест-кейса
Открыть ссылку из письма
Открывается форма нового пароля
Тег auth; Feature = Password recovery; путь Authentication → Password recovery
tag = "auth" and cf["Feature"] = "Password recovery"
До изменения
Ввести одноразовый код, затем открыть["Feature"] = "Password recovery"`
Исходное тело кейса сохраняется в версии
После изменения сценария
ссылку
Код принят, открывается форма нового пароля
Метаданные и положение в дереве не изменились
Прежний запрос по-прежнему находит кейс
После изменения классификации
Ввести одноразовый код, затем открыть ссылку
Код принят, открывается форма нового пароля
Тег security; Feature = Account recovery; путь Authentication → Account recovery
Требуется запрос по новым значениям
История версий показывает развитие проверочной логики. Метаданные, папки и группировки объясняют, как кейс организован и отбирается для работы. AQL превращает эти признаки в условия поиска или динамического тест-плана. Запуск и результат описывают факт выполнения, но без снимка сценария или прямой связи не доказывают, какая версия тела использовалась.
Версия ручного тест-кейса охватывает комбинации параметров, описание, предусловие, сценарий, ожидаемый результат и постусловие. Название, статус, теги и другие атрибуты карточки за пределами тела в такую версию не входят. Поэтому восстановление версии возвращает проверочную логику, но не откатывает всю карточку к прежнему состоянию.
Журнал изменений тест-кейса доступен для ручных и автоматизированных кейсов. Записи фиксируют время, автора и сведения об изменении, а при включённом версионировании — создание и восстановление версий. Содержимое тела, правки связанных кейсов, карантина, задач из таск-трекеров и вложений в журнале не отражаются.
История результатов описывает выполнение, а не редакцию сценария. В списке видны статус, запуск, время, дата, исполнитель и параметры, но конкретная версия не указана. Для автоматизированных кейсов документация описывает журнал и историю результатов, а версионирование тела — только для ручных.

Изменения определяют новую версию ТК

При включённом версионировании изменения тела ручного тест-кейса фиксируются в истории версий с учётом правил объединения правок. Система сохраняет техническое состояние, а смысловую значимость редакции определяет команда.
Изменение шага, параметра, описания, предусловия, ожидаемого результата или постусловия затрагивает тело. Исправленная в той же секции опечатка тоже попадает в версию, хотя не обязательно становится важной контрольной точкой. Название, статус, теги и прочие метаданные за пределами тела версию не создают: их изменение относится к журналу карточки.
Содержательная правка меняет не оформление, а проверяемое поведение. Например, требование добавляет подтверждение личности перед сменой пароля:
Состояние
Шаг
Ожидаемый результат
До изменения
Открыть ссылку из письма
Открывается форма нового пароля
После изменения
Ввести одноразовый код, затем открыть ссылку
Код принят, открывается форма нового пароля
Обе редакции относятся к телу ручного кейса и формируют версии. Переименование кейса или смена тега остались бы за пределами этой истории.
Новая редакция может быть сформирована через интерфейс ТестОпс, при импорте CSV или с помощью Ассистента ТестОпс. Правки из одного источника в пределах настроенного интервала объединяются в одну версию, а изменения из разных источников сохраняются раздельно. Поэтому формула «одна правка — одна версия» неточна. Значение интервала по умолчанию — 60 секунд; в серверной версии его можно настроить.
ТестОпс формирует название версии из даты и времени, но значимые состояния можно обозначать по релизу или требованию: 'Релиз 4.12 — восстановление пароля до перехода на SSO'. Описание дополняют причиной фиксации, связанной задачей и ревьюером. Такие детали упрощают навигацию, но не создают неизменяемого аудита: название и описание редактируются без записи в журнале.

Сравнение версии сценария с конкретным выполнением

Контекст выполнения восстанавливается по хронологии, данным запуска и принятому порядку фиксации изменений.
Перед контрольным запуском команда сохраняет и проверяет тело кейса, а значимую редакцию связывает с релизом, требованием и причиной изменения. После выполнения история результатов даёт время, запуск, исполнителя и параметры. Соседние версии очерчивают период действия конкретного состояния.
V12, R-418 и V13 — условные обозначения для объяснения хронологии, а не форматы идентификаторов ТестОпс. Если запуск R-418 по времени расположен между созданием V12 и V13, V12 можно рассматривать как наиболее вероятное действовавшее состояние. Это процессный вывод, а не встроенная техническая связь результата с идентификатором версии.
Несвоевременное сохранение версий повышает неопределённость даже при формально полной истории. Надёжность реконструкции поддерживает непротиворечивая цепочка данных: идентификатор кейса, версия и время её создания, запуск, исполнитель, параметры, релиз или требование. Версионирование не дополняет старый результат задним числом, а сохраняет состояние для последующего сопоставления.
Хронологическую гипотезу можно проверить простым скриптом. Он ищет последнюю версию, созданную до запуска, но возвращает её только как кандидата:
```Python
from datetime import datetime

versions = [
    {"id": "V12", "created_at": "2026-07-10T09:15:00"},
    {"id": "V13", "created_at": "2026-07-10T11:40:00"},
]

test_run = {
    "id": "R-418",
    "started_at": "2026-07-10T10:05:00",
}


def find_probable_version(versions, run):
    run_time = datetime.fromisoformat(run["started_at"])

    previous_versions = [
        version
        for version in versions
        if not datetime.fromisoformat(version["created_at"]) > run_time
    ]

    if not previous_versions:
        return None

    candidate = max(
        previous_versions,
        key=lambda version: version["created_at"],
    )

    return {
        "run_id": run["id"],
        "probable_version": candidate["id"],
        "basis": "chronology_only",
        "verified_link": False,
    }


print(find_probable_version(versions, test_run))
```
Результат:
```Python
{
    "run_id": "R-418",
    "probable_version": "V12",
    "basis": "chronology_only",
    "verified_link": False,
}
```
Если запуск R-418 расположен между созданием V12 и V13, V12 становится наиболее вероятным действовавшим состоянием. Это процессный вывод, а не встроенная техническая связь. Несвоевременное сохранение версий повышает неопределённость даже при формально полной истории.
Надёжность реконструкции повышает непротиворечивая цепочка данных: идентификатор кейса, версия и время создания, запуск, исполнитель, параметры, релиз или требование. Версионирование не дополняет старый результат задним числом, а сохраняет состояние для последующего сопоставления.

Восстанавливать версию или создавать новый тест-кейс: всему своё время

Решение зависит от предмета проверки. При сохранении прежнего проверочного смысла подходит восстановление; самостоятельный риск или параллельный сценарий требует отдельного кейса.
Ситуация
Решение
Причина
Внесена ошибочная правка
Восстановить версию
Проверочный смысл не изменился
Продукт вернулся к прежнему поведению
Восстановить версию
Прежняя логика снова актуальна
Старый и новый варианты действуют одновременно
Создать отдельный кейс
Проверки должны существовать независимо
Появился новый риск или ожидаемый результат
Создать отдельный кейс
Изменился предмет проверки
Сценарий утратил актуальность
Изменить статус
Историю не следует подменять новой проверкой
Обе редакции относятся к телу ручного кейса и формируют версии. Переименование кейса или смена тега остались бы за пределами этой истории.
Для сценария восстановления пароля ошибочная редакция или возврат продукта к прежней логике означают продолжение той же проверки. Параллельная поддержка входа по паролю и единого входа SSO (Single Sign-On) уже образует два самостоятельных варианта. Перезапись скрыла бы различие.
При восстановлении выбранная версия становится текущей, а заменённое состояние тела кейса автоматически сохраняется в истории версий. Откат возвращает тело кейса, но не стирает последнюю редакцию. Критерий остаётся содержательным: после изменения команда проверяет тот же риск или решает другую тестовую задачу?

Ревью массовых правок и изменений

Версия помогает вернуть прежнее тело кейса, но не подтверждает качество новой редакции. Массовые изменения требуют отдельного контроля выборки, источника правок и критериев приёмки.

Массовые операции

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

Импорт CSV

Импорт затрагивает тело и метаданные, поэтому ошибка маппинга масштабируется вместе с файлом. Предпросмотр и настройка соответствия столбцовпоказывают будущую структуру до загрузки. Пробная выборка ограничивает последствия ошибки, а сверка карточек и версий помогает установить фактические изменения.
Один и тот же CSV-файл может менять разные части карточки в зависимости от маппинга:
Учебный столбец CSV
Поле ТестОпс
case_name
Название
steps
Сценарий
expected
Ожидаемый результат
labels
Теги
Названия столбцов условны. Смысл примера в границе последствий: ошибка в steps затронет версионируемое тело ручного кейса, а ошибка в labels — метаданные карточки. Предпросмотр помогает увидеть маппинг до импорта, но не подтверждает смысловую корректность данных.

AI Ассистент ТестОпс

Ассистент ТестОпс создаёт и обновляет тест-кейсы через нативные инструменты продукта. Инструменты, меняющие проект, по умолчанию требуют подтверждения. При включённом версионировании Ассистент автоматически создаёт версии при создании и обновлении ручных тест-кейсов через инструменты ТестОпс.
Подтверждение контролирует запуск изменения, а журнал и история версий позволяют проверить его результат. Они не подтверждают смысловую корректность новой редакции, поэтому содержательное ревью остаётся отдельным этапом.
До изменений фиксируются выборка, контрольная версия и критерии приёмки. В процессе редакционные правки отделяются от смысловых. После изменения новые версии сопоставляются с требованиями, а выборочные кейсы проходят проверку. Границы правки остаются понятными, но наличие сохранённой версии само по себе не означает принятия.
История имеет конечную глубину. По умолчанию ТестОпс хранит 20 версий кейса и после достижения лимита при сохранении новой версии автоматически удаляет самую старую. В серверной версии лимит и интервал объединения правок настраиваются. Важные состояния требуют осмысленных названий и своевременного контроля, а не расчёта на бессрочный архив.

Доверие к истории проверок

Логу можно верить, когда состояние сценария, момент изменения и условия выполнения образуют непротиворечивую цепочку. Текущее тело отделено от сохранённых редакций, автор и время правки установлены, а запуск, время выполнения, исполнитель и параметры подтверждают обстоятельства выполнения. Предполагаемая связь результата с версией имеет явно зафиксированное процессное основание и не выдаётся за встроенную связь ТестОпс.
Количество записей само по себе ничего не гарантирует. Достоверность появляется там, где прошлое можно восстановить без подмены текущей редакцией и без выдачи хронологического вывода за технически зафиксированную связь.