Zastanawiasz się kim jest Agile Tester i jak wygląda jego praca? Przeczytaj artykuł i dowiedz się, jak wygląda testowanie w Scrum (i kto się tym zajmuje!).
Agile tester. Kim jest? Czym różni się od innych testerów oprogramowania? Czy w ogóle czymś się różni? Na te i kilka innych pytań postaram się odpowiedzieć w poniższym tekście.
Na początku pragnę zaznaczyć, że jest to moja subiektywna wizja oparta na własnych doświadczeniach, przemyśleniach moich znajomych - testerów, oraz wiedzy, którą uzyskałem podczas mojej przygody z testowaniem.
Jakiś czas temu, gdy byłem testerem w branży gier wideo i starałem się przejść do IT, na jednej z rozmów rekrutacyjnych padło pytanie:
Jaki powinien być tester w Agile?
Nie miałem wtedy najmniejszego pojęcia co odpowiedzieć. Nigdy wcześniej nie pracowałem w metodyce Agile, a moja wątłej wartości wiedza opierała się na skrawkach informacji przeczytanych w internecie.
Noo... eee... eeelastyczny? To znaczy taki żeby się potrafił dostosować do sytuacji i używanej technologii, żeby mógł wszystko testować! - odparłem coś w tym stylu.
Dziś prawie od roku pracuję w Scrumie i z czasem poznałem o co w tym wszystkim chodzi. Poznałem jego zalety, ale też i wady...
Wypadałoby jednak pokrótce omówić, czym jest Agile. Bez zbędnego rozpisywania się, bo to jednak artykuł o roli testera w tej metodyce, a nie o samych metodach zwinnych. Sam pracuję w Scrumie, stąd poniższy opis będzie z perspektywy bardziej Scrumowej.
Agile to metodyka wytwarzania oprogramowania
Jak sama nazwa wskazuje jest podejściem zwinnym, przystosowanym do zmian w procesach planowania, analizy. Opiera się nie na dokumentacji, a na interakcji między członkami zespołu. Nie budujemy od razu całego projektu, a staramy się krok po kroku budować poszczególne funkcjonalności. Najlepiej opisującą Agile (dokładniej Scrum) i pokazującą jego ideologię jest ilustracja, w której zamiast budować od razu samochód budujemy najpierw deskorolkę. Celem biznesowym jest zbudowanie środka transportu. Oczywiście ma on być finalnie luksusowy, elegancki i funkcjonalny. Jednak chcielibyśmy mieć jak najszybciej rezultaty!
źródło: https://blog.crisp.se/
Na deskorolce też da się jeździć, prawda? Z czasem przerobimy deskorolkę na rower, potem na motocykl, aż w końcu powstanie samochód. Taki samochód dalej może być potem rozwijany, modyfikowany itd.
Podejście Scrum cechuje pewna cykliczność, tak zwane iteracje (sprinty). Co jakiś wyznaczony czas (np. 2 tygodnie) zespół developerski zbiera się i sprawdza co wytworzył, czego jeszcze brakuje, co poszło nie tak, co poszło bardzo dobrze, co powinniśmy zrobić w następnej kolejności. To jak budowanie muru cegła po cegle, gdzie co jakiś czas zatrzymujemy się na chwilę aby spojrzeć czy dobrze idzie, czy gdzieś trzeba poprawić, a może użyć innej cegły.
Tu ważna sprawa, na którą muszę zwrócić uwagę - zespół developerski. Jest to najważniejszy podmiot, czy też "aktor" Agile. W Agile wszyscy członkowie nazywani są developerami, ponieważ zespół jako całość powinien zawierać kompetencje, aby wytworzyć finalny produkt.
Kto pracuje w takim zespole?
Programiści backend, programiści frontend, programiści baz danych, testerzy manualni, testerzy automatyzujący, analitycy, architekci systemów informacyjnych, specjaliści UX itp. Itd. Krótko mówiąc - ktokolwiek, kto jest potrzebny!
Przejdźmy do perspektywy pracy w Agile od strony testera
Sama charakterystyka pracy testera oprogramowania w systemie zwinnym z pozoru niczym się nie różni. Testuj, znajduj błędy, dbaj o jakość. Pisz scenariusze testowe, dbaj o dokumentację testową, być może coś zautomatyzuj. Wiadomo co kraj to obyczaj, co firma to zakres obowiązków na tym stanowisku.
Główną różnicą jaka rzuca się od razu w oczy jest współpraca z zespołem developerskim, którego częścią jest również tester. To interakcje z ludźmi nadają sens w podejściu zwinnym. Test oracle, czyli wiedza na której tester opiera oczekiwane wyniki testów to nie tylko dokumentacja danego projektu, ale też np. analityk biznesowy. Gdy chcesz dowiedzieć się jak coś ma działać w kontekście biznesowym, nikt lepiej tego nie wyjaśni jak product owner, osoba która go "zamówiła", a zatem ona powinna wiedzieć najlepiej co "to" ma robić. Są też oczywiście programiści i to do nich tester idzie jak coś zgrzyta. Dzięki pracy wśród developerów, droga do osoby tworzącej funkcjonalność jest bardzo skrócona. Bardzo szybko jesteś w stanie dopytać co autor ma na myśli. Przy okazji możesz bardzo szybko zweryfikować u przedstawiciela biznesu, czy to dobrze, że programista właśnie to miał na myśli. Dla porównania w outsourcingowej firmie testerskiej po znalezieniu błędu zawsze tworzony jest raport. Ktoś ten raport musi przeczytać, przypisać osobę do naprawy, ta osoba to weryfikuje, naprawia i odsyła do zgłaszającego do re-testu.
To wszystko trwa. Jeżeli ktoś piszący funkcjonalność siedzi obok, a błąd to tylko szybka poprawka w kodzie, czasami można w ogóle obejść się bez pisania raportu!
Jeśli chodzi o Scrum to ważnym aspektem dla tej metodyki jest cykl spotkań Scrumowych. Są to między innymi codziennie spotkania tzw. Daily Scrum Meeting (lub stand-up), na których członkowie zespołu przeglądają zadania nad którymi obecnie pracują. Spotkanie jest krótkie, trwa zwykle ok. 15 minut. Zazwyczaj odbywa się na stojąco, właśnie po to, aby niepotrzebnie nie przedłużać dyskusji. Jest to czas, w którym każdy członek zespołu mówi nad czym pracował wczoraj i co ma w planach na dzień dzisiejszy. Dzięki temu cały zespół wyrównuje wiedzę i wie na jakim etapie w sprincie się znajduje. Są też dłuższe spotkania typu refinement, czy planowanie, na których zespół ustala nad czym powinien pracować w dalszej kolejności. Jest to fantastyczna okazja do wyłapania błędów logicznych w początkowej fazie projektu, oraz zgłaszania wszelkiego rodzaju uwag np.:
Ja, jako użytkownik wolałbym to w formie rozwijanej listy!
Praca w zespole Scrumowym jest o tyle ciekawa, że kompetencje nieco się zacierają. To, że jesteś testerem nie znaczy, że nie możesz spróbować swoich sił jako UX designer i dorzucić do projektu jakiś ciekawy pomysł, rozwiązanie. Być może twoja uwaga będzie wartościowa i zostanie wdrożona. Możesz więc realnie przyczynić się to finalnego efektu pracy zespołu.
Kolejna charakterystyczna cecha pracy w Agile to iteracyjność, cykliczność wykonywanej pracy. Sprint się zaczyna zadania są zaplanowane i omówione zostało w jaki sposób zespół będzie je realizował. Programiści podejmują pracę, następnie oddają zadania do testów.
Tu przechodzimy do sedna sprawy pracy w Scrumie i pojawiają się pierwsze problemy. Proces opisany w poprzednim akapicie pięknie wygląda w teorii, niestety realnie rzecz biorąc jest w tym jedna spora wada. Przynajmniej wada dotycząca testów. Skoro na początku sprintu programiści zaczynają pracę nad zadaniami to w tym czasie testerzy... no właśnie, co w tym czasie robią testerzy?!
Kolejna wada pod kątem testowania w Scrumie, jaka jest mi znana z doświadczenia to zakończenie sprintu. W trakcie sprintu pierwsze zadania są oddawane do testów. Ustalmy dla przykładu, że sprint startuje w poniedziałek. Zadanie jest oddane do testów w czwartek. Testerzy biorą je do testów i nad nim pracują.
Co robią w tym czasie programiści?
Podejmują kolejne zadanie ze sprintu lub backlogu. Powiedzmy, że to było trudniejsze i oddane do testów zostaje w kolejny czwartek, a więc dzień przed zakończeniem sprintu (zakładając dwutygodniowy sprint). Testerzy zatem dostają zadanie do testów, w przeddzień zakończenia sprintu. Zadanie nie jest możliwe do przetestowania w tak krótkim czasie i w ten sposób otrzymujemy gotową receptę na spad (przejście niedokończonego zadania na następny sprint). Jest to czysto testerski spad, ponieważ prace programistyczne zostały wykonane na czas. Całe zadanie przechodzi do kolejnego sprintu i nie jest uznane jako wykonane w danym sprincie. Jest to pewien problem bo wlicza się takie rzeczy do statystyk danego zespołu.
Na szczęście sytuacja nie jest aż tak tragiczna jak w opisanym przeze mnie przykładzie. W głównej mierze dlatego, że zadań jest dużo więcej i tylko część, jakiś mniejszy procent to spady. Nie da się jednak ukryć, że jest to pewna luka w procesie. Może rozwiązaniem byłoby niepodejmowanie przez programistów kolejnych zadań pod koniec sprintu? W tym czasie mogłyby być prowadzone np. prace utrzymaniowe, unit testy, refactor kodu. Jednak ktokolwiek pracował z biznesem zdaje sobie sprawę jak czasami ciężko jest przedstawić taką filozofię. W odpowiedzi słyszy się:
Jak to prace utrzymaniowe?! A gdzie produkcja, rozwój i dodatnie wartości biznesowe?
Ciekawy jestem czy u kogoś z Was zostało wypracowane rozwiązanie problemu.
Wiemy już czym jest Agile. Znamy plusy i minusy pracy w Scrumie jako tester. Zobaczmy, jak pracować efektywnie w tym podejściu.
Wróćmy do pytania:
Jaki powinien być tester w Agile?
Spokojnie, nie musisz robić szpagatów na zawołanie żeby być zwinnym testerem. Jeszcze przed tym jak sam pracowałem w Scrumie, zasięgnąłem opinii znajomych. Wśród nich znalazło się parę niestandardowych, które mnie zaintrygowały: "O człowieku idzie umrzeć z nudów... Czekasz aż coś zrobią(programiści), czekasz i czekasz. Potem chwilę potestujesz i znowu czekasz...". "Nie możliwe, że jest aż tak źle, na pewno przesadzają" - pomyślałem.
Miałem poniekąd rację, aż tak źle nie jest, jednak trzeba sobie trochę pomóc żeby to miało ręce i nogi. Jaki zatem powinien być tester w Agile? Poniżej kilka porad ode mnie na dobry początek.
1. Dobra organizacja czasu i pracy
Tak. Nudniejsze chwile, w których programista pracuje, a tester grzecznie czeka na efekty jego pracy, przyjdą. Trzeba być na nie przygotowanym. Dobra organizacja czasu i pracy to moim zdaniem klucz do sukcesu. Takie momenty przestoju, to idealny czas na pisanie zaległych scenariuszy testowych, czy uzupełnianie dokumentacji. Wykorzystaj ten czas na konfigurację danych testowych. Wykonuj testy eksploracyjne, a nuż się coś trafi. Rozwijaj się! Myślę, że żaden szanujący się, z głową na karku pracodawca nie będzie miał problemu z tym, że uczysz się nowych technologii i nabywasz nowe umiejętności w pracy, to też jest wartość dodana dla firmy! Specjalnie nie wymieniam tu automatyzacji testów. Prawdopodobnie jeżeli łączysz funkcje testera manualnego i automatyzującego to nigdy się nie nudzisz.
2. Komunikuj się ze swoim zespołem
Czas schować introwertyka do szafy. Agile to kontakty z ludźmi i bez tego ani rusz. Myślę, że powstało już tysiące poradników dla testerów "Jak rozmawiać z programistą". Ja personalnie nigdy nie miałem z tym problemów, ale jak sobie nie radzisz to może takie poradniki nakierują Cię na dobry trop. Współpracuj, dopytuj, pozyskuj wiedzę, ale też dziel się nią jeżeli istnieje taka potrzeba. Rozmawiaj z programistami i z biznesem o rozwiązaniach. Bądź mediatorem, doradzaj. W końcu to Ty dbasz tutaj o jakość produktu. Pamiętaj, w Agile liczy się zespół!
3. Czynny udział w spotkaniach
Nie bądź statystą robiącym sztuczny tłum. Jesteś pełnoprawnym członkiem zespołu developerskiego. To nie tylko obowiązki ale też prawa. Zgłaszaj swoje pomysły i potrzeby. Podczas refinementu, czy planowania wyraź swoją opinię, swoje obawy. Przedstaw rozwiązanie jakiegoś problemu. Na retrospekcji powiedz co byś zmienił, może coś blokowało, albo opóźniało testy? Takie działanie nie tylko efektywnie zwiększa współpracę, ale też buduje świadomość innych członków zespołu, dlaczego testowanie jest ważne w całym procesie wytwórczym. Wszyscy jedziemy na tym samym wózku, do tego samego celu.
Metodyka Agile to coraz modniejsze podejście do produkcji oprogramowania. Ma z pewnością mnóstwo zalet w swoim podejściu. W podejściu elastycznym zmiana biznesowa jest mniej bolesna. Można nawet powiedzieć, że jest to podejście zbudowane pod zmiany. Tester pracujący w takim środowisku musi być przygotowany na jego dynamikę i wiedzieć jak z takimi zmianami sobie radzić. Współpraca i umiejętności interpersonalne grają tutaj ważną rolę.
Agile nie jest oczywiście bez wad. Pozostają kwestie nie do końca przemyślanej organizacji pracy programista-tester i "testerskich" spadów w sprincie. Jednak to tylko drobne szczegóły, z którymi można sobie poradzić i z czasem, wraz z nabytym doświadczeniem myślę, że nikomu to nie straszne. W zamian Agile tester jest pełnoprawnym członkiem zespołu developerskiego, specjalistą, który realnie wpływa na końcowy produkt.
