Регрессия в Scrum — это управление риском, а не прогон перед релизом.

Пять идей из статьи:

1. анализ влияния делается до разработки, а не после;

2. набор проверок собирается по риску (P0-P3), а не по привычке;

3. регрессия живёт в CI всю итерацию, а не в последние два дня спринта;

4. flaky tests и тестовые данные — технический долг, который подрывает доверие к пайплайну;

5. решение о релизе принимается по картине остаточных рисков, а не по проценту passed tests.

Привет, Хабр! На связи Евгений Гусинец — QA Engineer из Бизнес‑Инфо (Минск), автор ТГ канала о тестировании и IT‑технологиях QA❤️4Life

Наверняка многие их вас уже успели познакомиться и добавить себе в закладки мои предыдущие публикации: Большую подборку тестовых площадок («песочниц») и ресурсов для начинающих и опытных QA а также SQL для всех: от новичка до профи. Полный гид по тренажерам, курсам и песочницам и Автоматизация рутины в Postman (часть1) и (часть 2)

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

Содержание

• Почему об этом стоит говорить

• Что такое регрессионное тестирование

• Почему Scrum усиливает проблему

• Пять типичных проблем регрессии в Scrum

• Регрессия начинается до разработки: анализ влияния

• Приоритизация: выбирать по риску, а не по привычке

• Политика регрессии: что и когда запускать

• Регрессия после релиза: shift‑right

• Тестовая пирамида и контрактные проверки

• Нефункциональная регрессия

• Тестовые данные как часть стратегии

• Exploratory testing: то, что автоматизация не видит

• Автоматизация: что стоит, а что не стоит автоматизировать

• Как справляться с flaky tests

• Критерии входа и выхода

• QA не «разрешает релиз»

• Метрики регрессии

• Сквозной пример: изменение порядка скидок

• Как встроить регрессию в события Scrum

• Практический план из семи шагов

• Когда это не работает

• Частые ошибки

• Что в итоге

Почему об этом стоит говорить

По данным опроса Digital.ai (The State of Agile Report, 2021), подавляющее большинство респондентов — около 9 из 10 — заявляют об использовании Agile‑практик, хотя Scrum лишь одна из методологий, а гибридные подходы не менее распространены [10]. Тестируют в каждом спринте, а требования меняются на ходу из‑за плотной связи с заказчиком. Регрессия — одна из самых частых проверок перед релизом, и именно ей достаётся меньше всего времени, когда спринт двухнедельный, а фичи дорабатывают до последнего дня.

В Scrum регрессия легко становится ритуалом. Разработчики закрывают задачи. QA (обеспечение качества) проверяет новые истории отдельно от остального продукта. За день‑два до релиза запускают «полный регресс». Часть тестов не успевает пройти. В пайплайне копятся падения, которым уже никто не верит. Решение о релизе принимают на глаз.

Регрессия работает, когда команда выбирает проверки под конкретное изменение, распределяет их по уровням тестовой пирамиды и получает быстрый сигнал через CI/CD (непрерывную интеграцию и поставку).

Что такое регрессионное тестирование

ISTQB Foundation v4.0 определяет regression testing (регрессионное тестирование) как повторную проверку уже протестированного продукта после изменения. Цель — найти дефекты, которые появились из‑за самого изменения или всплыли в неизменённых местах как побочный эффект [1]. Последствия могут проявиться в том же модуле, в другом компоненте или в соседней системе. Регрессия не держится внутри объекта тестирования: она затрагивает окружение. Причиной может быть не только новая фича, но и фикс бага (исправление дефекта), рефакторинг, обновление библиотеки, смена конфигурации, инфраструктуры, базы данных или внешней интеграции [1].

Куликов в «Базовом курсе» приводит оценку Фредерика Брукса из «Мифического человеко‑месяца»: исправление одной ошибки с вероятностью 20–50% рождает новую [6]. Без регрессии качество почти любого проекта держится на удаче.

Там же он разделяет понятия, которые часто путают. Confirmation testing (подтверждающее тестирование), оно же re‑testing (повторное тестирование) — это прогон тех тест‑кейсов, которые нашли дефект, чтобы убедиться, что его закрыли. Это финальный шаг в жизненном цикле дефекта: перевод в статус «проверен» и «закрыт». Регрессия отвечает на другой вопрос: не сломало ли изменение что‑то рядом [6].

В терминологии ISTQB confirmation testing и re‑testing — синонимы: повторный прогон тестов, обнаруживших дефект, для подтверждения исправления [2]. Куликов использует confirmation testing как основной термин. Противопоставление confirmation testing и regression testing при этом остаётся корректным.

Confirmation testing отвечает на вопрос «исправили именно этот дефект?». Регрессия — на вопрос «что ещё могло сломаться?» [1]. Confirmation testing можно проводить по‑разному: от полного повтора всех упавших сценариев до нескольких новых тестов на исправление. При нехватке времени иногда достаточно шагов воспроизведения сбоя. Сокращённый confirmation допустим только при дефиците времени и для низкорисковых дефектов. Для критичных сценариев нужен полный повтор, иначе подтверждение исправления становится формальностью. Регрессия всегда смотрит шире одного дефекта.

Почему Scrum усиливает проблему

В Scrum команда постоянно выпускает инкременты. Каждая история, фикс, изменение API (программного интерфейса), миграция БД или конфигурации добавляет риск побочного эффекта. Если регрессию держат отдельной фазой «перед релизом», к концу спринта накапливается слишком много изменений при слишком малом остатке времени.

Тестирование и регрессионная защита каждой истории строятся в течение спринта, а не в его конце. За качество в Agile отвечает вся команда, а не один QA в последний день [1].

В Scrum Guide нет ни роли тестировщика, ни фазы тестирования. Это частая точка спора на Habr (“Scrum убил тестирование”). Scrum не запрещает тестирование. Он переносит ответственность за него в команду и в Definition of Done (критерии готовности). Регрессия в Scrum — не событие, а свойство процесса. В гибких командах регрессионный прогон идёт параллельно всей итерации: CI на каждый merge (слияние) повторно выполняет автоматические модульные тесты и проверки функционала текущей и предыдущих итераций [4],[5].

Пример для двухнедельного спринта: дни 1–10 — регрессия живёт в CI на каждый merge (unit — модульные, component — компонентные и API‑тесты); дни 11–14 — финальный risk‑based (основанный на рисках) прогон и exploratory‑сессии (сессии исследовательского тестирования) перед релизом.

На Scrum‑проектах внимание смещается на новую функциональность. Уверенность, что она не ломает старое, даёт не сам факт прогона, а правильно подобранный объём проверок.

Пять типичных проблем регрессии в Scrum

Две рабочие задачи стоят за большинством этих проблем: понять, что затронуло изменение, и решить, что автоматизировать.

1. Объём растёт быстрее, чем успевает команда. Гаятри Мохан в «Фулстек тестировании» приводит расчёт: 20 тестов по 2 минуты на функцию при 15 функциях — это 600 минут прогона. Если поддерживать две версии сервиса, уже 1200. И это без перепроверки после фиксов. Цифры описывают суммарное время выполнения. При параллельном прогоне (sharding — разбиение на несколько заданий) календарное время меньше, но стоимость вычислительных ресурсов и поддержки никуда не девается. Если отказаться от регрессии на раннем этапе, ошибки интеграции всплывают только на релизном тестировании — слишком поздно и уже под угрозой сроков [9]. Продукт растёт с каждой итерацией, объём тестирования растёт вместе с ним, а длина спринта не меняется. Реальный выход — автоматизация [4].

2. Разработка и QA не договариваются. По Тюлькину командам нужно согласовать три вещи: покрытие критичных функций, снижение рисков регрессий и актуальность тестовых данных. Без этого регрессия становится формальным прогоном «для галочки» [8]. Метрики нельзя использовать для наказания или изоляции конкретных людей: за качество отвечает вся команда [4].

3. Тесты устаревают, если их не поддерживать. Без регулярного пересмотра, обновления и удаления регрессионные тесты либо ложно падают, либо пропускают реальные дефекты. Разбор таких срабатываний съедает время [4]. Тест, написанный на ранней итерации, часто теряет смысл на поздней: функциональность меняется, появляются новые зависимости. Такой тест нужно обновить или удалить.

4. Доработки в конце спринта сокращают регрессию. Если полный прогон невозможен, план тестирования должен прямо объяснить почему и какие риски это несёт. Игнорирование регрессии часто оборачивается более дорогим дотестированием позже [2]. Если объём регрессии сознательно урезают, это решение фиксируют вместе с рисками.

5. Ложные срабатывания подрывают доверие к прогонам. Марк Винтерингем в «Тестировании веб‑API» пишет: автоматизация требует серьёзных вложений. Если она ненадёжна, она тормозит команду и вводит в заблуждение насчёт реального качества продукта [7]. Он разделяет два понятия. Машина даёт фидбек (обратную связь) по заданным шагам — это checking (проверка). Человек с эвристикой и опытом занимается testing (тестированием). Ставка только на автоматизацию теряет часть обратной связи [7].

Майкл Болтон на вебинаре «Things Could Get Worse» формулирует жёстче: регрессия не измеряет качество напрямую. Качество определяют пользователи. Зелёный или красный прогон — это интерпретация результата. Автоматические проверки он называет детекторами изменений, а не судьями качества [7]. Регрессия — необходимый, но недостаточный сигнал. Она не говорит, насколько продукт хорош. Она говорит, что мы не сломали то, что работало.

Причины ложных срабатываний шире «кривого теста»: нестабильное окружение, устаревшие данные, изменения в смежных системах, race conditions (состояния гонки) внутри самих тестов [4].

Регрессия начинается до разработки: анализ влияния

Качество регрессии определяет не количество тестов, а качество impact analysis (анализа влияния): понимания, какие компоненты, данные, интерфейсы и пользовательские пути затронет изменение. Анализ влияния показывает, какие части системы могут затронуть изменения [1]. Его можно проводить ещё до внесения изменения — чтобы решить, стоит ли его вносить вообще [1]. ISTQB Advanced Level требует impact analysis для любой значимой модификации. Если команда его не делает сама, тест‑менеджер должен запустить этот процесс [2].

QA стоит подключаться уже на refinement (уточнении бэклога). Не затем, чтобы заранее написать тест‑кейсы, а чтобы превратить неопределённость в договорённости: что меняется, где используется, какие риски важнее и что нужно добавить в Definition of Done.

Перед началом разработки полезно пройтись по чек‑листу:

• Какие роли, права и бизнес‑сценарии меняются?

• Какие API‑контракты затронуты: endpoint (конечная точка), обязательность параметров, коды ошибок, формат ответа, идемпотентность?

• Какие сервисы, очереди, фоновые процессы, webhooks (веб‑хуки) или cron‑задачи (задачи по расписанию) участвуют в обработке?

• Меняется ли схема БД: таблицы, индексы, constraints (ограничения целостности), миграции, backfill данных (обратное заполнение)?

• Затрагивает ли изменение кеш, feature flag (флаг функции), конфигурацию, секреты или лимиты?

• Какие web‑, mobile‑ и внешние клиенты используют изменяемый контракт?

• Какие бизнес‑потоки зависят от компонента: регистрация, оплата, оформление заказа, возврат, экспорт, биллинг?

• Что происходит при timeout (тайм‑ауте), повторной доставке события, сбое внешнего сервиса или rollback (откате)?

• Какие нефункциональные характеристики могут ухудшиться: производительность, безопасность, доступность, usability (удобство использования), accessibility (доступность интерфейса)?

На практике это не многостраничная форма. Разработчик отмечает изменённые модули. QA смотрит связанные компоненты по архитектуре и зависимостям. Регрессионный набор собирается из тестов на затронутые области плюс smoke‑тесты (дымовые тесты) на всю систему.

Ручной чек‑лист можно частично автоматизировать. Test Impact Analysis, TIA (анализ влияния изменения на тесты) — инструменты вроде pytest‑testmon, SeaLights или встроенные механизмы в CI — анализирует граф зависимостей и покрытие кода. Разработчик меняет pricing_service.py. TIA определяет, какие тесты выполняли эти строки в прошлых прогонах. Вместо 5000 тестов CI запускает только 140, прямо или косвенно зависящих от изменения. PR‑прогон (прогон на запросе на слияние) сокращается с 40 минут до трёх. TIA не заменяет инженерное суждение. Он снимает механическую часть. Решение «что ещё могло сломаться» остаётся за командой.

Приоритизация: выбирать по риску, а не по привычке

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

Risk exposure = Probability x Impact

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

Это модель мышления, а не калькулятор. Оба множителя на практике — экспертные оценки. Сочетание «высокая вероятность, критическое влияние» важнее выдуманной точности вроде 0,7 и 8,3. Оценки стоит калибровать на ретроспективах. Если дефект ушёл в прод (промышленную среду) в области, которую команда оценила как низкорисковую, шкалу нужно пересмотреть.

P0 должен укладываться в бюджет, который команда реально готова ждать, обычно 5–15 минут. Иначе гейт (шлюз проверки) становится формальностью: если «критичный» набор идёт 40 минут, разработчики начнут его пропускать.

Нужно различать выбор объёма и порядок запуска. Полный прогон, retest‑all (повтор всех тестов) — редко, перед релизом. Выборочный по анализу влияния, regression test selection (выбор регрессионных тестов) — на каждое изменение. Минимальный smoke — на каждый merge. Приоритизация отвечает на вопрос «в каком порядке». Выбор объёма — на вопрос «что вообще запускать».

ISTQB Advanced Level описывает три стратегии приоритизации [2].

• Risk‑based (на основе рисков): порядок задаёт анализ рисков. Для Scrum это самый практичный вариант, потому что бизнес‑приоритеты обычно уже известны.

• Coverage‑based (на основе покрытия): сначала идут тесты с максимальным покрытием. Есть вариант additional coverage prioritization (приоритизация по дополнительному покрытию): каждый следующий тест выбирают ради максимума нового покрытия сверх уже выполненного.

• Requirements‑based (на основе требований): приоритет наследуется от приоритета требований. Хорошо работает при чётко ранжированном бэклоге.

На практике эти три подхода живут вместе. Риск задаёт порядок. Требования держат в фокусе ожидаемое поведение. Покрытие показывает пробелы. Приоритизация может сломаться из‑за зависимостей между тестами: если высокоприоритетный тест зависит от низкоприоритетного, последний придётся выполнить первым. Также важна доступность окружения и людей [2].

Политика регрессии: что и когда запускать

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

Таблица — не универсальный рецепт. Частота релизов, зрелость автоматизации, архитектура и цена production‑дефекта (дефекта в промышленной среде) у всех разные. Политику нужно подгонять под конкретный продукт [1].

Регрессия после релиза: shift‑right

Регрессия не заканчивается на релизе. Она продолжается в проде, но с другими детекторами: вместо assert (проверки‑утверждения в тесте) работают ошибки, latency (задержка) и бизнес‑метрики. Классическое возражение «мы не успели прогнать всё — как выпускать?» снимается так: выпускай на 5% и смотри. DevOps даёт способы тестировать в production, ограничивая blast radius (радиус поражения) [2].

Shift‑right (сдвиг вправо) — это проверки уже после выкладки, в реальной среде.

Пример. Выкатили pricing service (сервис расчёта цен) на 5% трафика и наблюдаем за ошибками платежей и latency. Через 15 минут увидели рост 500-х. Откат занял 10 минут. Пользователи этого почти не заметили. Команда получила данные о дефекте, который полный регресс мог пропустить. Мониторинг в проде — та же логика: что изменилось, что могло сломаться, как быстро узнаем. Инструменты другие [2].

Тестовая пирамида и контрактные проверки

Майк Кон предложил концепцию пирамиды тестирования еще в 2005 году. И сначала в ней было три уровня: unit, service, UI (пользовательский интерфейс). Грегори и Криспин развили её в пирамиду автоматизации: все уровни можно автоматизировать, а тестов на нижних уровнях должно быть больше. Это даёт раннее тестирование и более дешёвое устранение дефектов [4].

Пирамида — метафора, а не строгая пропорция. Иногда интеграционных тестов больше, чем unit, если архитектура сложная. Сравнивать их количество на разных уровнях бессмысленно: они разного «размера». Один acceptance‑тест (приёмочный тест) покрывает целый use case (сценарий использования). Один TDD‑тест (тест в разработке через тестирование) — одну ветку в методе [4].

Пирамида не говорит, что UI‑проверки не нужны. Она говорит, что UI E2E применяют для самых ценных пользовательских путей, которые нельзя надёжно подтвердить на нижних уровнях [1]. Если регрессия на 80% состоит из UI‑тестов, пирамида стоит вверх ногами. Это антипаттерн «рожок мороженого» (ice cream cone): мало unit, почти нет интеграционных, огромный слой нестабильных UI E2E и большой ручной регресс на релизе. В такой схеме стоимость регрессии растёт очень быстро, а скорость поставки падает.

Проверки нужно перекладывать вниз. Unit — самая дешёвая регрессия на каждый коммит. API — регрессия на уровне сервисов несколько раз в день. UI — медленно и хрупко, для ночного прогона или перед релизом. Для сервисных архитектур есть альтернатива пирамиде — «testing trophy» (кубок тестирования) Кента К. Доддса: больше интеграционных тестов, меньше unit, потому что ценность сервиса живёт в контрактах между компонентами.

Пирамида отвечает на вопрос «на каком уровне гонять». На вопрос «зачем этот тест в наборе» отвечают квадранты тестирования Брайана Мэрика в адаптации Криспин и Грегори: пирамида задаёт форму, квадранты — состав [4].

Сбалансированная регрессионная стратегия задействует все четыре квадранта. Набор только из Q1 и Q2 подтверждает, что система работает как задумано, но не отвечает, достаточно ли она хороша. Если в наборе нет Q4-проверок, производительность и безопасность остаются слепыми зонами. Это нужно фиксировать как осознанный выбор, а не как случайность. Exploratory (Q3) и нефункциональная регрессия (Q4) — не дополнительные активности, а части сбалансированного набора.

В микросервисной архитектуре отдельно стоит выделить contract testing (контрактное тестирование). API‑тест проверяет, что сервис отвечает как ожидается. Контрактный тест отвечает на другой вопрос: не нарушили ли мы ожидания потребителей интерфейса. Контрактная регрессия особенно важна при удалении или переименовании полей, изменении типов данных, смене семантики статусов и кодов ошибок, обновлении схем событий в очереди, введении новых обязательных параметров, поддержке нескольких версий клиента одновременно и поэтапном rollout (выводе) сервисов. Так несовместимость находят раньше, чем она станет дефектом у другого сервиса.

Нефункциональная регрессия

Регрессия — это не только «кнопка работает». Система может отдавать правильный ответ и при этом стать медленнее, уязвимее или менее доступной.

Полный нагрузочный тест после каждого merge не нужен. Но если изменение потенциально ухудшает конкретный атрибут качества, соответствующая проверка должна попасть в scope (область охвата) регрессии. Это согласуется со стратегиями из ISTQB Advanced Level: широкая автоматизация на одном или нескольких уровнях плюс сочетание функциональной и нефункциональной регрессии, подобранное под возможности организации. Короткому проекту и долгоживущему продукту с высокими требованиями к безопасности нужен разный уровень интенсивности [2].

Тестовые данные как часть стратегии

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

Рабочая стратегия включает:

• создание данных внутри теста через API, fixture (фикстуру) или factory (фабрику данных);

• изоляцию по tenant (арендатору, изолированному клиенту) или уникальному id запуска;

• очистку сущностей после теста;

• версионирование seed‑данных (начальных данных) вместе с кодом;

• маскирование production‑like данных (данных, похожих на промышленные) без реальных персональных данных;

• управляемое время для сценариев с датами и cron‑задачами.

Sleep(5000) не доказывает готовность системы. Он делает тест медленнее и прячет проблему синхронизации. Для асинхронных процессов лучше ждать конкретный статус или использовать polling (опрос состояния) с ограниченным timeout. Если QA и разработка не договорились о поддержке тестовых данных, регрессия сама становится источником ложных срабатываний [8].

Exploratory testing: то, что автоматизация не видит

Автоматизация хорошо проверяет то, что команда уже предусмотрела. Она плохо отвечает на вопрос «а что мы не предусмотрели?». Здесь работает exploratory testing: тестировщик одновременно изучает продукт, придумывает проверки и сразу их выполняет, а новые наблюдения использует для следующих шагов [1]. Автоматизированная регрессия — это checking, а не testing в полном смысле. Она находит только то, что заранее прописано в шагах. Исследовательское тестирование ловит проблемы UX, неочевидные сценарии и race conditions.

Исследовательскую сессию лучше проводить через test charter (устав сессии), а не хаотично. Пример:

• цель — найти ошибки в новой логике скидок;

• область — корзина, checkout, возвраты, история заказов;

• риски — отрицательная цена, неверное округление, двойное применение скидки, рассинхронизация web и mobile;

• время — 45–60 минут;

• данные — товары с разными ставками, несколько типов скидок, разные валюты и роли пользователей;

• результат — найденные дефекты, заметки, идеи для новых постоянных автопроверок.

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

Автоматизация: что стоит, а что не стоит автоматизировать

Автоматизация не равна качеству. Без неё быстрый и повторяемый регрессионный feedback в Scrum почти недостижим. Она позволяет гонять проверки часто и одинаково, но требует вложений в архитектуру тестов, данные, окружения и поддержку [1].

Часто выгоднее отложить автоматизацию тестов на функциональность, которая ещё активно меняется, пока область не стабилизируется. Попытка покрыть новую фичу автотестами в том же спринте, где её разрабатывают, часто оборачивается переписыванием тестов в следующем спринте [4].

Здесь важно разделить уровни. Unit, component и API‑тесты должны писаться в том же спринте. Это часть Definition of Done. Иначе копится automation debt (долг автоматизации): QA в спринте N автоматизирует фичи спринта N-1, и на регресс времени не остаётся. Откладывать стоит только дорогие и нестабильные UI E2E, пока интерфейс активно меняется. Защиту бизнес‑логики нельзя откладывать на спринт N+1.

Автоматизировать стоит стабильную функциональность, критические сценарии P0/P1 и проверки, которые нужно гонять часто. Не стоит автоматизировать то, что активно дорабатывается, сложные визуальные проверки без специализированных visual testing tools (инструментов визуального тестирования) и то, что проще и быстрее проверить вручную.

Отдельный вопрос — test oracle (тестовый оракул): откуда автоматизированная проверка знает правильный ответ? Автоматизация может проверить только то, что допускает автоматический оракул [3]. Для регрессии работают такие оракулы:

• эталонная (предыдущая) версия: гоняем старую и новую на одних данных и сравниваем ответы (diff‑тестирование — сравнение различий, golden master — эталонный снимок);

• модель или спецификация;

• инварианты («сумма скидок не превышает сумму заказа»);

• эвристики.

Без явного оракула автотест проверяет «не упало ли», а не «правильно ли». Это граница checking без testing, о которой писал Винтерингем.

Пример последовательности quality gates (шлюзов или ворот качества):

Pull Request
  -> Lint / Static Analysis
  -> Unit Tests
  -> Component and API Tests
  -> Contract Checks
  -> Merge

Main Branch
  -> Build Verification / Smoke
  -> Integration Tests
  -> Deploy to Test Environment
  -> Risk-Based Regression

Release Candidate
  -> P0/P1 Regression
  -> Critical UI E2E
  -> Exploratory Testing
  -> Non-Functional Checks by Change Risk
  -> Release Decision

Production
  -> Post-Deploy Smoke
  -> Synthetic Monitoring
  -> Error and Business-Metric Monitoring

Кратко по ступеням: Pull Request — линтер и статический анализ, модульные, компонентные, API‑ и контрактные проверки, затем слияние. Основная ветка — проверка сборки и дымовые тесты, интеграция, выкладка на тестовую среду, регрессия по риску. Кандидат на релиз — P0/P1, критичные UI E2E, исследовательское тестирование, нефункциональные проверки по риску изменения, решение о релизе. Промышленная среда — дымовой прогон после выкладки, синтетический мониторинг, мониторинг ошибок и бизнес‑метрик.

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

Тюлькин описывает похожий флоу: ночью Jenkins запускает регрессию, формируется Allure‑отчёт, встроенный в TestOps, а аннотации в коде (@Step, @Description) делают отчёт понятным [8]. Модульные тесты выполняются перед попаданием кода в main и блокируют выкладку до прохождения. Приёмочные тесты запускаются в CI как минимум раз в день, но не при каждом изменении, потому что идут дольше [4].

Как только автоматический регрессионный тест падает, команда откладывает текущую работу и разбирается. Если падение из‑за законного изменения поведения, сценарий обновляют. Если из‑за дефекта, лучше исправить его до новой фичи [4]. В идеале работу откладывают. Если это невозможно из‑за WIP (незавершённой работы) и дедлайнов, падение нужно классифицировать и назначить владельца в течение дня. Иначе красный пайплайн перестаёт быть сигналом.

Автотесты стоит писать как полноценный код. При плохом дизайне усилия на поддержку могут превысить усилия на написание тестов с нуля. На практике это видно, когда в проекте накапливается сотня хрупких capture‑replay скриптов (записи и воспроизведения) и без keyword‑driven подходов (подходов на ключевых словах) и Page Object (объекта страницы) уже не разобраться [4].

Как справляться с flaky tests

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

Практический порог: тест, упавший три и более раз за 10 последних прогонов без изменения кода, — кандидат в quarantine (карантин). Самая опасная реакция — «нажмём rerun (повторный запуск), пока не станет зелёным». Повторный запуск иногда помогает диагностировать проблему, но не устраняет её источник. Разумная политика retry (повтора): один повтор допустим, каждый retry логируется и учитывается в flaky rate (доле нестабильных тестов). Тест, требующий повтора чаще порога, уходит в quarantine. Так retry остаётся диагностическим сигналом, а не доказательством качества.

Рабочая политика для flaky tests:

• каждое падение классифицируют: product defect (дефект продукта), test defect (дефект теста), data issue (проблема данных), environment issue (проблема окружения), external dependency (внешняя зависимость), infrastructure issue (проблема инфраструктуры);

• нестабильный тест не прячут и не удаляют молча: его статус и причина видны в отчётности;

• повторно нестабильный тест временно переводят в quarantine: исключают из blocking‑gate (блокирующего шлюза), но продолжают гонять отдельно;

• для quarantined‑теста (теста в карантине) заводят задачу с владельцем и сроком; жёсткий SLA (соглашение об уровне сервиса) — 1–2 спринта на разбор, иначе тест удаляют: мёртвый тест в карантине создаёт ложное ощущение покрытия;

• рост числа flaky и quarantined tests считают техническим долгом.

Flaky rate стоит считать по тестам (число нестабильных тестов / все тесты), а не по запускам. Иначе одна падающая проверка в наборе из тысячи даёт мизерный процент. Если команда не доверяет красному пайплайну, она перестаёт реагировать и на настоящий дефект. Стабильность тестовой системы — такая же часть качества, как стабильность продукта.

Критерии входа и выхода

Регрессия не должна начинаться на неидентифицированной сборке, недоступной среде и случайных данных. «100% passed» (все тесты прошли) не должно автоматически означать готовность к production.

Entry criteria (критерии входа):

• сборка идентифицирована и развёрнута в целевом окружении;

• изменение прошло code review (ревью кода) и имеет понятный scope;

• для значимых изменений выполнен impact analysis;

• тестовая среда, внешние зависимости и данные доступны;

• подготовлены миграции БД, если нужны;

• критичные известные дефекты классифицированы, по ним есть решение о релизном риске.

Exit criteria (критерии выхода):

• выполнены все обязательные P0-проверки и согласованный набор P1;

• все падения классифицированы, а не остаются «красными без объяснения»;

• нет незакрытых blocker/critical‑дефектов (блокирующих и критических), неприемлемых для релиза;

• неисполненные проверки и ограничения зафиксированы как остаточный риск;

• проведена целевая exploratory‑проверка самых рискованных изменений;

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

ISTQB считает entry и exit criteria частью планирования тестирования: они делают начало, завершение и достаточность тестовой работы прозрачными и проверяемыми [1].

QA не «разрешает релиз»

QA даёт доказательства: что проверено, какие дефекты найдены, какие риски остаются и насколько надёжны результаты. Решение о приемлемости бизнес‑риска не должно неформально висеть на одном тестировщике.

У этого есть оборотная сторона. QA отвечает за качество доказательств. Если риски не выявлены или скрыты, это ответственность QA, а не стейкхолдеров. В Scrum решение о выпуске инкремента принимает Product Owner (владелец продукта): он владеет ценностью и риском для бизнеса, а QA предоставляет факты. Блокирует не QA, а непроверенный риск. Решение принимает тот, кто отвечает за последствия.

Формат обсуждения релизного риска:

Так вместо «QA не даёт добро» появляется конкретный разговор: какой риск остаётся, насколько он вероятен, какие последствия и кто имеет право его принять [1].

Метрики регрессии

Метрики не должны измерять занятость QA или стимулировать «набивание» тысяч слабых автотестов. Их задача — поддерживать решения о качестве, скорости обратной связи и вложениях в тестовую инфраструктуру.

Количество тестов, процент автоматизации и общий pass rate (доля успешных тестов) — вспомогательные числа, а не самостоятельный KPI (ключевой показатель эффективности). Большой набор тестов не гарантирует ни релизной готовности, ни качества продукта [1]. ISTQB Agile Extension добавляет другие показатели: соотношение прошедших и не прошедших тестов, количество и плотность найденных дефектов, покрытие требований, рисков и кода, объём изменённого кода. Метрики должны помогать в решениях, а не в наказании [4]. ISTQB Advanced Level добавляет показатели именно для регрессии: процент тестовых сценариев, интегрированных в регрессионный набор; средние трудозатраты на тест; число регрессионных циклов; статус подтверждающих и регрессионных тестов с трендами [2].

Отдельно стоит метрика качества самого набора — мутационное тестирование, «тестирование тестов». В код вносят сотни искусственных дефектов (мутантов), и mutation score (оценка мутаций) показывает долю убитых мутантов. 1000 тестов с mutation score 40% хуже, чем 200 тестов с 80%. Пример: 100 мутантов в pricing‑модуле, убито 78. Выжившие приходятся на округление и отрицательные суммы — ровно те баги, которые уходили в прод в прошлом квартале. Мутационное тестирование дорого. Его стоит применять точечно: к критичной логике (расчёты, права доступа), а не ко всему проекту.

Анти‑примеры, без которых метрики повисают:

1) pass rate 100% при наборе, который не трогает изменённый код — такая метрика‑пустышка;
2) regression duration вырос с 30 до 90 минут за два спринта — это сигнал о том, что набор не чистят, поэтому здесь необходим аудит и удаление устаревших тестов;
3) pass rate как KPI для команды — стимул удалять флаковые тесты и упрощать сложные тесты, чтобы он всегда был зелёный. Любая метрика без действия — это просто украшение.

Сквозной пример: изменение порядка скидок

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

Прямое влияние затрагивает корзину, checkout, pricing service, API промокодов и итоговую сумму заказа. Косвенное влияние доходит до возвратов и отмен, уведомлений клиенту, фискальных документов, аналитики выручки, мобильного приложения, внешней системы лояльности и ограничений промокодов по времени, товарам и пользователям.

Нефункциональные риски тоже реальны: не стал ли расчёт цены медленным при массовом применении промокодов; как сервис ведёт себя при timeout системы лояльности; нельзя ли применить скидку к чужому заказу; не расходятся ли суммы между web, mobile, API и фискальным документом.

Регрессия не равна одному E2E‑сценарию. Ключевой риск обычно живёт в правилах, данных, интеграциях и совместимости, а не в кнопке «оформить заказ».

Если команда ошибётся, картина другая. Допустим, impact analysis пропустил фискальную систему. Дефект ушёл в прод, суммы в чеке разошлись с заказом. Это escaped defect (дефект, ушедший в промышленную среду). На retrospective (ретроспективе) разбирают, почему анализ влияния не увидел интеграцию. В регрессионный набор добавляют проверку контракта с фискальной системой и фиксируют категорию пробела: тест‑дизайн, окружение, отсутствие покрытия или изменение вне scope.

Как встроить регрессию в события Scrum

Регрессия становится устойчивой, когда живёт внутри Scrum‑событий, а не рядом с ними.

• Backlog refinement (уточнение бэклога): QA помогает выявить риски, зависимости, acceptance criteria (критерии приёмки) и тестируемость истории.

• Sprint planning (планирование спринта): команда оценивает не только разработку, но и создание или обновление проверок.

• Daily scrum (ежедневный стендап): падения пайплайна и блокировки тестирования — общие impediments (препятствия).

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

• Sprint review (обзор спринта): команда показывает не только работающую функциональность, но и известные ограничения с остаточными рисками.

• Retrospective: разбирают production‑дефекты, длительность feedback, flaky tests и пропущенные риски.

Definition of Done стоит дополнить обязательствами по регрессионной защите:

• выполнен impact analysis для изменения;

• обновлены или добавлены проверки на нужном уровне пирамиды;

• критичные acceptance criteria автоматизированы там, где это оправдано;

• выполнены релевантные функциональные и нефункциональные проверки;

• известные риски документированы;

• результаты тестирования доступны всей команде.

Практический план из семи шагов

1. Подготовить план тестирования. Сделать анализ влияния вместе с разработчиками, определить затронутые модули, собрать целевой регрессионный набор, оценить время прогона и выделить кандидатов на автоматизацию.
2. Создать доску регрессии. Расставить задачи по приоритету от самых рискованных к наименее важным по risk‑based подходу: P0/P1-тесты идут первыми.
3. Анализировать отчёты о дефектах. Смотреть не только pass/fail, но и тренды: тест, падающий три спринта подряд, возможно, устарел; если прогон стабильно зелёный, но в прод уходят баги — набор не покрывает реальные риски.
4. Добавить исследовательское тестирование. Автоматизированная регрессия это checking, а не testing, и она не заменяет человека для UX‑проблем и неочевидных сценариев.
5. Настроить модель коммуникации. QA держит связь с Product Owner по изменениям требований и с разработчиками по изменениям кода, иначе регрессионный набор отрывается от реального продукта.
6. Автоматизировать с умом. Стабильную функциональность и критические сценарии, но не то, что ещё активно меняется.
7. Управлять тестовыми данными. Держать seed‑данные в репозитории, использовать фабрики или фикстуры и согласовывать подходы с разработкой.

Когда это не работает

У подхода есть границы. В legacy‑коде (унаследованном коде) без тестов пирамиду строить не с чего. Начинать стоит с characterization tests (характеризующих тестов), которые фиксируют текущее поведение, и только потом добавлять проверки по риску. В команде из двух человек на продукте‑прототипе полная политика регрессии избыточна: хватит smoke‑тестов и exploratory. В монолите без выделенных границ contract testing неприменим, пока не появились явные контракты между модулями.

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

Частые ошибки

Слишком много UI‑тестов в регрессии. Если 80% набора — это UI, пирамида стоит вверх ногами. UI‑тесты медленные, хрупкие и дорогие в поддержке. Падение из‑за смены CSS‑класса говорит не о дефекте продукта, а о плохо написанном тесте без Page Object и data‑атрибутов.

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

Ещё одна ошибка — сводить ложные срабатывания только к «кривым тестам». Чаще они возникают из‑за нестабильного окружения, устаревших данных и изменений в смежных системах.

Что в итоге

Сильная стратегия регрессии в Scrum не пытается прогонять всё после каждого изменения. Она строит быстрые проверки на нижних уровнях пирамиды, защищает критические пользовательские потоки через risk‑based приоритизацию, использует impact analysis, поддерживает доверие к автотестам через управление flaky tests и тестовыми данными, а остаточный риск делает видимым для всей команды, а не спрятанным за процентом passed tests.

Ценность регрессии измеряется не количеством зелёных галочек, а тем, насколько уверенно команда отвечает на три вопроса: что изменилось и что могло быть затронуто, какие важные риски проверены и какие остаются — и кто осознанно принимает решение о релизе.

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

---

Источники

1. ISTQB Foundation Level v4.0 — разделы 1.3, 1.5.2, 2.2.3, 2.3, 4.4.2, 5.1.1–5.1.6, 5.2.1–5.2.4, 5.3.1, 6.2

2. ISTQB Advanced Level (Test Manager) — разделы 2.2.2, 5.1.5, “Стратегии тестирования”, «Testing in production», “Confirmation testing (re‑testing) and regression testing”

3. ISTQB Advanced Level Test Automation Engineering v2.0 — раздел «Limitations of test automation» (test oracle)

4. ISTQB Agile Extension — раздел 2.2.2 (управление регрессионными рисками, CI/CD, метрики), раздел 3.1.2 (тестовая пирамида, квадранты тестирования)

5. Agile Testing Foundations — ISTQB Foundation Level Agile Tester, разделы 2.2 (постоянная регрессия в течение итерации), 3.1.2

6. Куликов С. — Тестирование ПО. Базовый курс, 3-е изд., стр. 87

7. Винтерингем — Тестирование веб‑API, 2024, глава 6 (включая ссылку на вебинар Майкла Болтона, 2012)

8. Тюлькин И. — QA: тестирование, автоматизация и процессы, стр. 64–67, 791

9. Мохан Г. — Full‑Stack Testing (Фулстек тестирование), 2024, стр. 75

10. The State of Agile Report — Digital.ai, 2021 (опрос об использовании Agile‑практик)