Как искать и анализировать проблему при неработающей авторизации по номеру телефона в мобильном приложении
Что проверяют
Умеете ли вы локализовать проблему, а не просто завести баг «вход не работает». Интервьюеру важно, в каком порядке вы сужаете круг: клиент, сеть, бэкенд, внешний СМС-провайдер. Следом часто спрашивают, какие данные вы приложите к баг-репорту и что будете делать, если воспроизвести не удаётся.
Как отвечать
Постройте ответ как воронку от общего к частному:
- масштаб: у всех или у части пользователей. Смотрите разрез по платформе, версии приложения, оператору, стране. Если сломалось у всех после релиза, это одна история, если только у абонентов одного оператора, совсем другая;
- воспроизведение: чистая установка, разные номера, формат с
+7, с восьмёркой, с пробелами и скобками, вставка из буфера, автоподстановка кода из СМС; - трафик: прокси вроде Charles или Proxyman с установкой сертификата на устройство. Смотрите, уходит ли запрос на отправку кода, какой статус и тело ответа, принимается ли код при проверке;
- логи: Logcat в Android Studio, консоль Xcode или Console.app для iOS, логи бэкенда по идентификатору запроса, статус доставки у СМС-шлюза;
- ограничения: лимит на повторную отправку, блокировка номера после нескольких неверных кодов, истёкший код, неверное время на устройстве;
- окружение: не перепутан ли стенд, актуален ли конфиг, не сломалась ли доставка пушей, если код приходит пушем.
Потом сравнение с эталоном: на прошлой сборке работает? Если да, это регрессия, и круг сужается до конкретного изменения. В баг-репорт идут шаги, тестовый номер, время запроса, версия приложения и ОС, запрос и ответ из прокси.
Где спотыкаются
Проверяют только интерфейс и сразу пишут «не работает авторизация» без запроса и ответа сервера. Разработчику такой баг приходится расследовать заново.
Забывают о внешнем звене: СМС может не дойти из-за провайдера или оператора, и тогда приложение и бэкенд ни при чём.
Гоняют один и тот же тестовый номер до блокировки лимитами и принимают защиту от перебора за баг.