Release testing — проверка готовности конкретного изменения к выпуску в определённых условиях. Речь идёт о продукте, конфигурации, данных, зависимостях и способе развёртывания вместе. Успешные функциональные тесты важны, но не подтверждают, что миграция выполнится правильно, старая версия клиента продолжит работать, а команда сможет заметить ухудшение после запуска.
Результат QA — ясное описание проверенного риска для решения о выпуске. Формулировка «всё протестировано» скрывает границы работы. Гораздо полезнее указать сборку, изменённые области, пройденные сценарии, известные дефекты и условия, при которых вывод остаётся действительным.
Что является объектом проверки
Зафиксируйте release candidate: commit или идентификатор сборки, зависимости, миграции, конфигурацию и feature flags. Протестированный код с другим значением флага способен вести себя иначе. Повторная сборка из тех же исходников тоже требует понятной связи с исходным артефактом.
Соберите список изменений, включая инфраструктуру и внешние контракты. Небольшое изменение настройки cookie может затронуть вход сильнее, чем заметное обновление экрана. Размер diff не определяет риск сам по себе; важны путь пользователя, влияние на данные и возможность восстановления.
Критерии входа и выхода
До начала договоритесь, что делает кандидата пригодным для проверки: доступный стенд, известная сборка, готовые данные и работающие ключевые зависимости. Если эти условия нарушены, результаты будут неоднозначны. Задержку из-за неисправного стенда не стоит маскировать ручным изменением данных без записи.
Критерии выхода описывают обязательные сценарии, допустимые дефекты и подтверждённую готовность развёртывания. Универсального правила «не более трёх багов» нет: один дефект потери данных важнее десятков мелких визуальных проблем. Риск и исключения принимаются ответственными владельцами на основании фактов.
Как выбрать набор проверок
Сначала анализируют изменённую область и её зависимости. Затем проверяют исправления, новую функциональность, связанные регрессионные риски и основные цепочки продукта. Критический smoke нужен для кандидата целиком: локальное изменение не исключает ошибку упаковки или конфигурации.
Учитывайте историю инцидентов и слабые места покрытия. Если релиз меняет расчёт скидки, важны итоги, округление, возвраты и документы. Перебор несвязанных экранов может занять всё окно и оставить непроверенной именно финансовую цепочку, ради которой выпускался кандидат.
Миграции и совместимость
Проверьте обновление на данных, похожих по структуре и объёму на реальные. Пустая база не выявляет конфликт существующих значений, долгую блокировку и нарушение ограничений. Уточните, может ли приложение работать со схемой в промежуточном состоянии.
При постепенном развёртывании старые и новые экземпляры могут одновременно обращаться к данным. Нужны проверки совместимости API и схем, а также возвращения к предыдущей версии. Откат приложения не отменяет автоматически изменение данных; необратимая миграция требует отдельного плана восстановления или движения вперёд.
Практический пример: новая скидка
Релиз меняет правила применения промокода и добавляет поле в заказ. Подготовьте существующий заказ без нового поля, новый тестовый заказ и несколько промокодов с известными ограничениями. Зафиксируйте ожидаемые суммы независимо от приложения.
- 1.Обновите тестовое окружение штатной процедурой. Ожидается успешная миграция и доступность старых заказов с прежними итогами.
- 2.Создайте заказ с подходящим и неподходящим промокодом. Ожидаются корректные сумма, объяснение отказа и одинаковые значения в API, интерфейсе и документе.
- 3.Проверьте старый поддерживаемый клиент на новом сервере. Ожидается согласованное поведение при новом поле и сохранение основных действий.
- 4.Выполните согласованный сценарий отката либо отключения флага. Ожидается сохранность созданных заказов и заранее определённое поведение новых данных.
После исправления найденной ошибки повторите затронутую цепочку на новом кандидате. Старый успешный результат не переносится автоматически на изменённый артефакт.
Как проверить сам выпуск
Процедура развёртывания должна быть воспроизводимой: известны шаги, проверки готовности, владелец и условия остановки. На тестовом окружении полезно пройти тот же путь доставки артефакта, а не вручную скопировать файлы другим способом.
Проверьте значения окружения, доступность зависимостей и состояние миграции. Техническая готовность контейнера не доказывает готовность бизнес-операции. Добавьте короткую проверку чтения и безопасного действия в подходящем тестовом контексте, чтобы увидеть конфигурационную ошибку до широкого воздействия.
Наблюдение после запуска
До выпуска определите сигналы: доля ошибок, задержки, успех ключевой операции, очередь и критичные бизнес-инварианты. Нужны ожидаемый baseline и правило реакции. Мониторинг, который никто не откроет или не сможет связать с кандидатом, не уменьшает неопределённость.
При canary сравнение с контрольной группой помогает заметить ухудшение, но малая выборка может не включить редкий сценарий. Учитывайте состав трафика и длительность наблюдения. Плавное развёртывание ограничивает воздействие, однако не заменяет предварительную проверку данных, безопасности и миграций.
Решение о готовности
QA предоставляет факты: что прошло, что не прошло, что не проверено и почему. Укажите конкретные последствия известных дефектов и обходной путь, если он действительно проверен. «Пользователь может повторить» нельзя считать рабочим обходом, пока не исключён дубль операции.
Если изменение сужается или часть функциональности отключают флагом, обновите область вывода. Решение относится к фактической конфигурации выпуска. Устное обещание отключить рискованный путь не заменяет проверку того, что он действительно недоступен в выбранном кандидате.
Ошибки и завершение
Частые ошибки — тестировать движущуюся сборку, считать regression единственной задачей, забывать смешанные версии и принимать зелёный health check за готовность. После позднего изменения важно повторить осмысленный набор по его риску, а не автоматически объявлять весь прошлый прогон актуальным.
Итоговый release report должен быть коротким и проверяемым: артефакт, условия, результаты, открытые риски и необходимые действия. Тогда решение о выпуске опирается на наблюдения, а команда понимает, какие сигналы отслеживать и как действовать при ухудшении.