Сервис, от которого зависит тест-кейс, недоступен. Какой результат выполнения зафиксировать и почему?
Зафиксируйте результат «заблокирован» или эквивалентный ему статус, а не «пройден» и не «провален». Проверка не дала свидетельств ни соответствия, ни несоответствия продукта ожидаемому результату: её выполнение остановила внешняя причина.
В комментарии укажите недоступную зависимость, время, наблюдаемое сообщение или симптом, затронутые проверки и условие, после которого тест можно повторить. Если недоступность самого сервиса является проверяемым поведением продукта, это уже отдельная проверка, которая может завершиться как «провалена».
В ручном тестировании статусы выполнения стали отделять от общего решения о качестве, чтобы не смешивать факт проверки с причиной, по которой она не завершилась. Иначе незапущенные или прерванные проверки могли ошибочно выглядеть как успешно пройденные либо как дефекты продукта.
Такое разделение поддерживает прозрачный учёт покрытия: команда видит, какие проверки действительно дали результат, а какие требуют повторного запуска после устранения препятствия.
Недоступность внешнего сервиса может быть вызвана окружением, сетью, тестовыми данными, правами доступа или самим продуктом. Приписать такой результат продукту без достаточных доказательств — значит создать ложный дефект; отметить проверку успешной — значит скрыть непроверенный риск.
Последствия особенно важны перед релизом. Если заблокированные проверки не выделены, команда может принять решение на основании завышенного покрытия и не заметить, что критичный сценарий фактически не был проверен.
Сначала определите, была ли достигнута точка, в которой можно оценить ожидаемый результат тестируемой функции. Если зависимость недоступна до этой точки и выполнение невозможно, используйте «заблокирован». Если проверка уже показала результат продукта, не соответствующий ожидаемому, это «провалена», даже если затем сервис стал недоступен.
В записи должны быть:
Не следует автоматически считать заблокированный тест дефектом продукта. Сначала нужно установить область ответственности: если отдельная проверка требует доступности сервиса, а сервис не входит в предмет тестирования, результатом основной проверки будет блокировка; если же требование продукта обещает корректно обработать недоступность зависимости, нужно отдельно проверить это поведение.
«Не выполнен», «заблокирован» и «отложен» могут называться по-разному в разных инструментах. Важен согласованный смысл: «заблокирован» означает наличие препятствия, а не отрицательный результат проверки.
После восстановления зависимости тест запускают заново в подходящем окружении. Предыдущая запись обычно сохраняется как история, а новый запуск получает самостоятельный результат, чтобы было видно, когда именно появилась доказательная информация.
При проверке оформления заказа тестировщик должен был убедиться, что после подтверждения пользователь видит номер заказа. Сервис оплаты был недоступен, поэтому подтверждение заказа невозможно было завершить.
Рассматривались три варианта. Отметить тест как пройденный было бы быстро, но это создало бы ложное покрытие. Отметить его как проваленный можно было бы только при доказательстве, что продукт неправильно обработал доступную ошибку; в данном случае до проверки этой реакции дело не дошло. Оставить тест без результата сохраняло бы неопределённость, но не показывало бы причину блокировки.
Выбрали статус «заблокирован», добавили сведения об инциденте с платёжным сервисом и отдельно запланировали проверку сценария корректной обработки его недоступности. После восстановления сервиса основной тест повторили; это позволило не смешать инфраструктурную проблему с результатом проверки оформления заказа.
Нет, если под покрытием понимается наличие фактического результата проверки. Связь теста с требованием может существовать в отчёте о планировании, но она не доказывает, что поведение продукта проверено. Заблокированные проверки нужно показывать отдельно и учитывать при оценке остаточного риска.
Если требование проверяет бизнес-функцию, а внешний сервис не дал выполнить сценарий, это блокировка основной проверки. Если требование прямо описывает реакцию продукта на отказ или недоступность сервиса и эта реакция наблюдаемо нарушена, тест провален. Ключевой критерий — была ли оценена функциональность относительно ожидаемого результата.
Нет. Дефект создают, когда есть основание считать причиной проблемы продукт или его контролируемое окружение. Для внешней аварии может быть достаточно ссылки на эксплуатационный инцидент; для ошибки конфигурации тестового окружения — обращения к ответственной команде. Если причина пока неизвестна, корректнее зарегистрировать наблюдаемую проблему с неопределённой областью ответственности и не объявлять её дефектом продукта без проверки.