Rola testera w zespole scrumowym

Hierarchia w zespole scrumowym

Pytanie o to, czy tester oprogramowania jest tak samo wartościowym członkiem jak inne osoby w zespole, jest tak naprawdę pytaniem o hierarchię, czyli o to, kto decyduje o organizacji pracy w zespole. Czy jest to Product Owner, czyli Właściciel Produktu? Ten przecież odpowiedzialny jest za produkt, który ma dostarczyć klientowi, nie za zespół – nie jest więc jego menedżerem i nie nadzoruje jego pracy. A może tą osobą jest Scrum Master? Przewodnik po Scrumie podpowiada, że jest on „servant-leaderem”, co oznacza, że skupia się na identyfikowaniu potrzeb zespołu – nie zarządza, lecz obserwuje i czuwa nad tym, aby zasady Scruma były respektowane. Czy więc o porządku pracy decydować powinni zatem sami programiści? Wydaje się, że też nie do końca. A więc kto? Tak naprawdę to cały zespół deweloperski – wspólnie i dzięki stałej komunikacji – podejmuje decyzje i zarządza swoim czasem pracy.

Przeczytaj także: Samozarządzanie to zarządzanie przyszłości

Tester: model tradycyjny vs. Scrum

Ważne jest, aby zrozumieć rolę testera w takim samozarządzającym się zespole. W modelu kaskadowym poza określoną hierarchią i podziałem ról w zespole panuje konkretny porządek pracy w procesie dostarczania produktu. W takim modelu projekt wchodzi w fazę testów, w momencie kiedy deweloperzy kończą prace implementacyjne.

We frameworku Scrum tester oprogramowania nie czeka z testami do końca prac programistycznych, lecz współpracuje z innymi członkami zespołu deweloperskiego w trakcie określonych iteracji, czyli Sprintów. Umożliwia to weryfikowanie pracy zespołu deweloperskiego na każdym etapie powstawania produktu. Dodatkowo w Sprincie ograniczenie roli testera do przetestowania danej funkcjonalności po jej wytworzeniu wiązałoby się z niewykorzystaniem całego jego potencjału i marnowaniem jego czasu między kolejnymi implementacjami.

Rola testera w Scrumie – mity

Wokół roli testera w zespole scrumowym narosło wiele mitów. Do najbardziej rozpowszechnionych należy ten, że rola testera jest niepotrzebna, ponieważ każdy członek zespołu deweloperskiego posiada już wszystkie potrzebne kompetencje do stworzenia pełnowartościowej funkcjonalności. Takie przekonanie może wynikać z błędnej interpretacji definicji zawartej w Przewodniku po Scrumie, który definiuje co prawda zespół deweloperski jako wielozadaniowy i posiadający wszystkie kompetencje niezbędne do wytworzenia Przyrostu, nie określa jednak kompetencji poszczególnych członków zespołu. W Scrumie każdy jest Deweloperem, czyli osobą współtworzącą produkt. Tester oprogramowania powinien zatem brać czynny udział w pracy zespołu podczas trwania Sprintu i angażować się w trakcie spotkań. Rolą testera w Scrumie jest więc nie tylko testowanie, lecz także dbanie o utrzymanie jakości powstającego produktu i samego procesu jego powstawania – na przykład poprzez doskonalenie Backlogu produktu, o czym szerzej piszę w dalszej części artykułu.

Kolejnym, moim zdaniem krzywdzącym, mitem jest to, że w procesach zwinnych, jak Scrum, nie ma miejsca na testy inne niż automatyczne. W Scrumie każdy Sprint jest inny, niezbędna jest więc elastyczność w kontekście planowania, wykonania i analizy testów oraz ich wyników. Jest to praca, którą tester musi wykonać samodzielnie i to on dobiera rodzaj testów oraz ich szczegółowość na podstawie analizy ryzyka. W tych działaniach pomagać powinni pozostali członkowie zespołu – tak aby wspólnie dostarczyć najlepszy możliwy produkt w określonym czasie.

Jak więc tego dokonać? Odpowiem wymijającym stwierdzeniem: to zależy. Niestety nie ma tu złotego środka. Początkującym testerom polecam, by starali się być członkami zespołu nie tylko z nazwy. Uczestniczcie w całym procesie powstawania oprogramowania, a takie podejście zaowocuje szybkim zdobywaniem wiedzy i doświadczenia. Dzięki temu łatwiej będzie wam planować i organizować pracę w każdym kolejnym Sprincie, co z kolei przełoży się na lepszą i bardziej wydajną pracę całego zespołu deweloperskiego.

Zadania testera w zespole scrumowym

Doskonalenie Backlogu produktu

Wiele osób zastanawia się, w jaki sposób tester angażuje się w działania zespołu. Przyjrzyjmy się bliżej możliwym zadaniom testera w zespole deweloperskim, by lepiej zrozumieć jego rolę w Scrumie.

O Product Ownerze można powiedzieć, że jest „bohaterem ostatniej akcji”. Tester oprogramowania z kolei wkracza do akcji już na samym początku, podczas doskonalenia Backlogu produktu. Dzięki znajomości całej aplikacji, rozumieniu roli użytkownika i wartości, jaką dana funkcja wnosi, tester już na etapie sprawdzania wymagań postawionych przez Product Ownera może zwrócić uwagę na jakość, testowalność oraz użyteczność danej funkcjonalności.

Wiedza testera już na początkowym etapie pomoże uniknąć zbędnej pracy, której rezultatem mogłoby być niedostarczenie oczekiwanej przez Product Ownera wartości. Efekt? Cały zespół oszczędza czas na wytwarzaniu funkcjonalności, która np. powielałaby rozwiązania już istniejące, byłaby niepraktyczna lub nieprzydatna w gotowym systemie. Zaoszczędzony w ten sposób czas można poświęcić na dodawanie niezbędnych i poprawnie zaplanowanych elementów Backlogu. Pozwala to także oszczędzić czas poprawiania błędnie zaplanowanych rozwiązań dzięki temu, że dostarczamy oczekiwane efekty i produkt wysokiej jakości.

Estymacja

Czy estymacja jest zadaniem tylko dla programistów? Wiele razy spotkałem się z taką opinią, pracując jako tester w zespołach zwinnych. Z własnego doświadczenia mogę jednak powiedzieć, że doskonalenie Backlogu produktu i eliminowanie zbędnej pracy ma kluczowy wpływ na estymację czasu trwania zadań przez zespół scrumowy.

Wiele zespołów deweloperskich boryka się z problemem braku czasu na testowanie po implementacji danego rozwiązania. Ale proces wytwarzania oprogramowania nie kończy się wraz z zakończeniem implementacji, zatem estymacja powinna uwzględniać także czynności następujące po niej. Rolą testera w trakcie estymacji jest więc odpowiednio wcześnie przewidzieć zadania związane z testowaniem. Dzięki prawidłowej estymacji tester nie będzie przeciążony liczbą zadań, a dodatkowo nigdy nie powinno dojść w Sprincie do sytuacji, kiedy brakuje czasu na testy.

Pamiętajmy, że w Scrumie cały zespół odpowiada za ewentualne niepowodzenia, więc wszyscy powinni pracować nad unikaniem wyżej wymienionych sytuacji. Poprawne wykonanie estymacji pozwala lepiej ustalić wydajność zespołu i deklarowanie realnych Przyrostów.

Tworzenie Definition of Ready i Definition of Done

Gotowość produktu określają dwa dokumenty, które powinien sporządzić każdy zespół scrumowy: Definition of Ready (DoR), czyli kryterium gotowości, i Definition of Done (DoD) – kryterium ukończenia.

DoR definiuje, kiedy dany element Backlogu może zostać zawarty w Sprincie, a więc jest przygotowany w sposób umożliwiający jego zrozumienie, zaimplementowanie oraz dostarczenie, a wiedza testera jest w tym zakresie ważna i potrzebna. Tester na tym etapie powinien dopilnować w szczególności tego, żeby każdy element Backlogu był dla całego zespołu zrozumiały i testowalny. Jego wiedza i doświadczenie pomagają później dopilnować, aby punkt ten był spełniony dla każdego elementu Backlogu podczas jego doskonalenia.

Definition of Done (DoD) definiuje z kolei ukończenie wytwarzania danego elementu i określa, czy dana funkcjonalność jest ukończona. W tym dokumencie należy zadbać o to, aby pojawił się punkt mówiący o potwierdzaniu działania każdej funkcjonalności testami. W mojej osobistej opinii nie powinien natomiast definiować ich rodzaju, gdyż mogłoby to doprowadzić do sytuacji, kiedy pewne elementy Backlogu nie mogłyby zostać ukończone ze względu na brak możliwości wykonania konkretnych rodzajów testów. Wynika to z tego, iż Definition of Done odnosi się do każdego wytworzonego elementu, a zastosowany rodzaj testów i ich szczegółowość mogą się różnić w zależności od wielu czynników.

Podsumowanie

Dzięki zrozumieniu zasad funkcjonowania zespołów scrumowych oraz tego, że na każdym etapie, bez względu na rolę w zespole, ich członkowie dzięki swoim kompetencjom mają realny wpływ na wartość i jakość produktu, zyskujemy nowe spojrzenie na rolę testera w procesie dostarczania produktu. W tekście, który mam nadzieję będzie pierwszym z wielu o roli testera w Scrumie, próbowałem przedstawić, jak istotny jest jego wkład na każdym etapie – nie tylko w trakcie testów po implementacji. Patrząc na zadania testera z szerszej perspektywy, dostrzegamy, że jego rolą jest nie tylko znajdywanie błędów w funkcjonalnościach, lecz także przyczynianie się do właściwego zaplanowania działań całego zespołu, tak by wspólnie dostarczyć najwyższą możliwą jakość. Mam nadzieję, że mój artykuł pomoże wielu początkującym testerom poszukującym odpowiedzi na pytanie: „W jak wielu miejscach mogę poprawić nie tylko swoją pracę, lecz także działanie całego zespołu deweloperskiego?”.