W poprzednim artykule dotyczącym multiplatformowych aplikacji mobilnych skupiliśmy się na procesie tworzenia. Wyjaśnione zostały różnice sprzętowe, systemowe, ideologiczne. Nie jest to, oczywiście, pełna instrukcja, a raczej uproszczony przewodnik. Jego celem było uświadomienie czytelnikom, że mobilne systemy operacyjne różnią się na wielu poziomach, a ten najbardziej widoczny – czyli logo na obudowie smartfona – to tylko wierzchołek góry lodowej.
Jak można się domyślić, jeśli aplikacja ma działać na wielu platformach, to powinna być testowana na każdej z nich.
Uniwersalny kod
W poprzednim artykule poruszony został temat mnogości dostępnych języków programowania. Dla aplikacji multiplatformowych istotnym rozwiązaniem jest tu wybór narzędzi uniwersalnych, dzięki którym logika programu będzie dawała się zaimplementować na różnych systemach operacyjnych. Tutaj pojawia się pierwsze wyzwanie dla testerów.
Aplikacja na jednej platformie może działać, ale na drugiej nawet się nie zainstalować, a co dopiero uruchamiać. Jeśli wystąpi taki oczywisty błąd, wystarczy już tylko dotrzeć do jego źródła i naprawić wadliwy kod. Co jednak w sytuacji, gdy aplikacja pozornie działa, większość jej funkcji pozwala się wywołać i w mniej lub bardziej płynny sposób zwraca wyniki? Jeśli program uruchamia się na wirtualnej maszynie, ale na prawdziwym urządzeniu pojawia się awaria? Czy problemem jest tu komunikacja między hardware a interfejsem aplikacji, między interfejsem a procesami działającymi pod spodem, a może po prostu ten sam silnik zachowuje się inaczej zależnie od platformy, na jakiej został uruchomiony?
Mnogość konfiguracji
Do 2015 roku powstało ponad 24 tysiące różnych urządzeń z Androidem. W samym 2023 pod marką Redmi ogłoszono 16 smartfonów i tablet – a warto zaznaczyć, że to tylko jeden z brandów powiązanych z Xiaomi, poza nim ogłoszono też 4 modele spod szyldu POCO, a także 8 smartfonów i 3 tablety pod główną marką.
Oczywiście, nie jest tak, że współczesna aplikacja mobilna musi wspierać wszystkie modele urządzeń mobilnych znane ludzkości. Niemniej, należy się upewnić, że przynajmniej na tych najpopularniejszych smartfonach działa ona jak należy. Testerzy muszą więc sprawdzić program niezależnie na wielu urządzeniach. W przypadku iPhone jest to o tyle łatwe, że nawet jeśli aplikacja ma funkcjonować poprawnie na modelach, które już od dwóch lat nie dostają aktualizacji oprogramowania, w dalszym ciągu łączna liczba konfiguracji wynosi 32. Przypominam, że marki powiązane z Xiaomi ogłosiły 28 różnych smartfonów w samym 2023 roku.
W rzeczywistości różne sprytne sztuczki programowe i designerskie pozwalają ograniczyć ilość pracy dla testerów. Jeśli bowiem wzorcowy smartfon (na przykład QRD, czyli referencyjny model od Qualcomma) jest w stanie obsłużyć testowaną aplikację, to nie trzeba przecież sprawdzać każdego modelu z tym samym SoC. Jeżeli słabszy procesor radzi sobie z programem to wiadomo, że mocniejsza jednostka oparta na tej samej mikroarchitekturze nie będzie mieć problemów.
Znajomość specyfiki różnych systemów
Chyba każdy, kto kiedykolwiek zajrzał w sekcję komentarzy pod dowolnym artykułem o smartfonach na jakimkolwiek blogu technologicznym, miał okazję przyjrzeć się odwiecznej wojnie między fanami iOS i Androida. Nie muszę dodawać, że w oczach fanatyków obu platform używany przez nich system jest pozbawiony wad.
Tyle że to nieprawda.
Istotnym wyzwaniem podczas testowania aplikacji multiplatformowych jest więc pewna znajomość problemów i ograniczeń różnych rozwiązań. Taka wiedza jest niezbędna, gdyż pozwala na zwrócenie szczególnej uwagi na pewne nieoczywiste aspekty funkcjonowania aplikacji. Za przykład niech posłuży obsługa systemu BLIK na smartfonach Xiaomi z nakładką MIUI. Otóż, z powodu specyficznych restrykcji dotyczących aplikacji bankowych, powodujących automatyczne zamykanie ich po zminimalizowaniu, nie dało się korzystać ze wspomnianej metody płatności podczas zakupów online dokonywanych z poziomu smartfonu.
Problem nie dotyczył całego rynku urządzeń działających pod kontrolą Androida, a jedynie sprzętów od jednego producenta. Takie błędy, niestety, mogą zostać niezauważone, jeśli testy aplikacji nie będą przeprowadzane na odpowiednio dużej i zróżnicowanej grupie urządzeń.
Zróżnicowany poziom skomplikowania aplikacji
Rzecz wynikająca bezpośrednio z powyższych punktów. Uniwersalny kod nie rozwiązuje problemów powodowanych przez różnice między systemami, takich jak inne możliwości komunikowania się z hardware. Podczas gdy Android daje aplikacjom niemal nieograniczony dostęp do sprzętu czy pamięci masowej, programy dla iOS działają w piaskownicy. Oznacza to, że podczas testowania należy zwrócić szczególną uwagę nie tylko na to, co dzieje się wewnątrz apki i jak współpracuje ona z człowiekiem, ale też na aspekt wymiany danych między nią a systemem operacyjnym czy sprzętem.
Dobrym przykładem obrazującym problem jest software związany z audio. Aplikacje wykonujące te same zadania i działające równie szybko mogą napotkać problem, gdy przychodzi do komunikacji ze systemowym silnikiem audio. Jego konfiguracja, zależna zarówno od hardware i systemu operacyjnego jak i również decyzji każdego producenta smartfonów z osobna, może sprawiać, że na sprzęcie o podobnej specyfikacji program będzie działać bardziej lub mniej sprawnie zależnie od logo z tyłu urządzenia. Do pewnego stopnia można ten problem zniwelować, czasem jednak wystarczy odpowiednio zmodyfikować kod, a innym razem wręcz publikować specjalne instrukcje dla użytkowników lub uniemożliwić instalację programu na urządzeniach określonych producentów.
Jakie jest największe wyzwanie dla testera mobilnej aplikacji multiplatformowej?
Czy jest nim konieczność posiadania bardzo rozległej wiedzy na temat osprzętu współczesnych smartfonów? Dokładne rozumienie tego, jak działają różne systemy operacyjne? Niewątpliwie jest to ważne. Niemniej, zdaje się, że najistotniejsza jest świadomość fragmentacji ukrytej pod płaszczem duopolu iOS i Androida, a także zrozumienie, że nie wszystkie błędy da się łatwo naprawić.
