Testy akceptacyjne (UAT): jak odebrać oprogramowanie od dostawcy, żeby nie płacić za cudze błędy

Odbiór oprogramowania to decyzja biznesowa, nie podpis na końcu projektu

Koniec projektu wygląda u Was pewnie znajomo: dostawca zgłasza gotowość, zarząd pyta o datę startu, a testy akceptacyjne wypadają akurat w tygodniu, w którym wszyscy mają najmniej czasu. To nie jest niczyja wina, to normalna mechanika końcówki wdrożenia. Problem w tym, że właśnie wtedy zapada decyzja o największych skutkach finansowych w całym projekcie: odbiór oprogramowania.

Kodeks cywilny w art. 643 mówi, że zamawiający jest obowiązany odebrać dzieło wydane zgodnie z umową, a według art. 642 wynagrodzenie, w braku odmiennej umowy, należy się w chwili oddania dzieła. Dotyczy to umów kwalifikowanych jako umowa o dzieło, a umowy IT bywają kwalifikowane różnie, więc o szczegółach rozstrzyga treść Waszej umowy i warto ją sprawdzić z prawnikiem. Mechanizm jest jednak wspólny: podpis na protokole przenosi ryzyko z dostawcy na Was. Od tej chwili pieniądze są należne, a zgłaszanie wad przechodzi z trybu dostawca kończy pracę w tryb gwarancji i rękojmi.

Skala jest policzalna: w raporcie NIST z 2002 roku roczne koszty nieodpowiedniej infrastruktury testowania oprogramowania w USA oszacowano na od 22,2 do 59,5 mld dolarów, a ponad połowę tych kosztów ponoszą użytkownicy oprogramowania, nie producenci. Dane są amerykańskie i stare, ale mechanizm jest ponadczasowy: koszt wady ląduje u tego, kto na systemie pracuje. Jeśli po drodze macie wrażenie, że projekt żyje własnym życiem, spisaliśmy osobno oznaki, że dostawca wymyka Wam się spod kontroli. Dziś pytanie brzmi inaczej: co musi się wydarzyć przed podpisem, żeby podpis coś znaczył?

Czym są testy akceptacyjne (UAT), a czym nie są

Sylabus ISTQB Foundation Level w wersji 4.0.1 z 2024 roku definiuje testy akceptacyjne jako testy skupione na walidacji i wykazaniu gotowości do wdrożenia, czyli na tym, czy system spełnia potrzeby biznesowe użytkownika, i wskazuje, że najlepiej wykonują je docelowi użytkownicy. Ten sam sylabus ISTQB 4.0.1 wymienia sześć form testów akceptacyjnych: UAT, operacyjne, kontraktowe, regulacyjne, alfa i beta. Traktujcie to jako mapę pojęć, nie jako wzór do skopiowania.

Różnica, o którą toczy się gra: testy systemowe dostawcy odpowiadają na pytanie, czy zbudowano system zgodnie ze specyfikacją. UAT odpowiada na pytanie, czy da się na tym pracować u Was, na Waszych danych i Waszych procesach. To jedyny moment w projekcie, w którym sprawdzacie system własnymi oczami. Dlaczego rzetelne testy dostawcy nie zastępują drugiej pary oczu, opisaliśmy w artykule o testach dostawcy i testach niezależnych, więc tutaj tego wątku nie powtarzamy.

Kryteria akceptacji: spiszcie je, zanim powstanie pierwsza linijka kodu

Kryterium akceptacji ma być sprawdzalne, nie przymiotnikowe. Zapis system działa szybko nie jest kryterium, bo nie da się go rozstrzygnąć. Kryterium brzmi na przykład tak: wyszukiwanie klienta po numerze NIP zwraca wynik w ciągu 2 sekund przy 200 zalogowanych użytkownikach (to przykład ilustracyjny, własne liczby ustalacie u siebie). Sylabus ISTQB 4.0.1 z 2024 roku podaje dwa najczęstsze formaty kryteriów akceptacji: scenariusz w stylu Zakładając/Gdy/Wtedy (Given/When/Then) oraz listę reguł albo tabelę wejść i wyjść, a dobre kryteria opisują scenariusze pozytywne i negatywne.

W praktyce kryteria akceptacji są załącznikiem do umowy albo do zamówienia etapu, a każda zmiana wymagań zmienia też kryteria, na piśmie. Z naszego doświadczenia najtańszy moment na ich spisanie jest przed pierwszą linijką kodu: później każde doprecyzowanie wygląda jak zmiana zakresu i tak jest wyceniane. Jeśli Wasz zespół dopiero uczy się pisać wymagania, które da się potem odebrać, przygotowaliśmy szkolenie z pisania specyfikacji wymagań.

Scenariusze UAT, dane i ludzie: kto naprawdę prowadzi testy akceptacyjne

Scenariusz UAT to proces biznesowy od początku do końca, na przykład od złożenia zamówienia przez fakturę aż do korekty, a nie klikanie ekranów po kolei. Dlatego testują ludzie z biznesu, którzy znają wyjątki, bo wyjątki są w ich głowach, nie w specyfikacji. Mit, który widzimy w firmach, które szkolimy: UAT to formalność, bo dostawca już przetestował. Dostawca przetestował zgodność ze specyfikacją, a wyjątków z Waszej codzienności w specyfikacji nie było.

Trzy rzeczy, o których zamawiający zapomina najczęściej. Po pierwsze czas: testerzy z biznesu potrzebują zarezerwowanych godzin w kalendarzu, a nie dopisku w wolnej chwili, bo wolna chwila nie istnieje. Po drugie dane: testy na danych wymyślonych przez dostawcę nie pokażą, co stanie się z Waszymi danymi po przeniesieniu do nowego systemu, dlatego warto wcześniej przeczytać, jak wygląda testowanie migracji danych i systemów. Po trzecie środowisko: możliwie zbliżone do produkcji, z integracjami, bo system bez integracji to atrapa.

UAT jest w dużej części pracą ręczną i to jest jego zaleta, nie wada: pisaliśmy o tym w tekście o tym, dlaczego testy manualne wcale nie są mniej wartościowe. A jeśli po Waszej stronie brakuje osoby, która poprowadzi odbiór, możecie ją zatrudnić albo wypożyczyć: zajrzyjcie na QA Board, gdzie znajdziecie ponad 1000 profili specjalistów QA. W naszych projektach robiliśmy to także od podstaw: dla firmy z branży medycznej, ChaosGears, budowaliśmy dokumentację testową i odbiorczą oraz realizowaliśmy procedury odbiorcze. Metodyczne podejście do takich scenariuszy pokazujemy na szkoleniu testowanie procesów biznesowych (Business Process Testing).

Błąd blokujący a usterka: klasyfikacja, która rozstrzyga spory przy odbiorze

U naszych klientów najwięcej sporów przy odbiorze nie dotyczy tego, czy błąd jest, tylko jak go nazwać. Dlatego klasyfikację błędów i jej skutek dla odbioru wpisujcie do umowy: błąd blokujący wstrzymuje odbiór, błąd poważny pozwala na odbiór warunkowy z terminem naprawy wpisanym w umowie, a usterka trafia na listę poprawek w gwarancji. Ustalcie też z góry, kto rozstrzyga spór o klasyfikację: wskazana imiennie osoba albo niezależny tester. Bez tego każda dyskusja o jednym błędzie kończy się przepychanką o cały protokół.

Jedno jest pewne: każda runda poprawek to nowa runda testów, z regresją włącznie, i to ona zjada harmonogram. W projekcie dla Argos, firmy e-commerce, skróciliśmy regresję przed releasem z 5 dni do 10 godzin, a liczba błędów krytycznych na produkcji spadła o 46%. Przy trzech rundach poprawek taka różnica decyduje o tym, czy odbiór trwa tydzień, czy kwartał.

Protokół odbioru: co w nim powinno stać i gdzie zamawiający płaci za cudze błędy

Dobry protokół jest nudny i precyzyjny. Pułapki, które widzimy najczęściej: fikcja odbioru, czyli zapis, że brak uwag w X dni oznacza odbiór (przy UAT wypadającym w okresie urlopów robi się z tego odbiór automatyczny); ogólnik odbiór z uwagami bez listy błędów i terminów; podpis za całość po obejrzeniu jednego modułu; wreszcie protokół przygotowany przez dostawcę i podpisany bez własnych testów, a co sprawdza kontroler przy audycie niezależnym od producenta, opisaliśmy osobno. Skutki bywają wymierne: według wystąpienia pokontrolnego NIK z 2026 roku jedna z lubelskich uczelni publicznych zapłaciła łącznie 15,9 mln zł za system przyjęty odbiorem końcowym 30 września 2024 r., który do zakończenia kontroli w październiku 2025 r. nie został wdrożony, a prace wdrożeniowe toczyły się już w okresie gwarancji. Protokół odbioru podpisywany w piątek o 16:55 to zresztą osobny gatunek literacki, coś jak pakt o nieagresji przed weekendem: obie strony wiedzą, że zostało kilka spraw, i obie wolą o nich nie rozmawiać.

Kodeks cywilny daje Wam narzędzia jeszcze przed odbiorem: zgodnie z art. 636 przy wadliwym wykonywaniu dzieła możecie wezwać wykonawcę do zmiany sposobu wykonania w wyznaczonym terminie, a po jego bezskutecznym upływie odstąpić od umowy albo powierzyć poprawki komuś innemu na koszt wykonawcy. Do wad dzieła stosuje się przez art. 638 Kodeksu cywilnego przepisy o rękojmi, a art. 568 mówi o odpowiedzialności za wadę fizyczną stwierdzoną przed upływem dwóch lat od wydania. Umowa może te zasady modyfikować, więc swoją sprawdźcie z prawnikiem. Nasze zdanie po latach odbiorów: tańszy jest dobry protokół niż dobry prawnik.

Źródło: opracowanie własne Quality Island.

Tomasz Stelmach, CEO Quality Island, mówi o tym krótko: „Protokół odbioru to najdroższa kartka w całym projekcie. Podpisujecie na niej nie to, że system działa, tylko to, że od tej chwili jego problemy są Wasze. Dlatego zanim ktokolwiek sięgnie po długopis, chcę zobaczyć scenariusze, które przeszli ludzie z biznesu, na danych, na których firma naprawdę pracuje.”

Nasza perspektywa: dobry odbiór projektuje się na starcie projektu

Najlepsze odbiory, jakie widzimy u naszych klientów, nie są heroiczne. Są nudne, bo wszystko ustalono wcześniej: kryteria w załączniku do umowy, scenariusze gotowe, ludzie z zarezerwowanym czasem, klasyfikacja błędów bez pola do interpretacji. Testy akceptacyjne nie są wotum nieufności wobec dostawcy, są wspólnym językiem: dostawca wie, co ma dowieźć, a Wy wiecie, co sprawdzacie. Wtedy nikt nie płaci za cudze błędy, bo granica odpowiedzialności jest narysowana, zanim ktokolwiek jej potrzebuje.

W naszych projektach prowadzimy testy niezależne od producenta i zarządzanie testami po stronie zamawiającego, a osobom, które mają odbiory w obowiązkach, polecamy szkolenie Zarządzanie jakością w projekcie: testowanie, odbiory, dokumentacja. O tym, których decyzji o jakości żałuje się po roku, napisaliśmy osobny tekst. A na koniec pytanie, które zostawiamy Wam na dziś: ile z tych ustaleń macie już na piśmie w umowie, którą podpiszecie w przyszłym kwartale?

Powiązane na Strefie QA

• Testy dostawcy a testy niezależne: kiedy jedno nie zastępuje drugiego
• Jak wybrać firmę do testów oprogramowania: checklista dla dyrektora IT
• Umowa ramowa na testy: jak sektor publiczny kupuje QA i co z tego wynika dla wyceny

Źródła:

• Najwyższa Izba Kontroli, Wystąpienie pokontrolne: Uniwersytet Medyczny w Lublinie, kontrola I/25/001 „Nabywanie i wykorzystanie systemów informatycznych i teleinformatycznych przez wybrane lubelskie uczelnie publiczne”, 2026. Stąd liczby: 15,9 mln zł za system przyjęty odbiorem końcowym, 13,5 mln zł brutto za odbiory obszarów, 54 prace w obszarze Księgowość, niezawodność 60,08% przy wymaganych 95% oraz kary umowne 2 463 tys. zł.
• Kodeks cywilny, tekst jednolity, Dz.U. 2026 poz. 795, 2026. Stąd treść art. 643, 642, 636, 638 i 568 o odbiorze dzieła, wynagrodzeniu, wadliwym wykonywaniu i rękojmi.
• ISTQB, Certified Tester Foundation Level Syllabus v4.0.1, 2024. Stąd definicja testów akceptacyjnych, sześć ich form oraz dwa formaty kryteriów akceptacji.
• NIST, Planning Report 02-3: The Economic Impacts of Inadequate Infrastructure for Software Testing, 2002. Stąd szacunek od 22,2 do 59,5 mld dolarów rocznych kosztów oraz to, że ponad połowę ponoszą użytkownicy oprogramowania.