Na jednym z projektów historyjka brzmiała: „System ma obsługiwać płatności”. Tester zapytał, co znaczy „obsługiwać”. Deweloper zrobił płatność kartą. Klient na demie powiedział, że przecież chodziło o BLIK i przelew. Trzy tygodnie pracy, trzy różne wyobrażenia tego samego zdania. Nikt nie skłamał - po prostu zdanie „system ma obsługiwać płatności” jest puste. Nie da się go przejść testem. Nie da się go potwierdzić. To nie jest wymaganie, to życzenie.
Kryteria akceptacji są lekarstwem na tę chorobę. To zestaw warunków, które historyjka musi spełnić, żeby uznać ją za zrobioną - napisanych tak, że tester, deweloper i product owner czytają je i widzą dokładnie to samo. Dobre kryterium akceptacji jest jak zamknięte pytanie tak/nie: albo funkcja je spełnia, albo nie. Żadnego „raczej tak”, żadnego „zależy jak interpretować”. W tym artykule pokażę Ci, jak je pisać - głównie w formacie Given-When-Then - na spójnym przykładzie systemu rezerwacji wizyt fikcyjnej firmy MediFlow.
Czym są kryteria akceptacji i czym nie są
Kryteria akceptacji (ang. acceptance criteria, AC) opisują, kiedy historyjka jest gotowa - z perspektywy zachowania, nie implementacji. Definiują granice: co wchodzi w zakres, a co nie. Są kontraktem między tym, kto zamawia, a tym, kto buduje i testuje.
Czego AC nie są:
- Nie są projektem technicznym. Nie piszesz w nich, że ma być endpoint REST czy tabela w bazie. Piszesz, co użytkownik ma zobaczyć i co się ma stać.
- Nie są listą zadań. „Zrób frontend, zrób backend, napisz testy” to rozbicie pracy, nie kryterium akceptacji.
- Nie są opisem historyjki. Historyjka mówi „kto, co, po co”. AC mówi „po czym poznamy, że to działa”.
Test, który stosuję od lat: jeśli nie potrafię z kryterium akceptacji napisać przypadku testowego, który da się jednoznacznie zaliczyć lub oblać - to nie jest kryterium akceptacji, tylko zdanie o dobrych intencjach.
Given-When-Then - format, który wymusza precyzję
Najpopularniejszy format AC pochodzi z BDD (Behavior-Driven Development) i ma trzy człony:
- Given (zakładając) - kontekst, stan początkowy. Co jest prawdą, zanim cokolwiek się stanie.
- When (kiedy) - akcja, wyzwalacz. Co robi użytkownik lub system.
- Then (wtedy) - oczekiwany rezultat. Co ma być prawdą po akcji.
Możesz dokładać And do każdego członu, żeby nie upychać wszystkiego w jedno zdanie. Siła tego formatu polega na tym, że zmusza Cię do nazwania kontekstu (Given) - a właśnie pominięty kontekst jest źródłem większości nieporozumień.
Przykład: rezerwacja wizyty w MediFlow
Historyjka: „Jako pacjent chcę zarezerwować wizytę w wolnym terminie, aby nie dzwonić do rejestracji”. Słabe AC vs dobre AC:
ŹLE (życzenie, nie kryterium):
- Pacjent może zarezerwować wizytę.
- System pokazuje wolne terminy.
- Rezerwacja działa poprawnie.
DOBRZE (Given-When-Then):
Scenariusz: rezerwacja wolnego terminu
Given pacjent jest zalogowany i wybrał lekarza
And wybrany termin jest co najmniej 24h w przyszłości
When pacjent kliknie ten termin
Then termin zostaje zablokowany na 15 minut
And pacjent widzi formularz finalizacji rezerwacji
Scenariusz: próba rezerwacji terminu zbyt bliskiego
Given pacjent jest zalogowany
When pacjent wybierze termin za mniej niż 24h
Then system pokazuje komunikat "Rezerwacja możliwa min. 24h wcześniej"
And termin nie zostaje zablokowanyZauważ, że dobre AC opisują też ścieżkę negatywną - co się dzieje, gdy warunki nie są spełnione. Słaba wersja milczy o tym, a właśnie tam mieszka połowa bugów.
Dlaczego kontekst (Given) jest najważniejszy
Po latach widzę, że to człon „Given” odróżnia amatorskie AC od profesjonalnych. Większość nieporozumień nie bierze się z błędnej akcji czy złego rezultatu, tylko z niewypowiedzianego założenia o stanie początkowym. „Pacjent rezerwuje wizytę” - ale jaki pacjent? Zalogowany? Z aktywnym ubezpieczeniem? Z historią no-show? Każde z tych założeń zmienia zachowanie systemu, a jeśli nie nazwiesz go w „Given”, każdy domyśli się innego.
Ćwiczenie, które polecam: weź dowolne swoje kryterium i zapytaj „co musi być prawdą, żeby ta akcja w ogóle miała sens?”. Odpowiedzi to Twoje „Given”. Im więcej ich nazwiesz, tym mniej zostanie miejsca na domysły. Paradoksalnie dobre AC bywa dłuższe w sekcji kontekstu niż w sekcji rezultatu - i właśnie dlatego działa.
Inne formaty - kiedy Given-When-Then to za dużo
Given-When-Then jest świetny dla zachowań z wyraźnym wyzwalaczem i rezultatem. Ale nie wszystko jest scenariuszem. Dwa inne formaty, które warto mieć w arsenale:
Lista warunków (rule-based)
Gdy historyjka to zbiór reguł, a nie sekwencja, prostsza lista bywa czytelniejsza:
Historyjka: walidacja formularza rejestracji pacjenta
Kryteria akceptacji:
- Pole PESEL przyjmuje tylko 11 cyfr i przechodzi walidację sumy kontrolnej.
- E-mail musi mieć poprawny format, inaczej formularz się nie wysyła.
- Hasło ma min. 10 znaków, w tym cyfrę i znak specjalny.
- Bez akceptacji zgody RODO przycisk "Załóż konto" jest nieaktywny.Tabela porównawcza formatów
| Format | Kiedy stosować | Mocna strona | Słaba strona |
|---|---|---|---|
| Given-When-Then | Zachowania z akcją i rezultatem | Wymusza kontekst, łatwo zamienić w testy automatyczne | Rozwlekły przy prostych regułach |
| Lista warunków | Zbiory reguł walidacji, ograniczeń | Zwięzły, szybki do czytania | Gubi kontekst i ścieżki negatywne |
| Tabela decyzyjna | Wiele kombinacji warunków → różne wyniki | Pokazuje wszystkie przypadki naraz | Trudniejszy w utrzymaniu przy zmianach |
Moja zasada: domyślnie Given-When-Then, lista warunków dla walidacji, tabela decyzyjna gdy mam więcej niż trzy warunki mnożące się w kombinacje (np. typ pacjenta × rodzaj wizyty × ubezpieczenie → różne ceny).
Cechy dobrego kryterium akceptacji
Niezależnie od formatu, dobre AC ma kilka cech, które warto sprawdzać jak listę kontrolną przed dodaniem historyjki do sprintu:
- Testowalne. Da się jednoznacznie powiedzieć „spełnione / niespełnione”. To pierwsze i najważniejsze sito.
- Jednoznaczne. Dwie różne osoby przeczytają je i zrozumieją tak samo. Słowa typu „szybko”, „intuicyjnie”, „odpowiednio” są zakazane bez liczby.
- Skupione na „co”, nie „jak”. Opisują zachowanie i rezultat, nie technologię ani implementację.
- Niezależne od innych historyjek. Kryterium nie odsyła do trzech innych ticketów, żeby je zrozumieć.
- Kompletne dla danej historyjki. Pokrywają ścieżkę pozytywną, negatywną i istotne wartości brzegowe.
Mam prywatną zasadę „czerwonego ołówka”: czytam AC i podkreślam każde słowo, które da się zinterpretować na dwa sposoby. „System reaguje szybko” - podkreślam „szybko”. „Pacjent dostaje powiadomienie” - podkreślam „powiadomienie” (e-mail? SMS? push?). Każde podkreślenie to pytanie, które zada deweloper albo tester - lepiej, żeby zadał je teraz mnie, niż za tydzień na demie klientowi.
Wartości brzegowe - tam mieszkają bugi
Najwięcej defektów rodzi się na granicach. „Termin musi być co najmniej 24h w przyszłości” - a co dokładnie przy 24h? A przy 23 godzinach i 59 minutach? A przy dokładnie teraz + 24h co do sekundy? Dobre AC nazywa granice wprost:
ŹLE:
- Rezerwacja możliwa z wyprzedzeniem 24h.
DOBRZE (granica nazwana):
- Termin >= teraz + 24h → rezerwacja dozwolona
- Termin < teraz + 24h → rezerwacja zablokowana, komunikat
- Termin = dokładnie teraz + 24h → dozwolona (granica włączna)To wygląda na pedanterię, dopóki nie zobaczysz, jak deweloper i tester kłócą się na demie o to, czy „24h” znaczy „włącznie czy nie”. Trzy linijki precyzji oszczędzają tę kłótnię i buga, który by z niej wynikł.
Częste błędy - i jak je naprawić
- Kryterium nietestowalne. „System działa szybko” - jak szybko? Napraw: „Lista wolnych terminów ładuje się poniżej 2 sekund przy 500 terminach”.
- Mieszanie zachowania z implementacją. „Zapisz rezerwację w tabeli reservations” - to nie sprawa AC. Napraw: „Po finalizacji pacjent widzi rezerwację na liście swoich wizyt”.
- Tylko happy path. Opisujesz, co się dzieje gdy wszystko gra, a milczysz o błędach. Każde AC powinno mieć co najmniej jeden scenariusz negatywny.
- Za szerokie AC. Jedno kryterium opisuje pół systemu. Jeśli scenariusz ma sześć „And” w „Then”, prawdopodobnie to dwie historyjki.
- AC pisane po implementacji. Deweloper coś zrobił, a Ty dopisujesz kryteria pod to, co powstało. To odwrócenie ról - AC mają być umową PRZED pracą.
- Brak wartości brzegowych. „Termin min. 24h” - a dokładnie 24h to za blisko czy w porządku? Zawsze nazwij granicę: „24h lub więcej = OK, mniej niż 24h = blokada”.
Tabela decyzyjna - gdy warunki się mnożą
Są historyjki, w których Given-When-Then puchnie do dziesięciu scenariuszy, bo wynik zależy od kombinacji kilku warunków. Wtedy czytelniejsza jest tabela decyzyjna. Przykład z MediFlow: cena wizyty zależy od typu pacjenta i rodzaju wizyty.
| Typ pacjenta | Rodzaj wizyty | Ubezpieczenie NFZ | Wynik |
|---|---|---|---|
| Pierwszorazowy | Konsultacja | Tak | Bezpłatna, wymaga e-skierowania |
| Pierwszorazowy | Konsultacja | Nie | Pełna cena prywatna |
| Stały | Kontrolna | Tak | Bezpłatna, bez skierowania |
| Stały | Kontrolna | Nie | Cena obniżona (rabat lojalnościowy) |
Każdy wiersz tabeli to jeden testowalny przypadek. Tester dostaje gotową listę kombinacji do sprawdzenia, a Ty masz pewność, że nie zapomniałeś o żadnej. Tabela decyzyjna w trzech minutach pokazuje to, co w Given-When-Then zajęłoby stronę i tak by się rozjechało. Zasada: gdy masz więcej niż trzy warunki mnożące się w kombinacje, sięgaj po tabelę.
Three amigos - najlepsze AC powstają we trzech
Najgorsze kryteria akceptacji pisze analityk sam, w nocy, pod presją. Najlepsze powstają w rozmowie trzech perspektyw - to praktyka zwana three amigos:
- Analityk / product owner - wnosi intencję: po co to robimy, jaka jest wartość.
- Deweloper - wnosi wykonalność: „a co, jeśli baza zwróci pustkę?”, „to się gryzie z modułem płatności”.
- Tester - wnosi przypadki brzegowe: „a co przy dokładnie 24h?”, „a gdy pacjent kliknie dwa razy?”.
Piętnaście minut takiej rozmowy przy doprecyzowaniu historyjki wyłapuje dziury, których jedna głowa nie zobaczy. Tester zada pytanie, którego analityk nie pomyślał. Deweloper wskaże ograniczenie techniczne, które zmienia kryterium. To nie spowalnia - to przyspiesza, bo te pytania i tak padną, tylko bez three amigos padają tydzień później, gdy poprawka kosztuje dziesięć razy więcej.
Mini-case MediFlow: od rozmowy do gotowych AC
Product owner MediFlow mówi na warsztacie: „Pacjent musi móc odwołać wizytę”. Brzmi prosto. Rozbijmy to na pytania, które analityk zadaje, zanim napisze AC:
- Do kiedy można odwołać? (Odpowiedź: do 12h przed wizytą.)
- Co się dzieje z terminem po odwołaniu? (Wraca do puli wolnych.)
- Czy pacjent dostaje potwierdzenie? (Tak, e-mail.)
- Co jeśli odwołuje za późno? (Komunikat: skontaktuj się z rejestracją telefonicznie.)
Cztery pytania zamieniają jedno zdanie w kompletny zestaw AC:
Scenariusz: odwołanie w terminie
Given pacjent ma zarezerwowaną wizytę
And do wizyty pozostało co najmniej 12h
When pacjent kliknie "Odwołaj wizytę"
Then wizyta dostaje status "odwołana"
And termin wraca do puli wolnych terminów
And pacjent dostaje e-mail z potwierdzeniem odwołania
Scenariusz: odwołanie za późno
Given pacjent ma zarezerwowaną wizytę
And do wizyty pozostało mniej niż 12h
When pacjent otworzy szczegóły wizyty
Then przycisk "Odwołaj wizytę" jest nieaktywny
And widoczny jest komunikat z numerem telefonu do rejestracjiTo są kryteria, z których tester napisze przypadki testowe bez jednego dodatkowego pytania, a deweloper wie, gdzie są granice. To cały sens tej roboty - usunąć przestrzeń na domysły.
Kryteria akceptacji a Definition of Done - nie myl ich
To dwa różne narzędzia, które juniorzy często zlewają w jedno. Kryteria akceptacji są specyficzne dla historyjki - opisują, co ta konkretna funkcja ma robić. Definition of Done (DoD) jest wspólne dla całego zespołu - opisuje, co znaczy „skończone” dla każdej historyjki, niezależnie od treści.
| Aspekt | Kryteria akceptacji | Definition of Done |
|---|---|---|
| Zakres | Jedna historyjka | Każda historyjka w zespole |
| Treść | Co ta funkcja ma robić | Standardy jakości (testy, review, dokumentacja) |
| Przykład | „Termin blokuje się na 15 minut” | „Kod zmergowany, testy przechodzą, dokumentacja zaktualizowana” |
| Kto definiuje | Analityk / PO przy historyjce | Cały zespół, raz, dla wszystkich |
Historyjka jest naprawdę gotowa, gdy spełnia jedno i drugie: swoje kryteria akceptacji (robi to, co miała) ORAZ Definition of Done (jest zrobiona porządnie). Pominięcie któregokolwiek to dziura - funkcja, która robi, co trzeba, ale bez testów, albo perfekcyjnie przetestowana funkcja, która robi nie to, o co chodziło. Jak zapisać oba progi, żeby zespół faktycznie z nich korzystał, pokazuję na przykładach w tekście o tym, czym są Definition of Done i Definition of Ready.
FAQ
Ile kryteriów akceptacji powinna mieć jedna historyjka?
Zwykle 3-7 scenariuszy. Jeśli masz więcej niż 8-10, to silny sygnał, że historyjka jest za duża i powinna zostać rozbita. Jeśli masz tylko jedno trywialne kryterium, być może to nie jest osobna historyjka, tylko fragment innej.
Kto pisze kryteria akceptacji - analityk czy product owner?
Najlepiej wspólnie. Product owner zna intencję i priorytet, analityk pilnuje precyzji i testowalności, tester podpowiada przypadki brzegowe. Praktyka „three amigos” (PO + dev + tester) na etapie doprecyzowania historyjki daje najlepsze AC, bo trzy głowy widzą trzy różne dziury.
Czy Given-When-Then trzeba pisać po angielsku?
Nie. Słowa najważniejsze pochodzą z angielskiego (bo z narzędzi BDD), ale treść scenariuszy pisz w języku, którym mówi zespół. Polskie „Zakładając / Kiedy / Wtedy” jest równie poprawne. Ważna jest struktura, nie język.
Czy kryteria akceptacji to to samo co przypadki testowe?
Nie, choć są blisko spokrewnione. AC mówią „po czym poznamy, że historyjka jest gotowa” i są umową przed pracą. Przypadki testowe to konkretne kroki testera plus dane wejściowe i oczekiwany wynik - często powstają WPROST z kryteriów akceptacji. Dobre AC sprawiają, że pisanie testów jest mechaniczne.
Podsumowanie i następny krok
Kryteria akceptacji to najtańsze ubezpieczenie projektu, jakie znam. Kilka zdań w formacie Given-When-Then przed startem pracy oszczędza dni nieporozumień i poprawek po demie. Klucz to testowalność: każde kryterium ma dać się jednoznacznie zaliczyć lub oblać, każde ma swoją ścieżkę negatywną, żadne nie wchodzi w implementację.
Kryteria akceptacji nie istnieją w próżni - żyją wewnątrz historyjek użytkownika i lądują w narzędziach zespołu. Jeśli jeszcze nie czujesz pewnie samych historyjek, zacznij od poradnika o pisaniu User Stories, a potem zobacz, jak osadzić kryteria akceptacji w Jirze i jak przekuć je w testy akceptacyjne UAT. A najlepiej po prostu przećwicz - w darmowym teście wiedzy BA sprawdzisz, czy odróżniasz dobre kryterium od życzenia.