Definicja
UAT (User Acceptance Testing) to ostatnia faza testowania przed wdrożeniem, w której użytkownicy biznesowi (nie testerzy) weryfikują, czy system spełnia ich rzeczywiste potrzeby.
UAT w kontekście poziomów testowania
| Poziom | Kto testuje | Co testuje |
|---|---|---|
| Unit | Deweloper | Pojedyncze funkcje |
| Integration | QA | Współpraca komponentów |
| System | QA | Całość systemu |
| UAT | Użytkownik biznesowy | Wymagania biznesowe |
Typy UAT
| Typ | Opis |
|---|---|
| Alpha testing | Testy wewnętrzne w środowisku deweloperskim |
| Beta testing | Testy przez wybranych użytkowników zewnętrznych |
| Contract testing | Weryfikacja kontraktu (formalnie) |
| Regulation testing | Weryfikacja zgodności z regulacjami |
Rola BA w UAT
| Działanie | Opis |
|---|---|
| Przygotowanie scenariuszy | Pisanie test cases na bazie kryteriów akceptacji |
| Koordynacja | Organizacja sesji, rekrutacja testerów |
| Wsparcie | Pomoc użytkownikom podczas testów |
| Raportowanie | Agregacja wyników, decyzja Go/No-Go |
Dlaczego to ważne?
UAT to ostatnia szansa na wykrycie problemów przed produkcją. BA pisze scenariusze na bazie kryteriów akceptacji i koordynuje cały proces.
Skąd ten skrót i jak brzmi w rozmowie
Czyta się go po literach: u-a-t. Rozwinięcie to User Acceptance Testing. Po polsku mówi się testy akceptacyjne użytkownika, testy odbiorcze albo po prostu odbiór. W projektach skrót odmienia się jak zwykłe słowo: "jesteśmy na UAT-cie", "poprawka pójdzie po UAT-ach", "to defekt z UAT-u".
Skrót pada w rozmowie bez ostrzeżenia i zwykle w towarzystwie innych skrótów. Zdanie w rodzaju "to pójdzie CR-em po UAT-ach" na pierwszym spotkaniu w nowym projekcie potrafi wyłączyć nową osobę na kawał spotkania, bo zamiast słuchać, próbuje rozszyfrować, o czym mowa. Pytać wypada. Ale lepiej wiedzieć wcześniej.
Jedno UAT, dwa znaczenia: faza i środowisko
To najczęstsze źródło nieporozumień u osób, które dopiero wchodzą do projektu. Ten sam skrót znaczy dwie różne rzeczy, zależnie od zdania.
| Kiedy pada | Co znaczy | Zdanie, które usłyszysz |
|---|---|---|
| UAT jako faza | etap, w którym biznes odbiera rozwiązanie | "UAT startuje w poniedziałek, są scenariusze?" |
| UAT jako środowisko | instalacja systemu, na której ten odbiór się odbywa | "wrzućcie to na UAT, produkcji nie ruszamy" |
W drugim znaczeniu UAT to jedno ze środowisk testowych, obok deweloperskiego i systemowego. Gdy ktoś pyta "czy to jest już na UAT-cie", pyta o środowisko, nie o etap projektu.
Kiedy w takim razie odbiór się zaczyna? Po testach systemowych i przed wdrożeniem na produkcję, na wersji, która jest już stabilna i wolna od defektów blokujących. Jeśli użytkownik siada do systemu, który wywraca się przy trzecim kliknięciu, to nie jest UAT, tylko testowanie zamiast zespołu.
Kto stawia podpis pod odbiorem
Tutaj początkujący analitycy tracą najwięcej czasu, bo w odbiorze bierze udział kilka osób, a decyduje jedna.
W MediFlow (nasz case szkoleniowy: system rejestracji wizyt online z przypomnieniami SMS dla sieci 12 przychodni, przewijający się przez wszystkie minikursy) decyzja go/no-go z odbioru rozkłada się tak:
| Kto | Rola przy odbiorze |
|---|---|
| Kierownik przychodni | jedyny zatwierdzający: to jego placówki ruszają, on mówi go albo no-go |
| Kierownik projektu | koordynuje przebieg odbioru, pilnuje scenariuszy i zgłoszeń |
| Rejestratorki | realnie klikają i testują na swoich scenariuszach |
| Dział IT | daje środowisko i poprawia defekty w trakcie, ale nie odpowiada za akceptację |
Jak to wyglądało w praktyce: UAT modułu e-rejestracji trwał tydzień. Sześć rejestratorek z trzech przychodni dostało środowisko testowe z zanonimizowanymi danymi i 22 scenariusze - umów pacjenta NFZ, umów wizytę komercyjną z płatnością, obsłuż odwołanie po terminie, przełóż wizytę do innego lekarza. Wyszły rzeczy, których żaden tester wcześniej nie wychwycił: choćby to, że rejestratorka w realnej pracy trzyma słuchawkę przy uchu i musi obsłużyć rezerwację samą klawiaturą, bez myszki.
Uwaga na dwie rzeczy, które zlewają się w tabeli wyżej, przy pozycji "raportowanie, decyzja go/no-go": analityk zbiera wyniki odbioru i rekomenduje decyzję, ale podpis stawia biznes. Podobnie rozjeżdżają się dwa rodzaje odpowiedzialności: kto odpowiada za projekt jako całość (zwykle kierownik projektu), a kto za odbiór biznesowy (ten, czyi ludzie ruszają na nowym systemie). To nie musi być ta sama osoba i zwykle nie jest.
Reguła jest prosta: wykonawców odbioru może być kilku, zatwierdzający jest jeden. Rozpisuje się to w macierzy RACI. Brak jednoznacznego "A" w wierszu "akceptacja UAT" to najczęstszy powód, dla którego gotowe wdrożenie stoi tydzień, bo nikt nie czuje się uprawniony do podpisu.
Scenariusze UAT nie biorą się z powietrza
Materiałem wejściowym do odbioru są kryteria akceptacji spisane wcześniej, przy wymaganiach. Tak wygląda kryterium w formacie Zakładając - Gdy - Wtedy, z którego powstaje scenariusz odbioru:
Zakładając, że pacjent ma potwierdzoną wizytę na jutro na 10:00 i podany numer komórki, Gdy do wizyty zostają dokładnie 24 godziny, Wtedy system wysyła jeden SMS z datą, godziną, adresem przychodni i nazwiskiem lekarza.
Osoba testująca nie musi rozumieć architektury. Dostaje stan wyjściowy, zdarzenie i oczekiwany wynik. I stąd bierze się najczęstsza diagnoza chaotycznego odbioru: jeśli scenariuszy nie da się wyprowadzić z kryteriów, to kryteria były za ogólne, a więc problem powstał na długo przed UAT. Jak je pisać, żeby dały się przetestować: kryteria akceptacji krok po kroku.
UAT jest ostatnią siatką, nie pierwszą
Typowa wpadka, która wychodzi dopiero na odbiorze: jeden system trzyma status klienta jako literę "A", drugi oczekuje słowa "active", nikt tego nie spisał w mapowaniu danych. Deweloperzy zgadują, testerzy łapią to na UAT, a analityk tłumaczy biznesowi, dlaczego ślizga się termin.
Defekt złapany na odbiorze jest tańszy niż ten sam defekt na produkcji i wyraźnie droższy niż wyłapany przy pisaniu wymagań. Nasze zdanie jest takie: jeśli na UAT sypie się dużo zgłoszeń typu "to miało działać inaczej", winna jest zwykle nieprecyzyjna analiza, a nie słabe testy.
Czym UAT nie jest
| To nie to samo co | Różnica |
|---|---|
| Testowanie systemowe | robi je zespół QA przed odbiorem i sprawdza działanie systemu jako całości, nie zgodność z potrzebą biznesu |
| Smoke testing | krótkie sprawdzenie, czy wersja w ogóle wstaje i da się ją testować |
| Testy użyteczności | pytają, czy da się wygodnie, a nie czy zgadza się z wymaganiami |
| Demo | pokaz działającej funkcji prowadzony przez zespół; odbiór to samodzielna praca użytkownika na scenariuszach |
Gdzie UAT widać w narzędziach
Na tablicy odbiór stoi zwykle jako osobny status, wstawiony między testy zespołu a "done". Ma to sens tylko wtedy, gdy ktoś faktycznie odbiera. Inaczej robi się z tego poczekalnia dla rzeczy, których nikt nie chce zamknąć, i po dwóch sprintach nikt już nie wie, co tam wisi i dlaczego. Jak ustawić taki workflow: Jira i Confluence dla analityka.
Czy UAT to wymóg z ogłoszeń o pracę
Rzadko wprost. Na 293 aktywne oferty w naszym job boardzie UAT pojawia się w 1 (odczyt 12.08.2026; sprawdzamy tytuł, skrót opisu i listę umiejętności, bo tyle danych trzymamy z każdej oferty). Wniosek nie brzmi jednak "nie trzeba tego umieć". Pracodawcy wypisują w ogłoszeniach narzędzia i metodyki, a udział w odbiorze traktują jako oczywisty element roli analityka i nie poświęcają mu osobnego punktu. Bieżące liczby z całego rynku: Barometr rynku BA.
Sprawdź, czy to rozumiesz
Bezpłatny test Testowanie dla BA: UAT i kryteria akceptacji, bez zakładania konta. A jeśli masz zaplanować odbiór od strony organizacyjnej (kryteria wejścia i wyjścia, dobór testerów, sign-off, raportowanie), całość rozpisana jest we wpisie UAT: jak zaplanować i przeprowadzić testy akceptacyjne.