Dekomponowanie funkcjonalności

Trochę nawiązuję do artykułu Jak układać sprinty pod cele biznesowe? i kradę stamtąd mapę funkcjonalności, od której zaczniemy:

Zajmijmy się teraz pierwszym celem - "Przepchać rurę" :). Wyjaśniałem tę nazwę we wspomnianym wcześniej wpisie, więc nie będę się powtarzał.

Weźmy na warsztat jedną z karteczek:

Na obrazku zamieściłem przy okazji notkę, w jaki sposób czytać te karteczkowe wyklejanki: Jako Właściciel samochodu, po to, aby podpisać wniosek (o polisę OC), mogę podać kod SMS. Odrazu uprzedzam. że taka karteczkowa analiza NIE jest tożsama ze specyfikacją wymagań i NIE jest tożsama z wymaganiami funkcjonalnymi. Karteczkowa analiza - do tego przykładu wykorzystałem fragment wyklejanki z warsztatu User Story Mapping - służy do moderowania grupy osób, do "wyciągania" z ich głów tego, co jest ważne, do konfrontowania punktów widzenia i do wykuwania wspólnego zrozumienia tego, co mamy dostarczyć.

Scenariusze Gherkin - jak doprecyzować oczekiwania biznesowe

Oczekiwanie, że mogę podać kod SMS, by podpisać wniosek powinno zostać dalej doprecyzowane. Przede wszystkim należy doprecyzować, jak to właściwie ma działać. Ja polecam do tego celu scenariusze Gherkin.

Uwaga krótko wyjaśniam, że scenariusze Gherkin to struktura rozmowy, czyli pomocniczy schemat, który pomoże Ci rozmawiać o oczekiwaniach w sposób uporządkowany i dodatkowo ustalenia spisywać w użytecznej formie. Z tego wynika, że do używania Gherkina potrzeba dwóch stron rozmowy: tych co wiedzą lub powinni wiedzieć, jak funkcjonalność ma działać oraz tych, co będą ją wykonywać. Nigdy, przenigdy nie każ biznesowi spisywać scenariuszy w samotności. Zróbcie to razem.

A tak mogłby wglądać scenariusze w omawianym przypadku:

Feature: Jako Właściciel (WS) samochodu, po to, aby podpisać wniosek (o polisę OC), mogę podać kod SMS

Background:
  Given WS wybrał potwierdzenie wniosku o polisę OC kodem SMS
  Given WS wpisał kod SMS w formularzu

Scenario: Scenariusz podstawowy, pomyślny
  When WS zatwierdził wniosek o polisę OC
  Then WS widzi potwierdzenie złożonego wniosku
  Then Wysłano mail do WS z potwierdzeniem złożonego wniosku

Scenario: Podał błędny kod SMS
  Given Kod SMS jest błędny
  When WS zatwierdził wniosek o polisę OC
  Then WS otrzymał powiadomienie o błędnym kodzie SMS

Scenario: Nastąpił timeout formularza
  When Upłynęło 60 s. od momentu zaprezentowania formularza do podania kodu SMS
  Then WS został wylogowany
  Then Wniosek otrzymał status 'Zawieszony'

Scenario: Nastąpił timeout bramki SMS
...

Sytuacja naszej karteczki wygląda więc następująco:

W pewnym momencie odkryliśmy, że właściciel samochodu chce podać kod SMS, aby podpisać wniosek. A jak konkretnie to podawanie kodu SMS działa, to doprecyzowują scenariusze Gherkin.

Shift left - planowanie testów w trakcie refinementu

OK, ale jak to przetestować? No cóż, od strony funkcjonalnej scenariusze są całkiem nieźle spisaną procedurą przetestowania "podpisywania wniosku kodem SMS". Prócz testów funkcjonalnych istnieją jeszcze inne.

Nq etapie doprecyzowywania karteczki należy przygotować plan testów, czyli pęłną listę czynności, które jednoznacznie stwierdzą, że funkcjonalność działa tak, jak powinna i jednocześnie nie działa tak, jak nie powinna. Mamy zatem testy:

• jednostkowe,
• integracyjne wewnętrzne i zewnętrzne,
• kontraktowe,
• API,
• wydajnościowe,
• bezpieczeństwa,
• interfejsu użytkownika,
• funkcjonalne,
• akceptacyjne i odbioru,
• i kilka bardziej specjalistycznych.

Tak, dobrze zrozumiałeś/aś: plan testów należy przygotować podczas rozkminiania tej funkcjonalności, jeszcze przed rozpoczęciem plac. Puk, puk - shift left! ;P

Po przygotowaniu planu testów sytuacja wygląda jak poniżej:

Dekomponowanie funkcjonalności według scenariuszy

Wyobraź sobie teraz, że zespół stwierdza, iż podawanie kodu SMS wymaga więcej pracy, więcej niż mieści się w jednej iteracji. Trzeba to podzielić. Ale jak? Chłopcy adżajlowcy każą dzielić tak, żeby mieć porcje wartościowych ficzerów. Natomiast developerzy konsekwentnie twierdzą, że tak się nie da.

Przeważnie się jednak da. Dziel scenariuszami. Po to one są. Dzieląc dużą funkcjonalność ze względu na scenariusze, mamy zarówno małe jak i wartościowe kawałki pracy. Wartość ta jest oczywiście maciupka, ale jest i stale przyrasta.

Mamy zatem następujący przykład User Story Mapping w działaniu:

Automatyzacja pomaga zmniejszyć bezwładność procesu dostarczania

W tym momencie uważni czytelnik i czytelniczka powinni dostać zadyszki. No, bo skoro chcemy iteracyjnie dostarczać małe porcje wartości i funkcjonalności, to w każdej iteracji trzeba wykonać cały zestaw zaplanowanych testów. Przecież za każdym razem chcemy upewniać się, że zrobiono dobrą robotę. Toż tyle testowania i tak często będzie kosztowne! Ano, będzie - o ile wykonujesz je ręcznie.

Jeśli całą tę kopę testów robimy ręcznie, to proces jest kosztowny. Chcąc obciąć koszty, zaczynamy preferować rzadsze dostarczanie, rzadsze wdrożenia i dłuższe cykle pracy. W ten sposób proces pracy nad oprogramowaniem staje się bezwładny. To z kolei sprawia, że biznes nie mogąc wystarczająco szybko dopchać się do kolejki pracy IT, zaczyna zlecać pracę rzadko, ale za to w hurtowej ilości. I tak dalej, i tak dalej.

Właściwym kierunkiem jest tu automatyzacja. Powtarzalne czynności powinny być automatyzowane. Automatyzowane rzecz jasna "z głową". Zwróć uwagę, że w wykazie testów nie ująłem automatycznych testów funkcjonalnych end-to-end, gdyż są one turbodrogie w utrzymaniu, a nadmierne skupienie się na nich prowadzi do odwrócenia piramidy testów.

Automatyzacja powtarzalnych czynności w procesie deweloperskim jest niezbędna. Jej brak powoduje degradację procesu.