Zespół dostarcza kiedyś system wydatków, który przechodzi każdy test techniczny. Już pierwszego dnia zespół finansowy odkrywa, że ​​nie jest w stanie obsługiwać roszczeń wielowalutowych, co stanowi dużą część jego pracy. Nic nie było “zepsute”, ale nie nadawało się do użytku. Testowanie akceptacji użytkownika ma na celu wykrycie dokładnie tego rodzaju luk przed uruchomieniem.

W tym przewodniku opisano, czym UAT różni się od innych testów, jak przeprowadzić go krok po kroku i jak zdecydować, kiedy będzie gotowy do wydania. Powyższy scenariusz i poniższe przykłady mają charakter poglądowy, a proces należy skalować tak, aby pasował do Twojego projektu.

Co to jest UAT?

UAT to zazwyczaj ostatnia faza testów przed wydaniem, podczas której zamierzeni użytkownicy potwierdzają, że oprogramowanie może wykonywać swoją pracę w realistycznych warunkach. Nazywa się to również testowaniem użytkownika końcowego lub testem akceptacyjnym. Następuje po rozwoju i testowaniu systemu, kiedy oczekuje się, że produkt będzie stabilny.

Jego celem nie jest znalezienie każdego błędu. Na tym etapie większość z nich powinna już zniknąć. Celem jest walidacja: czy zbudowaliśmy właściwą rzecz? Testerzy sprawdzają, czy produkt jest zgodny ze specyfikacją. UAT sprawdza, czy specyfikacja i produkt rzeczywiście odpowiadają potrzebom.

Testowanie UAT vs QA

UAT nie zastępuje innych testów. Jeśli użytkownicy ciągle napotykają podstawowe błędy, oznacza to, że kompilacja nie była gotowa, a Ty marnujesz ich ograniczony czas. Problemy te dotyczą wcześniejszych poziomów testów i testów regresyjnych.

Kto prowadzi UAT?

Wybierz testerów, którzy naprawdę dzisiaj wykonują swoją pracę. Doświadczony specjalista zajmujący się roszczeniami dostrzeże problemy, których menedżer lub pełnomocnik nigdy by nie zauważył. Uwzględnij zakres doświadczenia, ponieważ nowy pracownik często ujawnia mylące kroki, nad którymi ekspert pracuje, niezauważając. I upewnij się, że ich menedżerowie znajdą na to czas, ponieważ UAT nie może odnieść sukcesu przy pełnym obciążeniu pracą.

Rodzaje UAT

Siedmioetapowy proces UAT

1. Zdefiniuj zakres i cele

Zdecyduj, co jest akceptowane, co wykracza poza zakres i jakie wyniki biznesowe mają znaczenie. Na przykład: „Personel finansowy może przesłać, zatwierdzić i opłacić wniosek o wydatek w dowolnej obsługiwanej walucie”.

2. Uzgodnij kryteria akceptacji

Zapisz prostym językiem, jak wygląda sukces, najlepiej na początku projektu, a nie na tydzień przed jego uruchomieniem. Niejasne kryteria prowadzą do późniejszych kłótni.

3. Wybierz i zrekrutuj testerów

Wybierz prawdziwych użytkowników, wyjaśnij cel, pokaż im, jak rejestrować opinie i wyjaśnij, że testują oprogramowanie, a nie sami są testowani. Wiele osób martwi się, że coś pójdzie nie tak.

4. Przygotuj środowisko i dane

Środowisko UAT powinno przypominać środowisko produkcyjne tak bardzo, jak to jest praktyczne. Korzystaj z realistycznych danych, konfiguruj prawidłowe role użytkowników i sprawdzaj integracje, takie jak poczta e-mail. Jeśli kopiujesz dane produkcyjne, najpierw zamaskuj dane osobowe. Przeprowadź szybki test dymny, aby testerzy nie przyszli i nie znaleźli uszkodzonej kompilacji.

5. Napisz scenariusze

Oprzyj je na rzeczywistych przepływach pracy, a nie na pojedynczych przyciskach. Powinni czytać jak pracę, a nie jak oprogramowanie. W naszym przewodniku po przypadku testowym a scenariuszu testowym wyjaśniono, ile szczegółów potrzebujesz.

6. Uruchom testy i zbierz opinie

Prowadź sesje z osobą, która może Ci pomóc. Zbieraj problemy w jednym miejscu za pomocą zrzutów ekranu. Zostaw też trochę czasu na swobodną eksplorację, ponieważ ludzie próbują rzeczy, których scenariusze nigdy nie przewidują. Testowanie eksploracyjne oferuje przydatne techniki.

7. Napraw, przetestuj ponownie i wyloguj się

Segreguj opinie, napraw to, co istotne i poproś tych samych użytkowników o potwierdzenie poprawek. Następnie zapisz formalną decyzję.

Przypadek testowy UAT

Przypadek testowy UAT powinien być łatwy do naśladowania dla osoby nietechnicznej. Oto przykład systemu wydatków:

ID:        UAT-012
Scenario:  Submit a foreign currency expense claim
User role: Sales employee
Before:    Logged in, with a USD receipt ready

Steps:
  1. Create a new expense claim
  2. Enter a client dinner of 80 USD and attach the receipt
  3. Submit the claim for approval

Expected:  The amount is converted to INR at the current rate
           The manager receives an approval request
           The claim shows as "Awaiting approval"

Result:    Pass / Fail
Comments:
Tester / Date:

Należy pamiętać, że opisuje on rzeczywiste zadanie, a nie szczegóły techniczne i pozostawia miejsce na komentarze. Te komentarze często okazują się najcenniejszą częścią, typu „to działa, ale nigdy nie znalazłbym tego przycisku”.

Kryteria wejścia i wyjścia

Wpisują się one w szerszy cykl życia testowania oprogramowania. Ustal wcześniej liczby ze swoimi interesariuszami. „Zdecydujemy, kiedy uznamy to za stosowne” zwykle prowadzi do pośpiesznej odpowiedzi „tak”, pod warunkiem dotrzymania terminu.

Obsługa informacji zwrotnej

Informacje zwrotne od UAT są mieszanką różnych rzeczy i nie wszystkie są błędami. Sortuj według kategorii:

Stosuj jasne zasady określające, co blokuje wydanie, zgodnie z opisem w artykule ważność a priorytet. I odpowiadaj na każdy element, także ten, który odrzuciłeś. Ludzie przestają dawać informację zwrotną, jeśli wydaje się, że zanika. Nasz przewodnik na temat jak napisać raport o błędzie może pomóc testerom w jasnym opisaniu problemów.

Lista kontrolna UAT

Przed UATem

• Zakres i kryteria akceptacji uzgadniane są w formie pisemnej
• Zakończono testy systemowe i regresyjne
• Testerzy są wybierani, instruowani i mają czas
• Środowisko, rachunki i realistyczne dane są gotowe
• Dane osobowe w kopiach zostały zamaskowane
• Scenariusze są sprawdzane przez firmę
• Utworzono jedno miejsce do rejestrowania problemów
• Podano imię i nazwisko właściciela podpisu

Podczas UAT

• Dostępny jest kontakt z pomocą techniczną
• Problemy są rozpatrywane codziennie
• Postęp jest udostępniany zainteresowanym stronom
• Poprawki są wdrażane i ponownie testowane w kontrolowany sposób

Po UAT

• Sprawdzono kryteria wyjścia
• Znane problemy są udokumentowane wraz z właścicielami
• Formalne podpisanie umowy jest rejestrowane
• Informacje o szkoleniach i wydaniach zostały zaktualizowane
• Odbyła się krótka retrospektywa

UAT w zespołach Agile

Tradycyjny UAT kończy się jedną dużą fazą, w której niespodzianka jest kosztowna. Zwinne zespoły skracają tę pętlę. Właściciele produktu sprawdzają każdą historię pod kątem kryteriów akceptacji podczas sprintu, a użytkownicy widzą działające oprogramowanie podczas recenzji sprintu. Wiele zespołów nadal uruchamia skoncentrowany test UAT przed wydaniem głównej wersji, szczególnie gdy kilka funkcji łączy się w jeden przepływ pracy.

W przypadku częstych wydań techniki takie jak flagi funkcji i wdrożenia kanarkowe umożliwiają prawdziwym użytkownikom stopniowe wypróbowywanie nowych rozwiązań. Należy pamiętać, że uzupełniają one testy akceptacyjne, ale nie zastępują ich automatycznie, szczególnie w branżach regulowanych, które wymagają formalnego zapisu.

Typowe błędy

• Traktowanie tego jako formalności. Podpisanie bez rzeczywistego zastosowania nikogo nie chroni.
• Korzystanie z niewłaściwych testerów. Programiści i kontrola jakości mają zbyt dużą wiedzę o systemie, aby reprezentować użytkowników.
• Zaczynając od niestabilnej wersji. Testerzy szybko tracą zaufanie i zainteresowanie.
• Zostawianie tego na ostatnią chwilę. Nie ma wtedy czasu na poprawianie tego, czego się nauczyłeś.
• Korzystanie z nierealistycznych danych. Dane testowe rzadko charakteryzują się tak chaotycznymi przypadkami, jak w przypadku prawdziwej pracy.
• Pozwól na rozwój zakresu. Traktuj nowe pomysły jako prośby o zmiany, chyba że faktycznie blokują.

Podsumowanie

UAT to ostatnia szansa, aby dowiedzieć się przed wydaniem, czy oprogramowanie naprawdę pomaga ludziom, którzy będą z niego korzystać. Zaplanuj to od początku projektu, zrekrutuj prawdziwych użytkowników i ustal, jak ma wyglądać sukces. W przypadku następnej wersji wypróbuj jedną prostą zmianę: usiądź z jednym użytkownikiem podczas rzeczywistego scenariusza i nic nie mów, gdy pracuje.

Najczęstsze pytania

Ucz się dalej