Что делать при краше приложения?
Что проверяют
Что вы делаете в первые минуты: соберёте артефакты, по которым разработчик воспроизведёт падение, или принесёте фразу «приложение падает». Заодно смотрят, отличаете ли вы падение от зависания и умеете ли оценить масштаб, чтобы выставить приоритет по влиянию, а не по эмоции.
Как отвечать
Сначала зафиксировать состояние, пока оно не потеряно: снять логи устройства (adb logcat на Android, системная консоль на iOS), достать стектрейс из отчёта о падении, сохранить запись экрана, отметить точное время с часовым поясом. Записать окружение: версия и номер сборки, отладочная она или релизная, модель устройства, версия ОС, сеть, учётная запись.
Потом воспроизвести и сузить:
- повторяется ли по тем же шагам и с какой частотой, например три раза из пяти;
- держится ли на чистой установке. Если падает только поверх обновления, речь о миграции данных, а это другой дефект;
- регрессия ли это: поставить предыдущую сборку и проверить там же, так находится момент появления;
- зависит ли от условий: мало памяти, возврат из фона, обрыв сети, отсутствие разрешений.
В баг-трекер дефект уходит со стектрейсом, шагами, окружением, частотой и оценкой влияния: падение на входе или оплате это блокер, редкое падение в служебном экране нет. Если сборка уже у пользователей, добавьте долю сессий без падений и то, кого нужно предупредить.
Где спотыкаются
Приносят падение без стектрейса. Скриншот и пересказ не помогают: без стека разработчик начинает с нуля, и дефект возвращается с вердиктом «не воспроизводится».
Второе: называют падением всё подряд. Зависший интерфейс, принудительная остановка системой по таймауту и тихий выход без ошибки имеют разные причины, а в одной задаче они отправляют исправление не по адресу.
Третье: проверяют на одном устройстве и делают вывод о продукте. Падение часто завязано на версию ОС, объём памяти или язык системы, поэтому в дефекте нужна выборка устройств, а не единственный личный телефон.