Что за сервис на стороне получения запросов
Что проверяют
Это уточнение по ходу вашего рассказа про интеграции. Собеседник хочет понять, знаете ли вы, куда уходят запросы, которые вы отправляли, и можете ли описать чужую сторону: кто принимает, по какому контракту, синхронно или через очередь. Так отделяют тестировщика, который понимал систему, от того, кто прогонял готовую коллекцию запросов.
Как отвечать
Назовите роль приёмника и то, что знаете про контракт:
- что это за сервис: внутренний сервис своего домена, шлюз API, адаптер к внешней системе партнёра, обработчик вебхуков;
- протокол и описание: REST со спецификацией, gRPC со схемой, SOAP у старых интеграций, сообщения через брокер;
- синхронность: отдаёт ли он результат сразу или только подтверждение приёма, и где тогда искать итог: статус, колбэк, очередь;
- аутентификация: токен, подпись тела запроса, взаимный TLS, ограничение по адресам;
- что проверяли вы: валидацию полей, коды ошибок, таймауты и повторные отправки, идемпотентность по ключу, дубли и порядок сообщений;
- как тестировали без доступа к чужой стороне: заглушка, песочница партнёра, контрактные тесты.
Не знаете деталей, так и скажите: внутреннюю реализацию не видел, работал по контракту, вот что в нём было. Это сильнее выдумки.
Где спотыкаются
Отвечают «ну, сервер» и замолкают. Звучит так, будто запросы отправлялись по инструкции, а что с ними происходит дальше, кандидата не интересовало.
Придумывают архитектуру на ходу: брокер, балансировщик, кэш, хотя ничего этого не видели. Одного уточняющего вопроса про то, как устроена повторная доставка, хватает, чтобы это вскрылось.
Описывают только успешный путь. От тестировщика ждут рассказ про поведение приёмника при повторе, таймауте, битом теле и просроченном токене; без идемпотентности и ретраев опыт интеграционного тестирования считают поверхностным.