Test zaczyna się od oczekiwanego wyniku.
Zanim sprawdzimy aplikację, trzeba wiedzieć, jak ma działać. Warunek „rezerwacje są poprawne” jest zbyt ogólny. Lepiej opisać sytuację: grupa ma jedno wolne miejsce, potwierdzony zapis zajmuje je, a kolejny użytkownik nie może otrzymać tego samego miejsca jako dostępnego.
Warunki wynikają z procesu firmy. W warsztacie zmiana kosztorysu może wymagać ponownej akceptacji. W wypożyczalni dostępność dotyczy całego okresu, a nie tylko dnia odbioru. W sklepie jedna kupiona sztuka nie powinna znaleźć się w dwóch zgłoszeniach zwrotu.
Takie scenariusze zapisujemy razem z zakresem. Pomagają projektantowi, wykonawcy i osobie odbierającej produkt rozumieć to samo zachowanie. Pozwalają też rozróżnić błąd od nowej funkcji, która nie była częścią uzgodnionej pierwszej wersji.
Reguły można sprawdzać niezależnie od wyglądu.
Testy logiki potwierdzają między innymi sumę, limit miejsc, ważność danych i dozwolone przejście do kolejnego etapu. Mogą szybko sprawdzić wiele sytuacji, również granicznych. Dla wynajmu ważny jest dzień zwrotu, nakładające się okresy i największa liczba urządzeń zajętych jednocześnie.
Sprawdzenie reguły nie mówi jednak, czy użytkownik potrafi uruchomić ją w interfejsie. Przycisk może mieć błędne połączenie, komunikat nie pojawić się w widocznym miejscu, a pole zachować stare dane. Dlatego sam wynik testów modelu nie jest potwierdzeniem całej aplikacji.
W podglądzie wypożyczalni pokazujemy reguły okresu i ilości. Zapis do pamięci lokalnego podglądu różni się od wspólnej rezerwacji wielu użytkowników. Produkcyjne sprawdzenie współbieżności wymaga gotowej warstwy zapisu.
Interfejs testujemy na rzeczywistym zadaniu.
Osoba powinna przejść od informacji wejściowych do wyniku: wybrać usługę, poprawić dane, zobaczyć podsumowanie i otrzymać potwierdzenie. Testujemy także powrót do wcześniejszego kroku oraz zmianę warunków. Stare wyniki nie mogą udawać aktualnych po zmianie terminu lub liczby osób.
Na telefonie sprawdzamy czytelność, szerokość pól i możliwość działania bez precyzyjnego trafiania. Ważna jest obsługa klawiaturą, widoczny fokus i zrozumiały błąd. Szczególną uwagę wymagają długie nazwy, większy tekst i tabele, które trudno zmieścić w wąskim widoku.
W3C wyjaśnia, że narzędzie automatyczne nie ustala samodzielnie pełnej dostępności. Ocena WAI obejmuje także sprawdzenia wykonywane przez ludzi. Wynik skanera trzeba opisywać zgodnie z jego zakresem, a nie jako certyfikat całego produktu.
Integracje i role wymagają osobnych prób.
Połączenie z kalendarzem, magazynem lub płatnością ma własne dane i błędy. Sprawdzamy, czy zewnętrzny system przyjął operację oraz jak aplikacja reaguje na odrzucenie, opóźnienie i ponowienie. Widoczne potwierdzenie powinno wynikać z rzeczywistego rezultatu, nie samego kliknięcia.
Dla ról sprawdzamy również brak dostępu. Klient nie powinien zmienić cudzej sprawy tylko dlatego, że zna jej identyfikator. Ukryty przycisk nie stanowi pełnej ochrony. Warstwę serwerową trzeba sprawdzić według uprawnień właściwych dla konkretnego konta i działania.
Przed takimi próbami przygotowujemy właściwe środowisko i dane testowe. Rzeczywiste obciążenia płatności oraz operacje klientów wymagają kontrolowanego zakresu. Poradnik integracji opisuje, jak uzgodnić wymianę i warunki odbioru.
Firma ocenia zgodność z codzienną pracą.
Odbiór przez klienta ma inne zadanie niż wyłącznie sprawdzenie kodu. Pracownik próbuje obsłużyć anonimową sprawę znaną z praktyki i ocenia, czy ma właściwe informacje oraz działania. Właściciel potwierdza zgodność z ofertą, odpowiedzialnością i sposobem rozliczenia.
Uwagi zapisujemy wraz z sytuacją, oczekiwaniem i faktycznym wynikiem. Zdanie „to nie działa” trudno odtworzyć, natomiast opis wybranych danych oraz kroków pozwala rozpoznać problem. Nie potrzeba technicznego raportu od klienta, ale warto zachować kontekst jego próby.
Odbiór nie powinien wymagać zgadywania, co już wykonano. Materiał do oceny zawiera zakres wersji i ograniczenia środowiska. Jeśli ekran działa na danych przykładowych bez zapisu, informacja pozostaje jasna. Tak właśnie odróżniamy nasze podglądy od wdrożenia dla firmy.
Wynik sprawdzeń opisujemy z granicami.
Raport wskazuje wykonane scenariusze, środowisko, urządzenia oraz problemy wymagające poprawy. Nie należy łączyć wyniku reguł, testu interfejsu i przeglądu wizualnego w jedną nieokreśloną etykietę „wszystko sprawdzone”. Każde z tych działań odpowiada na inne pytanie.
Zmiana ważnej reguły wymaga sprawdzenia jej skutków i powiązanych scenariuszy. Nie trzeba jednak powtarzać wszystkich niezwiązanych prób po drobnej korekcie tekstu. Dobór zakresu kontroli powinien wynikać z tego, co zmieniono i jakie zachowanie może zależeć od poprawki.
Przed startem ustalamy, które problemy blokują główny proces, a które mogą mieć zaplanowany dalszy termin. To świadoma decyzja oparta na zakresie, bez obietnicy braku jakiegokolwiek przyszłego błędu. Opisz proces firmy, aby określić także warunki jego odbioru.
Odbiór aplikacji przez właściciela firmy.
Do odbioru przygotuj jeden pełny przebieg i oczekiwany rezultat. W przykładzie rezerwacji ustal wolny termin, konto klienta oraz osobę z obsługi. Klient wybiera usługę, sprawdza podsumowanie i potwierdza zapis. Obsługa odnajduje tę samą sprawę w panelu, ze zgodnym terminem i statusem.
Poprawne zakończenie: użytkownik otrzymuje potwierdzenie, a zespół widzi właściwe dane. Powtórne kliknięcie nie powinno tworzyć drugiej sprawy, jeśli taki jest uzgodniony przebieg.
Wyjątek: termin przestaje być dostępny przed potwierdzeniem. Użytkownik otrzymuje zrozumiały komunikat i może wybrać inny; stare podsumowanie nie udaje przyjętej rezerwacji.
Brak odpowiedzi: po opóźnieniu wiadomo, czy zapis został potwierdzony. Nie zakładamy sukcesu wyłącznie dlatego, że kliknięto przycisk. Sposób ponowienia działania wynika z ustaleń produktu.
Zapis odbioru wskazuje wersję, warunki próby, wynik i uwagi do poprawy. Oddziel problem z uzgodnionym zachowaniem od propozycji nowego modułu. W próbach korzystaj z przygotowanych danych, a dostęp do rzeczywistych informacji ustal z osobą odpowiedzialną w firmie. Pobierz checklistę odbioru i opisz zgłoszenie przez sytuację użytkownika.
Jaką decyzję podjąć dalej?
Aby sprawdzić rezultat z perspektywy pracownika firmy, zobacz Jak zorganizować odbiór przez osobę z firmy?.
Jeśli tę samą czynność można ponowić, sprawdź Ponowne kliknięcie: jak unikać podwójnej operacji?.
Od decyzji do zakresu wykonania.
Zakres związany z tą decyzją opisujemy na stronie Projektowanie UX/UI.