Ile bugów ginie w Slacku, mailu i na karteczkach

W każdym software house'ie istnieje oficjalny proces raportowania bugów: tester znajduje problem, otwiera Jirę, pisze raport, przypisuje do developera. Ale obok tego procesu funkcjonuje drugi, nieoficjalny — wiadomość na Slacku „hej, coś się sypie na formularzu kontaktowym", mail od klienta przekazany dalej z komentarzem „do ogarnięcia", notatka na karteczce po daily. Capers Jones w „Applied Software Measurement" (2008) szacuje, że w typowym projekcie software'owym od 25% do 50% defektów nigdy nie trafia do formalnego systemu śledzenia.

Czym jest shadow bug reporting

Shadow bug reporting to zjawisko, w którym informacje o błędach krążą poza oficjalnym bug trackerem. Nie chodzi o to, że ludzie celowo omijają proces. Chodzi o to, że oficjalny proces jest zbyt kosztowny w porównaniu z alternatywą.

Napisanie wiadomości na Slacku zajmuje 15 sekund. Napisanie raportu w Jirze — 10 do 15 minut. Wybór jest oczywisty, szczególnie gdy deadline goni. Problem w tym, że wiadomość na Slacku nie ma przypisanego priorytetu, nie jest śledzona, nie pojawia się w raportach sprintowych i nikt nie weryfikuje, czy ktoś ją w ogóle przeczytał.

Dlaczego testerzy omijają bug tracker

Nie dlatego, że są leniwi. Dlatego, że optymalizują swój czas — tak jak każdy racjonalny pracownik. Badanie przeprowadzone przez Stack Overflow w Developer Survey 2023 pokazuje, że 62% programistów uważa „nieefektywne procesy" za jedną z głównych frustracji w pracy. U testerów ten wskaźnik jest prawdopodobnie wyższy, bo raportowanie to istotna część ich dnia.

Mechanizm jest prosty: jeśli napisanie raportu buga zajmuje 10-15 minut, a tester znajduje 4-6 bugów dziennie, to raportowanie pochłania od 40 minut do 1,5 godziny czasu pracy. Badania Dr Glorii Mark z University of California Irvine (opublikowane w „Attention Span", 2023) pokazują dodatkowo, że każde przerwanie — a wyjście z testowania do Jiry to przerwanie — kosztuje średnio ponad 23 minuty na powrót do skupienia.

W tej sytuacji tester staje przed wyborem: zaraportować formalnie i stracić czas, czy napisać na Slacku i wrócić do testowania. Szczególnie pod koniec sprintu, gdy presja czasu jest największa, Slack wygrywa.

Koszt niewidocznych bugów

Bug, który nie trafił do trackera, nie jest śledzony. Nikt nie wie, czy został naprawiony. Nikt nie testuje regresji. Nikt nie wie, ile takich bugów jest w systemie.

Raport CISQ „The Cost of Poor Software Quality in the US" (2022) szacuje, że koszty niskiej jakości oprogramowania w USA wyniosły 2,41 biliona dolarów rocznie. Choć to liczba dla całego rynku, mechanizm jest ten sam w każdej skali: nieśledzone defekty kumulują się i generują koszty wielokrotnie wyższe niż ich wczesna naprawa.

W software house'ie z 10-30 osobami, jeden niezaraportowany bug, który trafia na produkcję, kosztuje od 1 100 do 6 200 PLN samego czasu zespołu (hotfix + retesty + deploy + komunikacja z klientem). Jeśli takich bugów jest kilka miesięcznie — a przy shadow reportingu nikt nie wie ile ich jest — straty idą w dziesiątki tysięcy złotych rocznie.

Jak zmierzyć shadow reporting w swoim zespole

Prosty eksperyment: przez jeden tydzień poproś zespół, żeby każdy znaleziony bug — niezależnie od kanału — oznaczył w jednym miejscu (np. wspólny arkusz). Na koniec tygodnia porównaj tę listę z tym, co trafiło do Jiry.

Różnica między tymi dwiema liczbami to Twój wskaźnik shadow reportingu. Jeśli jest powyżej 20% — masz problem procesowy, nie personalny.

Co to oznacza dla Twojego software house'u

Shadow bug reporting to symptom, nie przyczyna. Przyczyna to zbyt wysoki koszt formalnego raportowania. Gdy raportowanie buga zajmuje 10-15 minut, ludzie naturalnie szukają szybszych dróg. Rozwiązaniem nie jest „dyscyplina" ani „procedury" — bo te wymagają energii, której pod presją deadline'u nie ma.

Rozwiązaniem jest zmniejszenie kosztu formalnego raportowania do poziomu, w którym Slack przestaje być atrakcyjną alternatywą. Jeśli raport w Jirze powstaje w poniżej minuty — tak jak wiadomość na Slacku — nikt nie ma powodu omijać tracker.

Voice2Bug robi dokładnie to. Tester klika ikonę w przeglądarce, mówi co widzi, robi screena. Poniżej minuty. Raport trafia do Jiry automatycznie — ze strukturą, krokami reprodukcji, danymi technicznymi. Bez wychodzenia z testowanej strony, bez zmiany kontekstu, bez wymówek „nie miałem czasu wpisać do Jiry".