Złe wieści - dobre słowo

Testerzy i programiści mają różne zadania do wykonania i różny stosunek emocjonalny do przedmiotu swojej pracy. Muszą jednak ze sobą współpracować. Aby ta współpraca była efektywna, potrzebna jest odpowiednia komunikacja między nimi.

Testerzy i programiści mają różne zadania do wykonania i różny stosunek emocjonalny do przedmiotu swojej pracy. Muszą jednak ze sobą współpracować. Aby ta współpraca była efektywna, potrzebna jest odpowiednia komunikacja między nimi.

Kontakty z programistami są dla większości testerów chlebem powszednim. Wynika to z charakteru pracy obu tych grup - programista tworzy oprogramowanie, a tester je sprawdza. Choćby nie wiem jak starać się opakowywać codzienność w firmie w ciężkie i bogate procedury, które starają się sformalizować wszelaką możliwą komunikację, zawsze będzie miejsce na wypowiedzi, które mogą być przyczyną niepotrzebnych zatargów. Zwracam uwagę na słowo "niepotrzebnych". Bywa, że trudnych, nieprzyjemnych rozmów nie da się uniknąć. Chcę pisać o tym, co robić, żeby unikać sporów, kiedy nie są one potrzebne.

Czego tester nie wie o programistach

Wielu testerów tak naprawdę nie wie, na czym dokładnie polega praca programisty. Nie rozumieją, w jakich warunkach programiści pracują, czego się boją, czego nie lubią, a na czym im naprawdę zależy.

W procesie wytwarzania oprogramowania programista może, lecz nie musi (zależy to od firmy i sposobu tworzenia oprogramowania), wziąć udział w specyfikacji wymagań. Za to w procesie projektowania i kodowania gra główną rolę. Są to zadania wymagające od niego dużego skupienia, złożenia w jedną, spójną całość wielu szczegółów. Często napotyka w swojej pracy problemy, których nie przewidziano w fazie definiowania wymagań. Ten cały trud tworzenia w połączeniu z końcową satysfakcją, kiedy ta misterna układanka zaczyna działać, powodują coś, czego wielu testerów sobie nie uświadamia - programista jest emocjonalnie związany ze swoim kodem. Czuje się artystą. I jest to jeden z podstawowych powodów, dla których każda książka o testowaniu mówi, że programiści mogą pomagać w testowaniu, ale nigdy nie powinni testować swojego kodu. Jak można chcieć zrobić krzywdę własnemu dziecku?

Tu pozwolę sobie na pewną dygresję na temat egoless programming. Spotkałem się z tym pojęciem pierwszy raz w książce Geralda Weinberga "The Psychology of Computer Programming". Egoless programming zakłada brak owego emocjonalno-ambicjonalnego stosunku programisty do swojego kodu. W egoless programming celem każdego z programistów nie jest zabłysnąć jakimś fragmentem pięknie napisanego kodu. Celem zespołu jest napisanie stabilnego, spełniającego najwyższe standardy oprogramowania. W efekcie jeżeli w kodzie jakiegoś programisty zostanie znaleziony błąd, to zamiast się obrazić i bronić programista cieszy się, że dzięki temu tworzony przez jego zespół kod będzie jeszcze bardziej stabilny.

W społeczności open source taki model do pewnego stopnia działa. Może właśnie dlatego dojrzałe produkty open source osiągają jakość, o jakiej w przypadku produktów komercyjnych można tylko pomarzyć. W większości firm produkujących oprogramowanie egoless programming ma małe szanse, aby się przyjąć. Widzę dwie główne tego przyczyny:

  • Po pierwsze, taki model wymaga bardzo dużej pewności siebie, dojrzałości i otwartości programistów biorących udział w projekcie, co nie jest częstym zjawiskiem w wielu firmach.

  • Po drugie, niejednokrotnie liczba błędów znalezionych w kodzie danego programisty może mieć konkretne przełożenie na jego awans lub premię.

    Punkty zapalne

    Zwróćmy uwagę na pewne czynniki psychologiczne, które wpływają na relację tester - programista (o niektórych już zdążyłem powiedzieć):

  • Obydwie strony patrzą na siebie jak na ciemiężców.

  • Programista jest emocjonalnie związany ze swoim kodem.

  • Tester jest osobą, która ocenia programistę.

  • Tester przekazuje złe wiadomości.

  • Programista jest często oceniany na podstawie błędów znalezionych w jego kodzie.

    Jednym z ważnych powodów złych stosunków między programistami a testerami jest funkcjonujące w obydwu grupach przekonanie, że ta druga strona jest ciemiężcą. Zauważyłem, że niektóre bardziej liczące się postacie w świecie testów świadomie, czy też nieświadomie utrwalają taką wizję świata. Widziałem już w prezentacjach sformułowania typu: "wychować programistę", "uświadomić programiście prawa testera". Niestety, nie widziałem jeszcze prezentacji, w której zachęcano by do tego, aby programistę z r o z u m i e ć. A warto, bo on też ma swoje problemy - np. zastoje spowodowane awarią środowiska, siedzi tygodniami do drugiej w nocy, bo ktoś mu tuż przed terminem oddania pracy dorzucił do wymagań jeszcze jakiś "drobiazg".

    Bycie na pozycji oceniającego jest często postrzegane jako bycie wyżej w hierarchii społecznej czy zawodowej. Problem polega na tym, że w oczach programistów tester na tej wyższej pozycji nie jest. Jeżeli osoba o dużym autorytecie, usytuowana wysoko w hierarchii, krytykuje osobę będącą niżej w hierarchii, jest to dla kogoś krytykowanego dużo łatwiejsze do przełknięcia niż taka sama krytyka z ust osoby równorzędnej, nie mówiąc już o krytyce pochodzącej odkogoś stojącego w hierarchii niżej.

    Ponieważ tester ocenia, musi mieć powyższe na uwadze. Nie powinien w żaden sposób dać odczuć, że bycie na pozycji oceniającego próbuje wykorzystać do podniesienia swojej pozycji w hierarchii firmy.

    Jak przekazywać programistom złe wieści

    Cóż więc robić? Jak przekazywać złe informacje, nie robiąc sobie wrogów i nie wzbudzać ich niechęci? Oto kilka praktycznych rad będących wynikiem moich doświadczeń jako programisty i testera:

    Nie mówmy z niezachwianą pewnością siebie, że znaleźliśmy błąd.

    Zamiast tego powiedzmy, że aplikacja zachowała się w inny sposób niż oczekiwaliśmy. Zapytajmy, czy zdaniem programisty jest to poprawne. Niejednokrotnie on sam skomentuje, że jest to błąd i poprosi o utworzenie oficjalnego raportu. Jeżeli ma wątpliwości, spróbujmy je wyjaśnić. Nie zakładajmy, że mamy rację. Może to my źle zrozumieliśmy wymagania.

    Zawsze, zanim zaraportujemy oficjalnie błąd w bazie danych, starajmy się skonsultować to z programistą.

    Dajmy mu szansę, aby sam podjął decyzję, że zachowanie, o którym mówimy, jest błędne. Pamiętajmy, że w wielu bazach raportów błędów istnieje możliwość zdobycia informacji, który programista robi najwięcej błędów. Jakkolwiek nie kwestionuję użyteczności tej wiedzy, to trzeba być świadomym, że stosunek programistów do tematu raportów w bazie błędów nie jest neutralny.

    Bądźmy rzeczowi.

    Unikajmy złośliwych komentarzy typu: "Kiedy wy to wreszcie dobrze napiszecie!?".

    Unikajmy pytań w tonie: "Dlaczego to nie zostało zrobione tak czy siak?".

    Nie sugerujmy z niezachwianą pewnością siebie, że coś można było zrobić lepiej. Bardzo często okazuje się, że rozwiązania z pozoru oczywiste i spójne w rzeczywistości takie nie są. Dlatego dobrze się zastanówmy, zanim protekcjonalnym tonem zaczniemy wyjaśniać tym "tłumokom z dewelopmentu", jak się pisze dobry software. Jeżeli komentujemy na gorąco, to mamy 95% szans, że wkurzymy programistów i 80% szans, że się po prostu wymądrzamy i nie mamy racji. Pamiętajmy, że wymądrzanie się protekcjonalnym tonem to nie to samo, co delikatne sugestie lub dyskusja. Te ostatnie mogą rzeczywiście poskutkować (chociaż nie muszą).

    Uprzedzajmy dewelopera przed utworzeniem raportu o błędzie krytycznym.

    Nad tym punktem chcę się zatrzymać. Naprawdę nie jest miłą rzeczą dowiedzieć się, że przez nas nic nie działa. A tak czuje się programista, kiedy dostaje raport o błędzie krytycznym. Ja w takich sytuacjach daję szansę programiście, aby sam doszedł do wniosku, że mamy do czynienia z poważnym błędem. Mówię jednak z trochę większą pewnością siebie. Nie mówię: "Słuchaj, przy każdej próbie dezaktywacji konta dostaję blue-screena. Czy uważasz, że jest to prawidłowe? Możesz mi pokazać, gdzie jest o tym w wymaganiach?" To wyglądałoby niepoważnie i mogłoby być odebrane jako próba naigrywania się.

    Mówię tak: "Słuchaj. Przy każdej próbie dezaktywacji konta dostaję blue-screena. To samo dzieje się też na komputerze mojego kolegi. (Sprawdziliśmy to, prawda? Zawsze to robimy, zanim postawimy cały dewelopment na nogi, prawda?). Rzuć, proszę, na to okiem i powiedz, co o tym myślisz. Mogę ci to pokazać na swoim komputerze, a potem pomóc ci to odtworzyć na twoim. Wyjaśnij to, proszę, jak najszybciej. Dla mnie jest to błąd krytyczny. Nie mogę dalej nic robić, więc proszę o jak najszybsze zbadanie sprawy".

    Sygnalizuję w ten sposób, że temat jest krytyczny, ale jednocześnie daję programiście szansę, aby sam doszedł do wniosku, że jest to poważny problem.

  • W celu komercyjnej reprodukcji treści Computerworld należy zakupić licencję. Skontaktuj się z naszym partnerem, YGS Group, pod adresem [email protected]

    TOP 200