Testy akceptacyjne (UAT): co to jest, rodzaje, kryteria akceptacji i jak je przeprowadzić

Czas czytania: około 12 minut

System przeszedł wszystkie testy, dostawca wysłał protokół, a tydzień po wdrożeniu dział sprzedaży pisze, że nie da się wystawić faktury korygującej do zamówienia z rabatem. Funkcja działa zgodnie ze specyfikacją. Problem w tym, że specyfikacja opisywała proces, którego w tej firmie nikt tak nie prowadzi. Tę lukę, między „działa zgodnie z dokumentem” a „nadaje się do pracy”, zamykają testy akceptacyjne, i to jedyny poziom testów, na którym decyduje odbiorca, nie wykonawca.

W tym tekście wyjaśniamy, czym są testy akceptacyjne według ISTQB, jakie mają rodzaje, czym są kryteria akceptacji i jak je zapisać, kto i kiedy je wykonuje, jak przeprowadzić je krok po kroku, czym różnią się od testów systemowych i regresyjnych oraz jak wyglądają w umowie z dostawcą i w sektorze regulowanym. Piszemy dla właścicieli produktu, kierowników projektów, analityków i testerów, którzy podpisują albo przygotowują protokół odbioru.

Czym są testy akceptacyjne?

Testy akceptacyjne to poziom testów, na którym sprawdza się, czy system spełnia potrzeby użytkowników, wymagania biznesowe i warunki umowy, a wynik służy do decyzji o wdrożeniu; według ISTQB ich celem jest zbudowanie zaufania do systemu i potwierdzenie gotowości do użycia, a nie wykrywanie defektów.

Tak ujmuje to słownik ISTQB: testowanie akceptacyjne to testowanie na poziomie systemu lub produktu, które ma ustalić, czy spełnia on potrzeby użytkownika i wymagania. Sylabus Foundation Level 4.0 dodaje, że jest to zwykle ostatni poziom w sekwencyjnym cyklu wytwarzania, ale w pracy iteracyjnej odbywa się na końcu każdej iteracji, a czasem przed testami systemowymi nowej funkcji.

Różnica wobec wszystkich wcześniejszych poziomów jest jedna i decydująca: na testach jednostkowych, integracyjnych i systemowych wykonawca sprawdza, czy zbudował produkt dobrze, a na testach akceptacyjnych odbiorca sprawdza, czy wykonawca zbudował dobry produkt. Dlatego nazywa się je też testami odbiorczymi, a ich wynik ma skutki finansowe i prawne, których nie ma żaden inny poziom testów.

Po co testy akceptacyjne, skoro system przeszedł testy systemowe?

Testy systemowe sprawdzają zgodność ze specyfikacją, a testy akceptacyjne sprawdzają zgodność z rzeczywistością odbiorcy: z jego procesami, danymi, ludźmi i infrastrukturą; system może być w stu procentach zgodny ze specyfikacją i nie nadawać się do pracy, jeśli specyfikacja była błędna albo niepełna.

Specyfikacja powstaje na początku projektu, często z rozmów z kilkoma osobami, i zawsze jest uproszczeniem. Testy akceptacyjne konfrontują system z pełnym obrazem: z pracownikiem, który wystawia korektę do zamówienia z rabatem, z danymi produkcyjnymi zawierającymi polskie znaki i puste pola, z administratorem, który musi odtworzyć kopię zapasową o trzeciej w nocy. Testy systemowe nie widzą tych scenariuszy, bo nie ma ich w dokumencie.

Drugi powód jest formalny. Odbiór to moment, w którym odpowiedzialność przechodzi z wykonawcy na odbiorcę, a płatność zostaje uruchomiona. Bez własnych testów odbiorca podpisuje protokół na podstawie zapewnień dostawcy, co w praktyce oznacza, że błędy znajdzie po wdrożeniu, gdy poprawki są już płatne osobno. O tym, ile kosztuje błąd wykryty za późno, piszemy w tekście o shift left testing.

Liczby z projektu dla Argos, potwierdzone przez klienta. Dla ChaosGears, firmy z branży medycznej, budowaliśmy dokumentację testową i odbiorczą oraz realizowaliśmy procedury odbiorcze, bo tam odbiór systemu jest częścią wymagań, a nie formalnością na końcu.

Jakie są rodzaje testów akceptacyjnych?

ISTQB wyróżnia testy akceptacyjne użytkownika (UAT), produkcyjne testy akceptacyjne (operacyjne), testy akceptacyjne zgodności z umową, testy akceptacyjne zgodności z przepisami oraz testy alfa i beta; różnią się tym, kto testuje, co sprawdza i jaka decyzja z nich wynika.

Definicje poszczególnych rodzajów: UAT, produkcyjne, zgodności z umową, zgodności z przepisami, alfa i beta w słowniku ISTQB. W projekcie na zamówienie zwykle występują pierwsze cztery, w produkcie dla wielu klientów dwa ostatnie, które opisujemy osobno w tekście o testach alfa i beta. Miejsce testów akceptacyjnych wśród innych poziomów opisujemy w tekście o poziomach testowania.

Czym są kryteria akceptacji i jak je pisać?

Kryteria akceptacji to zapisane przed rozpoczęciem prac warunki, które system musi spełnić, żeby odbiorca go przyjął; dobre kryterium jest sprawdzalne (da się jednoznacznie stwierdzić, czy spełnione), mierzalne tam, gdzie chodzi o liczby, i uzgodnione z obiema stronami, zanim powstanie kod.

Słownik ISTQB definiuje kryteria akceptacji jako kryteria, które system musi spełnić, żeby został zaakceptowany przez użytkownika, klienta lub inny upoważniony podmiot. W praktyce kryteria dzielą się na funkcjonalne (proces da się wykonać od początku do końca), niefunkcjonalne (czas odpowiedzi, dostępność, bezpieczeństwo, zgodność z WCAG), operacyjne (kopie, odtwarzanie, aktualizacje) i dokumentacyjne (instrukcje, dokumentacja techniczna, protokoły). Kryterium „system działa poprawnie” nie jest kryterium, bo każda strona rozumie je inaczej.

Kryterium akceptacji dla procesu korekty zamówienia (zapis Given, When, Then)

Scenariusz: korekta faktury do zamówienia z rabatem procentowym
  Zakładając, że zamówienie 10234 ma rabat 10% i wystawioną fakturę
  Gdy pracownik działu sprzedaży zmniejsza ilość produktu z 3 na 2
  Wtedy system wystawia fakturę korygującą na różnicę z zachowaniem rabatu 10%
  Oraz korekta jest widoczna w historii zamówienia i w eksporcie do księgowości w ciągu 5 minut

Kryterium niefunkcjonalne:
  Lista 500 zamówień z filtrem po dacie ładuje się poniżej 2 sekund przy 50 równoczesnych użytkownikach
Kryterium operacyjne:
  Odtworzenie bazy z kopii z poprzedniego dnia trwa poniżej 60 minut i kończy się poprawnym logowaniem 3 użytkowników testowych

Taki zapis ma dwie zalety: da się go wykonać jako test i da się go wpisać do umowy. Format Given, When, Then opisujemy w tekście o języku Gherkin, a sposób ułożenia kryteriów w całość w tekście o planie testów.

Kto wykonuje testy akceptacyjne i kiedy?

Testy akceptacyjne wykonuje odbiorca: użytkownicy biznesowi i właściciel produktu dla UAT, administratorzy dla testów produkcyjnych, a niezależni testerzy w imieniu odbiorcy tam, gdzie brakuje mu kompetencji albo gdzie wymaga tego umowa lub przepisy; czas to koniec każdej iteracji w pracy zwinnej i etap przed wdrożeniem w projekcie sekwencyjnym.

W projektach zwinnych testy akceptacyjne nie są jednym wydarzeniem na końcu, tylko dwoma czynnościami w każdej iteracji: sprawdzeniem, czy nowa funkcja spełnia swoje kryteria akceptacji, oraz walidacją z użytkownikami, czy w ogóle odpowiada na ich potrzebę. Odbiór końcowy w takim projekcie potwierdza to, co zostało odebrane przyrostowo, zamiast odkrywać wszystko naraz w ostatnim tygodniu.

Jak przeprowadzić testy akceptacyjne krok po kroku?

Testy akceptacyjne prowadzi się w sześciu krokach: kryteria akceptacji uzgodnione przed pracami, scenariusze z realnych procesów, środowisko i dane zbliżone do produkcji, sesje testowe z użytkownikami i rejestrem defektów, decyzja według ustalonych kryteriów wyjścia oraz protokół odbioru z listą odstępstw.

Krok 4 pada najczęściej, bo użytkownicy testują „przy okazji”, bez scenariusza i bez rejestru, a po tygodniu nikt nie wie, co zostało sprawdzone. Rozwiązaniem jest tester prowadzący sesję, który pilnuje scenariusza i zapisuje wynik, podczas gdy użytkownik skupia się na swoim procesie. Jak zgłaszać defekty tak, żeby dostawca je przyjął, opisujemy w tekście Jak poprawnie zgłosić błąd.

Czym różnią się testy akceptacyjne od systemowych, regresyjnych i end to end?

Testy systemowe sprawdzają cały system wobec specyfikacji i wykonuje je wykonawca, testy regresyjne sprawdzają, czy zmiany nie zepsuły tego, co działało, testy end to end sprawdzają pełną ścieżkę użytkownika przez wiele systemów, a testy akceptacyjne sprawdzają, czy odbiorca może i chce system przyjąć; różni je cel, wykonawca i skutek wyniku.

Testy akceptacyjne nie zastępują żadnego z pozostałych. Zespół, który przesuwa szukanie defektów na etap odbioru, płaci za to dwa razy: raz opóźnionym wdrożeniem, drugi raz zaufaniem użytkowników, którzy zapamiętają system jako zepsuty. O regresji piszemy w tekście o testach regresyjnych, o pełnych ścieżkach w tekście o testach end to end, a o kolejności filtrów przed odbiorem w tekście o smoke teście i sanity teście.

Testy akceptacyjne w umowie i w sektorze regulowanym: kto powinien je wykonać?

W umowie testy akceptacyjne powinny mieć zapisane kryteria, procedurę, kryteria wyjścia i skutki nieodebrania; w sektorze regulowanym, na przykład w bankowości pod rozporządzeniem DORA albo w medycynie, testy odbiorcze coraz częściej muszą wykonać osoby niezależne od dostawcy, bo dostawca testujący własny produkt nie jest odbiorem, tylko deklaracją.

• Kryteria w umowie, nie w załączniku dopisanym później. Kryteria akceptacji zgodności z umową ustala się przy jej zawieraniu. Umowa bez kryteriów daje dostawcy prawo twierdzić, że „działa zgodnie z ofertą”.
• Procedura odbioru. Kto testuje, na jakim środowisku, w jakim terminie, jak zgłasza defekty, ile czasu ma dostawca na naprawę, co się dzieje przy odbiorze warunkowym.
• Kryteria wyjścia i skutki. Przy jakich wynikach odbiór następuje, przy jakich jest warunkowy, przy jakich nie następuje i co to oznacza dla płatności i terminów.
• Niezależność. W projektach, w których odbiorca nie ma własnego zespołu testowego, testy odbiorcze wykonuje niezależna firma w jego imieniu. W sektorze finansowym i medycznym bywa to wymóg, nie wybór.
• Dokumentacja odbiorcza. Protokoły, rejestry defektów, dowody wykonania scenariuszy. W sektorze regulowanym to materiał dla audytu i kontroli, a nie wewnętrzna notatka.

Wymagania wobec testów w sektorze finansowym, w tym kto może je wykonywać i jak często, rozkładamy w tekście o rozporządzeniu DORA i testach niezależnych. Dla firm, które odbierają system od dostawcy bez własnego zespołu QA, prowadzimy testy akceptacyjne i odbiorcze jako strona niezależna: od kryteriów, przez sesje z użytkownikami, po protokół.

Jakie są najczęstsze błędy w testach akceptacyjnych?

Najczęstsze błędy to brak kryteriów przed pracami, testowanie przez dostawcę zamiast odbiorcy, użytkownicy klikający bez scenariusza i rejestru, pominięcie produkcyjnych testów akceptacyjnych, dane testowe niepodobne do produkcyjnych, odbiór pod presją terminu oraz traktowanie odbioru jako polowania na defekty.

1. Kryteria ustalane w tygodniu odbioru. Każda strona ma wtedy inny obraz „gotowego” i odbiór zamienia się w negocjację.
2. Dostawca testuje za odbiorcę. Wynik jest deklaracją wykonawcy. Odbiór wymaga własnych testów albo niezależnej strony.
3. Klikanie bez scenariusza. Użytkownicy sprawdzają to, co lubią, a pomijają zamknięcie miesiąca, bo „to dopiero za trzy tygodnie”.
4. Brak testów produkcyjnych. System odebrany, a nikt nie sprawdził odtworzenia kopii, aktualizacji ani uprawnień. Pierwsza awaria pokazuje, że nie ma procedury.
5. Dane z generatora. Na danych syntetycznych wszystko działa. Na danych z produkcji wychodzą polskie znaki w nazwiskach, puste pola z migracji i rekordy sprzed dziesięciu lat.
6. Odbiór pod presją terminu. „Odbierzmy, poprawki potem” bez listy zastrzeżeń z datami oznacza, że poprawki będą płatne osobno, a termin ich wykonania nie istnieje.
7. Odbiór jako szukanie defektów. Jeśli testy akceptacyjne znajdują dziesiątki błędów, to nie odbiór działa dobrze, tylko wcześniejsze poziomy zawiodły. Wniosek dotyczy procesu dostawcy, nie tylko tej wersji.

Kiedy uznać system za odebrany?

System uznaje się za odebrany, gdy spełnia zapisane wcześniej kryteria wyjścia: wszystkie scenariusze akceptacyjne wykonane, zero defektów krytycznych, liczba defektów istotnych poniżej ustalonego progu z terminami naprawy, testy produkcyjne zaliczone, dokumentacja dostarczona, a odstępstwa spisane w protokole z warunkami.

Odbiór warunkowy jest dopuszczalny i często rozsądny, pod jednym warunkiem: każde zastrzeżenie ma opis, termin i skutek niewykonania. Bez tego odbiór warunkowy jest odbiorem bezwarunkowym z dopiskiem. Kompetencje w tym obszarze budujemy na szkoleniu Tworzenie dokumentacji testowej oraz Analiza testowa: od wymagań do przypadków testowych, a wiedzę dla liderów jakości publikujemy na portalu Strefa QA.

Najczęstsze pytania o testy akceptacyjne

Co to są testy akceptacyjne?

Testy akceptacyjne to poziom testów, na którym odbiorca sprawdza, czy gotowy system spełnia potrzeby biznesowe, wymagania użytkowników i warunki umowy na tyle, żeby można go było wdrożyć i za niego zapłacić. Ich celem jest decyzja o odbiorze, nie wykrywanie defektów.

Kto wykonuje testy akceptacyjne?

Odbiorca: użytkownicy biznesowi i właściciel produktu dla testów akceptacyjnych użytkownika, administratorzy dla produkcyjnych testów akceptacyjnych, a niezależni testerzy w imieniu odbiorcy tam, gdzie brakuje mu kompetencji albo wymaga tego umowa lub przepisy. Dostawca przygotowuje środowisko, ale nie testuje za odbiorcę.

Czym są testy UAT?

UAT, czyli testy akceptacyjne użytkownika, to rodzaj testów akceptacyjnych, w którym przyszli użytkownicy sprawdzają w środowisku zbliżonym do produkcyjnego, czy system pozwala wykonać ich procesy biznesowe z minimalną liczbą problemów. To najczęstszy, ale nie jedyny rodzaj testów akceptacyjnych.

Jakie są rodzaje testów akceptacyjnych?

Według ISTQB: testy akceptacyjne użytkownika (UAT), produkcyjne testy akceptacyjne (operacyjne), testy akceptacyjne zgodności z umową, testy akceptacyjne zgodności z przepisami oraz testy alfa i beta dla produktów z półki.

Czym są kryteria akceptacji?

To zapisane przed rozpoczęciem prac warunki, które system musi spełnić, żeby odbiorca go przyjął. Dobre kryterium jest sprawdzalne, mierzalne tam, gdzie chodzi o liczby, i uzgodnione z obiema stronami. Dzielą się na funkcjonalne, niefunkcjonalne, operacyjne i dokumentacyjne.

Czym różnią się testy akceptacyjne od testów systemowych?

Testy systemowe sprawdzają zgodność całego systemu ze specyfikacją i wykonuje je wykonawca. Testy akceptacyjne sprawdzają, czy system nadaje się do pracy w realnych procesach odbiorcy, wykonuje je odbiorca, a wynik decyduje o wdrożeniu i płatności.

Kiedy przeprowadza się testy akceptacyjne?

W projekcie sekwencyjnym po testach systemowych, przed wdrożeniem i odbiorem. W pracy zwinnej na końcu każdej iteracji, jako sprawdzenie kryteriów akceptacji nowej funkcji i walidacja z użytkownikami, a odbiór końcowy potwierdza to, co zostało odebrane przyrostowo.

Czy testy akceptacyjne może wykonać dostawca?

Dostawca może je przygotować i wspierać, ale nie powinien ich wykonywać za odbiorcę, bo wtedy wynik jest deklaracją wykonawcy, nie odbiorem. W sektorze regulowanym testy odbiorcze coraz częściej muszą wykonać osoby niezależne od dostawcy.

Powiązane na blogu Quality Island

• Poziomy testowania oprogramowania: od testów jednostkowych po akceptacyjne
• Testy regresyjne: co to jest, rodzaje, kiedy je uruchamiać i jak skrócić regresję z dni do godzin
• Język Gherkin: co to jest i jak go używać w testowaniu oprogramowania
• Rozporządzenie DORA a testy: kto musi, jak często i dlaczego niezależnie
• Jak napisać plan testów
• Testy end to end (E2E): co to jest, kiedy je uruchamiać i ile ich naprawdę potrzebujecie

Pełna lista źródeł

• ISTQB Glossary, hasła acceptance testing, user acceptance testing, operational acceptance testing, contractual acceptance testing, regulatory acceptance testing, alpha testing, beta testing i acceptance criteria
• ISTQB, sylabus Certified Tester Foundation Level v4.0, rozdział o poziomach testów
• Rozporządzenie (UE) 2022/2554 (DORA), tekst w EUR-Lex
• Wikipedia, Acceptance testing
• Dane własne Quality Island: projekt dla Argos (e-commerce, liczby potwierdzone przez klienta), projekt dla ChaosGears (branża medyczna, dokumentacja testowa i odbiorcza, procedury odbiorcze), ponad 152 zrealizowane projekty, ponad 100 firm