Niemało już zostało powiedziane na temat różnic w sposobie myślenia testerów i programistów. Jest dość oczywiste, że testerzy patrzą na produkt z innej perspektywy niż programiści i często łatwiej wychwycić błąd w czyjejś pracy, niż zobaczyć go we własnej. Dlatego tak bardzo ważne jest mniej lub bardziej niezależne testowanie.

Poza tym, istnieje jeszcze jedna istotna różnica - w odmiennych stylach pracy. Praca testera zazwyczaj wymaga częstego przenoszenia uwagi: w ciągu dnia tester może wykonać do kilkunastu niepowiązanych ze sobą czynności. Programiści natomiast pracują w zupełnie inny sposób − zazwyczaj wykonują swoją pracę w stanie "przepływu" (flow). Owa osobliwość pracy programisty została szczegółowo opisana przez Toma Demarco i Timothy'ego Listera w kultowej książce "Czynnik ludzki ─ skuteczne przedsięwzięcia i wydajne zespoły": "Przepływ jest stanem głębokiego zaangażowania w pracę, graniczącego z medytacją. Podczas trwania przepływu człowiek odczuwa łagodny stan euforii i nie jest świadomy przepływającego czasu: 'Zacząłem pracować i nim się obejrzałem, minęły trzy godziny.' Nie istnieje poczucie wysiłku, a praca wydaje się po prostu płynąć". To ten rodzaj stanu umysłu, w którym programista płynnie pisze kod wysokiej jakości.

Nie można pogrążyć się w tym stanie na zawołanie; potrzeba przynajmniej 15 minut uwagi i koncentracji, by w niego wejść. Za to bardzo łatwo wyprowadzić programistę z tego stanu. Kiedy jesteś ciągle rozpraszany, niemożliwy jest płynny powrót do stanu przepływu... Wynikiem tego jest niższa wydajność pracy i wzrastające rozdrażnienie skierowane na ludzi, którzy nie dają Ci się skupić.

Warto mieć na uwadze tę osobliwość podczas komunikacji z programistami. Kiedy to tylko możliwe, staraj się wybrać jak najmniej uciążliwy sposób komunikacji. Zatem, komunikacja drogą mailową jest lepsza niż wiadomość na czacie, a czat jest lepszy niż rozmowa telefoniczna lub nagła wizyta. Niektórych ludzi drażnią i rozpraszają nawet wiadomości na czacie, ponieważ myślą, że oczekuje się od nich natychmiastowej odpowiedzi.

Nie nawołuję do zaprzestania jakichkolwiek form komunikacji "na żywo", lecz lepiej zaplanować ją wcześniej, by nie przeszkadzać kolegom podczas pracy.

Jeśli pracujesz w jednym pokoju z programistami, nie zapomnij, że hałas może utrudnić koncentrację i pogrążenie się w przepływie. Zresztą, zachowanie ciszy świadczy o okazanym szacunku dla wszystkich kolegów z pracy, nie tylko dla programistów. W firmie, w której kiedyś pracowałam istniała zasada − jeśli chcesz porozmawiać przez telefon, wyjdź na korytarz. Wierzę, że jest to dobra zasada w każdej firmie IT.

Konstruktywna krytyka

Szczerze mówiąc, nikt nie lubi być krytykowanym. Ludzie są różni; niektórzy są bardziej wrażliwi na krytykę, inni mniej, jednak mało prawdopodobne, że ktoś ją lubi. Poczucie rozdrażnienia, smutku, przygnębienia, podczas gdy ktoś wytyka Twoje błędy jest czymś normalnym i naturalnym. Mimo wszystko, na tym polega praca testera − na wyszukiwaniu defektów i problemów oraz zgłaszaniu ich. W zasadzie, wszyscy uczestnicy projektu to rozumieją, przynajmniej teoretycznie, jednak wciąż trudno zmienić sposób myślenia odnośnie krytyki...

Czasami między testerami i programistami powstają całkowicie bezsensowne, a nawet krzywdzące antagonizmy, które potrafią zniszczyć ducha współpracy, zepsuć relacje i stworzyć napięcia. W ideale, wszyscy uczestnicy projektu powinni pamiętać, że mają wspólny cel i nie są wrogami ani rywalami, lecz ostatecznie wszyscy jadą na tym samym wózku. Wiemy jednak, że w praktyce nie zawsze to tak wygląda.

Wiele już powiedziano na temat znaczenia konstruktywnej krytyki, jednak nie da się zastosować wszystkich rad w naszej pracy. Nie, nie będę Cię nakłaniać do pisania zgłoszenia o błędach przy użyciu słynnej metody kanapki (pochwała przed krytycznym komentarzem i od razu po nim), tym bardziej że nawet pięcioletniego dziecka nie da się okłamać tym sposobem więcej niż raz czy dwa. Ogólnie rzecz biorąc, sama forma zgłoszenia defektu w znacznym stopniu chroni nas przed niekonstruktywną krytyką, tak więc przy opisywaniu defektów powinno się pamiętać tylko o jednej zasadzie: konstruktywna krytyka musi być dobrze uzasadniona. Wytłumacz, dlaczego myślisz, że coś jest defektem. W ideale, odnieś się do wymagań lub standardów, z którymi program musi być zgodny. Jeśli masz trudności z wyjaśnieniem, dlaczego uważasz coś za pluskwę, to znaczy, że coś tu jest nie tak. Jeśli po prostu wydaje Ci się, że "lepiej byłoby na odwrót", może Twoja uwaga powinna być rozważona jako udoskonalenie lub feature request.

Nietrudno jest napisać zgłoszenie defektu w obiektywny i konstruktywny sposób. O wiele trudniejsza jest komunikacja "na żywo". Od czasu do czasu trzeba ustalić coś osobiście, i ogólnie taka umiejętność jest przydatna. Często kilkuminutowa rozmowa twarzą w twarz jest bardziej efektywna niż tygodnie wymiany mailowej. Przy czym istotne jest, aby nawiązać konstruktywny dialog.

Tak więc, w naszym przypadku powinieneś zastosować następujące zasady konstruktywnej krytyki:

Wybierz czas i miejsce. Przestań atakować programistów pytaniami typu "Kiedy zamierzasz naprawić pluskwę AB-123?!" na korytarzu lub podczas przerwy na kawę w kuchni. Ludzie spokojniej reagują na krytykę wtedy, gdy spodziewają się ją usłyszeć. Dobrym pomysłem jest ustalenie cyklicznych spotkań z zespołem testowym i projektowym.

Unikaj ataków osobistych. Jest oczywiste, że krytyka powinna być skierowana na sytuację, a nie na osobę, z którą rozmawiasz, w przeciwnym wypadku osoba ta zacznie się bronić i konstruktywny dialog stanie się niemożliwy.

Kontroluj komunikację niewerbalną. Jest to czasem trudne, szczególnie dla osób silnie emocjonalnych, szczególnie gdy wkładają w swoją pracę serce i naprawdę zależy im na sukcesie produktu lub projektu. Jednak warto włożyć trochę wysiłku w samokontrolę. Twój tembr głosu, gesty, intonacja − wszystko to jest tak samo ważne jak znaczenie Twoich słów. Nawet jeśli używasz neutralnych fraz, jednak niewerbalnie przekazujesz negatywne emocje, może to utrudnić osiągnięcie porozumienia z kolegami z zespołu, którzy mogą zacząć reagować w negatywny i emocjonalny sposób, bez zwracania uwagi na dokładne znaczenie twoich słów.

Skoncentruj się na najbardziej istotnych rzeczach. Wybierz najważniejsze punkty, na których chcesz się skupić i rozmawiaj na ich temat, bez rozwodzenia się nad nieznaczącymi kwestiami. Jeśli dostarczysz słuchaczowi zbyt wiele informacji, nie zapamięta on wszystkiego lub zapamięta niezbyt dokładnie to, co najważniejsze.

Zawsze dawaj swoim kolegom możliwość odpowiedzi. Słuchaj uwag i wyjaśnień. Nawet jeśli się nie zgadzasz, daj drugiej stronie szansę na wypowiedzenie się.

Pokaż, że także jesteś otwarty na krytykę. To bardzo istotna kwestia z punktu widzenia psychologii − pokazanie, że nie jest to proces jednostronny i jesteś gotowy na przyjęcie krytyki dotyczącej Twojej pracy. Możesz zasugerować programistom, aby wzięli udział w przeglądzie koleżeńskim (peer review) Twojej dokumentacji testowej (przypadki testowe, plan testów itd.). Jeśli się zgodzą i znajdą na to czas, może to być naprawdę przydatne, nie tylko z psychologicznego punktu widzenia, lecz także dlatego, że mogą mieć całkiem dobre pomysły na ulepszenie procesu testowania. Jeśli się nie zgodzą, przynajmniej dałeś im szansę.

Pamiętaj, że jesteście jednym zespołem. Jakkolwiek banalnie to brzmi, powinieneś o tym pamiętać i przy okazji przypominać innym, jeśli zauważysz, że Twoje uwagi krytyczne są negatywnie przyjmowane.

I jeszcze jedna rzecz, o której należy pamiętać, dzieląc przestrzeń z programistami. Kiedy znajdziesz poważny defekt, Twoja radość jest całkowicie zrozumiała (dla innych testerów), lecz postaraj się nie demonstrować jej w zbyt widoczny sposób − ludzie mogą to źle zrozumieć i pomyśleć, że jesteś złośliwy.

W następnym artykule zastanowimy się, w jaki sposób można poprawić komunikację zwrotną między testerem i programistą.

Victoria Slinyavchuk
Consultant on Software Testing