Тестирование перед релизом - это короткий, но жёсткий цикл проверок, который подтверждает: критические сценарии работают, интеграции не сломаны, система выдерживает ожидаемую нагрузку, а риски безопасности контролируются. Чтобы "не было стыда", фиксируйте критерии готовности, режьте проверку по приоритетам must/should/could и автоматизируйте повторяемое.

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

Тестирование перед релизом: что и как проверять, чтобы не было стыда - иллюстрация

Must: прогон критических пользовательских путей (happy path + 1-2 негативных ветки) на релизном билде.
Must: быстрый регресс ключевых модулей + проверка hotfix-областей.
Must: smoke интеграций (платежи/уведомления/SSO/внешние API) и валидация контрактов.
Should: проверка деградации производительности и ошибок под "похожей на прод" конфигурацией.
Should: экспресс-аудит безопасности: секреты, права доступа, PII-логирование, CORS/CSRF.
Could: доп. проверка совместимости (браузеры/ОС/девайсы) и доступности, если релиз затрагивает UI.

Функциональная готовность: ключевые сценарии и критические пути

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

Критерий успеха: все must-сценарии проходят без блокирующих дефектов; известные ограничения задокументированы и согласованы.

Что проверять (must / should / could)

Must: 3-10 критических путей (регистрация/логин, поиск/каталог, оформление/оплата, создание/редактирование сущности, ключевые админ-операции).
Must: права и роли (минимум: гость/пользователь/админ), запрет на действия без прав.
Must: негативные ветки для денег/данных (ошибка платежа, таймаут внешнего API, повторная отправка формы, конкурирующие изменения).
Should: граничные значения (длины полей, форматы, локали/таймзона, пустые списки).
Could: UX-детали (тексты, иконки, микроанимации), если не влияют на выполнение сценария.

Кому подходит и когда не стоит делать

Подходит: командам, где релиз идёт регулярно и нужна уверенность "здесь и сейчас"; полезно и для in-house, и когда вы покупаете услуги тестирования ПО как независимую проверку.
Не стоит делать в таком виде: если нет стабильного релизного кандидата (RC) или окружение не приближено к продакшену - сначала стабилизируйте сборку и конфигурацию, иначе qa тестирование превратится в охоту на фантомы.

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

Цель: не дать старым дефектам вернуться из-за новых изменений и миграций.

Критерий успеха: регресс покрывает изменённые зоны и их зависимости; повторный прогон даёт воспроизводимый результат.

Что понадобится (доступы, артефакты, инструменты)

Требования/артефакты: changelog/список тикетов в релизе, список затронутых компонентов, список "рискованных" модулей (платежи, авторизация, миграции).
Окружения: стенд, максимально похожий на прод (конфиги, фичефлаги, версии зависимостей), доступ к логам и метрикам.
Доступы: тестовые аккаунты для ролей, сервисные ключи/токены для интеграций (в безопасном хранилище), доступ к трассировке/лог-агрегатору.
Набор тестов: smoke + targeted regression (по зонам изменений) + "горячие" проверки по истории инцидентов.
Автоматизация: автоматизированное тестирование для повторяемого регресса (API/UI), чтобы релиз не тормозился ручными прогонами; ручное - для новых/сложных сценариев и UX.

Как резать регресс по приоритетам

Must: smoke на весь продукт (жив ли сервис, не падает ли критический путь) + проверки зон изменений.
Should: расширенный регресс зависимых модулей (что "цепляется" за изменения) и проверки данных/миграций.
Could: широкий регресс "на всякий случай" - только если есть время и риски высокие.

Интеграция и совместимость: тесты внешних зависимостей и контрактов

Цель: убедиться, что релиз не ломает взаимодействие с внешними сервисами и клиентами (API/SDK/вебхук/SSO) и корректно работает в заявленных средах.

Критерий успеха: контракты согласованы, деградация обрабатывается, несовместимости выявлены до выката.

Составьте карту интеграций и владельцев. Зафиксируйте, какие внешние зависимости участвуют в критических сценариях: платежи, SMS/e-mail, S3/объектное хранилище, SSO/OAuth, карты, антифрод, CRM. У каждого пункта должен быть контакт и SLA ожиданий (хотя бы качественно).
- Must: зависимости критических путей и все изменения в их настройках/версиях.
- Should: вторичные интеграции (аналитика, маркетинговые вебхуки).
Проверьте контракт API на уровне схем и статусов. Сравните вход/выход (поля, типы, обязательность, коды ошибок) между текущей и релизной версиями; убедитесь, что обратная совместимость не нарушена.
- Must: не ломать существующих клиентов без миграционного плана.
- Must: ошибки валидируются и возвращаются предсказуемо (без "500 на всё").
Сделайте интеграционный smoke на реальных конфигурациях. Прогоните 1-2 транзакции на каждый внешний сервис на релизном стенде: успешный сценарий и контролируемая ошибка (например, неверный токен/таймаут).
- Must: правильная обработка таймаутов, ретраев и идемпотентности (особенно для платежей/вебхуков).
- Should: проверка лимитов/квот и сообщений об ошибках для пользователя.
Проверьте совместимость клиентов и окружений. Убедитесь, что заявленные браузеры/ОС/версии SDK не деградировали на критических сценариях.
- Must: те комбинации, которые приносят основной трафик/доход (по вашим данным).
- Could: экзотика - только если вы её официально поддерживаете.
Зафиксируйте деградацию и фолбэки. Если интеграция недоступна, система должна вести себя предсказуемо: очередь, повтор, заглушка, понятная ошибка, отключение фичефлагом.
- Must: отсутствие бесконечных ретраев и лавины запросов при падении партнёра.

Примеры команд для быстрой проверки контрактов и доступности

Проверка health: curl -fsS https://staging.example.com/health
Проверка статуса и времени ответа: curl -o /dev/null -s -w "%{http_code} %{time_total}n" https://staging.example.com/api/ping
Проверка TLS/сертификата: openssl s_client -connect staging.example.com:443 -servername staging.example.com

Быстрый режим

Must: для каждой критической интеграции - 1 успешный запрос + 1 контролируемая ошибка на релизном стенде.
Must: сверка контрактов для изменённых эндпоинтов (поля/типы/коды ответов).
Should: тест таймаута/ретрая, чтобы не получить шторм запросов при сбое партнёра.
Could: быстрая проверка 1-2 целевых браузеров/ОС на критическом пути.

Нагрузочное поведение: проверка под реальной и пиковой нагрузкой

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

Критерий успеха: под нагрузкой нет лавинообразного роста ошибок, сервис восстанавливается после пика, а узкие места понятны и имеют план.

Проверка результата (чек-лист)

Must: ошибки 5xx/таймауты не растут лавинообразно при росте RPS/конкурентности на критическом сценарии.
Must: нет утечек ресурсов (память/дескрипторы/соединения) на коротком прогоне с прогревом и удержанием.
Must: база/кэш не уходят в стопор: блокировки, пул соединений, очереди, GC/CPU не "залипают".
Must: включены и проверены ограничители: rate limit, circuit breaker, backpressure (или их эквиваленты).
Should: холодный старт/рестарт не вызывает длительной недоступности (прогрев кэшей, миграции, фоновые задачи).
Should: проверена работа очередей и воркеров: нет бесконечного ретрая, есть DLQ/обработка ядовитых сообщений (если применимо).
Could: проверка "пилообразного" профиля (всплески/спады), если у вас типичный дневной/ивентный трафик.

Безопасность и приватность: быстрый аудит перед релизом

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

Критерий успеха: нет очевидных секретов/PII в логах и репозитории, доступы минимальны, внешняя поверхность контролируема.

Частые ошибки, которые нужно отловить

Must: секреты в репозитории/образах/логах (токены, ключи, пароли), в том числе в примерах конфигов.
Must: включённые debug-режимы, подробные stack trace для пользователя, раскрытие версий/окружения.
Must: неправильные права: IDOR (доступ к чужим объектам по ID), отсутствие проверок ролей на API.
Must: PII в логах/трекинге (телефоны, e-mail, документы, токены сессии), особенно в access-логах и аналитике.
Must: небезопасные CORS-настройки и отсутствие CSRF-защиты для state-changing запросов (если применимо к вашей архитектуре).
Should: неограниченные/предсказуемые токены, слишком длинные TTL, отсутствие ротации/ревокации.
Should: отсутствие лимитов на чувствительные операции (логин, восстановление пароля, отправка кода), что облегчает перебор.
Could: отсутствие security headers (где актуально) и недостаточная маскировка данных в UI/экспортах.

Критерии приёмки и чек-лист для зелёного релиза

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

Критерий успеха: понятные go/no-go условия, согласованные владельцами продукта и эксплуатации, и прозрачный список остаточных рисков.

Чек-лист релизной готовности (must / should / could)

Must: выполнено тестирование программного обеспечения на релизном кандидате: критические сценарии зелёные, блокеров нет.
Must: регресс по зонам изменений завершён; результаты зафиксированы (отчёт/прогон в CI, список известных дефектов).
Must: мониторинг/логирование готовы: вы знаете, как увидеть ошибку и как быстро откатиться/выключить фичу.
Must: план отката и миграций данных проверен (хотя бы dry-run) и понятны условия, когда откатываемся.
Should: автоматизированное тестирование для smoke/регресса встроено в пайплайн и воспроизводимо на RC.
Should: проведён экспресс-скан конфигурации безопасности и проверены доступы/секреты.
Could: расширенная проверка совместимости и нефункциональных требований, если релиз затрагивает фронт/клиенты.

Альтернативы, когда полный прогон неуместен

Risk-based релиз (по риску): уместно при небольших изменениях. Делайте узкий регресс по impacted-area + smoke, а остальное переносите, но фиксируйте риски и план наблюдения.
Canary/поэтапный выкат: уместно, если есть возможность ограничить аудиторию. Добавьте усиленный мониторинг и быстрый откат; это снижает цену ошибки при неполном тестировании перед релизом.
Feature flags + kill switch: уместно, когда часть функциональности можно выключить без отката всего релиза. Обязательно заранее проверить, что флаг реально отключает эффект и не ломает данные.
Тестирование у внешней команды: уместно, когда нужна независимая валидация или не хватает рук/экспертизы. Формулируйте scope и критерии качества заранее, иначе услуги тестирования ПО будут "про всё и ни о чём".

Ответы на типичные сомнения при последней проверке перед релизом

Можно ли ограничиться только smoke, если времени мало?

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

Что важнее в последний день: UI или API?

Важнее то, что ломает критический путь для пользователя и деньги/данные. Обычно это API/интеграции плюс один UI-прогон ключевого сценария на реальном клиенте.

Как понять, что регресс достаточный, а не "для галочки"?

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

Нужно ли делать нагрузочные тесты перед каждым релизом?

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

Где уместнее автоматизация, а где ручная проверка?

Автоматизация лучше всего работает для повторяемого регресса (smoke, API-контракты, критические happy path). Ручная проверка нужна для новых сценариев, сложных UX и исследовательского поиска дефектов.

Что считать стоп-фактором для релиза?

Блокеры в критическом пути, риски потери/искажения данных, неконтролируемые сбои интеграций и отсутствие рабочего плана отката. Всё остальное допускается только как согласованный и документированный риск.