Czy to dobrze, że testerzy rywalizują o to, kto otworzy więcej błędów?


54

Jestem programistą. Istnieje zespół testerów, którzy śledzą i wykonują przypadki testowe napisane przez analityka, ale także przeprowadzają testy eksploracyjne. Wygląda na to, że testerzy rywalizowali o to, kto otwiera więcej błędów, i zauważyłem, że jakość zgłoszeń błędów spadła. Zamiast testować funkcjonalność i zgłaszać błędy związane z działaniem oprogramowania, testerzy zgłaszali błędy dotyczące ulepszeń ekranu, użyteczności lub głupich błędów.

Czy to jest dobre dla projektu? Jeśli nie, jak mogę (jako programista) spróbować zmienić sposób myślenia i nastawienie zespołu testerów?

Innym problemem jest to, że termin jest szacowany i nie może się zmienić, więc w miarę upływu terminu testerzy będą się starali dokończyć swoje przypadki testowe, co spowoduje obniżenie jakości testów. Spowoduje to, że uzasadnione błędy znajdą się w produkcie końcowym otrzymanym przez klienta.

OBS: Ten konkurs nie jest praktyką firmy! Jest to konkurs tylko między organizowanymi przez nich testerami i bez żadnych nagród.


3
Czy testerzy są zaangażowani przed kompilacją? Czy są oni zaangażowani w opracowywanie wymagań lub przypadków użycia lub historii użytkowników, przeglądanie dokumentacji projektowej lub udział w przeglądach kodu? Czy raporty, które testerzy składają, są dobre i czy istnieją kontrole, aby upewnić się, że raporty są prawidłowe i kompletne? Jeśli mógłbyś zredagować swoje pytanie w celu dokładniejszego omówienia ról / obowiązków testerów i sposobu zarządzania ich raportami, pomogłoby mi to napisać dobrą odpowiedź.
Thomas Owens

35
Konkurencja niekoniecznie jest zła, ale w połączeniu z zachętami może mieć negatywne skutki. To pytanie przypomina mi historię z The Daily WTF, w której testerzy współpracowali z programistami, aby stworzyć dodatkowe błędy, które następnie można by heroicznie znaleźć . Zabawna lektura. Nie powtarzaj tego błędu.
amon

6
Twój punkt widzenia jest dobrze przyjęty, ale na marginesie doceniam, gdy ktoś mówi mi, że moja praca ma problemy z użytecznością. To jedna z najtrudniejszych rzeczy do zrobienia w oprogramowaniu, a także jedna z najcenniejszych, które należy mieć.
jpmc26

9
Pochodząc z projektu trwającego ponad rok ze skrupulatną kontrolą jakości, mogę powiedzieć, że chociaż wady związane z posiadaniem zbyt dużej odstępu między elementami lub różnymi kolorowymi symbolami, które oznaczają, że to samo może wydawać się bezproduktywne, ostatecznie poprawiają wrażenia użytkownika, często poprawiając wydajność, zmniejszając obciążenie pomocy technicznej i zapewniając bardziej profesjonalny wygląd aplikacji, wszystkie pożądane cechy. I tak, czasami oprogramowanie jest z tego powodu opóźnione, ale zwykle cena jest tego warta.
phyrfox

9
Wiele odpowiedzi sugeruje, że zadaniem testerów jest znajdowanie błędów; ten sposób myślenia powoduje problem, który zidentyfikowałeś. Zadaniem zapewnienia jakości jest dokładne określenie, czy produkt spełnia określony pasek jakości . Nie obchodzi mnie, czy tester generuje raporty o błędach; Dbam o to, czy tester przygotowuje dokładną, zorientowaną na klienta analizę jakości produktu. To jest rzecz, którą należy zachęcać.
Eric Lippert

Odpowiedzi:


87

Nie sądzę, że to dobrze, że robią konkurs, znajdując najwięcej błędów. Chociaż prawdą jest, że ich zadaniem jest znajdowanie błędów, ich zadaniem nie jest „znajdowanie największej liczby błędów”. Ich celem nie jest znalezienie najwięcej, ich celem jest poprawa jakości oprogramowania. Nagradzanie ich za znajdowanie kolejnych błędów jest mniej więcej tym samym, co wynagrodzenie programisty za pisanie jak największej liczby wierszy kodu, a nie kodu o najwyższej jakości.

Przekształcenie go w grę zachęca ich do skupienia się na znajdowaniu wielu płytkich błędów, a nie na poszukiwaniu najbardziej krytycznych błędów. Jak wspomniałeś w swojej edycji, dokładnie tak dzieje się w Twojej organizacji.

Można argumentować, że każdy znaleziony przez nich błąd to uczciwa gra i że wszystkie błędy muszą zostać odkryte. Biorąc jednak pod uwagę, że Twój zespół prawdopodobnie ma ograniczone zasoby, wolałbyś, aby tester koncentrował się kilka godzin lub dni na głębokim badaniu systemu, próbując znaleźć naprawdę duże błędy, lub spędził kilka godzin lub dni na pomijaniu aplikacji w poszukiwaniu błędów typograficznych i małych błędy w wyrównaniu obiektów na stronie?

Jeśli firma naprawdę chce z tego zrobić grę, daj programistom moc dodawania punktów do błędu. „głupie robaki” otrzymują punkty ujemne, ciężko znaleźć błędy z dobrze napisanymi raportami, które zdobywają wiele punktów. To przenosi motywację z „znajdź najbardziej” na „być najlepszym w wykonywaniu swojej pracy”. Nie jest to jednak zalecane, ponieważ programista i analityk ds. Kontroli jakości mogą współpracować, aby sztucznie uzupełniać swoje liczby.

Konkluzja: nie rób gry ze znalezienia błędów. Znajdź w swojej organizacji sposoby na nagradzanie dobrej pracy i na tym zostaw. Grywalizacja nagradza ludzi za osiągnięcie celu. Nie chcesz, aby analityk ds. Kontroli jakości miał na celu „znajdowanie jak największej liczby błędów”, chcesz, aby ich celem była „poprawa jakości oprogramowania”. Te dwa cele nie są takie same.


5
Pierwsza rzecz, o której pomyślałem, że jest podobna - jeśli chcą przekształcić ją w grę, byłoby lepiej, gdyby kierownik ds. Kontroli jakości (jeśli taki istnieje) ustawiał punkty za znalezione błędy, zakładając, że można zaufać osobie, która będzie w najlepszym interesie firma na uwadze. Pod tym względem może lepiej kontrolować konkurencję i, niezależnie od tego, czy postrzegasz to jako akceptowalne, czy nie, może nawet dowolnie zbliżyć się do konkurencji, przydzielając nieco wyższe lub niższe punkty ze względu na konkurencję. (w przeciwnym razie, jeśli jedna osoba uzyska przewagę dzięki testowaniu tego, co napisał nowy programista, wszyscy się
poddają

2
Mimo to nie poleciłbym tego pomysłu, ponieważ szybko się nudzi, chyba że członkowie twojego zespołu są prawie identycznie dopasowani (co się nie zdarza). Lepiej konkurować ze sobą.
DoubleDouble

1
Popierany za pomysł, że mierzenie produktywności w oparciu o liczbę znalezionych błędów jest równoważne mierzeniu produktywności programisty za pomocą wierszy napisanego kodu (lub zamkniętych punktów historii). Oba są absurdalne, ale oba pozostają w umysłach PHB, którzy nie widzą bardziej subtelnego sposobu oceny wydajności.
dodgethesteamroller

Twoja odpowiedź jest taka sama, jak myślałem. Ale punkt @DoubleDouble dotyczący identycznego poziomu testerów jest dobrym punktem do przemyślenia!
Tylko ciekawy umysł

2
Zgoda. Mimo że moja poprzednia praca związana z kontrolą jakości nie miała żadnych twardych i szybkich kwot, było kilku testerów, którzy uważali, że najważniejsze jest, aby popsuć każdy drobiazg, jaki mogli znaleźć - rzeczy takie jak „koszula postaci są za długie, większość ludzi tak robi nie nosić koszulek o takiej długości ”(gdy długość koszulki bohatera była całkowicie nieistotna dla gry), zamiast kopać w poszukiwaniu prawdziwych błędów, takich jak„ wielokrotne podłączanie / odłączanie kabla sieciowego na hoście [w grze hostowanej przez innych użytkowników] powoduje, że gra zostaje utracona przez klient i wygrana są dodawane do rekordu online hosta ”.
Doktor J

17

Nie zgadzam się trochę z innymi odpowiedziami. „Znajdowanie błędów” dla testera przypomina trochę „pisanie kodu” dla programisty. Surowa ilość jest bez znaczenia. Zadaniem testera jest znalezienie jak największej liczby błędów, które mogą, a nie znalezienie jak największej liczby błędów. Jeśli tester A znajdzie 5 z 10 błędów w komponencie wysokiej jakości, a tester B znajdzie 58 z 263 błędów w komponencie niskiej jakości, to tester A jest lepszym testerem.

Chcesz, aby programiści napisali minimalną ilość kodu, aby rozwiązać konkretny problem, i chcesz, aby tester spisał minimalną liczbę raportów poprawnie opisujących zepsute zachowanie. Konkurowanie w celu znalezienia jak największej liczby defektów jest jak konkurowanie w pisaniu jak największej liczby wierszy kodu. System jest zbyt łatwy do włożenia w system gier, aby był użyteczny.

Jeśli chcesz mieć testerów do rywalizacji, powinno to być bardziej bezpośrednie w oparciu o to, co mają zrobić, czyli sprawdzić, czy oprogramowanie działa zgodnie z opisem. Być może więc ludzie będą rywalizować o to, kto może napisać najbardziej akceptowane przypadki testowe, a nawet lepiej, napisać zestaw przypadków testowych obejmujących najwięcej kodu.

Lepszym miernikiem produktywności programistów jest liczba zadań ukończonych razy złożoność zadań. Lepszą miarą wydajności testera jest liczba wykonanych przypadków testowych razy złożoność przypadków testowych. Chcesz to zmaksymalizować, nie znaleziono błędów.


3
Zadaniem testera jest znalezienie jak największej liczby błędów, które mogą, a nie znalezienie jak największej liczby błędów. Jeśli ma być duża różnica między tymi stwierdzeniami celów testowych, to mnie to gubi.
Atsby

6
Ponieważ jeśli tester A znajdzie 5 z 10 błędów w komponencie wysokiej jakości, a tester B znajdzie 58 z 263 błędów w komponencie niskiej jakości, tester A jest lepszym testerem.
Gort the Robot

6
@ Zgadza się, jeśli pojedyncze zepsute zachowanie przejawia je w 10 różnych miejscach, to 1 zgłoszenie błędu na temat faktycznie uszkodzonej rzeczy jest znacznie lepsze niż 8 oddzielnych zgłoszeń błędów, które opisują 8 na 10 różnych objawów.
Peteris

8
@Peteris (i Steven) Oba są interesujące, ale nie są skutecznie przekazywane w cytowanym oświadczeniu Stevena .
Atsby

@Abyby W zdaniu, które cytujesz, pierwsza klauzula jest wyrażeniem względnym (znajdź największą część błędów), a druga jest bezwzględna (znajdź największą liczbę błędów). Różnica polega na powiedzeniu: napełnij to wiadro w 90% i napełnij to wiadro 1/2 galonu, gdy wiadro ma 1 galon.
dodgethesteamroller

16

Na podstawie moich osobistych doświadczeń nie jest to dobra rzecz. Prawie zawsze prowadzi to do tego, że programiści zgłaszają błędy, które są duplikatami, śmieszne lub całkowicie nieważne. Zazwyczaj wiele z nich pojawia się nagle pod koniec miesiąca / kwartału, gdy testerzy pędzą, aby spełnić kwoty. Jedyną gorszą rzeczą jest to, że karasz programistów na podstawie liczby błędów znalezionych w ich kodzie. W tym momencie zespoły testowe i programistyczne pracują przeciwko sobie i nie można odnieść sukcesu bez pogorszenia wyglądu drugiego.

Tutaj musisz skupić się na użytkowniku. Użytkownik nie ma pojęcia, ile błędów zgłoszono podczas testowania, wszystko, co widzą, to ten, który przeszedł. Użytkownicy ostatecznie nie dbają o to, czy złożysz 20 raportów o błędach lub 20 000, o ile oprogramowanie działa, gdy je otrzymają. Lepszym miernikiem do oceny testerów byłaby liczba błędów, które zostały zgłoszone przez użytkowników, ale powinny one zostać złapane przez testerów.

Jest to jednak o wiele trudniejsze do śledzenia. Dość łatwo jest uruchomić zapytanie do bazy danych, aby zobaczyć, ile raportów o błędach zostało zgłoszonych przez konkretną osobę, co, jak podejrzewam, jest głównym powodem, dla którego tak wiele osób używa metryki „zgłoszenia błędów”.


+1, ale jedynym problemem związanym z twoimi lepszymi parametrami jest to, że zachęca to do nie ulepszania systemu zgłaszania błędów użytkownika ... Pomysł jest słuszny, ale być może powinny to być bardziej ogólne „błędy znalezione poza oficjalnym procesem testowania”
user56reinstatemonica8

@ user568458 - Zakładałem, że dana organizacja miała różne zespoły ds. wewnętrznej kontroli jakości i wsparcia klienta i że to pytanie dotyczyło wyłącznie wewnętrznej kontroli jakości. Jeśli oba są tym samym zespołem, rzeczywiście będziesz miał konflikt interesów (czy to przy użyciu mojej metody, czy nie).
bta

6

Nie ma nic złego w tworzeniu gry w poszukiwaniu błędów. Znalazłeś sposób na motywowanie ludzi. To jest dobre. Ujawniono również brak komunikacji w zakresie priorytetów. Zakończenie konkursu byłoby marnotrawstwem. Musisz poprawić priorytety.

Niewiele prawdziwych gier ma prosty system punktacji. Dlaczego błąd powinien polować?

Zamiast oceniać grę po prostu liczbą błędów, musisz podać miarę jakości raportów o błędach. Wtedy w konkursie chodzi o mniej błędów. Będzie bardziej jak zawody wędkarskie. Wszyscy będą chcieli znaleźć duży błąd, który uzyska wysoki priorytet. Ustaw jakość raportu o błędzie jako część wyniku. Poproś programistów o przekazanie testerom informacji zwrotnych na temat jakości zgłoszenia błędu.

Dopasowanie balansu gier nie jest prostym zadaniem, więc przygotuj się na trochę czasu. Powinien jasno przedstawiać twoje cele i powinna być świetną zabawą. Będzie to również coś, co można dostosować do zmieniających się potrzeb biznesowych.


5

Znalezienie błędów to ich praca. Dopóki nie zmniejszają wydajności (na przykład otwierając błąd dla echa 10 liter zamiast jednego, aby pokryć kilka z nich), zachęca ich to do robienia dokładnie tego, co powinni robić, więc Nie widzę wiele wad.


Nie można zgodzić się więcej z Moot. Oczywiście ludzie mogliby zrobić coś głupiego (zapisać 100 literówek itp.) - ale „ludzie mogą zrobić coś głupiego”, stosując się do jakiegokolwiek schematu.
Fattie

1

To jest rozwinięcie odpowiedzi @ CandiedOrange .

Aby rozpocząć przenoszenie uwagi na bardziej przydatne cele, rozważ coś bardzo nieformalnego i nieoficjalnego. Na przykład programiści mogą kupić małe tokeny i trofea.

Każdego dnia, w którym zgłaszany był co najmniej jeden znaczący błąd, pozostaw token „Bug of the Day” na biurku testera. Raz w tygodniu organizuj ceremonię z udziałem programistów, którzy dostarczą większy i lepszy token lub trofeum „Bug of the Week”. Spraw, aby dostawa trofeum „Bug miesiąca” była jeszcze bardziej dramatyczna, być może z ciastem. Każdemu żetonowi lub trofeum powinien towarzyszyć cytat informujący, dlaczego deweloperzy uznali, że dobrze było znaleźć błąd w testowaniu. Kopie cytatów należy umieścić w miejscu, w którym wszyscy testerzy mogą je przeczytać.

Mamy nadzieję, że testerzy przeniosą swoją uwagę z znajdowania największej liczby błędów na zbieranie jak największej liczby trofeów i żetonów. Ich najlepszą strategią byłoby przeczytanie cytatów i zastanowienie się, jakie podejście do testowania może przynieść błędy, które programiści uznają za ważne.

Po prostu zignoruj ​​nieistotne zgłoszenia błędów. Ponieważ byłoby to bardzo nieoficjalne i nieformalne, można je w dowolnym momencie zamknąć lub zmienić.


Musiałbym się zgodzić. Jedno: nie rób tego o uzyskiwaniu zgody kierownictwa. Aby gra wyglądała jak gra, niezwykle ważne jest, aby testerzy czuli, że sami rozumieją zasady. Jeśli system logowania ma najwyższy priorytet, poinformuj go z góry i zwolnij go. Jeśli wady przypadków użycia o dużym natężeniu ruchu są priorytetem, a nie ukryte przypadki narożne, należy to wyjaśnić i wyjaśnić, w jaki sposób są oceniane. Po prostu posiadanie jasnych priorytetów sprawi, że będzie to zabawne i sprawi, że ludzie będą łowić ryby w odpowiedniej dziurze.
candied_orange

1

Czy to jest dobre dla projektu?

Nie . Sam zauważyłeś, że zaobserwowałeś, że skutkuje to niską jakością raportów, które nie są ukierunkowane na wymaganą funkcjonalność, i że testerzy kończą, aby pogłębić problem, starając się ukończyć pracę, którą w rzeczywistości są „przypuszczalnie „robić.

Jeśli nie, jak mogę (jako programista) spróbować zmienić sposób myślenia i nastawienie zespołu testerów?

Podnieś problem ze swoim Project Managerem. Powinni uważać tego rodzaju rzeczy za część swojej pracy. Jeśli twój PM nie chce lub nie jest w stanie sobie z tym poradzić, utknąłeś przy opracowywaniu własnych strategii radzenia sobie. (co byłoby innym pytaniem)


-1

Myślę, jak to będzie (lub jak już jest), jeśli tak będzie dalej, niekoniecznie uzyskasz niższą jakość. Chociaż myślę, że zmniejszy to stosunek ilości do jakości. To zależy, czy to źle, czy nie. To zależy, czy

zgłaszanie błędów dotyczących ulepszeń ekranu, użyteczności lub głupich błędów.

jest coś, czego naprawdę nie chcesz. Jeśli jest to jasne w przypadku testerów, po prostu powiedziałbym im, aby nie robili rzeczy, których nie chcesz zgłaszać, ale wyrażaj się jasno. Zrób to, gdy jeden z tych raportów pojawi się ponownie.

Powodem, dla którego mają oni konkurs, jest prawdopodobnie dobra zabawa podczas pracy, więc prawdopodobnie nie zamierzają wykonywać złej pracy (jeśli jest to uważane za złe).


1
Absolutnie chcę wiedzieć o problemach z użytecznością. Nazywamy je „błędami w specyfikacji”.
RubberDuck

1
@RubberDuck Cóż, jeśli jest to w 100% jasne dla zespołu, to jest powód, aby powiedzieć im, informując, że nie podoba ci się to, co robią, i wiedzą, dlaczego. Ostrzeż ich. Jeśli nie zostanie to omówione konkretnie z zespołem, nie sądzę, żebyś się na nich wściekł i podał przykład jednego z raportów, których nie pochwalasz, i dałby im do zrozumienia, że ​​tak nie chcesz.
Loko,
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.