Регрессионное тестирование по рискам: что проверять, когда времени мало
Регрессия — это не «прогнать всё ещё раз». В реальном релизе времени почти всегда меньше, чем проверок, поэтому ценность 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”.
Разбор: релиз меняет округление платежей
Команда изменила сервис расчёта комиссии. До релиза 90 минут, полный набор занимает два дня. Задача QA — не притвориться, что проверено всё, а построить короткий набор по зоне влияния и заранее назвать, где решение об остаточном риске остаётся за командой.
- Найти изменённые правила и потребителей сервиса.
- Ранжировать сценарии по вероятности и ущербу.
- Проверить критичный путь и ближайшие связи.
- Опубликовать результаты и остаточный риск.
Построй карту влияния
Прочитай diff, тикет и историю инцидентов. Расчёт комиссии может вызываться при переводе, возврате, отмене, выписке и уведомлении; каждое место — потенциальный потребитель изменённого контракта. Отметь валюту, единицу хранения, порядок округления и поведение старых клиентов. Если diff показывает только новую формулу, всё равно спроси, кто кэширует результат или повторяет запрос после timeout.
Сократи набор осмысленно
Сначала smoke: вход, доступность счетов и базовый перевод. Затем граничные суммы и валюта с минимальной денежной единицей, перевод ровно на остаток, отказ при недостатке средств, повтор с тем же ключом, возврат и сверка выписки. Разбей тесты на обязательные для выпуска и те, что можно проверить после rollout. Приоритет получают не самые короткие, а сценарии с возможной потерей денег или неправильным балансом.
Определи oracle и данные
Ожидаемую комиссию вычисли независимо от ответа API: по согласованной формуле и заранее подготовленным значениям. Для 1.005 в десятичной арифметике выбор округления может менять результат; тест без уточнённого правила бесполезен. Проверяй одновременно ответ, баланс двух счетов, запись операции и выписку. Два зелёных экрана не доказывают корректного ledger, если внутренние суммы разошлись.
Напиши отчёт, по которому реально решают
Укажи версию, окружение, результаты обязательных проверок, открытые дефекты и неохваченные области. Например, старый Android-клиент и редкая валюта не проверены; это не скрывают в формулировке “регрессия пройдена”. Назови владельца решения, мониторинг после релиза и порог отката. Если найдено двойное списание, рекомендация — остановить rollout независимо от процента зелёных тестов.
Build 1842 / QA / payment-fee rollout\nPassed: transfer, insufficient funds, rounding boundary, retry, refund\nBlocked: none\nNot checked: Android 11, JPY rounding, delayed statement export\nResidual risk: old client may parse fee field differently\nMonitor: duplicate charge count, ledger mismatch, 5xx, fee delta\nRecommendation: staged rollout with rollback threshold agreed by owner
Почему это регрессия по риску?
Набор основан на изменении, потребителях и ущербе, а не на привычном порядке чек-листа. Он не обещает полной безопасности, но даёт команде видимость проверенного, пробелов и сигналов, которые покажут проблему после выкладки.
Второй кейс: релиз CRM меняет конвертацию лида
Правка кажется маленькой: при конвертации лида теперь создаётся задача менеджеру. Но операция затрагивает клиента, сделку, назначение владельца, уведомления и повторный запрос. Регрессия должна идти по связям состояния, иначе зелёная кнопка Convert скроет повреждённые данные.
Построй граф зависимостей
До теста выпиши объекты: lead, customer, deal, activity, task, notification. Для каждого отметь create/update/delete и ключ связи. Проверь, какие события выполняются синхронно, а какие через очередь. Если задача появляется с задержкой, тест ждёт наблюдаемого состояния до ограниченного timeout, а не спит фиксированные пять секунд. Отдельно проверь, что у владельца задачи есть право видеть созданного клиента.
Выбери контрольные сценарии
Минимум: успешная конвертация нового лида, запрет повторной, конвертация с уже существующим email и отказ без обязательного поля. Затем проверь роль другого менеджера и откат при сбое создания задачи. Если создание клиента успело пройти, а задача упала, нужно знать контракт: вся операция откатывается или система делает retry. Без этого expected для частичного состояния невозможно оценить.
Проверь идентичность и количество объектов
После первого запроса должны быть ровно один клиент, одна сделка и одна задача в ожидаемых статусах. Повтори тот же запрос и сравни counts и id: ответ “already converted” сам по себе не доказывает отсутствие дубля. Проверь связи task.customer_id, deal.customer_id и owner_id. Уникальность email в UI не защищает от конкурентных двух запросов, поэтому риск гонки вынеси отдельно.
Проверь даты и напоминания
Просроченная задача не должна превращаться в обычную из-за неверного часового пояса. Используй фиксированную дату в тестовом окружении, сравни due_at в API, отображение менеджеру и сортировку списка просроченных. При смене DST ожидаемый локальный день может отличаться от UTC; зафиксируй правило продукта. Проверь, что уведомление не отправляется дважды при повторной доставке события.
Отрази пробелы в выпускном отчёте
Если времени нет на multi-tenant и миграцию старых лидов, назови эти области явно. Выдели запрет повторной конвертации и права на нового клиента как обязательные перед rollout, потому что ошибки там меняют данные и доступ. После выкладки мониторь долю неудачных конвертаций, число дублированных клиентов и глубину очереди задач. Отчёт с этими сигналами полезнее общего “CRM regression passed”.
Case Client Deal Task Lead state\nfirst convert +1 +1 +1 converted\nrepeat same lead +0 +0 +0 converted\ninvalid lead +0 +0 +0 unchanged\ntask worker fails contract-defined retry or rollback\nsecond manager no access unless assigned
Почему это полноценная регрессия?
Тест проверяет не одну кнопку, а инварианты связанных объектов, роли, асинхронные события и повторяемость операции. Матрица делает риск понятным разработчику и владельцу релиза; её можно обновлять, когда меняется процесс продаж.
Частые вопросы о регрессии
Чем smoke отличается от regression?
Smoke быстро отвечает, пригодна ли сборка для дальнейшей проверки и доступны ли ключевые функции. Regression ищет побочные эффекты изменений в существующем поведении. Smoke обычно входит в regression, но не заменяет её.
Нужно ли всегда запускать весь автоматизированный набор?
Если набор быстрый, стабильный и дешёвый, часто да. Но его зелёный результат не отменяет анализ impact, новые риски и ручное исследование. Медленные или flaky проверки также требуют приоритизации и ремонта.
Кто принимает остаточный риск?
Не QA в одиночку. QA делает риск и доказательства видимыми; решение обычно принимает product, engineering или release owner по процессу команды.
Хорошая регрессия — это видимая приоритизация. Она защищает продукт и честно показывает команде, какой риск всё ещё едет в релиз.