Przejdź do treści
TestLine Menu
TestLine
mobile

Plan testów przed pierwszym releasem aplikacji mobilnej

Urządzenia, wersje systemów, uprawnienia i scenariusze offline, które warto sprawdzić.

autor
Artur Machowski, Senior QA Engineer
opublikowano
czytanie
11 min

Dlaczego mobile to osobny temat

Aplikacja webowa działa w kilku przeglądarkach. Aplikacja mobilna działa na setkach modeli telefonów, kilku wersjach systemu, z różnymi ustawieniami uprawnień, przy słabym zasięgu i z przerwami na połączenia telefoniczne. Do tego dochodzi weryfikacja w App Store i Google Play, której nie da się “poprawić hotfixem w pięć minut”.

Poniżej lista, od której zaczynam testy aplikacji mobilnej przed pierwszym releasem.

1. Macierz urządzeń

Nie testuj na wszystkim. Ustal macierz na podstawie danych:

  • Wersje systemu. Zwykle dwie ostatnie główne wersje iOS i cztery-pięć wersji Androida pokrywają większość użytkowników. Sprawdź minimalną wersję ustawioną w projekcie.
  • Rozmiary ekranów. Najmniejszy obsługiwany telefon, typowy i duży. Plus tablet, jeśli aplikacja go wspiera.
  • Producenci Androida. Nakładki systemowe (np. agresywne oszczędzanie baterii) potrafią zabijać procesy w tle i blokować powiadomienia.

2. Instalacja i aktualizacja

  • Świeża instalacja i pierwsze uruchomienie (onboarding, zgody).
  • Aktualizacja z poprzedniej wersji z zachowaniem danych i sesji.
  • Odinstalowanie i ponowna instalacja.

Aktualizacja to scenariusz, o którym najczęściej się zapomina przy pierwszym releasie, bo nie ma jeszcze poprzedniej wersji. Warto przygotować go od razu, przed drugim wydaniem.

3. Uprawnienia

Dla każdego uprawnienia (aparat, lokalizacja, powiadomienia, kontakty) sprawdź trzy ścieżki: zgoda, odmowa i odmowa z zaznaczeniem “nie pytaj ponownie”. Aplikacja nie może się zawiesić ani zostawić użytkownika bez wyjaśnienia, co zrobić dalej.

4. Sieć i tryb offline

  • Brak sieci przy starcie aplikacji.
  • Utrata zasięgu w trakcie wysyłania formularza lub płatności.
  • Przełączenie z Wi-Fi na sieć komórkową.
  • Wolne połączenie: czy użytkownik widzi stan ładowania, czy pusty ekran.

Najgroźniejsze błędy mobilne to te, które powodują podwójne operacje: dwa zamówienia albo dwie płatności po ponowieniu żądania.

5. Przerwania i cykl życia

Połączenie przychodzące, przejście do innej aplikacji, zablokowanie ekranu, obrót urządzenia. Po powrocie aplikacja powinna być w tym samym stanie, a wprowadzone dane nie powinny zniknąć.

6. Powiadomienia i deep linki

Sprawdź, czy powiadomienie otwiera właściwy ekran, gdy aplikacja jest zamknięta, w tle i na pierwszym planie. To samo dla linków z e-maila czy SMS-a.

7. Wymagania sklepów

  • Działające konto testowe dla recenzentów App Store.
  • Polityka prywatności dostępna z aplikacji.
  • Możliwość usunięcia konta z poziomu aplikacji, jeśli rejestracja jest możliwa.
  • Opisy uprawnień w Info.plist, które wyjaśniają, po co aplikacja ich potrzebuje.

Co automatyzować

Na start: logowanie, główną ścieżkę biznesową i płatność. W Appium można napisać jeden zestaw testów dla obu platform, a XCUITest i UIAutomator (Espresso) dają szybsze i stabilniejsze testy natywne kosztem dwóch osobnych zestawów.

// UIAutomator: sprawdzenie, że aplikacja wraca do ekranu koszyka
device.pressHome()
device.findObject(By.desc("Moja aplikacja")).click()
device.wait(Until.hasObject(By.text("Koszyk")), 5_000)

Podsumowanie

Pierwszy release aplikacji mobilnej zostaje z użytkownikami na długo, bo nie wszyscy szybko aktualizują. Lepiej poświęcić tydzień na testy według planu niż miesiąc na gaszenie pożarów i odpowiadanie na jednogwiazdkowe recenzje. Jeśli chcesz, żebym przygotował i przeprowadził testy Twojej aplikacji, opisz projekt. Jeśli aplikacja dopiero powstaje, zbudować ją może moja spółka, software house 2Simple.

Masz release za kilka tygodni?

Opisz projekt w formularzu. Odpiszę z pytaniami o zakres albo z wstępnym planem testów.