Regression strategy определяет, как команда проверяет, что изменение не нарушило нужное существующее поведение. Это набор решений о рисках, уровнях проверок, частоте запусков и поддержке тестов. Большой список кейсов сам по себе стратегией не становится: важно понимать, какую ошибку он способен обнаружить и когда результат будет полезен.
Хорошая регрессия меняется вместе с продуктом. В неё входят критические сценарии, взаимодействия компонентов и дефекты, для которых повторное появление действительно опасно. Часть проверок выполняется автоматически, часть требует исследовательской работы и осмысленного наблюдения человека. Их сочетание зависит от риска и устройства системы.
Что защищает регрессия
Начните с пользовательских и бизнес-обязательств: вход, создание заказа, доступ к своим данным, корректная сумма, получение результата. Для каждого обязательства найдите возможные точки нарушения: правило расчёта, API-контракт, сохранение данных, интерфейс и внешняя зависимость.
Такое описание полезнее перечня экранов. Экран оплаты может открываться, но итоговая сумма уже неверна. Стратегия должна включать проверку важных инвариантов и передачи данных между шагами. Сохранённый ранее баг — источник риска, но не единственный способ выбрать полезный тест.
Анализ влияния изменения
Для каждого изменения определите затронутую логику, соседние сценарии, общие компоненты и данные. Замена библиотеки авторизации требует шире смотреть на сессии, чем изменение текста одной подписи. При неизвестной зависимости область проверки расширяют осознанно, фиксируя причину.
Обсудите влияние с разработчиком и сверяйте с архитектурой. Одно мнение автора изменения не исключает скрытую связь. История инцидентов и контрактов помогает проверить предположение: например, общий formatter суммы влияет на корзину, письмо и экспорт, хотя задача упоминает только один экран.
Распределение по уровням
Чистое правило скидки выгодно подробно проверять на уровне unit-тестов. Контракт между сервисами — через контрактные или интеграционные проверки. Несколько ключевых пользовательских цепочек проходят end-to-end, чтобы увидеть реальную связность компонентов и состояние интерфейса.
Не переносите всю комбинационную проверку в UI: это увеличивает длительность и число случайных отказов. Но и успешные unit-тесты не подтверждают правильность конфигурации маршрута и записи заказа. Для каждого риска выбирайте самый подходящий уровень, сохраняя необходимую проверку целого сценария.
Наборы и частота
Быстрый набор даёт ранний сигнал при изменениях. Более широкий набор выполняют по событиям и расписанию, соответствующим скорости доставки. Перед выпуском добавляют проверки конкретного кандидата, миграций и конфигурации. Эти наборы могут пересекаться, но имеют разные цели.
Запишите владельца и максимальное полезное время обратной связи. Если результат приходит после следующего выпуска, раннюю защиту он не обеспечивает. Длительные проверки можно разделять и запускать параллельно, но при этом нужно сохранить независимость данных и не создавать конфликт за одну учётную запись.
Практический пример: промокоды
Магазин меняет совместимость промокода с персональной скидкой. Выделите правила, интерфейс выбора, API заказа, возврат и документ. Подготовьте ожидаемые суммы для нескольких комбинаций независимо от реализации, чтобы не повторить ошибочную формулу приложения в эталоне.
- 1.На unit-уровне проверьте допустимые комбинации, границы суммы, округление и порядок применения. Ожидаются согласованные математические результаты.
- 2.На API-уровне создайте заказ и прочитайте его обратно. Ожидается сохранение той же суммы и оснований скидки.
- 3.Через UI пройдите одну критическую цепочку с промокодом и одну без него. Ожидается совпадение корзины, подтверждения и документа.
- 4.Выполните возврат подходящего тестового заказа. Ожидается возврат именно оплаченной суммы по правилам продукта, без повторного применения скидки.
После изменения общих денежных функций добавьте связанные операции по анализу влияния. Проверка только формы ввода промокода оставит важный финансовый риск без покрытия.
Как выбирать ручные проверки
Ручная работа полезна для новых взаимодействий, неоднозначных требований, визуальных состояний и исследовательского поиска. Задавайте её как цель с данными и наблюдениями: «изменить способ доставки после промокода и проверить пересчёт», а не «пощёлкать корзину».
Результаты исследования возвращайте в стратегию. Если найден дорогой повторяемый риск, добавьте подходящую автоматическую проверку. Если сценарий требует человеческой оценки текста или взаимодействия, сохраните понятную исследовательскую подсказку и критерии, не превращая её в механический список десятков кликов.
Нестабильные тесты
Flaky-тест иногда проходит и иногда падает при сопоставимых условиях. Это может быть ошибка теста, данных, окружения или настоящая нестабильность продукта. Повторный запуск помогает собрать сигнал, но не объясняет причину и не делает исходное падение несуществующим.
Задайте процесс разбора, владельца и срок временного исключения. Карантин без срока постепенно убирает защиту из важных областей. Сохраняйте следы первой ошибки, результаты повторов и долю нестабильности. Проверка, которая проходит только после нескольких попыток, не должна выглядеть полностью надёжной в отчёте.
Данные и поддержка набора
У тестов должны быть явные предусловия и независимые данные. Общий изменяемый заказ вызывает конфликты параллельных запусков и неочевидную зависимость от порядка. Подготовка и очистка входят в стоимость проверки, даже если сами assertions занимают несколько строк.
Регулярно удаляйте дубли, обновляйте ожидания после согласованных изменений и проверяйте актуальность риска. Но не переписывайте эталон только ради зелёного результата: сначала подтвердите новое правило. Иначе регрессия начинает закреплять текущее поведение, включая дефект, вместо защиты требований.
Метрики и критерий полезности
Количество кейсов и процент автоматизации плохо показывают защищённость сами по себе. Полезнее смотреть время обратной связи, стабильность, дефекты, найденные до выпуска, пропущенные риски и стоимость поддержки. У каждой метрики есть контекст: уменьшение числа дефектов может означать и улучшение, и слабый поиск.
Хорошая стратегия объясняет, какие обязательства защищены, какими проверками и с какой частотой. После инцидента её корректируют по причине пропуска, а не просто добавляют ещё один длинный UI-тест. Цель — получать своевременные и достоверные сведения о риске каждого изменения.