W skrócie
- UAT robią przyszli użytkownicy na danych firmy - testy wykonawcy ich nie zastępują.
- Testuje się scenariusze z codziennej pracy, a nie pojedyncze przyciski.
- Każda usterka potrzebuje opisu: co zrobiono, co się stało, czego oczekiwano, zrzut ekranu i krytyczność.
- Ustal z góry, które usterki blokują odbiór, a które można usunąć po starcie.
- Wynik zamyka protokół odbioru: bez zastrzeżeń, z zastrzeżeniami albo odmowa.
Kto testuje
Osoby, które będą korzystać z systemu na co dzień, i ktoś, kto zna proces od strony biznesowej. Wykonawca testuje wcześniej i pomaga w UAT, ale to zamawiający ocenia, czy system nadaje się do pracy.
Zaplanuj czas tych osób - UAT robione „przy okazji” zwykle kończy się szybkim kliknięciem kilku ekranów.
Scenariusze testów
Zamiast testować pojedyncze funkcje, opisz scenariusze z prawdziwej pracy, np. „handlowiec przyjmuje zamówienie od klienta, kierownik je akceptuje, zamówienie trafia do ERP”. Do każdego scenariusza dopisz warianty:
- typowy przypadek,
- błędne dane i puste pola,
- odrzucenie i poprawa,
- nieobecność osoby akceptującej,
- duża liczba danych.
Dane testowe
Testuj na danych podobnych do prawdziwych: realne nazwy towarów, polskie znaki, długie opisy, nietypowe przypadki. Jeśli test odbywa się na kopii danych produkcyjnych, zadbaj o dane osobowe - mogą wymagać zanonimizowania.
Zgłaszanie usterek
Dobre zgłoszenie oszczędza dni wyjaśnień. Każde powinno zawierać:
- co zrobiono (kroki),
- co się stało,
- czego oczekiwano,
- zrzut ekranu albo nagranie,
- krytyczność: krytyczna (blokuje pracę), poważna (utrudnia), drobna (nie przeszkadza).
Decyzja o odbiorze
Ustal przed testami, które usterki blokują odbiór. Zwykle: krytyczne - tak, poważne - zależy od liczby i obejść, drobne - nie, ale trafiają do protokołu z terminem usunięcia. Wynik zapisuje się w protokole odbioru: bez zastrzeżeń, z zastrzeżeniami albo odmowa z uzasadnieniem.