Komunikacja między testerem a deweloperem

Podczas gdy dużo pisze się o komunikacji programista-programista, programista-klient, kierownik zespołu programistów, nie mogłem znaleźć tekstu, który zawierałby wytyczne dotyczące komunikacji i relacji tester-programista.

Niezależnie od tego, czy testerzy i programiści są oddzielnymi zespołami, czy w tym samym (w moim przypadku jestem samotnym testerem w zwinnym projekcie programistycznym), jestem przekonany, że postrzeganie testerów jest niezwykle ważne, aby testy były dobrze akceptowane , a także, aby przyczynić się do poprawy jakości projektu (na przykład nie należy ich postrzegać jako siły policyjnej).

Wszelkie porady lub badania dotyczące sposobu, w jaki tester powinien komunikować się z programistami?

Aktualizacja : Dziękuję wszystkim za odpowiedzi. Wszyscy potwierdzili, co miałem na myśli. Na razie mój zespół był bardzo otwarty na moją rolę i osiągnęliśmy prawdziwy postęp. Mogłem wybrać więcej niż jedną odpowiedź, ale musiałem podjąć decyzję.

Najłatwiejszym sposobem na usprawnienie komunikacji jest współpraca z programistami (oraz projektantami i architektami itp.) Oraz powolne rozbijanie tych głupich ról i ostatecznie uświadomienie sobie, że wszyscy jesteśmy testerami, z wyjątkiem tego, że niektórzy z nas mają więcej doświadczenia niż inni.

Aby zwinnie, po prostu zrób to „przy książce”. Testerzy są częścią zespołu, a nie tylko zewnętrzną jednostką, której przekazujesz rzeczy po zakończeniu. Twoja cenna wiedza jest wykorzystywana podczas całego rozwoju. Po pierwsze, tworząc historie użytkowników, pomagasz uzyskać testy akceptacyjne i uczynić je zautomatyzowanymi. Testy te są następnie wykorzystywane przez programistów w ich pracy. Codziennie spędzasz czas na testach eksploracyjnych częściowej i ukończonej pracy i rozmawiasz z organizacją producentów, aby stale wyjaśniać i doskonalić swoje testy.

Właśnie to mam na myśli, gdy mówię o „współpracy”. Jestem całkowicie pewien, że tak powinna działać komunikacja w zespole. Ten artykuł wyjaśnia to bardzo dobrze.

W przeciwieństwie do tego wiele organizacji lubi zajmować się rozwojem, umieszczając wszystkich testerów (i DBA oraz projektantów i programistów) w osobnych działach. Działa to przeciwko komunikacji i służy jedynie wzmocnieniu idei stopniowego rozwoju. Próbowanie poprawy komunikacji w takiej sytuacji jest możliwe, ale niewielkie ulepszenia, których można się spodziewać, nie są warte wysiłku. Przynajmniej nie w porównaniu z faktycznym umieszczaniem ludzi w tym samym pokoju i tworzeniem wielofunkcyjnych zespołów.

Mocno wierzę w DOWOLNĄ komunikację między programistą a testem.

Zbyt wiele razy widziałem walki bun między każdą drużyną, drobne tam iz powrotem („zamknięte z założenia”, a następnie „ponownie otwarte” itp.).

Zawsze mówię testerom, z którymi współpracuję, aby przyszli i porozmawiali ze mną, jeśli mają jakiekolwiek wątpliwości.

Jedną rzeczą, której naprawdę NIENAWIDZĘ, są programiści, którzy są aroganccy w testowaniu i rozmawiają o tym, więc staram się robić wszystko, co mogę zrobić, aby wspierać dobre relacje z zespołami testowymi.

Tester powinien być bardzo przejrzysty i precyzyjny z programistami podczas komunikowania się na temat błędów i testowania. Szczegółowa lista kroków do odtworzenia błędu, w razie potrzeby zrzuty ekranu ... Niejasne opisy błędów, których nie można odtworzyć lub które mają niejasne kroki do odtworzenia, bardzo szybko zaśmiecą relację programista-tester.

Nigdy nie wierzyłem, że zawsze istnieje poziom nieporozumień między deweloperem a testerem, ale musiałem zmierzyć się z tą sytuacją, gdy jeden z moich najlepszych przyjaciół dostał rolę testera w firmie, w której pracowałem, i ku mojemu zaskoczeniu przydzielono mu ten sam moduł do testowania że się rozwijałem, więc to była prawdziwa FUNwspółpraca z nim i muszę powiedzieć, że bardzo ważne jest zrozumienie opinii drugiej osoby w takiej sytuacji i kontrola nad własnym ego, bardzo mi to pomogło i dobrze sobie radzimy z naszym profesjonalistą zobowiązania oraz osobisty poziom przyjaźni.

Ponieważ oświadczyłeś, że jesteś jedynym testerem w środowisku Agile (zakładając, że Scrum), być może wykorzystasz spotkanie retrospektywne jako otwarte forum do zdefiniowania procesu komunikacji.

Jak wiecie, spotkanie retrospektywne ma na celu usunięcie zmarszczek w procesie Scruma. Mogą to być takie elementy, jak pozwolenie programistom na godziny XY nieprzerwanego czasu, wysyłanie wiadomości e-mail tylko w poniedziałki i ustne przez resztę tygodnia, niezależnie od tego, co odpowiada Twojemu zespołowi; ponieważ komunikacja nigdy nie jest uniwersalna.

Jako programista doceniam testera, który wykazuje inicjatywę. Nie rysują linii ... chcą usunięcia wady; niezależnie od przyczyny. Programiści i testerzy muszą oddzielić uczucia od biznesu. Wady są częścią firmy, ponieważ w grę wchodzą ludzie. Najlepszym podejściem do rozwiązywania defektów jest wyrównany zespół, który rozwiązuje usterki w sposób całościowy. Kiedy linie zaczynają się pojawiać, a granice są układane; komunikacja się zepsuje.

Skorzystaj z codziennych spotkań stand-up. Zaangażuj się w jak największym stopniu; nie tylko z testowaniem, ale z całym produktem. Na koniec programista i tester pracują nad jednym celem i zawsze powinni go koncentrować.

Wolę widzieć testerów jako część tego samego zespołu. W tym względzie nie ma kwestii komunikacji.

Ilekroć tester musi porozmawiać z deweloperem lub na odwrót, po prostu przyjdź i porozmawiajmy. Rutynowa codzienność.

Obie strony muszą się jednak szanować i właściwie wykonywać swoją pracę.

Testerzy muszą podać szczegółowe informacje na temat warunków błędu i nie zgłaszać czegoś jako błędu, dopóki jest to zgodne z projektem. Zwłaszcza, gdy wystarczy zapytać faceta o coś, co podejrzanie wygląda jak funkcja.

Programiści muszą poważnie potraktować zgłoszenie błędu i zbadać go nie tylko po prostu zamknąć problem, jeśli błąd nie zostanie odtworzony za pomocą pięciu kliknięć.

Wystarczy profesjonalne podejście.

Narzędzie numer 1, które znalazłem, jako tester (SDET), mogę wykorzystać do polepszenia relacji między testami a programistami, to uczciwe pochlebstwo, szczególnie w postaci poszukiwania mentora od deweloperów.

Mam nadzieję, że programiści, z którymi współpracuję, są lepszymi programistami niż ja. Nie są idealne, inaczej nie miałbym pracy, ale jest wiele rzeczy, które wiedzą lepiej niż ja. Były czystym rozwojem, podczas gdy moja uwaga jest częściowo skoncentrowana na testowaniu. Zauważam te rzeczy, które robią lepiej, i często o nich wspominam. Kiedy czytam ich kod, zauważam eleganckie detale lub zgrabne wykorzystanie wzorów i rozmawiam z nimi. Naśladuję programistów, w miarę możliwości wykorzystując podobne konwencje kodowania i integrując komponenty z produkcji z moimi narzędziami testowymi (np. Rejestrowanie). Doceniam ich wiedzę fachową i dlatego cieszą się z uznania. Pamiętaj, że jeśli myślę, że jest lepszy sposób, to absolutnie mówię głośno - ale staram się przekazywać więcej pozytywnych opinii niż negatywnych, ogólnie. Generalnie staram się, aby negatywne opinie były bardziej formalne i bezosobowe (np. Zgłoszenia błędów), a pozytywne były mniej formalne i bardziej osobiste (np. Rozmowy osobiście).

Udzielanie pozytywnych informacji zwrotnych na temat jakości, a także negatywnych opinii i proszenie o poradę zmienia stosunek z kontrowersyjnego do pracy zespołowej i wzajemnego uczenia się oraz obniża obronność. Programiści wiedzą, że mogą mi zaufać, że zawsze będą mówić więcej dobrych niż złych rzeczy, więc czują się swobodnie, słuchając mnie. Również zadawanie wnikliwych pytań na temat rozwoju podnosi ich opinię o mnie i przełamuje stereotyp „SDET są nieudanymi twórcami” (tam, gdzie nadal istnieje).

Mocno wierzę, że dobra komunikacja między programistami i testerami ma kluczowe znaczenie. Jeśli chodzi o najlepszy sposób, jestem pewien, że istnieje wiele dobrych podejść, ale oto, co zadziałało najlepiej dla mnie.

Komunikacja bezpośrednia / osobista! Odkryłem, że komunikacja osobista, a nie e-mailowa, zawsze działa najlepiej. Pozwala deweloperowi i testerowi nawiązać osobistą relację. Gdy już to osiągniesz, wydaje się, że wszystko działa lepiej i zwykle płynie. Nigdy nie mają problemów z przeprowadzeniem specjalnego testu lub przejechaniem dodatkowej mile za Ciebie. To samo dotyczy programisty i zawsze poświęcam dodatkowy czas, aby przyjrzeć się rzeczom, w których potrzebują pomocy lub z którymi mają problem. Z mojego doświadczenia wynika, że ​​rozwiązywanie problemów przebiega szybciej, jest mniej zmarnowanego czasu.