5 grzechów komunikacji QA – DEV

W pracy Testera istotną umiejętnością jest odpowiednia komunikacja na lini Tester – Developer. Dlatego dzisiejszy wpis przygotował dla Ciebie specjalista w tej dziedzinie Aleksander Gozdek. Ma on za sobą wieloletnie doświadczenie jako Software Engineer oraz Scrum Master.

Zapraszam Cię na blog Aleksandra dotyczący komunikacji i ludzi www.alexgozdek.com.

#1 Rywalizacja.

W dysfunkcyjnych zespołach można spotkać się z rywalizacją pomiędzy testerami, a
programistami. Objawia się ona chęcią udowodnienia wyższości jednych nad drugimi. Z
jakiegoś powodu powstają dwa obozy. Programiści uważają się za lepszych, bo kodują i
wytwarzają nowe funkcjonalności. Testerzy uważają, że to dzięki nim produkt w ogóle działa
i obwiniają programistów za kiepską jakość. Dzieląc zespół na my/oni budujemy granicę.
Ludzie pracujący w silosach, podzieleni wyraźnie na kompetencje gubią cel jakim jest
dostarczenie działającego oprogramowania. Zespół wytwarzający oprogramowanie powinien
być jak zespół piłkarski. Z punktu widzenia meczu najważniejszy jest wynik zespołu, a nie
statystyki poszczególnych zawodników, czyli kooperacja, a nie rywalizacja.

#2 Brak dzielenia się wiedzą

Brak wychodzenia poza swoją rolę i obowiązki jest kolejnym czynnikiem po rywalizacji, która
tworzy bariery. Zarówno testowanie, jak i kodowanie to skomplikowane i złożone zadania.
Oczywiście ciężko znaleźć kogoś kto jest świetny zarówno w jednym i jak i drugim. Z punktu
widzenia rozwoju warto jednak wychodzić poza swoje codziennie obowiązki i dowiadywać
się jak najwięcej o tym czym zajmują się koledzy w pracy. Jeśli jesteś testerem dowiedz się
jak wygląda programowanie np. w jaki sposób został naprawiony dany bug. Jeśli jesteś
programistą zainteresuj się jak pracują testerzy i z jakimi problemami się mierzą. To otwiera
drzwi do komunikacji opartej na wzajemnym zrozumieniu.

#3 Krytyka.

Przekazywanie negatywnych informacji nie jest łatwym zadaniem. Szczególnie jeśli zależy
nam na dobrych relacjach w zespole. Najczęściej występującym problemem nie tylko wśród
osób technicznych, ale także kadry menadżerskiej jest nieumiejętne przekazywanie
informacji zwrotnych. Należy pamiętać, że krytyka powinna skupiać się na problemie, a nie
osobie. Często niestety można usłyszeć komentarze dotyczące umiejętności typu “słabo to
napisał”, “źle zaprojektował rozwiązanie”, zamiast po prostu “ten kod ma błędy” lub
“rozwiązanie zostało źle zaprojektowane, ponieważ nie uwzględnia sytuacji X”.

#4 Brak transparentności.

Współpraca między QA, a DEV jest wyjątkowo istotna nie tylko z punktu widzenia samego
zespołu, ale także jakości produktu. Zrozumienie przypadków testowych przez
programistów, czy też ograniczeń technologicznych przez testerów pozwala zaoszczędzić
sporo czasu na trudne i żmudne dyskusje. Szczególnie liderzy zespołów, kierownicy i Scrum
Masterzy powinni dbać o przepływ informacji pomiędzy testerami, a programistami. Jeśli

toczy się dyskusja odnośnie nowych funkcjonalności to poza programistami powinni być
obecni również testerzy. To oni pozwalają znaleźć luki w przypadkach użycia. Niestety w
firmach wciąż często widuję podział wertykalny, w którym dyskusje toczą się głównie według
podziału na role lub działy. Programiści dyskutują o funkcjonalnościach wyłącznie z punktu
widzenia kodowania, natomiast testerzy z punktu widzenia testowania.

#5 Przecież to oczywiste.

Im większe doświadczenie, tym większa pokusa do zakładania, że coś jest oczywiste. Z
moich obserwacji wynika, że jest to częsta przyczyna problemów komunikacyjnych w
zespołach technologicznych. Tester zgłaszając buga może czasami pominąć pewne
szczegóły, ponieważ zakłada, że programista powinien wiedzieć jak go zreprodukować.
Testując system po jakimś czasie niektóre aspekty faktycznie stają się dla niego oczywiste.
Z drugiej strony programista tworząc oprogramowanie również może pójść na skróty,
ponieważ tester i tak znajdzie ewentualne bugi. Wystarczy dodać do tego komunikację
elektroniczną, zamiast face-to-face, pracę w rozproszonych zespołach i problem staje się
jeszcze większy. Tego typu małe niedopowiedzenia i nieprawdziwe założenia przyczyniają
się do napięć w zespołach, które z czasem nawarstwiają się i psują relacje.

Udostępnij i podziel się z innymi!
  • 11
  •  
  •  
  •  
  • 11
  •  
  •  
  •  

Dodaj komentarz

avatar

This site uses Akismet to reduce spam. Learn how your comment data is processed.

  Subscribe  
Powiadom o