6 najgorszych reakcji na zgłaszanie bugów 

Nawet najlepiej przeprowadzone testy nie uchronią projektu przed błędami na produkcji. Dlatego niezwykle ważne jest, aby zapewnić użytkownikom możliwość zgłaszania błędów i przygotowanie systemu automatycznego powiadamiania o nich. Nie zawsze jednak reakcja samych developerów na zgłoszone błędy jest… adekwatna. 

Być może to zmęczenie, być może irytacja kiepskim opisem błędu – fakt, że zdarzają się sytuacje, których użytkownicy zgłaszający błąd z całą pewnością się nie spodziewali. I które w zasadzie nigdy nie powinny się wydarzyć. Przybliżamy kilka z nich.

Brak reakcji

Bodaj najczęstszą nieprawidłową reakcją na zgłoszenie błędu jest… brak reakcji. Sytuacji, w której użytkownicy w ogóle nie otrzymują odpowiedzi na swoje zgłoszenia, nie mówiąc już o rozwiązaniu problemu, jest sporo i dotyczy to nawet największych graczy. Przykład może stanowić historia opisywana przez użytkownika illusionofchaos. 

illusionofchaos odnalazł w iOS-ie cztery podatności i powiadomił o tym Apple. Jakie było jego zdziwienie, gdy w kolejnej aktualizacji załatano zaledwie jedną z nich, przy czym informacje o tym w ogóle nie pojawiły się w changelogu. illusionofchaos ponownie skontaktował się z Apple, które zapewniło go, że wraz z następną wersją luki zostaną załatane, a zgłoszone przez niego podatności zostaną opisane na liście zmian.

Tak się jednak nie stało. Skutek? Po wielu tygodniach zirytowany illusionofchaos zdecydował się – zgodnie z wcześniejszą zapowiedzią – opublikować informacje o podatnościach. Trudno nie zgodzić się z oceną, że Apple po prostu samo jest sobie winne.

Skomplikowanie procedur

Choć wydaje się to trudne do osiągnięcia, źle obsłużyć zgłoszenie błędu można jeszcze przed tym, jak użytkownik je wyśle! Zdarzają się bowiem sytuacje, kiedy sposób zgłaszania jest tak złożony i wymagający, że sprawia wrażenie, jakby developerzy zniechęcali użytkowników do pomocy. Tak było w przypadku gry sieciowej Amazonu, New Order, w której developerzy wymagali podania między innymi informacji o tym, jak błąd wpływał na grywalność czy nagrania wideo z widocznym błędem.

U mnie działa

Powyższe zdanie może przyprawić o rwanie włosów z głowy nawet najcierpliwszych zgłaszających. Prawdziwy pokaz arogancji wynikający najczęściej z lenistwa. Warto jednak pamiętać, że może to być także umiarkowanie kulturalna reakcja na kiepski opis błędu, przez który developerowi trudno jest go otworzyć. Dziś fraza „u mnie działa” pada już na szczęście głównie w kontekście humorystycznym.

It’s not a bug, it’s a feature

To kolejne już nieco memiczne twierdzenie, które trafiało nawet na koszulki, nadal pozostaje dla developerów świetną wymówką, by nie łatać błędów. To nieco bardziej zawoalowana forma „u mnie działa”, gdzie developer sili się na argumentację, że coś, co ewidentnie jest błędem to tak naprawdę zaprojektowana przez niego funkcja. 

Takim doświadczeniem podzielił się użytkownik jychp, który odnalazł lukę w zabezpieczeniach Cloudflare. Znów zatem mowa o przypadku, w którym na złą obsługę błędów pozwala sobie branżowy gigant, a nie firemka z garażu. Obejście zabezpieczeń pozwoliło mu uzyskać w usłudze Cloudflare przepustowość 100 tys. żądań na dzień całkowicie za darmo. Po zgłoszeniu otrzymał odpowiedź, według której, krótko mówiąc, „tak ma być”. Po wewnętrznej dyskusji zespół obsługujący zgłoszenia stwierdził, że błąd nie stanowi ryzyka dla bezpieczeństwa i… nie zostanie naprawiony.

Odpowiedź… agresją?

Na szczęście niezwykle rzadko zdarza się, aby w odpowiedzi na zgłoszenie użytkownik został… niewybrednie zwyzywany. Ale zdarza się. Doświadczył tego najwyraźniej pochodzący z Palestyny (co w tym przypadku mogło mieć znaczenie) łowca podatności MiDo, który w odpowiedzi na błąd zgłoszony do NetApp otrzymał takiego maila:

Gorszy dzień? Nieodpowiedni człowiek na nieodpowiednim miejscu? A może rasizm lub polityka? Nigdy się nie dowiemy.

Pozwy i groźby sądem

Choć może się to wydawać kuriozalne, aby osoby odnajdujące błędy i podatności, pozywać lub też grozić pozwem, to jednak zdarza się to zaskakująco często. Takich praktyk dopuścili się między innymi twórcy popularnej aplikacji Talkspace. Gdy jeden z użytkowników zauważył błąd w uwierzytelnianiu użytkowników umożliwiający korzystanie z usług Talkspace za darmo, twórcy aplikacji powiedzieli, że dysponują szeregiem wewnętrznych procesów, które eliminują ryzyko. Gdy zaś użytkownik zdecydował się opublikować informacje o bugu, błyskawicznie otrzymał wezwanie do zaprzestania naruszania dóbr osobistych i groźbę pozwu sądowego. Nieźle.

Ten przypadek przebiegł zresztą nad wyraz łagodnie w porównaniu z historią pewnego 18-latka, który odnalazł błąd w systemie sprzedaży biletów na Mistrzostwa Świata w Pływaniu, które odbyły się w 2017 roku w Budapeszcie. Zauważył on bowiem, że wystarczy nacisnąć klawisz F12, aby aplikacja pozwoliła wprowadzić dowolną cenę biletu na wydarzenie. W dobrej wierze zgłosił sprawę administratorom, co skończyło się… aresztowaniem. Węgierskie władze uznały bowiem, że skoro młody człowiek wiedział o tym błędzie, to na pewno go wykorzystywał.

Zgłoszenia na poważnie

Oczywiście podobnych sytuacji moglibyśmy wymienić znacznie więcej, ale najważniejsze, aby traktować zgłoszenia błędów i zgłaszających ludzi na serio. Informując o występowaniu jakiegoś błędu, wykonują za darmo pracę, której nie wykonali developerzy i testerzy. Warto to docenić, nawet jeśli zgłoszenie jest niekompletne czy niezrozumiałe.