Praca testera w Scrum nie polega na walce o błędy z developerami. Scrum wymusza pracę zespołową, by osiągnąć ten sam cel, jakim jest dostarczenie działającej aplikacji na czas. Praca testera w Scrum to przede wszystkim planowanie swojego czasu pracy. Planowanie testów i przygotowywanie sobie środowisk do tych testów. Praca testera w Scrum to również pisanie przypadków testowych, scenariuszy, dokumentacji i raportów (choć te w większości wypadków są generowane z aplikacji). Do codziennych obowiązków należą również spotkania, na których na bieżąco informujemy się nawzajem o postępach prac.
Wprowadzenie, czyli co musisz wiedzieć zanim przejdziesz do czytania o tym, co w kolejnych dniach robię.
Projekt, w którym pracuję, prowadzony jest w metodyce Scrum z dwutygodniowymi sprintami. To znaczy, że co dwa tygodnie spotykamy się i planujemy, co chcemy wdrożyć w aplikacji w najbliższym czasie. Na zakończenie tego spotkania powstaje lista tasków do zrealizowania w aplikacji. Od tego momentu przez kolejnych dziesięć dni (weekendów nie liczę) wspólnie dążymy do tego, by zaplanowane taski zostały zrealizowane. Na koniec dwutygodniowego Sprintu spotykamy się i omawiamy, co udało się zrobić. Następnie rozpoczynamy planowanie kolejnego dwutygodniowego Sprintu. I tak wkoło.
W moim zespole pracuje trzech programistów, jeden analityk, jeden Scrum master oraz ja tester. Razem tworzymy zespół developerski. Scrum nie przewiduje obecności testera jako testera. W Scrumie każdy jest developerem i teoretycznie (+może czasami praktycznie) powinien móc zastąpić kolegę z zespołu w jego kompetencjach. To jest teoria. W praktyce każdy ma swoją specjalizację, może nią być programowanie, testowanie czy też analizowanie i tworzenie dokumentów analizy biznesowej.
Dzień dziesiąty (nowy sprint się nie zaczął, to ostatni dzień sprintu, który właśnie się kończy)
W tym dniu mam przed sobą trzy spotkania, do których muszę się przygotować — Retrospekcję, Demo oraz Planowanie.
Przed Retrospekcją sprawdzam listę zadań z obecnego Sprintu. Domykam te, które zostały zrealizowane, a przerzucam na następny Sprint te, których nie udało się zrobić. Wolę to zrobić sam, informując Scrum Mastera, ponieważ daje mi to większą kontrolę nad tym, co zrobiłem oraz co jeszcze zostało do zrobienia.
Spotkanie – Retrospekcja
Podczas Retrospekcji omawiamy plusy i minusy z całego sprintu. Rozmawiamy o tym, co zostało zrobione. Jak się nam pracowało podczas tego Sprintu. Z czym były problemy oraz co nie zostało zrobione.
Spotkanie – Demo (Sprint Review)
Przed Demo (Sprint Review) instaluję na środowisku Preprodukcujnym (Preprod) wersję finalną aplikacji z tego Sprintu. Do moich obowiązków należy:
- Przygotowanie listy zadań, które zostały zrobione. Zadania układam w taki sposób, aby spotkanie przebiegło możliwie najsprawniej, jak tylko się da.
- Przygotowanie danych na środowisku Preprod na podstawie powyższej listy. Tak by pokazać w trakcie spotkania, jak aplikacja działa.
- Zarezerwowanie salki oraz przygotowanie sprzętu potrzebnego do przeprowadzenia spotkania.
Spotkanie – Planowanie
Po DEMO i Retrospekcji siadamy razem z zespołem do Planowania przyszłego Sprintu. Rozmawiamy na temat zadań, jakie Product Owner chciałby otrzymać z kolejną paczką. Estymujemy czas potrzebny na ich realizację tak, aby potwierdzić czy mieszczą się one w przeciągu jednej iteracji Sprintu. Wynikiem tego spotkania jest dokument analizy biznesowej.
Po tych czynnościach weryfikuję czy udało się zainstalować paczkę na środowisku Produkcyjnym.
Dzień pierwszy nowego Sprintu
Niestety pierwsze dni Sprintu nie należą do moich ulubionych – takie życie nie zawsze robimy to, co lubimy. Po przyjściu do pracy zabieram się ponownie za dokument analizy biznesowej i staram się go przejrzeć jak najdokładniej w celu zgłoszenia błędów/nieścisłości w dokumencie. Żeby nie marnować czasu, zaczynam w tym dniu planować testy na ten Scrum.
- Muszę między innymi zaplanować wygląd środowisk do testów.
- To jak powinny być poukładane wersje aplikacji na środowiskach, jakie mam dostępne do testów.
- Jakie dane testowe będą mi potrzebne. Przykładowo w testach aplikacji farmaceutycznej i refundacji leków z NFZ powinienem mieć w bazie leki, dla których w danym Sprincie zmienił się sposób refundowania.
Przygotowuję sobie bazę danych ze starymi danymi sprzed zmiany w aplikacji, aby móc zweryfikować jak się zachowają „stare sprawy” w kontekście wgranych zmian.
W międzyczasie uczestniczę w krótkim Daily Scrum (Stand up), na którym mówię, co robiłem dzień wcześniej, co mam w planach na dzień dzisiejszy oraz czy coś mnie blokuje w pracy. Wprowadziłem do tego spotkania również pytanie od testera „Kiedy szacujecie, że wpadnie pierwsza funkcjonalność do testów?” – dzięki temu lepiej mogę zaplanować pracę na najbliższe dni.
Dzień drugi
Zabieram się za pisanie dokumentacji testowej — tworzę przypadki testowe i scenariusze testowe dla nowych funkcjonalności. Staram się przy tym, aby była ona jak najbardziej czytelna, elastyczna oraz poukładana w miarę ergonomicznie w TestLinku. Ergonomiczna, czyli logicznie i chronologicznie poukładana tak by testy wykonywane były szybko. Do tego standardowo uczestniczę w Daily Scrum.
Dzień trzeci
Przeważnie w pierwszym tygodniu sprintu otrzymujemy zgłoszenia od klienta, które przeoczyłem podczas testów. W takim wypadku część z mojego dnia muszę poświęcić na support, czyli:
- Reprodukuję zgłoszone błędy.
- Zakładam taski w Jira (tu umieść dowolny bug tracker).
W tym dniu dopinam dokumentację testową i przesyłam ją do review.
Moim zdaniem to fajna praktyka, jeśli razem z innym testerem/analitykiem robicie sobie review. Pozwala to na dużo lepszy efekt końcowy produktu niezależnie czy to będzie w przypadku testera dokumentacja testowa, czy w przypadku analityka dokumentacja analityczna.
Dokumentacja po weryfikacji jest udostępniona klientowi w celu potwierdzenia tego, jakie wymagania ma spełniać aplikacja po wdrożeniu.
W tym dniu rozpoczynam przygotowywanie środowiska tak, aby było w jak najlepszym stanie do testów. Przy okazji zapisuje sobie na boku backup bazy danych tak, aby łatwo można było go odtworzyć.
Oczywiście uczestniczę w codziennym Daily Scrum, na którym dostaję powoli informacje na temat funkcjonalności, jakie są już na ukończeniu.
Dzień czwarty
W tym dniu zaczynam testy funkcjonalności, które zostały przygotowane przez zespół. Równocześnie muszę przeprowadzić retesty po zgłoszeniach, które napłynęły od klienta oraz przejrzeć i uwzględnić uwagi do dokumentacji testowej. W tym dniu staram się poprawić wszystkie uwagi i od razu je wysłać do akceptacji (o ile są zasadne – jeśli nie to rozmawiam z osobą po stronie klienta na ich temat).
Dzień piąty
Zostało tak naprawdę pięć dni pracy nad wersją. W tym momencie dopinam przeważnie mniejsze funkcjonalności wrzucone do Sprint Backlog’u i potwierdzam ich jakość. Jeszcze pod koniec Spirntu wykonam Smoke testy tych funkcjonalności.
To jest też dzień, w którym ponownie przygotowuje sobie środowisko do testów:
- wrzucam bazę przygotowaną wcześniej,
- robię wstępny raport z testów w TestLinku informujący o jakości dostarczonych funkcjonalności.
Raport przydaje mi się na Daily Scrum’ie. Tego dnia mam poinformować o postępach pracy. A także potwierdzić czy funkcjonalności przewidziane na tą wersję zostaną dostarczone zgodnie z planem i w odpowiedniej jakości.
Dzień szósty
Jest dniem, w którym intensywnie testuję wbitki oddawane przez developerów oraz zaczynam przygotowywać się do testów integracji za pomocą SOAPUI. Korzystam z wcześniej przygotowanych przeze mnie danych testowych, dzięki czemu mogę sprawnie przejść przez testy, które sobie zaplanowałem w ramach tego sprintu.
W tym dniu oczywiście standardowo biorę udział Daily Scrum.
Dzień siódmy
To praktycznie w całości testy integracji. Zgłaszanie błędów. Ogarnianie środowiska, na którym testuję. Wgrywanie nowych wersji na serwer – przeważnie w tym okresie 2-3 razy na dzień, ponieważ zależy mi na domykaniu tematów całościowo.
Równolegle z tym testami staram się na bieżąco testować scenariusze, które wpadły mi do głowy. Biorę udział w Daily Scrum i informuję na nim o postępach w testach, o tym, jak idą prace i czy widzę jakieś zagrożenia dla wystawienia wersji aplikacji.
Na koniec dnia powinienem mieć prawie komplet funkcjonalności oczywiście bez poprawek defektów, które zgłosiłem.
Dzień ósmy
Jest dniem weryfikacji, w tym dniu testuję aplikację za pomocą przypadków testowych, które napisałem na początku Sprintu i potwierdzam czy aplikacja działa poprawnie. Jeśli wszystko jest OK, to generuję raport z testów tak, aby móc go przedstawić zespołowi i przesłać go później do Product Ownera.
Na Daily Scrum’ie przekazuję informację na temat postępu prac oraz tego, jak od strony suchych statystyk (ile przypadków już przeszło „na zielono”) wygląda nasza aplikacja.
Dzień dziewiąty
Przeznaczam na przeprowadzenie testów eksploracyjnych. W tym dniu przez większość czasu staram się testować aplikację bez dokumentacji, w oparciu o moją wiedzę biznesową, doświadczenie, jeśli testy nie wykażą niczego strasznego, to przygotowuję się do wystawienia paczki z wersją aplikacji do klienta.
Dzień dziesiąty
Opisany został na początku wpisu.
Podsumowanie
Zawód testera oprogramowania wymaga umiejętności komunikatywnych, by móc zorganizować spotkania, a także wziąć w nich czynny udział. Od czasu do czasu wymusza kontakt z klientem w celu wyjaśnienia nieścisłości. Wymaga zdolności umiejętnego planowania sobie pracy, tak by nie opóźniać pracy zespołu. Wiąże się z pisaniem dokumentacji testowej. Jest również to testowanie aplikacji, by zweryfikować i upewnić się, że dostarczony do klienta produkt jest dobrej jakości.
Praca testera w Scrum to, czym akurat danego dnia się zajmuję, jest uzależnione od tego, który dzień sprintu wypada danego dnia. Ten wpis to „pamiętnik” opisujący dzień pod dniu moje obowiązki w poszczególnych dniach dwutygodniowego sprintu. Ostatnie 5 lat zawodowej kariery spędziłem na pracy w projektach Scrumowych, myślę, że opisany przeze mnie schemat pracy w Scrumie może wyglądać podobnie dla wielu testerów, ale niekoniecznie tak samo. Firmy często dopasowują Scrum do własnych potrzeb. Często rezygnuje się z części procesu definiowanego przez Scrum Guide.
