Фильтр неизвестных звонков может изменить то, как телефон показывает входящий вызов: заглушить его, отправить в отдельный список или пометить как нежелательный. Поэтому клиент не всегда замечает звонок, хотя система авторизации его инициировала. Чтобы найти причину отказов, проверьте настройки телефона, сценарий ввода кода и журналы OTP отдельно. Ниже — план тестирования для бизнеса: он поможет отличить проблему доставки от ошибки интерфейса или слишком короткого времени на подтверждение.
Что именно может изменить фильтр звонков?
Flash Call подтверждает номер через входящий вызов: пользователь принимает последние цифры номера или код, предусмотренный сценарием. На телефоне с фильтром неизвестных вызовов входящий звонок может отображаться не так, как обычный вызов. Точное поведение зависит от настроек устройства и используемого программного обеспечения, поэтому нельзя считать один тест на одном телефоне проверкой для всех клиентов.
Разделяйте три события: запрос кода, попытку вызова и ввод кода. Если звонок не появился на экране, это ещё не доказывает, что сервис не инициировал вызов. И наоборот: запись о попытке в системе не подтверждает, что пользователь увидел нужные цифры. Фиксируйте для каждого шага время, статус и результат.
Для понимания сценариев фильтрации полезно отдельно проверить, почему вызов может распознаваться как спам: как проверить распознавание Flash Call как спама.
Как проверить Flash Call на телефонах клиентов?
Соберите небольшую тестовую матрицу из устройств, которые реально используют ваши клиенты. Включите в неё разные модели телефонов и операционные системы, а также варианты с включённым и выключенным фильтром неизвестных вызовов. Если бизнес обслуживает пользователей с двумя SIM-картами или eSIM, добавьте такие конфигурации отдельно: активная линия и настройки звонков могут отличаться.
- На каждом устройстве запросите подтверждение номера в тестовом сценарии.
- Запишите, появился ли входящий вызов на экране, в журнале вызовов или в папке нежелательных.
- Проверьте, смог ли пользователь найти цифры для подтверждения и завершить вход.
- Повторите тест с другим состоянием фильтра, не меняя остальные настройки.
- Сопоставьте наблюдения с журналом запросов и статусами доставки в вашей системе.
Проводите проверки на номерах, которыми участники теста вправе пользоваться. Не просите их отключать защитные функции постоянно: для диагностики достаточно сравнить два состояния настроек и вернуть исходный режим после проверки. Готовый план запуска поможет последовательно проверить устройства и сценарии: тест-план Flash Call перед запуском в Беларуси.
Как отличить сбой фильтра от ошибки в OTP-сценарии?
Сравните, на каком шаге прекращается пользовательский путь. Если запрос создан, но вызов не отражён в наблюдениях тестировщика, проверьте доступность звонка и настройки фильтра. Если вызов виден, но пользователь не завершает подтверждение, проверьте инструкцию на экране, формат кода и срок его действия. Если код введён, но система его отклоняет, изучите серверную проверку и связь кода с конкретным запросом.
| Наблюдение | Что проверить | Следующий шаг |
|---|---|---|
| Пользователь не заметил вызов | Фильтр неизвестных звонков, список нежелательных, журнал вызовов | Повторить тест с изменённым состоянием фильтра |
| Вызов отображается, но код не вводят | Текст подсказки и понятность инструкции | Уточнить, какие цифры нужно взять из номера |
| Код введён, но подтверждение не проходит | Срок действия, привязку к запросу, число попыток | Сопоставить ввод с записью проверки OTP |
| Повторные запросы возникают после ожидания | Время ожидания и сообщение о ходе проверки | Проверить, когда интерфейс предлагает новый запрос |
Не ставьте диагноз по одной жалобе. Сопоставьте одинаковые сценарии на нескольких устройствах и повторите тест после изменения только одного параметра. Так вы увидите, связан ли отказ с фильтром или с другим этапом авторизации.
Какие ошибки мешают диагностике?
- Считать запись о создании вызова подтверждением, что клиент его увидел.
- Проверять только один телефон и переносить результат на всю аудиторию.
- Одновременно менять фильтр, текст подсказки и срок действия кода.
- Не различать статусы «запрос создан», «вызов замечен» и «код принят».
- Предлагать повторный запрос без проверки, завершился ли предыдущий сценарий.
Если тесты показывают, что часть пользователей не замечает вызов, предусмотрите понятный запасной путь: например, повторную попытку или другой канал подтверждения, если он поддерживается вашей системой. Ограничьте частоту запросов и проверок, а журналы используйте для поиска конкретного сбойного шага. Для внедрения такого сценария в продукте заранее опишите события, которые API должен передавать между интерфейсом и системой авторизации.
Начните с короткой проверки: выберите несколько устройств, сравните работу с фильтром и без него, затем сопоставьте результат с журналом OTP. Если проблема повторяется только в одной конфигурации, добавьте её в тесты перед выпуском обновлений.
