Nasza strona używa cookies. Dowiedz się więcej o celu ich używania i zmianie ustawień w przeglądarce. Korzystając ze strony, wyrażasz zgodę na używanie cookies, zgodnie z aktualnymi ustawieniami przeglądarki. Rozumiem

Programisto! Czy testerzy grają Ci na nerwach?

Poznaj 6 sprawdzonych technik, które poprawią Twój komfort pracy przy współpracy z testerami.
Programisto! Czy testerzy grają Ci na nerwach?

O ogromnej wadze testowania oprogramowania żadnego odpowiedzialnego programisty nie trzeba przekonywać. Lepiej przecież zapobiegać błędom, niż usuwać je z już udostępnionych aplikacji. Duża liczba błędów wpływa negatywnie nie tylko na samą opinię o produkcie, ale także działa niekorzystnie na markę producenta, nie wspominając już o kosztach usuwania bugów. Dlatego twórcy oprogramowania coraz powszechniej stawiają na zespoły testerskie, z którymi muszą współpracować programiści. Problem polega jednak na tym, że nawet jeśli programista rozumie wagę testów, nie musi rozumieć testerów. Niestety, nierzadko postrzega ich wręcz jako przeciwników, a przynajmniej kolesi, którzy nie wiedzieć czemu przyczepiają się do wszystkiego i są po prostu złośliwi.

Czy zatem programista rzeczywiście może dogadać się z testerem? Z odpowiednim podejściem - jak najbardziej.
 

Cel przede wszystkim

Fundamentem jakiegokolwiek porozumienia z testerem jest uświadomienie sobie, że nie jest on naszym wrogiem. Nawet, jeśli to osoba niezwykle irytująca, której widok podnosi Ci ciśnienie, musisz zmienić podejście. Traktowanie testera jako wroga, którego trzeba jak najszybciej pokonać wszelkimi możliwymi sposobami, to najprostszy krok do konfliktu w zespole. Skutkuje stratą czasu, przedłużającą się pracą nad projektem i nerwową atmosferą. Oczywiście zmiana podejścia do testera nie jest łatwa. W końcu przecież w pocie czoła tworzysz kod, rozwiązujesz skomplikowane problemy programistyczne, łapiesz nadgodziny, może nawet zarywasz nocki przed deadlinem, a tu pojawia się napuszony tester, który wciska we wszystko swój wścibski nos i się wymądrza. Tylko czy to rzeczywiście wina testera, że napisałeś kod z błędami? Nie zapominaj, że pracujecie w tym samym zespole, jesteście częścią tej samej firmy i macie ten sam cel: udostępnienie klientowi wysokiej jakości oprogramowania.
 

Komunikacja, komunikacja, komunikacja

Często dużym problemem we współpracy programisty z testerem jest brak komunikacji. Nie jesteście osobnymi wyspami, które nigdy się nie spotkają. Prędzej czy później staniecie naprzeciwko siebie: twarzą w twarz lub za pośrednictwem poczty elektronicznej, a wtedy zapewne dojdzie do starcia. Nagle okaże się, że to, co dla testera jest błędem, z Twojego punktu widzenia nie jest żadnym bugiem. Test, który został przeprowadzony, nie jest dla Ciebie w ogóle ważny, ponieważ dana funkcja bardzo dobrze działa. Tester będzie miał zapewne inne zdanie na ten temat. Tych wszystkich nieporozumień można by uniknąć, gdyby istniała dobra komunikacja. Najlepiej porozmawiaj z osobą odpowiedzialną za testy jeszcze przed napisaniem kodu i omów z nią to, co zostanie przetestowane. Ustalcie wspólne priorytety. Wiedząc, co i jak zostanie przetestowane, będziesz mógł podejść odpowiednio do kodu i unikniesz pyskówki z testerem.

Swój kod testuj jako pierwszy

Programista musi zrozumieć, że tester nie jest jego niańką, która pogłaszcze po głowie i zajmie się całą robotą związaną z testowaniem, zwalniając go tym samym z tego obowiązku. Jeśli chcesz uniknąć nadmiernej frustracji, pretensji i poczucia, że tester jest złośliwy, sam testuj jako pierwszy to, co napisałeś. To właśnie Twoją rolą jest identyfikowanie problemów, usuwanie bugów i „dopieszczanie” kodu. Musisz zrozumieć, że tester to w rzeczywistości ostatnia obrona przed oddaniem klientowi oprogramowania z błędami. To ostatni szaniec, który dba w rezultacie o Twoją reputację i prestiż firmy w oczach użytkowników produktów. Zrozumienie specyfiki pracy testera zmienia optykę postrzegania specjalistów od testowania. Nie każ im szukać błędów, daj im możliwość sprawdzenia poprawności kodu. Nie przez przypadek najlepsi testerzy mawiają często, że weryfikują oprogramowanie, a nie testują. Niby niewielka różnica, a jednak istotna.
 

Błędy w kodzie, a efektywność

Efektywność zespołu ma kluczowe znaczenie dla dotrzymywania terminów ustalonych z klientem. Niestety, każdy cykl znajdowania błędów, naprawiania i ponownego sprawdzania poprawności działania oprogramowania wiąże się z wydłużeniem pracy nad projektem. Co, jeśli takich cykli jest bardzo wiele? Nie powinno dziwić, że takie procedury zabierają dużo czasu, skoro konieczne jest wykonanie wielu różnych czynności: znalezienie i zgłoszenie błędu, przypisanie go konkretnemu programiście do poprawy, wysłanie kodu do ponownego sprawdzenia, ustalenie, czy bug został naprawiony, a potem oznaczenie tego jako sprawy załatwionej. Dobra współpraca programisty z testerem polega również na tym, że potrafią oni uniknąć formalnych procedur, które są bardzo czasochłonne i obniżają efektywność zespołu. Częsty kontakt z testerem, rozmowa, bezpośrednia współpraca to szybszy sposób na eliminowanie błędów niż ograniczanie kontaktu tylko do oficjalnych procedur.
 

Warto współtworzyć zautomatyzowane testy

Konflikt między programistami, a testerami często wynika z tego, że ci ostatni nie są… programistami. Nie, to nie kwestia megalomanii programujących - chodzi o odpowiednie umiejętności i wiedzę. Ile razy już frustrowałeś się, analizując raport na temat błędów w Twoim kodzie, chociaż dobrze wiedziałeś, że on działa? Mimo to okazywało się, że zautomatyzowane testy się nie powiodły. Niestety, czasami problem polega na tym, że takie testy nie przechodzą, ponieważ tester nie napisał lub nie przygotował ich poprawnie. Ty jako programista dostrzegasz to od razu i... krew Cię zalewa. Cały dzień zepsuty. Czy nie lepiej zatem współpracować z testerami również na tym polu? Zamiast doświadczać frustracji przy lekturze raportu o błędach, korzystniej jest pomóc testerowi w tworzeniu zautomatyzowanych testów. Oczywiście nie chodzi o to, żebyś wykonywał za niego całą pracę, ale o to, żeby wesprzeć go programistyczną wiedzą.
 

Gdy tester nie chce porozumienia

Niestety, możesz trafić na testera, który w rzeczywistości nie chce żadnego porozumienia. Bez względu na to, że wyciągasz do niego rękę, on i tak jest do ciebie negatywnie nastawiony. Mało tego, na każdym kroku próbuje Ci udowodnić, że Twój kod jest do niczego.

Dlaczego tak się dzieje? Przyczyn jest wiele – tester może mieć do Ciebie jakiś żal z przeszłości, wyładowuje na Tobie frustracje spoza pracy lub czuje się kimś gorszym od programisty. Ten ostatni przypadek wcale nie jest rzadki. Być może to człowiek, który aplikował do firmy na stanowisko programisty, a wylądował na stanowisku testera. W takiej sytuacji mógłbyś oczywiście iść na konfrontację. Tylko po co? Konflikt nie jest dobry ani dla Ciebie, ani dla efektywności Twojego zespołu. O wiele lepiej ugryźć się czasem w język, przełknąć dumę i przyznać, że tester ma rację, choć oczywiście to nie jest łatwe.

Nierzadko okazuje się, że taki sfrustrowany tester potrzebował dowartościowania albo po prostu zwykłej, ludzkiej rozmowy. Szybko sam zaczyna rozumieć niestosowność swojego zachowania, a nawet jest mu wstyd. A wtedy wyciągnie do Ciebie dłoń. Niestety, nie działa to w każdym przypadku. Bywają testerzy „niereformowalni”, z którymi na porozumienie nie masz szans. To samo zresztą dotyczy programistów. Jednak w takiej sytuacji nie będziesz mógł zarzucić sobie, że nie próbowałeś się dogadać.

Zobacz więcej na Bulldogjob

Masz coś do powiedzenia?

Podziel się tym z 80 tysiącami naszych czytelników

Dowiedz się więcej
Rocket dog