Регрессионное тестирование по рискам: что проверять, когда времени мало
Регрессия — это не «прогнать всё ещё раз». В реальном релизе времени почти всегда меньше, чем проверок, поэтому ценность QA — выбрать главное и честно назвать остаточный риск.
- Понять, что изменилось
- Найти затронутые сценарии
- Выбрать проверки с большим impact
- Назвать, что не покрыто
Начинай с изменения, а не с привычки
Регрессия легко превращается в ритуал. Risk-based regression начинается с release notes, коммитов, задач или разговора с разработчиком: что поменяли и что это может задеть?
Один и тот же баг в checkout важнее после рефакторинга оплаты, чем после правки текста в футере.
Что считать высоким риском
Высокий риск — это большой ущерб или высокая вероятность. Деньги, вход, права, персональные данные, заказы, платежи и интеграции обычно идут первыми.
- Сценарии, которые блокируют главную работу пользователя.
- Сценарии, где двигаются деньги или необратимые данные.
- Зоны, затронутые текущим релизом.
- Зоны с недавними или повторяющимися дефектами.
- Интеграции, где сбой плохо виден в интерфейсе.
Как безопасно сказать “не проверяли”
Middle QA не молча пропускает проверки. Он говорит, что не покрыто и почему. Так невидимая дырка становится общим релизным решением.
Фраза “не тестировалось” не стыдная, если она явная. Опасной она становится, когда все думают, что это проверил кто-то другой.
Компактный регрессионный чек-лист
Для небольшого релиза проверь smoke-сценарии, изменённую функциональность, соседнюю функциональность, права доступа, ключевые негативные случаи и один end-to-end бизнес-путь.
Для API-релиза добавь совместимость схемы, ошибки, идемпотентность и старые клиенты, если они ещё существуют.
Что улучшать после релиза
Каждый пропущенный баг учит регрессию. Спроси, какого сигнала не хватило: тест-кейса, данных, владельца, лога или автоматической проверки.
Регрессия становится лучше, когда её редактируют, а не когда она только растёт.
Матрица вероятности и ущерба
Оцени каждый риск по простой шкале 1–3. Вероятность растёт, если код меняли, зона сложная, были похожие дефекты или зависимость нестабильна. Ущерб растёт для потери денег или данных, security, блокировки основного пути и большого числа пользователей. Score помогает сравнивать, но не заменяет обсуждение: риск 3×3 идёт раньше 1×3.
Добавь confidence. Если команда плохо понимает новую интеграцию, проверка может подняться выше даже без истории дефектов. Записывай причину оценки, иначе матрица превращается в красивые цифры без решения.
Сценарий P I Score Решение\nПовтор payment callback 3 3 9 проверить первым\nСтарый mobile client 2 3 6 contract + smoke\nФильтр истории заказов 2 1 2 выборочно\nТекст в footer 1 1 1 вне текущего scope
Пример: на регрессию оплаты есть 90 минут
Первые 10 минут — прочитать diff, ticket и rollout plan, уточнить изменённые сервисы. Следующие 15 — smoke входа, каталога и открытия checkout. 40 минут — happy path оплаты, decline, timeout с retry, повтор callback, одинаковый idempotency key и сверка заказа с платежом. 15 минут — старый клиент и права на чужой заказ. Последние 10 — логи, метрики и test summary.
Не вошли редкие валюты и полный набор промокодов. Это не скрывают: указывают, почему они ниже, кто принимает риск и какой мониторинг заметит проблему после rollout.
Как написать test summary, по которому можно выпускать
Короткий отчёт содержит build и окружение, scope, результат критичных сценариев, открытые дефекты, непроверенные области, наблюдения по метрикам и рекомендацию QA. Рекомендация не должна звучать как магическое “разрешаю”: решение о релизе принимает команда или владелец риска.
Хорошая формулировка: “Критичные payment flow пройдены на build 1842. Открыт blocker PAY-91: повтор callback списывает дважды. Рекомендуем остановить rollout. Не проверены JPY и Android 11; при продолжении риск принимает release owner”.
Частые вопросы о регрессии
Чем smoke отличается от regression?
Smoke быстро отвечает, пригодна ли сборка для дальнейшей проверки и доступны ли ключевые функции. Regression ищет побочные эффекты изменений в существующем поведении. Smoke обычно входит в regression, но не заменяет её.
Нужно ли всегда запускать весь автоматизированный набор?
Если набор быстрый, стабильный и дешёвый, часто да. Но его зелёный результат не отменяет анализ impact, новые риски и ручное исследование. Медленные или flaky проверки также требуют приоритизации и ремонта.
Кто принимает остаточный риск?
Не QA в одиночку. QA делает риск и доказательства видимыми; решение обычно принимает product, engineering или release owner по процессу команды.
Хорошая регрессия — это видимая приоритизация. Она защищает продукт и честно показывает команде, какой риск всё ещё едет в релиз.