Internal Testing: суть, як працює та як налаштувати трек

Що таке Internal Testing?

Internal Testing — це трек тестування в Google Play Console та TestFlight, призначений для поширення білдів серед учасників команди розробки. На відміну від відкритого бета-тестування, доступ до Internal Testing обмежений списком електронних адрес, затверджених власником облікового запису розробника.

Основна перевага — мінімальний час доставки білда тестувальникам. У Google Play Internal Testing не вимагає проходження модерації — білд з'являється в учасників через 5–15 хвилин після завантаження. В App Store через TestFlight білд також доставляється без попереднього App Review, але підлягає автоматичній перевірці на базові вимоги безпеки.

Чим Internal Testing відрізняється від інших треків

У Google Play існує три треки тестування: Internal Testing, Closed Beta (Open Beta) та Production. Internal Testing — найшвидший і обмежений за кількістю учасників (до 100 осіб). Closed Beta допускає до 10 000 учасників і вимагає налаштування сторінки тестування. Production — фінальний етап з повною модерацією.

Коли використовувати Internal Testing

Internal Testing застосовується для первинної перевірки білдів перед передачею на бета-треки. Розробники завантажують щоденні збірки для QA-команди, перевіряють інтеграцію нових SDK, тестують сумісність з різними версіями ОС та виявляють регресійні помилки до того, як білд побачать зовнішні тестувальники.

Internal Testing у Google Play

У Google Play Console Internal Testing — це окремий трек, доступний у розділі Release → Testing. Для додавання тестувальника достатньо вказати його електронну адресу — учасник отримує запрошення та посилання на приєднання через Google Play. Білди завантажуються через той самий інтерфейс, що й production-релізи.

Процес публікації у внутрішній трек

Розробник завантажує App Bundle або APK у розділ Internal Testing Google Play Console. Система перевіряє базові вимоги: підпис, версію коду та сумісність з API. Після 5–15 хвилин обробки білд стає доступним тестувальникам. Статус відстежується в консолі: Draft, In Review, Ready to Test.

// Fastlane — публікація в Internal Testing трек
lane :internal_testing do
    gradle(task: ":app:assembleRelease")
    
    upload_to_play_store(
        track: "internal",
        release_status: "completed",
        rollout: 1.0
    )
    
    slack(
        message: "Build uploaded to Internal Testing"
    )
end

Управління тестувальниками

Додавання учасників виконується через розділ Testers у Google Play Console. Доступне групове завантаження через CSV-файл. Кожен тестувальник отримує листа із запрошенням та інструкцією щодо встановлення. Для відкликання доступу достатньо видалити учасника з групи — встановлений застосунок продовжує працювати, але нові оновлення не надходять.

Internal Testing в App Store через TestFlight

В екосистемі Apple роль Internal Testing виконує TestFlight — платформа для поширення бета-версій. TestFlight підтримує до 100 внутрішніх тестувальників, які додаються за електронною поштою через App Store Connect. Для публікації білда не потрібно проходити повний App Review, але білд перевіряється автоматично на мінімальні вимоги.

Особливості TestFlight Internal Testing

На відміну від Google Play, де Internal Testing не вимагає модерації взагалі, Apple виконує автоматичну базову перевірку. Перевірка займає 30–60 хвилин і включає сканування бінарного коду на шкідливі API та дотримання базових вимог. Після успішної перевірки білд доступний тестувальникам протягом 24 годин. Термін дії білда — 90 днів.

Налаштування Internal Testing в App Store Connect

У App Store Connect Internal Testing налаштовується в розділі TestFlight → Internal Testing. Власник облікового запису додає тестувальників за електронною поштою та призначає ролі. Після завантаження білда через Xcode або Transporter система повідомляє учасників про доступність нової версії. Тестувальники встановлюють застосунок через застосунок TestFlight на пристрої.

Як налаштувати Internal Testing трек

Налаштування Internal Testing для обох платформ займає від 10 до 30 хвилин. Нижче наведено покрокові інструкції для Google Play та App Store. Процес не вимагає змін у коді застосунку — достатньо одноразового налаштування консолі розробника.

Інтеграція з CI/CD системами

Обидва магазини підтримують публікацію в Internal Testing через API. Для автоматизації використовуються Gradle Play Publisher (Google Play) та Fastlane (обидві платформи). CI/CD-пайплайн може завантажувати білди у внутрішній трек після кожного успішного проходження unit-тестів та UI-тестів.

Налаштування тестових облікових записів

Для застосунків з авторизацією необхідно підготувати тестові облікові записи та передати їх QA-команді. Облікові записи повинні мати доступ до тестового середовища (staging/development) та не зачіпати production-дані. Рекомендується створити окрему тестову Firebase-конфігурацію для внутрішнього треку.

Робочий процес QA з Internal Testing

Internal Testing вбудовується в QA-пайплайн після проходження автоматичних перевірок у CI. Розробник або DevOps-інженер завантажує білд у внутрішній трек, після чого QA-інженери отримують сповіщення та встановлюють оновлення на тестові пристрої через магазин застосунків.

Оптимальна частота викладки

Рекомендується викладати білди в Internal Testing щодня або після кожної значущої зміни в кодовій базі. QA-команда тестує критичні сценарії: авторизацію, основний користувацький потік, інтеграцію з API та роботу з локальним сховищем. Регресійне тестування виконується на кожному третьому-четвертому білді.

Інструменти для збору зворотного зв'язку

Для збору баг-репортів використовуйте інтеграцію з системами відстеження: Jira, YouTrack, Trello або GitHub Issues. Тестувальники надсилають скріншоти, логи та кроки відтворення. TestFlight вбудовано підтримує збір скріншотів та логів з пристрою при струшуванні — дані надсилаються розробнику через App Store Connect.

Інтеграція з CI/CD пайплайном

Для автоматичної публікації білдів у Internal Testing трек налаштуйте CI/CD пайплайн. Після проходження unit-тестів та UI-тестів скрипт завантажує білд у внутрішній трек та надсилає сповіщення QA-команді. Fastlane надає готовий action upload_to_play_store з параметром track: internal. Для iOS використовуйте Fastlane Pilot для завантаження в TestFlight.

Обмеження та ліміти Internal Testing

Internal Testing має жорсткі ліміти за кількістю учасників: до 100 осіб у Google Play та до 100 внутрішніх тестувальників у TestFlight. Google Play додатково обмежує кількість груп — максимум 1 група для внутрішнього треку. App Store не обмежує кількість білдів, але термін дії кожного білда становить 90 днів.

Відмінності лімітів між платформами

Google Play не обмежує кількість завантажуваних білдів у внутрішній трек, але після 90 днів бездіяльності трек може бути автоматично призупинено. TestFlight має більш суворі обмеження: до 30 активних білдів одночасно, до 10 000 зовнішніх тестувальників (не внутрішніх). Для зняття обмежень потрібна участь у програмі Apple Developer Enterprise.

Міграція з Internal в Open Beta

Після стабілізації білда на внутрішньому треку він переноситься в Closed або Open Beta для тестування на зовнішній аудиторії. Google Play дозволяє скопіювати налаштування треку та перенести білд без повторного завантаження. TestFlight вимагає створення окремого зовнішнього треку з додаванням нових груп тестувальників.

Безпека Internal Testing треку

Білди у внутрішньому треку захищені від зовнішнього доступу: завантажити застосунок можуть лише учасники, авторизовані через Google Play Console або App Store Connect. Навіть знаючи посилання на застосунок, сторонній користувач не зможе встановити білд. Це забезпечує конфіденційність нових функцій та захист інтелектуальної власності на етапі розробки.