Dojrzałe zespoły scrumowe pracujące w branży IT są różnorodne. Składają się z osób pełniących różne role. Najczęściej jest to Product Owner, Scrum Master, developer, analityk oraz tester. Oczywiście, jeśli zakres prac zespołu jest szeroki do zespołu dołączy ktoś jeszcze. Celem tego artykułu jest przedstawienie realnego obrazu oraz wyjaśnienie co pozytywnego wnosi tester manualny do zespołu.

Tester - niezbędny, chociaż nie najważniejszy

Jeśli chcemy realnie spojrzeć na rolę testera, to z pewnością trzeba powiedzieć, że nie jest to najbardziej strategiczna i najważniejsza osoba, niemniej jednak żaden zespół, który „dowozi” jakąkolwiek funkcjonalność nie może pominąć testera. Jeśli chcemy realnie spojrzeć na rolę testera żaden zespół, który „dowozi” jakąkolwiek funkcjonalność nie może go pominąć, niemniej nie jest to najbardziej strategiczna i najważniejsza osoba. Przyjrzyjmy się najpierw początkowej fazie projektu, kiedy zespół dopiero organizuje się. Wówczas w dziedzinie testów prawdopodobnie zobaczymy tylko test leada. To osoba odpowiedzialna za stworzenie dokumentacji wstępnej – test plan. Czasem management wymaga dodatkowej dokumentacji np. ryzyka testowego – gdzie określamy najbardziej strategiczne funkcjonalności i określamy priorytety ich testowania. Na końcu tworzony jest kalendarz testowania. Dokument ten jest opracowywany wspólnie z zespołem developerów. Na tym etapie znamy już następujące elementy procesu testowego:

• co będzie testowane,
• jakie metody będą używane,
• jakie narzędzia wykorzystane,
• jakie są terminy.

Zespół skompletowany i co dalej?

Mając to wszystko na uwadze test lead wraz z Product Ownerem może rozpocząć rekrutację testerów. Wówczas, w zależności od budżetu, podejmuje się decyzję o liczbie potrzebnych testerów oraz definiuje się kompetencje i doświadczenie wymagane od nowych członków zespołu. Kiedy zespół jest już skompletowany, testerzy rozpoczynają pracę. W zespole scrumowym na przestrzeni każdego pojedynczego sprintu developerzy są zobligowani dostarczyć jakąś porcję kodu, nadającą się do testowania. Testerzy mają do dyspozycji kilka poziomów testów, które mogą być prowadzone na różnych etapach projektu:

Testy eksploracyjne – rodzaj swobodnego testowania, kiedy tester poznaje system i poszczególne funkcjonalności w oparciu o początkową dokumentację i konsultacje z developerami i analitykami. Tutaj tester bazuje głównie na swojej intuicji i doświadczeniu z innych projektów. Rozpoznajemy na tym etapie czy szacunki ujęte w test planie są poprawne. Jeśli okaże się, że zakres testowania jest większy i bardziej skomplikowany niż pierwotnie przypuszczano, niezbędna jest korekta dokumentacji.

Testy Sanity – to szybkie, sformalizowane testy, które wykonuje się po nowym deploymencie lub w regularnych odstępach czasowych. Ich celem jest dostarczenie zespołowi szybkiej informacji o stanie i dostępności środowiska. Ten poziom testów to idealny kandydat dla testów automatycznych. Robienie ręcznie takich testów jest czasochłonne i bardzo nurzące. Wykonywanie tych samych czynności manualnie tygodniami bądź miesiącami stwarza ryzyko przyzwyczajenia się do błędu. Defekty nie będą wówczas skutecznie wykrywane.

Testy regresji – wykonywane są zawsze wtedy, gdy na środowisku pojawia się nowy kod. Sprawdzamy wówczas, czy stare, przetestowane już funkcjonalności nie zostały naruszone. Wykonuje się je zawsze gdy developerzy wprowadzą nowy kod na środowisko. Testy te są już z reguły bardziej skomplikowane niż Sanity. Liczba testów w zestawie regresji szybko rośnie, dlatego to najlepszy kandydat do automatyzacji. Obecnie świat testów automatycznych jest już tak szeroki, że z pewnością znajdziemy doskonałe narzędzia do automatycznego uruchamiania testów oraz (również automatycznego) wysyłania raportów do wszystkich zainteresowanych osób.

System Acceptance Tests (SAT) – oficjalne testy, wykonywane w zaufanym narzędziu. Testerzy mają pewność, że środowisko nie będzie zmieniało się w tym czasie. Developerzy wstrzymują deploymenty nowego kodu. Na tak przygotowanym i stabilnym środowisku testerzy wykonują wcześniej przygotowane test casy. Raport z tego etapu daje zespołowi bardzo solidny obraz czy system działa zgodne z wymaganiami.

User Acceptance Tests – ten etap odbywa się po SAT. To najczęściej powtórzenie całości lub części testów SAT przez przedstawicieli klienta. Daje mu to pogląd na to w jakim stanie jest zamawiany system. UAT mogą być przeprowadzone tylko raz, przed odbiorem systemu przez klienta. Przy większych i bardziej skomplikowanych systemach etap UAT jest przeprowadzany kilka razy dla odbierania poszczególnych części systemu.

Obowiązki testera

Tester jak widać dba o jakość dostarczonego przez zespół oprogramowania. Do jego głównych zadań należy:

Projektowanie nowych scenariuszy testowych.Wykonywanie ich zgodnie z ustalonym harmonogramem na jednym lub kilku środowiskach utrzymywanych przez zespół/projekt.

Raportowanie nowych defektów, śledzenie ich naprawiania, przetestowanie po dostarczeniu fixa oraz zamknięcie. Raportowanie defektów powinno odbywać się według ustalonego procesu zgodnie z ustalonym w projekcie lifecycle (czyli zestawu statusów, które następują po sobie oraz osób które pracują na defektem na poszczególnych etapach jego życia).

Aby sprostać tym zadaniom tester bierze udział we wszystkich eventach wymaganych przez scrum. Jest aktywnym uczestnikiem regularnych spotkań (daily lub stand-up), retrospektywy, sprint planning, sprint review.
Wspomnę też o dodatkowych aktywnościach, które mogą pojawić się w zespole i angażują dodatkowo testera: Specjalne spotkania między zespołowe np.: „defect meeting”. Organizowany jest cyklicznie kiedy liczba defektów staje się niepokojąco wysoka. Uczestniczą w nim przedstawiciele zespołu (w tym testerzy) oraz przedstawiciele (biznesu)businessu. Innym dodatkowym spotkaniem może być „environment status” – celem tego spotkania jest dzielenie się aktualnymi informacjami o stanie środowiska testerskiego. Tutaj upubliczniamy informacje o planowanych przerwach w funkcjonowaniu środowiska, planowanych wdrożeniach oraz innych obserwacjach na temat kondycji środowiska. Dodatkowe raportowanie. Tester dostarcza raporty częściowe, wykresy, zestawienia dla managementu projektu. Jego celem jest śledzenie postępów całego projektu. Tutaj przydają się kompetencje analityczne testera oraz doskonała znajomość narzędzi takich jak: Jira, HP ALM, Confluence a czasem nawet Excel.

Z racji faktu, że tester uczestniczy (a z pewnością powinien uczestniczyć) w większości aktywności zespołu, bardzo dobrze zna system nie tylko ogólnie ale też posiada wiedzę o szczegółach funkcjonowania poszczególnych jego części, rola testera jest świetnym punktem wyjścia do wszelkich awansów. I nie mam tu na myśli, że pewnego dnia tester manualny może zostać test leadem i kierować własnym zespołem. Nie jest rzadkością, że tester zostaje analitykiem. Bliska współpraca analityka i testera to norma w projekcie. Często tester zadaje najwięcej pytań o wymagania. Tester na co dzień pracuje z dokumentacją tworzoną przez analityka, zgłasza swoje sugestie a nawet raportuje błędy dokumentacji.

Wieloletnie doświadczenie testera często kieruje jego ciekawość w rejony kodu. Po jakiś czasie pojawia się pytanie jak developer zbudował tak skomplikowany system. To zainteresowanie popycha go w kierunku programowania. Niejednokrotnie zdarza się, że ambitni testerzy, po odpowiednim przeszkoleniu stają się developerami. Programista z przeszłością testerską jest znacznie bardziej wyczulony na jakość swojego kodu oraz potrafi znacznie lepiej współpracować z testerami w projekcie. Tutaj mała uwaga – kompetencja pracy w grupie i umiejętność współpracy z innymi rolami np. programista-tester jest niesłychanie trudna i ważna. Nie jest rzadkością swego rodzaju lekceważenie obszaru testów przez programistów i uznawanie testów za niepotrzebny ciężar a czasem nawet nieuzasadnione poczucie wyższości programisty nad testerem. Developer przeświadczony o swoim geniuszu i bezbłędności nie będzie widział wartości w testowaniu swojego kodu. Będzie z niechęcią patrzył na każdy defekt zgłoszony na jego kawałek kodu. Jestem przekonany, że niejeden tester z kilkuletnim doświadczeniem spotkał się z tym zjawiskiem choć raz. Do legend już przeszło „U mnie działa”. Programista z przeszłością testerską z pewnością nie będzie powtarzał tego rodzaju postawy.

Kiedy projekt dobiega końca, szczególnie test lead musi dostarczyć dokumentację końcową – test raport. To zbiór informacji dla managementu w jakim stopniu udało się zrealizować założenia z test planu. Tutaj można znaleźć wyniki testów na wszystkich poziomach, liczbę zgłoszonych i rozwiązanych defektów. Tutaj też jest najważniejsza z punktu widzenia informacja: czy etap UAT przeszedł pomyślnie i klient odebrał system zgodny z wymaganiami.

Niekiedy po zakończeniu projektu następuje faza utrzymania. W tej fazie okrojony zespół nadal funkcjonuje. Wówczas główny wysiłek skupia się na wspieraniu działania systemu na środowisku produkcyjnym, pomoc użytkownikom w obsłudze oraz od czasu do czasu dostarczenie jakiegoś ulepszenia (change request). W tej fazie bierze udział również tester. Jednak zakres jego obowiązków jest już bardzo zależny od specyfiki systemu.

Podsumowując można śmiało stwierdzić, że rola testera z zespole scrum nie jest najważniejsza. Tester nie dostarcza jakości ale dba o nią. Od jego zaangażowania i umiejętności zależy zadowolenie finalnych użytkowników aplikacji, co w prosty sposób przekłada się na wartości biznesowe firmy, która tą aplikację udostępnia publicznie. Tester to osoba, od której wymaga się określonych cech, tj: dokładność, uczciwość, zaangażowanie, inteligencja i odpowiedzialność. Testowanie aplikacji to profesja bardzo angażująca, dająca dużo satysfakcji ale to również znakomity punkt wyjścia do osiągania innych stanowisk w branży IT jak: analityk biznesowy czy programista.