Web Testing Heuristic Checklist: 40 heurystyk testowania aplikacji webowych do skopiowania

Web Testing Heuristic Checklist to lista heurystyk (ang. heuristic, reguła kciuka), które podpowiadają testerowi, gdzie w aplikacji webowej najczęściej chowają się błędy: w nawigacji, w polach formularzy, w danych, w sesji, w dostępności i w bezpieczeństwie. Heurystyka nie jest przypadkiem testowym z oczekiwanym wynikiem, tylko pytaniem, które kieruje uwagę w miejsce o wysokim ryzyku. Dobra checklista nie zastępuje myślenia testera, tylko pilnuje, żeby nie zapomniał o rzeczach, które już raz kogoś zabolały.

W tym tekście pokazujemy, skąd wzięła się nazwa i lista (Test Heuristics Cheat Sheet Elisabeth Hendrickson, Jamesa Lyndsaya i Dale’a Emery’ego), jak działają najważniejsze heurystyki: SFDIPOT, Goldilocks, CRUD i kilka innych, dajemy pełną checklistę heurystyk do skopiowania w tabeli oraz instrukcję krok po kroku, jak zbudować własną checklistę dla Waszej aplikacji.

Co to jest heurystyka w testowaniu?

Heurystyka to omylna, ale użyteczna metoda rozwiązywania problemu. W testowaniu jest to skrót myślowy, który podsuwa pomysł na test: „sprawdź wartość za dużą, za małą i w sam raz”, „sprawdź, co się stanie, gdy dwie osoby edytują ten sam rekord”. Omylność jest tu cechą, nie wadą. Heurystyka nie gwarantuje znalezienia błędu, za to w krótkim czasie prowadzi w miejsca, w których błędy pojawiają się najczęściej.

Web Testing Heuristic Checklist łączy dwa ostatnie wiersze z drugim: to lista, ale złożona z pytań heurystycznych, a nie z kroków. Dlatego dobrze sprawdza się tam, gdzie scenariusze testowe nie nadążają za zmianami, czyli w większości nowoczesnych aplikacji webowych. Jak checklisty i heurystyki wpisują się w pozostałe typy testów webowych, pokazujemy w lekcji testowanie aplikacji webowych: co sprawdzić i jakimi narzędziami.

Skąd pochodzi Web Testing Heuristic Checklist?

Nazwa i układ tej checklisty pochodzą z Test Heuristics Cheat Sheet, ściągi opracowanej przez Elisabeth Hendrickson, Jamesa Lyndsaya i Dale’a Emery’ego, z prawami autorskimi Quality Tree Software z 2006 roku. Ministry of Testing opublikowało w 2022 roku jej rozszerzoną wersję, uzupełnioną przez kolejnych praktyków. Ściąga ma osobną sekcję testów webowych z grupami nawigacja, dane wejściowe, składnia, preferencje i dostępność, a obok niej sekcję ogólnych heurystyk, takich jak Goldilocks, CRUD, Follow the Data czy Interruptions.

Poprzednia wersja tego artykułu nie podawała tego źródła i ograniczała się do kilku ogólnych pytań. Uzupełniamy to, bo przy heurystykach źródło ma znaczenie praktyczne: oryginalna ściąga jest zwięzła i warto mieć ją otwartą obok naszej tabeli, a nazwy heurystyk ułatwiają rozmowę w zespole. Zdanie „sprawdziłem Goldilocks na polu ilości” mówi więcej niż „przetestowałem pole”.

Jak działa SFDIPOT na przykładzie aplikacji webowej?

SFDIPOT to mnemonik z Heuristic Test Strategy Model Jamesa Bacha, który dzieli produkt na siedem obszarów do przemyślenia: strukturę, funkcje, dane, interfejsy, platformę, sposób użycia i czas. Każda litera to pytanie: „czego jeszcze nie przetestowaliśmy z tej perspektywy?”. Poniżej przykład dla typowego procesu zamówienia w sklepie internetowym.

Jak używać heurystyk Goldilocks, CRUD i pokrewnych?

Heurystyki z sekcji ogólnej ściągi są krótkie, ale każdą łatwo przełożyć na konkretny test w aplikacji webowej. Poniżej te, których w naszych projektach używamy najczęściej, z przykładami.

Goldilocks to jedyna bajka, którą testerzy czytają w pracy bez wyrzutów sumienia. A mówiąc poważnie: heurystyki z tej listy najłatwiej przekazać nowym osobom w zespole, bo każda zmieści się na jednej karteczce. Kiedy znajdziecie dzięki nim błąd, zgłoście go tak, żeby programista mógł go odtworzyć za pierwszym razem. Jak to zrobić, piszemy w przewodniku jak poprawnie zgłosić błąd.

Pełna Web Testing Heuristic Checklist do skopiowania

Poniżej pełna checklista heurystyk testowania aplikacji webowych, zbudowana na grupach z sekcji testów webowych Test Heuristics Cheat Sheet i uzupełniona o obszary, które w naszej praktyce dają najwięcej błędów: sesję, uprawnienia, integracje i wydajność. Tabelę możecie skopiować do arkusza albo do strony w Confluence i dopisać kolumnę z wynikiem dla Waszej aplikacji.

To 40 heurystyk w dziewięciu obszarach. Nie musicie przechodzić wszystkich w każdej sesji. Lepiej wybrać kilka obszarów najbardziej ryzykownych dla danej zmiany i przejść je dokładnie. Sekcję wydajności rozwijamy w artykule jak szybko powinna ładować się strona internetowa, dostępność w tekście audyt dostępności strony, a pełne kryteria kontrastu i wielkości celu znajdziecie w WCAG 2.2.

Jak stworzyć własną checklistę heurystyk?

Gotowa lista to dobry start, ale najwięcej błędów łapie checklista dopasowana do Waszego produktu. Poprzednia wersja tego artykułu obiecywała kroki i ich nie podała, więc tu jest pełna instrukcja.

Jak nazwać heurystykę, żeby zespół ją zapamiętał? Najlepiej krótko i obrazowo, tak jak robią to autorzy ściągi. W naszych projektach u klientów sprawdzają się nazwy z życia zespołu, na przykład „test poniedziałku”, czyli sprawdzenie raportów po weekendzie bez ruchu. Taka nazwa żyje w rozmowach dłużej niż numer pozycji w dokumencie.

Jak używać checklisty w testach eksploracyjnych?

Checklista heurystyk działa najlepiej w testach eksploracyjnych prowadzonych w sesjach: z misją, ograniczonym czasem i notatkami. Misję sesji zapisuje się zwykle w krótkim szablonie, tzw. karcie sesji (charter). Przykład, który możecie skopiować:

KARTA SESJI EKSPLORACYJNEJ
Misja: zbadać proces zamówienia z kodem rabatowym
       z użyciem heurystyk Goldilocks, Interruptions i Follow the Data
Zakres: koszyk, kod rabatowy, płatność testowa, mail potwierdzający
Poza zakresem: panel administratora
Czas: 60 minut
Środowisko: staging, Chrome i Safari na iOS
Heurystyki z checklisty: Wstecz, Podwójne kliknięcie, Daty i czas, Eksporty

NOTATKI
- [hh:mm] co zrobiłem, co zobaczyłem
BŁĘDY
- tytuł, kroki, wynik oczekiwany i rzeczywisty
PYTANIA DO ZESPOŁU
-
CO ZOSTAŁO DO SPRAWDZENIA
-

Po sesji wnioski trafiają z powrotem do checklisty: nowy wzorzec błędu to nowa heurystyka. Z naszego doświadczenia to właśnie ta pętla odróżnia zespół, który „robi eksploracje”, od zespołu, który z każdą sesją testuje mądrzej. Prowadzenie testów eksploracyjnych w uporządkowany i mierzalny sposób ćwiczycie na szkoleniu testy eksploracyjne i heurystyczne w praktyce, a podstawy pracy z narzędziami przeglądarki, które przydają się przy wielu pozycjach z tabeli, na szkoleniu testowanie interfejsów webowych z użyciem DevTools. O tym, dlaczego praca manualna i eksploracyjna wciąż ma ogromną wartość, piszemy też na portalu Strefa QA w tekście czemu manualne testowanie wcale nie jest mniej wartościowe.

Czym różnią się heurystyki testowe od heurystyk Nielsena?

Słowo „heurystyka” pojawia się w dwóch światach i łatwo je pomylić. Heurystyki testowe, o których jest ten artykuł, podpowiadają, gdzie szukać błędów. Heurystyki użyteczności Jakoba Nielsena, opublikowane w 1994 roku i przejrzane przez Nielsen Norman Group w 2024 roku, służą do oceny interfejsu przez eksperta, czyli do tak zwanej ewaluacji heurystycznej. To dziesięć zasad, między innymi widoczność stanu systemu, kontrola i swoboda użytkownika, spójność i standardy, zapobieganie błędom oraz pomoc w rozpoznaniu błędu i wyjściu z niego.

Obie listy dobrze się uzupełniają. Pozycja „Przerwanie” z naszej tabeli prowadzi do sytuacji, którą potem oceniacie heurystyką Nielsena „pomóż użytkownikowi rozpoznać błąd i z niego wyjść”. Jeśli Wasz zespół testuje głównie interfejs, warto mieć obie listy w jednym miejscu. Jeśli wolicie, żeby przegląd aplikacji zrobił zespół z zewnątrz, prowadzimy testy oprogramowania, w tym testy dostępności i testy bezpieczeństwa aplikacji webowych.

Powiązane na blogu Quality Island

• Testowanie aplikacji webowych: co sprawdzić, jakie testy i jakimi narzędziami
• Jak poprawnie zgłosić błąd: praktyczny przewodnik
• 7 zasad testowania oprogramowania według ISTQB
• Jak szybko powinna ładować się strona internetowa? Progi Core Web Vitals
• Testy manualne: na czym polegają

Pełna lista źródeł

• Ministry of Testing, Test Heuristics Cheat Sheet, wersja z 2022 roku na podstawie oryginału Elisabeth Hendrickson, Jamesa Lyndsaya i Dale’a Emery’ego (Quality Tree Software, 2006). Stąd sekcja testów webowych i nazwy heurystyk.
• Michael Bolton, DevelopSense, How Models Change, 2014. Stąd historia mnemonika SFDPO, SFDPOT i SFDIPOT.
• James Bach, Satisfice, Heuristic Test Strategy Model, wersja 6.3 z 2024 roku. Model, z którego pochodzi SFDIPOT.
• Nielsen Norman Group, Jakob Nielsen, 10 Usability Heuristics for User Interface Design, 1994, przegląd 2024. Stąd heurystyki użyteczności.
• W3C, Web Content Accessibility Guidelines (WCAG) 2.2, 2023. Stąd kontrast 4,5:1 i minimalny rozmiar celu 24 na 24 piksele.
• OWASP Foundation, Web Security Testing Guide, wersja 4.2 z 2020 roku. Rozwinięcie pozycji z obszaru bezpieczeństwa.