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. Билдовете се качват чрез същия интерфейс като продукционните версии.

Процес на публикуване в Internal трак

Разработчикът качва 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 извършва автоматичен Basic Review. Проверката отнема 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 пайплайнът може да качва билдове в Internal трак след всяко успешно преминаване на unit тестове и UI тестове.

Настройка на тестови акаунти

За приложения с автентикация е необходимо да подготвите тестови акаунти и да ги предоставите на QA екипа. Акаунтите трябва да имат достъп до тестовата среда (staging/development) и да не засягат продукционни данни. Препоръчва се създаване на отделна Firebase конфигурация за Internal трак.

Работен процес на QA с Internal Testing

Internal Testing се вгражда в QA пайплайн след преминаване на автоматичните проверки в CI. Разработчикът или DevOps инженерът качва билда в Internal трак, след което QA инженерите получават уведомление и инсталират актуализацията на тестови устройства чрез магазина за приложения.

Оптимална честота на пускане

Препоръчва се пускане на билдове в Internal Testing ежедневно или след всяка значителна промяна в кодовата база. QA екипът тества критични сценарии: автентикация, основен потребителски поток, интеграция с API и работа с локално хранилище. Регресионното тестване се извършва на всеки трети или четвърти билд.

Инструменти за събиране на обратна връзка

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

Интеграция с CI/CD пайплайн

За автоматично публикуване на билдове в Internal Testing трак, настройте CI/CD пайплайн. След преминаване на unit тестове и UI тестове, скриптът качва билда в Internal трак и изпраща уведомление на QA екипа. Fastlane предоставя готовата акция upload_to_play_store с параметър track: internal. За iOS използвайте Fastlane Pilot за качване в TestFlight.

Ограничения на Internal Testing

Internal Testing има строги ограничения на броя участници: до 100 души в Google Play и до 100 вътрешни тестери в TestFlight. Google Play допълнително ограничава броя групи — максимум 1 група за Internal трак. App Store не ограничава броя билдове, но срокът на валидност на всеки билд е 90 дни.

Разлики в ограниченията между платформите

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

Миграция от Internal в Open Beta

След стабилизиране на билда в Internal трак, той се прехвърля в Closed или Open Beta за тестване на външна аудитория. Google Play позволява копиране на настройките на трака и прехвърляне на билда без повторно качване. TestFlight изисква създаване на отделен външен трак с добавяне на нови групи тестери.

Сигурност на Internal Testing трак

Билдовете в Internal трак са защитени от външен достъп: приложението могат да изтеглят само участници, оторизирани чрез Google Play Console или App Store Connect. Дори и да знае линка на приложението, външно лице няма да може да инсталира билда. Това осигурява поверителност на новите функции и защита на интелектуалната собственост на етапа на разработка.