Zgłaszanie błędów – jak zrobić to dobrze
W dzisiejszym wpisie zajmiemy się kolejnym zagadnieniem ważnym z perspektywy zarówno testera, jak i developera. Poruszymy temat jakim jest zgłaszanie błędów. Jak robić to skutecznie, klarownie, przejrzyście oraz w taki sposób, żeby wiadomość była czytelna dla wszystkich zainteresowanych.
Trociny dla devów
Usłyszałem kiedyś to określenie i bardzo mi zapadło w pamięć — czym są trociny, które czasem testerzy przekazują developerom? Są to wszystkie informacje, które są niepełne, niekompletne, takie które zostawiają dużo niedopowiedzeń bez faktów.
Zapewne znasz sytuacje, gdy znalazłeś błąd, czas goni, szybka informacja w tickecie i wracasz do poszukiwania następnych błędów. Zastanówmy się tylko co dzieje się z taką informacją na kolejnych etapach.
a) tester znajduje błąd
b) opisuje błąd dość niedokładnie, nie podając wszystkich istotnych informacji
c) ticket z błędem otrzymuje ją developer
b) developer próbuje zreplikować błąd, jednak podczas próby trafia na niepełne informacje
e) przerywa proces
f) prosi o więcej informacji
g) tester po jakimś czasie stara dopisać więcej szczegółów i odpisać na pytania developera (o ile pamięta więcej detali i znów nie musi poświęcić czasu na odtwarzanie tego błędu)
Zastanówmy się teraz ile mamy w procesie zmarnowanego czasu z powodu sprawy tak trywialnej, jak nieprawidłowe opisanie błędu.
Gdybyśmy chcieli zrobić to idealnie, proces wyglądałby tak.
a) tester znajduje błąd
b) dokonuje opisu, podaje wszystkie niezbędne informacje
c) developer odczytuje wiadomość i implementuje poprawkę
d) tester robi retesty i akceptuje
Zobaczmy, o ile skrócił się nasz proces z powodu tylko i wyłącznie opisania błędu w sposób czytelny, klarowny, który nie pozostawia przestrzeni na domysły i jest wypełniony informacjami.
Pomyślmy również o komforcie, jaki zyskuje developer i tester pracując nad naprawą takiego błędu.
Pozorny zysk
Czemu powstają więc niedokładnie zaraportowane błędy? Myślę, że jednym z głównych czynników jest pozorna oszczędność oraz presja. Oszukujemy siebie sami, że raportując szybciej i mniej dokładnie zyskujemy więcej czasu na eksploracje i poszukiwanie błędów. Prada jest jednak inna i takie praktyki nie są niczym innym jak marnowaniem cennego zasobu, jakim jest czas zespołu.
Jak zaraportować dobrze
To oczywiście zależy, zależy od typu aplikacji, specyfiki testowanego oprogramowania czy projektu. Poniższy szablon jest ogólnym przedstawieniem raportu, może być on dobrym punktem wyjścia do pracy nad Waszymi szablonami do raportowania błędów.
- Tytuł — klarowny i czytelny stanowi podstawę dobrze zaraportowanego błędu.
- Środowisko — jest to istotny punkt, gdyż niektóre błędy mogą być spowodowane samym środowiskiem testowym, a nie kodem — błędy wynikające z konfiguracji / środowiska.
- Priorytet — poinformuj również developera, jak pilny jest to błąd. Skala priorytetu zależy od organizacji firmy.
- Label — (zależy od projektu i procesu).
- Warunki wstępne — czasem zreplikowanie błędu nie jest łatwe ani oczywiste. Warto podać developerowi informacje o warunkach wstępnych, jakie należy spełnić, aby odtworzyć błąd.
- Opis błędu — klarowny i czytelny, czym więcej informacji zawrzemy w tym punkcie, tym łatwiejsze powinno być debugowanie przez developera błędu.
- Kroki do reprodukcji błędu — również w tym punkcie opiszmy klarownie i czytelnie jak odtworzyć nasz błąd.
- Oczekiwany rezultat — co powinno się dziać z naszą aplikacją.
- Wersja aplikacji / branch
- Urządzenie / przeglądarka / wersja
- Załączniki — wszelkie zdjęcia, video czy logi, które posiadamy, dodajemy do tej sekcji.
Produktywny tester
Warto tutaj zauważyć, że możemy dodatkowo przyśpieszyć nasze raportowanie błędów i spowodować, że będzie efektywniejsze. Kluczem do tego jest przygotowanie sobie odpowiednich materiałów.
Nie wyobrażam sobie przepisywać szablonu do raportowania błędu za każdym razem, kiedy chce zaraportować o nieprawidłowościach. Tutaj dobrze przygotować sobie wcześniej zdefiniowane szablony (przykładowo GitLab ma możliwość dodawania takich szablonów).
Można też używać dodatkowego oprogramowania, które przy odpowiednim skrócie klawiszowym wygeneruje za nas szablon do zaraportowania.
Zgłaszanie błędów – raport idealny
Pamiętaj, że pisanie czytelnych raportów to kwestia wprawy, chęci oraz współpracy z developerami. Możesz porozmawiać z nimi, czego ich zdaniem brakuje w zgłaszanych błędach przez Ciebie bądź Twój zespół. Feedback ze strony programistów może pomóc Ci nakierować raporty w lepszym bardziej produktywnym kierunku.
Zadanie na koniec wpisu
Porozmawiaj z zespołem programistów, z którym pracujesz, co ich zdaniem możecie jako testerzy poprawić w raportowaniu błędów. Następnie najczęściej pojawiające się uwagi do Waszego raportowania zamień w zadania i wdróż do procesu poprawki opierające się na feedbacku.
Pozwoli Wam to oszczędzać czas, dostarczać lepszej jakości oprogramowania w krótszym czasie — same korzyści. : )
Koniecznie daj znać w komentarzu, jako poszło!
Więcej artykułów z podstawami testowania znajdziesz pod linkiem: https://projectquality.it/testowanie-oprogramowania-podstawy/
