1.Automatyzacja testówNatalia Krawczyk

1.1. Opis przypadku

W obecnej firmie, w zespole, który liczy 10 programistów i 2 testerów, pracuję dla klienta ze Skandynawii. Pełnię funkcję zarówno starszego testera, jak i często test managera. Zajmuję się testami manualnymi, automatycznymi, konfiguracją środowisk deweloperskich, testowych oraz konfiguracją procesów ciągłej integracji. Po stronie klienta są jedynie menedżerowie projektów. Klient ten posiada kilku partnerów biznesowych, dla których dostarcza oprogramowanie. Jednym z klientów jest firma mająca hurtownię internetową. Otrzymaliśmy zlecenie naprawy istniejących błędów oraz utrzymywania aplikacji webowej będącej ich sklepem internetowym, który działa w trzech krajach. Aplikacja jest oparta o CMS Webnodes oraz korzysta z zewnętrznego SOAP[1] API[2], które dostarcza informacje o użytkownikach, klientach, ich zniżkach, zamówieniach oraz o samych produktach. Program został napisany w technologii .Net.

Wygląda to na dosyć typowy, "normalny" projekt informatyczny będący w fazie utrzymania. Niestety, szybko okazało się, że nie będzie łatwo. Natknęliśmy się na szereg problemów.

Firma, która tworzyła sam system, nie wykazała się dobrymi praktykami - nazewnictwo zastosowane w kodzie nie było napisane w języku angielskim, nie zastosowano żadnych prawidłowych wzorców. Kod aplikacji śmiało można było określić mianem "spaghetti code" - niewielka zmiana w kodzie powodowała nieprzewidywalne skutki. Do tego należy dodać, że nie dostaliśmy żadnej dokumentacji informującej nas o tym, jak powinien działać system, mogliśmy jedynie polegać na wiedzy czerpanej z kodu źródłowego.

Nie był to niestety koniec problemów - budżet na testowanie był bardzo ograniczony, a czasem nawet go nie było.

Początkowo to deweloperzy musieli dbać o jakość w projekcie. Jak wiadomo, testy wykonywane przez dewelopera są na najniższym poziomie niezależności testów, deweloper nigdy nie podejdzie tak krytycznie do swojego kodu jak niezależny tester.

Brak specyfikacji oraz bezpośredniego kontaktu z końcowym klientem był chyba najtrudniejszym problemem w tym projekcie. Często dowiadywaliśmy się o jakiejś funkcji poprzez nieświadome jej zepsucie. Nie mieliśmy na początku bezpośredniego kontaktu z końcowym klientem. Aby uzyskać odpowiedź na nasze pytanie, musieliśmy je przesłać do naszego klienta, następnie on je tłumaczył na język norweski i wysyłał zapytanie do klienta końcowego. Zdarzało się, że na odpowiedź czekaliśmy tydzień, a nawet dłużej. Próbowaliśmy ten problem rozwiązać poprzez utworzenie wspólnego czatu w systemie do komunikacji Slack, ale niestety nie skutkowało to szybszą komunikacją. Zyskaliśmy jedynie możliwość bezpośredniego kontaktu z klientem, który niestety odpisywał nam z dużym opóźnieniem.

W przypadku wdrożenia rozległych zmian bądź zmian w zakresie krytycznych funkcjonalności udawało nam się uzyskać kilka dodatkowych godzin na testy regresji. Niestety, bez pełnej dokumentacji i wiedzy na temat systemu testy te nie zawsze znajdywały wprowadzone błędy. W tym celu przygotowałam prostą listę kontrolną (ang. checklist) obejmującą podstawowe akcje, jakie należało przetestować przed wdrożeniem nowej wersji na środowisko produkcyjne.

Podsumowując, w projekcie było kilka problemów do rozwiązania:

- brak dokumentacji,

- brak procesu testowego,

- złej jakości kod źródłowy,

- ograniczona komunikacja z klientem.

1.2. Rozwiązanie problemu

Nie będę opisywać tutaj, jak deweloperzy poradzili sobie z naprawą kodu i jego refaktoryzacją. Chciałabym opowiedzieć głównie o problemie związanym z testowaniem aplikacji.

Czasami udawało nam się uzyskać dodatkowy budżet na testowanie, np. aby sprawdzić, jak aplikacja działa na różnych przeglądarkach, jednak mieliśmy poczucie, że nie robimy tego tak, jak należy. Brakowało nam dokumentacji, do której moglibyśmy się odnieść, testów automatycznych, które wspierały testowanie manualne, ogólnego procesu opisującego, jak powinniśmy postępować w przypadku każdego nowego zadania, aby utrzymać jak najwyższą jakość produktu. Bardzo często mówiliśmy o tym naszemu klientowi na spotkaniach statusowych. Pewnego dnia, gdy okazało się, że mam trochę luźniejszy czas w innych projektach u tego klienta, zostałam poproszona o przygotowanie propozycji: jak miałby wyglądać idealny proces testowy dla tego projektu, w jaki sposób chciałabym wdrożyć w nim testy automatyczne, aby skrócić czas testowania?

Początkowo przygotowałam ogólną odpowiedź, która zawierała listę rzeczy, które powinny być przygotowane (dokumentacja testowa, testy automatyczne), jak i pogląd na ogólny proces testowy dla tego projektu.

Jako warunki wstępne do wprowadzenia dobrego procesu testowego postawiłam:

- utworzenie dokumentacji testowej,

- wprowadzenie testów automatycznych UI na poziomie testów akceptacyjnych (otrzymaliśmy zgodę na 10 testów),

- zdefiniowanie i ustawienie procesu ciągłej integracji w Team City.

Następnie zdefiniowałam proces testowy (rys. 1.1) uwzględniający testowanie jednej funkcjonalności, jak i testowanie regresji przed wdrożeniem nowej wersji systemu na środowisko produkcyjne.

W przypadku każdej nowej funkcjonalności proces uwzględniał:

- analizę zadania w celu wyceny czasochłonności czynności testowych,

- dodanie nowej funkcjonalności do dokumentacji testowej bądź wprowadzenie zmian w istniejącej,

- napisanie testów automatycznych (o ile ma to w danym przypadku sens na warstwie UI),

- testowanie manualne z uwzględnieniem napisanej dokumentacji oraz testy eksploracyjne,

- zaraportowanie znalezionych defektów do Jiry,

- retesty (o ile znaleziono, zaraportowano i poprawiono nowe defekty).

Testowanie przed wdrożeniem nowej wersji na produkcję miało uwzględniać:

- uruchomienie testów automatycznych i analizę ich wyników,

- testy manualne na podstawie dokumentacji testowej (tylko funkcjonalności nieuwzględnione w testach automatycznych).

Szybko okazało się, że taki opis nie był wystarczający. Warunki wstępne zostały bardzo szczegółowo spisane i przedstawione końcowemu klientowi jako propozycja procesu testowego, dzięki któremu łatwiej będzie nam kontrolować jakość projektu. Dokument z propozycją zawierał szczegółowy opis składników dokumentacji testowej (wraz z kilkoma przykładami) oraz opis sposobu tworzenia testów automatycznych. Dodatkowym utrudnieniem wymagającym analizy i rozwiązania było niestabilne API. Pisząc testy automatyczne muszę podać w asercji oczekiwane rezultaty, takie jak: cena produktu, jego dostępność itp. Opierając się na testowym API, nie jesteśmy w stanie tego zrobić. Dzisiaj interfejs programistyczny aplikacji podaje nam cenę X dla produktu Y, ale jutro może nam zwrócić inną. Rozwiązaniem tego jest jego zamockowanie, czyli przygotowanie wcześniej gotowych odpowiedzi z API, zastąpienie API zaślepką, która odpytana zwróci przygotowane wcześniej odpowiedzi. Cała analiza była przeprowadzona przy współpracy z deweloperem, który wspierał mnie swoją wiedzą na temat architektury aplikacji i doświadczeniem. Zaproponowaliśmy 10 scenariuszy testowych, których weryfikacja powinna być według nas zautomatyzowana w pierwszej kolejności (były to scenariusze pokrywające kluczowe funkcjonalności systemu). Tak przygotowany dokument wraz z pełną estymacją został wysłany do końcowego klienta w celu zatwierdzenia. Po kilku dniach oczekiwań dostaliśmy zgodę na wykonanie zaplanowanych działań.

Rysunek 1.1. Zdefiniowany proces testowy

Rozpoczęłam od przygotowania dokumentacji testowej, która miała być bazą dla całego procesu testowego. Zaproponowana przeze mnie dokumentacja testowa napisana była w programie Microsoft Excel i składała się z 3 części:

1. Listy funkcjonalności - tabeli, na którą składały się kolumny: id funkcjonalności; nazwy modułu, którego dana funkcjonalność dotyczy; opis funkcjonalności zapisanego w postaci User story; link do arkusza, w którym znajdują się scenariusze testowe do danego user story; ilość zdefiniowanych scenariuszy testowych; ilość scenariuszy testowych pokrytych przez testy automatyczne; status testu; link oraz id zgłoszonego błędu w zewnętrznym systemie do zarządzania błędami (tab. 1.1).

2. Arkuszy zawierających dokładny opis funkcjonalności oraz scenariusze testowe do danego user story (wraz z przykładowymi danymi testowymi, statusem każdego scenariusza i ewentualnym linkiem do zgłoszonego błędu w Jirze).

3. Raportu zawierającego listę wszystkich user stories wraz z ich obecnym statusem: Before testing, Under testing, Positive, Negative.

Tabela 1.1. Lista funkcjonalności

Tabela 1.2. Arkusz z opisem funkcjonalności i odpowiadających jej scenariuszy testowych

Następnie zaczęłam pracę nad przygotowaniem testów automatycznych.

Testy automatycznie zostały napisane w języku C#, przy użyciu następujących narzędzi:

- nUnit (wersja 2.6),

- SeleniumWebDriver,

- Chrome WebDriver.

Ponieważ otrzymaliśmy zgodę na napisanie tylko 10 testów, postanowiłam zastosować nietypowe podejście, aby w trakcie tych 10 testów sprawdzić jak najwięcej. Pierwszy pomysł, jaki większości z nas w takiej sytuacji może przyjść do głowy, to zakończenie każdej akcji asercją - sprawdzeniem, czy akcja się wykonała, czy stan aplikacji się zmienił. Przykładowo, po otwarciu przeglądarki i przejściu do danej strony sprawdzilibyśmy asercją, czy tytuł strony jest odpowiedni, następnie po kliknięciu w przycisk zaloguj sprawdzilibyśmy asercją, czy pole do wpisana loginu jest wyświetlone, itp. Jak wiadomo jednak nie jest to najlepsze rozwiązanie: przy pierwszej asercji, która zwróci wynik negatywny (oczekiwany warunek nie zostanie spełniony), test zostanie przerwany, więc jeśli w aplikacji byłby błąd polegający na tym, że po zalogowaniu źle wyświetla się na przykład imię zalogowanego użytkownika (a ten warunek byłby sprawdzany po zalogowaniu), wszystkie napisane testy zakończyłyby się po zalogowaniu do aplikacji. Takim podejściem uzależniamy test sprawdzający jedną funkcję od warunków dotyczących zupełnie innych funkcji systemu. Dlatego zastosowałam trochę inne rozwiązanie. Postanowiłam sprawdzać w każdym teście jedną konkretną operację i weryfikować ją jak największą liczbą asercji.

Zanim opiszę dokładnie, na czym polega powyższa metoda, chciałabym przybliżyć narzędzie nUnit oraz jego możliwości, aby lepiej wytłumaczyć obrane przeze mnie podejście. nUnit jest narzędziem wykorzystywanym do pisania testów jednostkowych w języku programowania C#. Narzędzie to ma adnotacje, które określają, czy dana metoda w klasie jest testem ([Test]), czy powinna wykonywać się przed/po każdym teście ([SetUp] / [TearDown]), lub czy dana klasa jest zestawem testów ([Test fixture]). Standardowo - testy, określane adnotacją [Test], są niezależne od siebie, zawierają przygotowanie do testu, wykonanie samego testu oraz sprawdzenie jego wyniku.

Postanowiłam pozamieniać nieco role adnotacji: testem był cały zestaw testów, a sprawdzenie wykonanej operacji - pojedynczym testem. Wydaje się to na pierwszy rzut oka trochę zagmatwane, postaram się wytłumaczyć to na przykładzie testu sprawdzającego dodanie produktu do koszyka jako "niezalogowany użytkownik".

Przygotowanie do testu składałoby się wówczas z następujących czynności:

- uruchomienie przeglądarki;

- przejście do adresu testowanej aplikacji;

- przejście do strony produktu, który miałby być dodany do koszyka.

Większość tych akcji umieściłam w metodzie oznaczonej adnotacją SetUpFixture, czyli metodzie, która uruchomi się przed wykonaniem zestawu testów. Jednak tu należy bardzo uważać - jeśli wykonanie jakiejś metody, operacji zawartej w tym miejscu zakończy się wyjątkiem, zestaw testów oraz metoda oznaczona adnotacją [TearDown] nigdy się nie wykonają. Czemu zwracam na to uwagę?

W metodzie wykonującej się po zestawie testów lub po teście przeważnie wyłączamy przeglądarkę, kończymy procesy itp. Jeśli wszystkie nasze testy zostaną przerwane na metodzie SetUpFixture, na stacji roboczej, gdzie uruchamiamy testy, wszystkie uruchomione procesy, np. chrome.exe, pozostaną włączone i będą wymagały ręcznego zakończenia.

Wróćmy do naszego przykładu.

Akcja w tym teście jest tylko jedna - wybranie żądanej liczby egzemplarzy produktu i wciśnięcie przycisku "Dodaj do koszyka". Wykonanie tej operacji zamieściłam już w metodzie oznaczonej adnotacją [Test], ale sama nazwa metody zaczynała się od przedrostka "T001" - oznaczenia, że ta metoda wykona się jako pierwsza w danym zestawie testów. Nie jest to jakieś specjalne oznaczenie, tylko zwykły ciąg znaków wybrany przeze mnie. Testy w danym zestawie testów domyślnie uruchamianie są w kolejności alfabetycznej.

Kolejnym etapem testu jest sprawdzenie poprawności wykonania się operacji. Załóżmy, że będziemy sprawdzać:

- czy wyświetlił się komunikat o prawidłowym dodaniu produktu do koszyka,

- czy odpowiednio zmieniła się ilość produktów w koszyku wyświetlana w górnej części ekranu,

- czy po przejściu do strony koszyka dodany przez nas produkt się w nim znajduje,

- czy na stronie koszyka sumaryczna ilość dodanych produktów jest prawidłowa,

- czy na stronie koszyka sumaryczna kwota za dodane produkty jest prawidłowa.

Wymieniłam 5 sprawdzeń, więc potrzebujemy 5 asercji. Pierwszą z nich umieszczamy w teście "T001". Kolejną w teście z przedrostkiem "T002". W teście "T003" przed asercją jest wykonanie akcji przejścia do strony koszyka. Wykonanie jej jest obarczone ryzykiem, ale jeśli się nie uda, będziemy wiedzieli, że jedna z kluczowych funkcjonalności w systemie nie działa. Kolejne asercje umieszczamy również w osobnych testach.

W taki sposób zaimplementowałam 10 testów sprawdzających kluczowe operacje wykonywane przez użytkowników systemu. Dzięki nim wiedziałam, że nawet jeśli programiści będą zmuszeni wykonać wdrożenie nowej wersji systemu na środowisko produkcyjne bez testów manualnych (tylko na podstawie wyniku testów jednostkowych i napisanych przeze mnie testów automatycznych), podstawowe funkcjonalności na tzw. Money path (szeregu akcji zapewniającej klientowi zysk) będą działać poprawnie.

Równocześnie z implementacją testów automatycznych trwały prace nad przygotowaniem dedykowanego środowiska testowego z namiastką symulującą API. W tym celu użyliśmy programu SoapUI, dzięki któremu mogliśmy zamockować część interfejsu programistycznego aplikacji oraz przygotować odpowiedzi na zapytania. Pracę nad tym zadaniem wykonywał głównie deweloper, do niego należało przygotowanie aplikacji, aby zamiast odpytywać zewnętrzne API na przykład o dane użytkownika, zwracała się do przygotowanych mocków. Moją rolą w tym zadaniu było przygotowanie przykładowych odpowiedzi, które będą zwracane przez zamockowany interfejs programistyczny aplikacji. Do tego celu wykorzystałam przykładowe odpowiedzi z testowego API. Dzięki stałym odpowiedziom mogłam bez problemu zdefiniować oczekiwane rezultaty w asercjach w napisanych testach automatycznych oraz mogłam być pewna, że jeśli na stronie zostanie wyświetlona inna cena produktu niż się spodziewałam, wina będzie leżała po stronie aplikacji, a nie po stronie zewnętrznego API.

Kolejnym etapem było zdefiniowanie i skonfigurowanie nowego projektu w systemie ciągłej integracji (w tym przypadku TeamCity), który by instalował aktualną wersję na dedykowanym środowisku testowym z zamockowanym API i uruchamiał testy. Po wdrożeniu aktualnej wersji aplikacji na dedykowane środowisko testowe uruchamialiśmy procedurę sprawdzającą spójność bazy danych oraz sprawdzaliśmy, czy strona jest już dostępna. Jeśli aplikacja została poprawnie wdrożona, proces był kontynuowany. Jeśli aplikacja wciąż nie odpowiadała, kolejne etapy były pomijane. Dodatkowo, aby nie martwić się o dane pozostałe po teście, wprowadziliśmy również przywracanie bazy danych z momentu sprzed uruchomienia testów.

Rysunek 1.2. Proces testowania w TeamCity

Całościowo proces dla testów w TeamCity wyglądał następująco:

1. Pobierz aktualny kod źródłowy aplikacji z repozytorium.

2. Skompiluj kod.

3. Uruchom testy jednostkowe.

4. Zainstaluj aplikację z testowym plikiem konfiguracyjnym na środowisku testowym.

5. Uruchom procedurę sprawdzającą spójność danych i poczekaj aż się zakończy.

6. Wykonaj test wstępny (sprawdź, czy aplikacja jest gotowa do uruchomienia testów automatycznych).

7. Wykonaj backup bazy danych.

8. Uruchom testy automatyczne.

9. Przywróć backup bazy danych z punktu 7.

Wykonanie całego procesu trwało około 45 minut. Ponieważ nie było potrzeby, żeby uruchamiać te testy po każdej zmianie kodu w repozytorium, ustawiliśmy w TeamCity, aby proces uruchamiał się raz dziennie w nocy. W razie potrzeby uruchamialiśmy go też manualnie na żądanie.

1.3. Podsumowanie działań

Dzięki spełnieniu warunków wstępnych udało nam się wprowadzić ustandaryzowany proces testowy w przypadku każdego nowego zadania. Może on miejscami odbiegać od założeń przyjętych w pierwszym dokumencie opisu procesu, jaki stworzyłam, jednak sprawdza się bardzo dobrze w naszym przypadku. Składa się on obecnie z następujących etapów:

- analizy i estymacji - wykonywany jest wspólnie z deweloperem, podczas którego programista tłumaczy, co będzie zmienione oraz gdzie można spodziewać się błędów regresji, a tester zadaje pytania, analizuje przypadki użycia i zaczyna rozpisywać podstawowe przypadki testowe; wynikiem analizy było oszacowanie, ile godzin potrzeba na wykonanie zadania (zarówno czynności deweloperskich, jak i testerskich);

- projektowania testów - przeprowadzane jest przez testera, podczas którego do dokumentacji testowej dodawane są nowe scenariusze testowe lub modyfikowane już istniejące; po dopisaniu nowych scenariuszy tester przedstawia je deweloperowi w celu ich przeglądu;

- analizy wyników testów automatycznych - często jest wykonywana przez dewelopera, jak i przez testera; jeśli jakiś test zakończył się niepowodzeniem, należało sprawdzić, czy przyczyną był błąd na stronie, czy błąd w kodzie testów automatycznych, czy może problem ze środowiskiem testowym;

- wykonania testów manualnych nowej funkcjonalności - na podstawie napisanej wcześniej dokumentacji testowej;

- implementacji skryptów wykonujących testy automatyczne (o ile dana funkcjonalność tego wymagała);

- raportowania wyników testów;

- ewentualnych retestów;

- testów eksploracyjnych.

Do dziś stosujemy ten proces w przypadku nowych funkcjonalności. Wszystko jest uporządkowane i dobrze przetestowane. Testy automatyczne są bardzo stabilne, szybkie oraz zdarzyło im się parę razy znaleźć błędy regresji. Dodatkowo programiści docenili ten proces - dzięki wnikliwej analizie i rozpisywaniu przypadków testowych wiedzą na co powinni zwrócić uwagę przy dewelopmencie, co sprzyja powstawaniu mniejszej liczby usterek.

Niestety, opracowany przeze mnie proces testowy nie przyjął się w przypadku wdrożenia nowej wersji produktu. Przypomnę, że proces wymagał manualnego przetestowania wszystkich scenariuszy testowych niepokrytych przez testy automatyczne. Przyczyną niepowodzenia były zbyt wysokie koszty wykonania testów manualnych (szacowany był na 2-3 dni). Dlatego sam proces wykonania testów regresji uległ zmianie, składał się z:

- sprawdzenia i analizy wyników testów automatycznych;

- testów eksploracyjnych, obejmujących podstawowe funkcjonalności;

- dodatkowych testów funkcjonalności, które były obarczone największym ryzykiem (jeśli zmiany związane były np. z rejestracją konkretnego typu użytkownika, przeprowadzono testy dla wszystkich scenariuszy testowych związanych z rejestracją użytkownika, logowaniem użytkownika i edycją jego profilu) - o ile udało nam się na takie testy uzyskać zgodę.

1.4. Wnioski, zalecenia, rekomendacje

Wprowadzenie uporządkowanego procesu testowego przyniosło wiele korzyści. Jedną z nich jest zaangażowanie testera od momentu estymacji i analizy. Często, aby dobrze wyestymować daną zmianę, przeprowadzaliśmy analizy, podczas których już rozpisywaliśmy przypadki użycia i przykładowe scenariusze testowe, jakie będą sprawdzane podczas etapu testów danej funkcjonalności. Dzięki temu rzadko zdarzały się błędy we wprowadzanej zmianie - programiści implementując kod, od razu wiedzieli, na co zwrócić uwagę.

Testy automatyczne okazały się być bardzo przydatne, ponieważ wcześniej opracowany proces testowy nie mógł być w pełni wdrożony ze względu na brak środków na jego przeprowadzenie. Jeśli wszystkie testy automatyczne kończyły się sukcesem, mogliśmy stwierdzić, że przynajmniej podstawowe funkcjonalności, takie jak zakup produktów, będą działać prawidłowo. Dzięki temu, że testy używały zamockowanego API, można było na nich zawsze polegać. Praktycznie nie zdarzały się fałszywie negatywne wyniki (było kilka przypadków spowodowanych źle skonfigurowanym środowiskiem testowym).

2.Testowanie mobilnePiotr Wicherski

2.1. Opis przypadku

Nowoczesne narzędzia skutecznie wspomagają proces wytwarzania oprogramowania mobilnego. Pomimo bardzo szybkiego wzrostu popularności aplikacji i stron mobilnych, dojrzałość narzędzi i procesów jest wciąż na niższym poziomie niż w przypadku chociażby stron web. Już w maju 2015 roku raport Google ostatecznie potwierdził, że liczba wyszukiwań mobilnych jest większa niż tych wykonywanych z komputerów osobistych.

Jednym z najbardziej odstających obszarów jest testowanie mobilne. Narzędzia są niedojrzałe, a sam proces i kryteria wymagają jeszcze sporo pracy.

Rozdział ten jest zbiorem pomysłów i sugestii mających na celu wprowadzenie czytelnika w proces tworzenia projektu i budowania laboratorium urządzeń mobilnych (LUM). Konceptu, który ma być wsparciem procesu wytwarzania oprogramowania mobilnego poprzez zgrupowanie i udostępnienie urządzeń testowych. Czy to w sposób otwarty (rys. 2.2), czy zamknięty, w formie zabezpieczenia urządzeń w szafie rackowej (rys. 2.3). Potencjalnie koncept ten jest w stanie załagodzić jedne z głównych problemów, które napotykają testerzy oprogramowania mobilnego w trakcie automatyzacji aplikacji i stron mobilnych, takich jak:

- fragmentacja,

- wysoki koszt urządzeń,

- rozproszenie zespołów.

2.2. Fragmentacja

Problem fragmentacji urządzeń mobilnych osiągnął poziom, w którym pochłonął zarówno urządzenia z systemem Android, jak i te produkowane przez Apple z systemem iOS. Spowodowało to sytuację, w której pokrycie testami odpowiedniej liczby urządzeń w celu zapewnienia jak najlepszej jakości produktu staje się coraz trudniejsze. Problem jest o tyle poważny, że dotyczy zarówno fizycznych urządzeń zwanych smartfonami, jak i oprogramowania, które jest na nich preinstalowane przez producentów. Jeszcze niedawno fragmentacja była domeną urządzeń z sympatycznym zielonym robocikiem. Stan ten ulega ciągłemu pogorszeniu, co możemy zaobserwować dzięki statystykom ze strony Google Android Developers i raportowi, który tworzy od pewnego czasu OpenSignal[3].

Rysunek 2.1. Wizualizacja mnogości urządzeń występujących na rynku

Tabela 2.1. Liczba różnych urządzeń mobilnych w latach 2013-2015

Rok

2013

2014

2015

Urządzenia

11 868

18 796

24 093

W 2013 roku twórcy raportu poprawnie zidentyfikowali 11 868 różnych urządzeń. W następnym roku wartość ta wzrosła do 18 796, natomiast w raporcie z 2015 roku były to już 24 093 urządzenia. Zaobserwowano więc ponad 200% wzrost w ciągu zaledwie 2 lat. Jak zaznaczono jednak w raporcie, zidentyfikowane urządzenia nie są na pewno wszystkimi, jakie występują na świecie. Przypuszczalnie jest to co najwyżej zdecydowana większość.

Jako "różne urządzenia" rozumiemy tutaj podział zarówno na producentów, jak i modele danego urządzenia. Samsung Galaxy S3, Samsung Galaxy S7 i HTC Dream będą zatem liczone osobno. Podobnie rzecz ma się w przypadku platformy iOS. Rozpatrując tylko liczbę urządzeń wraz z możliwymi największymi aktualizacjami systemu operacyjnego, otrzymujemy ponad 80 możliwych kombinacji[4]. Wszystko jest oczywiście ograniczone grupą docelową, która została określona dla danego produktu.

Na fragmentację mają wpływ między innymi takie czynniki, jak:

- wielkość i gęstość wyświetlacza,

- pojemność pamięci wewnętrznej,

- pamięć RAM,

- architektura procesora,

- moduły, takie jak GSM czy GPS,

- czujniki,

- systemy operacyjne,

- nakładki na system operacyjny producentów,

- nakładki na system operacyjny tworzone przez społeczności,

- modyfikacje systemu pod operatorów sieci komórkowych,

- modyfikacje systemu spowodowane specyficznymi podzespołami,

- modyfikacje regionalne sprzętu i oprogramowania,

- modyfikacje sprzętu lub oprogramowania kierowane wymogami prawnymi.

Producenci, tacy jak Samsung czy Apple, co roku prześcigają się w patentowaniu nowych rozwiązań, które następnie stają się często nowymi komponentami ich flagowych urządzeń. Inwestując w swoje centra R&D setki milionów dolarów, napędzają rynek, zmieniając często futurystyczne - w mniemaniu klientów - pomysły w codzienność. Wprowadzanie takich gadżetów, jak czytnik linii papilarnych czy czujnik wilgotności, dodaje kolejne pozycje na i tak długiej liście funkcji, o których istnieniu powinny wiedzieć osoby odpowiedzialne za projektowanie aplikacji. Następnie będzie musiał zmierzyć się z nimi między innymi zespół odpowiedzialny za jakość mobilnego produktu. Android bez modyfikacji wspiera do 13 różnych czujników. Nie jest to jednak ostateczna liczba, ponieważ producenci (np. Samsung) tworzą własne modyfikacje urządzeń, takie jak wspomniany wcześniej czytnik linii papilarnych czy czujnik wilgotności powietrza (Samsung Galaxy S4 GT-I9500). Natomiast iOS w zależności od urządzenia wspiera do 10 czujników.

Temat fragmentacji nie ulegnie najprawdopodobniej poprawie w ciągu najbliższych lat ze względu na chęć spełniania indywidualnych oczekiwań klientów, jak też z powodu wysokich aspiracji wielu większych i mniejszych producentów. Pod pojęciem aspiracji w tym przypadku kryje się jedna z większych ciekawostek świata mobilnego ostatnich lat. Początek telefonów komórkowych był ciężki, proces trudny, a wymagania, które musiało spełniać urządzenie, aby trafiło na rynek, wysokie. Sytuacja jednak zmieniła się w podobny sposób jak w przypadku komputerów osobistych. Mimo że większość rynku należy do topowych graczy, to wyprodukowanie własnego komputera wysokiej jakości nie jest już najmniejszym problemem dla nawet najmniejszych firm z Dalekiego Wschodu. Identycznie sytuacja wygląda w przypadku sprzętów mobilnych, takich jak telefony czy zegarki.

"Xiaomi success inspires every man and his dog to make smartphones in China"[5].

Jest to cytat z jednego z artykułów opublikowanych przez agencję Reutera. Przedstawiają w nim między innymi to, jak prosto jest złożyć zamówienie w jednej z wielu chińskich fabryk na własny model telefonu. Nie można tego dokonać na kilkadziesiąt sztuk. Jednak kilkaset sztuk nie jest już żadnym problemem, a możliwość modyfikacji sprzętu jest ogromna. Dzięki temu wiele firm decyduje się na tworzenie własnych telefonów w celach czysto reklamowych. Niektórzy, jak na przykład PepsiCo, posuwają się do zbierania funduszy na wydanie swojego smartfonu poprzez portale crowdfoundingowe.

Jednym z głównych czynników, które wpłynęły na tak niesamowity wzrost popularności porywania się na tworzenie własnych urządzeń, jest ogromny sukces azjatyckiej firmy Xiaomi.

Takie firmy jak: Xiaomi czy ZTE swój sukces zawdzięczają po części największym graczom na rynku.

Przyjmijmy hipotetyczną sytuację, w której firma A, która jest jednym z największych producentów smartfonów, zleca wyprodukowanie stu tysięcy wyświetlaczy Super LCD3 pewnej firmie S, która ma swoje fabryki w Azji. Ze względu na umowę firma S jest zobowiązana dostarczyć dokładnie sto tysięcy sztuk wyświetlaczy Super LCD3 firmie A. Jednak ze względu na bardzo delikatny proces tworzenia takich wyświetlaczy, średnio 12% trafi na straty ze względu na niespełnienie przewidywanych standardów bądź uszkodzenie. Przeprowadzana jest dokładana analiza ryzyka i fabrykom zlecane jest wykonanie, przypuśćmy, stu dwudziestu pięciu tysięcy wyświetlaczy. Do fabryk następnie zamawiane są zasoby niezbędne do wyprodukowania co najmniej zleconej liczby wyświetlaczy. Po wykonaniu zlecenia fabryki raportują wyprodukowanie około stu ośmiu tysięcy wyświetlaczy gotowych do montażu w urządzeniach. Firma A kupuje tylko umówioną liczbę wyświetlaczy, ponieważ na to jest przygotowana. Firma S ma więc nadwyżkę w postaci ośmiu tysięcy wyświetlaczy Super LCD3 bardzo dobrej jakości. W tym momencie na scenę wkracza firma X, która w okazyjnej cenie odkupuje tę nadwyżkę. Jeżeli wspomniana firma X wykona odpowiednią liczbę podobnych operacji, to będzie w stanie wyprodukować urządzenie o wartości rynkowej znacznie przekraczającej poniesione koszty.

Opisany przypadek został przeze mnie bardzo uproszczony. Nie były to jedyne czynniki, w grę wchodziły też systemy zarządzania ludźmi, pracą, wielkość firmy, specyficzny rynek i tak dalej. Jednak skrócona forma przekazu w uproszczeniu pozwala ukazać co, między innymi, mogło wpłynąć na bardzo głośne początki kilku firm azjatyckich.

Tzw. "Inni", w rozumieniu tego raportu, to głównie firmy z Dalekiego Wschodu, których specjalizacją jest produkcja i dystrybucja urządzeń z niskiej i średniej półki cenowej.

Tabela 2.2. Liczba wysłanych przez producentów sztuk telefonów w milionach[6]

Firma

2014

2015

Samsung

318.2

324.8

Apple

192.7

231.5

Huawei

73.8

106.6

Lenovo

59.4

74.0

Xiaomi

57.7

70.8

Inni

599.9

625.2

Mamy na tym rynku także własnych graczy, takich jak MyPhone, Krüger&Matz, Manta, Modecom czy Pentagram. Nie osiągnęli oni jeszcze co prawda takich zysków jak światowi giganci, jednak lokalne sukcesy Krüger&Matz i względnie stabilna sytuacja MyPhone mogą sugerować, że nadal warto czekać na swój kawałek w ogromnym torcie całego świata.

Modyfikacje sprzętu lub oprogramowania kierowane wymogami prawnymi bardzo rzadko dotyczą urządzeń skierowanych na polski rynek. Zazwyczaj są spowodowane wygranymi pozwami z powodu naruszenia patentów. Jednymi z najdotkliwszych spraw były całkowity zakaz sprzedaży Samsunga Galaxy Tab 7.7 na terenie Unii Europejskiej i konieczność modyfikacji Samsunga Galaxy Tab 10.1 specjalnie na rynek niemiecki.

Oprócz aspektów fizycznych dużą rolę w procesie fragmentacji urządzeń odgrywa także oprogramowanie. Tutaj niestety bardzo obwinia się producentów urządzeń za zaprzestawanie wspierania większych aktualizacji dla urządzeń po 18-24 miesiącach od premiery. Z roku na rok okres wsparcia aktualizacji dla urządzeń skraca się. Najlepiej pod tym względem wypadają urządzenia z serii Nexus i produkty Apple, których średni okres wsparcia wynosi 38 miesięcy.

W momencie gdy urządzenie przestaje być wspierane, część użytkowników, nie chcąc tracić możliwości korzystania z najnowszych dobrodziejstw Androida dostarczanych przez Google, decyduje się na wgranie niestandardowego i zarazem zmodyfikowanego oprogramowania na swoje urządzenia. Tym oprogramowaniem są custom ROMy. Niestety, ze świecą aktualnie szukać świeżych statystyk odnośnie do liczby użytkowników tak zmodyfikowanego oprogramowania. Jeśli wierzyć częściowym statystykom opublikowanym przez osoby odpowiedzialne za dystrybucję CyanogenMod, to samych użytkowników korzystających z ich systemu w 2015 roku zarejestrowano ponad 50 milionów. Statystyka może być odrobinę przekłamana, ponieważ do wersji CM11 włącznie CyanogenMod był preinstalowany na przynajmniej kilku komercyjnie sprzedawanych urządzeniach. Sytuacja ta zmieniła się na rzecz CyanogenOS. Jednak nawet w przypadku pewnego przekłamania liczba kilkudziesięciu milionów użytkowników robi wrażenie. Jest wiele innych dystrybucji Androida, takich jak MIUI czy Oxygen OS, które oprócz możliwości ręcznego wgrania na wielu różnych telefonach, są też na wielu preinstalowane.

Kwestia wsparcia tak zindywidualizowanych oczekiwań użytkownika powinna zostać poważnie przemyślana. Osobiście sugerowałbym korzystanie z używanego sprzętu do doraźnego wsparcia użytkowników i pokrycia testami także na modyfikacjach, z których korzystają klienci niemający oficjalnego wsparcia producentów.

2.3. Koszt urządzeń i rozproszenie zespołów

Jeszcze w 2015 roku zgodnie z raportem ABI Research i The Wall Street Journal średnia cena iPhone'a to 687$ a urządzenia z systemem Android 254$. Kwoty te są oczywiście mocno uśrednione, ponieważ w momencie pisania tego rozdziału koszt telefonu iPhone 6s Plus (pamięć 128GB) to 949$, a urządzeń z Androidem to przykładowo nawet 418$ w przypadku BlackBerry PRIV (32GB), a w przypadku Samsung Galaxy S7 Edge (64GB) to 849$. Są to przykłady jednych z najdroższych sprzętów, które mamy możliwość spotkać na rynku urządzeń mobilnych. Podane kwoty są zawyżone ze względu na fakt, że do testów najprawdopodobniej (w zależności od testowanego produktu) wystarczą nam modele z mniejszą pamięcią wbudowaną, co pozwoli nam zaoszczędzić nawet 200$ w przypadku iPhone'a 6s Plus (16GB).

Niemniej, koszt zakupu takiego urządzenia jest nadal wysoki. Niewiele firm może sobie pozwolić na niekontrolowany zakup urządzeń w celu przeprowadzenia testów mobilnych, jeżeli jest konieczność posiadania fizycznych urządzeń. W dzisiejszych czasach coraz więcej firm ma oddziały IT rozsiane nie tylko po całym kraju, ale też po całym świecie. Pozwala również pracownikom pracować przez większość czasu w domu, nie licząc w pełni zdalnych posad. W takich okolicznościach, nawet w przypadku posiadania oddziałów tylko w Warszawie i Poznaniu, firma potencjalnie duplikuje część kosztów. Między innymi są to koszty związane z urządzeniami, z których powinny korzystać zespoły odpowiedzialne za tworzenie produktów mobilnych w celach chociażby sprawdzania kompatybilności w trakcie testów manualnych, automatyzacji, szybkiej weryfikacji pomysłów czy też sprawdzania większych aktualizacji systemu operacyjnego.

2.4. Problemy i wyzwania

Oto kilka problemów czy też wyzwań, którym trzeba będzie stawić czoło we wcześniejszej lub późniejszej fazie projektowania i tworzenia laboratorium. Dodatkowe rozwinięcie przedstawionych tematów znajduje się w części poświęconej sprzętowi.

Rysunek 2.2. Wizualizacja przykładowego modelu szafy, która ułatwi zarządzanie urządzeniami

2.4.1. Dobór urządzeń

Dobór odpowiednich urządzeń jest krytyczny dla efektywnego działania konceptu farmy. Na problem ten mają oczywiście wpływ wcześniej wspomniane czynniki determinujące poziom fragmentacji danej platformy. Można wesprzeć się narzędziami do analizy danych z aplikacji i stron. Pozwolą one określić urządzenia, z których użytkownicy korzystają najczęściej w odpowiedniej grupie docelowej dla danego produktu. Pomocne będą takie serwisy, jak Google Analytics czy Fabric. Możliwe też, że firma, w której pracujesz, prowadzi już takie statystyki lub wdrożyła własne rozwiązanie, dzięki któremu będziecie w stanie wybrać odpowiednie urządzenia. Liczba urządzeń, która powinna zostać przeznaczona na funkcjonowanie laboratorium, jest bardzo uzależniona od wyników wcześniej wspomnianych analiz, jak też od rezultatów, które planujesz osiągnąć. Idąc za przykładem takich firm jak Etsy, możemy przyjąć, że 10 do 12 urządzeń powinno wystarczyć. Trzeba jednak pamiętać o tym, że liczba urządzeń będzie uzależniona od celu farmy, czyli od problemu, który chcemy rozwiązać.

2.4.2. Zasilanie

Posiadanie wielu urządzeń w jednym miejscu wiąże się z potencjalnymi problemami infrastruktury. Każde urządzenie powinno być podłączone do komputera i w tym samym czasie otrzymywać zasilanie niezbędne do stałego funkcjonowania. W tym celu można wykorzystać huby USB lub huby USB z aktywnym zasilaniem, które mają dodatkowo zasilane porty. Przy większej liczbie urządzeń i mając odpowiedni budżet można skorzystać ze specjalnych hubów, które potrafią zasilać nawet do 48 urządzeń, zabezpieczając je przed przeciążeniem, jednocześnie pozwalając na komunikację poprzez interfejs USB z serwerem lub komputerem. Zasilanie jest potencjalnie jednym z poważniejszych problemów, nad którym trzeba się pochylić. Jeżeli urządzenia będą podłączone do zasilania przez całą dobę i będą zostawiane bez fizycznej opieki, to należy przedsięwziąć odpowiednie kroki razem z administratorem budynku lub innymi osobami odpowiedzialnymi za bezpieczeństwo w celu zabezpieczenia tak ich, jak i pozostałego sprzętu. Tak pozostawione urządzenia są niestety narażone na wiele usterek, takich jak uszkodzenie kabla USB, przegrzanie urządzenia (które może nastąpić na przykład w trakcie wykonywania testów gier mobilnych) czy samozapłon baterii. Urządzenia mobilne nigdy nie były idealne i chociaż najwięksi producenci gwarantują bezpieczeństwo swoich produktów, to rozmawiając z największymi dostarczycielami usług (firmami typu Cloud Infrastructure for Mobile Development), dowiedziałem się, że wybuchające urządzenia są jednym z ich największych utrapień. Oczywiście liczba urządzeń, z których korzystają dostawcy takich rozwiązań, często przekracza kilkaset czy nawet kilka tysięcy, więc prawdopodobieństwo, że przy stukrotnie mniejszej liczbie urządzeń, któreś ulegnie tak poważnemu uszkodzeniu, jest niezwykle małe. Jednak zawsze pozostaje pewne ryzyko, które powinno zostać według mnie przewidziane i przemyślane.

2.4.3. Chłodzenie

Wiele urządzeń, takich jak BlackBerry PRIV czy niektóre modele z serii Samsung Galaxy, mają tendencję do przegrzewania się. Najczęściej powodem jest specyficzny procesor graficzny. Jeżeli na urządzeniu będą przeprowadzane testy aplikacji natywnych, które nie wykonują wielu operacji, problem nie zostanie najprawdopodobniej nigdy zauważony. Nawet wielogodzinne testy automatyczne z wykorzystaniem narzędzi, takich jak Appium czy Espresso, i zwiększoną liczbą zapytań sieciowych nie powinny zwiększyć temperatury baterii o więcej niż 3°C w porównaniu z zachowaniem zwykłego użytkownika.

Problem pojawia się przy testowaniu gier lub aplikacji wykorzystujących moc obliczeniową urządzenia w większym stopniu niż przeciętnie. W takiej sytuacji należy zadbać o dodatkowe chłodzenie nie tylko miejsca, w którym znajduje się urządzenie, ale też jego samego, poprzez zastosowanie na przykład podkładek chłodzących, które będą znajdowały się tuż pod urządzeniem, rozebranie urządzenia ze zbędnych części mogących ułatwiać nagrzewanie, takich jak klapka, nakładki na wyświetlacz czy etui. Dobrym zabezpieczeniem może także okazać się zastosowanie aplikacji, która będzie informowała osoby odpowiedzialne w momencie, gdy urządzenie zacznie się przegrzewać. Aplikację taką można zainstalować zarówno na urządzeniu, jak i skorzystać ze skryptu na serwerze, który będzie odpytywał urządzenie o dane.

2.4.4. Przygotowanie urządzeń

Jednym ze sposobów na zdobycie potrzebnych urządzeń jest zakupienie modeli używanych bezpośrednio z portali aukcyjnych czy komisów. Dzięki temu zaoszczędzimy część budżetu, a egzemplarze te mogą zostać następnie użyte przy odtwarzaniu bardziej realnych scenariuszy testowych sprawdzających na przykład wpływ aplikacji na zużycie baterii lub prędkość odczytywania i przetwarzania danych na chociażby 5-letnim urządzeniu. Sprzęt niemający już gwarancji można z powodzeniem wykorzystać do instalowania zmodyfikowanego przez społeczność oprogramowania wcześniej wspomnianych custom ROMów, które są wgrywane przez użytkowników na ich urządzenia. Korzystanie z używanego sprzętu jest w tym konkretnym przypadku bardziej opłacalne, ponieważ większość producentów zawiera w swojej karcie gwarancyjnej informację o zakazie modyfikowania tej części oprogramowania pod groźbą utraty tejże gwarancji.

W zależności od podjętego planu testów warto też zastanowić się nad zostawieniem kilku urządzeń w stanie jak najbardziej zbliżonym do faktycznego stanu, w którym użytkownik będzie korzystał z danego produktu. Wciąż wiele telefonów ma bardzo mało pamięci wewnętrznej i pamięci RAM. Niekiedy zainstalowanie kilku najpopularniejszych w danym kraju aplikacji i na przykład zostawienie ich w tle pomaga odnaleźć przypadki brzegowe, na które może kiedyś trafić potencjalny użytkownik produktu. Najpopularniejsze aplikacje można bez problemu obejrzeć w Sklepie Play (Google Play Store) i App Store (Apple).

2.4.5. Przygotowanie testów

Oprócz przeprowadzania testów manualnych, na urządzeniach mogą być odpalane testy automatyczne. W celu zwiększenia efektywności powinny być odpalane symultanicznie. W przypadku Androida istnieje już co najmniej kilka narzędzi umożliwiających uruchamianie testów na wielu urządzeniach jednocześnie. W przypadku platformy iOS na ten moment jest niepewna sytuacja względem uruchamiania testów na wielu urządzeniach lokalnie. Jeżeli decyzja padłaby na rozwiązanie w chmurze, wtedy do już wymienionej listy kryteriów oceny dostawcy należałoby dodać infrastrukturę dostosowaną do uruchamiania testów symultanicznie dla platformy iOS. Potencjalnym problemem dla obu platform jest jednak sposób, w jaki zaprojektowane zostały testy. Czy aby na pewno są gotowe na uruchamianie ich na więcej niż jednym urządzeniu jednocześnie? Czy nie nastąpią na przykład konflikty w postaci próby korzystania z tych samych danych do uwierzytelnienia z kilku urządzeń jednocześnie?

2.4.6. Sieć

Testowanie ruchu sieciowego jest według mnie bardzo ważnym czynnikiem warunkującym dobrze przetestowany produkt mobilny. Symulowanie sieci nie jest problemem, ponieważ są na rynku gotowe symulatory, które możemy wgrać na router i zarządzać z ich poziomu ruchem dla pojedynczych urządzeń. Nie zastąpią jednak rzeczywistych testów terenowych, które powinno się wykonać - przynajmniej przy większych zmianach, czy to wprowadzanych w aplikacji, czy przez operatorów. Testy te są oczywiście w pewnym sensie częścią świata idealnego, świata, w którym mamy zawsze czas na wykonywanie testów i możemy spokojnie planować każde wydanie. Nie zawsze mamy taką możliwość. Tak jak w przypadku laboratorium urządzeń mobilnych, problemem będzie właśnie podejście bliskie rzeczywistym warunkom.

Co się stanie, gdy użytkownik pobierając formularz w aplikacji mobilnej, otrzyma połączenie głosowe? Ktoś do niego najprościej w świecie zadzwoni. Jeżeli urządzenie będzie podłączone do Wi-Fi, wszystko będzie w porządku. Co natomiast, jeśli będzie korzystał z pakietówki? Z transmisji danych od swojego operatora, będąc podłączonym do dowolnego BTSa? Jeżeli będzie korzystał z 3G, 3.5G czy LTE, to wszystko będzie w porządku. Jeżeli natomiast będzie pobierał dane po GPRS albo EDGE, wtedy połączenie pakietowe zostanie zerwane. W naszym kraju nadal ogromne obszary nie są pokryte w pełni zasięgiem powyżej 2G. Warto o tym pamiętać.

Wiele osób podjęło się stworzenia tzw. Rogue GSM BTS (Base Transciever Station), czyli stacji przekaźnikowej własnej roboty, dzięki której jest możliwość modyfikowania zasobami sieci GSM, które są przydzielane konkretnemu urządzeniu. Działa to na zdecydowanie lepszej zasadzie niż symulator sieci Wi-Fi. Niestety jednak tworzenie, posiadanie i używanie takiej stacji przekaźnikowej własnego wyrobu jest w wielu krajach nielegalne. Jednym z ciekawszych rozwiązań, jakie zaobserwowałem, jest stworzenie prowizorycznej klatki Faradaya. Dzięki modyfikowaniu jej elementami jest możliwość wpływania na poziom sygnału, który dochodzi do urządzeń.

2.4.7. Organizacja

Posiadanie dodatkowych kilkunastu do kilkudziesięciu urządzeń może spowodować dodatkowe problemy administracyjno-logistyczne. Istnieje wiele bardzo wygodnych sposobów zarządzania dodatkową pulą urządzeń w zależności od tego, gdzie będą się znajdowały. Jeżeli wszystkie urządzenia będą znajdowały się w ogólnodostępnym pomieszczeniu, trzeba będzie szczególnie zadbać o bezpieczeństwo sprzętu, danych i akcesoriów, takich jak baterie czy kable USB. Urządzenia można oznaczyć za pomocą kodów QR, aby ułatwić identyfikację urządzenia, które powinno wieczorami znaleźć się w laboratorium. Kable USB bardzo łatwo natomiast zidentyfikować i dopasować ładowarkę, telefon, jeżeli po obu końcach kabla USB przyczepiona zostanie naklejka z odpowiednim kolorem albo numerem.

Kolejnym elementem jest organizacja dostępności urządzeń. Całe zespoły mobilne mogą wymagać pracy na fizycznych urządzeniach, mając je podpięte do swojego komputera. Firma może nie mieć wystarczających funduszy na zakup urządzeń, które będą służyły laboratorium, i kolejnego zestawu dla zespołów deweloperskich. Jest to jeden z pierwszych problemów poruszonych w tym rozdziale i jeden z pierwszych, które może rozwiązać projekt laboratorium. Proponowanym przeze mnie podejściem w tym przypadku byłoby skorzystanie z czasu w proporcji 1 do 2 (8 na 16 z 24 godzin). Przez około 8 godzin pracy w dzień urządzenia byłyby w pełni do dyspozycji zespołów mobilnych, a na pozostałe 16 godzin przed i po pracy byłyby podłączane do komputera obsługującego uruchamianie testów. Natomiast w weekendy urządzenia mogłyby funkcjonować cały czas.

2.4.8. Urządzenia lokalne czy w chmurze

Jednym z głównych wyborów w trakcie przygotowywania projektu będzie to, czy firma powinna skorzystać z urządzeń udostępnianych przez firmy świadczące tego typu usługi w chmurze, czy też zdecydować się na zbudowanie własnego laboratorium. Istnieje również możliwość wykorzystania oprogramowania usługodawcy, które zostanie spięte z urządzeniami fizycznie dostępnymi lokalnie. Tę opcję przedstawię jako zaletę obydwu rozwiązań.

Jak zwykle nie istnieje jeden poprawny czy też najlepszy wybór. Należy przeprowadzić analizę i zweryfikować, które rozwiązanie będzie najkorzystniejsze dla firmy w danym momencie.

Dzięki zastosowaniu urządzeń, już dostępnych w firmie, próg wejścia w automatyzację z wykorzystaniem laboratorium urządzeń mobilnych jest według mnie najniższy ze wszystkich innych możliwych opcji. W takim przypadku przyjmujemy założenie, że automatyzacja będzie odbywała się w sposób zaproponowany przeze mnie przy organizacji urządzeń. Przez około 8 godzin pracy w dzień urządzenia byłyby w pełni do dyspozycji zespołów mobilnych, a na pozostałe 16 godzin przed i po pracy byłyby podłączane do komputera obsługującego uruchamianie testów. Natomiast w weekendy urządzenia mogłyby funkcjonować cały czas.

W takim przypadku koszty ograniczają się do dodatkowego komputera obsługującego urządzenia i czasu, który dedykowana osoba lub zespół spędzą nad przygotowywaniem laboratorium.

2.4.9. Analiza rozwiązań w chmurze

Poniżej przedstawię przykładowe istotne kryteria, które można wziąć pod uwagę w trakcie analizy ofert usługodawców. Ich ostateczna lista powinna być dostosowana do oczekiwań projektowych. Nie wszystkie mogą okazać się ważne, czy też nawet przydatne dla każdego projektu. W trakcie wyboru i analizy sugeruję dodatkową lekturę najaktualniejszych raportów na ten temat, na przykład "Market Guide for Mobile App Test Automation Tools".

Lista urządzeń spełnia oczekiwania

Analiza porównawcza wykazuje, że urządzenia, które posiada usługodawca, pokrywają się z najważniejszymi urządzeniami niezbędnymi do zapewnienia odpowiedniego pokrycia testami w projekcie. Dane odnośnie do najpopularniejszych urządzeń powinny być pobierane ze źródeł wiarygodnych, takich jak Sklep Play (Google Play Store) czy raport OpenSignal, biorąc pod uwagę rozkład urządzeń na rynku docelowym.

Zabezpieczenie urządzeń spełnia oczekiwania

Stosowane, gdy z tych urządzeń korzystają też inni klienci usługodawcy, czyli w przypadku, gdy nie jest planowane stałe wypożyczenie urządzeń w tzw. chmurze prywatnej. Pamięć i ustawienia urządzenia powinny być czyszczone za każdym razem przed i po wykonaniu testu.

Lista dostępnych urządzeń jest aktualizowana przynajmniej raz na kwartał

Ze względu na szybko rozwijający się rynek i częstość, z jaką pojawiają się na nim flagowe urządzenia usługodawca powinien zapewnić możliwość przetestowania nowego urządzenia potencjalnie najszybciej jak to tylko możliwe.

Istnieje możliwość przeprowadzenia testów manualnych na dowolnym urządzeniu z oferty

Testy manualne są i jeszcze przez długi czas będą bardzo ważną częścią testowania aplikacji mobilnych. Tak programiści, jak testerzy i osoby odpowiedzialne za UX i grafikę powinni móc sprawdzić, jak nowe zmiany będą wyglądały na dowolnym urządzeniu, bez konieczności projektowania w tym celu testów automatycznych.

Istnieje dostępne dla użytkowników dobrze udokumentowane API

Dzięki dostępowi do danych poprzez API można w łatwy sposób kontrolować przeprowadzane testy i zbierać informacje na przykład na wewnętrznych tablicach lub automatycznie zamieszczać je w raportach wewnątrzfirmowych.

- Możliwe jest przeprowadzenie automatyzacji z wykorzystaniem frameworków, z których firma aktualnie korzysta lub też planuje korzystać.

- Umożliwia testowanie aplikacji natywnych, hybrydowych i webowych.

- Umożliwia testowanie stron web.

- Istnieje możliwość stworzenia kilku użytkowników pod jednym profilem administratorskim.

- Nie istnieje ograniczenie regionalne lub zależne od stref czasowych w jakikolwiek sposób uniemożliwiające skorzystanie z oferty.

- Umożliwiają negocjację oferty enterprise i dedykowanych urządzeń.

- Oferują dedykowane wsparcie przez 24 godziny na dobę przez 7 dni w tygodniu.

2.4.10. Rozliczanie czasu dostępu

Usługodawcy rozliczają czas przeprowadzania testów na urządzeniach w godzinach, dziennie lub miesięcznie. Każda minuta przeprowadzonego testu na pojedynczym urządzeniu jest równoważna minucie pobranej z "czasu dostępu".

Oznacza to, że jeżeli czas potrzebny na wykonanie pełnych testów na jednym urządzeniu wynosi 50 minut, to przy wykonaniu tego testu na 100 z dostępnych urządzeń z naszego planu zostanie pobranych ponad 5000 minut, co jest równe ponad 83 godzinom. Do tego należy doliczyć czas przygotowania telefonu do testów i oddania w czystej formie do chmury (w niektórych planach ten czas jest dodatkowo doliczany). Nawet w przypadku usługodawcy oferującego 100 godzin dziennie, może okazać się, że liczba ta nie wystarczy nawet na jednokrotne wykonanie wszystkich scenariuszy testowych - zakładając, że nie zaistnieje jakikolwiek problem w trakcie realizacji scenariuszy testowych - ponieważ musimy pamiętać o tym, że uruchamianie testów ponownie będzie liczone jako kolejne uruchomienie z ponownym naliczaniem minut. Bez względu na to, czy poprzednie testy miały wynik pozytywny (w większości planów).

2.4.11. Analiza rozwiązania lokalnego

Jednym z możliwych podejść do posiadania laboratorium urządzeń mobilnych jest stworzenie go razem z zespołem deweloperskim. Przydatne jest posiadanie urządzeń i szafy lub innej przestrzeni, w której będą przechowywane na terenie firmy. Posiadanie własnego laboratorium ma wiele zalet, które zaraz opiszę. Należy jednak pamiętać o tym, że rozwiązanie nie jest idealne, niesie za sobą pewne ryzyko, którego musimy być świadomi.

2.4.12. Potencjalne zalety posiadania laboratorium urządzeń mobilnych

Łatwy dostęp do fizycznych urządzeń

Urządzenia będą zawsze dostępne dla zespołów znajdujących się na miejscu. Natomiast zespoły zdalne mogą uzyskać dostęp do urządzenia poprzez VNC (Virtual Network Computing) lub zgłosić zapotrzebowanie na przesłanie konkretnego urządzenia, które może zostać wysłane przesyłką wewnątrzfirmową.

Łatwy dostęp do dowolnego urządzenia zdalnie

Urządzenia zostaną wyposażone w serwer VNC, który po odpowiedniej konfiguracji i wdrożeniu umożliwi zdalną kontrolę nad urządzeniem.

Dostęp z dowolnego miejsca na świecie

Zarówno testy automatyczne, jak i manualne będą możliwe dzięki połączeniu zdalnemu.