Jak zgłaszać błędy i dokumentować przypadki niewłaściwego funkcjonowania serwisu www?

Każdy z nas – użytkowników sieci – spotykał się nie raz z błędami, problemami i zaskakującym zachowaniem aplikacji. Jedni ignorują napotkaną przeszkodę, inni na zawsze żegnają się z daną stroną bądź programem. Jest też grupa użytkowników, którzy postanawiają zgłosić błąd, zazwyczaj licząc na szybkie jego wyeliminowanie. Czy wy – zgłaszający bugi i błędy – zastanawialiście się jak prawidłowo to zrobić? Co zawrzeć w informacji, by problem rzeczywiście został szybko rozwiązany? Ten artykuł przybliży wam podstawowe zasady raportowania błędów i wadliwych zachowań aplikacji.

bledy-3

Cel zgłaszania bugów (ang. „robak”, powszechnie przyjęte jako nazwa błędu cyfrowego) jest zawsze ten sam – wyeliminowanie problemu. Jest to niezależne od etapu życia programu. Ten sam cel przyświeca testerom i zespołom Quality Assurance w czasie produkcji aplikacji, jak i użytkownikom końcowym, korzystającym z danego tworu. Na wstępie należy wyjaśnić ważną kwestię – nie istnieją strony, aplikacje i programy pozbawione błędów. Im bardziej skomplikowane dzieło, tym tych błędów jest więcej. Zdecydowana większość zostaje wyeliminowana w fazie produkcji, jednak może się zdarzyć, że jakiś problem prześlizgnie się do wersji finalnej. I właśnie w tym momencie na arenę wkraczają użytkownicy uzbrojeni w narzędzia i drogi kontaktu z działem wsparcia.

Pojawił się błąd!

Po pierwsze – nie panikuj! Wiele osób w starciu z błędem traci głowę i zaczyna na oślep zamykać okienka oraz komunikaty o błędach, a to najgorsze co można zrobić! Gdy pojawi się błąd, należy mu się przyjrzeć, poznać wroga. Któż z nas w dzieciństwie nie oglądał drobnych żyjątek przez lupę? Wyobraźmy sobie, że bug to właśnie taki robaczek. Ma nóżki, korpus i kolorowe skrzydełka oraz wielkie oczka, którymi się w nas wpatruje. Czy jest straszny i nas pogryzie? Nie. Warto więc na niego spojrzeć. Jeśli pojawił się komunikat o błędzie, zróbmy zrzut ekranu. Zrzut ekranu przyda się także wtedy, gdy aplikacja internetowa wygenerowała podejrzany naszym zdaniem adres URL, pustą stronę lub po prostu się zawiesiła. Jeśli wykonanie zrzutu jest z jakiegoś powodu niemożliwe, zapiszmy komunikat o błędzie. Nawet, a raczej zwłaszcza wtedy, gdy zawiera on nierozumiane przez nas, z pozoru losowe ciągi znaków. To, co dla użytkownika jest niezrozumiałe, dla programisty jest jasnym komunikatem mówiącym o podłożu błędu.

Drugim ważnym nawykiem, który warto w sobie wyrobić, jest sprawdzenie powtarzalności. Problem zostanie rozwiązany o wiele szybciej, gdy programista w zgłoszeniu otrzyma informację o tym, czy błąd pojawił się ponownie, czy był jednorazowy. Warto się temu przyjrzeć, spróbować powtórzyć czynności, które zakończyły się pojawieniem błędu. A może istnieje prostsza droga do uzyskania go? Takie informacje są ważne dla osoby, która będzie rozwiązywała zgłoszony przez nas problem.

bledy-2

Warto pamiętać, że dla programisty duże znaczenie mają informacje z pozoru nieistotne. Może błąd pojawia się tylko przy wpisywaniu długiego tekstu, może powodują go polskie znaki, może długość aktywności w sesji ma znaczenie? Bug nie zawsze pojawia się z jasnych i oczywistych powodów. Czasami trzeba poświęcić mu dłuższą chwilę, zastanowić się co mogło go spowodować. Oczywiście nie podamy programiście gotowej recepty na rozwiązanie problemu, ale znacznie mu pomożemy, a co za tym idzie przyspieszymy naprawę, jeśli podamy mu nasze przypuszczenia. Nie bójmy się używać sformułowań Wydaje mi się, że…, Problem może być spowodowany przez…, Możliwe, że…

Czym zgłaszać?

Najpopularniejszą formą wymiany informacji pomiędzy użytkownikiem a działem wsparcia są infolinie oraz poczta elektroniczna. Te metody mają jednak wadę w postaci braku wytycznych odnośnie do treści i formy zgłaszania błędu. Można za ich pomocą stworzyć raport zawierający jedno zdanie, ale też taki, który będzie aspirował do druku w formie broszury. Obie formy nie sprzyjają szybkiemu rozwiązaniu problemu.
Szczęśliwy programista to taki, który posiada niezbędną ilość informacji i nic ponad nie. A zadowolony developer to skuteczny developer.

bledy-1

Zupełnie odmienną formą zgłaszania błędów są tzw. bugtrackery, a więc środowiska stworzone specjalnie w celu zbierania, katalogowania i zarządzania zgłaszanymi błędami. Do najpopularniejszych z nich należą:

  • Bugzilla – Oprogramowanie open source stworzone przez Fundację Mozilla. Umożliwia ono zbudowanie całego serwisu internetowego do raportowania błędów. Jak większość tego typu programów, posiada możliwość katalogowania zgłoszeń według kategorii (np. błąd, problem, sugestia), priorytetu, a także statusu naprawy (np. nowy, w trakcie, rozwiązany). Użytkownicy mogą także załączyć do swojego zgłoszenia komentarz bądź pliki.
  • Mantis Bug Tracker – Kolejne narzędzie open source. Jego wielką zaletą jest użycie języka PHP, co czyni go środowiskiem bardzo uniwersalnym, mogącym pracować na najbardziej popularnych serwerach. W dodatku jest bardzo rozbudowany, a przy tym prosty w użytkowaniu. Od rejestracji do możliwości zgłoszenia błędu mija ledwie kilka chwil.
  • Redmine – System zarządzania zadaniami, będący niezwykle pomocny w panowaniu nad całością projektu. Oferuje wiele możliwości, od określenia rodzaju zgłoszenia, przez jego priorytet, opis, aż po załączniki i komentarze. W naszej agencji wykorzystywany jest także do raportowania błędów. Od poprzedników wyróżnia go to, że rzadko jest udostępniany dla użytkowników spoza zespołu pracującego nad daną aplikacją internetową.

Jak zgłaszać?

bledy-4

Dobrze napisane zgłoszenie błędu powinno zawierać te z poniższych punktów, które są adekwatne do przedmiotu problemu. Oczywistym jest, że w przypadku serwisu internetowego nie podamy informacji o wersji, która za to ma znaczenie w przypadku na przykład aplikacji mobilnej. Ważnym jest, by każdy z punktów uzupełniać w sposób zwięzły, ale jednocześnie zawierający wszystkie potrzebne informacje. Nie bójmy się wypunktowań, wyszczególnień i ciągów zdarzeń wymienianych od myślników. Taki sposób zapisu często jest wystarczający, a przy tym znacznie bardziej przejrzysty od długich opisów.

Tytuł

Dobry tytuł jest zwarty i w kilku słowach oddaje istotę problemu. Unikajmy jednak zbyt ogólnych sformułowań, takich jak Menu nie działa. O wiele lepszym byłoby Elementy menu są nieklikalne. Jeśli problem dotyczy jednej z wielu dostępnych wersji (np. działającej na komputerach stacjonarnych, tabletach, smartfonach), możemy to zaznaczyć już w tym miejscu. Umożliwi to szybsze przekierowanie zgłoszenia do odpowiedniej osoby.

Miejsce wystąpienia

W tym miejscu podajemy adres URL lub ciąg dostępu do miejsca, w którym pojawił się błąd, a także usytuowanie na stronie.

Przykłady:

  • http://example.com/build/home.html – belka menu
  • Powiększenie zdjęcia w galerii „Nasz zespół”.

Środowisko

bledy-5

Kolejną niezwykle ważną kwestią jest podanie środowiska, w którym wystąpił błąd. W przypadku aplikacji i serwisów internetowych niezbędne jest podanie informacji o wersji przeglądarki oraz systemu operacyjnego. Podobnie w razie zgłoszenia błędów występujących na urządzeniach mobilnych – należy podać urządzenie, wersję systemu oraz przeglądarkę internetową.

Nieco inaczej jest w przypadku oprogramowania, a także dedykowanych aplikacji mobilnych. Tutaj, oprócz systemu, warto podać także numer dystrybucji, a więc wersję aplikacji lub programu. Jeśli błąd wiąże się z grafiką, nie zaszkodzi podać także specyfikacji komputera, z którego korzystamy.

Nie bójmy się, te dane nie zostaną wykorzystane w żaden negatywny sposób. Posłużą jedynie do zdiagnozowania przyczyny problemu. Nierzadko zdarza się bowiem, że problem występuje tylko w konkretnej konfiguracji sprzętu i oprogramowania. Aby uniknąć przeciągającego się kontaktu z działem wsparcia, lepiej od razu podać przydatne informacje.

Ścieżka odtworzenia

bledy-6

Programiści lubią konkrety, a ścieżka odtworzenia błędu nieraz jest niezbędna do jego naprawy. Niestety musimy liczyć się z tym, że developer odrzuci zgłoszenie, jeśli nie będzie wiedział jak uzyskać opisywany bug. Dlatego zawsze powinniśmy zawrzeć opis czynności, po wykonaniu których pojawił się problem.

Ścieżka może być prosta, na przykład:
– Dodać produkt do koszyka.
– Wejść do koszyka.

Może być też jednak bardziej złożona, na przykład:
– Znaleźć produkt z ceną promocyjną – dodać produkt do koszyka – zwiększyć ilość tego produktu do 3 sztuk – zaktualizować cały koszyk.

Sposób zapisu odtworzenia błędu jest dowolny. Pamiętajmy jednak o zasadzie: im prościej, tym lepiej. Z pewnością należy unikać długich, wielokrotnie złożonych zdań. Nie bójmy się natomiast powtórzeń: zgłoszenie błędu to nie sprawdzian z języka polskiego. Chociaż poprawna ortografia i interpunkcja są mile widziane, to powtórzenia są czymś całkowicie normalnym i dopuszczalnym.

Informacje dodatkowe

Jest to miejsce na zawarcie swoich przypuszczeń oraz spostrzeżeń. Zawsze warto dodać, że błąd jest powtarzalny lub jednorazowy. Może pojawia się sporadycznie w pozornie losowych sytuacjach? Taka wiedza znacznie przyspieszy proces lokalizacji i rozwiązania problemu.

W dobrym zwyczaju jest także podanie swoich oczekiwań co do spodziewanego efektu. Dzięki temu zespół wsparcia otrzymuje informację o tym, jak dane rozwiązanie jest rozumiane i przyjmowane przez użytkowników. Sam programista natomiast dowiaduje się, czy ma do czynienia z bugiem czy błędem w logice aplikacji.

Jeśli czujemy się na siłach, możemy dołączyć także nasze przypuszczenia co do powodu występowania problemu. Unikajmy oczywiście przesady, ograniczając się jedynie do krótkiej notki zawierającej nasze spostrzeżenia. Nikt nie oczekuje tego, że podamy programiście gotowe rozwiązanie, jest to wręcz niewskazane. Ale developerowi pracującemu nad zgłoszeniem z pewnością będzie miło, gdy zobaczy, że poświęciliśmy nieco swojego czasu, by spróbować zrozumieć problem, który zgłaszamy.

Podsumowanie

Zgłoszenie błędu może wydawać się trudną sztuką, pełną kruczków i fałszywych dróg. Być może masz wrażenie, że problem nie dotrze do programisty, a zamiast tego utknie gdzieś w odmętach działu wsparcia. Tak naprawdę wystarczy jednak pamiętać o jednej prostej zasadzie – dokładności. Im bardziej precyzyjny opis, tym lepsze rezultaty, także te w kwestii szybkości naprawy.
A zanim postanowimy powtórzyć kontakt, zniecierpliwieni długim czasem oczekiwania, uświadommy sobie, że nasze zgłoszenie nie musi być jedynym, a dział wsparcia prawdopodobnie odebrał w tej sprawie już wiele telefonów i przestaje weryfikować powtarzające się zgłoszenia. Bądźmy więc cierpliwi i dajmy programistom czas.

Tester aplikacji internetowych w poznańskiej agencji interaktywnej Merixstudio. Pasjonatka nowych mediów oraz grafiki komputerowej. Po godzinach zdobywa doświadczenie w nadzorowaniu przeglądarkowych tekstowych gier RPG opartych na silniku Vallheru i jego późniejszych modyfikacjach.

Send this to a friend

webmastah.weekly
Cotygodniowa porcja linków ze świata WEBDEV BEZ spamu, TYLKO samo mięcho!
Zobacz poprzednie wydania. Dołącz do 2 tysięcy webdeveloperów!
HTML5, CSS3, JS (React, Angular, Ember, Vue), PHP, SQL