Kryteria akceptacji opisują warunki, po których właściciel zakresu rozpozna, że wymaganie zostało zrealizowane. Doprecyzowują granice, reguły i przykłady, zanim zespół rozpocznie implementację. Nie są pełnym zestawem testów ani techniczną instrukcją wykonania.
Dobre kryterium jest obserwowalne i rozstrzygalne: dla określonych danych lub sytuacji istnieje oczekiwany rezultat. Zdanie „funkcja działa poprawnie” tylko powtarza intencję i nie wyjaśnia, co oznacza poprawność.
Dwa użyteczne formaty
Scenariusz Given–When–Then
Format sprawdza się, gdy ważny jest stan początkowy, zdarzenie oraz wynik. Mając klienta z aktywną umową i saldem 120 zł, gdy pracownik rejestruje zwrot 20 zł, wtedy system tworzy dyspozycję na 20 zł i zmniejsza dostępne saldo zwrotów do 100 zł.
Nie trzeba zapisywać angielskich słów. Istotna jest logika: kontekst → działanie → oczekiwany rezultat. Jeden scenariusz powinien opisywać jeden ważny przykład, nie cały proces w kilkunastu krokach.
Lista reguł biznesowych
Gdy kryteria mają charakter statycznych zasad, czytelniejsza jest lista: „Kwota zwrotu jest większa od zera”, „Suma zwrotów nie przekracza kwoty opłaconej”, „Dla płatności kartą zwrot trafia wyłącznie na tę samą kartę”. Dla wielu kombinacji warunków warto użyć tabeli decyzyjnej.
Przypadek: reset hasła
Wymaganie brzmi: „Użytkownik może odzyskać dostęp do konta przez adres e-mail”. Sama ścieżka poprawna nie wystarczy. Trzeba uzgodnić zachowanie dla nieistniejącego adresu, wygaśniętego linku, ponownego użycia, zbyt wielu żądań i konta zablokowanego.
| ID | Kontekst i działanie | Oczekiwany rezultat |
|---|---|---|
| AC-1 | Aktywne konto; użytkownik podaje przypisany e-mail | System wysyła jednorazowy link ważny 30 min i pokazuje neutralne potwierdzenie |
| AC-2 | Nieistniejący e-mail | System pokazuje ten sam neutralny komunikat i nie ujawnia istnienia konta |
| AC-3 | Link wykorzystano wcześniej | System odmawia zmiany i umożliwia złożenie nowego żądania |
| AC-4 | Trzecie żądanie w ciągu 10 min | System nie wysyła kolejnej wiadomości i rejestruje ograniczenie |
| AC-5 | Nowe hasło nie spełnia polityki | System wskazuje niespełnione zasady bez unieważniania ważnego linku |
Takie przykłady ujawniają decyzje produktowe i bezpieczeństwa przed kodowaniem. Tester może później rozwinąć je o szczegóły danych, przeglądarek czy testy penetracyjne, ale podstawowe zachowanie zostało wspólnie zatwierdzone.
Co powinny obejmować kryteria
- podstawowy przypadek prowadzący do wartości dla użytkownika;
- najważniejsze reguły i limity;
- uprawnienia oraz różnice między rolami;
- brakujące lub niepoprawne dane;
- powtórzenie operacji i idempotencję, jeśli ma znaczenie;
- zachowanie przy niedostępności zależności;
- widoczne rezultaty i zmiany stanu;
- istotne wymagania jakościowe powiązane z funkcją.
Nie trzeba mechanicznie dodawać każdego typu do każdej historii. Wybierz te przypadki, które zmieniają zakres, decyzję użytkownika, koszt lub ryzyko. Reszta może trafić do standardów zespołu albo szczegółowych testów.
Kryterium akceptacji a przypadek testowy
| Kryterium akceptacji | Przypadek testowy |
|---|---|
| Uzgadnia biznesową granicę zakresu | Opisuje wykonanie konkretnej weryfikacji |
| Powstaje podczas doprecyzowania wymagania | Może powstać po projekcie i analizie ryzyka |
| Koncentruje się na zachowaniu widocznym dla odbiorcy | Zawiera dane, kroki, środowisko i wynik |
| Nie musi pokrywać wszystkich kombinacji | Buduje pełniejsze pokrycie pozytywne i negatywne |
Najczęstsze błędy
- Powtórzenie wymagania: „użytkownik może zresetować hasło”.
- Techniczna lista zadań: „dodać endpoint, tabelę i kolejkę”.
- Nieostre przymiotniki: „komunikat jest przyjazny, a e-mail przychodzi szybko”.
- Tylko happy path: pominięcie błędów ujawniających najważniejsze decyzje.
- Zbyt wiele scenariuszy w jednym: trudność w ustaleniu, który warunek zawiódł.
- Kryteria dopisane po implementacji: dokumentują istniejące zachowanie zamiast uzgadniać oczekiwane.
Jak wybierać wartości graniczne i przykłady
Kryteria nie powinny zawierać wyłącznie przypadków „środkowych”. Jeśli rabat obowiązuje od 1000 zł, użyj kwot 999,99 zł, 1000 zł i wartości powyżej. Dla limitu czasu sprawdź moment tuż przed i po granicy. Dla uprawnień porównaj role różniące się jednym istotnym prawem.
Dobieraj przykłady według ryzyka: utrata pieniędzy, ujawnienie danych, nieodwracalna zmiana stanu, konflikt równoczesnych operacji i niedostępność zewnętrznej usługi. Nie trzeba zamieniać kryteriów w pełną kombinatorykę. Wystarczy utrwalić przypadki, które rozstrzygają znaczenie wymagania, a szczegółowe pokrycie pozostawić strategii testów.
Kryteria dla zmiany stanu
Przy każdej operacji zmieniającej dane potwierdź stan początkowy, końcowy i skutek częściowego błędu. Jeśli anulowanie zamówienia powiedzie się, ale zwrot płatności nie, system nie może pozostawić sprawy w nieokreślonym stanie. Kryterium powinno wskazać status, możliwość ponowienia, informację dla użytkownika oraz ślad audytowy.
Zwróć też uwagę na powtórzenie żądania. Podwójne kliknięcie, ponowienie po timeoutcie lub dostarczenie tej samej wiadomości przez kolejkę nie powinno tworzyć dwóch wypłat. Jeśli idempotencja ma znaczenie biznesowe, jej rezultat należy uzgodnić, nawet gdy techniczny mechanizm pozostaje decyzją zespołu.
Checklista przed rozpoczęciem prac
- Każde kryterium jest powiązane z konkretnym wymaganiem.
- Stan początkowy i oczekiwany rezultat są jednoznaczne.
- Użyto pojęć zgodnych ze słownikiem domenowym.
- Przykładowe dane obejmują istotne granice.
- Uwzględniono uprawnienia, błędy i ponowienia tam, gdzie zmieniają zachowanie.
- Kryteria nie narzucają implementacji bez uzasadnienia.
- Biznes, wykonawca i tester rozumieją je tak samo.
- Spełnienie można potwierdzić obiektywną obserwacją lub pomiarem.
Po uzgodnieniu kryteriów oznacz ich status i właściciela akceptacji. Zmiana kryterium w trakcie realizacji może oznaczać zmianę zakresu, a nie kosmetyczną korektę testu. Zespół powinien wtedy ocenić wpływ na implementację, inne scenariusze oraz termin. Poprzednią wersję warto zachować w historii wraz z powodem zmiany. Odbiorca powinien potwierdzić nowe rozumienie przed kontynuacją prac.
Kryteria nie naprawią niejasnego celu. Najpierw sprawdź, jak napisać dobre wymaganie, a następnie użyj przeglądu jakości dla całego zestawu.
