Проводилось ли интеграционное тестирование со смежными системами и отделами
Что проверяют
Работали ли вы на стыке систем, где ошибка стоит дороже всего: чужой сервис, чужая команда, чужой релизный цикл. Смотрят и на технику, и на умение договариваться.
Как отвечать
Сначала назовите, с чем интегрировались: платёжный провайдер, очередь сообщений, сервис соседней команды, выгрузка в отчётность. Дальше по уровням.
- Контракт. Совпадение схем запроса и ответа, обязательность полей, версионирование. Контрактные тесты сообщают о поломке на сборке поставщика, а не на общем стенде через неделю.
- Сценарий целиком. Сквозной путь через обе системы на предпроде или в песочнице провайдера, с проверкой не только успеха, но и отказов.
- Окружение. Заглушки, когда соседней системы нет. Это честный способ проверить свою сторону, но живую проверку контракта он не заменяет.
Обязательно перечислите негативные проверки: таймаут, ответ с ошибкой, некорректное тело, повторная доставка одного сообщения, нарушенный порядок событий. Отсюда сам собой пойдёт разговор про идемпотентность и повторные попытки. Организационная часть тоже ответ: у каждой смежной системы есть контактное лицо, окно для тестов, тестовые учётные записи и договорённость предупреждать об изменении контракта.
Где спотыкаются
Называют интеграционным любой тест, который идёт через интерфейс и задевает всю систему. Уровень определяется тем, что именно проверяется, а не длиной сценария, и такая путаница слышна сразу.
Проверяют только успешный путь. В проде ломается обратное: сосед отвечает ошибкой, отваливается по таймауту, присылает то же событие дважды. Ничего этого нет в тестах, и первое же падение соседа становится инцидентом.
Живут на одних заглушках и не сверяют их с реальностью. Заглушка застывает на старой версии контракта, прогон зелёный, а интеграция сломана. Обратная крайность это общий стенд, где данные меняют другие команды, и все падения списывают на нестабильность.