Kryteria akceptacji

Kryteria akceptacji to konkretne warunki, które musi spełnić dzieło, aby zostało uznane za ukończone. Towarzyszą one wymaganiu lub historyjce użytkownika, są uzgadniane przed rozpoczęciem prac i stanowią obiektywną podstawę oceny rezultatu. Ich funkcją jest przekształcenie ogólnego opisu intencji w coś, co można zweryfikować, a nie poddać dyskusji.

Ich nieobecność prowadzi do przewidywalnego i kosztownego schematu. Praca jest opisywana w kategoriach ogólnych, budowana zgodnie z interpretacją jednej osoby i recenzowana przez kogoś o innej interpretacji, w którym to momencie spór ujawnia się jako przeróbka w najmniej dogodnym momencie. Sformułowanie kryteriów w pierwszej kolejności doprowadza spór do punktu, w którym jego rozwiązanie wymaga rozmowy, a nie przebudowy.

Dominują dwa formaty. Prosta lista kontrolna określa każdy warunek, który musi zostać spełniony, co odpowiada prostym wymaganiom i jest szybkie w pisaniu. Struktura „dane-kiedy-wtedy”, zaczerpnięta z programowania sterowanego zachowaniami, określa kontekst początkowy, działanie i oczekiwany wynik, co jest zgodne z zachowaniem warunkowym i bezpośrednio przekłada się na testy automatyczne. Żaden z nich nie jest z natury lepszy, a spójność w zespole liczy się bardziej niż wybór.

Najcenniejsze kryteria to te, które obejmują to, co pomija narracja. Szansa jest zazwyczaj oczywista i rzadko kwestionowana; spory dotyczą reguł walidacji, stanów błędów, pustych i ekstremalnych danych, granic uprawnień, tego, co się dzieje w przypadku awarii usługi zewnętrznej oraz tego, jak zachowanie różni się w zależności od urządzenia. Zespoły, które opracowują kryteria tylko dla oczekiwanego przypadku, odkrywają resztę podczas testowania, gdzie zazwyczaj trafia harmonogram.

Kryteria opisują rezultaty, a nie implementację, co pozwala zespołowi na wybór podejścia. Stwierdzenie, że użytkownik musi otrzymać potwierdzenie w określonym czasie, jest kryterium; określenie, która technologia kolejki powinna je wysłać, jest decyzją projektową, która nie powinna znaleźć się w oświadczeniu o akceptacji. Kryteria określające implementację ograniczają osoby, które najlepiej mogłyby podjąć decyzję, i często kodują rozwiązanie, które okazuje się niepotrzebne.

Możliwość śledzenia między kryteriami a testami zapobiega rozbieżnościom między nimi w czasie. Gdy każde kryterium jest powiązane z weryfikacją, automatyczną lub ręczną, pokrycie jest widoczne, a zmiana wymagania powoduje zmianę testu. Gdy testy są utrzymywane oddzielnie, stopniowo zaczynają opisywać to, co system robi, a nie to, co było wymagane, co uniemożliwia im wykrycie regresji w stosunku do zamierzonego celu.

Oczekiwania niefunkcjonalne należą do kryteriów, gdy mają znaczenie, i zazwyczaj są pomijane. Progi wydajności, wymagania dotyczące dostępności, obsługa przeglądarek i urządzeń oraz ograniczenia bezpieczeństwa to warunki akceptacji, a pozostawienie ich w sposób dorozumiany oznacza, że ​​są one uwzględniane niespójnie lub wykryte w późniejszym audycie. Jeśli zespół ma wspólną definicję ukończenia, obejmującą te elementy dla wszystkich prac, poszczególne kryteria powinny jedynie określać odchylenia od niej.

Wspólne ich tworzenie przynosi korzyści, a nie sam dokument. Kryteria opracowane przez jedną osobę i przekazane dalej przekazują specyfikację; kryteria omawiane między osobą, która chce danej funkcjonalności, osobą ją tworzącą i osobą ją testującą, ujawniają niejasności, gdy są jeszcze tanie. Dyskusja często zmienia wymaganie, a o to właśnie chodzi.

Ponieważ kryteria określają, co będzie testowane, łączą one definicję wymagań bezpośrednio z zapewnieniem jakości, zamiast traktować je jako kolejne etapy. W praktyce są one zapisywane w rozwój produktów w ramach udoskonalania, przy czym warunki użyteczności i dostępności są zgodne ze standardami ustalonymi przez Audyt UX pracy, tak aby to, co uznaje się za akceptowalne, odzwierciedlało doświadczenie, jakie produkt ma dostarczyć, a nie tylko jego funkcjonalne zachowanie.