Czym są kryteria akceptacji
Kryteria akceptacji (AC) opisują warunki, które musi spełnić ukończona zmiana. Pomagają osobie zamawiającej, developerowi i testerowi uzgodnić oczekiwany wynik. Nie są instrukcją implementacji. „Użyj hooka React” może być ograniczeniem technicznym, ale nie mówi, czy użytkownik może wykonać zadanie.
Dobre kryterium określa obserwowalne zachowanie, kontekst i sprawdzalny rezultat. „Eksport ma być szybki” jest nieprecyzyjne. Zespół musi najpierw uzgodnić cel i sposób pomiaru.
Opis ticketu określa problem i zakres. AC określają warunki przyjęcia wyniku. Definition of Done dotyczy wspólnych standardów zespołu, np. review i testów; nie zastępuje AC dla konkretnego zadania. Mała zmiana może potrzebować jednego lub dwóch kryteriów, a proces z rolami i błędami — więcej. Liczą się tylko warunki, które pomagają ocenić wykonanie pracy.
Wymaganie to nie założenie
„Dodaj eksport klientów” nie określa CSV, uprawnień administratora, limitu 10 000 wierszy ani nazwy clients.csv. To brakujące decyzje. Znane wymaganie zostało zapisane i uzgodnione. Założenie jest niepotwierdzoną propozycją odpowiedzi. Rekomendacja wskazuje opcję i uzasadnienie; nadal wymaga decyzji, zanim stanie się AC.
Nie zamieniaj samodzielnie słowa „szybko” na „poniżej dwóch sekund”. Zapytaj o cel i warunki pomiaru. Jeśli wymaganie brzmi „Eksport maksymalnie 10 000 rekordów kończy się w ciągu 10 sekund”, możesz z niego napisać mierzalne kryterium.
Funkcja: eksport raportu
Słabo: „Użytkownicy mogą łatwo eksportować wszystkie dane”. Nie wiadomo, kto ma uprawnienie, czy działają filtry, jaki jest format i co się dzieje przy pustym wyniku.
Lepiej, po potwierdzeniu decyzji:
- Osoba z uprawnieniem do raportów pobiera CSV ze wszystkimi wierszami zgodnymi z bieżącymi filtrami, także spoza widocznej strony.
- CSV zawiera uzgodnione kolumny w uzgodnionej kolejności i jest kodowany w UTF-8.
- Gdy nie ma pasujących wierszy, plik zawiera nagłówki bez wierszy danych.
Nie dopisuj drugiego ani trzeciego warunku do prawdziwego ticketu bez uzgodnienia. Najpierw zapytaj właściciela zadania, czy właśnie tego oczekuje.
Błąd: sporadyczny problem z logowaniem
Słabo: „Logowanie znowu działa”. Tester nie wie, jaki przypadek został naprawiony.
Lepiej: „Mając aktywne konto z włączonym uwierzytelnianiem dwuskładnikowym, gdy użytkownik po resecie hasła wpisze poprawny kod, sesja zostaje otwarta i zgłoszony błąd nie występuje”. Ten warunek ma sens tylko wtedy, gdy pierwotny błąd da się odtworzyć w takich okolicznościach. Kroki i środowisko zapisz w tickecie.
Zadanie techniczne: aktualizacja API
Słabo: „Zaktualizować API billingowe do v2 i niczego nie zepsuć”. „Niczego” nie da się zweryfikować.
Lepiej:
- Klient billingowy korzysta z endpointu v2 w docelowym środowisku.
- Dotychczasowy eksport faktur nadal zwraca uzgodnione pola i kody odpowiedzi.
- Testy integracyjne objętych zmianą procesów przechodzą w środowisku testowym v2.
Wersja i środowisko wyznaczają zakres. Dwa kolejne punkty dają dowód, że zmiana działa.
Kiedy stosować Given / When / Then
Ten zapis pomaga, gdy kolejność akcji i reakcji systemu ma znaczenie albo warunki zmieniają wynik. Dobrze porządkuje proces logowania. Przy prostej zmianie tekstu, np. „Przycisk zamówienia ma etykietę «Złóż zamówienie»”, dodaje tylko formalizm. Nie każde kryterium musi być Gherkinem.
Przy aktualizacji PHP 8.2 do 8.4 lepiej wskazać obsługiwany runtime, dotknięte integracje i konieczne sprawdzenia. Sztuczne „Mając PHP...” nie poprawia testu.
Przed pisaniem AC sprawdź, czy ticket ma jasny cel, zakres i decyzje. Narzędzie do analizy gotowości zadania pomoże zebrać otwarte pytania. Wynik jest szkicem do rozmowy, a nie samodzielną akceptacją. Użyj checklisty gotowości zadania i zobacz różnicę między DoR a AC.