Testowanie akceptacji użytkownika (UAT)

Testowanie akceptacji użytkownika to ostateczny etap walidacji, w którym przedstawiciele firmy lub społeczności użytkowników potwierdzają, że system spełnia wymagania, dla których został stworzony, i jest odpowiedni do zamierzonego celu. Przeprowadza się je po testach funkcjonalnych, zazwyczaj w środowisku zbliżonym do produkcyjnego, a ich wynikiem jest decyzja o ewentualnym wydaniu.

Odpowiada na inne pytanie niż poprzedzające je testowanie. Testowanie programistyczne i testowanie jakości weryfikuje, czy system zachowuje się zgodnie ze specyfikacją; testowanie akceptacyjne weryfikuje, czy to, co zostało określone, faktycznie spełnia potrzeby biznesowe. Praca może przejść wszystkie testy funkcjonalne, a mimo to nie zostać zaakceptowana, ponieważ specyfikacja była niekompletna, proces został źle zrozumiany lub z powodu braku obsługi rzeczywistego przypadku, który nie został udokumentowany.

Najpoważniejszym problemem jest mylenie testów akceptacyjnych z testami użyteczności. Testy akceptacyjne wykorzystują osoby znające proces biznesowy, analizując scenariusze, aby upewnić się, że system je obsługuje. Testy użyteczności polegają na obserwacji reprezentatywnych użytkowników stykających się z produktem bez wskazówek, aby sprawdzić, czy jest on zrozumiały i użyteczny. Zastępowanie jednego drugim jest poważnym błędem: system może zostać zaakceptowany przez kompetentnych interesariuszy, a jednocześnie pozostać bezużyteczny dla osób, dla których został stworzony.

Dobór uczestników decyduje o tym, co ćwiczenie jest w stanie wykryć. Testy przeprowadzane przez zespół projektowy lub przez interesariuszy, którzy byli zaangażowani w cały proces i znają założenia systemu, potwierdzają, że wersja jest zgodna ze wspólnym rozumieniem i nie ujawniają niczego więcej. Włączenie osób, które będą faktycznie obsługiwać system i nie brały udziału w rozmowach projektowych, ujawnia rozbieżności między zamierzonym a rzeczywistym procesem.

Projektowanie scenariuszy powinno opierać się na rzeczywistej pracy, a nie na listach funkcji. Przejście przez zadania operacyjne, które system musi obsługiwać, w tym niewygodne wyjątki, które stanowią znaczną część rzeczywistej praktyki, pozwala wykryć problemy, których nie wykryje kontrola każdej funkcji osobno. Realistyczne dane są równie ważne, ponieważ systemy, które działają poprawnie z czystymi danymi testowymi, często zawodzą w przypadku wadliwych, niekompletnych i nietypowych rekordów zawartych w środowisku produkcyjnym.

Etap ten jest strukturalnie podatny na kompresję, ponieważ znajduje się na końcu harmonogramu, który zazwyczaj już został przesunięty. Uczestnicy, wciskając go między swoje normalne obowiązki, przeprowadzają testy akceptacyjne w ułamku zaplanowanego czasu, a znalezione defekty są przekazywane do poprawek po premierze. Zaplanowanie ich w realistycznym czasie, wcześniejsze zapewnienie czasu uczestnikom oraz wcześniejsze uzgodnienie, jaki stopień trudności wykrycia opóźni wydanie, zapobiegają przekształceniu się tego w formalność.

Kryteria selekcji usterek powinny zostać uzgodnione przed rozpoczęciem testów, a nie negocjowane pod presją, gdy już pojawią się ustalenia. Ustalenie, które kategorie problemów blokują wydanie, które są naprawiane natychmiast po ich zakończeniu, a które są rejestrowane na później, eliminuje argumentację z momentu, w którym presja komercyjna na kontynuację jest największa, a osąd najmniej wiarygodny.

Ponieważ akceptacja potwierdza przydatność do celów biznesowych, nie mówiąc nic o tym, czy użytkownicy końcowi mogą faktycznie korzystać z systemu, potrzebne są obie formy walidacji. W praktyce etap akceptacji jest planowany w ramach rozwój produktów w ramach procesu wydania, podczas gdy na osobne pytanie, czy prawdziwi użytkownicy mogą wykonywać swoje zadania, odpowiada się poprzez badania użytkowników, a w przypadku systemów wewnętrznych realizm operacyjny scenariuszy zwykle zależy od zaangażowania Dział IT oraz zespoły, które będą obsługiwać system po jego uruchomieniu.