← Wróć do notatek

Czego rozwiązanie 112 zgłoszeń UAT od klienta nauczyło mnie o traktowaniu akceptacji jako pętli feedbacku projektowego, a nie jedynie bramki release'owej.

Udostępnij mailem
Pliki do pobrania 00
Brak załączonych plików Ten artykuł nie zawiera dodatkowych materiałów. 0
Odczyt głosowy nie jest obsługiwany przez tę przeglądarkę lub urządzenie.

Popularny model delivery traktuje UAT jak ostatni checkbox przed releasem: implementacja się kończy, użytkownicy ją weryfikują, błędy są poprawiane i software idzie na produkcję.

Dla systemów operacyjnych ten model jest zbyt płytki.

W platformie produkcyjnej UAT jest często pierwszym momentem, gdy technicznie spójny workflow zderza się z realną sekwencją decyzji podejmowanych na hali. Przydatne pytanie brzmi nie tylko „czy to działa?”, ale „czy system koduje operację tak, jak ludzie faktycznie ją wykonują?”

112 zgłoszeń nie oznaczało 112 bugów

W jednym projekcie MES/APS rozwiązałem 112 zgłoszeń UAT klienta, w tym 17 oznaczonych jako krytyczne. Część była prostymi defektami. Inne ujawniły rozjazdy w założeniach, granicach ról, przejściach stanów, widoczności lub kolejności, w jakiej informacja staje się dostępna.

Traktowanie każdego zgłoszenia jako osobnego ticketu naprawiłoby objawy, zachowując błędny model.

Zamiast tego każde znalezisko jest bardziej użyteczne, gdy zostanie sklasyfikowane do jednej z czterech grup:

  1. defekt implementacji;
  2. brakująca reguła domenowa;
  3. rozjazd workflow;
  4. niejednoznaczność kryterium akceptacji.

To rozróżnienie zmienia poprawkę. Defekt dostaje patch. Luka w regule domenowej może wymagać zmiany modelu. Rozjazd workflow może unieważnić kilka ekranów naraz. Niejasne kryterium akceptacji powinno zostać zamienione w testowalne stwierdzenie, zanim powstanie kolejny kod.

Akceptacja powinna zostawiać dowody

Dla przepływów krytycznych biznesowo „przetestowane” jest słabą dokumentacją. Preferuję macierz akceptacji łączącą scenariusz z warunkami wstępnymi, aktorem, krokami, oczekiwanym stanem i dowodem.

Robi to dwie rzeczy jednocześnie: daje klientowi precyzyjną powierzchnię do sporu i zamienia finalny handover w coś powtarzalnego.

Zasada praktyczna

Używaj UAT jako review modelu domenowego wykonywanego na działającym oprogramowaniu.

Gdy przychodzi zgłoszenie, pytaj, czy wskazuje lokalny problem implementacyjny, czy błędne założenie wcześniej w łańcuchu. W tej drugiej kategorii chowają się drogie błędy i właśnie tam UAT daje najwięcej wartości.

0%