Wyjaśnienie kryteriów akceptacji Dane-Kiedy-Wtedy
Format: Kryteria Dane-Kiedy-Wtedy definiują jasne, testowalne działanie oprogramowania, zapewniając wspólne rozumienie wśród członków zespołu.
Struktura: Każdy scenariusz w tym formacie obejmuje kontekst, działanie użytkownika i oczekiwany rezultat, opisane prostym językiem.
Najlepsze praktyki: Skupienie się na prostocie, współpracy i szczegółach poprawia jasność kryteriów akceptacji.
Najczęstsze błędy: Należy unikać łączenia scenariuszy, opisywania szczegółów technicznych i pomijania przypadków brzegowych.
Kryteria akceptacji w formacie założenie–kiedy–wtedy (GWT) zapewniają prosty i możliwy do przetestowania sposób opisania oczekiwanego zachowania oprogramowania, dzięki czemu deweloperzy, testerzy i interesariusze mają wspólne rozumienie wymagań. Gdy kryteria akceptacji są nieprecyzyjne, zespoły tracą czas na dyskusje o wymaganiach, tworzenie niewłaściwego rozwiązania i wykrywanie luk na późnym etapie prac.
W tym poradniku omówię format założenie–kiedy–wtedy, pokażę rzeczywiste przykłady z typowych scenariuszy, porównam go z innymi podejściami do kryteriów akceptacji oraz przedstawię praktyki, które pomagają zespołom zwinnym tworzyć jaśniejsze i skuteczniejsze historyjki użytkownika.
Czym są kryteria akceptacji w formacie założenie–kiedy–wtedy?
Założenie–kiedy–wtedy to trójczłonowy szablon służący do zapisywania kryteriów akceptacji historyjki użytkownika. Każdy scenariusz opisuje jeden fragment oczekiwanego zachowania prostym językiem, który mogą zrozumieć deweloperzy, testerzy i interesariusze.
Continue Reading for Free
Create a free account to finish this article, plus get ongoing access to timely insights and practical resources.
Have an account? Log In
Oto jak działa ta struktura:
- Założenie określa, co musi już być prawdą, zanim użytkownik końcowy wykona jakiekolwiek działanie.
- Kiedy wprowadza działanie. Chodzi o to, co robi użytkownik, lub o zdarzenie wywołane przez system.
- Wtedy ujawnia rezultat. Jest to wynik, który potwierdza, że system zareagował prawidłowo.
Jak pisać kryteria akceptacji w formacie założenie–kiedy–wtedy
Jak formułować każdą część, aby sprawdzała się podczas tworzenia i testowania oprogramowania.
Założenie: określanie kontekstu i warunków wstępnych
Część dotycząca założenia opisuje to, co musi już być prawdą. Obejmuje to stan systemu, rolę użytkownika, warunki dotyczące danych oraz konfigurację środowiska. Dobre stwierdzenia dotyczące założenia są konkretne. Unikaj zapisu „Zakładając, że użytkownik jest zalogowany”, gdy scenariusz zależy od roli. Zamiast tego napisz: „Zakładając, że zarejestrowany klient z ważną subskrypcją znajduje się na stronie ustawień konta”.
Oto kilka wskazówek dotyczących pisania części dotyczącej założenia:
- Podaj rolę użytkownika lub personę, gdy ma to znaczenie.
- Określ warunki systemowe, takie jak przełączniki funkcji, stany danych lub łączność.
- Łącz wiele warunków wstępnych za pomocą słowa „Oraz”, zamiast upychać je w jednym zdaniu.
Kiedy: definiowanie działania lub wyzwalacza
Część dotycząca „kiedy” opisuje działanie lub zdarzenie, które uruchamia testowane zachowanie. Powinna opisywać jedną interakcję użytkownika lub jedno zdarzenie systemowe, a nie sekwencję działań. Używaj strony czynnej. Napisz „Kiedy klient klika przycisk «Zastosuj kupon»”, zamiast „Kiedy przycisk kuponu zostanie kliknięty”. Eliminuje to niejasność dotyczącą osoby wykonującej działanie.
Ta część powinna być zwięzła. Jeśli potrzebujesz więcej niż jednego stwierdzenia „kiedy”, prawdopodobnie opisujesz dwa odrębne scenariusze. Rozdziel je.
Wtedy: określanie oczekiwanego rezultatu
Część dotycząca „wtedy” określa, co użytkownik powinien zaobserwować lub co system powinien zrobić po wykonaniu działania. Opisuj obserwowalne rezultaty. „Wtedy pulpit się ładuje” to słaby zapis. „Wtedy system wyświetla pulpit klienta w ciągu dwóch sekund” można przetestować. Uwzględnij szczegóły, takie jak komunikaty o błędach, miejsca przekierowania, zmiany danych, wyzwalanie wiadomości e-mail lub zmiany stanu interfejsu użytkownika.
Użyj słowa Oraz, aby połączyć wiele rezultatów, gdy jedno działanie prowadzi do więcej niż jednego obserwowalnego wyniku. Na przykład: „Wtedy wyświetla się strona potwierdzenia zamówienia” Oraz „klient otrzymuje wiadomość e-mail z potwierdzeniem w ciągu 60 sekund”.
Przykłady formatu założenie–kiedy–wtedy
Oto przykłady kryteriów akceptacji w formacie założenie–kiedy–wtedy z różnych dziedzin.
Logowanie użytkownika
Scenariusz 1: pomyślne logowanie przy użyciu prawidłowych danych uwierzytelniających
Zakładając, że zarejestrowany użytkownik znajduje się na stronie logowania, kiedy użytkownik wpisze prawidłowy adres e-mail i poprawne hasło oraz kliknie przycisk „Zaloguj się”, wtedy system przekieruje użytkownika do pulpitu jego konta
Część dotycząca założenia jest tutaj celowo ograniczona do minimum, ponieważ scenariusz nie zależy od poziomu subskrypcji ani stanu konta. Zwróć uwagę na złożoną część dotyczącą „kiedy”: wprowadzenie danych uwierzytelniających i kliknięcie przycisku to jedno logiczne działanie (przesłanie formularza logowania), dlatego pozostawiam je razem, zamiast dzielić na osobne scenariusze dla każdego naciśnięcia klawisza.
Scenariusz 2: nieudane logowanie przy użyciu nieprawidłowych danych uwierzytelniających
Zakładając, że zarejestrowany użytkownik znajduje się na stronie logowania, kiedy użytkownik wprowadzi prawidłowy adres e-mail i nieprawidłowe hasło oraz kliknie „Zaloguj się”, wtedy system wyświetli komunikat „Nieprawidłowy adres e-mail lub hasło”, oraz użytkownik pozostanie na stronie logowania
Klauzula „Wtedy” określa dokładną treść komunikatu o błędzie. Druga klauzula „Oraz” ma znaczenie, ponieważ potwierdza, że użytkownik nie zostanie przypadkowo przekierowany w inne miejsce.
Koszyk i finalizacja zakupu
Scenariusz 1: Dodawanie produktu do koszyka
Zakładając, że klient przegląda stronę szczegółów produktu dostępnego w magazynie, kiedy klient kliknie „Dodaj do koszyka”, wtedy ikona koszyka zostanie zaktualizowana i pokaże jeden produkt, oraz pojawi się komunikat potwierdzający „Produkt dodano do koszyka”
Klauzula „Zakładając” zawiera informację „dostępny w magazynie”, ponieważ zachowanie różni się w przypadku produktów niedostępnych, a to jest osobny scenariusz.
Scenariusz 2: Zastosowanie prawidłowego kodu rabatowego
Zakładając, że klient ma w koszyku dwa produkty o łącznej wartości $80.00, kiedy klient wprowadzi kod rabatowy „SAVE20” i kliknie „Zastosuj”, wtedy system zastosuje rabat w wysokości 20%, oraz suma koszyka zostanie zaktualizowana do kwoty $64.00
Podanie konkretnych kwot uniemożliwia błędną interpretację. Taki scenariusz rabatowy może pomóc wykryć błąd zaokrąglania na środowisku produkcyjnym, w którym rabat procentowy od nieparzystej kwoty skutkował ceną z trzema miejscami po przecinku. Precyzja w klauzuli „Zakładając” ($80.00) i klauzuli „Wtedy” ($64.00) sprawia, że scenariusz jest wartościowy.
Odzyskiwanie hasła
Scenariusz 1: Żądanie zresetowania hasła przy użyciu zarejestrowanego adresu e-mail
Zakładając, że użytkownik znajduje się na stronie logowania, kiedy użytkownik kliknie „Nie pamiętasz hasła?”, wprowadzi zarejestrowany adres e-mail i kliknie „Wyślij”, wtedy system wyświetli komunikat „Link do resetowania hasła został wysłany na Twój adres e-mail”, oraz system wyśle wiadomość e-mail umożliwiającą zresetowanie hasła w ciągu 60 sekund
Złożona klauzula „Kiedy” przedstawia jeden logiczny przebieg: żądanie zresetowania hasła. Ograniczenie czasowe wynoszące 60 sekund w klauzuli „Wtedy” ma kluczowe znaczenie. Bez niego wiadomość e-mail umożliwiająca zresetowanie hasła, która dotrze 20 minut później, technicznie „przechodziłaby” test. Rezultaty ograniczone czasowo należą do najczęściej pomijanych szczegółów.
Scenariusz 2: Użycie wygasłego linku do resetowania hasła
Zakładając, że użytkownik otrzymał wiadomość e-mail umożliwiającą zresetowanie hasła ponad 24 godziny temu, kiedy użytkownik kliknie link do resetowania hasła zawarty w wiadomości e-mail, wtedy system wyświetli komunikat „Ten link wygasł. Poproś o nowy.”
Klauzula „Zakładając” zawiera warunek czasowy, który wymusza omówienie tego, jaki powinien być okres ważności linku.
Walidacja formularza
Scenariusz 1: Przesyłanie formularza z niewypełnionymi wymaganymi polami
Zakładając, że użytkownik znajduje się w formularzu rejestracji, kiedy użytkownik pozostawi puste pole „E-mail” i kliknie „Wyślij”, wtedy system wyświetli bezpośrednio w formularzu komunikat o błędzie „E-mail jest wymagany” poniżej pola E-mail, oraz formularz nie zostanie przesłany
Klauzula „Wtedy” określa miejsce wyświetlenia błędu („poniżej pola E-mail”), a nie tylko fakt jego wyświetlenia.
Scenariusz 2: Przekroczenie limitu znaków w polu tekstowym
Zakładając, że użytkownik wypełnia pole „Biogram” z limitem 500 znaków, kiedy użytkownik wprowadzi 501 znaków, wtedy system uniemożliwi dalsze wprowadzanie danych, oraz zostanie wyświetlony komunikat „Dozwolonych jest maksymalnie 500 znaków”
GWT a listy kontrolne i przypadki użycia
Oto kilka innych typów kryteriów akceptacji oraz sytuacje, w których można zastosować każdy z nich:
| Aspekt | Dane-Kiedy-Wtedy | Lista kontrolna oparta na regułach | Przypadek użycia |
|---|---|---|---|
| Struktura | Dane, Kiedy, Wtedy | Lista punktowana reguł | Ponumerowane kroki z przepływami |
| Najlepsze zastosowanie | Scenariusze behawioralne, BDD | Reguły biznesowe, specyfikacje interfejsu użytkownika | Złożone funkcje z wieloma przepływami |
| Mocne strony | Możliwość testowania i automatyzacji, bogaty kontekst | Szybkie w tworzeniu, łatwe do przeglądania | Kompleksowe, obejmują przypadki brzegowe |
| Ograniczenia | Zbyt rozwlekłe w przypadku prostych zmian | Brak przepływu scenariusza, trudne do automatyzacji | Ciężkie, powolne w utrzymaniu |
| Odbiorcy | Zespół programistyczny, QA, produkt | Produkt, projekt, interesariusze | Zespoły zewnętrzne, zgodność z przepisami |
| Zakres | Pojedyncze zachowanie | Cała funkcja | Cała funkcja |
| Poziom szczegółowości | Trzy klauzule | Elastyczny | Warunki wstępne, warunki końcowe, wyzwalacze i ponumerowane kroki |
Uważam, że przypadki użycia sprawdzają się najlepiej, gdy trzeba udokumentować system na potrzeby zgodności z przepisami lub przekazać go zewnętrznemu dostawcy. W codziennej pracy sprintowej format dane-kiedy-wtedy jest bardziej zwięzły i szybszy.
Najlepsze praktyki formatu Dane-Kiedy-Wtedy
Oto kilka najlepszych praktyk, które pomogą skutecznie korzystać z GWT:
- Unikaj niejasnego lub wieloznacznego języka: Zamiast „Następnie strona ładuje się szybko”, napisz „Następnie strona wyników wyszukiwania ładuje się w ciągu dwóch sekund”. Zastępuj przymiotniki takie jak „odpowiedni” lub „istotny” wartościami mierzalnymi. Jeśli nie możesz tego przetestować, przeredaguj zapis.
- Utrzymuj scenariusze proste i skoncentrowane: Stosuj zasadę jednego zachowania na scenariusz. Każdy scenariusz powinien testować dokładnie jedną rzecz. Gdy łączysz wiele działań lub rezultatów, tworzysz przypadki testowe trudne do debugowania i utrzymania. Jeśli scenariusz zawiera więcej niż dwie instrukcje „i” w sekcji „wtedy”, zadaj sobie pytanie, czy testujesz jedno zachowanie, czy dwa.
- Organizuj sesję trzech amigos: Sesja trzech amigos to krótka, skoncentrowana rozmowa, podczas której osoba odpowiedzialna za produkt (właściciel produktu lub analityk biznesowy), programista i tester wspólnie przeglądają nadchodzące historyjki przed rozpoczęciem sprintu. Wspólnie zapisują lub dopracowują kryteria GWT, co zapobiega konieczności ponownej pracy.
- Zachowuj spójność terminologii i stylu: Wybierz standardowe terminy i stosuj je w każdej historyjce. Jeśli w jednym scenariuszu używasz słowa „klient”, a w innym „użytkownik”, wprowadzasz niejasność. W razie potrzeby utwórz mały słownik. Stosuj tę samą strukturę zdań w klauzulach.
Pięć typowych antywzorców
Oto kilka typowych błędów, których należy unikać podczas pisania kryteriów akceptacji w formacie dane-kiedy-wtedy:
- Opisywanie szczegółów implementacji zamiast zachowania: Scenariusze takie jak „Jeśli wywołanie API zwraca kod statusu 200” opisują implementację techniczną, a nie zachowanie użytkownika. Przepisz je z perspektywy użytkownika: „Jeśli katalog produktów został załadowany na stronie głównej”. Szczegóły techniczne pozostaw w kodzie automatyzacji testów.
- Upychanie wielu scenariuszy w jednym: Scenariusz, który testuje logowanie, nawigację i realizację zakupu w jednym bloku, jest testem integracyjnym, a nie kryterium akceptacji. Podziel każde zachowanie na osobny scenariusz. Uzyskasz dzięki temu bardziej przejrzyste wyniki i łatwiejsze debugowanie.
- Pominięcie scenariuszy negatywnych i przypadków brzegowych: Zespoły tworzące oprogramowanie w metodyce Agile często opisują ścieżkę pozytywną i zapominają o tym, co dzieje się, gdy coś pójdzie nie tak. Przy każdym udanym scenariuszu zadaj pytanie: co się stanie, jeśli dane wejściowe będą nieprawidłowe? Co się stanie, jeśli połączenie sieciowe zostanie przerwane? Co się stanie, jeśli zabraknie danych? Napisz co najmniej jeden scenariusz negatywny dla każdej historyjki, aby wykryć problemy, zanim trafią do środowiska produkcyjnego.
- Traktowanie GWT jako jedynego akceptowalnego formatu: Używaj GWT do opisywania zachowania, a list kontrolnych do wszystkiego innego. Jeśli będziesz zmuszać każdą historyjkę do formatu given-when-then, w tym zmiany koloru przycisków, aktualizacje treści i konfigurację infrastruktury, otrzymasz absurdalne rezultaty (np. „Jeśli strona główna istnieje, Kiedy użytkownik ją wyświetli, Wtedy czcionka nagłówka ma 16 px”).
- Tworzenie scenariuszy w izolacji: Nie twórz kryteriów GWT samodzielnie. Wartość tego formatu wynika z rozmowy, którą wywołuje. Jeśli przed rozpoczęciem tworzenia oprogramowania Twoje scenariusze nie są omawiane przez przedstawicieli co najmniej dwóch dziedzin, używasz GWT jako formatu dokumentacji, podczas gdy jego prawdziwa siła polega na wspieraniu współpracy.
Co dalej?
Jasne kryteria akceptacji w formacie given-when-then to tylko jedna z części realizacji udanych projektów. Rozwiń tę podstawę dzięki bezpłatnemu członkostwu DPM i uzyskaj dostęp do praktycznych szablonów, materiałów eksperckich oraz sprawdzonych struktur, które pomagają przekształcać dobrze zdefiniowane wymagania w sprawniejszą realizację i lepsze rezultaty.
