Testy odbiorowe (UAT — User Acceptance Testing) to ostatni moment, w którym możesz powiedzieć dostawcy: „to nie działa, popraw". Po podpisaniu protokołu odbioru każda poprawka jest już rozmową o dodatkowej fakturze. Większość MŚP marnuje tę okazję na godzinne spotkanie, na którym oglądają ładne demo.
Znamy ten scenariusz na pamięć. Dostawca przychodzi z laptopem, pokazuje 4-5 przypadków użycia na wyselekcjonowanych rekordach, wszystko klika w 2 sekundy. Prezes patrzy, mówi „wygląda dobrze", podpisuje protokół. Miesiąc po go-live okazuje się, że w produkcji ten sam ekran działa 40 sekund, bo w bazie jest 8000 kartotek zamiast pięciu, a handlowcy z trasy nie mogą wpisać rabatu, bo widok mobilny nie ma tego pola.
U jednego z naszych klientów — 22-osobowa firma dystrybucji części samochodowych na Śląsku — testy odbiorowe nowego CRM zajęły dwa spotkania po godzinie. Dyrektor obejrzał demo, kliknął „OK". Miesiąc po starcie okazało się, że handlowcy w trasie w ogóle nie korzystali z systemu — widok mobilny nie pokazywał pola rabatu indywidualnego, więc oferty i tak wypisywali w Excelu i wysyłali z prywatnych maili. 3 miesiące pracy i około 45 000 zł konsultacji poszło w błoto. Poprawki po fakcie kosztowały kolejne 18 000 zł, a wdrożenie trzeba było de facto powtórzyć.
To jest cena skróconego UAT. I jeszcze łagodna cena — bo nie doszło do awarii, tylko do wygaszenia inwestycji. Znacznie gorzej wygląda scenariusz, w którym firma odbiera zintegrowany ERP z WMS i po tygodniu okazuje się, że kompletacja zamówień działa 3× wolniej niż przed wdrożeniem.
Demo to nie test
Demo od dostawcy pokazuje, że system potrafi zrobić to, o co go poprosisz. Test odbiorowy sprawdza, czy system poradzi sobie z tym, co Twoja firma wrzuci mu na klawiaturę w poniedziałek rano.
Różnica jest ogromna. Demo używa 3 przygotowanych rekordów. Twoja produkcja ma 15 000. Demo pokazuje jednego użytkownika. Twoja produkcja ma 12 osób klikających jednocześnie. Demo pokazuje ścieżkę „wszystko poszło dobrze". Twoja produkcja produkuje wyjątki: brakującą kartotekę, zdublowanego kontrahenta, plik CSV z BOM-em na początku, sieć, która na 2 minuty pada.
Jeżeli w UAT używacie tych samych danych, tych samych scenariuszy i tego samego użytkownika co na demie — to nie jest test. To jest kolejne demo, tylko wam się wydaje, że coś sprawdziliście.
Scenariusze pisz z życia, nie z oferty
Dobre scenariusze testowe nie biorą się z dokumentacji dostawcy. Biorą się z tego, co Twoja firma faktycznie robi każdego dnia. Klasyczny błąd: dostawca dostarcza „listę przypadków testowych" na 30 pozycji, ludzie z firmy klikają je posłusznie, wszystko przechodzi. Nikt nie zauważył, że na tej liście nie ma sytuacji „handlowiec wystawia korektę do faktury sprzed 3 miesięcy, do której klient dopłacił zaliczkę przelewem w EUR".
Zbierz 15-20 realnych scenariuszy z ostatnich 30 dni:
- 5 typowych dnia codziennego (najczęstsze zamówienie, najczęstsza faktura, standardowe przyjęcie towaru).
- 5 nietypowych, ale realnych (korekta, zwrot, faktura zaliczkowa w walucie obcej, zamówienie do klienta z blokadą kredytową).
- 5 sytuacji brzegowych (klient bez NIP, zamówienie na 200 pozycji, produkt o cenie zerowej, kompletacja z dwóch magazynów).
- 5 „coś poszło nie tak" (padnie internet w trakcie zapisu, dwóch użytkowników edytuje ten sam rekord, w cenniku znalazła się cena ujemna).
Te scenariusze piszą Twoi ludzie, nie dostawca. To jest praca na 1-2 dni dla 2 osób znających procesy — księgowej, magazyniera, handlowca — nie dla informatyka. Informatyk nie wie, co się zdarza w pracy każdego dnia. Oni wiedzą.
Testuj na wolumenie, nie na próbce
Cała klasa błędów pokazuje się dopiero przy realnym rozmiarze bazy. Wyszukiwanie kontrahenta po fragmencie nazwy działa błyskawicznie na 50 rekordach i wisi 15 sekund na 8 000. Generowanie raportu sprzedaży miesięcznej robi się 2 sekundy dla 100 dokumentów i 4 minuty dla 12 000. Import cennika z 500 pozycji przechodzi, z 30 000 rzuca timeout.
Zanim usiądziesz do UAT, zażądaj środowiska testowego z realnymi wolumenami. Nie z próbką, nie z 100 rekordami dla demonstracji. Import produkcyjnej bazy klientów, produktów, stanów magazynowych i historii transakcji z co najmniej 12 miesięcy. Dostawca może narzekać, że to skomplikowane. Dobrze — właśnie dlatego ma to zrobić przed odbiorem, a nie po nim, na Twoich danych produkcyjnych.
Podczas testów uruchom pracę na normalnym obciążeniu: 6-8 osób loguje się jednocześnie i klika swoje typowe zadania przez godzinę. To wychwyci 80% problemów z wydajnością i konkurencyjnym dostępem — a to są problemy, których nie da się rozwiązać jednym klikiem po go-live.
Sprawdź, co się dzieje, gdy coś się psuje
Systemy dobrze wdrożone różnią się od źle wdrożonych nie tym, że nigdy nie mają błędów — tylko tym, jak się zachowują, gdy błąd wystąpi. Świadomie zepsuj coś w środowisku testowym:
- Wyciągnij kabel sieciowy w środku zapisu dokumentu — czy dane wracają, czy nikną?
- Podaj plik CSV w złym kodowaniu — czy system daje sensowny komunikat, czy „unknown error"?
- Utwórz dwa dokumenty z tym samym numerem — czy blokuje, czy tworzy duplikat?
- Wyłącz jeden z systemów integrowanych (np. WMS) — czy ERP czeka, ponawia, czy się zawiesza?
- Wyloguj użytkownika w trakcie edycji — co się dzieje z jego niezapisanymi danymi?
Jeżeli odpowiedzi są niepokojące, to jest moment, żeby żądać poprawek. Po podpisaniu protokołu każdy taki błąd będzie już „nowym zgłoszeniem", rozliczanym godzinowo.
Protokół odbioru z kryteriami, nie z uściskiem dłoni
Ostatnia rzecz, którą MŚP notorycznie robią źle: podpisują protokół odbioru bez wypisanych kryteriów. „System działa zgodnie z umową" to nie jest kryterium — to jest deklaracja wiary.
Napisz przed rozpoczęciem UAT listę konkretnych, mierzalnych kryteriów akceptacji:
- Wystawienie faktury zajmuje mniej niż 5 sekund przy 10 000 kartotek klientów.
- 8 użytkowników jednocześnie może wystawiać dokumenty bez zauważalnego spowolnienia.
- Import cennika z 30 000 pozycji kończy się sukcesem w mniej niż 10 minut.
- Wszystkie 20 scenariuszy zebranych z życia przechodzi bez błędu krytycznego.
- Backup bazy wykonuje się w oknie nocnym i można go odtworzyć w ciągu 2 godzin.
Do protokołu załącz listę tych kryteriów i wynik testu każdego z nich. To zajmuje dodatkowe 2 strony. Chroni Cię przed najgorszym scenariuszem, w którym za pół roku okazuje się, że „przecież to działało na odbiorze".
Warto też podzielić błędy na trzy kategorie: krytyczne (blokują pracę, muszą być naprawione przed odbiorem), średnie (utrudniają pracę, harmonogram poprawek w załączniku do protokołu) i drobne (kosmetyka, do backlogu). Bez tego podziału każda rozmowa o poprawkach kończy się „to nie było krytyczne".
Co dalej
UAT jest nudny. Wymaga oderwania kilku osób od bieżącej pracy na 3-5 dni, wymaga spisywania scenariuszy, wymaga rozmowy z dostawcą o rzeczach, o których dostawca wolałby nie rozmawiać. Ale ten tydzień to najtańsze ubezpieczenie, jakie kupisz w całym projekcie — kilka razy tańsze niż jedna poprawka po go-live.
Jeżeli masz przed sobą odbiór ERP, WMS, CRM albo systemu dedykowanego i nie masz pewności, jak go poukładać, żeby nie odebrać bubla — pogadajmy. Pierwsza rozmowa jest bezpłatna i trwa pół godziny.
Podpisany protokół odbioru to koniec dźwigni negocjacyjnej. Wszystko, co chcesz wymóc na dostawcy, musisz wymóc wcześniej.