Ответ.

Ручное тестирование интеграций — это процесс проверки взаимодействия между разными модулями, сервисами или внешними системами вручную, без автоматических скриптов.

История вопроса:

На заре развития ИТ-продуктов все системы создавались монолитно, но с ростом масштабов компании и числа сторонних сервисов стали актуальны интеграционные тесты. Тестировщики стали задаваться вопросом: как удостовериться, что данные и действия корректно проходят между системами — например, что успешная оплата отражается и в биллинге, и в учетной системе.

Проблема:

Самая большая сложность — отсутствие полнофункциональной среды: интеграции могут зависеть от сторонних сервисов, нестабильных API или внешних ограничений. Кроме того, ручное тестирование на каждом стыке интеграции может быть очень трудоемким, легко допустить ошибку в последовательности шагов или упустить важное каскадное последствие.

Решение:

Используйте тестовые окружения с «заглушками» (mock/stub), чтобы гарантировать повторяемость теста.
Структурируйте тест-кейсы, прописывайте пошаговые проверки сообщений, логов, статусов.
В первую очередь проверяйте граничные случаи, таймауты, повторные попытки вызова интеграций, реакцию системы на отказы.

Ключевые особенности:

Необходимость понимания бизнес-логики обеих интегрируемых сторон.
Учет асинхронности и погрешностей передачи состояния.
Поддержка устойчивости к частичным сбоям.

Вопросы с подвохом.

Что такое тестовые двойники (test doubles) и зачем они нужны при ручном тестировании интеграций?

Тестовые двойники — это имитации интеграционных компонентов (например, mock, stub, fake). При ручном тестировании они нужны, чтобы отрабатывать сценарии, когда настоящая внешняя система недоступна или ее вызовы стоят денег.

Можно ли считать интеграцию протестированной, если тест-кейсы покрыли только happy path?

Нет. Необходимо обязательно тестировать edge cases: ошибки соединения, неверные форматы данных, timeouts, unexpected responses.

Достаточно ли проверить только отправку/получение данных или нужно что-то еще?

Важно проверять корректность СОДЕРЖИМОГО данных, их преобразование и поведение системы при различных ошибках на стыке.

Типовые ошибки и анти-паттерны

Работать только с "своей" частью системы, не проверяя поведение на стороне партнера.
Игнорировать негативные сценарии.
Не анализировать логи или не копить историю интеграционных ошибок.

Пример из жизни

Негативный кейс

Тестировщик проверяет интеграцию между CRM и системой биллинга только на успешное добавление заказа. Не проверяет ошибку синхронизации и пропуск транзакции.

Плюсы:

Быстрое покрытие основных сценариев.

Минусы:

Ошибка при сбое интеграции обнаружится только на реальных данных.

Позитивный кейс

Тестировщик создает набор тестов с отключением и включением интернет-соединения, с подстановкой невалидных токенов. Валидирует логи обеих сторон.