Kryteria akceptacji w środowisku Scrumowym

Zapraszamy do naszego kolejnego artykułu, który związany jest z testowaniem oprogramowania w metodykach zwinnych. Nie będziemy ukrywać, że w naszych opracowaniach skupiamy się głównie na środowisku Scrumowym, a tym razem przyjrzymy się bliżej kryteriom akceptacji.

 

Wstęp do wymagań w Agile / Scrum

Generalnie środowisko Scrumowe składa się z kilku podstawowych artefaktów. Jednym z nich jest Product Backlog, który stanowi zbiór wszystkich wymagań, składających się na wizję produktu. Osobą odpowiedzialną za listę tych wymagań jest właściciel produktu, czyli według ról w Scrumie – Product Owner. Product Backlog powinien być wypriorytetyzowany (odpowiedzialność po stronie Product Ownera) i na tyle szczegółowy, aby Development Team (Zespół Deweloperski), mógł pracować ze znajdującymi się tam wymaganiami. Wymagania te mogą być spisywane w różnej postaci, np. User Story (Historyjka Użytkownika). Jedną z cech dobrze napisanego wymagania jest potwierdzenie jego wykonania (ang. Confirmation), które pozwoli dać nam odpowiedź na pytanie, czy wymaganie zostało poprawnie zbudowane i czy nie zawiera defektów (krytycznych, w podstawowej ścieżce). Odpowiedzialność za tworzenie kryteriów akceptacji, jak i całych wymagań, leży po stronie Product Ownera, natomiast w sytuacji, gdy w Zespole Deweloperskim znajduje się osoba odpowiedzialna za testy (np. tester oprogramowania), może ona uczestniczyć w ich uszczegółowieniu.

 

KryteriaAkceptacji

 

 

Co nam dają kryteria akceptacji?

Poniżej znajduje się lista najważniejszych korzyści, płynąca z utworzonych kryteriów akceptacji

  • Wyznaczenie granicy testów

Kryteria akceptacji pozwalają nam na wyznaczenie zakresu testów, jaki należy przeprowadzić. Ich precyzyjne określenie pozwala na skupienie się na istotnych testach, a nie na testowaniu często mniej ważnych i sporadycznie wykorzystywanych elementach systemu.

  • Precyzyjniejsze koszty testów

W sytuacji, gdy mamy dokładne informacje, co należy zweryfikować w systemie, mamy możliwość precyzyjniejszego oszacowania (potrzebny czas oraz zasoby) naszych testów oraz prac programistycznych. Zasada, że im bardziej szczegółowe kryteria akceptacji, tym bardziej precyzyjne szacunki, jest jak najbardziej prawidłowym stwierdzeniem.

  • Poznanie oczekiwań klienta

W Agile’u sukces zależy również od tego, jak blisko udaje nam się współpracować z naszymi klientami / użytkownikami. W sytuacji, gdy odpowiedni interesariusze są również zaangażowani w określanie kryteriów akceptacji, możemy bliżej poznać oczekiwania klienta pod względem jakości i funkcjonalności systemu. Warto zatem angażować klienta (chyba że jest nim Product Owner) w definiowanie przynajmniej wysokopoziomowych kryteriów akceptacji.

  • Brak niespodzianek na Sprint Review

Kolejną korzyścią, jaką dają nam kryteria akceptacji, jest ich wykorzystanie podczas Sprint Review – spotkania, na którym omawiany jest zrealizowany zakres produktu i gdzie często klient po raz pierwszy widzi to, co udało nam się zrealizować w ramach przyrostu. W przypadku, gdy mamy precyzyjne kryteria akceptacji, które były konsultowane z naszym klientem i poszczególne wymagania zostały w oparciu o nie zweryfikowane, jest duże prawdopodobieństwo, że unikniemy niespodzianek objawiających się tym, że system nie zadziała w oczekiwany sposób.

  • Testy z perspektywy użytkownika

Dobrze napisane kryteria akceptacji pozwalają na tworzenie oraz weryfikację funkcjonalności z punktu widzenia użytkownika końcowego.

  • Precyzyjne przypadki testowe

Zawarte w kryteriach akceptacji dokładne informacje na temat tego, w jaki sposób będziemy weryfikować system i jakie są oczekiwania pod względem jego działania, pozwalają m.in. testerom oprogramowania na precyzyjne tworzenie przypadków testowych weryfikujących działanie poszczególnych wymagań.

 

Kto powinien pisać kryteria akceptacji?

Dobrze opracowane kryteria akceptacji to takie, które wynikają z rozmów z naszymi klientami. Osobą odpowiedzialną za tworzenie wymagań (i jednocześnie kryteriów akceptacji) jest nie kto inny, jak Product Owner. Osoba pełniąca tę rolę powinna najpierw opracować kryteria akceptacji wysokiego poziomu, a następnie je uszczegóławiać. Osobami, z którymi Product Owner powinien konsultować opracowane kryteria akceptacji, są oczywiście klienci / użytkownicy tworzonego systemu. Product Owner może być jednocześnie klientem, ale różnie z tym bywa w zależności od organizacji. Ważne jest, aby kryteria akceptacji były również omawiane z całym Zespołem Deweloperskim. W sytuacji, gdy w Development Team znajduje się tester oprogramowania, może on przyczyniać się do wyklarowania i uszczegółowienia tworzonych kryteriów akceptacji.

UWAGA!

Należy pamiętać, aby kryteria akceptacji nie były tylko i wyłącznie obowiązkiem testera oprogramowania, jak zdarza się w niektórych organizacjach. To Product Owner jest osobą odpowiedzialną za kryteria akceptacji, a reszta Zespołu może go wspomóc w ich tworzeniu, doprecyzowaniu.

Poniżej przykładowy przepływ tworzenia kryteriów akceptacji w jednej z organizacji.

SOT1 - Tworzenie kryteriów akceptacji przepływ

 

 

Ogólne uwagi do tworzenia i używania kryteriów akceptacji

Poniżej prezentujemy kilka punktów, które warto rozważyć podczas tworzenia i korzystania z kryteriów akceptacji

  • Sprint Review nie jest odpowiednim momentem, aby pierwszy raz weryfikować kryteria akceptacji w odniesieniu do utworzonego przyrostu

Weryfikacja utworzonej funkcjonalności w oparciu o kryteria akceptacji powinna odbywać się zaraz po ukończeniu tworzenia przyrostu. W przypadku wystąpienia wątpliwości, pozwala to na ewentualne wyjaśnienia oraz rozwiązanie ewentualnych defektów.

  • Kryteria akceptacji nie powinny być jedynym sposobem na weryfikację poprawności realizacji wymagania

Powinniśmy pamiętać, że weryfikacja oprogramowania powinna odbywać się na różnych poziomach i z użyciem różnych technik testerskich. Oprócz testów w oparciu o utworzone kryteria akceptacji należy przeprowadzać testy wykorzystujące np. techniki eksploracyjne czy wykonując testy jednostkowe.

  • Unikanie niejednoznacznego słownictwa

W trakcie tworzenia kryteriów akceptacji musimy unikać słów wskazujących na niejednoznaczność. W przypadku, gdy w kryteriach będą używane słowa “chyba”, “powinno”, “może”, ciężko oczekiwać, że każdy zinterpretuje to w identyczny sposób. Warto o to zadbać, aby później uniknąć niemiłych sytuacji.

  • Kryteria akceptacji do każdego wymagania

Jesteśmy zwolennikami tego, aby każde wymaganie znajdujące się w Product Backlogu było pokryte kryteriami akceptacji. Jeśli takie kryteria akceptacji nie są utworzone, Zespół powinien mieć możliwość odrzucenia takiego wymagania.

 

Jak pisać kryteria akceptacji?

Nie ma jednego poprawnego sposobu tworzenia kryteriów akceptacji. Najczęściej wykorzystywaną i podstawową techniką tworzenia kryteriów akceptacji jest zwykły opis (w formie listy), który zawiera najważniejsze informacje dotyczące sposobu weryfikacji danego wymagania. Drugim sposobem jest tworzenie kryteriów akceptacji w formie scenariusza, korzystając przy tym z technik BDD.

Aby przedstawić Wam sposób tworzenia kryteriów akceptacji, zastanówmy się nad przykładowym wymaganiem spisanym w postaci poniższego User Story

Jako użytkownik aplikacji Mantis (np. mantis.testpro.pl),
chcę mieć możliwość zdefiniowania nowego hasła
po to, aby móc korzystać z systemu w sytuacji, gdy zapomnę swoje dotychczasowe hasło.

Tak jak już mówiliśmy, dobrze stworzone wymaganie powinno składać się z elementu, który pozwoli nam potwierdzić poprawność zrealizowanego wymagania. Poniżej znajduje się przykład kryteriów akceptacji, które zostały stworzone przez Product Ownera i uszczegółowione przez Development Team (wraz z testerem) podczas jednej z sesji pielęgnacji Product Backloga.

  • Na ekranie logowania dostępny jest link “Zapomniałem hasła”, który docelowo poprowadzi mnie do ustawienia nowego hasła do swojego konta.
  • Po naciśnięciu linku “Zapomniałem hasła” zostanę przeniesiony na formularz, na którym muszę podać swoją nazwę użytkownika i przypisany adres email.
  • Po uzupełnieniu i wysłaniu formularza resetowania hasła otrzymuję link na podany adres email, po którego kliknięciu mogę nadać nowe hasło do swojego konta.
  • Nowe hasło musi składać się z co najmniej 8 znaków, zawierających co najmniej 1 dużą literę oraz znak specjalny. W przypadku niespełnienia wymagań, otrzymam stosowny komunikat.
  • Link, który został przesłany na adres email, jest ważny przez 24 godziny. Po tym czasie link zostaje dezaktywowany i nie mam już możliwości z jego korzystania. Po kliknięciu w dezaktywowany link otrzymam informację o jego wygaśnięciu.
  • Po ustawieniu nowego hasła jestem przekierowany bezpośrednio do okna logowania do aplikacji.
  • Po podaniu nazwy użytkownika i nowego hasła mam możliwość zalogowania się do aplikacji.

 

Jeśli chcielibyście poszerzyć wiedzę m.in. z zakresu tworzenia kryteriów akceptacji i testowania w środowisku Scrumowym, zapraszamy Was do udziału w jednym z naszych szkoleń – “Testowanie w Scrumie”

Testowanie w Środowisku Scrum