Czy programista powinien również działać jako tester? [Zamknięte]


60

Jesteśmy zespołem scrum złożonym z 3 programistów, 1 projektanta, mistrza scrum i właściciela produktu. Jednak nie mamy oficjalnego testera w naszym zespole. Problem, który zawsze jest z nami, polega na tym, że testowanie aplikacji, przekazywanie testów i usuwanie błędów zostało zdefiniowane jako jedno z kryteriów uznania PBI (Product Backlog Item) za wykonane.

Problem polega jednak na tym, że bez względu na to, jak bardzo my (3 programistów i 1 projektant) próbujemy przetestować aplikację i zaimplementowane przypadki użycia, nadal niektóre błędy nie są widoczne i rujnują naszą prezentację ( prawo Murphy'ego ) interesariuszom.

Aby temu zaradzić, zalecamy zatrudnienie nowego testera w firmie. Ktoś, kto ma pracę, będzie testować i tylko testować. Oficjalny profesjonalny tester.

Problem polega jednak na tym, że scrum master i interesariusze uważają, że programista (lub projektant) powinien być również testerem.

Czy oni mają rację? Czy my, programiści (także projektanci), powinniśmy też być testerami?


1
Możliwy duplikat programmers.stackexchange.com/questions/100637/… , chociaż ten jest zadawany z przeciwnego punktu widzenia.
Adam Lear

W zespole scrum, w którym pracowałem, wszyscy testowali aplikację na smartfony lub tablety i wszyscy byli świetną pomocą.
ott--

Pisarze potrzebują edytora.
JeffO,

Odpowiedzi:


59

Ex ante: Wydaje się, że istnieje wiele zamieszania w kwestii tego, co uważa się za testowanie tego, co nie jest. Jasne, każdy programista musi przetestować swój kod podczas jego tworzenia, musi zweryfikować, czy działa. Nie może przekazać go testerowi, zanim uzna, że ​​jest to zrobione i wystarczająco dobre. Ale programiści nie widzą wszystkiego. Mogą nie rozpoznawać błędów. Te błędy można znaleźć dopiero w późniejszym etapie cyklu programowania, gdy przeprowadzane są dokładne testy. Pytanie brzmi, czy programiści powinni przeprowadzić tego rodzaju testy, czy nie, i moim skromnym zdaniem należy na to spojrzeć z punktu widzenia kierownika projektu:

Programiści mogą być testerami, ale nie powinni być testerami . Programiści zwykle mimowolnie / nieświadomie unikają korzystania z aplikacji w sposób, który mógłby ją uszkodzić. To dlatego, że to napisali i przeważnie testują, w jaki sposób należy go używać.

Z drugiej strony dobry tester próbuje torturować aplikację. Jego / jej głównym celem jest złamanie go. Często używają aplikacji w sposób, jakiego nie wyobrażali sobie programiści. Są bliżej użytkowników niż programistów i często mają inne podejście do testowania przepływu pracy.

Używanie programistów jako testerów zwiększa koszty programowania i nie wpływa na jakość produktu tak bardzo, jak posiadanie dedykowanego testera. Nie pozwoliłbym programistom testować swoich prac, kiedy mogę to zrobić lepiej przez testera za tanie. Tylko jeśli pętla sprzężenia zwrotnego między programistami a testerami stanie się zbyt droga, chciałbym, aby programiści sprawdzali kod drugiej strony, ale z mojego doświadczenia wynika, że ​​tak rzadko jest i zależy to w dużej mierze od procesu.

To nie znaczy, że programista powinien być niechlujny i pozostawić wszystko testerowi. Oprogramowanie należy wykonać za pomocą testów jednostkowych, a błędy techniczne należy ograniczyć do minimum przed przekazaniem oprogramowania testerowi. Mimo to czasami naprawiasz tutaj, łamiesz problemy lub inne błędy, których żaden programista nie mógł przewidzieć, to w porządku. Ponadto testy integracyjne powinny być wykonywane głównie przez programistów. Głównym celem testera jest sprawdzenie, czy wymagania są spełnione.

W tak małym zespole (a także w zależności od wielkości aplikacji) widzę też testera w roli hybrydowej, pisząc testy jednostkowe i testy interfejsu użytkownika. Zdecydowanie powinieneś go zatrudnić .

Ale ważniejsze od testera są regularne zamrażanie / odgałęzienia. Nie prezentuj niczego, co nie zostało odpowiednio przetestowane. Gdy dodasz funkcję lub coś zmienisz, wszystko, co ją otacza, musi zostać ponownie zweryfikowane. Otrzymasz złą reputację tylko wtedy, gdy Twoja firma tego nie zrobi. Nie uwalniaj czegoś niestabilnego. Gdy klient chce mieć oprogramowanie w określonym terminie, przestań je programować wystarczająco wcześnie i przetestuj odpowiednio, aby mieć wystarczająco dużo czasu na usunięcie błędów. Często lepiej jest odrzucić prośby o funkcje w ostatniej chwili, niż źle je zaimplementować lub zwolnić bez odpowiedniego testowania.


9
Zdecydowanie i gwałtownie się nie zgadzam ... Programiści mogą być bardzo skutecznymi testerami, ale twórca funkcji NIE powinien być również testerem tej samej funkcji. Wiele małych zespołów gra obie role, w których trzy osoby pracują nad trzema różnymi funkcjami, a następnie przekazują testowanie jednemu z pozostałych trzech programistów. Działa wyjątkowo dobrze, gdy zespół nie ma testera jakości.
wałek klonowy

5
@maple_shaft: Imho nie ma usprawiedliwienia dla braku testera. Każdy projekt zapewni wyższą jakość dzięki dedykowanemu testerowi, a programiści mogą się na nim skupić, dobrze rozwijając się, jeśli taki istnieje. Posiadanie przez programistów sprawdzania siebie nawzajem kodu jest prowizorycznym rozwiązaniem, nawet dla małych zespołów imho. Powinieneś także przeczytać artykuł Joela na ten temat.
Falcon,

3
Programiści mogą być testerami - a dobry programista zna wiele miejsc, w których kod może być słaby i ulegać uszkodzeniu. Po prostu ludzie nigdy nie testują kodu, który zaprojektowali lub napisali - to bezużyteczne. Kod innej osoby może być w porządku.
StasM,

4
@deadalnix: Naprawdę zastanawia mnie, dlaczego ludzie głosują, nawet nie czytając i nie rozumiejąc mojej odpowiedzi. Cytując siebie: „Oprogramowanie powinno zostać poparte testami jednostkowymi, a błędy techniczne powinny zostać zredukowane do minimum przed przekazaniem oprogramowania testerowi”.
Falcon

2
„Z drugiej strony dobry tester stara się torturować aplikację. Jego głównym celem jest jej złamanie”. - Całkowicie się nie zgadzam. Mam tester, który nieustannie próbuje zmiksować klawiaturę lub przepełnić pola. Jasne, to są błędy, ale faktura 1 bilion bilionów dolarów, która generuje błąd, jest tak niska na mojej liście spraw, że nie mogę się zarejestrować. GREAT tester sprawdza wszystkie scenariusze, które różni użytkownicy będą korzystać z aplikacji. Dobry programista zapewnia, że ​​wszystkie ścieżki kodu zostały przetestowane, a aplikacja działa zgodnie z przeznaczeniem.
Paul,

42

Programiści mogą być testerami - kodu innych programistów.

Ale testowanie własnego kodu nie jest dobrym posunięciem - programiści często mają mentalne bloki na temat własnego kodu, dlatego mają trudności z zaprojektowaniem kompleksowych lub odpowiednich testów.

Zawsze znajdą się programiści, którzy myślą, że robią to dobrze, ale zwykle nie robią tego (i na pewno wiem, że mam wiele martwych punktów).

Jeśli NAPRAWDĘ NIE MOŻESZ wynająć testera, poproś programistów, aby przetestowali się nawzajem - to znaczy, jeśli A napisze kod i przeprowadzi testy jednostkowe, to poproś B, aby przejrzał te testy jednostkowe i sprawdził, czy mogą być dodane inne rzeczy . Poproś B, aby spróbował przetestować kod (jako użytkownik) i zgłosić usterki.

To nie jest idealne, ale lepsze niż jeden programista próbujący zrobić wszystko.

Czasami twoi koledzy potrafią być naprawdę dobrzy w łamaniu oprogramowania, ponieważ czerpią z tego przyjemność i nie przejmują się tak bardzo - ponieważ nie jest to ICH kod.


2
Och tak, jasne. Całkowicie się zgadzam. Po prostu, gdy nie możesz uzyskać 100% tego, czego chcesz, być może będziesz musiał zadowolić się mniejszym kosztem. Wiesz, że mniej nie jest tak dobre, ale lepsze niż nic.
szybko_nie

4
Ogólnie zgadzam się z testami krzyżowymi, ale w niektórych zespołach, które wprowadzą konflikty. Niektórzy ludzie lubią obwiniać innych („moje rzeczy działają, twoje nie, lol, jestem o wiele lepszy od ciebie”) i to jest niedopuszczalne. Byłem tego świadkiem wiele razy. Test krzyżowy powinien być wykonywany tylko między kolegami, którzy szanują się nawzajem. W moim zespole przedstawiłem bezimiennego programistę, którego obwinia się za każdy błąd, aby uniknąć utraty twarzy. Błędy są bezimienne, zdarzają się.
Falcon,

5
+1 nie można poprawnie przetestować własnego kodu. To niesamowite, jakie sztuczki umysł może na tobie zagrać - będziesz w 100% pewien, że zakodowałeś i przetestowałeś jakąś funkcję, a ktoś inny pokaże ci, że tak naprawdę nie działa, z wyjątkiem bardzo wąskich przypadków i być dla ciebie oczywistym raz pokazanym - ale sam nigdy tego nie zobaczysz. Umysł używa skrótów poznawczych, a podczas testowania uniemożliwiają osobie, która zaprojektowała i opracowała kod, prawidłowe przetestowanie go.
StasM,

2
@StasM - zgodził się, z jedną małą kwalifikacją: odkryłem, że wracając do mojego własnego kodu miesiące później, widzę błędy i mogę lepiej wykonać obiektywne testowanie. Ale przetestowanie własnych po napisaniu jest naprawdę bardzo trudne.
szybko_nie

1
@Ben Aston: Deweloper powinien nadal przeprowadzać testy jednostkowe, testy integracyjne itp. Nie tylko. Martwe punkty nie znikną tylko dlatego, że tego chcesz.
Szybko_nie

11

Czy dziennikarz powinien raczej pisać poprawnie? Chodzi mi o to, że zadaniem korektorów i redaktorów jest znalezienie wszystkich błędów gramatycznych.

Niemniej dziennikarze sami sprawdzają pisownię. Niemniej korektor to osobny i ważny zawód.

To samo dotyczy programistów i testerów, z tym wyjątkiem, że kontrola jakości jest jeszcze ważniejszą częścią rozwoju. Nawet jeśli jesteś dobrym programistą, po prostu nie masz czasu na dokładne przetestowanie wszystkich przypadków testowych, aby uwzględnić wszystkie środowiska, przeglądarki i systemy operacyjne obsługiwane przez Twój produkt.

Jeśli oprócz rozwijania się, ciągłego wykonywania tej pracy, oznacza to po prostu prosty fakt - jest on testerem w niepełnym wymiarze godzin.


10

bez względu na to, jak bardzo my (3 programistów i 1 projektant) próbujemy przetestować aplikację i zaimplementowane przypadki użycia, nadal niektóre błędy nie są widoczne i rujnują naszą prezentację ... interesariuszom.

Rozważ wykonanie „kontrolowanego biegu” dla sprintu lub dwóch, osobne śledzenie programisty i testowanie. Pod koniec takiego przebiegu przeanalizuj zebrane dane, aby dowiedzieć się, ile wysiłku poświęcasz na testowanie.

Jeśli dowiesz się, że testowanie wymaga dużo wysiłku, przekaż te dane do zarządzania - będą to przekonujące dowody potwierdzające twoje żądanie (znacznie bardziej przekonujące niż teraz).

W przeciwnym razie (jeśli okaże się, że testowanie zajmuje niewiele czasu), zastanów się nad zainwestowaniem dodatkowego wysiłku, aby to zrobić lepiej (lub naucz się tego robić). Negocjuj dodatkowy wysiłek, który planujesz z kierownictwem - ponieważ mogą oni wolą zatrudnić testera. :)


... zalecamy, aby firma zatrudniła nowego testera. Ktoś, kto ma pracę, będzie testować i tylko testować. Oficjalny profesjonalny tester.

Problem polega jednak na tym, że scrum master i interesariusze uważają, że programista (lub projektant) powinien być również testerem.

Muszę przyznać, że zarządzanie twoją firmą wygląda dla mnie raczej kiepsko. Mam na myśli - ok, może być naprawdę trudno dowiedzieć się, ilu testerów byłoby najlepszych dla projektu, dobrze.

Ale posiadanie co najmniej jednego testera to tylko bezpieczny zakład - naprawdę zabawne, że wahają się spróbować, a jednocześnie twierdzą, że są scrum / zwinne .


9

Cóż, mieliśmy dwóch programistów, którzy przeprowadzili test krzyżowy po tym, jak pierwszy wprowadził pewne zmiany w ekranie głównym. To wtedy nasz regularny tester był na urlopie macierzyńskim.

Zasadniczo zmienił ekran z listą faktur, za pomocą którego użytkownicy wybierali faktury przed powiększeniem w celu dokonania edycji za pomocą przycisku „Edytuj”. Oryginalna lista została wyrzucona i dodano nowy widok siatki, z filtrowaniem, grupowaniem, sortowaniem i wszystkimi fajnymi funkcjami.

Testy przebiegły świetnie i następnego dnia przesłano zmiany do klienta. Dwa tygodnie później klient dzwoni i mówi: „Naprawdę podoba nam się nowa rzecz, którą włożyłeś, teraz widzimy różnego rodzaju informacje. Ale ... eee ..... gdzie teraz edytujemy faktury? ??

Okazuje się, że programista wyjął pole wyboru (do wyboru) i przycisk edycji, a ponieważ programiści i tak zawsze klikali dwukrotnie, aby wybrać element, żaden z nich nie znalazł z nim nic złego ......

Deweloperzy i użytkownicy żyją w różnych światach, testowanie krzyżowe jest lepsze niż testowanie własnej pracy przez programistę, ale to wciąż nie to samo.


3
Nie powiedziałbym, że „żyją w różnych światach”, ale ludzie mają nawyki i kod programisty zadziała, jeśli będzie używany przez kogoś o tym samym nawyku. Nie mogę policzyć, jak często nie mogłem odtworzyć błędu znalezionego przez testera, obejrzałem się przez ramię, podczas gdy on odtworzył błąd i powiedział: „wow, nigdy bym nie zrobił tego, co właśnie zrobiłeś”.
gnasher729

4

Jak powiedzieli inni tutaj, programiści mogą testować nawzajem swój kod (testy jednostkowe lub funkcjonalne), i być może twój scrum master i właściciel produktu mogą pomóc w testach integracyjnych, ale w przypadku testów akceptacyjnych użytkownika powinieneś upewnić się, że otrzymujesz wiele informacji zwrotnych z testów przeprowadzonych przez klienta - co oznacza częste wdrożenia , z którymi mogą współpracować w sposób, w jaki robią to prawdziwi użytkownicy i naprawdę otwarty kanał komunikacyjny .


2

Powinieneś projektować z myślą o testowaniu, ale jeśli nie masz dedykowanego testera, niektóre rzeczy po prostu prześlizgną się przez pęknięcia, ponieważ w ciągu dnia nie ma wystarczającej liczby godzin na zaprojektowanie, wdrożenie i przetestowanie oprogramowania.


2

Testowanie oprogramowania to profesjonalna praca na pełny etat. Potrzebuje dobrego mózgu, talentu i dużego doświadczenia, aby zostać dobrym testerem. Śmiesznie jest założyć, że twórca oprogramowania, bez względu na to, jak sprytny, może zbliżyć się do profesjonalnego testera, gdy testowanie to tylko niewielki element jego codziennej pracy.

Do tego dochodzi problem, że podświadomie twórca oprogramowania nie chce znaleźć błędów.


1

Zgadzam się z ich twierdzeniem, że programiści / projektanci powinni przetestować swój kod, z zastrzeżeniem, że projektant / programista, który napisał sekcję kodu, nie będzie jedynym zestawem „oczu” na tym kodzie, zanim zdecyduje się żyć. Chociaż to nie wszystko złapie, pomoże przynajmniej uniknąć ślepoty, która wkrada się podczas testowania i ponownego testowania własnego kodu podczas programowania.

Ze wspomnianego przypadku użycia założę, że używasz również narzędzi do pokrywania kodu? Jeśli nie, może pomóc zobaczyć, który kod może nie zostać przetestowany, i może napotkać nieoczekiwane błędy w określonych warunkach.

Biorąc to pod uwagę, jeśli jest wystarczająco dużo pracy lub Twoja organizacja ma przyzwoity rozmiar, zgodziłbym się, że potrzebna jest profesjonalna osoba do kontroli jakości, pomogłaby bardziej skoncentrować się na rolach wszystkich osób, a także mogła zobaczyć, czy istnieją jakieś wzorce co do tego, co jest pomijany, a co ważniejsze, jak to naprawić.

Korzystając z naszej strony potwierdzasz, że przeczytałeś(-aś) i rozumiesz nasze zasady używania plików cookie i zasady ochrony prywatności.
Licensed under cc by-sa 3.0 with attribution required.