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. 

Dane wstępne

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.

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.

Demo

Przed Demo instaluję na środowisku Preprodukcujnym (Preprod) wersję finalną aplikacji z tego Sprintu. Do moich obowiązków należy:

  • Przygotowanie checklisty zadań, które zostały zrobione. Zadania układam w taki sposób, aby spotkanie przebiegło możliwie najsprawniej jak się da.

  • Przygotowanie danych na środowisku Preprod na podstawie powyższej checklisty. Tak by pokazać w trakcie spotkania jak aplikacja działa.

  • Zarezerwowanie salki oraz przygotowanie sprzętu potrzebnego do przeprowadzenia spotkania.

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

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. Aby 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 Statusie (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 – tworze przypadki i scenariusze 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 hronologicznie 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 przejżeć 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 stornie 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 oprogarmowania 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. Ale także jest 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 przez co mój dzień może wyglądać podobnie jak dużej części testerów ale niekoniecznie tak samo. Firmy często dopasowują Scrum do własnych potrzeb przez co często rezygnuje się z części procesu defioniowanego przez Scrum Guide.

Waldemar Szafraniec

Nazywam się Waldemar Szafraniec. Karierę testera rozpocząłem w 2012 roku. Od początku pracy w zawodzie wiedziałem, że będzie to coś więcej niż tylko praca. Obecnie praca jest również moim hobby. Jednym z moich obowiązków w obecnym miejscu pracy jest rekrutowanie nowych testerów oraz szkolenie ich. Sam stale podnoszę swoje kwalifikacje uczestnicząc w szkoleniach (ISTQB, ISTQB Advanced Level – Test Analyst). Szkolę ludzi w dziedzinie testów manualnych od 2014 roku. Jestem trenerem, ponieważ wiem, że dobrze mi wychodzi przekazywanie wiedzy, wiem jak praca testera wygląda oraz mam doświadczenie w rekrutacji.

Dodaj komentarz