Чек-лист тестирования интеграции перед продакшном

Короткий ответ

Перед выходом в продакшн интеграция должна пройти восемь групп тестов: функциональные сценарии, данные и форматы, ошибки, дубли и повторные отправки, объём и лимиты, безопасность, мониторинг и уведомления, откат. Ожидаемый результат каждого теста записывается заранее, а итог фиксируется как «пройден / не пройден / не применимо». Бизнес-владелец и технический владелец письменно подтверждают итог. Тестирование диалогов чат-бота — отдельная работа; этот чек-лист проверяет сам поток данных между системами.

Зачем нужен чек-лист

Тестирование интеграции часто заканчивается словами «работает»: разработчик отправляет один тестовый лид, видит его в CRM, и работа считается сделанной. Проблемы всплывают в продакшне: у клиента с азербайджанской буквой «ə» в имени она превращается в символы, у ночного лида дата сдвигается на сутки, при обновлении CRM лиды теряются. Ничего из этого не видно в тесте «счастливого пути».

Чек-лист заставляет тестировать по письменному списку, а не по тому, что пришло в голову, и потом отвечает на вопрос «а мы это проверяли?».

1. Функциональные сценарии

• Обычный случай каждого бизнес-сценария: лид создаётся с правильными полями и назначается нужному менеджеру.
• Альтернативные случаи: клиент уже есть, номера нет, обращение с двумя намерениями.
• Смена статуса проходит в обе стороны, как ожидается.
• Ожидаемая задержка: событие появляется в приёмнике за согласованное время.

2. Данные и форматы

• Азербайджанские буквы — ə, ş, ç, ğ, ı, ö, ü — сохраняются в именах, адресах и заметках.
• Смешанный текст кириллицей и латиницей, эмодзи и длинные сообщения.
• Форматы телефона: 055…, +99455…, с пробелами и скобками.
• Дата и время: событие около полуночи, разница часовых поясов.
• Пустые поля: пустое в источнике поле не стирает правильное значение в приёмнике.
• Длинный текст: обрезается ли резюме длиннее лимита поля и как.

Как пишется карта полей, показано в статье о маппинге полей CRM.

3. Ошибки

• Приёмник не отвечает: запрос не теряется и повторяется.
• Тайм-аут: повтор не создаёт вторую запись.
• Ключ неверный или истёк: сразу приходит уведомление.
• Данные не проходят проверку (например, пустое обязательное поле): запрос уходит в очередь, и его видит человек.
• Превышен лимит (429): система ждёт и потом продолжает.

Правила этого поведения разобраны в статье об ошибках API и правилах повторов.

4. Дубли и повторные отправки

• Одно событие отправлено дважды — в приёмнике остаётся одна запись.
• Один клиент пришёл из двух каналов — правило работает, как ожидается.
• При двусторонней синхронизации изменение не возвращается и не создаёт бесконечный цикл.
• Два параллельных запроса пытаются создать одну запись — остаётся одна.

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

5. Объём и лимиты

Проведите короткий тест с объёмом в несколько раз больше ожидаемого дневного — например, имитируя день кампании. На что смотреть: растёт ли задержка, теряются ли запросы, достигается ли лимит другой стороны, как быстро разбирается очередь. Тест идёт в тестовой среде, а не на рабочей системе.

6. Безопасность

• Тестовые и рабочие ключи разделены, ключей нет в коде.
• У учётной записи интеграции только нужные права.
• Адрес webhook не принимает запросы без подписи или ключа.
• В журнале нет лишних персональных данных.
• AI-инструменты обращаются только к разрешённым адресам.

7. Мониторинг и уведомления

До продакшна тестируются и сами уведомления: создайте искусственную ошибку и проверьте, что уведомление пришло нужному человеку в нужный канал. Панель мониторинга или отчёт должны показывать состояние интеграции: когда была последняя успешная доставка, сколько запросов в очереди, сколько ошибок за последний час.

8. Откат

Самый забываемый тест: как выключить интеграцию? План отката нужно проверить — интеграция останавливается одной кнопкой или настройкой, данные за это время не теряются (остаются в очереди или обрабатываются вручную), а при повторном включении очередь обрабатывается правильно. Непроверенный план отката может не сработать во время аварии.

Как записывать результат

1. 1ТестЧто проверяется и на каких данных.
2. 2Ожидаемый результатЗаписывается заранее, а не после теста.
3. 3Фактический результатПройден, не пройден, не применимо — с доказательством (скриншот, запись журнала).
4. 4РешениеДля непройденного теста: исправление, принятие риска (с причиной) или перенос запуска.
5. 5ПодписьПисьменное подтверждение бизнес- и технического владельцев.

Иллюстративный пример

Это иллюстративный пример. Интеграция чата с CRM в страховом агентстве проходит функциональные тесты. В группе данных находят две проблемы: имя клиента с азербайджанскими буквами отображается в CRM искажённым, а лид, созданный в 23:50, попадает на следующий день. Тест отката показывает, что для отключения интеграции нужен разработчик.

Вносят три исправления: кодировка, часовой пояс и настройка паузы интеграции в панели. Только после этого чек-лист подписывают и интеграцию запускают.

Типичные ошибки

• Один тест «счастливого пути».
• Записывать ожидаемый результат после теста.
• Не проверять азербайджанские буквы и часовые пояса.
• Не тестировать уведомления.
• Не тестировать план отката.

Ограничения

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

Интеграция с Vexvon

При интеграции с Vexvon каналы до выхода в рабочий режим проверяются тестовыми диалогами, тестовые диалоги виджета сайта не попадают в отчёты, а маршрутизация звонков проверяется симуляцией. Для webhook и API компании тестовый чек-лист — какие сценарии, какие ошибки и критерии приёмки — пишем вместе в плане интеграции. Подробнее — интеграции.

Следующий шаг

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