Ile defektów musi znaleźć tester?

Komentarz pod wpisem na Facebooku dotyczącego projektu Bugster (oraz jego modelu płacenia za znaleziony błąd / buga) dotknął ważnego zagadnienia liczby znalezionych defektów w odniesieniu do kosztów pracy testera.

 

Wpisy i komentarze na FB mają krótką żywotność, a przy okazji rozwinięcia dyskusji warto go wspomnieć.

Poniżej fragmenty komentarza Dariusza Kozona, który pisze (wersja oryginalna):

"(...)  pokusiłem się o drobne obliczenia:
przy założeniu, że mediana płacy w zawodzie testera to okolica 5000 brutto = koszt pełnoetatowego pracownika dodając do tego około 1000 kosztu pracodawcy daje to ca 6000 pln, jeden defekt to 40 pln netto [cena za znalezienie jednego defektu w bugster.pl - przypomnienie redakcji] daje to konieczność zgłoszenia 150 defektów (czy to dużo czy to mało to już inna kwestia - jeśli mówimy o dużym projekcie to można wyczerpać limit kilkukrotnie :), jeśli mały projekcik o wąskim zakresie to czas poświęcony testerowi na wgryzienie się logikę może nie zostać pokryty z przychodu za błędy - ale nie musi to być częsty scenariusz). Oczywiście wziąłem poprawkę, że projekty mogą być małe gdzie całą aplikację jedna osoba ogarnie w 2-3 dni a są i takie gdzie pełne testy zajmą zespołowi kilku osób tydzień :) więc w skali miesiąca aby firma była rentowna (biorąc inne koszta prowadzenia firmy) jeden tester musi znaleźć 200 błędów / mc (jak mniemam w różnych aplikacjach) - pomijam też koszt czasu na tzw. context switching, czytanie dokumentacji/zapoznawanie się logiką biznesową - można to trochę zredukować poprzez exploratory testing
(...)
dla większych firm z pełnym zapleczem IT mimo wszystko dalej może opłacać się utrzymywać testerów na stanowiskach (200 defektów przy stawce 40 pln daje 8000 pln + VAT) a zazwyczaj przy większych projektach są większe budżety i potrzeba robienia też innych rzeczy w okół jakości np. testy automatyczne, konfiguracja CI, proces współpracy i przepływu informacji, etc. itd. itp...
(...)"

 

Od Redakcji

Jest to bardzo ciekawa, choć oczywiście bardzo uproszczona analiza tego, co tester może lub też musi zrobić aby "zapracować" na swoją pensję. Uproszczenie polega przede wszystkim na zorientowaniu się tylko na złej jakości, czyli na poszukiwaniu defektów oprogramowania. Taki jest jednak model pay-per-bug, gdzie klient płaci za informację o tym, co nie działa. Nie płaci za to za informację o jakości w postaci raportu z testów, który wskazuje również co i w jakim zakresie działa.

Oczywiście nie mogą to być defekty trywialne, nieuznane, duplikaty, itp. Muszą to być wartościowe zgłoszenia, które zostaną naprawione przez programistów. Aby wpasować się w cenę proponowaną na bugster.pl muszą one być warte średnio 40 PLN, co oznacza, że gdyby ich nie znaleziono, to mogłyby wygenerować stratę (lub nie przynieść przychodu) o minimum takiej wartości. Musimy pamiętać, że nie każdy defekt generuje milionowe koszty jego naprawienia, ale nawet najmniejszy błąd może zniechęcić do zapłacenia za nasze oprogramowanie.

Zakładając więc, że testerowi płaci się jedynie za znalezione defekty, to, jak pokazuje Darek, wystarczy przy cenie 40 PLN znaleźć 150 defektów w miesiąc pracy. Przy dwudziestu dniach roboczych w miesiącu i efektywności liczonej na 75% czasu (średnio 25% czasu w roku to urlopy, święta czy chorobowe) zostaje 15 dni pracy. Wychodzi więc 10 defektów dziennie, czyli ponad 1 defekt na godzinę!

Jest to obliczenie dla pensji na poziomie 5000 PLN brutto. Jeśli więc zarabiasz więcej, to Twoja efektywność musi być większa : )

 

Podkreślamy, że zarówno komentarz, jak i nasze rozwinięcie jest uproszczeniem i powinno być traktowane z przymrużeniem oka.

 

 

 

Najbliższe terminy szkoleń

Partnerzy

Narzędzia testerskie