Ręczne testowanie UI powstało z konieczności, ponieważ narzędzia automatyczne słabo uchwycają błędy związane z percepcją wizualną i użytecznością interfejsu (historia). Wszystkie elementy powinny być dostępne, wyświetlać się poprawnie i działać zgodnie z oczekiwaniami użytkownika.
Głównym problemem ręcznego testowania UI jest subiektywna ocena: różni ludzie mogą różnie postrzegać ten sam interfejs. Ponadto, często zdarzają się sytuacje, w których defekty wizualne nie są dokumentowane lub są ignorowane (‘problem’). Aby uniknąć subiektywności, należy opracować jasne kryteria akceptacji wizualnych elementów, używać izometrycznych oraz wytycznych, a znalezione problemy dokumentować za pomocą zrzutów ekranowych, jasnych opisów i porównań z oryginalnymi makietami (‘rozwiązanie’).
Kluczowe cechy:
Czy wystarczy sprawdzić UI tylko w jednej przeglądarce lub na jednym urządzeniu?
Nie, elementy mogą być wyświetlane różnie z powodu różnic w silnikach przeglądarek i rozdzielczościach urządzeń.
Jeśli tester nie widzi defektu, czy może uważać, że błąd nie występuje?
Nie, należy porównywać interfejs z wytycznymi i makietami, a nie polegać tylko na własnym subiektywnym spojrzeniu.
Czy można ignorować wymagania dotyczące dostępności (accessibility) podczas testowania UI?
Nie, wymagania dotyczące dostępności są ważne dla końcowych użytkowników, w tym dla osób z ograniczeniami.
Tester sprawdził UI tylko na swoim komputerze i w jednej przeglądarki, a także tylko wizualnie porównał z poprzednią wersją, bez oparcia na makiecie. W efekcie użytkownicy korzystający z urządzeń mobilnych zobaczyli uszkodzony interfejs.
Zalety:
Wady:
Tester sprawdził UI na różnych urządzeniach i przeglądarkach, porównał z makietą, uwzględnił wytyczne dotyczące dostępności. Użył checklistów dotyczących wizualnych kryteriów.
Zalety:
Wady: