Что тестировать перед релизом: приоритеты при сжатых сроках

Что тестировать в первую очередь, если сроки релиза сжаты

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

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

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

Первый вопрос перед тестированием: что именно изменилось в релизе

Сокращать тестирование без понимания состава релиза рискованно. Сначала нужно зафиксировать, какие изменения вошли в конкретную сборку и какие части продукта они потенциально затрагивают.

Перед проверкой желательно понимать:

• какие функции добавлены;
• что изменилось в существующей функциональности;
• какие дефекты исправлялись;
• менялись ли API;
• затрагивалась ли база данных;
• обновлялись ли библиотеки и компоненты;
• менялись ли интеграции;
• затрагивались ли роли и права доступа;
• были ли изменения конфигурации или инфраструктуры;
• какие исправления вошли в сборку непосредственно перед релизом.

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

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

Как определить критические пользовательские сценарии

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

Высокий приоритет обычно получают процессы, сбой которых:

блокирует основную услугу;

не позволяет пользователю оплатить товар или услугу;

приводит к потере заказа или данных;

блокирует вход в систему;

нарушает доступ к данным;

останавливает работу сотрудников;

затрагивает значительную часть аудитории;

не имеет приемлемого обходного сценария.

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

Поэтому список критических сценариев лучше формировать заранее и пересматривать по мере развития продукта.

Как расставлять приоритеты по риску

При сжатых сроках тестирование имеет смысл строить по принципу risk-based testing — тестирования на основе риска.

Для каждого сценария нужно ответить минимум на два вопроса:

1. Насколько вероятно, что здесь появилась ошибка?
2. Насколько серьёзными будут последствия?

Дополнительно можно учитывать:

• объём и сложность изменения;
• количество связанных систем;
• историю дефектов в этой области;
• частоту использования функции;
• сложность восстановления после ошибки.

Такая матрица не должна превращаться в сложную математическую модель. Её задача — помочь команде сравнить несколько рисков и решить, на что потратить ограниченное время.

Например, редкая визуальная ошибка в малоиспользуемом разделе может иметь меньший приоритет, чем изменение платёжного процесса, даже если интерфейсный дефект воспроизводится стабильно.

Что проверять первым: практический порядок

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

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

Что должен включать smoke-тест перед релизом

Smoke testing — это короткая проверка базовой работоспособности продукта. Его задача — быстро определить, имеет ли смысл продолжать более глубокое тестирование.

Для интернет-магазина smoke-набор может включать:

• открытие сайта;
• работу каталога;
• открытие карточки товара;
• добавление товара в корзину;
• переход к оформлению;
• авторизацию;
• создание заказа;
• доступность критического API.

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

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

При этом успешный smoke-тест не означает, что релиз полностью проверен. Он подтверждает только базовую работоспособность.

Новая функция работает — почему этого недостаточно

Изменённая функциональность редко существует изолированно. Поэтому после проверки самой задачи нужно провести impact analysis — оценить, какие связанные части системы могло затронуть изменение.

Например, команда изменила применение промокода. Проверить только поле ввода кода недостаточно. Изменение может повлиять на:

• итоговую цену;
• другие скидки;
• стоимость доставки;
• платёж;
• данные заказа;
• передачу заказа в 1С или ERP.

Другой пример — изменение профиля пользователя. Если его данные используются при оформлении документов, заказов или уведомлений, эти сценарии тоже попадают в область риска.

Поэтому правильный вопрос звучит не только как «работает ли новая функция?», но и как «что ещё могло сломаться из-за этого изменения?».

Как сократить регрессионное тестирование, если времени мало

Regression testing — регрессионное тестирование — проверяет, не нарушили ли новые изменения ранее работавшие функции.

Если полного регресса выполнить нельзя, его стоит сокращать не по количеству тестов, а по рискам.

В приоритетный набор включают:

1. критические пользовательские пути;
2. области, напрямую затронутые изменениями;
3. связанные функции;
4. сценарии с высокой ценой ошибки;
5. исторически нестабильные части продукта;
6. часто используемые функции;
7. критические интеграции;
8. сценарии, которые уже ломались при похожих изменениях.

Плохой вариант — открыть общий набор из 800 тест-кейсов и выполнить первые 150.

Более рациональный — заранее сформировать отдельный релизный набор, который охватывает критические процессы и наиболее рискованные зоны.

Универсального процента, до которого можно безопасно сократить регрессию, не существует.

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

Одна из опасных ситуаций — исправить критический дефект непосредственно перед релизом и проверить только его исходный сценарий.

После такого изменения нужно:

1. убедиться, что первоначальный дефект действительно устранён;
2. понять, какой код или бизнес-процесс был изменён;
3. определить связанные функции;
4. повторно проверить их;
5. при необходимости снова выполнить часть smoke или регрессии.

Это не означает, что после каждого исправления нужен полный регресс. Объём повторной проверки должен соответствовать потенциальному влиянию изменения.

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

Какие интеграции нельзя забывать перед релизом

В сложных проектах интерфейс может работать корректно, хотя основной процесс уже нарушен из-за сбоя обмена данными.

Особого внимания могут требовать:

• 1С;
• CRM;
• ERP;
• платёжные системы;
• службы доставки;
• внешние API;
• системы авторизации;
• email- и SMS-уведомления;
• телефония;
• внутренние сервисы.

Интеграцию нужно проверять не только по факту отправки запроса.

Например: сайт создал заказ → данные передались в 1С → 1С корректно их обработала → статус вернулся на сайт → пользователь увидел правильный результат.

Ошибка на любом этапе способна нарушить процесс, хотя отдельные элементы системы продолжают работать.

Если проекту не хватает собственных QA-, DevOps- или разработческих ресурсов для регулярной проверки таких сценариев, часть задач может закрываться через IT-аутсорсинг с подключением необходимых специалистов.

Платежи, авторизация и данные: когда риск особенно высок

Некоторые области требуют повышенного внимания из-за последствий возможной ошибки.

Нужно ли проверять все браузеры и устройства перед срочным релизом

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

В первую очередь проверяются:

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

Источником для выбора может служить аналитика проекта.

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

Если определённая платформа почти не используется и изменения её не затрагивали, при срочном релизе она может получить более низкий приоритет. Это решение должно быть осознанным и зафиксированным, а не случайным.

Какие ошибки должны блокировать релиз

Релиз обычно требует остановки или отдельного решения ответственных лиц, если дефект:

ломает основной пользовательский сценарий;

приводит к потере или повреждению данных;

блокирует оплату или оформление ключевой операции;

нарушает разграничение доступа;

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

ломает критическую интеграцию;

создаёт неприемлемый риск безопасности;

не имеет приемлемого обходного решения.

При этом сам факт существования бага ещё не означает автоматическую отмену релиза.

Важно учитывать:

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

Можно ли выпускать продукт с известными ошибками

Иногда релиз с известными дефектами допустим. Главное — чтобы это было сознательное решение, а не ситуация, когда часть команды просто не знает о проблеме.

Для каждого существенного дефекта перед решением о выпуске желательно понимать:

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

Кто принимает решение go/no-go

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

Go/no-go — решение выпускать или не выпускать релиз — принимается на основе совокупности этой информации.

Важно отдельно проговорить и непроверенный объём. Фраза «критичных багов не найдено» не равнозначна фразе «критичных багов нет», если часть критической области вообще не успели проверить.

Что предусмотреть перед самой выкладкой

Даже хорошо протестированную сборку можно некорректно доставить на рабочий сервер.

Перед выкладкой желательно подтвердить:

• Версию сборки;
• Фактический состав релиза;
• Необходимые миграции;
• Настройки окружения;
• Последовательность deployment;
• Ответственных участников;
• Способ возврата к предыдущему состоянию;
• Готовность мониторинга.

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

CI/CD — автоматизированные процессы сборки, проверки и доставки изменений — может уменьшить количество ручных операций и запускать часть проверок ещё до последнего этапа релиза.

Что проверить сразу после релиза на production

Production — рабочая среда, которой пользуются реальные пользователи.

После выкладки нужен короткий post-release smoke: проверка того, что приложение развернулось корректно именно в рабочем окружении.

По ситуации проверяются:

• Доступность продукта;
• Авторизация;
• Основной пользовательский сценарий;
• Формы;
• Создание заказа или заявки;
• Платежи;
• Критические интеграции;
• Корректность сохранения данных;
• Фоновые процессы;
• Ошибки в логах и системах мониторинга.

Не все операции безопасно выполнять непосредственно на production. Для некоторых проектов заранее создаются тестовые аккаунты, специальные заказы или другие контролируемые механизмы проверки.

После релиза особенно важна связка QA, разработки и эксплуатации. При проектах с повышенными требованиями к доступности этот процесс может входить в техническую поддержку по SLA, где команда продолжает контролировать работу продукта после запуска.

Что отслеживать в первые часы после релиза

Тестирование заканчивается, а наблюдение за продуктом — нет.

В зависимости от архитектуры проекта после релиза контролируют:

• Рост технических ошибок;
• Ответы 4xx и 5xx;
• Состояние сервисов;
• Очереди и фоновые процессы;
• Ошибки интеграций;
• Количество успешных ключевых операций;
• Создание заказов;
• Платежи;
• Обращения пользователей;
• Аномальные изменения бизнес-метрик.

Универсального порога тревоги нет. Рост ошибок нужно сравнивать с нормальным состоянием конкретного продукта.

Особенно важно наблюдать за теми функциями, которые были изменены или получили ограниченный объём предрелизного тестирования.

Как снизить риск срочных релизов в будущем

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

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