Zgłaszanie bugów - jak robić to tak, żeby nie przedobrzyć?

Żyjemy w czasach, w których powiedzenie “czas to pieniądz” ma swoje pełne odzwierciedlenie w rzeczywistości, dlatego dbamy o to, by tego czasu nie marnować, a w efekcie zaoszczędzać pieniądze. Jednym z aspektów efektywnej pracy w zespole developerskim jest raportowanie błędów oraz ich odczytywanie. W sytuacji, gdy zgłoszony bug jest opisany zbyt obszernie, tracą na tym wszyscy - tester, który poświęcił czas na jego napisanie, developer próbujący wyciągnąć najważniejsze informacje oraz biznes, który próbuje zrozumieć co właściwie jest nie tak.

Należy zatem znaleźć właściwy balans w raportowaniu błędów. Jak tego dokonać?

Istota szczegółowego raportu z błędu

Wspomaganie reprodukcji błędu

Dostarczenie dokładnego opisu błędu i warunków w jakich występuje pomaga developerom zreprodukować błąd u siebie, co jest niezbędne do diagnozy i w efekcie naprawy błędu.

Oszczędność czasu

Wyczerpujący raport pozwala zaoszczędzić czas poprzez zminimalizowanie ryzyka tzw. gry w ping-ponga między testerem a developerem, w celu wyjaśnienia szczegółów.

Podniesienie jakości

Odpowiednio opisane oczekiwane zachowanie pomaga zrozumieć ideę stojącą za daną częścią aplikacji, co pozwala na dostarczenie solidnego rozwiązania błędu.

Efekt przeciwny do zamierzonego

Bałagan w opisie

Chaotyczny opis i podanie zbędnych informacji prowadzi do tego, że raport przestaje być czytelny, co sprawia, że kluczowe elementy są niejasne. Jeśli jeszcze dodamy do tego zbyt szczegółową listę kroków do reprodukcji, mamy przepis na niewłaściwie napisane zgłoszenie.

Zmarnowany wysiłek

Zbieranie a potem rozpisywanie informacji, które są niepotrzebne w zgłoszeniu marnują czas testera, a następnie developera, który będzie próbował zrozumieć w czym rzecz, a ostatecznie skontaktuje się bezpośrednio ze zgłaszającym, aby wyjaśnić sprawę.

Zapełnianie backlogu nieistotnymi zgłoszeniami

Raportowanie błędów, które z punktu widzenia biznesowego nie mają znaczenia, spowoduje że najprawdopodobniej nigdy nie trafią one na szczyt listy, aby mogły zostać poprawione. W efekcie otrzymujemy backlog, który jest sztucznie napompowany zgłoszeniami i trudniej jest w nim odnaleźć te najważniejsze tematy do realizacji.

Odnajdywanie równowagi

Pisz jasno i zwięźle

Kierując się tą zasadą, zawieraj niezbędne szczegóły, ale unikaj rozpisywania się na tematy oczywiste czy niezwiązane z meritum.

Skup się na istotnych informacjach

Zawieraj: kroki do reprodukcji, aktualny vs. oczekiwany efekt, szczegóły na temat środowiska, logi oraz zrzuty ekranu.

Używaj szablonów

Wyciągając wnioski z dwóch poprzednich punktów, skonsultuj z zespołem jakie informacje są zawsze potrzebne, aby zostały zawarte w zgłoszeniu, a następnie używaj takiego szablonu.

Dopasuj treść do odbiorcy

Zastanów się do kogo trafi Twoje zgłoszenie i dostarcz właściwe informacje. Back-end developerowi niekoniecznie będzie potrzebny zrzut ekranu z interfejsu graficznego, za to logi z błędu jak najbardziej. Pamiętaj że management też może chcieć zapoznać się z opisem błędu, więc ważne jest, żeby raport zawierał jakiś wysokopoziomowy opis czego dotyczy problem.

Kategoryzuj

Dla wygody własnej oraz zespołu określ kategorię błędu - czy to błąd po stronie API czy frontendu? Może to kwestia wydajności? Aby to przekazać w łatwy sposób reszcie, użyj labelki w JIRZE (zakładając, że z niej korzystacie) lub dodaj na początku tytułu zgłoszenia jakiś tag, np. [FE] lub iOS: co pozwoli w łatwy sposób ocenić developerowi czy to jest coś, za co może się zabrać czy powinien szukać kolejnego zadania.

Nadawaj priorytet

Nie bój się jasno wyrazić, że błąd wymaga szybkiej reakcji, jeżeli tak jest, bo na przykład blokuje część Twoich testów. Informuj też, jeżeli istotność problemu jest mała - może okazać się, że poprawka do tego wyjdzie przy okazji w kolejnej iteracji rozwijania funkcjonalności.

Podsumowanie

Wiemy już jak ważnym jest, by treść zgłoszenia była trafna - nie zawierała zaciemniających informacji, a jednocześnie pozwalała na podjęcie natychmiastowej reakcji bez dopytywania o szczegóły. Wyjaśniliśmy też co można zrobić w codziennej pracy, aby nie marnować czasu, dzięki czemu zyskać opinię konkretnego testera, a nie “tego marudy i nudziarza”. Stosując wyżej opisane propozycje, cały zespół zyska naprawdę wiele. Jeżeli znasz jakieś techniki, które sprawdzają się u Ciebie, podziel się proszę nimi w komentarzu - wszyscy na tym skorzystamy!

Więcej szczegółów na temat odnajdywania równowagi w pisaniu odpowiednich raportów z błędów znajdziesz w kursach TestSlayer.pl.