Poradnik testera 1.0: Kto to testował?

Napisany przez
Maciej Lorenc
Bardzo często w swoim środowisku pracy słyszałem pytania:
• kto to testował?
• kto robił przegląd kodu?
• kto wpuścił to na produkcję?

oraz analogiczne. Pewnie wiele osób nie widzi w nich nic złego – dotyczy to zarówno pytających jak i testujących, wdrażających czy programujących. Ale jeśli głębiej zastanowić się nad tymi pytaniami, można dojść do zupełnie innych wniosków.

Wyobraźmy sobie sytuację, kiedy zaraz po wrzuceniu kodu na serwery produkcyjne występuje awaria. Osoba odpowiedzialna za wdrożenie rzuca w eter magiczne pytanie: “Kto to testował”? Pierwszą i najważniejszą kwestią jest – czy w tej sytuacji to pytanie powinno w ogóle paść? Czy w danej chwili najważniejszym jest kto testował czy robił przegląd kodu? Odpowiedź brzmi – nie. W takiej sytuacji najważniejsze jest usunięcie awarii. Dopiero po tej czynności można zastanowić się, dlaczego nie udało nam się zlokalizować  defektu wcześniej. Podkreślam – zastanowić się, nie pytać: “Kto to testował”? Mam wrażenie, że zbyt często skupiamy się na tym by znaleźć winnego, a tym samym zdjąć z siebie współodpowiedzialność za awarię.

Komunikacja w zespole jest kluczowa

Chyba nie tędy droga. Nie dość, że nie znajdujemy problemu, to jeszcze możemy spowodować szereg innych. Co mam na myśli? Ludzie są różni i różnie mogą odbierać ten sam komunikat. Jedna osoba puści tak zadane pytanie mimo uszu. Druga może odebrać je bardzo osobiście, co może spowodować choćby niewiarę w siebie, strach przed pracą z daną osobą, czy też inne konsekwencje. Należy wyraźnie zaznaczyć, że obwinianie jednej osoby w zespole jest zupełnie nieuzasadnione. Przecież daną funkcjonalność ktoś wcześniej opisał, ktoś inny zakodował, przeprowadzono testy, a może i przegląd kodu. Mogło zdarzyć się, że taki zabugowany kod przeszedł przez gęste sito testów automatycznych. Kluczową kwestią jest to, że coś zostało źle zrealizowane, a nie to, że ktoś popełnił błąd. Problem zapewne nie tkwi w samym człowieku, lecz w naszym procesie czy raczej w jego niedoskonałościach.

Celowe błędy?

No chyba, że zatrudniliśmy dywersanta. Nie wierzę w to, że w naszej branży ktoś celowo wykonuje swoją pracę źle – wierzę w to, że problem leży w procesie. Na przykład zadanie zostało opisane w sposób niewystarczający albo zakres testów został źle ustalony. Może programista zapomniał powiedzieć testerowi, że zmiany które wprowadził nie dotkną tylko modułu A, lecz także i B? Albo, że niezbędne są testy regresji? A może to tester przekonany o swojej ogromnej wiedzy nt. testowanego systemu uznał, że posiada wszystkie niezbędne wiadomości do przetestowania danej zmiany czy funkcjonalności i nie dopytał o coś programisty? Powodów może być wiele, jednak jestem przekonany o tym, że większości z nich można uniknąć poprawiając komunikację.

Nie myli się ten, kto nic nie robi

Należy pamiętać o tym, że niezależnie od metodyki w jakiej pracujemy, wszyscy gramy w jednej drużynie. Mamy wspólny cel, gramy do jednej bramki. Czy pytając “kto to testował” scalamy nasz zespół czy może powodujemy rozluźnienie relacji i burzymy zaufanie? I jeszcze raz – problem zazwyczaj nie leży w człowieku, lecz w procedurze. Znajdźmy problem, a nie “winnego”. Tylko wówczas poprawimy jakość naszego produktu, naszej pracy i zbudujemy dobrą atmosferę. Pamiętajmy – każdy się może pomylić. Nie tylko programista może mieć gorszy dzień i popełnić błąd, także tester może czegoś nie zauważyć lub o czymś zapomnieć. Wszyscy jesteśmy ludźmi i się mylimy, tego nigdy nie unikniemy. Ale swoją pracę zorganizujmy tak, aby takich pomyłek unikać i zminimalizować ich liczbę.

Potrzebujesz rozwiązania zaprojektowanego dla ciebie?
Maciej Lorenc
Lead Software Tester, Hicron

Ta strona używa plików cookie. Kontynuując korzystanie z tej witryny, zgadzasz się z naszą Polityką Prywatności.

Wyrażam zgodę