---
title: "UAT nie jest końcem developmentu"
description: "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."
publishedAt: "2026-08-08"
draft: false
featured: false
category: "Delivery"
readingMinutes: 6
tags: ["UAT", "produkcja", "jakość", "MES"]
---

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.