KraQA #38

Tradycyjnie już w przedostatni wtorek miesiąca odbyło się spotkanie KraQA. Spotkanie numer 38 było pierwszym po zorganizowanej przez nas w marcu konferencji SkładQA. I choć spotkanie KraQA nie może równać się frekwencją ze SkładQĄ, to sala klubu Re ponownie pękała w szwach. Bardzo Wam za to dziękujemy!

Podczas spotkania swoją wiedzą na temat testów mobilnych podzielili się z nami Dorota Tadych i Maciej Jaskulski, testerzy pracujący na co dzień we wrocławskim software hous’ie Droids on Roids, współtworzący również wrocławski meetup LogCat.

Jako pierwsza wystąpiła Dorota, która w prezentacji “Hyperion – wystarczy jeden shake” przedstawiła nam szereg narzędzi wspierających i ułatwiających codzienną pracę związaną z manualnym testowaniem aplikacji mobilnych. Na początku poznaliśmy kilka z nich:

  • Layout Inspector – narzędzie znajdujące się w Android Studio pozwalające w prosty sposób porównać layout aplikacji z designami.
  • QA Tool – to aplikacja umożliwiająca zbadanie innej wybranej przez siebie aplikacji. QA Tool pobrać możemy w Play Store.
  • Cockpit – Debug menu pozwalający “zdefiniować parametry widoków, które mogą być użyte w aplikacji bez konieczności re-kompilowania projektu”.
  • Chuck – program do śledzenia requestów i responsów API.
  • DBDebug Toolkit – narzędzie stworzone przez Dariusza Bukowskiego będące debug screenem dla iOSa.

Następnie Dorota przeszła do omówienia tytułowego Hyperiona. Jak dowiedzieliśmy się z prezentacji, Hyperion stworzony został przez amerykańską firmę WillowTree i jest debug screenem dostępnym dla iOSa, oraz Androida. Aby go używać potrzebny jest nam dostęp do repozytorium projektu. Jeśli taki dostęp posiadamy, możemy skorzystać ze szczegółowo omówionej przez Dorotę instrukcji konfiguracji i aktywacji Hyperiona.

Kiedy już udało nam się uruchomić Hyperiona, możemy zapoznać się z przedstawionymi przez Dorotę funkcjonalnościami Hyperiona. Należą do nich:

  • Attributes Inspector – pozwalający na podejrzenie parametrów widoków.
  • BuildConfig – który jak sama nazwa wskazuje pozwala podejrzeć build config aplikacji.
  • File Explorer – funkcjonalność umożliwiająca przeglądanie, usuwanie i udostępnianie plików aplikacji.
  • Geiger Counter – służący do wykrywania frame dropów podczas użytkowania aplikacji. Geiger Counter wymaga włączenia dźwięków, gdyż frame dropy sygnalizowane są dźwiękowo.
  • Measurement Inspector – feature mierzący odstępy pomiędzy elementami, szczególnie przydatny podczas sprawdzania marginesów czy paddingów.
  • Phoenix – czyści pamięć podręczną i uruchamia ponownie aplikację.
  • Recorder – służący do nagrywania ekranu aplikacji.
  • Shared Preferences – “Pozwala na przeglądanie i zmianę trwałych danych aplikacji zapisanych w Shared Preferences”
  • Timber – feature przechwytujący logi. Umożliwia również ich udostępnianie przy pomocy wielu zewnętrznych aplikacji.
  • Crash plugin – opcja niewidoczna w głównym menu Hyperiona. Sprawia, że w momencie crashu aplikacji wyświetlony zostaje raport z logami.

Hyperion posiada również szereg tzw. Third Party Plugins. Do tych wymienionych przez Dorotę należą:

  • Wspomniany już Chuck.
  • AppInfo – ułatwiający przejście do informacji systemowych aplikacji.
  • Simple Item – plugin do dodawania “belek” w menu, oraz konfigurowania ich treści, klikalności i możliwych akcji.

W ramach podsumowania prezentacji Dorota podkreśliła, że Hyperion jest bardzo solidnym programem którego sama używa, ale oczywiście posiada on również pewne wady. Do najpoważniejszych zaliczyć można problemy z przetestowaniem pop-upów wynikające z przykrywana przez nie Hyperiona, niedopracowanym wyświetlaniem nagrań z funkcji Recordera, czy brak możliwości przeklejania tekstu w Attribute Inspectorze.

Drugą prezentację przedstawił Maciej Jaskulski. W swojej prezentacji “Igła w stogu siana – jak sprawnie wybrać telefony do testów” omówił tematy takie jak:

  • Wybór urządzeń przez klienta.
  • Dopasowanie urządzeń według ich specyfikacji technicznej.
  • Wersje systemu i ich popularność a testy.
  • Wnioski i tworzenie finalnej listy.

Problemem często spotykanym przez testerów jest wybór właściwych urządzeń na których przeprowadzimy nasze testy. Urządzeń nie może być zbyt mało, gdyż nasze testy muszą być dokładne. Nie może ich być również zbyt dużo, gdyż zwiększa to koszt i czas trwania testów. Przed testerem stoi więc zadanie takiego dobrania urządzeń, aby przy możliwie niewielkiej ich ilości przetestować działanie aplikacji na urządzeniach i systemach operacyjnych najczęściej używanych przez naszych docelowych klientów. Warto w tym celu zapoznać się ze statystykami rynkowymi co do popularności użytkowania systemów np. Androida i iOSa. Jak pokazały przedstawione przez Maćka statystyki, większa ilość użytkowników iOSa posiada nowsze wersje oprogramowania w swoich urządzeniach, natomiast użytkownicy wyposażeni w Androida częściej posiadają starsze wersje systemów operacyjnych. Ma to wymierny wpływ na dobór urządzeń do testów.

W swojej prezentacji Maciek omówił również kilka rodzajów podejść do planowania testów i tworzenia aplikacji. Omawiając problem komunikacji z klientem wyróżnił kilka rodzajów najpopularniejszych “wymagań” klientów takich jak:

  • stworzenie czegoś lepszego niż konkurencja.
  • stworzenie czegoś równie dobrego.
  • poszerzenie dzięki aplikacji grupy odbiorców swojego produktu.
  • stworzenie aplikacji mobilnej współpracującej z już istniejącą stroną internetową.

Zależnie od celu jaki postawił przed nami klient zmieni się nieco nasz sposób tworzenia test case’ów.

Maciek zwrócił również uwagę na określenie nadrzędnej cechy jaką charakteryzować powinna się nasza aplikacja. Czy ma być ona szybka, ponad wszystko stabilna, bardzo energooszczędna czy może posiadać wyjątkowej jakości UI?

Tworząc listę urządzeń wykorzystywanych w testach należy wziąć pod uwagę nie tylko różne systemy operacyjne, ale również specyfikację techniczną urządzeń posiadających ten sam OS. Urządzenia mobilne mogą znacznie różnić się nie tylko wielkością ekranu, ale również procesorem, pamięcią RAM, aparatem czy różnego rodzaju dodatkami i wspieranymi technologiami (NFC, czytnik linii papilarnych, wersja Bluetooth itp.).

W swojej prezentacji Maciek podzielił urządzenia na 3 grupy:

  • Debeściaki – urządzenia najnowsze, najlepsze, z aktualnym OS.
  • Średniawki – urządzenia budżetowe z nową, lub nieco starszą wersją OS (ale nadal wspieraną), największa grupa.
  • “Ogon” – najsłabsze urządzenia, starsze wersje OS, brak niektórych popularnych rozwiązań np. słabsze telefony bez NFC.

Tester powinien zatem wiedzieć które systemy operacyjne ma wspierać nasza aplikacja, jakie urządzenia wchodzą w skład każdego systemu operacyjnego, oraz ile wersji OS będziemy wspierać. Bezcelowe może się okazać testowanie starych wersji, których praktycznie żaden użytkownik już nie używa. Ważne jest również poznanie grupy docelowej, która w największym stopniu będzie korzystać z aplikacji. Możemy założyć, że systemy operacyjne młodszych użytkowników będą zaktualizowane do nowszych wersji niż użytkowników starszych.

Zachęcamy do zapoznania się z prezentacjami. Znajdziecie w nich linki do omawianych urządzeń i nie tylko.
A my oczywiście widzimy się już w maju!