Сценарии, которые защищают правило

Регрессионный сценарий — это повторная проверка поведения, которое уже однажды было важно: после изменения мы убеждаемся, что нужное правило сохраняется. Сценарий полезен не потому, что в нём много шагов, а потому, что заранее видны входные данные, действие и результат. Разберём учебную «Заявку на выплату» из серии аналитика. Это синтетическая модель, не описание реальной конфигурации.

У неё заданы три правила: для операции «Оплата услуг» назначение платежа обязательно; для «Возврата средств» оно не обязательно; до 100000 рублей нужен один согласующий, начиная с 100000 — два. Приёмка должна охватить обычный путь, границу правила и соседнее поведение, которое может случайно измениться.

Матрица превращает правило в проверяемые случаи

Правило	Вход и действие	Ожидаемое поведение для согласования
Назначение обязательно для оплаты услуг	Создать такую заявку без назначения; попытаться сохранить или продолжить	Система сообщает о пропуске в согласованной точке процесса и не принимает заявку дальше
Назначение не обязательно для возврата	Создать возврат без назначения	Отсутствие назначения само по себе не блокирует согласованное действие
Меняется состав согласующих	Сумма 99999, затем 100000, затем 100001	До порога один согласующий, от порога два
Значение сохраняется	Заполнить назначение, сохранить, открыть заявку повторно	После повторного открытия значение совпадает с сохранённым

Таблица — проект матрицы, а не свидетельство о фактическом поведении приложения. Владелец процесса должен подтвердить точку проверки: ввод, сохранение, проведение или отправка. Не переносите слово «сохранить» в критерий, если по правилам операции проверка выполняется позже.

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

Не смешивайте отображение с сохранённым состоянием

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

Сформулируйте критерии предметно: «При сумме 100000 рублей после выбора оплаты услуг система формирует маршрут с двумя согласующими». Затем выясните с владельцем и исследованием формы, где этот результат доступен наблюдателю. Не обещайте проверку внутреннего состояния, если у аналитика нет доступа к нему.

Для негативного случая тоже нужен критерий: что увидит пользователь, сможет ли исправить данные и останется ли заявка в допустимом состоянии. «Ошибка возникла» — недостаточно: зафиксируйте текст или смысл сообщения и то, какой шаг не должен быть выполнен. Не придумывайте название сообщения до знакомства с приложением.

Условия и данные фиксируются рядом

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

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

Свяжите сценарий с правилом устойчивым идентификатором, например PAY-APPROVAL-THRESHOLD; такой идентификатор здесь иллюстративный, его следует заменить принятой в команде схемой. В записях результата укажите требование, сценарий, базу, пользователя/роль теста, версию конфигурации и дату прогона.

Статика помогает найти место проверки, но не заменяет запуск

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

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

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

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