O testowaniu aplikacji

Na niskim poziomie testuje się pojedyncze klasy czy moduły w kodzie, sprawdzając ich logikę i samą jakość kodu. Na wyższych poziomach przeprowadza się testy integracji poszczególnych komponentów programu, wydajność, zgodność ze specyfikacją czy wygląd interfejsu. 

Należy także wspomnieć o dwóch rodzajach podejścia do testów: testach białej oraz czarnej skrzynki. Te pierwsze odnoszą się do testów, gdzie osoba testująca wie, jak działa dany komponent oraz jaki kod znajduje się w środku. Dzięki temu może dokładnie prześledzić całą zawartość i od razu zlokalizować błędy. Takie podejście ma dużo zalet, jest jednak dość kosztowne ponieważ wymaga m.in. zaangażowania testera z umiejętnościami programistycznymi czy zaplanowania dodatkowego czasu pracy programistów.

Drugim rodzajem są testy czarnej skrzynki. Tester, mając za zadanie przetestować jakiś komponent, posiada wiedzę jedynie o danych wejściowych oraz wyjściowych jakie są obsługiwane, nie wie natomiast, jak jest skonstruowany obiekt testów sam w sobie. Takie rozwiązanie pozwala sprawdzić wpływ innych elementów aplikacji – np. tych, które dostarczają czy odbierają dane. Testami czarnoskrzynkowymi są również testy wydajnościowe i funkcjonalne. Takie podejście niestety nie pozwala na natychmiastowe znalezienie przyczyny defektu w aplikacji, lecz jest przydatne w utrzymaniu aplikacji w fazie produkcji. Rozumiemy przez to zestawy głównie automatycznych testów, które są uruchamiane codziennie, dzięki czemu możemy sprawdzić ich wpływ na nowo dodane funkcje na istniejącą już aplikację.  

O rodzajach i etapach testowania można jeszcze wiele pisać, ale w tym krótkim artykule chcielibyśmy również nieco przybliżyć istotę testowania elementu najbliższego użytkownikowi, czyli interfejsu graficznego (GUI). 

Wygląd aplikacji jest często czymś, co decyduje o jego popularności. Dużą wagę przykłada się do funkcji, gadżetów, kolorystyki czy stylu graficznego. Żeby spełnił on wymagania użytkowników, musi być możliwie wszechstronnie sprawdzony. Tutaj pole do popisu mają zarówno testy automatyczne jak i manualne.

Retail, który nie sprzedaje „na siłę”. Showroom Lenovo & Motorola jako przykład doświadczeniowego brand store’u

Testowanie GUI jest czasami jednym z bardziej problematycznych zagadnień. Panel, jaki widzi użytkownik, musi spełniać wiele wymogów, takich jak np. odpowiedni layout czy bezawaryjność. O ile sprawdzanie czy interfejs zawiera wszystko, czego zażyczył sobie klient, nie jest sprawą trudną, to sprawdzenie jak się aplikacja zachowuje np. przy większym obciążeniu czy nietypowych zachowaniach użytkownika czasami wymaga więcej wysiłku. Tutaj nasuwa się pytanie, czy nie warto zautomatyzować takiego procesu, by oszczędzić czas i pieniądze, nie ma na nie jednak jednoznacznej odpowiedzi. 

Tworzenie aplikacji to oprócz dodawania kolejnych komponentów i funkcjonalności także mnóstwo modyfikacji już istniejących elementów. Koncepcja interfejsu graficznego na przestrzeni tworzenia może się zmieniać, co wymaga także modyfikacji testów automatycznych.Takie testy mają nam głównie odpowiedzieć na pytanie, czy aplikacja posiada wszystkie wymagane funkcje. Mówiąc prostym językiem, program wykonujący skrypty testowe beznamiętnie szuka w interfejsie komponentów o danym identyfikatorze i sprawdza, czy po kliknięciu nastąpi pożądana akcja i generuje raport ze swoich czynności. 

Jeśli raport zaświadczy o braku błędów, to i tak tylko połowa sukcesu. Reszta pracy testerskiej to zasymilowanie działań niepożądanych i nieprzewidzianych w dokumentacji.

Weźmy pod uwagę przykład sklepu internetowego. Mamy setki okien i pól, gdzie użytkownicy wpisują dane zamówienia, dane osobiste i inne. Automat może nam bez problemu sprawdzić ich poprawne działanie czy parametry. Z drugiej strony zastanówmy się, co stanie się w momencie gdy te same zakupy użytkownicy będą robić, używając 3 różnych okien w przeglądarce, czasami dodając te same produkty do koszyka. Jeżeli według jednej zakładki ilość produktów w magazynie się skończyła, a w innej produkt dalej jest dostępny i chcemy sfinalizować całe zakupy, aplikacja powinna w jakiś sposób odnieść się do naszego niestandardowego działania, np wyświetlając odpowiedni komunikat dotyczący braku danego produktu.

Każdorazowe sesje testowania ręcznego GUI zawsze wnoszą coś nowego, tester za każdym razem może kliknąć coś w innej kolejności, użyć innych ustawień przeglądarki czy spróbować wymusić błąd przez wpisywanie nieprawidłowych parametrów. Generowanie w taki sposób różnych scenariuszy pozwala na sprawdzenie aplikacji z wielu stron. 

 Ciekawym sposobem testowania jest również testowanie przez osoby nie posiadające gruntownej wiedzy o aplikacji.  

Tester, który posiada konkretną wiedzę o aplikacji zupełnie inaczej może wykonać testy niż osoba, którą poproszono o poklikanie sobie wedle uznania. Taki użytkownik klikając niejako „na ślepo” sprawdza (świadomie bądź nie), na ile aplikacja jest elastyczna w interakcji z użytkownikiem i jak sobie radzi na zachowania nieprzewidziane przez projektantów i testerów w dokumentacji. Oczywiście często stosuje się np. wymianę testerów pomiędzy zespołami, czy organizację testów w innych zespołach, jedynie ma podstawie dokumentacji klienckiej. Kolejna para oczu, która spojrzy na aplikację, z dużym prawdopodobieństwem wymyśli nowy scenariusz, przez co udaje się pokryć testami coraz to większy obszar funkcjonalności aplikacji. 

 Podsumowując, testowanie aplikacji jest tematem szerokim i dającym możliwość wykorzystania wielu technologii. Testów manualnych, gdzie wtrącony jest pierwiastek ludzki, nigdy nie będzie można w pełni zastąpić testami automatycznymi. Niemniej jednak, połączenie tych dwóch technik jest niezbędne w prawidłowym dbaniu o jakość aplikacji, szczególnie w przypadku testowania interfejsów graficznych.

Artykuł powstał we współpracy z Bartkiem Krakowianem.