Klient znalazł buga przed testerem — co poszło nie tak

Scenariusz znany każdemu software house'owi: klient dzwoni lub pisze maila. „Po kliknięciu w link do faktury wyskakuje biały ekran". Zespół sprawdza — faktycznie, jest bug. PM pyta QA: „Dlaczego tego nie złapaliśmy?". Tester odpowiada: „Nie testowałem tego scenariusza" albo „Widziałem coś podobnego, ale nie zdążyłem zgłosić". I zaczyna się szukanie winnego. Tymczasem winny nie jest człowiek — winny jest proces.

Jak bugi przechodzą przez QA na produkcję

Capers Jones w „Applied Software Measurement" (2008) szacuje, że nawet najlepsze zespoły QA osiągają tzw. defect detection effectiveness (DDE) na poziomie 85%. Oznacza to, że 15% defektów przechodzi przez proces testowania niezłapanych — nawet w dojrzałych organizacjach. W mniejszych firmach, gdzie jeden tester obsługuje kilka projektów, ten wskaźnik jest niższy.

Ale jest kategoria bugów, która nie przechodzi przez QA dlatego, że tester ich nie zauważył. Przechodzi, bo tester je zauważył, ale nie zaraportował. Powód jest zawsze ten sam: presja czasu + bariera raportowania. Napisanie formalnego raportu to 10-15 minut. Gdy masz do przetestowania 3 moduły przed demo w piątek — priorytetem jest testowanie, nie dokumentowanie.

Koszt buga znalezionego przez klienta

Bug znaleziony przez klienta kosztuje wielokrotnie więcej niż ten sam bug złapany w fazie testowania. NIST (National Institute of Standards and Technology) w raporcie „The Economic Impacts of Inadequate Infrastructure for Software Testing" (2002) wykazał, że koszt naprawy defektu rośnie nawet 30-krotnie, gdy defekt przechodzi z fazy developmentu na produkcję.

Ale pieniądze to tylko część kosztu. Są jeszcze konsekwencje, których nie widać na fakturze:

Dlaczego presja czasu zabija coverage testów

World Quality Report 2023-24 (Capgemini, Sogeti, Micro Focus) wskazuje, że 52% respondentów uważa brak czasu na odpowiednie testy za główne wyzwanie w QA. To nie jest problem budżetowy — to jest problem efektywności procesu.

Tester pod presją musi wybierać: testować więcej scenariuszy czy raportować dokładniej. Każda minuta spędzona na pisaniu raportu to minuta mniej na testowanie. Przy 10-15 minutach na raport i 4-6 bugach dziennie, samo raportowanie pochłania 1-1,5 godziny — czas, który mógłby być przeznaczony na eksploracyjne testy kolejnych scenariuszy.

Efekt jest przewidywalny: tester testuje mniej albo raportuje mniej. W obu przypadkach bugi uciekają na produkcję. Różnica jest taka, że gdy tester testuje mniej — problem jest widoczny w metrykach pokrycia. Gdy raportuje mniej — problem jest niewidoczny, bo nikt nie mierzy bugów, których nie zaraportowano.

Co to oznacza dla Twojego software house'u

Klient znajdzie buga na produkcji. To jest pewne — żaden zespół QA nie ma 100% skuteczności. Pytanie brzmi: ile bugów, które klient znajdzie, mogło być złapanych wcześniej, gdyby bariera raportowania była niższa?

Rozwiązanie nie polega na zatrudnieniu kolejnego testera ani na wydłużeniu fazy QA. Rozwiązanie polega na skróceniu czasu, jaki tester potrzebuje na raport — bo wtedy zaraportuje więcej znalezionych problemów zamiast odkładać je „na później".

Voice2Bug skraca czas raportowania z 10-15 minut do poniżej minuty. Tester klika ikonę w przeglądarce, opisuje problem głosem, robi screena. Raport trafia do Jiry automatycznie — z danymi technicznymi, screenshot, krokami reprodukcji. Efekt: tester raportuje wszystkie znalezione bugi, nie tylko te, na które „miał czas". Mniej bugów ucieka na produkcję. Klient dzwoni rzadziej.