Gdy tester "nie ma co testować"...

Gdy tester "nie ma co testować"...

Nie wiem jak Wam, ale mi zdarza się słyszeć nie raz w zespołach, że testerzy nie mają co robić – większość testowania zwala im się na głowę pod koniec sprintu…- to częsty problem, ale nie chcę go tutaj rozwiązywać – opiszę go w oddzielnym artykule (racjonalne planowanie sprintu).

Zamiast tego, chciałbym wspomnieć o kilku technikach, których opanowanie byłoby z pewnością inspirujące dla testerów (i nie tylko), a których praktykowanie świetnie wypełniłoby potencjalne luki w środku sprintu.

Fakt, że tester miewa przestoje wynika bardzo często z nieco płytkiego postrzegania tej roli – jako łowcy bugów. Skoro deweloper nie dostarczył nowych funkcjonalności, to tester nie ma nowej “zwierzyny do ustrzelenia”. Proste, wina dewelopera. 

W mojej ocenie jest to trochę wymówka i brak pomysłu na wyjście ze swojej strefy komfortu, poza schemat testowania wyłącznie funkcjonalności. Ale co zaproponować w zamian? 

Testowanie wartości biznesowej?

By móc ją testować, trzeba najpierw ją znać. By ją poznać, trzeba dobrze “siedzieć” w procesie biznesowym, czy też w domenie naszego klienta.

No i teraz pytanie za 100 pkt. czy Wasi testerzy wiedzą, jaka była wizja produktu, jaki jest model biznesowy, na czym ten produkt zarabia? Czy tylko skupiają się na tym, że ma być lista kontaktów, newsletter, mapa, wyszukiwarka i żeby dało się lajkować?

Bardzo często usłyszycie – a skąd my to mamy wiedzieć? Przecież Biznes jest daleko, my nie widzimy jak oni to sprzedają, nie znamy liczb/ruchu, proces biznesowy jeśli nawet jest opisany, to trzymają go analitycy w swoich EA, nie mamy do tego dostępu, deweloperzy nam o nim nie opowiadają, bo oni wolą po prostu “kodzić” – nie obchodzi ich to.

Istnieje technika, za pomocą której można szybko nadrobić zaległości w swojej wiedzy biznesowej, bez konieczności znajomości lub żmudnego uczenia się UMLa. 

Sprawna wymiana wiedzy

EventStorming – bo o nim mowa, to warsztat podczas którego w jednym miejscu gromadzimy osoby znające dokładnie biznes/domenę produktu (eksperci domenowi, produktowcy, użytkownicy końcowi) i zespół techniczny. Wszyscy uczestnicy spotkania przyklejają na karteczkach tzw. eventy – czyli zdarzenia biznesowe jakie występują w ich procesie (np. przedmiot został wyszukany w sklepie, przedmiot dodany do koszyka, lista zakupów potwierdzona, etc.). W szybki sposób, powstaje nam mapa zdarzeń – na sali są różne osoby, więc niektóre zdarzenia się powtarzają, pojawiają się spory, co jest wcześniej, co później – dyskusja i zaangażowanie wszystkich gwarantowane. Warsztat oryginalnie zaprojektowany przez Alberto Brandoliniego, zyskuje coraz większą popularność, również w Polsce za sprawą m.in. Mariusza Gila:

Wyniki dobrze przeprowadzonego warsztatu służą zarówno developerom (jako dobry wsad do określenia bounded contextów w domain drived design), ale również product ownerom i testerom – w zidentyfikowaniu punktów zapalnych, zdarzeń krytycznych, lub ryzykownych – tych które w procesie wspierają zarabianie, lub takich, które jeśli ulegną zniszczeniu, to wygenerują nam wielkie straty. Jest to idealna baza, do układania priorytetów naszych prac, oraz spisania wstępnych scenariuszy testowych…

 

URUCHAMIALNA SPECYFIKACJA NA PRZYKŁADACH

…a skoro o nich mowa, to czas na drugą technikę – Specification By Example.

To nie tylko powszechnie znana składnia Gherkina – Given… When… Then… To coś więcej. To umiejętność takiej rozmowy z Biznesem, by w jej efekcie potrafić zapisać przykład tego, jak software ma działać w określonych biznesowych sytuacjach.

Michał Michaluk na swoim koncie github zamieścił kompletny przykład implementacji systemu zarządzania produkcją w fabryce, gdzie można sprawdzić jak wygląda architektura DDD wraz z przykładowymi scenariuszami:

 

***

Mam nadzieję, że udało mi się Was zainspirować i zachęcić do kreatywnego wykorzystywania czasu, gdy “nie ma co testować”. Dobre zrozumienie wartości biznesowej i umiejętne przygotowanie scenariuszy testowych znacznie zwiększa szanse na wytworzenie oprogramowania w taki sposób, aby nie stało się legacy jeszcze przed pierwszym releasem 😉