Best practices testowania aplikacji mobilnych: osiem zasad, które chronią ocenę w sklepie

Best practices testowania aplikacji mobilnych to zestaw zasad i konkretnych przypadków testowych, które sprawdzają aplikację tam, gdzie ludzie naprawdę jej używają: w tramwaju bez zasięgu, z 15 procentami baterii, z odebranym uprawnieniem do aparatu i z telefonem, który właśnie dzwoni. Ten artykuł jest checklistą do pracy: osiem zasad, szesnaście przypadków testowych z oczekiwanym wynikiem, komendy adb i simctl oraz przykład testu w Appium, który możecie uruchomić u siebie.

Jeśli dopiero porządkujecie podstawy, zacznijcie od tekstu Testowanie aplikacji mobilnych: kompletny przewodnik po typach, urządzeniach i narzędziach. Tutaj zakładamy, że wiecie, czym jest test funkcjonalny i emulator, i chcecie wiedzieć, co dokładnie sprawdzić przed kolejnym wydaniem, żeby jedna gwiazdka w sklepie nie była pierwszym zgłoszeniem błędu.

Czym są best practices testowania aplikacji mobilnych i czym różnią się od przewodnika?

Best practices odpowiadają na pytanie „jak”, a nie „co to jest”. Na blogu Quality Island temat aplikacji mobilnych rozkłada się na pięć tekstów o różnej intencji i warto wiedzieć, który otworzyć, zanim zaczniecie czytać. Ten wpis jest najbardziej praktyczny: lista kontrolna i komendy. Pozostałe dają kontekst, rodzaje testów i porównanie narzędzi.

Rozgraniczenie ma też sens praktyczny. Manualne testowanie aplikacji mobilnych i testy automatyczne aplikacji mobilnych korzystają z tej samej listy przypadków: różni je tylko to, kto klika. Dlatego checklista niżej ma kolumnę „automat?”, która podpowiada, gdzie skrypt się zwróci, a gdzie oko testera nadal wygrywa.

Dlaczego ocena w sklepie zależy od testów bardziej niż od marketingu?

Bo sklep ocenia aplikację liczbami, których nie da się podkręcić kampanią. Według dokumentacji Android vitals z 2026 roku Google Play obniża widoczność aplikacji, gdy odsetek sesji z awarią widoczną dla użytkownika przekracza 1,09 procent, a odsetek sesji z ANR, czyli zamrożonym ekranem, przekracza 0,47 procent. Dla pojedynczego modelu telefonu próg wynosi 8 procent, co oznacza, że jeden popularny, słabszy model potrafi pogrążyć wynik na urządzeniach, których w ogóle nie mieliście na biurku.

Druga liczba, o której mało kto pamięta przy planowaniu testów, to wymóg docelowego API. Według wymagań Google Play od 31 sierpnia 2026 roku nowe aplikacje i aktualizacje muszą celować w Androida 16, czyli API 36, a przedłużenie można dostać najwyżej do 1 listopada 2026. Zmiana targetSdk to nie formalność w pliku Gradle: przełącza aplikację na nowe zachowania systemu, w tym nowe reguły uprawnień i pracy w tle. Każde podniesienie targetSdk traktujcie jak wydanie wymagające pełnej regresji.

W naszych projektach mobilnych najlepiej widać to na liczbach klienta Autono z branży wynajmu samochodów. Z danych Autono, potwierdzonych przez klienta, liczba błędów krytycznych w procesach rezerwacji spadła o 55 procent, a system pozostał stabilny przy obciążeniu większym o 120 procent w sezonie wakacyjnym. Ten wynik nie wziął się z jednego narzędzia, tylko z tego, że testy objęły dokładnie te ścieżki, które klient wykonuje na telefonie w pośpiechu: rezerwację, płatność i zmianę terminu.

Jakie osiem zasad testowania aplikacji mobilnych chroni ocenę w sklepie?

Zasady są te same od lat, zmieniło się to, jak je sprawdzać. Poniżej każda z ośmiu dostaje jedno zdanie „po co” i jeden konkret „jak”, bez powtarzania podręcznika.

1. Zacznijcie testy na etapie wymagań

Najtańszy błąd mobilny to ten, który znajdziecie w makiecie: brak stanu „brak sieci”, brak ekranu po odmowie uprawnienia, przycisk pod klawiaturą ekranową. Przegląd wymagań i makiet pod tym kątem to testowanie statyczne w najczystszej postaci. Zapytajcie przy każdej historyjce: co widzi użytkownik, gdy sieć zniknie w połowie tej operacji?

2. Sprawdzajcie warstwę sieciową, nie tylko brak sieci

Zero zasięgu to łatwy przypadek, bo aplikacja zwykle od razu pokazuje komunikat. Trudne są stany pośrednie: 2 sekundy opóźnienia, utrata połączenia w trakcie płatności, przełączenie z Wi-Fi na LTE przy wyjściu z biura. Wtedy wychodzą zdublowane zamówienia i wieczne kółka ładowania.

3. Dobierzcie prawdziwe urządzenia do danych, nie do mody

Emulator wystarczy do logiki, ale nie pokaże przegrzania, pamięci słabszego telefonu ani nakładek producentów, które agresywnie zabijają procesy w tle. Matrycę urządzeń budujcie z analityki: pięć do ośmiu modeli, które pokrywają większość Waszych sesji, plus jeden najsłabszy wspierany telefon.

4. Testujcie języki, a nie tylko tłumaczenia

Niemiecki tekst bywa wyraźnie dłuższy od angielskiego, arabski czyta się od prawej, a polskie „zł” stoi po kwocie. Sprawdzajcie ucięte przyciski, łamanie słów, kierunek RTL i formaty dat po zmianie języka systemu w trakcie działania aplikacji.

5. Mierzcie baterię i pracę w tle

Drenaż baterii rzadko widać w krótkim teście, bo powstaje w tle: synchronizacja co minutę, lokalizacja trzymana bez potrzeby, blokada wybudzenia, której nikt nie zwalnia. Komendy i narzędzia są w osobnej sekcji niżej.

6. Testujcie sprzęt i przerwania

Aparat, GPS, mikrofon, Bluetooth, biometria i przychodzące połączenie w środku formularza. Każda funkcja sprzętowa ma dwa przypadki obowiązkowe: działa i odmówiono dostępu.

7. Weryfikujcie uprawnienia w trzech stanach

Przyznane, odmówione i odebrane później w ustawieniach. Na nowszych systemach dochodzi czwarty: dostęp częściowy do zdjęć albo kontaktów. Szczegóły w sekcji o Androidzie 14 i iOS.

8. Automatyzujcie regresję, nie wszystko

Skrypt zwraca się przy ścieżkach powtarzanych przy każdym wydaniu: logowanie, koszyk, płatność, uprawnienia. Wrażenia wizualne, animacje i ergonomia zostają przy człowieku. Jeśli zastanawiacie się, gdzie jest ta granica, pomoże tekst o zaletach i wadach automatyzacji testów i liczeniu ROI.

Checklista przypadków testowych: co sprawdzić przed każdym wydaniem?

Poniższa lista to minimum, które przechodzimy przed wydaniem aplikacji mobilnej w projektach Quality Island. Każdy przypadek ma oczekiwany wynik, bo bez niego test kończy się zdaniem „chyba działa”. Kolumna „automat?” mówi, czy warto go wpiąć w regresję.

Źródło: przypadki opracowane na podstawie praktyki Quality Island oraz dokumentacji Android i Apple, październik 2026.

Przypadek M16 jest najczęściej pomijany, bo testerzy instalują aplikację od zera. Użytkownicy tego nie robią: aktualizują ją ze sklepu, z danymi z poprzedniej wersji w pamięci. Migracja bazy danych to jedyne miejsce, w którym aplikacja potrafi zepsuć się bez zmiany ani jednej linii w kodzie ekranu, za to z pełnym zaangażowaniem po stronie recenzji w sklepie.

Jak testować uprawnienia na Androidzie 13, 14 i na iOS?

Uprawnienia zmieniają się z każdą wersją systemu, więc przypadki testowe sprzed dwóch lat już nie wystarczą. Według dokumentacji Androida od wersji 13, czyli API 33, powiadomienia są dla nowo zainstalowanej aplikacji domyślnie wyłączone, a aplikacja musi poprosić o uprawnienie POST_NOTIFICATIONS. Android 14 dodał dostęp częściowy do zdjęć i filmów: użytkownik wskazuje konkretne pliki, a aplikacja celująca w API 34 dostaje uprawnienie READ_MEDIA_VISUAL_USER_SELECTED i musi obsłużyć sytuację, w której ten dostęp wygasa.

Źródło: Google, dokumentacja Android 13 i 14; Apple, dokumentacja frameworków Photos, AppTrackingTransparency i Contacts, 2026.

Najważniejszy przypadek z tej sekcji to odebranie uprawnienia w ustawieniach, gdy aplikacja działa w tle. Android w takiej sytuacji kończy proces aplikacji, więc po powrocie system odtwarza ją od nowa i wychodzą wszystkie miejsca, w których stan trzymany był tylko w pamięci. Na emulatorze i na iOS w symulatorze zrobicie to jedną komendą:

# Android: odebranie i przyznanie uprawnienia bez klikania w ustawieniach
adb shell pm revoke pl.przyklad.sklep android.permission.CAMERA
adb shell pm grant  pl.przyklad.sklep android.permission.CAMERA

# iOS, symulator: cofnięcie dostępu do zdjęć i reset wszystkich zgód
xcrun simctl privacy booted revoke photos pl.przyklad.sklep
xcrun simctl privacy booted reset all pl.przyklad.sklep

Uwaga, którą Apple umieszcza w pomocy do simctl: ustawienie zgody komendą omija okno systemowe, więc może ukryć błąd w opisie powodu w Info.plist. Komendy służą do przygotowania stanu, a ścieżkę z prawdziwym oknem zgody przejdźcie przynajmniej raz ręcznie na urządzeniu.

Ten sam przypadek w Appium, z driverem UiAutomator2 i klientem Java 11.0.0. Test zamyka aplikację, odbiera uprawnienie do aparatu, uruchamia ją ponownie i sprawdza, że zamiast awarii pojawia się komunikat. Kod skompilowaliśmy z Mavenem na Javie 25 z poziomem języka 21:

@Test
void odmowaDostepuDoAparatuNieWylaczaAplikacji() throws Exception {
    UiAutomator2Options opcje = new UiAutomator2Options()
            .setApp(System.getProperty("app"))
            .setAutoGrantPermissions(false);
    AndroidDriver driver = new AndroidDriver(URI.create("http://127.0.0.1:4723").toURL(), opcje);
    try {
        driver.terminateApp(PAKIET);
        driver.executeScript("mobile: changePermissions", Map.of(
                "permissions", List.of("android.permission.CAMERA"),
                "action", "revoke"));
        driver.activateApp(PAKIET);
        driver.findElement(AppiumBy.accessibilityId("skanuj-kod")).click();
        assertTrue(driver.findElement(AppiumBy.accessibilityId("komunikat-brak-aparatu")).isDisplayed());
    } finally {
        driver.quit();
    }
}

Jak testować przerwania, tryb offline i słabą sieć?

Przerwania i sieć najłatwiej testować na emulatorze Androida, bo jego konsola symuluje połączenie, SMS, prędkość łącza i opóźnienie. Komendy wysyłacie przez adb emu, więc da się je wpiąć w skrypt testu i powtarzać przy każdej regresji:

# przerwania: połączenie przychodzące i SMS w trakcie scenariusza
adb emu gsm call 500600700
adb emu gsm cancel 500600700
adb emu sms send 500600700 "Kod: 482913"

# sieć: prędkość EDGE i opóźnienie od 150 do 550 ms (profil gprs)
adb emu network speed edge
adb emu network delay gprs

# powrót do pełnej prędkości
adb emu network speed full
adb emu network delay none

Na iPhonie odpowiednikiem jest Network Link Conditioner, dostępny w ustawieniach dewelopera na urządzeniu, z gotowymi profilami słabej sieci i utraty pakietów. Tryb offline testujcie w dwóch wariantach, bo dają różne błędy: sieć wyłączona przed startem aplikacji (M09) i sieć znikająca w trakcie operacji (M10). Drugi jest groźniejszy, bo prowadzi do podwójnych zamówień i płatności w stanie nieznanym.

Przy operacjach, które dotykają pieniędzy, sam test interfejsu nie wystarczy. Sprawdźcie po stronie API, czy żądanie ponowione po utracie sieci jest idempotentne, czyli czy drugie identyczne zamówienie nie tworzy drugiej transakcji. To miejsce, w którym testy mobilne spotykają się z testami API, i warto, żeby oba zespoły miały wspólny przypadek testowy.

Jak zmierzyć zużycie baterii, zanim zrobią to użytkownicy?

Zużycie baterii to przypadek, którego nie złapie żaden test funkcjonalny, bo aplikacja działa poprawnie, tylko kosztownie. Według dokumentacji Android vitals próg złego zachowania dla nadmiernych blokad wybudzenia wynosi 5 procent sesji, a dla zegarków z Wear OS nadmierne zużycie baterii ma osobny próg 1 procent. To jest metryka, którą Google zbiera od prawdziwych użytkowników, więc najlepiej zobaczyć problem wcześniej u siebie.

Na Androidzie zacznijcie od trybu Doze i App Standby, bo to w nich aplikacje najczęściej gubią powiadomienia albo budzą telefon bez potrzeby. Dokumentacja Androida podaje gotowe komendy:

# Doze: wymuszenie bezczynności urządzenia i powrót
adb shell dumpsys deviceidle force-idle
adb shell dumpsys deviceidle unforce
adb shell dumpsys battery reset

# App Standby: aplikacja nieaktywna przy odłączonej ładowarce
adb shell dumpsys battery unplug
adb shell am set-inactive pl.przyklad.sklep true
adb shell am get-inactive pl.przyklad.sklep

Do pomiaru użyjcie profilera energii w Android Studio, który pokazuje zużycie w podziale na CPU, sieć i lokalizację, a na iOS instrumentu Energy Log w Xcode Instruments i zakładki Energy w Xcode Organizer z raportami od użytkowników. Mierzcie zawsze ten sam scenariusz, na przykład 30 minut nawigacji albo noc w tle, i porównujcie wersje między sobą, nie z intuicją.

Trzy wzorce drenażu, które spotykamy najczęściej: lokalizacja z najwyższą dokładnością tam, gdzie wystarczy miasto, synchronizacja w pętli zamiast przez WorkManager albo BGTaskScheduler, i animacja, która nadal działa, gdy ekran jest niewidoczny. Każdy z nich ma prosty przypadek testowy: uruchomcie aplikację, przejdźcie do tła i porównajcie zużycie po godzinie.

Appium, Firebase Test Lab czy farma urządzeń: co wybrać?

Narzędzie wybierajcie pod pytanie, na które ma odpowiedzieć, a nie pod popularność. Według listy wydań Appium na GitHubie Appium 3.0 ukazało się 18 sierpnia 2025, a w październiku 2026 aktualna wersja to 3.8.0, wymagająca Node.js 20.19 lub nowszego. Pełne porównanie Appium, Espresso, XCUITest i Maestro, razem z kryteriami wyboru, jest w tekście o narzędziach do automatyzacji testów aplikacji mobilnych, więc tu tylko mapa decyzji.

Źródło: wydania Appium na GitHubie, Firebase, dokumentacja Android Studio i Xcode, październik 2026.

Farmy urządzeń porównujemy szerzej w tekście o Sauce Labs i BrowserStack. Jeśli wybór między testami ręcznymi a skryptami jest dla Was jeszcze otwarty, zacznijcie od checklisty wyżej: przypadki z dopiskiem „tak” to gotowa lista kandydatów do automatyzacji.

Od czego zacząć w Waszym zespole w tym tygodniu?

Nie potrzebujecie od razu nowego narzędzia. Weźcie checklistę z tego artykułu, przejdźcie ją ręcznie na dwóch urządzeniach przed najbliższym wydaniem i zapiszcie, które przypadki nie mają dziś oczekiwanego wyniku. To jest Wasza lista ryzyk, a przypadki oznaczone „tak” w kolumnie automatyzacji to plan na kolejny sprint. Wyniki opiszcie zgodnie z zasadami z tekstu o tym, jak poprawnie zgłosić błąd, z modelem telefonu, wersją systemu i stanem sieci.

Jeśli chcecie podnieść kompetencje zespołu, mamy dwa praktyczne szkolenia: szkolenie z manualnego testowania aplikacji mobilnych oraz testowanie automatyczne aplikacji mobilnych w Appium z Javą. Gdy wolicie oddać część pracy, zespół Quality Island przejmie automatyzację testów mobilnych albo szersze testy funkcjonalne.

O tym, ile testów wystarczy przy pierwszej wersji produktu, gdy budżet jest mały, a ryzyko duże, pisze Strefa QA: minimum QA w MVP, czyli co testować, żeby nie zabić pomysłu błędem.

Powiązane na blogu Quality Island

• Testowanie aplikacji mobilnych: kompletny przewodnik po typach, urządzeniach i narzędziach
• Testowanie aplikacji mobilnych część 2: rodzaje i typy testów
• Narzędzia do automatyzacji testów aplikacji mobilnych: Appium, Espresso, XCUITest, Maestro
• Najczęściej popełniane błędy podczas testowania aplikacji mobilnych
• Środowisko testowe: jak je zbudować i utrzymać

Pełna lista źródeł

• Google, Android Developers, Android vitals: progi złego zachowania, 2026. Stąd progi 1,09 procent awarii, 0,47 procent ANR, 8 procent na model telefonu i 5 procent nadmiernych blokad wybudzenia.
• Google Play, Target API level requirements for Google Play apps, 2026. Stąd wymóg API 36 od 31 sierpnia 2026 i przedłużenie do 1 listopada 2026.
• Google, Android Developers, Notification runtime permission, 2026. Stąd POST_NOTIFICATIONS i domyślnie wyłączone powiadomienia od Androida 13.
• Google, Android Developers, Grant partial access to photos and videos, 2026. Stąd READ_MEDIA_VISUAL_USER_SELECTED i wygasanie dostępu częściowego w Androidzie 14.
• Google, Android Developers, Optimize for Doze and App Standby, 2026. Stąd komendy adb do testów trybu Doze i App Standby.
• Google, Android Developers, Send emulator console commands, 2026. Stąd komendy gsm, sms, network speed i network delay.
• Firebase, Usage levels, quotas, and pricing for Test Lab, 2026. Stąd limity planu Spark, ceny planu Blaze i data wyłączenia usługi 30 września 2027.
• Appium, GitHub, Appium releases, 2026. Stąd data wydania Appium 3.0 (18 sierpnia 2025) i wersja 3.8.0 z września 2026; wymagania Node.js w przewodniku Migrating to Appium 3.
• Appium, UiAutomator2 Driver: mobile: changePermissions i autoGrantPermissions, 2026. Stąd składnia zmiany uprawnień w teście.
• Apple, CNAuthorizationStatus.limited, 2024. Stąd ograniczony dostęp do kontaktów od iOS 18.
• Dane własne Quality Island, 2026: case study Autono (liczby potwierdzone przez klienta) i ponad 450 000 napisanych testów automatycznych.