Automatyzacja testów aplikacji mobilnych. Od czego zacząć?

Era mobile nastała. Rozwiązania mobilne mają coraz wyższy udział w rynku, co widać również w oczekiwaniach pracodawców IT. Od zespołów projektowych oczekuje się coraz szerszych kompetencji w zakresie automatyzacji testów. W tekście zebrałem wskazówki pomocne przy procesie automatyzacji. Sprawdź, o czym nie możesz zapomnieć.

Korzyści jakie niesie za sobą automatyzacja to m.in. szybkość wdrażania nowej wersji na produkcję, ciągły feedback przy zmianach kodu oraz odciążenie manualnych testerów od nudnej, kolejnej iteracji testów. Istnieje pokaźna liczba narzędzi, które pozwalają automatyzować testy na różnych poziomach oraz odmiennych składowych naszych systemów np. stron WWW (Selenium Webdriver, Cypress) czy serwisów API (REST Assured). Podobnie z aplikacjami mobilnymi (Espresso, XCTest, Appium), które coraz częściej wypierają desktop. Trend nazwany Mobile First jest już rzeczywistością.

Automatyzacja – na co należy zwrócić uwagę?

Załóżmy, że jesteś testerem, który ma wybrać i wdrożyć testy automatyczne aplikacji mobilnej o architekturze klient-serwer, pisanej na urządzenia z systemami iOS oraz Android. Zabierasz się do pracy, wpisujesz w Google „Test automation for mobile apps”, wybierasz narzędzie np. Appium, bo znasz już Javę i zaczynasz działać. Zatrzymaj się w tym miejscu! A co, gdyby podejść do zagadnienia trochę inaczej?

Krok 1 – ustal cel biznesowy

Automatyzacja testów jest oddzielnym projektem, często równie skomplikowanym, co sama testowana aplikacja. Zanim dokonasz wyboru narzędzia, odpowiedz na pytania:

1. Co chcesz osiągnąć dzięki automatyzacji testów?
2. W czym testy automatyczne mają pomóc?
3. Jak automatyzacja testów wpisze się w strategię testowania obraną dla tego projektu?
4. Jakie oczekiwania ma klient końcowy?

Pytania, które tutaj postawisz zależą od kontekstu oraz tego, na jakim etapie jest już projekt. Inne cele możesz sobie postawić w momencie startu projektu. Odmienne, gdy aplikacja jest w fazie utrzymania, a jeszcze inne, gdy aplikacja jest na produkcji i trwa development kolejnych funkcjonalności.

Przykładowa lista celów:

• automatyzacja testów dymnych przed wydaniem nowej wersji, aby szybciej potwierdzić gotowości aplikacji,
• przyśpieszenie weryfikacji nowo przygotowanej wersji aplikacji ze względu a dużą bazę testów manualnych, a co za tym idzie czasochłonność ich wykonywania,
• implementacja testów automatycznych na bieżąco z trwającymi pracami,
• zaimplementowanie konceptu piramidy testów (dowiedz się więcej o piramidzie testów pgs-soft.com/blog/test-pyramid-in-practice).

Nie wszystko uda się osiągnąć od razu. Dlatego warto obrać cele krótkoterminowe, z równoczesnym ustaleniem celów długoterminowych. Mniejsze cele, od których zaczniemy pracę, będą nas przybliżać do realizacji tych większych. Takie podejście pozwala mierzyć progres całego projektu oraz uzasadniać decyzje podejmowane na dalszym etapie.

Przykładem może być zamiar uruchamiania testów na prawdziwych urządzeniach (np. na chmurze urządzeń AWS czy Browserstack’a), wtedy zaczniesz tylko z symulatorami oraz emulatorami, których to integracja i użycie jest prostsze do wdrożenia. Pomaga tutaj analiza i wybranie tzw. low hanging fruits.

Krok 2 – ustal, kto będzie automatyzował testy

Kolejnym istotnym pytaniem, na które trzeba odpowiedzieć jest to, kto będzie odpowiedzialny w zespole za tworzenie, implementację, utrzymanie i zarządzanie testami automatycznymi. Wpłynie to na decyzję przy wybraniu konkretnego narzędzia oraz języka, w którym testy będą implementowane. Jeżeli chcemy wprowadzić podejście, w którym do testów podchodzimy kompleksowo (testujemy automatycznie nie tylko scenariusze systemowe i biznesowe, ale także tworzymy testy integracyjne, komponentów oraz jednostkowe), to w testy będą również zaangażowani programiści.

W takim przypadku większą korzyść przyniesie wybór natywnych frameworków (Espresso + XCTest) oraz języków (Swift i Kotlin). Programiści mogą zapewnić wsparcie przy rozszerzaniu naszego frameworka testowego, implementowaniu łatwiej testowalnej architektury aplikacji oraz tworzeniu i utrzymaniu testów, także tych end-to-end. Wybór ten może jednak spowodować konieczność nauki przez testerów nowych, dotąd nieznanych im języków programowania.

W innej sytuacji, gdy naszym celem jest implementacja jedynie testów end-to-end, a członkowie naszego zespołu znają na ten moment np. tylko język Java, to Appium może okazać się najlepszym wyborem. Podobną decyzję należałoby rozważyć w momencie, gdy testerzy nie są częścią zespołu projektowego i nie współpracują z programistami, a testy automatyczne są oddzielnym projektem. Ponownie cel biznesowy automatyzacji testów ma kluczowe znaczenie.

Oferty pracy z

Krok 3 – wybierz odpowiednie narzędzie

Gdy znamy i rozumiemy cel biznesowy wprowadzania automatyzacji testów, kolejnym krokiem jest wybranie najbardziej odpowiedniego do naszych potrzeb projektowych narzędzia. Jak już wspomniałem, istnieją różnego rodzaju rozwiązania, ale można podzielić je na dwa główne typy:

1. Natywne (np. Espresso + XCTest)
2. Międzyplatformowe (np. Appium)

Zalety rozwiązań natywnych to m. in.:

• kod testów jest częścią repozytorium kodu aplikacji, co ułatwia utrzymanie testów w synchronizacji wraz z rozwojem aplikacji oraz uruchamianie tych testów w systemach Continuous Integration przy każdej zmianie,
• kod testów jest w tym samym języku, co sama aplikacja, dzięki czemu można zaangażować programistów we współtworzenie i utrzymanie tych testów,
• szybka naprawa błędów oraz dostępność do funkcjonalności, ponieważ aktualizacje są tworzone przez twórców SDK dla iOS’a oraz Androida,
• bardzo dobra oficjalna dokumentacja,
• możliwość łączenia metryk pokrycia kodu z egzekucji testów, także end-to-end, z tymi z poziomu unit testów,
• w przypadku Espresso, mamy bezpośredni dostęp z kodu testów do kodu aplikacji (klas, modeli itd.), co ułatwia testowanie niektórych bardziej skomplikowanych funkcjonalności.

Wady rozwiązań natywnych to m.in.:

• konieczność nauki dwóch języków programowania oraz niuansów i różnic pomiędzy samymi narzędziami np. Espresso jest bardziej białoskrzynkowe, podczas gdy XCTest jest mocno czarnoskrzynkowy,
• problem synchronizacji testów pomiędzy dwiema platformami i łatwego pokrycia tych samych przypadków,
• różne podejścia odnośnie lokalizowania elementów,
• odmienne biblioteki wspierające testowanie oraz niedostępność adekwatnego odpowiednika dla drugiej platformy (np. brak jednej biblioteki do tzw. fluent assertions),
• inne systemy budowania artefaktów testowych,
• trudne zastosowanie scenariuszy pisanych w Gherkinie i np. Cucumbera dla obu platform.

Zalety Appium to m.in.:

• jeden język używany do implementacji testów, do wyboru wiele języków jak np. Java, Python itd.,
• łatwość dodania Cucumbera i używania scenariuszy pisanych w Gherkinie,
• wspólne repozytorium kodu testów dla obu platform,
• jednolite podejście do lokalizowania elementów,
• API Appium jest podobne do Selenium – może to ułatwić naukę tego narzędzia przez testerów automatyzujących do tej pory testy frontendu webowego.

Wady Appium to m.in.:

• synchronizacja testów z wytwarzaniem oprogramowania na obie platformy, gdy występują rozbieżności w funkcjonalnościach,
• konieczność obsługi akcji na widokach oddzielnie dla iOS’a i oddzielnie dla Androida – rzadko da się napisać uniwersalne lokatory elementów,
• Appium „pod spodem” oparte jest na rozwiązaniach natywnych, więc wszelkie poprawki błędów czy wsparcie dla nowych wersji systemów potrafi być opóźnione,
• jako kolejna „warstwa pośrednia”, może mieć swoje własne defekty,
• inny język używany do implementacji testów, utrudniający zaangażowanie programistów aplikacji natywnych w proces tworzenia testów automatycznych.

Powyższe listy wad i zalet są oczywiście niekompletne i w dużej mierze zależą od tego, jakie problemy napotkamy w naszej pracy.

Krok 4 – eksperymentuj, poprawiaj, rozwijaj

Gdy już wybierzesz swoje narzędzie i zaczniesz pracę, pamiętaj, aby nie spocząć na laurach. Co jakiś czas dokonaj rewizji swojej strategii automatyzacji oraz jej celów. Myśl o ewentualnych usprawnieniach oraz poprawkach dla stworzonego frameworka. Na bieżąco szukaj rozwiązań do napotkanych problemów – może ktoś stworzył bibliotekę, która umożliwi Ci osiągnąć Twój cel? Nie bój się eksperymentować! Coś, co kiedyś wydawało się trudne i nie warte pracy, teraz może mieć sens (szczególnie jeśli poszerzyłeś swoje umiejętności i nabrałeś nowych doświadczeń).

Przemyślana automatyzacja testów, specjalisto!

Artykuł nie jest odpowiedzią na wszystkie problemy, które mogą pojawić się przy wdrażaniu automatyzacji testów dla aplikacji mobilnej. Niemniej wzrost znaczenia kanału mobilnego dla użytkowników końcowych wymaga od testerów nauki automatyzacji również tego typu aplikacji. Z moich doświadczeń wynika, że proces ten nie jest aż tak trudny i żmudny. Często używam tutaj metafory mówiąc o składaniu mebli (nasze testy automatyczne) trochę innymi młotkami (narzędzia) niż w przypadku aplikacji webowych. Główne zasady, wzorce i najlepsze praktyki pozostają takie same.

Chcesz zgłębić temat? Poniżej przygotowałem listę pozycji, gdzie możesz znaleźć więcej inspiracji odnośnie podejścia i wyboru narzędzi do automatyzacji testów, jak również dobrych praktyk i pomysłów dotyczących samego ich projektowania oraz implementacji. Owocnej lektury!

• „Fifty Quick Ideas To Improve Your Tests” Gojko Adzic.
• „Lessons Learned in Software Testing: A Context-Driven Approach” Cem Kamer, James Bach, Bret Pettichord.

---

Zdjęcie główne artykułu pochodzi z unsplash.com.