Dlaczego testerzy i programiści się nie lubią? [Zamknięte]

Podczas mojej kariery programisty widziałem różnych programistów i testerów, a wielu z nich się nie lubiło. To znaczy, programiści uważają, że praca testera nie jest „prawdziwą” pracą, a testerzy uważają, że programiści są zbyt „dumni”.

Czy to moja właściwa decyzja, dlaczego tak jest i co możemy zrobić, aby uniknąć tego rodzaju problemów?

Myślę, że to rażące nad generalizacją i nad uproszczeniem.

Obecnie jestem testerem, piszę prawie tyle samo kodu, co napisałem jako programista (zależy od fazy testowej), a moim najlepszym przyjacielem w firmie jest programista i wszyscy się dogadujemy.

Możesz spojrzeć na kulturę korporacyjną i sposób, w jaki zespoły pracują względem siebie, aby znaleźć odpowiedź. Z mojego doświadczenia wynika, że ​​jeśli masz bardzo reakcyjne przepływy pracy (np. Devs „rzuca kompilację nad ścianą w celu przetestowania” i testowania „odrzuca błędy”) zamiast pracować razem , tylko z różnych punktów skupienia lub „wektorów ataku”, wtedy „ Przekonam się, że oba wydziały w ogóle się nie lubią.

Tam, gdzie pracuję, każdy zespół ds. Funkcji lub zespół projektowy ma prawie tyle samo testerów, co programistów pracujących razem, aby uzyskać efekt. Ten wynik jest kodem produkcyjnym, który spełnia wymagania określone przez kod testowy.

edytować

Zauważ też, że myślę, że ciężar testera spoczywa na testerze bardziej niż na deweloperach, aby wspierać relacje między nimi.

O wiele łatwiej jest nam ulepszyć lub pogorszyć życie programistów, ale celem nie jest po prostu „znalezienie błędów”, ale także znalezienie potencjalnych rozwiązań. Jeśli nie mogę, to nie mogę i będę pracować z każdym, kto w tym momencie zostanie przypisany do błędu , aby znaleźć rozwiązanie. Ale jeśli jest to proste rozwiązanie, przedstawię potencjalną poprawkę, która spełniłaby różne wymagania i test regresji, który napiszę.

Ja kocham moje testerów - pomagają mi rozwiązywać problemy i dostrzec rzeczy, które nie będę myśleć jako problem, ale nasi klienci. I najważniejsze dla mnie, pomagają mi upewnić się, że nie zabiję nikogo ze złym kodem.

Dlaczego pojawiają się problemy?

• Ciągle oceniacie siebie nawzajem, a niektórzy ludzie nie mogą przyjąć żadnej krytyki
• Wykonanie złej pracy marnuje czas przeciwnika
• Obaj jesteście jednocześnie pod presją tej samej rzeczy i nikt nie chce być tym, który trzyma rzeczy

Połączenie powyższego z charakterem pozycji oznacza, że ​​naprawdę łatwo jest pozbyć się swoich obecnych gniewów i frustracji, jeśli wpadniesz w tę pułapkę, przestaniesz ze sobą współpracować i zaczniesz działać przeciwko sobie. Trudno się z tego wydostać i nie jest to dobre dla nikogo.

Wydaje mi się, że dzieje się tak, ponieważ programiści tworzą program, a oni postrzegają, że testerzy następnie próbują znaleźć w nim wady (nawet jeśli testery faktycznie są częścią ulepszania produktu końcowego). Ilekroć ktoś znajdzie wady w czymś, w co wkładasz wiele wysiłku, prawdopodobnie naturalną reakcją jest zareagowanie na nie negatywnie.

Sposobami na złagodzenie tego problemu byłoby skłonienie programistów i testerów do postrzegania gotowego produktu jako wyników całego zespołu (w tym testerów ORAZ programistów) i uświadomienia im, że testowanie nie jest samodzielną misją polegającą na wykrywaniu błędów, ale ważną częścią rozwój proces. A jeśli programiści nie sądzą, że testowanie jest prawdziwym zadaniem lub że jest to łatwe, poproś o napisanie matryc testowych, wykonanie setek przypadków testowych, udokumentowanie każdego kroku i każdego wyniku.

Znam konkretnych programistów i testerów, którzy się nie lubią, ale nie z podanych przez ciebie powodów, ale raczej dlatego, że pracują dla siebie nawzajem.

Taka jest natura bestii. Niektórzy z konkretnych testerów, których znam, którzy nie dbali o konkretnych programistów, ponieważ uważali, że ich kod jest podatny na błędy z powodu niedbalstwa / lenistwa / itp. Niektórzy ze znanych mi programistów, którzy nie dbali o konkretnych testerów, uważali, że stosowali absurdalnie wymyślone warunki testowe (wybieranie nitów) lub prosili o poprawki do kodu w oparciu o styl.

Myślę, że unikanie osobowości i skupienie się na zadaniu ma długą drogę do zmniejszenia napięć. Jeśli organizacja jest wystarczająco duża, testowanie metodą podwójnie ślepej próby jest świetnym pomysłem.

Tester, który potrafi jasno wyrażać problemy, oraz koderzy, którzy wyraźnie wdrażają rozwiązania, stanowią świetny zespół.

W zespołach, w których ściśle współpracowałem z testerami, świetnie się dogadywaliśmy. Testerzy rozumieją decyzje podejmowane w związku z różnymi podejmowanymi decyzjami, wiedzą, jak wyglądają harmonogramy deweloperów i między dwiema grupami budowane są relacje.

W zespołach, w których test jest jakimś amorficznym bytem na morzu, tak nie było. Wyniki testerów są mniej istotne, ponieważ nie wiedzą zbyt wiele o tym, co się dzieje, twórcy zaczynają bać się zalewu tego, co uważają za nieistotne szczegóły, które są w częściach programu, które nie zostały dotknięte w dwóch miesięcy zespół testowy denerwuje się, że żadne zgłoszone błędy nie zostały naprawione (ponieważ harmonogram jest spieprzony, a deweloperzy są zajęci przygotowywaniem demonstracji lub dodawaniem żądanych funkcji itp.) i ogólnie obie grupy postrzegają się jako antagonistyczne „inni” w przeciwieństwie do członków zespołu.

Pracujcie ściśle, a wszystko będzie dobrze. Ktoś musi upewnić się, że oba zespoły są koordynowane i znajdują się na tej samej stronie. Moje najlepsze doświadczenie, zespół testowy został zaproszony na każde spotkanie wysokiego szczebla, na które został zaproszony zespół programistów (wszyscy) i wszyscy znaliśmy harmonogram, mieliśmy zunifikowaną listę priorytetów, a zarówno projektanci, jak i test mieli takie same (w górę- aktualny) dokument wymagań. Moje najgorsze doświadczenie (inne niż brak testu) w zasadzie spakowaliśmy nasze rzeczy, wysłaliśmy je za granicę, aby je obejrzeć, a następnie odzyskaliśmy wszystko miesiąc później z rzeczami oznaczonymi jako złe, które nawet nie były nasze (wtyczka innej firmy, która spełniła nowe wymagania, ale nie oczekiwania zespołu testowego).

Ani programista, ani test nie odniesie sukcesu bez drugiego. Jeśli pracujesz jak dwie połówki tej samej maszyny i szanujesz drugą stronę, tak samo jak szanujesz swoich najbliższych członków zespołu, wszystko będzie dobrze. Zachowuj się jak dwie osobne maszyny i załóż, że twoja maszyna jest lepsza, wszystko będzie okropne.

Kiedy programiści i testerzy się nie lubią, często dzieje się tak dlatego, że błędnie wyobrażają sobie, że ich cele są sprzeczne.

Odkryłem, że problemy te są znacznie złagodzone, gdy testerzy i programiści pracują w tym samym zespole, zamiast „zespołu testowego” i „zespołu programistycznego”. Myślę, że właśnie dlatego, jako tester, zdecydowanie wolę pracować w zespołach Agile, niż tworzyć wodospady. Komunikacja jest większa, zwrot jest szybszy, a programiści bardziej doceniają czas i talent, które trzeba poświęcić na testowanie, gdy praca jest bardziej przejrzysta.

Indywidualnie można również wiele zrobić. Jako tester stwierdzam, że jestem w stanie zmniejszyć to tarcie, zapewniając pozytywne opinie, a także znajdując błędy. Muszę jeszcze przetestować programistę, który nie mógłby mnie wiele nauczyć , a deweloperzy doceniają testera, który naprawdę rozumie kod. Deweloperzy są dumni, jak każdy dobry rzemieślnik. Ważne jest, aby poinformować ich, że posiadanie błędów nie czyni ich mniej godnymi podziwu

Deweloperzy uważam za najłatwiejszy do pracy z docenianą dobrą jakością i zademonstrowali to, starając się napisać kod wysokiej jakości, zanim tester go zobaczył, w tym wykonując testy wstępne (głównie automatyczne testy jednostkowe i ręczne testy dymu). Deweloperzy poprosili również test o wykonanie przeglądu kodu pod kątem testowalności i włączyli testery do procesu tak szybko, jak to możliwe, w tym o przedstawienie im projektów wcześniej (co pozwala testerom na wcześniejsze planowanie strategii testowych, gdy test ma mniejsze obciążenie). Programiści mogą pomóc testerom znaleźć słabe obszary w kodzie, informując ich, które obszary zostały opracowane w pośpiechu, lub które obszary były trudne do przetestowania jednostkowego. Ogólnie rzecz biorąc, wszystko, co programiści mogą zrobić, aby ułatwić pracę testerowi, jest doceniane i pokazuje, że cenią czas testera, jak i własny. Gdy programiści to robią,

Innym problemem jest to, że wiele firm często myśli o jakości. Wiele razy mówi się o projektach w ostatniej chwili i jest rażąco za mało personelu w porównaniu do zespołu programistów. W niektórych miejscach ścieżką do programisty jest wsparcie techniczne, kontrola jakości, a następnie programista. Czasami więc jest obsadzona ludźmi, którzy chcieliby być programistami ... A kiedy znajdą usterkę, ich postawa jest taka, jak ta osoba może być programistą, a nie ja, nigdy nie popełniłbym takiego błędu itp.

Ogólnie chciałbym zespół QA. Również uważam, że testowanie jednostkowe powinno być niezbędną częścią rozwoju oprogramowania, oddzieloną od kontroli jakości. W związku z tym, gdy QA znajduje błędy, testy jednostkowe są zmieniane, aby to sprawdzić. Dodatkowo myślę, że programiści, którzy przeprowadzają testy jednostkowe, mogą lepiej zrozumieć, co znajduje QA.

Ponadto wiele zespołów kontroli jakości musi robić rzeczy ręcznie, w takim przypadku jest to NAPRAWDĘ nudne zadanie. W niektórych miejscach QA pisze skrypty i korzysta z programów automatyzacyjnych, które pozwalają nawet na tworzenie skryptów GUI (poprzez pewnego rodzaju rozpoznawanie obrazu na ekranie dla przycisków / itp.). Potem jest ciężko, gdy na początku zdarzają się poważne zmiany, ale potem wszystko jest zautomatyzowane i wydaje się przyjemniejsze ...

Również niektórzy programiści patrzą z góry na jakość. Nadal wolałbym, aby QA znalazła wadę niż klient ...

Uwielbiamy naszych testerów, ale wielu z nas pamięta, jak to było, zanim je mieliśmy. O wiele lepiej jest, aby testerzy znaleźli problemy, niż gdyby klient znalazł je po przejściu do produkcji. Nie ma żywego programisty, który nie stworzył błędu lub źle zinterpretował wymaganie.

Kluczem jest traktowanie wszystkich profesjonalistów z uprzejmością i szacunkiem, niezależnie od tego, czy robią to, co robisz, czy nie. Kiedy zaczniesz myśleć, że Twoja praca jest lepsza lub ważniejsza niż ich, wtedy przegrywasz.

W oparciu o to pytanie: techniki testowania oprogramowania lub kategorie Podejrzewam, że potrzebujesz dostosowania nastawienia do testerów i ogólnie testów.

Jako programista doświadczyłem swojego napięcia w testerach.

W jednym zadaniu testerzy rzadko testują „właściwą rzecz”. Wdrożyłbym nową funkcję dla serwera naszego produktu, a testerzy zgłaszali całą masę błędów dotyczących interfejsu użytkownika. Ponieważ w tym produkcie, interfejs użytkownika został skonfigurowany nie kodowane , obecność (lub nie) z problemami w naszym UI rozwoju miał żadnego linku do tego, czy użytkownicy końcowi miałoby UI z podobnymi problemami. Testerzy wiedzieli o tym, ale nadal rejestrowali błędy dotyczące obcych obszarów.

To powiedziawszy, dobrzy testerzy są na wagę złota - w jednej chwili zamieniłbym kiepskiego programistę na dobrego testera. Dobry tester jest partnerem w dostarczaniu wysokiej jakości produktu.

Znałem także niektórych programistów, którzy traktują testerów jak wroga - tak jakby testerzy wprowadzali błędy. Ważne jest, aby programiści zdali sobie sprawę, że testerzy nigdy nie wprowadzają usterki - po prostu ją odkrywają.

Jak uniknąć tych problemów? Co powiesz na bycie dla siebie miłym? Jeden potrzebuje drugiego, aby uzyskać wysokiej jakości oprogramowanie, więc dlaczego nie uszanować tego, co każda ze stron musi zrobić, aby to osiągnąć? Dowiedz się, co robi każda ze stron, a być może docenisz pracę.

Upór po obu stronach tego, co jest poprawną interpretacją wymagania, byłby tym, w którym zwykle widziałem konflikt między programistami a testerami. Chociaż może pojawić się snobizm lub arogancja, to po prostu każda ze stron trzyma się broni i chce mieć rację.

Dobrym sposobem na uniknięcie tego problemu jest zorganizowanie przez 3 strony, programistę, testera i mediatora, analityka biznesowego lub kierownika projektu, pracy nad różnymi sprawami granicznymi. Należy rozważyć, jakie rodzaje ego mogą powstać, gdy istnieje rozbieżność między deweloperami a testerami.

Złe samopoczucie jest zwykle wynikiem złej komunikacji, co zwykle wynika z tego, że programiści i testerzy mają różne perspektywy kodu. Programista zna bity, nad którymi ściśle pracował, ale może nie wiedzieć, jak pasują do całego systemu (poza tym, co mówi mu specyfikacja). Testerzy widzą duży obraz, ale nie znają szczegółowo kodu. Grupy mogą stosować inną terminologię i procedury w odniesieniu do tych samych rzeczy.

Może to prowadzić do zgłoszenia wad w stosunku do niewłaściwego komponentu (ponieważ komponent reaguje na awarię wcześniej) lub programistów zamykających uzasadnione defekty, ponieważ nie mogą odtworzyć problemu w swoim środowisku (ponieważ tak naprawdę nie rozumieją, jak się reprodukować problem poprawnie). Jeśli tak się często zdarza, może to nadwyrężać relacje między grupami.

Potem jest radość z otrzymywania partii wad o 11 godzinie; terminy zbliża, ciśnienie przyjście na ciebie ze swoim bezpośrednim przełożonym na górę łańcucha, a otrzymasz świeżą porcję wad na problem, którego znamy już ustalone już i tak naprawdę nie chcą mieć trochę czasu, aby przejść przez proces, aby to udowodnić.

Jednym naprawdę dobrym sposobem na wkurzenie zespołu ds. Kontroli jakości jest podsumowanie kilkuset uzasadnionych, ale o niskim priorytecie usterek (głównie zgłoszonych przeciwko brzydkim lub niespójnym interfejsom użytkownika, które w przeciwnym razie byłyby funkcjonalne) z uzasadnieniem, że zaległości w defektach o wyższym priorytecie są tak duże, że „ nigdy do nich nie dojdziemy. ” Zmieniasz kolor z czerwonego na zielony w arkuszu kalkulacyjnym menedżera programu i dostajesz pełnomocnika od wyższego kierownictwa, podczas gdy zespół kontroli jakości sprawdza swoje dane za zgłoszenie wielu fałszywych błędów.

Bad juju.

Często wynika to z trzech czynników -

• Takie pytania wskazują na istnienie „folkloru” w branży, którego twórcy i testerzy się nie lubią. Ludzie starają się znaleźć aspekty, które to potwierdzają, nawet jeśli takie uczucie może nie istnieć w ich zespole.
• Niekompetentni kierownicy projektów mierzą postęp według wskaźników, takich jak liczba zarejestrowanych błędów.
• Dysfunkcyjny zespół (i brak liderów, którym zależy na tyle, aby to naprawić).

Lubię testerów, ale w dwóch przypadkach znalazłem konflikt.

1. Kiedy zarząd gra testerów i nawzajem sobie nawzajem.

2. Ciągłe przesyłanie problemów, w których brakuje szczegółów, tzn. „Ekran x nie działa”.

Myślę, że jeśli tak jest naprawdę, jest to oznaka niedojrzałości. Czasami możesz mówić o tym jako żart. Ale jeśli ty (programiści i testerzy pracujący nad tym samym projektem) nie czujesz się zespołem, wynik byłby katastrofą.

Testowanie jest bardzo ważną częścią cyklu życia oprogramowania (zwinne czy nie). Więc nie powinieneś myśleć o testerach jako o ludziach, którzy żyją, aby ci przeszkadzać w błędach, ale raczej jako kolega z zespołu, który pomaga ci dostarczać wysokiej jakości oprogramowanie.