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