Kryteria akceptacji dla przypadków krawędziowych

Jestem właścicielem produktu w zwinnym zespole. Kiedy robię testy akceptacji PO, zwykle robię notatki, aby wypróbować niektóre przypadki krawędzi. Często zdarza się, że coś odkrywam, a potem oddaję to twórcom. Dostaję odpowiedź od jednego z programistów, gdy odrzucam jego historie. Mówi, że to niesprawiedliwe, ponieważ nie określam przypadków skrajnych i tego, jak program powinien reagować w kryteriach akceptacji, ponieważ zwykle koduje tylko to, co opisuję w tej historii. Zachęciłem go, by zapytał mnie, gdy wpada na jakieś przypadkowe przypadki podczas kodowania, ale uważa, że ​​nie jego zadaniem jest zastanawianie się nad przypadkowymi przypadkami, jego kopalnią i powinienem napisać nowe historie na następny sprint.

W mojej obronie nie znam jego projektu do czasu, gdy go zaimplementuje, więc trudno jest iterować przez wszystkie możliwości (czy konfiguracja będzie w pliku DB lub właściwości?). Dla uproszczenia załóżmy, że mamy historię dodawania podziału do aplikacji kalkulatora. Czy w idealnym świecie SCRUM obowiązkiem byłoby dodać do kryteriów akceptacji „scenariusz dzielenia przez zero”, czy powinien on pracować nad tymi przypadkami, gdy się rozwija, aby aplikacja nie implodowała na 5/0? Żeby było jasne, w tym przypadku nie zaakceptowałbym, gdyby aplikacja mocno się zawiesiła na 5/0, ale przekazałbym, jeśli loguje się, drukuje DIV0 lub w jakikolwiek inny sposób poradzić sobie z błędem ... tak długo jak nie rozbić się.

Myślę, że odpowiedź brzmi: oboje powinniście myśleć o swoim własnym zestawie przypadków. Jako, że deweloper powinien obsługiwać przypadki brzegowe, które są specyficzne dla danych, takie jak awaria aplikacji z dowolnego wejścia użytkownika, 5/0 z pewnością należy do tej części spektrum. Twórca powinien zapytać o ciebie, co Twoim zdaniem byłby odpowiednim komunikatem o błędzie, gdy dane wejściowe podane w ramach interakcji użytkownika prowadzą do czegoś nieprawidłowego.

Twoja część spektrum to biznesowa strona rzeczy. Jak powinien zachowywać się kalkulator, jeśli konto użytkownika nie może używać przycisku podziału? Jak powinno się to zachowywać, gdy konto może korzystać z operacji Mod, ale nie ma dostępu do funkcji podziału?

Ważną wiadomością, którą moim zdaniem należy przekazać i uzyskać akceptację wszystkich członków zespołu, jest to, że wszyscy jesteście w tym samym zespole. Jeśli produkt nie jest kompletny, produkt nie jest kompletny, a zespół ponosi winę, a nie dany członek.

Zespół musi współpracować, a nie mieć postawę / mantrę typu „Nie moja praca, nie moja odpowiedzialność”.

Kryteria akceptacji mają postać:

• Akceptacja biznesowa
• Akceptacja zapewnienia jakości

Zazwyczaj akceptacja firmy zazwyczaj odpowiada na pytanie:

• Czy zaimplementowana funkcja działa tak, jak chcę?

Ta funkcja będzie miała szereg wymagań, które są zorientowane na biznes, na przykład jeśli kliknę ten przycisk, spodziewam się, że to nastąpi. Wymienione zostaną spodziewane scenariusze biznesowe i oczekiwane zachowanie, ale nie obejmie wszystkich możliwych przypadków.

Oczekuje się, że wymagania biznesowe powinny być zdefiniowane przed iteracją, aby w ramach zapewniania jakości można było opracować wszelkie wymagania techniczne dotyczące wymagań innych niż biznesowe. W ramach zapewniania jakości należy opracowywać przypadki niszczące, a także w razie potrzeby przypadki skrajne.

Oba zestawy wymagań powinny zostać przejrzane przed rozpoczęciem pracy nad historią, aby możliwe było formalne oszacowanie i zaangażowanie jednostki pracy. Po wykonaniu tej czynności można opracować funkcję / historie. W tym momencie wszyscy mają jasność co do tego, co ma zostać dostarczone zarówno z biznesowego, jak i technicznego punktu widzenia.

Fabuła osiąga ostateczną akceptację, gdy członkowie zespołu ds. Biznesu i zapewnienia jakości podpiszą ją. Powinno to nastąpić podczas iteracji zarówno akceptacji biznesowej, jak i akceptacji zapewnienia jakości. Jest to definicja gotowej (DoD), która sygnalizuje, że można rozpocząć dodatkowe prace nad historią.

Wszelkie nowe ustalenia mogą być rejestrowane jako wady lub dodatkowe skoki historii. W idealnym świecie nigdy by się to nie zdarzyło, ale w rzeczywistości zwykle występuje pewne „odkrycie”, które ma miejsce podczas pracy nad fabułą / historią. To jest naturalne.

Zespół powinien współpracować (biznes, QA, deweloper) do mieszania z każdym chaotyczny typu odkrycie wymagań. Jeśli jest to sprawne, wszyscy powinni siedzieć przy tym samym stole, aby wspierać komunikację i szybkie rozwiązywanie wszelkich pojawiających się pytań. Powinien wyglądać mniej więcej tak:

QA:

„Hej, Deweloperu, powinniśmy poradzić sobie z tym konkretnym scenariuszem. Odkryłem, że jeśli wprowadzę te dane, otrzymam błąd”

DEV:

„Nie zostało to uwzględnione w żadnym wymaganiu, ale możemy dodać dodatkową funkcjonalność, aby to pokryć. OK, hej przedsiębiorco, jak chciałbyś, aby aplikacja zachowywała się w tym przypadku?”

BIZNES:

„Pokażmy nasz standardowy komunikat o błędzie i pozwól użytkownikowi spróbować ponownie w tym scenariuszu. Ile to będzie dodatkowego wysiłku?”

DEV:

„Będzie to łatwe, tylko dodatkowa godzina lub dwie. Mogę zobowiązać się do tej iteracji. Kontrola jakości proszę zaktualizować kryteria akceptacji dla tego scenariusza, nie potrzebujemy dodatkowej historii. Dzięki!”

Lub jeśli jest to dużo pracy, nowa historia jest dodawana do zaległości. Zespół nadal może zaakceptować oryginalną historię, ponieważ spełnia ona wszystkie pierwotne wymagania, a następnie podnieść historię szczytów w następnej iteracji.

Pisanie oprogramowania, które zachowuje się w solidny sposób w obliczu niepoprawnych lub niejednoznacznych danych wejściowych, jest istotną częścią pracy programisty.

Jeśli programiści nie widzą tego w ten sposób, dołącz dodatkowe wymagania niefunkcjonalne do specyfikacji wymagań, które wyraźnie określają to wymaganie, i przekaż programistom przykład procesu testowania, aby mogli sami zastosować ten proces przed przesłaniem ostatecznej wersji kod do recenzji.

Testy akceptacyjne powinny być istotną częścią każdego dokumentu wymagań. Jeśli wymaganie nie określa również kryteriów akceptacji, tak naprawdę nie jest to wymaganie; to życzenie.

Stało się tutaj, że odkryłeś wartość . Wartość wejściowa nie była brana pod uwagę przy pisaniu historii (i kryteriach akceptacji) ani przy pisaniu kodu. Jeśli nie jest to część kryteriów akceptacji, tak naprawdę nie masz podstaw do odrzucenia historii.

To, co moglibyśmy zrobić w moim zespole, to:

1. Utwórz błąd opisujący oczekiwane i rzeczywiste zachowanie.
2. Zaktualizuj kryteria akceptacji, aby udokumentować nowe znalezione wymaganie.
3. Priorytetem błędu wraz z wszystkimi innymi historiami i błędami w następnej iteracji.

Korzyścią tutaj jest to, że musisz rozważyć, czy naprawienie tego błędu jest kolejną najważniejszą rzeczą do zrobienia. To może być lub nie być wystarczająco ważne, aby to naprawić, ale ważne jest, aby wziąć pod uwagę jego wartość.

Oczywiście nadal musisz znaleźć sposób, aby zachęcić programistów (i siebie) do zbadania tych przypadków z góry. Jeśli Twój zespół programistów nie spędza czasu na dzieleniu się historiami, zachęć ich do szczegółowej sesji planowania przed rozpoczęciem pracy nad nimi.

Niektóre spostrzeżenia:

... kiedy odrzucam jego historie

Nie znam twojej kultury pracy ani procesu, ale dla mnie odrzucenie historii jest poważnym krokiem. Gdybym był deweloperem, generowałbym również push, ponieważ jest to nagrana akcja, która źle odbija się na mnie i zespole.

Mówi, że to niesprawiedliwe, ponieważ nie określam przypadków skrajnych.

To niesprawiedliwe, że spodziewa się, że znasz wszystkie skrajne sprawy. Ale jednocześnie niesprawiedliwie jest oczekiwać od niego tego. Każda zmiana wiąże się z ryzykiem, a po wykryciu problemów musisz współpracować jako zespół, aby je rozwiązać.

Nie znam jego projektu do czasu, gdy go zrealizuje

Nie powinieneś znać projektu. Pomocna może być znajomość projektu, aby wstępnie zgadnąć, które historie są łatwiejsze lub trudniejsze do zarządzania zaległościami. Ale unikaj uwięzienia programisty w swoim projekcie podczas pisania opowiadań. Wysysa całą zabawę, gdy jesteś po prostu klawiaturą aktywowaną głosem dla PO.

Wygląda na to, że powinniście popracować nad usprawnieniem procesu i budować zespół. Niektóre rzeczy, które mogę zasugerować dla procesu:

• Zasugeruj, aby twórca umieścił w historii czas na naprawę odkrytych skrzynek. Do licha, niech będzie częścią każdej historii użytkownika. Można to łatwo obronić poprzez wprowadzenie 0 nowych błędów. Problem polega na tym, że deweloper obecnie tego nie planuje. I nie ma czasu, kiedy odkryjesz problemy. Tak czy inaczej, zajmie to trochę czasu, więc umieść to w historii, w której jest widoczne podczas planowania.
• Po testach (a przy okazji, dziękuję za testowanie!), Wyślij programistowi listę wykrytych problemów. Naprawienie tych problemów będzie sprzeczne z warunkiem satysfakcji dotyczącym „ustalania krawędzi”.
• Jeśli coś pozostanie nierozwiązane lub zostanie odkryte zbyt późno, zdecyduj, czy opowieść musi zostać przekazana dalej, w oparciu o to, czy przypadek użycia może zostać spełniony. Zdarzają się znane problemy i obejścia. Ujawniłem je w uwagach do wydania i stwórz nowe historie, aby je naprawić.
• Jeśli w procesie występuje szczególne szorstkie miejsce, które generuje wypychanie, zmień swój proces! W końcu usprawnianie procesu jest częścią Scrum. Na przykład, jeśli twój deweloper denerwuje się, gdy odrzucisz historię, to zasugeruj zespołowi zmianę procesu, aby odrzucenie nie spowodowało poprawek. Wykonaj testy i poprawki przed Gotowe i Odrzucone.
• Pracuj z zespołem i nad tym, co wyprodukowali, i wykorzystaj go najlepiej, jak potrafisz. Nie wykonują doskonałej pracy i ty też. Więc zaplanuj to. Moje zespoły były zwykle deweloperami, więc mamy historię użytkowników nieplanowanego wsparcia dla każdego sprintu w przypadku pojawiających się problemów ... planowanie niemożliwego do zaplanowania.

Wymagania powinny być jasne i zwięzłe. Jeśli nie są, to dzieje się dokładnie to, co się z tobą stało. To twoja wina, a najgorsze, co możesz zrobić, określając wymagania, to zakładać różne rzeczy.

Podałeś konkretny przykład dotyczący dzielenia przez zero. Jeśli nie określiłeś, że chcesz zarejestrować błąd, nie narzekaj, jeśli programista wydrukuje 100 jako wynik.

Ale w takich przypadkach uzupełniałem brakujące luki i przekazywałem je deweloperowi. W końcu zdarzają się błędy w wymaganiach.