Почему не предусматривалась проверка отсутствия сетевой связанности со сторонними системами
Что проверяют
Умеете ли вы честно разобрать пробел в покрытии: почему негативный сценарий с недоступностью внешней системы не попал в тесты и как его вообще воспроизводят. Это вопрос про тест-дизайн и работу с требованиями, а не про поиск виноватого.
Как отвечать
Сначала назвать причину. Чаще всего в требованиях не описано поведение при недоступности соседа: нет ожидаемого результата, значит проверять нечего. Второе: на стенде всё стоит в одной сети, прав резать трафик у команды нет, а вместо реальной системы отвечает песочница вендора, которая не умеет падать по команде.
Дальше то, что интервьюер и хочет услышать: как вы это закроете. Сначала договориться об ожидании вместе с аналитиком и разработчиком: таймаут, сколько повторов, что видит пользователь, что уходит в лог и в мониторинг. Без этого тест написать невозможно.
Потом инструменты. Подменить внешнюю систему стабом (WireMock и аналоги) и задать в нём задержку больше таймаута, обрыв соединения, ответ 5xx, битое тело. На уровне инфраструктуры отрезать сеть контейнеру или поставить прокси, который умеет рвать соединения.
И обязательно различать случаи: хост отказал сразу, пакеты уходят в никуда и ждём таймаут, соединение встало посреди чтения ответа, сервис ответил, но очень медленно. Для приложения это четыре разные ветки, и ломается оно обычно на последней.
Где спотыкаются
Отвечают, что это не зона тестирования. Пропуск проверки бывает осознанным решением, но тогда у него есть автор и записанный риск. Без этого ответ звучит как «мы не подумали».
Сводят всё к одному случаю: сервис лежит, пришла ошибка. Дороже всего обходится другое: сосед отвечает медленно, пул соединений кончается, встаёт весь сервис целиком. Повтор запроса без ограничения числа попыток опасен ровно так же.
Предлагают проверять доступность при старте приложения. Проверка на старте ничего не говорит о том, что будет через минуту, а сервис, который не поднимается из-за недоступного соседа, усиливает аварию вместо того, чтобы её пережить. Проверять надо поведение в момент запроса.