Интеграция Instabug для отслеживания багов мобильного приложения

Тестировщик нашёл баг. Он сделал скриншот в Telegram и написал текстом что делал. Разработчик не может воспроизвести — нет логов, информации об устройстве, сетевых запросов. По нашим данным, до 70% времени на баг уходит на сбор контекста. Вместо переписки мы внедряем Instabug: shake-to-report, скриншот с аннотациями, логи, данные устройства и сессии. После интеграции время обработки баг-репортов сокращается в 3–5 раз. Наша команда с 8+ лет опыта в мобильной разработке выполнила более 50 интеграций Instabug для клиентов из FinTech, E-commerce и HealthTech. Оценим ваш проект бесплатно — свяжитесь с нами.

Какие данные автоматически прикрепляются к репорту Instabug?

Instabug автоматически захватывает до 100 последних шагов пользователя (session replay), до 50 сетевых запросов с заголовками и телами, device info (модель, OS, версия приложения), память и CPU за последние 30 секунд. Тестировщику остаётся только описать что не так — и через 5 минут разработчик видит полную картину. В 90% случаев репорт содержит достаточно информации для воспроизведения без дополнительных уточнений.

Сравнение поддержки платформ Instabug

Какие проблемы решает Instabug?

Instabug незаменим, когда баг проявляется только на редкой конфигурации: iOS 16.3 в locale en-US или Android 12 с кириллицей в инпуте. Разработчик сразу видит device info и логи. Особенно полезен для network race condition: Instabug сохраняет все запросы, даже если соединение обрывается. Наш опыт показывает сокращение времени на баг-репорты на 60–70%. Например, у клиента из FinTech баг проявлялся только на Android 12 с кириллицей в поле ввода суммы. Instabug зафиксировал device info и сетевой запрос — оказалось, сервер возвращал 400 из-за неверной кодировки. Без Instabug отладка заняла бы 2 дня, а с ним — 2 часа.

Интеграция Instabug: пошаговое руководство

Шаг 1: Добавление SDK в проект

Для iOS используйте CocoaPods или SPM, для Android — Gradle. Instabug поддерживает Swift 5.9+, Kotlin 1.9+ и Flutter/React Native через официальные плагины. Для Android обязательно добавьте правила сохранения Instabug классов в proguard-rules.pro:

-keep class com.instabug.** { *; }

Шаг 2: Инициализация с токеном

iOS (Swift):

// AppDelegate.swift
import Instabug

func application(_ application: UIApplication,
                 didFinishLaunchingWithOptions launchOptions: [UIApplication.LaunchOptionsKey: Any]?) -> Bool {
    Instabug.start(withToken: "YOUR_APP_TOKEN", invocationEvents: [.shake, .screenshot])
    Instabug.welcomeMessageMode = .disabled  // убираем онбординг для тестировщиков
    NetworkLogger.enabled = true
    return true
}

Android (Kotlin):

// Application class
override fun onCreate() {
    super.onCreate()
    Instabug.Builder(this, "YOUR_APP_TOKEN")
        .setInvocationEvents(InstabugInvocationEvent.SHAKE, InstabugInvocationEvent.SCREENSHOT_GESTURE)
        .build()
    NetworkLogger.setEnabled(true)
}

Для перехвата сетевых запросов на Android — OkHttp interceptor:

val client = OkHttpClient.Builder()
    .addInterceptor(InstabugOkhttpInterceptor())
    .build()

Шаг 3: Настройка обфускации чувствительных данных

Instabug логирует сетевые запросы полностью. Если API передаёт пароли или токены в теле — нужно настроить blacklist:

NetworkLogger.addIgnoredURL(URL(string: "https://api.example.com/auth")!)

Или маскировать конкретные поля через кастомный response sanitizer.

Шаг 4: Настройка окружений

Используйте отдельные токены для Debug, Staging и Release. В Debug включайте полное логирование и session replay, в Release — только краш-репорты. Это уменьшает шум и ускоряет поиск критических багов.

Почему важно настроить Instabug под рабочий процесс?

Без правильной настройки Instabug может захламлять дашборд тестовыми репортами. Настройка репорт-темплейта с обязательными полями (приоритет, компонент, шаги воспроизведения) — залог порядка. Интеграция с Jira, GitHub Issues или Linear позволяет автоматически создавать тикеты с прикреплёнными логами. Мы настраиваем репорт-темплейт под ваш workflow и обучаем команду.

Как Instabug интегрируется с вашим стеком?

Instabug адаптируется под ваш цикл разработки. Мы настраиваем его для CI/CD: отдельные конфиги для Staging и Release, автоматическое включение NetworkLogger только для внутренних сборок. Это уменьшает шум и ускоряет поиск критических багов.

Что входит в работу по интеграции Instabug

• Установка и настройка SDK для iOS / Android / Flutter / React Native
• Конфигурация инициализации под все окружения (Debug, Staging, Release)
• Настройка перехвата сетевых запросов (OkHttp / URLSession)
• Обфускация чувствительных полей (пароли, токены)
• Интеграция с вашим баг-трекером (Jira, Linear, GitHub Issues)
• Настройка репорт-темплейта и кастомных invocation events
• Документация по работе с Instabug для команды
• Поддержка после внедрения

Сроки и стоимость

Базовая интеграция — от 1 дня. Расширенная (с интеграцией трекера, обфускацией, настройкой окружений) — до 5 дней. Стоимость рассчитывается индивидуально в зависимости от сложности конфигурации. Закажите консультацию — мы оценим ваш проект и предложим оптимальное решение.

Тестирование мобильных приложений: XCTest, Espresso, Detox и Appium

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

Почему flaky-тесты опасны?

Одна нестабильная проверка может завалить пайплайн, заблокировав релиз. Разработчики тратят 15-20% рабочего времени на перезапуск и анализ ложнонегативных сбоев. Автоматизация без стабильности — не экономия, а потеря эффективности. Мы решаем эту проблему на уровне архитектуры: Gray Box-фреймворки (Detox, Patrol) синхронизируются с состоянием приложения, а native инструменты (XCUITest, Espresso) получают правильные IdlingResource и accessibilityIdentifier. Результат: стабильность >99% на CI.

Unit-тесты: что тестировать, а что нет

На iOS XCTest — основа. Бизнес-логика в ViewModel, Interactor, UseCase — тестируется без проблем, если она не тянет UIKit. Типичная ошибка: логика в UIViewController напрямую — тогда unit-тест требует создания view-иерархии, что медленно и нестабильно. Выход — выносить логику в сервисы с @testable import.

Для асинхронного кода в Swift: XCTestExpectation для старого стиля, await + XCTest async для современного. С Combine — XCTestExpectation + sink, но удобнее использовать библиотеки типа CombineExpectations. На Android JUnit 4/5 + Mockito для unit-тестов, Coroutines Test для suspend-функций. runTest {} из kotlinx-coroutines-test — стандарт для ViewModel с StateFlow. Покрытие кода unit-тестами на уровне 80% сокращает время регрессии на 60% (данные наших проектов).

UI-тесты: стабильность важнее покрытия

XCUITest (iOS) и Espresso (Android) — нативные UI-тесты. Работают быстро, интегрированы с IDE, но тестируют одну платформу. Главная проблема XCUITest — хрупкость селекторов. app.buttons["Войти"] падает при смене локализации или рефакторинге accessibility label. Правильный подход: accessibilityIdentifier для тестируемых элементов, никогда не текстовые метки. Идентификаторы из shared enum — чтобы они не расходились между приложением и тестами. Опыт показывает: такая практика снижает flakiness на 90%.

Espresso на Android стабильнее из-за IdlingResource механизма — тест автоматически ждёт завершения background операций. Но кастомные async операции (OkHttp, кастомные Executors) нужно регистрировать в IdlingRegistry вручную, иначе тест не синхронизируется с сетевыми запросами. Мы гарантируем правильную настройку IdlingResource на этапе аудита.

Detox и Patrol: end-to-end для React Native и Flutter

Detox — E2E фреймворк для React Native, разработанный Wix. Работает на реальных устройствах и симуляторах через Gray Box подход: знает о состоянии JS thread и синхронизируется с ним. Это решает главный flakiness-источник — тест не нажимает кнопку, пока приложение занято. Настройка Detox нетривиальна. Требует специальный debug-билд с DetoxInstrumentsServer, конфигурации в package.json и отдельного Appium-сервера не нужно. Типичная проблема: тест стабилен на симуляторе, падает на реальном устройстве из-за анимаций. Решение — animations: disabled в Detox конфигурации для E2E билда.

Patrol — аналог для Flutter. Расширяет встроенный integration_test пакет и добавляет возможность взаимодействовать с нативными системными диалогами (permission prompts, notifications) — то, что flutter_driver и базовый integration_test не умеют. Для CI используется через patrol test --target integration_test/app_test.dart.

Appium: кроссплатформа с ценой

Appium — когда нужно покрыть iOS и Android одними тестами. Использует WebDriver протокол, поверх XCUITest и UiAutomator2 драйверов. Скорость ниже нативных фреймворков, но для команд без ресурсов на две тестовые кодовые базы — компромисс. Appium 2.x с плагинной архитектурой заметно удобнее первой версии. appium-doctor диагностирует окружение — полезен при настройке CI.

CI и параллелизация

Для параллельного запуска XCUITest используем Xcode Cloud или xcodebuild test-without-building с несколькими симуляторами через parallel-testing-enabled. Время прогона 200 UI-тестов с параллелизацией на 4 симулятора — с 40 минут до 12. На Android аналогично используем Firebase Test Lab с шардингом.

Типичные ошибки при настройке (и как их избежать)

Как мы это делаем: процесс работы

1. Аудит текущего кода и CI — оцениваем flakiness, покрытие, узкие места.
2. Проектирование тестовой архитектуры — выбираем фреймворк, селекторы, моки.
3. Настройка инфраструктуры — CI пайплайн, parallel execution, отчёты (Allure, Xcode Report).
4. Написание тестов — unit, UI, E2E, performance (XCTMetrics, Macrobenchmark).
5. Интеграция и стабилизация — прогон 200+ тестов, отлов flaky-кейсов.
6. Передача документации — архитектура, запуск, troubleshooting.

Что входит в работу (deliverables)

• Архитектурная документация тестового покрытия
• Настроенный CI-пайплайн с параллелизацией и отчётами
• Код тестов (unit, UI, E2E) с styleguide
• Обучение команды (2 часа воркшопа)
• Доступ к тестовым билдам и CI-логам
• Поддержка в течение месяца после сдачи (фикс flakiness, обновление под новые версии)

Сроки ориентировочно

Настройка инфраструктуры с нуля (CI, unit + UI тесты, отчёты) — 2-3 недели. Написание покрытия для существующего приложения — от 2 недель до месяца в зависимости от объёма. Оценим ваш проект за 2 дня — свяжитесь с нами. 5+ лет опыта в автоматизации, 50+ успешных проектов, сертифицированные специалисты по iOS/Android. Гарантируем стабильность тестов >98% на CI после внедрения.