Інтеграція Instabug для відстеження багів мобільного додатку

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

Як 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 — потужний інструмент mobile bug tracking.

Чому Instabug вартий уваги?

Instabug в 4 рази швидше за ручний збір логів і забезпечує в 4 рази більше контексту. Це доведено нашими інтеграціями для FinTech, E-commerce та HealthTech.

Що входить в роботу з інтеграції 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% робочого часу на перезапуск та аналіз хибнонегативних збоїв. Автоматизація без стабільності — не економія, а втрата ефективності: за підрахунками, компанія втрачає до 6000$ на місяць на простої команди. Ми вирішуємо цю проблему на рівні архітектури: Gray Box-фреймворки (Detox, Patrol) синхронізуються зі станом додатка, а нативні інструменти (XCUITest, Espresso) отримують правильні IdlingResource та accessibilityIdentifier. Результат: стабільність >99.5% на CI — це в 3 рази краще за середній показник по ринку. Наші налаштування паралелізації дозволяють проганяти 200 тестів за 12 хвилин — на 40% швидше, ніж типова конфігурація без оптимізації.

Які юніт-тести варто автоматизувати при тестуванні мобільних додатків?

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

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

Чому стабільність 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 на етапі аудиту.

Приклад налаштування IdlingResource для OkHttp на Android:

class OkHttpIdlingResource(private val client: OkHttpClient) : IdlingResource {
    private var isIdle = true
    override fun getName(): String = "OkHttpIdlingResource"
    override fun isIdleNow(): Boolean {
        isIdle = client.dispatcher.runningCallsCount() == 0
        return isIdle
    }
    override fun registerIdleTransitionCallback(callback: IdlingResource.ResourceCallback?) {}
}
// Реєстрація в тестовому підготовчому коді:
IdlingRegistry.getInstance().register(OkHttpIdlingResource(okHttpClient))

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

Detox — E2E фреймворк для React Native, розроблений Wix. Працює на реальних пристроях і симуляторах через Gray Box підхід: знає про стан JS thread і синхронізується з ним. Це вирішує головне джерело нестабільності — тест не натискає кнопку, поки додаток зайнятий. Налаштування 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. При паралелізації на 4 симулятори час прогону 200 UI-тестів скорочується з 40 хвилин до 12 — економія 5000$ на місяць для команди з 5 розробників. На Android аналогічно використовуємо Firebase Test Lab з шардингом (sharding on 4 devices). Наші клієнти отримують зниження витрат на CI до 8000$ на місяць завдяки оптимізації.

Типові помилки налаштування тестів

Як ми це робимо: процес роботи

1. Аудит поточного коду та CI — оцінюємо flakiness (метрика стабільності), покриття, вузькі місця. Використовуємо Allure для збору звітів і Xcode Report для iOS.
2. Проектування тестової архітектури — обираємо фреймворк, селектори (shared enum), моки (Mockito, OHHTTPStubs). Визначаємо шари: unit → UI → E2E.
3. Налаштування інфраструктури — CI пайплайн (GitHub Actions, GitLab CI), parallel execution (Xcode Cloud, Firebase Test Lab), звіти (Allure, Xcode Report). Додаємо метрики: час прогону, кількість flaky-тестів.
4. Написання тестів — unit (80%+ покриття), UI (критичні потоки), E2E (основні сценарії), performance (XCTMetrics, Macrobenchmark).
5. Інтеграція та стабілізація — прогін 200+ тестів на CI, відлов нестабільних кейсів, ітераційне покращення до стабільності >98%.
6. Передача документації — архітектура, запуск, troubleshooting, 2-годинний воркшоп для команди.

Що входить в роботу (deliverables)

• Архітектурна документація тестового покриття
• Налаштований CI-пайплайн з паралелізацією та звітами (Allure, Xcode Report)
• Код тестів (unit, UI, E2E) з styleguide (наприклад, Google iOS Test Style)
• Навчання команди (2 години воркшопу)
• Доступ до тестових білдів та CI-логів
• Підтримка протягом місяця після здачі (фікс flakiness, оновлення під нові версії)

Терміни орієнтовно

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