Czemu testować jak przecież powinno działać? – Quality Assurance aplikacji mobilnych

Jak wygląda praca testera w projekcie prowadzonym w systemie Agile w software house?Czemu testy przeprowadzone przez deweloperów nie są wystarczające do wyprodukowania niezawodnej aplikacji przyjaznej użytkownikowi? 

Spis treści

1. Praca programisty w Agile
   – A co, jeśli…
   – Dlaczego więc nawet po wykonaniu szeregu sprawdzeń gotowa aplikacja może zawierać błędy?
2. Nie da się sprawdzić wszystkiego
3. Dlaczego programista nie powinien przejmować roli testera?
   – Podejście czarnej skrzynki
   – Specjalizacja
   – Dlaczego więc programista nie powinien przejmować roli testera?
4. Na czym polega praca testera w projekcie?
   – Analiza zebranej dokumentacji
   – Testy eksperymentalne
   – Tworzenie i wykonywanie scenariuszy testowych
5. Podsumowanie

Praca programisty w Agile

Jednym z najczęściej pojawiających się błędów w przeświadczeniu jak wygląda pisanie aplikacji jest postrzeganie samej roli programisty w projekcie.. Osoba ta odpowiedzialna jest za implementację wcześniej określonych funkcjonalności w ramach wprowadzanego zakresu. Jej zadaniem jest upewnienie się, że dodana część aplikacji działa zgodnie z założeniami. Kilka aspektów tego procesu może więc budzić nasze wątpliwości. 

A co, jeśli

Co zrobić kiedy dodana funkcja nie działa w połączeniu z resztą aplikacji, albo powoduje brak działania innych komponentów? Albo działa tylko na danym urządzeniu (marka, wielkość ekranu, typ połączenia z internetem etc.), czy przestaje działać w momencie wyłączenia internetu?Co, jeśli działa tylko w podstawowy sposób, tzn istnieją przypadki, gdy funkcjonalność nie będzie działała poprawnie, a co gorsza zamykała całą aplikację.

Odpowiedzią na te wszystkie problemy jest osoba, która się z nimi spotyka – tester.. Jej rolą jest analiza działania aplikacji, czy oprogramowania z perspektywy użytkownika oraz znalezienie takich sytuacji, przy których aplikacja może przestać działać prawidłowo lub w ogóle. 

Nie oznacza to, że rola programisty sprowadza się do przepisywania kodu. Deweloper powinien weryfikować działanie napisanej treści. Pomocne w jego pracy są testy jednostkowe kodu – odnoszące się bezpośrednio do dodanej treści, testy integracyjne kodu – sprawdzające jak dodana treść funkcjonuje z resztą aplikacji, oraz testy na fizycznym urządzeniu bądź symulatorze/emulatorze.

Dlaczego więc nawet po wykonaniu szeregu sprawdzeń gotowa aplikacja może zawierać błędy? 

Testy kodu odnoszą się do samej logiki działania aplikacji. Nie uwzględniają np błędów wizualnych występujących np tylko dla mniejszych rozdzielczości ekranów

W momencie, gdy zespół dostaje już stary kod aplikacji która jest zmieniana i/lub także backend (API) często dochodzi do problemu z brakiem aktualnej dokumentacji. Aplikacja może po swojej stronie działać perfekcyjnie, ale gdy programista sam rozpracowuje sposób działania zewnętrznej funkcji może dojść do nieporozumień.

Nie da się sprawdzić wszystkiego

Testy na fizycznych urządzeniach wykonywane są na bardzo wąskiej grupie. Istnieje duża szansa, że proporcje wyświetlacza mogą spowodować problemy z interfejsem a nakładka systemowa producenta błędy związane z implementacją animacji lub obsługi powiadomień. Te kwestie nie są dokumentowane przez firmy więc tylko sprawdzenie na reprezentacyjnej próbie urządzeń z zakładanego rynku docelowego może dać rezultaty w postaci znalezienia problemów nim zrobią to użytkownicy

Deweloper sprawdza tylko najbardziej podstawowe przypadki działania funkcjonalności. W prawdziwym życiu niestety na komfort używania aplikacji mogą wpłynąć liczne czynniki jak problem z połączeniem internetowym, przychodząca rozmowa, niski stan baterii itp.

Dlaczego programista nie powinien przejmować roli testera?

Deweloper piszący daną aplikację doskonale wie, jakimi zależnościami są powiązane ze sobą poszczególne elementy programu. Świadomie lub nie, ale spodziewa się niepowodzenia w określonych przypadkach. Nie jest to oczywiście zjawiskiem niepożądanym, ale posiadając taką wiedzę jest w stanie dopracować funkcjonalność.

Niesie to jednak za sobą problem popadania w schematyczne, zamknięte myślenie. Dużo trudniej jest w takim przypadku wyjść poza utworzony schemat, o którym nie myśli nasz klient, a to przecież on jest najważniejszy. Aplikacja ma działać w rękach każdej osoby a nie wtajemniczonego grona, które wie, jak omijać czyhające za rogiem błędy.

Podejście czarnej skrzynki

Osoba korzystająca z aplikacji nie zna mechanizmów wewnątrz programu – wie, jakie dane wprowadza na jego wejściu i zdaje sobie sprawę z tego, co powinno zostać zwrócone na wyjściu. To tak, jak z kupowaniem biletu w parkometrze – wrzucamy do niego monetę i oczekujemy, że otrzymamy wydruk. Nie musimy znać zawiłości działania urządzenia wewnątrz, aby z niego korzystać.

Specjalizacja

Developer to osoba, która nauczona jest tworzenia oprogramowania – bardzo często z wykorzystaniem kilku języków programowania. Pracując, tworzy aplikacje w oparciu o wypracowane przez lata schematy. Skutkiem jest wykorzystywanie tych schematów także w momencie podejścia do testowania aplikacji od strony użytkownika. Istnieje więc duża szansa, że nawet sprawdzając gotowy produkt innego developera, taka osoba nie będzie świadoma potencjalnej liczby błędów, które wykryłby tester pracujący w tym samym czasie z produktami różnych programistów.

Praca ze zróżnicowanym oprogramowaniem uczy jak łatwiej można znaleźć potencjalne problemy związane z działaniem aplikacji i znacznie łatwiej dostrzega się te błędy.

Dlaczego więc programista nie powinien przejmować roli testera?

• Deweloper piszący daną aplikację doskonale wie jakimi zależnościami są powiązane ze sobą poszczególne elementy programu. Świadomie lub nie – spodziewa się niepowodzenia w określonych przypadkach. Samo w sobie nie jest to oczywiście zjawiskiem niepożądanym. Posiadając taką wiedzę jest w stanie dopracować funkcjonalność. Jednak niesie to za sobą problem popadania w schematyczne i zamknięte myślenie. Dużo trudniej jest w takim przypadku wyjść poza utworzony schemat – którego przecież nie będzie posiadał końcowy klient a ten jest w całym procesie najważniejszy. Aplikacja powinna działać w rękach każdej osoby a nie tylko grona wtajemniczonych z tajemną wiedzą jak omijać czyhające się za rogiem błędy. Podejście takie nazywamy testami czarnej skrzynki. Sprawdzająca osoba nie zna mechanizmów wewnątrz programu – wie, jakie dane wprowadza na jego wejściu i także zdaje sobie sprawę co powinno być zwrócone na wyjściu. Podobnie jak z kupowaniem biletu w parkometrze – wrzucamy monetę i oczekujemy, że otrzymamy wydruk. Nie musimy znać zawiłości działania urządzenia wewnątrz budki.
• Kolejną kwestią jest specjalizacja. Deweloper to osoba nauczona tworzenia oprogramowaniach najczęściej w kilku językach. Zwykle bywa, że jest biegły w kilku w tym będący na bieżąco z technologią i rozwojem jeszcze mniejszej grupy. Pracując tworzy aplikacje w oparciu o wypracowane przez lata schematy. Skutkiem tego jest wypracowanie schematów również w momencie podejścia do oprogramowania od strony użytkownika. Istnieje moim zdaniem duża szansa, że nawet sprawdzając gotowy produkt innego dewelopera taka osoba nie będzie świadoma takiej ilości potencjalnych błędów jak tester pracujący w tym samym okresie czasu z produktami różnych programistów. Praca ze zróżnicowanym oprogramowaniem uczy jak łatwiej można znaleźć potencjalne problemy związane z działaniem aplikacji. 

Na czym polega praca testera w projekcie?

Analiza zebranej dokumentacji

Zadaniem testera jest analiza dokumentacji na wszystkich etapach projektu. Zarówno od jego rozpoczęcia, gdy omówione są wstępne zachowania oraz przedstawione szkice, jak i w każdej, kolejnej fazie projektu.

Tester powinien alarmować o wszelakich zachowaniach, które są potencjalnie niebezpieczne, nielogiczne lub nieczytelne dla użytkownika. W gronie osób technicznych, stanowi swego rodzaju obrońcę biednego, niczego nieświadomego użytkownika końcowego. „Pan Władek” zapewne nie ma pojęcia, dlaczego akurat tak płynnie i intuicyjnie korzysta mu się z danej aplikacji. Dzięki temu, że mamy w projekcie testera, w ostatecznym rozrachunku, końcowy użytkownik będzie brany pod uwagę podczas tworzenia rozwiązania.

Testy eksperymentalne

Testy eksperymentalne to po prostu złapanie za urządzenie z aplikacją i działanie. Nie opierają się one na sztywno opisanym planie. Tester bierze pod uwagę luźne sugestie oraz funkcje, jakie powinna pełnić aplikacja i stara się znaleźć w niej błędy.

W tym momencie można bazować zarówno na sytuacjach brzegowych, jak i wykorzystać wcześniej przygotowane profile końcowego odbiorcy. Są to zapisy przedstawiające charakterystykę domniemanej osoby, która w przyszłości będzie używała aplikacji.

Pisząc program do analizy sytuacji giełdowej, wyobrażamy sobie młodego gracza, który używać będzie stosunkowo nowego telefonu ze średniej/wyższej półki cenowej a ważnymi dla niego będą szybkość działania aplikacji, jej niezawodność oraz stabilność. Niższy priorytet stanowi spójność aplikacji, funkcje społecznościowe, czy długość pracy baterii.

Willy – bohater naszej krótkiej opowieści – zaczyna dzień od wyłączenia budzika i uruchomienia aplikacji. W drodze do pracy, kiedy telefon przełącza się z sieci WiFi na GSM, by później zmieniać także nadajniki, po raz kolejny sprawdza notowania giełdowe. Z tego też powodu kluczem do sukcesu aplikacji jest jej szybkość działania, niezawodność oraz konsekwencja w działaniu. 

Tworzenie i wykonywanie scenariuszy testowych

Bazując na własnym doświadczeniu, dokumentacji oraz innych zebranych informacjach, tester spisuje, w jaki sposób będzie testował aplikację. Pozwala to na przyjrzenie się metodologii działania całemu zespołowi i reagowanie na nowe, potencjalne zagrożenia w przyszłości, już na wczesnym etapie tworzenia aplikacji. Zapewnia to także powtarzalność wykonywanych testów po wprowadzeniu poprawek i stanowi czytelną, wizualną reprezentację wykonanej pracy nad programem dla klienta i całego zespołu.

Podsumowanie

Bez testera w zespole aplikacje nie zostaną właściwie przetestowane. Ważnym jest, aby skupić się na tym, co użytkownik może próbować robić w aplikacji i zweryfikować wszelkie, możliwe scenariusze, które mogą się pojawić. Tester, na bazie swojego doświadczenia i elastycznego myślenia, jest wstanie znaleźć i wyeliminować problemy, które w przyszłości, mogłyby zaważyć na odbiorze naszej aplikacji.