Dwie twarze testera

Kto zna uniwersum Batmana, ten teoretycznie może się domyślić, o czym będzie ten artykuł. Od razu na wstępie ostrzegam, że ten wpis jest mocno subiektywny i raczej „lekki” nie traktowałbym go jako mądrość życiową, czy testerską tylko bardziej jak na spojrzenie z pewnego dystansu na pracę testera. 🙂

Definicja postaci Two-Face

Harvey Dent był początkowo obiecującym prokuratorem okręgowym w Gotham City, który jednak zszedł na drogę przestępczości i został jednym z głównych przeciwników Batmana, kiedy jego twarz została oblana kwasem przez mafioza – Sala Maroniego, na jego procesie. Jego atrybutem jest moneta, od rzutu której zależą podejmowane przez niego decyzje, szczególnie gdy decydują o czyimś życiu lub śmierci. Cechuje go obsesja na punkcie dualizmu, liczby „2” i rozdwojenie osobowości[3].

źródło https://pl.wikipedia.org/wiki/Dwie_Twarze

Scrum to zaufanie do kolegów z zespołu

Pracując, jako tester na przestrzeni lat dużo czasu spędziłem w zespołach Scrumowych, gdzie to podejście do wytwarzania oprogramowania jest bardzo fajne i mam wrażenie takiej chęci zrobienia czegoś razem, wspólnie z kolegami i koleżankami z zespołu

Podejście „Wszyscy kłamią”

Dobra teraz szybkie odniesienie do kolejnej ciekawej postaci fantastycznej, jaką jest Dr House. Jedną z dewiz Dr House jest stwierdzenie „Wszyscy kłamią”. Moim zdaniem idealnie pasuje ono do pracy testera. Dewizy tej często używałem w swojej pracy i w sumie często wychodziło mi to na zdrowie. Dlaczego? Dlatego, że niejednokrotnie zobaczyłem w praktyce, że tak właśnie jest. Przykład z jednego projektu, w którym pracowałem. W naszym zespole był programista, który miał jedną dosyć sporą wadę, a mianowicie: lubił „przemycać” zmiany. Teraz pewnie się zastanawiacie, co się kryje pod tym przemycaniem zmian i już śpieszę z wyjaśnieniem.

Załóżmy, że zgłosiłem pięć błędów w aplikacji do różnych obszarów nawet ze sobą niepowiązanych. Programista ten często odbijał status jednego z nich na „Do testów”, równocześnie dodając do wersji z poprawką pozostałe cztery błędy. Nie zmieniał równocześnie statusów na tych zgłoszeniach. Pod tym poprawionym zgłoszeniem ze statusem „do testów” nie dawał informacji o innych wbitych zmianach. Skutkiem tego zdarzało się, że w nawale pracy nie zauważałam dodanych błędów i nie sprawdzałem ich.

Zmiana podejścia z ufnego na 100%, na „Wszyscy kłamią” sprawiła, że sprawdzałem, czy każde zgłoszenie nie ma czegoś przemyconego ekstra. 😉  Nie było kłótni. Nabyłem nawyk, by na wszelki wypadek sprawdzić co kolega podpiął do wersji.

Znaczenie zaufania w codziennej pracy zespołu

Z drugiej strony jakiś czas później pracowałem w zupełnie innym zespole, gdzie przy kawie opowiedziałem koledze o swoim podejściu, że „Wszyscy kłamią”. Zapytany, czy i ja to robię, odpowiedziałem, że ogólnie rzecz biorąc, można przyjąć, że tak. Mówiąc, że sprawdziłem i według mnie aplikacja może być wypuszczona, nie oznacza, że inna osoba nie znajdzie bugów w aplikacji przeze mnie testowanej. 

Podejście kolegi, który uważał, że należy ufać nie przekonywało mnie do końca. Lubię podchodzić do testów aplikacji z pewnym dystansem, który pozwoli mi zachować bezstronność i lepiej przetestować aplikację.  Kto nie słyszał nigdy, że coś zostało zrobione i działa super, czyli testów niewiele tam trzeba, niech teraz pierwszy rzuci kamieniem :).

Przyznać jednak muszę, że od tamtego momentu też zwiększyłem swoje zaufanie względem devów z zespołu. Uwaga spoiler… to był strzał w dziesiątkę! Jak wiadomo, tester powinien być komunikatywny i tu też potwierdziła się ta zasada.

Zwyczajnie razem z zespołem wypracowaliśmy model, który dawał nam poczucie, że mogliśmy liczyć na siebie. Zaufanie to przychodziło z czasem. Było też wynikiem obserwacji pracy kolegów.

Kiedy zaufanie pomagało mi w pracy 

Jeśli wziąć za przykład duże zmiany w projekcie, to mogą one być dwojakiego rodzaju. 

Pierwszy jest prosty, zmiany są widoczne, jako tester wiem, że dodano nowy moduł, zmieniono dużo i rozumiem, że dużo pracy trzeba włożyć w testy. 

Innym rodzajem dużej zmiany jest przykładowo zmiana bibliotek lub dodanie nowych itp. itd., czyli zmiana, po której pozornie aplikacja się nie zmienia. I tak zadanie, które wyceniłem na jedną czy też dwie godziny, zmuszało mnie do wykonania regresji – co niekoniecznie z historyjki wynikało. W przypadku tych zmian naprawdę nieocenioną pomoc okazywał zespół, który potrafił się jednoczyć i zwyczajnie nawet dać znać, jeżeli widzieli, że coś nie do szacowałem. Dodatkowo nawet przy kawie potrafiliśmy przegadać temat, który nie czuliśmy na zasadzie „Cześć mamy zadanie X, chcę je przetestować tak i tak da mi to możliwości potwierdzenia tego i tego, co o tym myślisz?” i dostawałem odpowiedź „Wiesz co, jest to ok”, albo „Zapomniałeś o, nie ma sensu tego sprawdzać, tego obszaru nie dotykałem”.

Brzmi znajomo? Poniekąd tak, ale jednak nie, bo tutaj wspólna praca przez ponad rok nad jednym projektem wyrobiła wzajemne zaufanie. Moje względem kolegów, że dają super informacje i uzupełniają moje ułomności. Jednocześnie ich zaufanie względem mojej pracy też rosło, ponieważ zawsze mogli liczyć na przetestowanie aplikacji, najlepiej jak się dało, pełną szczerość i pomoc w miarę moich skromnych możliwości w każdej sytuacji.

Dwie twarze testera

Tak więc widzicie tutaj dwie twarze testera. Pierwsza połowa twarzy w tym przypadku jest ufna, otwarta na kooperację, wszelaką pomoc i podejście zespołowe. W myśl zasady, że razem damy radę osiągnąć wszystko! Druga część twarzy odpowiedzialna jest za czujność, nieufność w stosunku do wykonanej pracy oraz wszelkich zapewnień, że to na pewno działa.

Ostatecznie na przestrzeni tych lat myślę, że najważniejsze w tym wszystkim jest zachowanie równowagi i zdrowego rozsądku. Takie trochę Yin i Yang razem to podejście daje nam komplet owocujący fajnie wykonaną pracą.

Trzymając się jednej tylko strony, możemy zostać naiwniakami, gdzie leniwy dev wciśnie nam cokolwiek (nie każdy dev jest dobrym programistą, tak samo, jak nie każdy tester jest dobrym testerem). Z drugiej strony, jeżeli tylko wszędzie będziemy wietrzyć spiski i to, że wszyscy kłamią, to zostaniemy paranoikami. Wówczas na dłuższą metę sami sobie przestaniemy ufać, bo zwyczajnie nigdy nie będzie dość testów, żeby zaspokoić nasz strach przed oddaniem źle działającej wersji oprogramowania. To z kolei zwiększy koszty naszych testów, bo będziemy sprawdzać w kółko to samo — lub też budżet na sprawdzenie jakiegoś zadania nam się wyczerpie.

A wy co myślicie? Warto bardziej ufać? Czy raczej metodą dr Housa nie ufać nikomu, bo każdy kłamie? Czy jednak coś pomiędzy tymi podejściami jest tym idealnym rozwiązaniem? A może jednak macie jakieś inne podejście, którym chcielibyście się podzielić? Komentujcie, najlepiej wpis bezpośrednio, ponieważ wówczas wasza wypowiedź nie zginie w bezkresie Facebooka, ja chętnie zobaczę i odniosę się do waszego podejścia.