Product Owner przysyła Ci zrzut ekranu z Google Play: ocena aplikacji spadła z 4,5 do 3,9 w dwa tygodnie. W recenzjach powtarzają się trzy zdania: „nie działa po aktualizacji”, „ekran płatności się zawiesza”, „na moim telefonie przyciski są poza ekranem”. Zespół jest zdziwiony, bo aplikacja przeszła testy na trzech telefonach w biurze: dwóch iPhone’ach i jednym flagowym Androidzie. Żaden z nich nie miał małego ekranu, starszej wersji systemu ani nakładki producenta, której używa spora część Twoich klientów.
Jako Tech Lead dostajesz zadanie: „zamów testy mobilne na zewnątrz, żeby to się nie powtórzyło”. Pierwsze rozmowy z dostawcami kończą się pytaniami, na które nie masz gotowych odpowiedzi. Ile urządzeń? Fizyczne czy w chmurze? Testy manualne, automatyczne, czy jedne i drugie? Bezpieczeństwo też? Każda odpowiedź zmienia cenę, a oferty, które przychodzą, różnią się tak bardzo, że trudno je porównać.
Ten artykuł pomaga podjąć te decyzje przed wysłaniem zapytania ofertowego. Nie wyjaśniamy od podstaw, czym są testy mobilne, bo robi to artykuł Testy aplikacji mobilnych: czym są, jak przebiega proces i jak mierzyć ich skuteczność. Zajmujemy się zakupem usługi: jak dobrać zakres i macierz urządzeń, kiedy wystarczy farma w chmurze, co automatyzować, od czego zależy cena i co zapisać w umowie.
Co kupujesz, zamawiając testy aplikacji mobilnej jako usługę?
Kupujesz trzy rzeczy naraz, a oferty często wyceniają tylko jedną z nich. Pierwsza to praca testerów: projektowanie i wykonywanie testów, zgłaszanie błędów, raportowanie. Druga to dostęp do urządzeń: fizycznych telefonów i tabletów albo farmy urządzeń w chmurze. Trzecia to wiedza o platformach: znajomość tego, czym różnią się iOS i Android, jak zachowują się nakładki producentów, jak działają uprawnienia, powiadomienia, praca w tle i proces publikacji w sklepach.
Testowanie mobilne różni się od testowania aplikacji webowych w kilku miejscach, które przekładają się bezpośrednio na koszt. Aplikację trzeba sprawdzić na dwóch platformach o różnych zasadach. Na Androidzie liczba kombinacji producenta, modelu, wersji systemu i rozmiaru ekranu jest bardzo duża. Aplikacja działa w warunkach, których przeglądarka na biurku nie zna: przerwania przez połączenia i powiadomienia, utrata zasięgu, przejście w tło, niski poziom baterii, zmiana orientacji ekranu. Do tego dochodzi proces wydawniczy: buildy testowe, TestFlight, ścieżki testów w Google Play, przegląd w sklepach.
Dlatego tani wariant usługi zwykle oznacza „testy manualne na urządzeniach, które dostawca akurat ma”. To może wystarczyć dla prostej aplikacji o wąskiej grupie użytkowników, ale nie rozwiąże problemu z przykładu we wstępie, bo nie zaczyna się od pytania, jakich urządzeń używają Twoi klienci.
Zanim porównasz oferty, zapisz trzy rzeczy: jaki problem chcesz rozwiązać (awarie po wydaniach, słabe oceny w sklepie, przygotowanie do premiery, wymagania bezpieczeństwa), jak często wydajesz aplikację i czy testy mają być jednorazowe, czy stałe. Od tych odpowiedzi zależy cały dalszy zakres.
Jaki zakres testów jest potrzebny dla Twojej aplikacji?
Pełna lista rodzajów testów mobilnych jest długa, ale nie każda aplikacja potrzebuje wszystkich. Poniżej obszary, które warto rozważyć, wraz z pytaniem, które pomaga zdecydować, czy dany obszar jest dla Ciebie.
Testy funkcjonalne i regresja. Czy aplikacja robi to, co ma robić, i czy nowe wydanie nie zepsuło tego, co działało. To rdzeń każdej usługi. Pytanie: które ścieżki generują przychód albo blokują użytkownika, gdy nie działają?
Kompatybilność. Czy aplikacja działa i wygląda poprawnie na różnych urządzeniach, wersjach systemu i rozmiarach ekranu. To obszar, który najczęściej odpowiada za recenzje typu „na moim telefonie nie działa”. Pytanie: jak bardzo zróżnicowany jest sprzęt Twoich użytkowników?
Warunki rzeczywiste i przerwania. Słaby zasięg, przełączanie między Wi-Fi a siecią komórkową, tryb samolotowy, przychodzące połączenie w trakcie płatności, przejście aplikacji w tło i powrót. Pytanie: czy użytkownicy korzystają z aplikacji w ruchu?
Wydajność i zużycie zasobów. Czas uruchomienia, płynność przewijania, zużycie pamięci i baterii, rozmiar aplikacji. Pytanie: czy Twoi użytkownicy mają słabsze telefony i czy aplikacja działa długo w tle?
Użyteczność i dostępność. Czy interfejs jest zrozumiały, czy elementy są odpowiednio duże, czy aplikacja działa z czytnikami ekranu i powiększonym tekstem. Pytanie: czy Twoja aplikacja podlega wymaganiom dostępności, na przykład jako usługa objęta europejskim aktem o dostępności?
Bezpieczeństwo. Przechowywanie danych na urządzeniu, komunikacja z API, uwierzytelnianie, odporność na modyfikacje. Punktem odniesienia jest OWASP MASVS, standard weryfikacji bezpieczeństwa aplikacji mobilnych, który dzieli wymagania na osiem grup: przechowywanie danych, kryptografia, uwierzytelnianie i autoryzacja, komunikacja sieciowa, interakcja z platformą, jakość kodu, odporność na inżynierię wsteczną i manipulacje oraz prywatność. Pytanie: czy aplikacja przetwarza dane osobowe, finansowe albo zdrowotne?
Integracje sprzętowe. Aparat, Bluetooth, NFC, GPS, biometria, płatności zbliżeniowe. Pytanie: czy aplikacja korzysta z czegoś więcej niż ekran i sieć?
Gotowość do publikacji. Zgodność z wytycznymi sklepów, uprawnienia, opisy, zachowanie przy pierwszym uruchomieniu i aktualizacji z poprzedniej wersji. Pytanie: jak często aplikacja jest odrzucana albo psuje się przy aktualizacji?
Wybierz obszary, które odpowiadają na Twoje pytania, i zapisz je w zapytaniu. Oferta „pełne testy mobilne” bez listy obszarów to oferta, której nie da się porównać ani odebrać.
Ile urządzeń trzeba przetestować i jak je wybrać?
Liczba urządzeń to najczęstsze pytanie i najczęstsze źródło przepłacania w obie strony. Za mało urządzeń i testy przegapiają problemy, które widzą klienci. Za dużo i płacisz za regresję na sprzęcie, którego nikt nie używa.
Macierz urządzeń buduje się z danych, nie z intuicji. Zacznij od analityki własnej aplikacji: Firebase, App Store Connect, Google Play Console albo inne narzędzie pokażą, jakie modele i wersje systemu mają Twoi użytkownicy. Jeśli aplikacja jeszcze nie istnieje, punktem wyjścia są dane rynkowe. Według StatCounter w październiku 2026 roku Android miał w Polsce 61,0% udziału w rynku mobilnych systemów operacyjnych, a iOS 39,0%. To oznacza, że żadnej z platform nie da się potraktować jako dodatku, a różnorodność urządzeń z Androidem będzie głównym wyzwaniem.
Typowa macierz ma trzy warstwy. Rdzeń to kilka urządzeń, na których wykonujesz pełną regresję przed każdym wydaniem: najpopularniejsze modele wśród Twoich użytkowników na obu platformach, w najczęstszych wersjach systemu. Skrajne przypadki to urządzenia, które najczęściej odsłaniają błędy: najmniejszy wspierany ekran, najstarsza wspierana wersja systemu, najsłabszy sprzęt, tablet, jeśli aplikacja go wspiera, oraz telefony producentów z własnymi nakładkami na Androida, które inaczej zarządzają pracą w tle i powiadomieniami. Szeroka pula to kilkadziesiąt modeli, na których uruchamiasz szybkie testy automatyczne albo test instalacji i uruchomienia, najczęściej w farmie w chmurze.
Macierz powinna być dokumentem żywym. Co kwartał porównaj ją z analityką i zaktualizuj: nowe modele wchodzą do rdzenia, stare wypadają, a gdy podnosisz minimalną wspieraną wersję systemu, odpada część skrajnych przypadków. Dostawca powinien to robić z Tobą, a nie trzymać się listy urządzeń, które ma na półce.
Farma urządzeń w chmurze czy fizyczne urządzenia: co wybrać?
Farma urządzeń w chmurze to usługa, w której testy uruchamiasz na prawdziwych telefonach i tabletach w centrum danych dostawcy, zdalnie, ręcznie albo automatycznie. Alternatywą są fizyczne urządzenia u testera lub w Twoim biurze. Oba podejścia mają swoje miejsce, a decyzja wpływa zarówno na koszt, jak i na to, co da się przetestować.
Ceny farm są publiczne, więc można je sprawdzić przed rozmową z dostawcą usług testowych. AWS Device Farm rozlicza testy na prawdziwych urządzeniach po 0,17 USD za minutę urządzenia albo w planie bez limitu minut od 250 USD miesięcznie za tzw. slot urządzenia; urządzenia prywatne, przypisane tylko do Twojego konta, zaczynają się od 200 USD miesięcznie. Firebase Test Lab w planie Blaze kosztuje 5 USD za godzinę na urządzeniu fizycznym i 1 USD za godzinę na urządzeniu wirtualnym, z darmowymi 30 minutami dziennie na urządzeniach fizycznych i 60 minutami na wirtualnych. Komercyjne platformy testowe mają własne cenniki, zwykle w modelu subskrypcji za liczbę równoległych sesji.
Farma w chmurze wygrywa, gdy potrzebujesz szerokiej puli modeli, uruchamiasz testy automatyczne w CI, chcesz sprawdzić konkretny model zgłoszony w recenzji albo nie chcesz kupować i utrzymywać sprzętu. Daje też dostęp do nowych modeli w dniu premiery bez zakupów.
Fizyczne urządzenia wygrywają, gdy testy wymagają kontaktu ze sprzętem: Bluetooth i NFC, akcesoria, aparat, czujniki, płatności zbliżeniowe, testy w terenie przy słabym zasięgu, długie testy zużycia baterii, a także subiektywna ocena płynności i gestów. Także wtedy, gdy polityka bezpieczeństwa nie pozwala instalować buildów z danymi testowymi na współdzielonej infrastrukturze.
W praktyce najczęściej sprawdza się model mieszany: kilka do kilkunastu fizycznych urządzeń z rdzenia macierzy do testów manualnych i farma do automatyzacji i szerokiej puli. Zapytaj dostawcę, które urządzenia ma fizycznie, z jakiej farmy korzysta, kto płaci za minuty i czy koszt farmy jest wliczony w stawkę, czy fakturowany osobno. Jeśli płacisz za farmę bezpośrednio, masz kontrolę nad kosztem i zachowujesz dostęp po zakończeniu współpracy.
Kiedy emulator lub symulator wystarczy, a kiedy nie?
Emulatory Androida i symulatory iOS są darmowe, szybkie i łatwo je uruchomić w CI. Dla programistów są codziennym narzędziem, a w testach mają swoje miejsce, ale nie zastąpią prawdziwych urządzeń w testach przed wydaniem.
Emulator dobrze sprawdza się do szybkich testów automatycznych przy każdej zmianie w kodzie, testów logiki i interfejsu na różnych rozmiarach ekranu, testów różnych wersji systemu i lokalizacji. Jest najtańszym sposobem na wczesne wykrycie regresji, zanim build trafi do testerów.
Emulator nie odda wiernie wydajności prawdziwego sprzętu, zwłaszcza słabszego, zachowania nakładek producentów, pracy z aparatem, czujnikami, Bluetooth i NFC, zużycia baterii ani realnych warunków sieciowych. Symulator iOS nie jest emulatorem sprzętu, tylko uruchamia aplikację skompilowaną na komputer, więc część problemów z wydajnością i pamięcią w ogóle się na nim nie pojawi.
Rozsądny podział wygląda tak: emulatory i symulatory w CI do szybkiej informacji zwrotnej przy każdej zmianie, farma urządzeń do automatycznej regresji na prawdziwym sprzęcie przed wydaniem, fizyczne urządzenia do testów manualnych, eksploracyjnych i sprzętowych. Jeśli oferta opiera całe testowanie na emulatorach, zapytaj, jak dostawca sprawdzi problemy, które widzą Twoi użytkownicy na konkretnych modelach.
Testy manualne czy automatyczne w aplikacjach mobilnych?
To nie jest wybór „albo, albo”. Pytanie brzmi: które testy automatyzować, a które zostawić ludziom, i ile kosztuje każda decyzja.
Automatyzacja opłaca się dla stabilnych ścieżek krytycznych, powtarzanych przy każdym wydaniu: rejestracja i logowanie, wyszukiwanie, koszyk i płatność, kluczowe formularze. Przy wydaniach co dwa tygodnie na dwóch platformach ręczna regresja tych ścieżek na kilku urządzeniach szybko staje się największą pozycją w budżecie testów. Automatyzacja pozwala uruchamiać je na farmie urządzeń w CI, nocą i przy każdym kandydacie do wydania.
Ręczne testy są lepsze dla nowych funkcji, które jeszcze się zmieniają, użyteczności i gestów, testów eksploracyjnych, w których tester szuka problemów, jakich nikt nie przewidział, oraz testów sprzętowych i w terenie. Tu automatyzacja jest droga w budowie i utrzymaniu, a jej wartość niska.
Narzędzia do automatyzacji mobilnej dzielą się na wieloplatformowe i natywne. Appium pozwala pisać testy dla iOS i Androida w jednym podejściu i jest jednym z narzędzi wymienianych przez ARDURA na stronie usług testowania oprogramowania. Narzędzia natywne platform, takie jak Espresso dla Androida i XCUITest dla iOS, są szybsze i stabilniejsze, ale wymagają dwóch zestawów testów i bliższej współpracy z kodem aplikacji. Wybór zależy od tego, kto będzie utrzymywał testy, czy aplikacja jest natywna, czy cross-platformowa, i ile ścieżek ma być automatyzowanych.
Pamiętaj, że automatyzacja ma koszt utrzymania: każda zmiana interfejsu wymaga aktualizacji testów. O tym, ile kosztuje budowa i utrzymanie automatyzacji, piszemy w artykule Ile kosztuje automatyzacja testów w 2026 roku?. W zapytaniu ofertowym poproś o wycenę automatyzacji osobno od testów manualnych, z szacunkiem utrzymania w kolejnych miesiącach.
Jak wygląda harmonogram zlecenia i rytm testów przy wydaniach?
Usługa testów mobilnych występuje zwykle w jednym z dwóch kształtów: jednorazowe zlecenie przed premierą lub dużym wydaniem albo stała współpraca w rytmie wydań. Harmonogram i koszt są w obu przypadkach inne.
Jednorazowe zlecenie przed premierą trwa zwykle od dwóch do czterech tygodni. Pierwszy tydzień to analiza aplikacji, ustalenie macierzy urządzeń, przygotowanie przypadków testowych dla ścieżek krytycznych i kont testowych. Drugi i trzeci tydzień to wykonanie testów na urządzeniach, zgłaszanie błędów, retesty poprawek. Ostatnie dni to test kandydata do wydania, sprawdzenie aktualizacji z poprzedniej wersji i raport z rekomendacją: wydajemy albo nie.
Stała współpraca działa w rytmie wydań. Przy wydaniach co dwa tygodnie typowy cykl to testy nowych funkcji w trakcie sprintu, regresja na rdzeniu macierzy przed wydaniem, szybki test na szerokiej puli w farmie, test aktualizacji i test po publikacji. Z czasem rosnąca część regresji przechodzi do automatyzacji, a testerzy skupiają się na nowych funkcjach i testach eksploracyjnych.
Jest też trzeci rytm, o którym zamawiający często zapominają: nowe wersje systemów operacyjnych. Apple i Google co roku wydają duże aktualizacje iOS i Androida, poprzedzone publicznymi wersjami beta. Nowa wersja systemu potrafi zmienić zasady uprawnień, pracy w tle, powiadomień czy wyglądu elementów interfejsu, a użytkownicy instalują ją niezależnie od Twojego kalendarza wydań. Dobrze zaplanowana usługa uwzględnia test aplikacji na wersji beta nowego systemu, zanim trafi on do użytkowników, oraz szybki test regresji po jego premierze. Jeśli oferta stałej współpracy o tym nie wspomina, zapytaj, jak dostawca obsługuje premiery systemów i czy ten test jest w cenie, czy wyceniany osobno. Przy zleceniach jednorazowych warto po prostu zaplanować taki test raz w roku, w okresie poprzedzającym premierę nowego systemu, bo właśnie wtedy rośnie ryzyko recenzji typu „po aktualizacji przestało działać”, które otwierają ten artykuł.
Na harmonogram wpływa też proces publikacji, którego nie da się przyspieszyć. Dla nowych kont deweloperskich w Google Play obowiązuje dodatkowy wymóg: według pomocy Google Play Console konta osobiste utworzone po 13 listopada 2023 roku muszą przeprowadzić zamknięty test aplikacji z co najmniej 12 testerami, którzy są do niego zapisani nieprzerwanie przez co najmniej 14 dni, zanim aplikacja trafi do produkcji. Jeśli to Twój przypadek, uwzględnij te dwa tygodnie w planie premiery i zapytaj dostawcę, czy może pomóc w organizacji takiego testu.
Od czego zależy cena testów aplikacji mobilnych?
Cena usługi to głównie liczba osobodni testerów pomnożona przez stawkę, plus koszt dostępu do urządzeń. Stawki QA są w ofertach podobne; różnice w wycenach wynikają z liczby dni, a ta zależy od czynników z poniższej tabeli.
| Czynnik | Co obniża koszt | Co podnosi koszt | Pytanie kontrolne |
|---|---|---|---|
| Platformy i technologia | Jedna platforma albo aplikacja cross-platform z prostym interfejsem | iOS i Android natywnie, osobne bazy kodu, tablety | Czy obie platformy mają ten sam zakres funkcji? |
| Liczba ekranów i ścieżek | Kilka ekranów, proste formularze | Dziesiątki ekranów, wieloetapowe procesy, role użytkowników | Które ścieżki są krytyczne dla przychodu? |
| Macierz urządzeń | Kilka urządzeń w rdzeniu, jednolity sprzęt użytkowników | Kilkanaście urządzeń w rdzeniu, duże zróżnicowanie Androida | Co pokazuje analityka o urządzeniach użytkowników? |
| Integracje sprzętowe | Brak, tylko ekran i sieć | Bluetooth, NFC, aparat, GPS, biometria, płatności | Czy testy wymagają fizycznego kontaktu z urządzeniem? |
| Integracje zewnętrzne | Jedno API własne | Płatności, mapy, logowanie społecznościowe, systemy partnerów | Czy dostępne są środowiska testowe integracji? |
| Bezpieczeństwo | Podstawowe sprawdzenie w ramach testów funkcjonalnych | Test bezpieczeństwa wg OWASP MASVS, testy API, analiza buildu | Jakie dane przetwarza aplikacja? |
| Automatyzacja | Brak albo istniejące testy do utrzymania | Budowa frameworka od zera na dwie platformy | Ile ścieżek ma być automatyzowanych i kto je utrzyma? |
| Rytm wydań | Kilka wydań w roku | Wydania co tydzień lub co dwa tygodnie | Ile razy w miesiącu potrzebna jest regresja? |
| Dostęp do urządzeń | Farma opłacana bezpośrednio przez Ciebie, mała pula | Duża pula, urządzenia prywatne, zakup sprzętu | Kto płaci za farmę i sprzęt? |
| Lokalizacja | Jeden język | Wiele języków, pisma od prawej do lewej, formaty regionalne | W ilu językach działa aplikacja? |
Dwa czynniki najczęściej zaskakują zamawiających. Pierwszy to podwójna platforma: aplikacja natywna na iOS i Androida to w praktyce dwie aplikacje do przetestowania, a nie jedna na dwóch telefonach. Drugi to rytm wydań: koszt regresji mnoży się przez liczbę wydań, więc przy częstych wydaniach automatyzacja przestaje być opcją, a staje się sposobem na ograniczenie kosztu.
Ile to kosztuje: jak policzyć widełki samodzielnie?
Jednego cennika testów mobilnych nie ma, ale widełki da się policzyć ze stawki i liczby dni. Zacznij od stawki: w cenniku ARDURA inżynier QA na poziomie senior kosztuje 1 440–2 000 PLN netto za dzień, a testerzy manualni zaczynają od 560 PLN netto za dzień (cennik). Szerszy obraz stawek rynkowych znajdziesz w artykule Stawki outsourcingu QA w Polsce i CEE w 2026 roku.
Poniższe widełki to nasz szacunek dla typowych zleceń, a nie fakt rynkowy ani cennik; przesuwają je czynniki z tabeli wyżej.
- Test przed wydaniem prostej aplikacji (jedna platforma lub cross-platform, kilkanaście ekranów, macierz kilku urządzeń, testy manualne funkcjonalne i kompatybilności, raport): około 5–10 osobodni. Przy stawce seniora to rząd 7 000–20 000 PLN netto, mniej, jeśli część pracy wykonuje tester manualny o niższej stawce.
- Test przed premierą aplikacji na iOS i Androida (kilkadziesiąt ekranów, kilka integracji, macierz kilkunastu urządzeń, warunki sieciowe i przerwania, podstawowe bezpieczeństwo, retesty): około 10–20 osobodni, czyli rząd 14 000–40 000 PLN netto.
- Stała współpraca w rytmie wydań (regresja co dwa tygodnie na dwóch platformach, testy nowych funkcji, stopniowa automatyzacja ścieżek krytycznych): liczona miesięcznie jako koszt jednej lub kilku osób w zespole, plus dostęp do farmy urządzeń.
Do kosztu pracy dolicz dostęp do urządzeń. Przy farmie rozliczanej za minutę koszt zależy od długości testów i liczby urządzeń; dla przykładu godzinny przebieg testów automatycznych na 10 urządzeniach w AWS Device Farm to 600 minut urządzenia, czyli według cennika 102 USD. Przy częstych przebiegach bardziej opłacalny bywa plan ze stałą liczbą slotów. Jeśli kupujesz fizyczne urządzenia, policz ich koszt na kilka lat i dodaj czas na aktualizacje systemów i wymianę.
Proś o wycenę w osobodniach z rozbiciem na obszary testów i platformy. Dzięki temu zobaczysz, czy dostawca wycenił dwie platformy, czy jedną, i ile czasu przewidział na kompatybilność i retesty.
Co przygotować po swojej stronie, żeby nie przepłacić?
Jak w każdej usłudze testowej, najdroższe osobodni to te, które tester spędza na czekaniu. W testach mobilnych źródeł oczekiwania jest więcej niż w webowych, więc przygotowanie po Twojej stronie ma bezpośredni wpływ na rachunek.
Dystrybucja buildów. Ustal, jak testerzy dostają nowe wersje: TestFlight dla iOS, wewnętrzna lub zamknięta ścieżka testów w Google Play albo inne narzędzie dystrybucji. Testerzy muszą być dodani do grup testowych przed startem, a buildy muszą trafiać do nich automatycznie z CI.
Konta i dane testowe. Konta użytkowników w różnych rolach i stanach (nowy użytkownik, użytkownik z historią, konto zablokowane), karty testowe bramki płatności, dane w środowisku testowym. Bez nich połowa ścieżek jest nie do przetestowania.
Środowisko testowe backendu. Aplikacja mobilna jest tak stabilna, jak API, z którym rozmawia. Jeśli środowisko testowe backendu jest niestabilne albo często resetowane, testerzy zgłaszają błędy, które nie są błędami aplikacji.
Macierz urządzeń z analityki. Wyeksportuj dane o modelach i wersjach systemu użytkowników. To skraca pierwszy tydzień i chroni przed testowaniem na niewłaściwym sprzęcie.
Kryteria wydania. Kiedy wydanie jest gotowe? Na przykład: brak otwartych błędów krytycznych i wysokich, ścieżki krytyczne przechodzą na całym rdzeniu macierzy, aktualizacja z poprzedniej wersji nie traci danych. Bez kryteriów raport z testów nie może zakończyć się rekomendacją.
Proces zgłaszania błędów. Szablon zgłoszenia z modelem urządzenia, wersją systemu, wersją aplikacji, krokami i nagraniem ekranu oraz ustalone, kto po Twojej stronie przyjmuje zgłoszenia i nadaje priorytety.
Jakie pytania zadać dostawcy i co zapisać w umowie?
Siedem pytań pomaga oddzielić dostawcę, który testuje Twoją aplikację, od dostawcy, który testuje na swoich telefonach.
Jak zbudujecie macierz urządzeń? Dobra odpowiedź zaczyna się od Twojej analityki. Zła odpowiedź zaczyna się od listy urządzeń, które dostawca ma.
Które urządzenia macie fizycznie, a z jakiej farmy korzystacie? Poproś o listę i o informację, kto płaci za farmę.
Jak dzielicie testy manualne i automatyczne? Szukaj uzasadnienia opartego na ryzyku i rytmie wydań, a nie deklaracji „automatyzujemy wszystko”.
Jakie macie doświadczenie z obiema platformami? Testy iOS i Androida wymagają znajomości ich różnic: uprawnień, pracy w tle, powiadomień, procesu publikacji. Poproś o rozmowę z osobą, która będzie testować.
Jak wygląda zgłoszenie błędu i raport z cyklu? Poproś o przykład. Zgłoszenie bez modelu urządzenia, wersji systemu i nagrania jest dla programisty mało przydatne.
Jak testujecie bezpieczeństwo? Jeśli aplikacja przetwarza wrażliwe dane, zapytaj o odniesienie do OWASP MASVS i o to, czy test obejmuje API.
Czyje są przypadki testowe i skrypty automatyzacji? Odpowiedź powinna brzmieć: Twoje, w Twoim repozytorium i narzędziach.
W umowie zapisz zakres obszarów testów, macierz urządzeń z zasadą jej aktualizacji, model rozliczeń i sposób rozliczania farmy, kryteria wydania, format raportów, własność artefaktów z przeniesieniem autorskich praw majątkowych do przypadków testowych i skryptów na wymienionych polach eksploatacji, zasady dostępu do buildów i danych oraz umowę powierzenia, jeśli testerzy mają dostęp do danych osobowych. Przy stałej współpracy dodaj warunki wymiany specjalistów i okres wypowiedzenia. O tym, jak porównywać modele rozliczeń, piszemy szerzej w artykule Ile kosztuje outsourcing testów oprogramowania.
Jakie sygnały ostrzegawcze w ofercie powinny Cię zatrzymać?
Niektóre oferty da się ocenić bez rozmowy, po kilku sygnałach w treści.
Liczba urządzeń bez uzasadnienia. „Testy na 50 urządzeniach” brzmi imponująco, ale jeśli nikt nie zapytał o Twoich użytkowników, 50 urządzeń może nie obejmować tych, które mają znaczenie.
Brak rozróżnienia platform. Wycena, która nie mówi, czy obejmuje iOS, Androida, czy obie platformy, i ile czasu przypada na każdą, zwykle oznacza, że jedna z nich będzie przetestowana pobieżnie.
Wyłącznie emulatory. Oferta oparta tylko na emulatorach i symulatorach jest tania, ale nie wykryje problemów z wydajnością, nakładkami producentów i sprzętem.
Rozliczanie za liczbę zgłoszonych błędów. Nagradza ilość, a nie wagę. Dostaniesz dużo zgłoszeń kosmetycznych i duplikatów.
Automatyzacja bez kosztu utrzymania. Wycena budowy testów automatycznych bez słowa o ich utrzymaniu oznacza, że za pół roku zapłacisz ponownie.
Brak kryteriów wydania i rekomendacji. Raport, który kończy się listą błędów bez odpowiedzi na pytanie „czy wydajemy”, zostawia decyzję Tobie, bez informacji, której potrzebujesz.
Skrypty i przypadki u dostawcy. Jeśli artefakty zostają w narzędziach dostawcy, przy zmianie dostawcy zaczynasz od zera.
Brak testu aktualizacji. Wielu użytkowników nie instaluje aplikacji od nowa, tylko aktualizuje ją z wersji sprzed kilku miesięcy, z zapisanymi danymi i ustawieniami. Jeśli oferta przewiduje testy wyłącznie na świeżej instalacji, nie wykryje błędów migracji danych i utraty sesji po aktualizacji, czyli dokładnie tego, na co skarżą się recenzje „nie działa po aktualizacji”.
Żaden z tych sygnałów nie dyskwalifikuje dostawcy automatycznie, ale każdy wymaga pytania i odpowiedzi na piśmie przed podpisaniem umowy.
Jakie są kluczowe wnioski?
Testy aplikacji mobilnych jako usługa to zakup trzech rzeczy: pracy testerów, dostępu do urządzeń i wiedzy o platformach. Oferty różnią się tym, ile każdej z nich zawierają, więc porównuj je dopiero po ustaleniu zakresu, macierzy urządzeń i podziału na testy manualne i automatyczne.
Zapamiętaj sześć rzeczy. Po pierwsze, zakres dobierz do problemu: regresja i kompatybilność na awarie po wydaniach, bezpieczeństwo według OWASP MASVS przy danych wrażliwych, testy sprzętowe przy integracjach z urządzeniem. Po drugie, macierz urządzeń buduj z analityki użytkowników w trzech warstwach: rdzeń, skrajne przypadki i szeroka pula. Po trzecie, łącz farmę urządzeń w chmurze z kilkoma fizycznymi telefonami; emulatory zostaw do szybkich testów w CI. Po czwarte, automatyzuj stabilne ścieżki krytyczne, a nowe funkcje, użyteczność i sprzęt testuj ręcznie. Po piąte, cena to osobodni razy stawka plus urządzenia; test przed premierą aplikacji na dwie platformy to szacunkowo 10–20 osobodni. Po szóste, przygotuj dystrybucję buildów, konta testowe i kryteria wydania przed startem, bo czekanie testerów to najdroższa pozycja w rachunku.
Więcej o testowaniu znajdziesz w hubie Quality Assurance. Jeśli przygotowujesz premierę aplikacji albo chcesz zatrzymać spadek ocen w sklepie, zobacz, jak prowadzimy testy mobilne w ramach usług testowania oprogramowania, a jeśli potrzebujesz stałego wsparcia w zespole, sprawdź testerów mobilnych w modelu body leasingu. Możesz też umówić krótką rozmowę o zakresie: ustalimy, jakie obszary testów i jaka macierz urządzeń mają sens dla Twojej aplikacji i ile to będzie kosztować.