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ę.
