Приведи пример статуса Blocked

Статус Blocked в процессе тестирования

В жизненном цикле задачи тестирования (бага или тест-кейса), статус Blocked (или «Заблокирован») присваивается, когда выполнение действия по задаче невозможно из-за внешних факторов, которые не зависят от тестировщика. Этот статус критически важен для управления процессом, так как он четко сигнализирует о возникшем препятствии и останавливает напрасную трату времени.

Пример из реальной практики

Представьте, что я, как QA Engineer, работаю над проверкой функции «Оформление заказа» в интернет-магазине. Мой тест-кейс включает шаг: «после добавления товара в корзину, перейти к оплате, используя тестовую кредитную карту с номером 4111 1111 1111 1111».

В процессе выполнения я сталкиваюсь со следующей ситуацией:

1. Я добавляю товар в корзину и нажимаю «Перейти к оплате».
2. Страница оплаты не загружается. Вместо этого появляется всплывающее окно с ошибкой: «Платежный шлюз временно недоступен. Попробуйте позже».
3. Я повторяю попытку несколько раз, пробую разные браузеры, очищаю кэш – проблема сохраняется.
4. Я проверяю статус мониторинга платежной системы и вижу, что она действительно проводит плановые технические работы.

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

Действия тестировщика при установке статуса Blocked

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

• Детальное описание блокировки: В комментарии к задаче я четко указываю причину.

  **Статус: BLOCKED**
  **Причина:** Не удается протестировать сценарии оплаты, так как интеграция с платежным шлюзом X не работает.
  **Детали:** На шаге перехода на страницу /checkout/payment система возвращает ошибку 503 от сервиса payment-gateway-x.com. В логах команды разработки подтверждены сбои на стороне внешнего провайдера. ETA на восстановление – 2 часа.
  **Заблокированные тест-кейсы:** TC-101, TC-102, TC-150.
  

• Приоритизация: Я временно переключаюсь на другие, независимые задачи. Например, на тестирование функциональности личного кабинета или проверку UI/UX других разделов.
• Коммуникация: Я уведомляю о блокировке тимлида тестирования и менеджера проекта, чтобы они были в курсе задержек.
• Мониторинг: Я подписываюсь на обновления инцидента и периодически проверяю, восстановилась ли работа шлюза, чтобы снять статус Blocked и возобновить работу.

Отличие Blocked от других статусов

Важно не путать этот статус со смежными:

• Failed (Провален): Задача может быть выполнена, но обнаружен дефект. Например, платежная страница загружается, но при вводе валидной карты возникает ошибка валидации. Здесь я могу продолжить исследование и задокументировать баг.
• On Hold (На удержании): Задача приостановлена по внутренним, часто плановым или приоритетным причинам (например, релиз отложен, требуются уточнения от аналитика). Blocked же почти всегда связан с внешней технической невозможностью выполнить шаги.

Еще несколько типичных примеров статуса Blocked

• Зависимость от другого критического бага: Невозможно проверить печать документа (функция Б), потому что само создание этого документа (функция А) падает с ошибкой 500 (баг PROJ-123).
• Отсутствие тестовых данных или доступов: Для проверки роли «Супер-администратор» нужны специальные учетные данные, которые еще не предоставлены.
• Проблемы со средой: Тест-сервер упал, база данных не отвечает, или на стенде развернута не та версия приложения.
• Блокировка внешним сервисом: Функционал отправки email зависит от работоспособности почтового сервера SMTP, который временно отключен.

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