UAT - jak zaplanować i przeprowadzić testy akceptacyjne

Wdrożenie systemu rezerwacji w MediFlow miało iść na produkcję w piątek. W środę odpaliliśmy UAT z trzema rejestratorkami - i w 20 minut pani Anna złamała system. Nie znalazła buga w kodzie. Zrobiła coś, czego nikt z nas nie przewidział: zarezerwowała wizytę, potem ją odwołała, a potem spróbowała zarezerwować ten sam termin ponownie. System pokazał błąd, bo termin „wisiał” w stanie pośrednim. Deweloperzy testowali happy path. Tester sprawdzał scenariusze z dokumentacji. Dopiero prawdziwa rejestratorka robiąca to, co robi codziennie, znalazła dziurę, która w piątek wybuchłaby na oczach pacjentów.

To jest cała istota UAT - User Acceptance Testing, testów akceptacyjnych użytkownika. To ostatnia brama przed produkcją, w której prawdziwi użytkownicy sprawdzają, czy system robi to, czego naprawdę potrzebują, a nie to, co napisano w specyfikacji. UAT nie testuje, czy kod działa (od tego są testerzy). UAT testuje, czy biznes dostał to, co zamówił. To dwie różne rzeczy i mylenie ich kosztuje wdrożenia. W tym artykule pokażę Ci, jak zaplanować i przeprowadzić UAT, który łapie problemy ZANIM trafią do użytkowników - na przykładzie systemu rezerwacji wizyt firmy MediFlow.

Czym jest UAT i czym różni się od testów testera

UAT to formalna faza testów, w której końcowi użytkownicy (lub ich reprezentanci biznesowi) weryfikują, czy system spełnia ich potrzeby i czy nadaje się do codziennej pracy. Najważniejsze słowo: akceptacja. Wynik UAT to decyzja biznesowa „bierzemy / nie bierzemy”, a nie techniczna ocena jakości kodu.

Rola analityka w UAT jest centralna. To Ty przekładasz wymagania na scenariusze testowe, przygotowujesz użytkowników, prowadzisz sesje, zbierasz uwagi i decydujesz (z biznesem), które defekty blokują wdrożenie. Bez analityka UAT zamienia się w chaotyczne „poklikajcie sobie i powiedzcie, czy działa” - a to nie test, to loteria.

Planowanie UAT - fundament sukcesu

Krok 1: Zdefiniuj kryteria wejścia i wyjścia

UAT zaczyna się dopiero, gdy spełnione są kryteria wejścia: system przeszedł testy testera, krytyczne bugi są naprawione, środowisko gotowe, dane testowe przygotowane. Odpalanie UAT na niedokończonym systemie to zaproszenie do tego, żeby użytkownicy zgłaszali znane już błędy i stracili zaufanie.

Kryteria wyjścia mówią, kiedy UAT się kończy sukcesem. Przykład z MediFlow: 100% scenariuszy krytycznych zaliczonych, zero defektów blokujących, max 5 defektów drobnych z planem naprawy. To kryteria wyjścia zamieniają „chyba działa” w decyzję opartą na faktach.

Krok 2: Wybierz właściwych testerów

Najczęstszy błąd: na UAT idą menedżerowie, bo „mają decyzyjność”. Tymczasem na UAT mają iść ci, którzy będą używać systemu codziennie. W MediFlow testowały trzy rejestratorki o różnym stażu - i to właśnie ta z 15-letnim doświadczeniem znalazła najwięcej problemów, bo automatycznie robiła rzeczy, których nikt nie zaprojektował. Reprezentuj różne role i poziomy doświadczenia.

Krok 2b: Przygotuj testerów - to nie jest „poklikajcie sobie”

Użytkownicy biznesowi rzadko testowali cokolwiek formalnie. Wrzucenie ich na UAT bez przygotowania kończy się chaosem: nie wiedzą, co zgłaszać, mylą bug z własną pomyłką, frustrują się. Krótkie wprowadzenie (30-45 minut) ratuje fazę. Powiedz im:

• Co testujemy, a czego nie. „Sprawdzamy, czy system nadaje się do Waszej codziennej pracy, nie czy jest ładny”.
• Że szukanie problemów to sukces, nie porażka. Znaleziony problem na UAT to oszczędność, nie powód do wstydu.
• Jak zgłaszać. Pokaż, gdzie wpisać uwagę, co opisać (co robiłem, co się stało, co miało się stać).
• Że mają robić to, co robią naprawdę. „Nie idźcie idealną ścieżką z instrukcji - róbcie to, co robicie codziennie, łącznie z dziwnymi przypadkami”.

To właśnie ostatni punkt sprawił, że pani Anna złamała system. Gdyby trzymała się scenariusza krok po kroku, nigdy nie zrobiłaby rezerwacji-odwołania-rezerwacji tego samego terminu. Zachęcenie do „bądź sobą” to najlepsza inwestycja w jakość UAT.

Krok 3: Napisz scenariusze testowe oparte na realnych przepływach

Scenariusze UAT to nie listy kliknięć. To realistyczne historie z życia. Wyprowadzaj je wprost z kryteriów akceptacji historyjek i z map procesów. Dobry scenariusz UAT dla MediFlow:

Scenariusz UAT-07: Pacjent przekłada wizytę
Rola: rejestratorka działająca w imieniu pacjenta
Warunek wstępny: pacjent ma zarezerwowaną wizytę na jutro

Kroki:

1. Otwórz kartę pacjenta i jego nadchodzącą wizytę.
2. Kliknij "Przełóż wizytę".
3. Wybierz nowy wolny termin w przyszłym tygodniu.
4. Potwierdź zmianę.

Oczekiwany rezultat:

- Stary termin wraca do puli wolnych.
- Nowy termin jest zablokowany dla pacjenta.
- Pacjent dostaje e-mail z nową datą.
- W historii wizyty widać ślad przełożenia.

Wynik: [ ] Zaliczony  [ ] Niezaliczony
Uwagi testera: _______________

Zostaw miejsce na uwagi testera - bo to tam pojawiają się rzeczy, których scenariusz nie przewidział („a co, jeśli przekładam na termin, który już sam zarezerwowałem?”).

Prowadzenie sesji UAT

Sesja UAT to nie egzamin, w którym czyhasz na pomyłki użytkownika. To wspólne polowanie na problemy. Kilka zasad, które sprawdziłem w praktyce:

• Nie podpowiadaj. Gdy tester nie wie, gdzie kliknąć, to nie jego błąd - to znaleziony problem z użytecznością. Zapisz to. Twoja podpowiedź zamaskuje realną wadę.
• Obserwuj, nie tylko czytaj wyniki. Najwięcej dowiesz się z tego, gdzie tester się zawahał, gdzie westchnął, gdzie kliknął nie tam. Wynik „zaliczony” z trzema błędnymi próbami po drodze to czerwona flaga.
• Notuj cytaty. „To jest nielogiczne, bo zawsze najpierw sprawdzam ubezpieczenie” to gotowe wymaganie na poprawkę.
• Klasyfikuj defekty od razu. Blokujący / poważny / drobny / kosmetyczny - żeby na końcu wiedzieć, co naprawdę wstrzymuje wdrożenie.

Raportowanie i decyzja o wdrożeniu

Po sesjach analityk zestawia wyniki w raport UAT, który odpowiada na jedno pytanie: czy wdrażamy? Raport zawiera: liczbę zaliczonych/niezaliczonych scenariuszy, listę defektów z klasyfikacją, rekomendację. Defekty klasyfikujesz tak:

Decyzja o wdrożeniu jest biznesowa, nie techniczna - ale analityk dostarcza fakty, na których biznes ją opiera. W MediFlow problem z podwójną rezerwacją po odwołaniu sklasyfikowaliśmy jako blokujący. Wdrożenie przesunęliśmy o trzy dni. Trzy dni opóźnienia kontra wstyd przed pacjentami w pierwszym tygodniu - łatwa decyzja, gdy masz dane.

Dane testowe - niewidzialny bohater UAT

Najlepsze scenariusze nie pomogą, jeśli środowisko UAT jest pełne danych w stylu „Jan Testowy, PESEL 00000000000”. Realne problemy wychodzą na realistycznych danych. Przygotowanie danych testowych to osobna, często lekceważona robota analityka:

• Różnorodność przypadków. Pacjent nowy i stały, wizyta dziś i za miesiąc, lekarz z pełnym grafikiem i z pustym. Jeden „idealny” rekord ukrywa większość bugów.
• Przypadki brzegowe w danych. Pacjent z dwoma kontami, termin na granicy 24h, lekarz na urlopie. To na nich system się sypie.
• Anonimizacja danych produkcyjnych. Jeśli kopiujesz dane z produkcji (kuszące, bo realistyczne), w systemie medycznym MUSISZ je zanonimizować - inaczej łamiesz RODO. To nie opcja, to wymóg.
• Stan początkowy każdego scenariusza. Scenariusz „przełożenie wizyty” wymaga, żeby pacjent MIAŁ już wizytę. Zadbaj, żeby warunki wstępne były spełnione, zanim tester usiądzie.

UAT w Agile vs waterfall

W modelu kaskadowym UAT to wyraźna, osobna faza na końcu projektu - duża, formalna, z podpisem akceptacyjnym. W Agile UAT rozprasza się na końce sprintów: po każdym przyroście biznes sprawdza, czy to, co dostarczono, nadaje się do użytku.

Moja rada niezależnie od modelu: im wcześniej prawdziwy użytkownik dotknie systemu, tym taniej kosztuje znaleziony problem. W MediFlow pokazywaliśmy rejestratorkom działające fragmenty już po drugim sprincie - i to wtedy, a nie na finałowym UAT, wyszła sprawa z podwójną rezerwacją. Gdyby projekt był czysto kaskadowy, dowiedzielibyśmy się o niej trzy miesiące później, tuż przed go-live.

Metryki UAT - jak zmierzyć, czy faza ma sens

UAT bez metryk to opinia. UAT z metrykami to decyzja. Kilka liczb, które warto śledzić i pokazać w raporcie:

• Pokrycie scenariuszy - ile procent zaplanowanych scenariuszy faktycznie wykonano. Jeśli 40% nie ruszono, akceptacja jest na wiarę, nie na dowodach.
• Wskaźnik zaliczenia - ile scenariuszy przeszło za pierwszym razem. Niski wskaźnik to sygnał, że system wszedł na UAT za wcześnie.
• Gęstość defektów wg klasy - ile blokujących, poważnych, drobnych. Klasy ważą więcej niż suma.
• Czas naprawy i retestu - jak szybko zgłoszony defekt wraca naprawiony. Wolny cykl wydłuża całą fazę.

Te liczby służą nie do oceniania zespołu, tylko do podjęcia świadomej decyzji o wdrożeniu. „95% scenariuszy zaliczonych, zero blokujących, dwa drobne z planem naprawy” to konkretna podstawa do go-live. „Wygląda nieźle” - to nie jest podstawa, to życzenie.

Częste błędy - czego unikać

• UAT jako druga tura testów testera. Użytkownicy zgłaszają bugi techniczne zamiast oceniać przydatność. Znak, że wpuściłeś UAT za wcześnie - przed spełnieniem kryteriów wejścia.
• Niewłaściwi testerzy. Menedżerowie zamiast codziennych użytkowników. Akceptują system, którego nie będą obsługiwać, i przegapiają realne problemy.
• Scenariusze oderwane od rzeczywistości. Testy sprawdzają funkcje pojedynczo, a nie realne przepływy. System „działa”, a w codziennej pracy się sypie na połączeniu kroków.
• Brak kryteriów wyjścia. „Wygląda OK, wdrażamy” - bez progu nie wiesz, czy gotowe. Pierwszy poważny problem na produkcji uczy pokory.
• Ignorowanie wahań użytkownika. Tester zaliczył scenariusz, ale szukał przycisku 30 sekund. To problem z użytecznością, który zignorowany wróci jako fala telefonów do supportu.
• UAT pod presją czasu. „Macie godzinę, poklikajcie”. Pośpieszny UAT to teatr akceptacji - wszyscy udają, że przetestowali, nikt nie wziął odpowiedzialności.

Role i odpowiedzialności w UAT

UAT, w którym „wszyscy odpowiadają za wszystko”, kończy się tym, że nie odpowiada nikt. Jasny podział ról decyduje o tym, czy faza ma właściciela:

Najważniejsza zasada: decyzja o akceptacji należy do biznesu, nie do analityka i nie do zespołu IT. Analityk dostarcza fakty i rekomendację, ale podpis „bierzemy” składa właściciel biznesowy, bo to on bierze na siebie konsekwencje. Rozmycie tej odpowiedzialności to klasyczny sposób, w jaki nieudane wdrożenie staje się „winą wszystkich i niczyją”.

Formalna akceptacja - sign-off, który coś znaczy

UAT kończy się formalnym sign-offem - świadomym potwierdzeniem, że biznes akceptuje system z pełną wiedzą o jego stanie. Dobry sign-off nie brzmi „wszystko jest idealne”. Brzmi: „akceptujemy wdrożenie; znamy 3 defekty drobne z planem naprawy w kolejnym wydaniu; defekt blokujący X został naprawiony i przetestowany ponownie”. To uczciwa akceptacja z otwartymi oczami, a nie podpis pod fikcją perfekcji. Załącz do niego raport UAT i listę otwartych defektów - to dokument, do którego wrócisz, gdy ktoś za miesiąc zapyta „dlaczego to weszło z tym błędem?”.

FAQ

Kto powinien przeprowadzać UAT?

Końcowi użytkownicy lub reprezentanci biznesowi, którzy będą używać systemu na co dzień - nie testerzy i nie menedżerowie „od decyzji”. Analityk organizuje i prowadzi proces, ale samego testowania nie wykonuje, bo zna system zbyt dobrze, żeby zachować świeże spojrzenie użytkownika.

Czym UAT różni się od testów akceptacyjnych w ogóle?

UAT to specyficzny rodzaj testów akceptacyjnych prowadzony przez użytkownika końcowego. Istnieją też inne typy testów akceptacyjnych - np. operacyjne (czy zespół IT umie system utrzymać) czy kontraktowe (czy spełnia zapisy umowy). UAT odpowiada na pytanie „czy biznes może z tym pracować?”.

Ile czasu trzeba zarezerwować na UAT?

Zależy od skali, ale typowo 1-2 tygodnie dla średniego systemu plus bufor na naprawę defektów i retest. Najczęstszy błąd to zaplanowanie UAT na ostatnie dwa dni przed go-live - bo gdy znajdziesz coś blokującego, nie masz już czasu na naprawę. Zostaw przestrzeń na poprawki i ponowne sprawdzenie.

Co zrobić, gdy użytkownicy znajdują dużo drobnych defektów?

Sklasyfikuj je i policz. Wiele drobnych defektów rzadko blokuje wdrożenie pojedynczo, ale ich masa może sygnalizować głębszy problem z jakością lub z dopasowaniem do procesu. Decyzję podejmuj na podstawie klas defektów, nie ich liczby - jeden blokujący waży więcej niż dwadzieścia kosmetycznych.

Podsumowanie i następny krok

UAT to ostatnia brama, w której biznes mówi „bierzemy” na podstawie tego, jak system zachowuje się w rękach prawdziwych użytkowników. Klucz to: jasne kryteria wejścia i wyjścia, właściwi testerzy (codzienni użytkownicy, nie menedżerowie), scenariusze z realnych przepływów i decyzja oparta na klasyfikacji defektów, a nie na „wygląda OK”. Pani Anna i jej podwójna rezerwacja to przypomnienie, że najcenniejszy tester to ten, który robi to, czego nie zaprojektowałeś.

Scenariusze UAT rodzą się wprost z kryteriów akceptacji, więc jeśli te są słabe, UAT będzie dziurawy - zacznij od poradnika o pisaniu kryteriów akceptacji Given-When-Then. Zobacz też, jak UAT łączy się z testowaniem i weryfikacją wymagań oraz macierzą śledzenia wymagań, która gwarantuje, że każde wymaganie ma swój test. A żeby sprawdzić, czy odróżniasz UAT od testów QA - zrób darmowy test wiedzy BA.