Nie każdy Tester to QA. Omawiamy rolę Testera/QA w zespole.

Kolejny odcinek podcastu „Rozmowy na Classpathie”, gdzie poprzez rozmowy ze specjalistami Tobiasz Kowalski stara się przybliżyć świat IT tym, którzy dopiero do niego wkraczają.

Z kolejnym gościem, Przemkiem Kowalskim , Senior QA Engineer’em w IDEMIA, rozmawiał o pracy Testera oraz QA Engineer’a, a w szczególności o tym:

• czym różnią się te dwie role?
• kim jest Tester Manualny, Automatyzujący oraz QA Engineer?
• jak wygląda typowy dzień i zadania osób, które pełnią którąś z tych ról?
• jak ważną rolą w zespole jest rola QA Engineera?
• czy młody Programista, któremu trudno znaleźć pracę na stanowisku programisty powinien pomyśleć o roli Testera?

Tobiasz: Co myślisz o tym, żeby był osobny dział QA i osobny zespół developerski? Czy lepiej jest, jeśli mamy zespół „inżynierów”, w których QAs i Developerzy pracują razem? Które podejście uważasz za lepsze? Jakie są plusy i minusy jednego i drugiego rozwiązania?

Przemek: (…) Przy tym podziale na osobne dwa zespoły, z jednej strony widzę takie plusy, że zespół QA-owy jest wtedy większy. Mamy tam pewnie, jak to zwykle w organizacjach bywa, różny przekrój doświadczenia. Są seniorzy, regularzy, juniorzy. Taka organizacja pracy może wspierać rozwój tych młodych, bo zawsze obok jest kolega, który nie tylko zna domenę, tę aplikację nad którą pracuje, ale często tworzył testy, tworzył kod związany z testami, na którym teraz ja mam jakieś zadanie i jako junior nie mogę ruszyć dalej. Na pewno łatwiejsza jest współpraca między QA’ami, przepływ wiedzy, szybsze wdrażanie się QAów, szybszy rozwój tych młodszych doświadczeniem pracowników. Natomiast myślę, że wadą jest to, że taka organizacja sprzyja takiemu nastawieniu „anty” . Tzn.” my i oni”. „Weź zgłoś im błąd!”. „Weź im odbij ten błąd!”. Takim zachowaniom. Pewnie można się starać tego unikać, można na poziomie organizacji te więzi zacieśniać i uczyć ludzi, że jesteśmy wszyscy na jednym wózku. Ale sam ten set-up moim zdaniem już lekko sprzyja takiemu „ping-pong’owi”w Jirze i w innych narzędziach.

Tobiasz: Jest to trudniejsze.

Przemek: Pewnie też utrudnia poznanie QAowi/Testerowi aplikacji na niskim poziomie – jej architektury itd. Bo tę wiedzę często pozyskujemy od Programistów. Jak siedzimy od nich dalej, mamy trochę słabszy kontakt, to może rzadziej ich pytamy o pewne rzeczy.

Tobiasz: A pracowałeś kiedyś w takim zespole? Odzielonym od produktu?

Przemek: Tak, ta moja pierwsza przygoda, to typowo taka sytuacja, gdzie zespół testerów biznesowych, to była odseparowana jednostka w tej strukturze. To było trudne. Tam mieliśmy takie przykłady, gdzie „ping-pong’owaliśmy się”. Screeny wrzucane, że u mnie działa, screeny, że u mnie nie działa. Zamiast wstać, pójść i porozmawiać z tą osobą. Tak, to na pewno był w tej organizacji problem, że to działało w ten sposób. (…) Ale dużo lepiej wspominam późniejsze, czy obecne projekty, gdzie jestem w Zespole Scrumowym razem z Developerami i ta bliska współpraca myślę, że jest bardziej owocna dla obu stron i bardziej owocna dla organizacji. Bo to pozwala dowozić jeszcze lepszą jakość. Bo jeśli pracujemy razem i mamy jako zespół, jeden wspólny cel, to łatwiej nam się zrozumieć, na przykład w potrzebach związanych z tym, że musimy coś „otestować”, że musimy mieć pipeline zbudowany z pewnego rodzaju „checków/sprawdzeń”, które pomagają nam na końcu unikać pewnych błędów. Bo pamiętajmy, że im później wykryty błąd, tym większy koszt. Ta praca blisko QA’ów i Developerów pomaga wykrywać błędy wcześniej, bo szybciej dostaniemy jakąś wersję do testów.

Tobiasz: A dlaczego to jest większy koszt? Jak liczysz koszt problemu? To też jest ciekawe.

Przemek: Dobre pytanie.(…) W cyklu życia oprogramowania, na początku zbieramy sobie wymagania, formułujemy jakąś specyfikację, jak aplikacja i system mają działać. Jeśli wykrywamy coś na tym etapie, to w zasadzie tak: nie został zaangażowany jeszcze Developer, nie spędził iluś godzin na developmencie, nie zbudowaliśmy tej paczki, nie uruchomiliśmy pewnych zasobów, nie wszedł w to finalnie Tester, który zgłosił ten błąd, na który poświęcił czas. Czyli nie wydarzyły się pewne czynności, które pozwoliły wykryć ten błąd, nie poświęciliśmy na to czasu. Jeśli wykrywamy to na tym etapie, to jest to najlepsze, jest to najtańsze. Jeśli wykrywamy błędy w trakcie developmentu, na przykład dobrymi unit testami, czy zautomatyzowaną paczką testów regresyjnych, która jest uruchamiana po każdym commicie, to „leci” nam błąd – widzimy, że mamy czerwony raport- Developer dostaje wtedy bardzo szybki feedback.  Developer jest jeszcze na etapie pracy nad tą funkcjonalnością, nie zmienił kontekstu. To nie jest feedback za miesiąc, gdy on już zapomniał, jak coś miało działać i co ta metoda tak naprawdę miała robić, więc bardzo szybko może to poprawić.  Jeśli to się dzieje za kilka tygodni czy miesięcy, to po pierwsze jest właśnie koszt na tym, że trzeba odkopać, o co tam chodziło, ktoś musi zaraportować ten błąd, może być też zaangażowany Analityk, żeby przeanalizować, czy faktycznie ten błąd to jest błąd, czy nie. Także, to kosztuje więcej, głównie przez to. Już pomijam błędy, które poszły na produkcję, bo to oznacza wydawanie paczek nowych, nowy proces releasowy.

Tobiasz: Tak, tam już koszty są ogromne, bo zakładam, że zazwyczaj to inny zespół przejmuje już ten produkt. On musi zrozumieć ten problem. (…) Jest też bardzo duży koszt na warstwie komunikacyjnej czasami

Przemek: Do tego jeszcze straty wizerunkowe, straty biznesowe. Bo ten błąd mógł się przełożyć na realną stratę zysków dla klienta.

Tobiasz: Tak, oczywiście, zgadza się. Jest takie powiedzenie w programowaniu: „nie ma to jak zastąpić godzinę analizy tygodniem programowania”. Czyli można tak potężnie poprogramować tydzień, a potem na koniec powiedzieć: ej, w sumie to jest bez sensu.

Przemek:Widzisz, jak świetnie zbudowaliśmy platformę porozumienia? (między Developerem a Testerem) 😉

Tobiasz: Cieszę się, ale wiesz, to chyba przez nazwisko.;)