7 praktycznych wskazówek dot. testowania stron i aplikacji internetowych

16 February 2011 | Szymon Ignaczak | Komentarzy: 3 »

„Chociażbym chodził ciemną doliną,
złego klienta się nie ulęknę,
bo Ty jesteś ze mną.
Twoja bystrość i Twoja intuicja
są tym, co mnie pociesza.”

Project Managerowie o Testerach Ps. 23 Wielkiej Księgi Merix

Testowanie jest to przede wszystkim proces mający na celu ocenę jakościową projektu, wskazać ewentualne poprawki oraz określić stronę/aplikację z perspektywy UX (User Experience)  w tym User Usability. Kierunek projektu zostaje opracowany przy tworzeniu specyfikacji natomiast testowanie koryguje ten kierunek nadając mu odpowiedni, bardziej efektywny kształt.

Jakie są podstawowe cele testowania?

• Ogólna ocena jakościowa projektu
• Poprzez testowanie sprawdza się projekt w poszukiwaniu błędów programisty oraz dawania propozycji rozwiązań do poprawy tych błędów.
• Poprzez testowanie sprawdza się projekt w poszukiwaniu zmian, które poprawiają działanie aplikacji. Duże znaczenie ma tutaj sprawdzenie strony pod kątem użyteczności i User Experience.

Aby lepiej poznać ideę testowania, charakter oraz sposób należało by zrozumieć założenie że:

„Testowanie to nie praca syzyfowa, a benedyktyńska.”

Testowanie to praca żmudna, momentami monotonna (w zależności od projektu), irytująca ze względu na powtarzający się schemat, ale dającą ogromny pożytek – przede wszystkim oszczędza cenny czas programisty, a po dokładnym przetestowaniu klient otrzymuje kompletny, w pełni funkcjonalny produkt (tu stronę internetową lub aplikację www), co ogranicza ilość późniejszych konfrontacji ;). W efekcie, dokładne testowanie dosyć skutecznie chroni skrzynkę pocztową od przegrzania ilością maili nadesłanych przez klienta dotyczących poprawek do projektu.

Testowanie samo w sobie nie służy do poprawienia jakości aplikacji czy strony, ale jest tej jakości miernikiem. Przystępując do testów należy zadać sobie pytanie “czy wszystko działa?” i co ważniejsze “na ile działa?”. Podczas tego procesu warto również wczuć się w rolę ostatecznego odbiorcy czyli użytkownika.

Zajmując się na co dzień testowaniem stron oraz aplikacji webowych (Quality Assurant) opiszę kilka praktycznych zasad, których warto się trzymać podczas testów.  Choć reguł i metod testowania jest wiele, tylko kilka kluczowych stanowi podstawę, kamień węgielny całego projektu.

7 praktycznych wskazówek dot. testowania i aplikacji internetowych

1 – Stand your ground

Bądź pewien na czym stoisz. Zapoznanie się ze specyfikacją i całym materiałem oraz przygotowanie instrukcji testów. Bardzo ważne na tym etapie jest zautomatyzowanie testów – o ile to możliwe. Nie musi się to wiązać z wysokim budżetem. Wszystko zależy od masy różnych czynników, ale bardzo ważne jest, aby wszelkie testy manualne wspomóc programami które zrobią za Nas niektóre zadania szybciej i lepiej. Na tym etapie również pojawia się zjawisko znane, jako ‘smoke test’ które polega na tym, że sprawdzamy czy strona/aplikacja ogólnie działa zgodnie z przewidywaniami, tzn. czy jej obszary krytyczne działają. Jeżeli okazuje się że oddana przez programistów strona/aplikacja nie zgadza się z ideą projektu, nie można przeprowadzać dalszych testów. Kolejne etapy testowania zależą głównie od przygotowanej przez Nas instrukcji.

2 – Teamwork

“Co trzy głowy to projekt lepiej wykonany” – krótka rozmowa z Project Managerem i Developerem to skuteczny sposób, aby wyjaśnić wszelkie nieścisłości, które napotkamy na samym początku testowania, tuż po zapoznaniu się ze specyfikacją od klienta. Zwykle na tym etapie współpraca z Project Managerem kończy się na ustaleniach dotyczących wstępnych założeń projektu, natomiast należy przygotować się na dłuższą współpracę z programistą przez kolejne etapy procesu testowania.

Przydatne pytania które należało by zadać przed rozpoczęciem procesu testowania:

• Jaki przeznaczyć czas na testowanie?
• Na których funkcjonalnościach/modułach/elementach strony należało by się skoncentrować (które są wyjątkowo ważne z punktu widzenia realizacji projektu)?
• Które funkcjonalności/moduły/elementy strony są najbardziej skomplikowane (im bardziej skomplikowane tym bardziej narażone na wystąpienie błędów)?
• Jakie funkcjonalności/moduły/elementy strony zostały wykorzystane, jeżeli nie były określone przez klienta?
• Co zostało zmienione w specyfikacji w późniejszych ustaleniach z klientem?

3 – World is a playground

Witamy w świecie ticketów! Teraz najważniejsza część, czyli platforma gdzie rozgrywa się akcja. Bardzo ważne, aby zapewnić odpowiednią płaszczyznę na której będzie istniała komunikacja między trzema podmiotami: Webdeveloperem, Testerem oraz Project Managerem oraz gdzie będzie można zawrzeć wszelkiego rodzaju uwagi dotyczące projektów.

Nasza agencja z powodzeniem wykorzystuje narzędzie Redmine (napisane we frameworku Ruby on Rails), które służy przede wszystkim jako system zarządzania projektem. Charakter działania polega głównie na tym że dodaje się tzw. tickety w których są zawarte informacje dotyczące projektu – w większości przypadków są to bugi które należało by poprawić, ale występują także features, supports czy zapytania (do PM’ów, Developerów oraz innych uczestników projektu). Ticketom można ustawiać odpowiednie statusy, nadawać priorytet oraz ustawić odpowiedni czas na wykonanie poprzez diagram Gantta . Dzięki temu można uporządkować w znaczący sposób pracę WebDevelopera.

BugTracker = Pole bitwy

Przynoszenie złych wiadomości nie jest przyjemne, ani dla nadawcy, ani dla adresata. Logiczne jest zatem, że BugTracker jest również polem bitwy, ponieważ często występuje konflikt polegający na tym że tester określa coś, jako błąd, natomiast programista, często stwierdza że to nie jest błędem jego pracy … Idealnie przedstawia tą sytuację poniższy szkic:

W sytuacji takiej jak powyższa lub gdy podczas testowania nie można zinterpretować dokładnie na czym polega błąd, trzeba uzbroić się w dużą cierpliwość do czasu wyjaśnienia tych delikatnych kwestii poprzez np. rozmowę. Należy pamiętać, że tester (lub osoba pełniąca jego rolę) oraz programista powinni nawzajem się uzupełniać, a nie wchodzić sobie nawzajem w drogę.

4 – Toolbox

Z dobrymi narzędziami to i amator coś zbuduje. To może nie do końca prawda, ale warto zaopatrzyć się w bardzo przydatne narzędzia, które zdecydowanie ułatwiają pracę i przyspieszają proces testowania (poniżej jest lista tych kilku najlepszych):

• 7 przeglądarek (FF, IE7, IE8, Opera, Chrome, Safari, ew. IE6) + Apple MAC lub jego emulator (w większości przypadków nie są lustrzanym odbiciem oryginału, dlatego wyniki testów nie zawsze są wiarygodne). Taki arsenał przeglądarek przyda się podczas sprawdzania tzw. “Cross-Browser Compatibility”, czyli weryfikacji poprawności wyświetlania strony/aplikacji przez popularne przeglądarki. Niestety każda z przeglądarek może wyświetlić tę samą stronę/aplikację zupełnie inaczej. Dobrym pomysłem jest zaopatrzenie się także w iPad’a (lub jego emulator), szczególnie klienci zagraniczni proszą nas o taką kompatybilność. Na szczęście dla koderów staruszek IE6 odszedł już w zapomnienie i przestał być częścią wymagań projektowych.
• Adobe Photoshop albo inny program graficzny – musisz mieć dostęp do wszelkich wymiarów layoutu, aby móc określić programiście  dlaczego się pomylił  przy ‘cięciu’.
• Irfan View (freeware)– genialny programik do przeglądania plików graficznych i w przypadku gdy mamy dwa monitory tej samej wielkości, można porównać layout z gotową stroną. Dbając o to, aby strona została zakodowania idealnie z projektem (pixel-perfect) można wspomóc się rozszerzeniem do Firefoxa – Pixel Perfect.

Dodatkowo przydatne mogą się okazać:

• Xenu Sleuth – jest to bardzo ważny program jeżeli chodzi o wspomnianą wyżej automatyzację testów. Program ma za zadanie sprawdzenie wszystkich martwych linków na stronie oraz wskazuje na której stronie utknął dany deadlink.
• VVCap – (freeware) doskonałe narzędzie dzięki któremu oszczędzamy czas przy tworzeniu screenshotów całej lub fragmentów interfejsu (screenshot  zapisany do pliku lub “schowka” w 2 sekundy ;))

5 – This is the end… for now!

Zakończenie pierwszego procesu testowania. Wynikiem jest bug/feature lista dla programisty do poprawki.

6 – Never ending story

Koło się zamyka, ale przynajmniej średnica robi się coraz mniejsza. Niestety po tym jak programista poprawi wszystko z listy trzeba sprawdzić czy poprawił to dobrze. Może się okazać, że na 100 rzeczy do poprawy o 10 zapomniał, 20 odrzucił że nie jest to błąd, 10 nie zostało poprawionych zgodnie z założeniami czyli faktycznie poprawił 60. Jednak z doświadczenia wiem, że na to 60 które poprawił, wskoczyło 20 nowych błędów, a połowę z tych które odrzucił jednak błędem są, więc po zaktualizowaniu listy okazuje się, że pozostaje jeszcze 40 poprawek. Ten etap należy powtórzyć 2-3 razy – aż do całkowitego wyczyszczenia listy z BugTrackera. Wysyłamy produkt do klienta.

7 – Loading – please wait…

Ttik tak, tik tak. Teraz pozostaje tylko poczekać na feedback od klienta. W momencie gdy tylko pojawią się jakieś uwagi należy zaktualizować bug/feature listę i powtórzyć Regułę no. 6.

Dobrze wykonany test = mniej poprawek = zadowolony developer, PM i klient

Podsumowując. Baba z wozu, koniom…

Testowanie wcale nie musi być to przysłowiową toporną babą na wozie, którą jak się zrzuci, będzie lżej. Wręcz przeciwnie – baba jest nawigatorem woźnicy, jakim jest PM, a Konie programistami… i dzięki tej babie ta bryczka nigdy się nie zgubi przez co dojedzie do celu na czas i bez większych problemów :)