„Nie da się odtworzyć" — najdroższe trzy słowa w software house'ie

Scenariusz jest klasyczny. Tester zgłasza buga: „Formularz kontaktowy nie wysyła maili po kliknięciu Wyślij." Developer otwiera formularz, klika Wyślij — działa. Komentarz w tickecie: „Cannot reproduce. Zamykam." Tester otwiera ticket ponownie: „U mnie nadal nie działa." Developer: „Na jakiej przeglądarce? Jaki URL? Staging czy produkcja?" Dzień później tester odpowiada z brakującymi danymi. Developer próbuje jeszcze raz — teraz reprodukuje. Bug istniał cały czas. Stracone: 2 dni.

To nie jest odosobniony przypadek. Badania nad procesem debuggowania konsekwentnie wskazują, że próba reprodukcji pochłania znaczną część czasu programistów poświęconego na naprawę buga — w wielu organizacjach to około połowa tego czasu. Raport Cambridge University z 2013 roku szacuje, że globalne koszty debuggowania wynoszą setki miliardów dolarów rocznie.

Dlaczego „cannot reproduce" to nie odpowiedź

„Nie da się odtworzyć" brzmi jak diagnoza, ale to nie jest diagnoza. To informacja, że developer próbował odtworzyć buga z danymi, które miał — i nie udało się. Przyczyn może być kilka: inny URL, inna przeglądarka, inny stan sesji, inny moment w cyklu życia aplikacji. Cem Kaner, James Bach i Bret Pettichord w „Lessons Learned in Software Testing" (2002) zwracają uwagę, że jakość raportu buga determinuje, czy developer jest w stanie go naprawić — a nie to, czy bug „naprawdę istnieje".

Problem nie tkwi w developerze, który nie chce szukać. Problem tkwi w raporcie, który nie daje mu wystarczających danych. Developer nie siedzi w tej samej przeglądarce co tester. Nie widzi tego samego stanu aplikacji. Nie zna kontekstu, w jakim bug wystąpił. Jeśli raport mówi „formularz nie działa" bez informacji o URL, przeglądarce, logach konsoli i dokładnych krokach — developer ma do dyspozycji próbowanie na ślepo.

Czego brakuje w 80% raportów bugów

Raport buga ma jedno zadanie: dać developerowi wystarczająco dużo danych, żeby mógł odtworzyć problem w swoim środowisku. W praktyce większość raportów tego nie robi. Michael Bolton w serii artykułów na blogu DevelopSense pisze o tym wprost: raport buga powinien opowiadać historię — co zrobiłeś, co zobaczyłeś, czego się spodziewałeś.

To nie jest kwestia kompetencji testera. To kwestia kosztu. Dopisanie każdego z tych elementów ręcznie do raportu w Jirze zajmuje czas. Sprawdzenie wersji przeglądarki — 30 sekund. Otwarcie konsoli, skopiowanie logów — minuta. Opisanie kroków z pamięci, 5 minut po znalezieniu buga — ryzyko pominięcia szczegółu. Cały proces: 10-15 minut. Pod presją czasu tester idzie na skróty. I raport wychodzi niekompletny.

Ping-pong tester-developer — ile to kosztuje

Każdy cykl „cannot reproduce → reopen → dodatkowe dane → próba reprodukcji" to koszt dwóch osób. Developer traci czas na próbę odtworzenia z niekompletnymi danymi, na napisanie komentarza, na czekanie na odpowiedź. Tester traci czas na przeczytanie komentarza, wrócenie do buga, zebranie brakujących danych, aktualizację ticketa.

Raport CISQ „The Cost of Poor Software Quality in the US" (2022) szacuje, że koszty niskiej jakości oprogramowania w samych Stanach Zjednoczonych wynoszą 2,41 biliona dolarów rocznie. Znaczna część tych kosztów to nie bugi same w sobie — to nieefektywne procesy ich obsługi. Ping-pong „cannot reproduce" to jeden z najczęstszych takich procesów.

W software house'ie z 5 testerami i 10 developerami, jeśli co tydzień 5 ticketów przechodzi przez cykl „cannot reproduce", to 200-350 minut tygodniowo na sam ping-pong. Ponad 3-6 godzin. A do tego dochodzi opóźnienie w naprawie — bug, który mógł być naprawiony w dniu zgłoszenia, leży 1-2 dni czekając na kolejną rundę.

Co to oznacza dla Twojego software house'u

„Cannot reproduce" to problem danych, nie problem ludzi. Developer nie jest złośliwy — nie ma danych. Tester nie jest leniwy — nie miał czasu ich zebrać. System wymusza kompromis: albo raport szybki (i niekompletny), albo raport kompletny (i 10-15 minut zamiast testowania).

Rozwiązanie nie polega na szkoleniu testerów „jak pisać lepsze raporty". Rozwiązanie polega na tym, żeby dane techniczne — URL, przeglądarka, wersja, logi konsoli, rozdzielczość ekranu — trafiały do raportu automatycznie, bez żadnego dodatkowego wysiłku ze strony testera.

Voice2Bug zbiera te dane w momencie raportowania. Tester klika ikonę wtyczki, mówi co widzi, robi screenshot. Poniżej minuty. Raport w Jirze zawiera automatycznie: dokładny URL, przeglądarkę z wersją, rozdzielczość ekranu, logi konsoli, transkrypcję głosową przetworzoną na ustrukturyzowane kroki reprodukcji. Developer otwiera ticket — i ma wszystko czego potrzebuje, żeby odtworzyć buga od pierwszej próby.

Efekt: mniej ticketów z „cannot reproduce". Mniej ping-pongów. Mniej czasu straconego przez obie strony. Mniej bugów, które leżą w Jirze dzień lub dwa czekając na brakujące dane. Bug znaleziony rano — naprawiony do obiadu. Nie dlatego, że developer jest szybszy. Dlatego, że dostał kompletne dane za pierwszym razem.