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

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.

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.

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.

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”.

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.

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.

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ć.

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)

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).