Redakcja
By dobrze opowiedzieć o testowaniu eksploracyjnym i wytłumaczyć jego zasady, trzeba teorię poprzeć przykładem.
Nagranie prezentacji można znaleźć na naszym kanale testerzy na YouTube. Niestety jakość nagrania nie jest najlepsza.
Podczas prezentacji na białostockim meetupie BiałQA zdecydowałem się pokazać nie tylko reguły testów eksploracyjnych, ale również przykład ich zastosowania. Pytanie jakie postawiłem to jaką metodę wybrać i ile można osiągnąć mając 30 minut czasu na testy?
Od slajdu 15. zaczyna się opis przykładowej sesji eksploracyjnej, której cel brzmiał: Przetestuję w 30 minut stronę internetową: programuj.gov.pl.
Czy przy takim zadaniu rozpoczniesz pisać przypadki testowe lub skrypty automatyczne? Mało prawdopodobne. Raczej rozpoczniesz sesję eksploracyjną.
Na kolejnym slajdzie znajdziecie narzędzia środowiska testowego. Jego konfiguracja powinna być zrealizowana w ramach przygotowania, które nie powinno zająć więcej niż 20% czasu sesji. Do definicji środowiska testowego zastosowałem świeże dane z ranking.pl, do określenia konfiguracji maszyny użyłem DxDiag, a do zebrania zrzutów ekranów - Greenshota. Dodatkowo użyłem AutoMagicTest, który w tym miejscu posłużył do znalezienia nieistniejących stron, oceny wydajności serwisu oraz SEO.
Na slajdzie 18. znajdziecie potencjalne DEFEKTY i UWAGI. Nie podejmuje się oceny, czy są to realne problemy czy też nie, ale brak obsługi dla 404, czy też stronicowanie po dwa artykuły nie wydają się być standardem.
Z kolei na slajdzie 19. pokazuję, jakie FUNKCJE udało mi się zweryfikować oraz prezentuję ocenę akceptacji z perspektywy użytkownika.
Home - OK
rozwiń / zwiń - OK Spot - OK
Powiększanie czcionki - OK
Aktualności - OK
Klawisz "Więcej" - OK
Stronicowanie - NIE OK
Najbliższe wydarzenia - OK
Statyczna strona: Dowiedz się jak uzyskać dofinansowanie? - OK
Poznaj szczegóły - OK
Breadcrumb - OK
Footer - OK
Tak przygotowany raport pokazuje nie tylko defekty, ale również informacje na temat poprawnie działających elementów.
Serwis jest bardzo prosty, dlatego też po 15-stu minutach skończyły mi się pomysły na dalsze testy. Postanawiam więc przeanalizować KOD źródłowy w poszukiwaniu informacji o ARCHITEKTURZE.
Szybko można się dowiedzieć, że jest to mechanizm wordpressowy i, co za tym idzie, można analizować stronę pod kątem wiedzy o samym CMS-ie. Przykładowo, funkcja wyszukiwania nie jest dostępna na interfejsie, ale można ją wywołać przez modyfikację adresu URL. Do poszukiwania potencjalnych dziur i luk można skorzystać z metody twitter driven testing. Wyszukujecie hasło #wordpress i szybko trafiacie na informację, że Wordpress ostatnio miał poważne problemy z bezpieczeństwem. Końcowym elementem jest przygotowanie raportu, który nie powinien nam zająć więcej niż 20% czasu.
Szybko można się dowiedzieć, że jest to mechanizm wordpressowy i, co za tym idzie, można analizować stronę pod kątem wiedzy o samym CMS-ie. Przykładowo, funkcja wyszukiwania nie jest dostępna na interfejsie, ale można ją wywołać przez modyfikację adresu URL. Do poszukiwania potencjalnych dziur i luk można skorzystać z metody twitter driven testing. Wyszukujecie hasło #wordpress i szybko trafiacie na informację, że Wordpress ostatnio miał poważne problemy z bezpieczeństwem. Końcowym elementem jest przygotowanie raportu, który nie powinien nam zająć więcej niż 20% czasu.
W 30 minut udało się:
-
przetestować funkcjonalnie cały serwis na jednej przeglądarce i w widokach responsywnych
-
ocenić SEO i znaleźć problem niedostosowania serwisu dla osób niewidzących
-
pozytywnie ocenić wydajność serwisu
- znaleźć potencjalne luki bezpieczeństwa (bez ich dalszego eksplorowania).
Polecam eksplorację wszystkim testerom manualnym, którzy myślą o testowaniu jako o wyzwaniu intelektualnym.
Radek Smilgin
