Что делать, если вылетело мобильное приложение

Алгоритм действий при вылете мобильного приложения

Когда мобильное приложение неожиданно завершает работу (крашится), это критический инцидент, требующий системного подхода к исследованию и исправлению. Как опытный QA-инженер, я следую чёткому протоколу, чтобы не только зафиксировать факт падения, но и собрать максимум информации для разработчиков, что значительно ускоряет процесс дебаггинга.

1. Немедленная первичная фиксация и воспроизведение

Первое, что я делаю — пытаюсь понять контекст и стабильность бага.

• Фиксация условий падения: Запоминаю или записываю, какое действие привело к краху (тап по кнопке, переход между экранами, ввод данных, поворот устройства, приход уведомления и т.д.).
• Проверка воспроизводимости: Пытаюсь повторить те же шаги.

    *   **Стабильный баг:** Если падение воспроизводится каждый раз — это хорошо для анализа.
    *   **Плавающий баг:** Если падение происходит не всегда, это сложнее. В этом случае я повторяю сценарий многократно, меняя внешние условия (сила сигнала сети, свободная память, запущенные фоновые приложения), чтобы найти закономерность.

2. Сбор и анализ логов (Ключевой этап)

Логи — основной источник информации для разработчика. Я собираю их всеми доступными способами.

Для Android (Android Studio/Logcat):

# Пример фильтрации логов по тегу приложения и уровню ERROR через ADB
adb logcat -v time MyAppTag:E *:S

# Или сохранение полного лога в файл для последующего анализа
adb logcat -v time > crash_log.txt

В Logcat я ищу строки с уровнем FATAL, ERROR и AndroidRuntime, особенно стектрейс исключения (Java/Kotlin StackTrace), который точно указывает на строку кода, вызвавшую проблему.

Для iOS (Xcode/Console):

• Подключаю устройство к Mac, запускаю приложение через Xcode и смотрю логи в панели Console.
• Ищу краш-репорты (Crash Reports) в разделе Window -> Organizer -> Crashes или в самом устройстве (Settings -> Privacy & Security -> Analytics & Improvements -> Analytics Data). Имена файлов обычно содержат название приложения и дату. Ключевая информация содержится в бэктрейсе (backtrace).

3. Детальное описание баг-репорта

В тикет (в Jira, YouTrack и т.д.) я вношу исчерпывающую информацию, структурируя её:

1. Заголовок: Кратко и ясно. Пример: [Crash]: Приложение вылетает при нажатии "Отправить" в форме обратной связи на слабом интернете.
2. Шаги воспроизведения: Максимально детальные и последовательные.
3. Фактический результат: "Приложение аварийно завершает работу с выходом на домашний экран устройства".
4. Ожидаемый результат: "Приложение должно отобразить тост 'Сообщение отправлено' или показать информационное сообщение об ошибке сети".
5. Окружение (Environment): Это критически важный раздел:

    *   **Версия приложения:** `2.5.1 (build 742)`.
    *   **Тип сборки:** `Debug/Release`, `Production`.
    *   **Устройство и ОС:** `iPhone 12 Pro, iOS 16.5.1` / `Google Pixel 6, Android 13`.
    *   **Сеть:** `Wi-Fi / 3G`.
    *   **Свободная память (RAM) и хранилище:** Особенно если приложение ресурсоёмкое.
    *   **Активность других приложений:** Были ли запущены тяжёлые фоновые процессы.

1. Вложения (Attachments):

    *   **Полные логи** (текстовый файл или скриншот ключевой части).
    *   **Скриншот/Видео падения.** На iOS можно использовать `Screen Recording`, на Android — встроенные средства или `adb shell screenrecord`.
    *   **Снимок экрана (Screenshot)** за момент до падения.
    *   Для плавающих багов — **указание частоты воспроизведения** (например, `3 раза из 10 попыток`).

4. Использование продвинутых инструментов и гипотез

На основе опыта я могу выдвигать первоначальные гипотезы для разработчиков:

• Утечка памяти (OOM - Out Of Memory): Частая причина на старых устройствах или при работе с большими изображениями. Мониторинг через Instruments (iOS) или Android Profiler.
• Работа с потоками (Threading Issue): Попытка обновления UI не из главного потока (NetworkOnMainThreadException на Android).
• Проблемы с нативными библиотеками или зависимостями: Особенно в кроссплатформенных проектах (React Native, Flutter).
• Коррупция данных или состояние гонки (Race Condition).
• Ошибки в обработке жизненного цикла активности/вьюконтроллера.

5. Коммуникация и пост-релизный мониторинг

После отправки отчёта:

• Обсуждаю баг с разработчиком, чтобы убедиться, что логи понятны и контекст ясен.
• После того как разработчик выпускает фикс, я провожу регрессионное тестирование не только на сценарии краша, но и на связанной функциональности.
• Рекомендую настроить системы краш-репортинга для продакшена, такие как Firebase Crashlytics, Sentry или Instabug. Эти инструменты автоматически собирают анонимизированные данные о падениях у реальных пользователей, агрегируют их и предоставляют стектрейсы, что бесценно для обнаружения "плавающих" и аппаратно-зависимых багов.

Итог: Моя задача как QA — не просто констатировать факт "приложение упало", а провести мини-расследование, превратив неочевидный сбой в технически документированный инцидент с конкретными координатами для быстрого исправления. Качественный баг-репорт о краше экономит команде часы, а иногда и дни работы.