Internal Testing: istota, jak działa i jak skonfigurować tor

Czym jest Internal Testing?

Internal Testing to tor testowania w Google Play Console i TestFlight, przeznaczony do rozpowszechniania buildów wśród członków zespołu programistycznego. W przeciwieństwie do otwartego beta-testowania, dostęp do Internal Testing jest ograniczony do listy adresów e-mail zatwierdzonej przez właściciela konta dewelopera.

Główną zaletą jest minimalny czas dostawy builda do testerów. W Google Play Internal Testing nie wymaga przechodzenia moderacji — build pojawia się u uczestników po 5–15 minutach od przesłania. W App Store przez TestFlight build również jest dostarczany bez wcześniejszego App Review, ale podlega automatycznej weryfikacji podstawowych wymogów bezpieczeństwa.

Czym Internal Testing różni się od innych torów

W Google Play istnieją trzy tory testowania: Internal Testing, Closed Beta (Open Beta) i Production. Internal Testing jest najszybszy i najbardziej ograniczony pod względem liczby uczestników (do 100 osób). Closed Beta dopuszcza do 10 000 uczestników i wymaga skonfigurowania strony testowania. Production to końcowy etap z pełną moderacją.

Kiedy stosować Internal Testing

Internal Testing jest używany do wstępnego sprawdzania buildów przed przekazaniem na tory beta. Programiści przesyłają codzienne kompilacje dla zespołu QA, sprawdzają integrację nowych SDK, testują zgodność z różnymi wersjami systemów operacyjnych i wykrywają błędy regresyjne, zanim build zobaczą zewnętrzni testerzy.

Internal Testing w Google Play

W Google Play Console Internal Testing to oddzielny tor, dostępny w sekcji Release → Testing. Aby dodać testera, wystarczy podać jego adres e-mail — uczestnik otrzymuje zaproszenie i link do dołączenia przez Google Play. Buildy są przesyłane przez ten sam interfejs co release produkcyjne.

Proces publikacji w torze Internal

Programista przesyła App Bundle lub APK do sekcji Internal Testing w Google Play Console. System sprawdza podstawowe wymagania: podpis, wersję kodu i zgodność z API. Po 5–15 minutach przetwarzania build staje się dostępny dla testerów. Status można śledzić w konsoli: Draft, In Review, Ready to Test.

// Fastlane — publikacja w torze 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

Zarządzanie testerami

Dodawanie uczestników odbywa się przez sekcję Testers w Google Play Console. Dostępne jest masowe przesyłanie przez plik CSV. Każdy tester otrzymuje wiadomość e-mail z zaproszeniem i instrukcją instalacji. Aby cofnąć dostęp, wystarczy usunąć uczestnika z grupy — zainstalowana aplikacja nadal działa, ale nowe aktualizacje nie są dostarczane.

Internal Testing w App Store przez TestFlight

W ekosystemie Apple rolę Internal Testing pełni TestFlight — platforma do dystrybucji wersji beta. TestFlight obsługuje do 100 wewnętrznych testerów, którzy są dodawani przez e-mail w App Store Connect. Do publikacji builda nie jest wymagane przejście pełnego App Review, ale build jest automatycznie sprawdzany pod kątem minimalnych wymagań.

Cechy TestFlight Internal Testing

W przeciwieństwie do Google Play, gdzie Internal Testing w ogóle nie wymaga moderacji, Apple wykonuje automatyczną Basic Review. Weryfikacja trwa 30–60 minut i obejmuje skanowanie kodu binarnego pod kątem złośliwych API oraz przestrzegania podstawowych wymagań. Po pomyślnej weryfikacji build jest dostępny dla testerów w ciągu 24 godzin. Okres ważności builda wynosi 90 dni.

Konfiguracja Internal Testing w App Store Connect

W App Store Connect Internal Testing konfiguruje się w sekcji TestFlight → Internal Testing. Właściciel konta dodaje testerów przez e-mail i przypisuje role. Po przesłaniu builda przez Xcode lub Transporter system powiadamia uczestników o dostępności nowej wersji. Testerzy instalują aplikację przez aplikację TestFlight na urządzeniu.

Jak skonfigurować tor Internal Testing

Konfiguracja Internal Testing dla obu platform zajmuje od 10 do 30 minut. Poniżej znajdują się instrukcje krok po kroku dla Google Play i App Store. Proces nie wymaga zmian w kodzie aplikacji — wystarczy jednorazowa konfiguracja konsoli dewelopera.

Integracja z systemami CI/CD

Oba sklepy obsługują publikację w Internal Testing przez API. Do automatyzacji używa się Gradle Play Publisher (Google Play) i Fastlane (obie platformy). Pipeline CI/CD może przesyłać buildy do toru Internal po każdym pomyślnym przejściu testów jednostkowych i UI.

Konfiguracja kont testowych

W przypadku aplikacji z autoryzacją należy przygotować konta testowe i przekazać je zespołowi QA. Konta powinny mieć dostęp do środowiska testowego (staging/development) i nie wpływać na dane produkcyjne. Zaleca się utworzenie oddzielnej konfiguracji Firebase dla toru Internal.

Proces pracy QA z Internal Testing

Internal Testing jest wbudowany w pipeline QA po przejściu automatycznych sprawdzeń w CI. Programista lub inżynier DevOps przesyła build do toru Internal, po czym inżynierowie QA otrzymują powiadomienie i instalują aktualizację na urządzeniach testowych przez sklep z aplikacjami.

Optymalna częstotliwość wydań

Zaleca się przesyłanie buildów do Internal Testing codziennie lub po każdej znaczącej zmianie w bazie kodu. Zespół QA testuje krytyczne scenariusze: autoryzację, główny przepływ użytkownika, integrację z API i pracę z lokalnym magazynem. Testy regresyjne są wykonywane co trzecim lub czwartym buildzie.

Narzędzia do zbierania opinii

Do zbierania raportów o błędach użyj integracji z systemami śledzenia: Jira, YouTrack, Trello lub GitHub Issues. Testerzy wysyłają zrzuty ekranu, logi i kroki reprodukcji. TestFlight wbudowanie obsługuje zbieranie zrzutów ekranu i logów z urządzenia po potrząśnięciu — dane są wysyłane do programisty przez App Store Connect.

Integracja z pipeline CI/CD

Do automatycznej publikacji buildów w torze Internal Testing skonfiguruj pipeline CI/CD. Po przejściu testów jednostkowych i UI skrypt przesyła build do toru Internal i wysyła powiadomienie do zespołu QA. Fastlane udostępnia gotową akcję upload_to_play_store z parametrem track: internal. Dla iOS użyj Fastlane Pilot do przesłania do TestFlight.

Ograniczenia i limity Internal Testing

Internal Testing ma sztywne limity liczby uczestników: do 100 osób w Google Play i do 100 wewnętrznych testerów w TestFlight. Google Play dodatkowo ogranicza liczbę grup — maksymalnie 1 grupa dla toru Internal. App Store nie ogranicza liczby buildów, ale okres ważności każdego builda wynosi 90 dni.

Różnice w limitach między platformami

Google Play nie ogranicza liczby przesyłanych buildów w torze Internal, ale po 90 dniach bezczynności tor może zostać automatycznie zawieszony. TestFlight ma bardziej rygorystyczne ograniczenia: do 30 aktywnych buildów jednocześnie, do 10 000 zewnętrznych testerów (nie Internal). Aby usunąć ograniczenia, wymagany jest udział w programie Apple Developer Enterprise.

Migracja z Internal do Open Beta

Po stabilizacji builda w torze Internal jest on przenoszony do Closed lub Open Beta w celu testowania na zewnętrznej publiczności. Google Play pozwala skopiować ustawienia toru i przenieść build bez ponownego przesyłania. TestFlight wymaga utworzenia oddzielnego toru zewnętrznego z dodaniem nowych grup testerów.

Bezpieczeństwo toru Internal Testing

Buildy w torze Internal są chronione przed dostępem z zewnątrz: aplikację mogą pobrać tylko uczestnicy autoryzowani przez Google Play Console lub App Store Connect. Nawet znając link do aplikacji, osoba postronna nie będzie mogła zainstalować builda. Zapewnia to poufność nowych funkcji i ochronę własności intelektualnej na etapie rozwoju.