Menu

Jak napisać dobry raport o błędzie? Porady i wskazówki

how write good bug report

Wypróbuj Nasz Instrument Do Eliminowania Problemów

Dlaczego dobry raport o błędzie?

Jeśli Twój raport o błędzie jest skuteczny, szanse na naprawienie są większe. Naprawienie błędu zależy więc od tego, jak skutecznie go zgłosisz. Zgłoszenie błędu to nic innego jak umiejętność i wyjaśnię, jak ją osiągnąć.

„Celem napisania raportu o problemie (zgłoszenia błędu) jest naprawienie błędów” - autor: Cem Kaner. Jeśli tester nie zgłasza błędu poprawnie, programista najprawdopodobniej odrzuci ten błąd, stwierdzając, że jest on nieodwracalny.

Jak napisać dobry raport o błędzie

Może to zaszkodzić moralności testerów, a czasami także ego. (Sugeruję, aby nie zachowywać żadnego typu ego. Ego brzmi: „Prawidłowo zgłosiłem błąd”, „Mogę go odtworzyć”, „Dlaczego on / ona odrzucił błąd?”, „To nie moja wina” itp. ,).

Czego się nauczysz:

Jakie są cechy dobrego raportu o błędzie oprogramowania?

Każdy może napisać raport o błędzie. Ale nie każdy może napisać skuteczny raport o błędzie.

Powinieneś być w stanie rozróżnić między przeciętnym zgłoszeniem błędu a dobrym zgłoszeniem błędu. Jak odróżnić dobry od złego zgłoszenia błędu? To bardzo proste. Zastosuj następujące cechy i techniki, aby zgłosić błąd.

Charakterystyka i techniki obejmują

# 1) Mając jasno określony numer błędu: Zawsze przypisuj unikalny numer do każdego zgłoszenia błędu. To z kolei pomoże ci zidentyfikować zapis błędu. Jeśli korzystasz z dowolnego narzędzia do automatycznego zgłaszania błędów, ten unikalny numer będzie generowany automatycznie za każdym razem, gdy zgłaszasz błąd.

Zanotuj numer i krótki opis każdego zgłoszonego błędu.

# 2) Odtwarzalne: Jeśli twojego błędu nie da się odtworzyć, to nigdy nie zostanie naprawiony.

Powinieneś wyraźnie wspomnieć o krokach prowadzących do odtworzenia błędu. Nie zakładaj ani nie pomijaj żadnego etapu odtwarzania. Błąd, który jest opisany krok po kroku, jest łatwy do odtworzenia i naprawienia.

# 3) Bądź konkretny: Nie pisz eseju na temat problemu.

Bądź konkretny i na temat. Postaraj się podsumować problem minimalną liczbą słów, ale w skuteczny sposób. Nie łącz wielu problemów, nawet jeśli wydają się podobne. Napisz różne raporty dla każdego problemu.

Skuteczne raportowanie błędów

Zgłaszanie błędów jest ważnym aspektem testowania oprogramowania. Skuteczny raport o błędzie dobrze komunikuje się z zespołem programistów i pozwala uniknąć nieporozumień i nieporozumień.

Powinien być dobry raport o błędzie jasne i zwięzłe bez brakujących punktów kluczowych. Wszelkie niejasności prowadzą do nieporozumień, a także spowalniają proces rozwoju. Pisanie i raportowanie błędów jest jednym z najważniejszych, ale zaniedbanych obszarów w cyklu życia testów.

Dobre pisanie jest bardzo ważne przy zgłaszaniu błędu. Najważniejszą kwestią, o której tester powinien pamiętać, jest nie używać rozkazującego tonu w raporcie. To łamie morale i tworzy niezdrową relację w pracy. Użyj sugestywnego tonu.

Nie zakładaj że programista popełnił błąd i dlatego możesz użyć ostrych słów. Przed zgłoszeniem równie ważne jest sprawdzenie, czy ten sam błąd został zgłoszony, czy nie.

Duplikat błędu jest obciążeniem w cyklu testowym. Sprawdź całą listę znanych błędów. Czasami programiści mogli znać problem i zignorować go w przyszłej wersji. Można również użyć narzędzi takich jak Bugzilla, które automatycznie wyszukują zduplikowane błędy. Najlepiej jednak ręcznie wyszukać każdy zduplikowany błąd.

Informacje o imporcie, które musi przekazać raport o błędzie, to 'W jaki sposób?' i gdzie?' Raport powinien jasno określać, w jaki sposób przeprowadzono test i gdzie dokładnie wystąpiła wada. Czytelnik powinien łatwo odtworzyć błąd i znaleźć, gdzie jest błąd.

Pamiętaj, że celem napisania raportu o błędzie polega na umożliwieniu programiście wizualizacji problemu. Powinien jasno zrozumieć usterkę z raportu błędu. Pamiętaj, aby podać wszystkie istotne informacje, których szuka deweloper.

Należy również pamiętać, że raport o błędzie zostałby zachowany do przyszłego użytku i powinien być dobrze napisany z wymaganymi informacjami. Używaj znaczących zdań i prostych słów opisać swoje błędy. Nie używaj mylących stwierdzeń, które marnują czas recenzenta.

Zgłoś każdy błąd jako osobny problem. W przypadku wielu problemów w jednym raporcie o błędzie nie można go zamknąć, chyba że wszystkie problemy zostaną rozwiązane.

Dlatego najlepiej podzielić problemy na osobne błędy . Gwarantuje to, że każdy błąd można obsłużyć oddzielnie. Dobrze napisany raport o błędzie pomaga programiście odtworzyć błąd na ich terminalu. Pomaga im to również zdiagnozować problem.

Jak zgłosić błąd?

Użyj następującego prostego szablonu raportu o błędzie:

To jest prosty format zgłoszenia błędu. Może się różnić w zależności od używanego narzędzia do zgłaszania błędów. Jeśli piszesz raport o błędzie ręcznie, niektóre pola muszą zostać wymienione, jak np. Numer błędu, który należy przypisać ręcznie.

Reporter: Twoje imię i nazwisko oraz adres e-mail.

Produkt: W którym produkcie znalazłeś ten błąd.

Wersja: Wersja produktu, jeśli istnieje.

Składnik: To są główne podmoduły produktu.

Platforma: Podaj platformę sprzętową, na której znalazłeś ten błąd. Różne platformy, takie jak „PC”, „MAC”, „HP”, „Sun” itp.

System operacyjny: Wymień wszystkie systemy operacyjne, w których znalazłeś błąd. Systemy operacyjne, takie jak Windows, Linux, Unix, SunOS, Mac OS. Wymień różne wersje systemu operacyjnego, takie jak Windows NT, Windows 2000, Windows XP itp., Jeśli dotyczy.

jaka jest najlepsza aplikacja do pobierania plików mp3 na Androida

Priorytet: Kiedy należy naprawić błąd? Priorytet jest generalnie ustawiany od P1 do P5. P1 jako „napraw błąd o najwyższym priorytecie”, a P5 jako „Napraw, gdy pozwala na to czas”.

Surowość: Opisuje wpływ błędu.
Rodzaje dotkliwości:

  • Blokujący: Nie można wykonywać żadnych dalszych prac testowych.
  • Krytyczny: Awaria aplikacji, utrata danych.
  • Poważny: Poważna utrata funkcji.
  • Mniejszy: Niewielka utrata funkcji.
  • Trywialny: Niektóre ulepszenia interfejsu użytkownika.
  • Wzmocnienie: Prośba o nową funkcję lub ulepszenie istniejącej.

Status: Gdy logujesz się do dowolnego systemu śledzenia błędów, domyślnie status błędu to „Nowy”.
Później błąd przechodzi przez różne etapy, takie jak Naprawiony, Zweryfikowany, Ponownie otwarty, Nie zostanie naprawiony itp.

=> Kliknij tutaj aby dowiedzieć się więcej o szczegółowym cyklu życia błędów.

Przypisać do: Jeśli wiesz, który programista jest odpowiedzialny za ten konkretny moduł, w którym wystąpił błąd, możesz podać adres e-mail tego programisty. W przeciwnym razie pozostaw to pole puste, ponieważ spowoduje to przypisanie błędu do właściciela modułu, jeśli nie, menedżer przydzieli błąd do dewelopera. Ewentualnie dodaj adres e-mail menedżera do listy DW.

URL: Adres URL strony, na której wystąpił błąd.

Podsumowanie: Krótkie podsumowanie błędu, w większości 60 słów lub poniżej. Upewnij się, że podsumowanie dotyczy problemu i jego lokalizacji.

Opis: Szczegółowy opis błędu.

Użyj następujących pól w polu opisu:

  • Odtwórz kroki: Wyraźnie wspomnij o krokach prowadzących do odtworzenia błędu.
  • Spodziewany wynik: Jak aplikacja powinna zachowywać się na wyżej wymienionych krokach.
  • Aktualny rezultat: Jaki jest rzeczywisty wynik wykonania powyższych kroków, tj. Zachowanie błędu.

To są ważne kroki w zgłoszeniu błędu. Możesz również dodać „Typ zgłoszenia” jako jeszcze jedno pole, które będzie opisywać typ błędu.

Typy raportów obejmują:

1) Błąd kodowania
2) Błąd projektowy
3) Nowa sugestia
4) Wydanie dokumentacji
5) Problem ze sprzętem

Ważne funkcje w raporcie o błędzie

Poniżej podano ważne funkcje raportu o błędzie:

# 1) Numer / identyfikator błędu

Numer błędu lub numer identyfikacyjny (np. Swb001) znacznie ułatwia zgłaszanie błędów i odwoływanie się do nich. Deweloper może łatwo sprawdzić, czy konkretny błąd został naprawiony, czy nie. Dzięki temu cały proces testowania i ponownego testowania jest płynniejszy i łatwiejszy.

# 2) Tytuł błędu

Tytuł błędu jest czytany częściej niż jakakolwiek inna część raportu o błędzie. Powinien mówić wszystko o tym, co zawiera błąd.

Tytuł błędu powinien być na tyle sugestywny, aby czytelnik mógł go zrozumieć. Jasny tytuł błędu ułatwia zrozumienie, a czytelnik może wiedzieć, czy błąd został zgłoszony wcześniej, czy został naprawiony.

# 3) Priorytet

Na podstawie wagi błędu można ustawić dla niego priorytet. Błąd może być blokujący, krytyczny, poważny, mniejszy, trywialny lub sugestia. Można nadać priorytet błędu od P1 do P5, tak aby ważne były najpierw przeglądane.

# 4) Platforma / środowisko

Konfiguracja systemu operacyjnego i przeglądarki jest niezbędna do jasnego zgłoszenia błędu. Jest to najlepszy sposób na poinformowanie, w jaki sposób można odtworzyć błąd.

Bez dokładnej platformy lub środowiska aplikacja może zachowywać się inaczej, a błąd po stronie testera może nie zostać odtworzony po stronie programisty. Dlatego najlepiej wyraźnie wspomnieć o środowisku, w którym wykryto błąd.

# 5) Opis

Opis błędu pomaga programiście zrozumieć błąd. Opisuje napotkany problem. Słaby opis wprowadzi zamieszanie i straci czas programistów i testerów.

Konieczne jest jasne poinformowanie o skutku opisu. Zawsze warto używać pełnych zdań. Dobrą praktyką jest opisanie każdego problemu z osobna, zamiast całkowitego ich niszczenia. Nie używaj terminów takich jak „myślę” lub „wierzę”.

# 6) Kroki do reprodukcji

Dobry raport o błędzie powinien jasno określać kroki do odtworzenia. Kroki powinny obejmować działania, które powodują błąd. Nie rób ogólnych stwierdzeń. Podaj konkretne kroki.

Dobry przykład dobrze napisanej procedury podano poniżej

Kroki:

  • Wybierz produkt Abc01.
  • Kliknij Dodaj do koszyka.
  • Kliknij Usuń, aby usunąć produkt z koszyka.

# 7) Oczekiwany i rzeczywisty wynik

Opis błędu jest niekompletny bez oczekiwanych i rzeczywistych wyników. Konieczne jest określenie, jaki jest wynik testu i czego powinien oczekiwać użytkownik. Czytelnik powinien wiedzieć, jaki jest prawidłowy wynik testu. Wyraźnie opisz, co wydarzyło się podczas testu i jaki był wynik.

# 8) Zrzut ekranu

Obraz jest wart tysiąca słów. Zrób zrzut ekranu przedstawiający awarię z odpowiednimi podpisami, aby podkreślić usterkę. Nieoczekiwane komunikaty o błędach wyróżnij jasnoczerwonym kolorem. To zwraca uwagę na wymagany obszar.

Kilka wskazówek dotyczących premii, aby napisać dobry raport o błędzie

Poniżej podano kilka dodatkowych wskazówek, jak napisać dobry raport o błędzie:

# 1) Natychmiast zgłoś problem

wymagane uwierzytelnienie nazwa użytkownika i hasło routera

Jeśli podczas testowania znajdziesz jakiś błąd, nie musisz czekać na późniejsze napisanie szczegółowego raportu o błędzie. Zamiast tego natychmiast napisz raport o błędzie. Zapewni to dobry i powtarzalny raport o błędzie. Jeśli zdecydujesz się napisać raport o błędzie później, istnieje duże prawdopodobieństwo, że przeoczysz ważne kroki w swoim zgłoszeniu.

# 2) Przed napisaniem raportu o błędzie należy trzykrotnie odtworzyć błąd

Twój błąd powinien dać się odtworzyć. Upewnij się, że Twoje kroki są wystarczająco solidne, aby odtworzyć błąd bez żadnych niejasności. Jeśli twój błąd nie daje się odtworzyć za każdym razem, możesz zgłosić błąd, wspominając o okresowej naturze błędu.

# 3) Przetestuj to samo wystąpienie błędu na innych podobnych modułach

Czasami programista używa tego samego kodu dla różnych podobnych modułów. Więc istnieje większe prawdopodobieństwo, że błąd w jednym module wystąpi również w innych podobnych modułach. Możesz nawet spróbować znaleźć poważniejszą wersję znalezionego błędu.

# 4) Napisz dobre podsumowanie błędu

Podsumowanie błędów pomoże programistom szybko przeanalizować charakter błędu. Raport niskiej jakości niepotrzebnie wydłuży czas programowania i testowania. Komunikuj się dobrze z podsumowaniem raportu o błędzie. Należy pamiętać, że podsumowanie błędów służy jako odniesienie do wyszukiwania błędu w spisie błędów.

# 5) Przeczytaj raport o błędzie przed naciśnięciem przycisku Prześlij

Przeczytaj wszystkie zdania, sformułowania i kroki użyte w zgłoszeniu błędu. Sprawdź, czy którekolwiek zdanie nie powoduje niejednoznaczności, która może prowadzić do błędnej interpretacji. Należy unikać wprowadzających w błąd słów lub zdań, aby uzyskać jasny raport o błędzie.

# 6) Nie używaj obraźliwego języka

Fajnie, że wykonałeś dobrą robotę i znalazłeś błąd, ale nie wykorzystuj tego kredytu do krytykowania programisty ani do atakowania jakiejkolwiek osoby.

Wniosek

Bez wątpienia twój raport o błędzie powinien być dokumentem wysokiej jakości.

Skoncentruj się na pisaniu dobrych raportów o błędach i poświęć trochę czasu na to zadanie, ponieważ jest to główny punkt komunikacji między testerem, programistą i menedżerem. Menedżerowie powinni uświadomić swojemu zespołowi, że napisanie dobrego raportu o błędzie jest głównym obowiązkiem każdego testera.

Twoje wysiłki zmierzające do napisania dobrego raportu o błędzie nie tylko zaoszczędzą zasoby firmy, ale także stworzą dobre relacje między tobą a programistami.

Aby zwiększyć produktywność, napisz lepszy raport o błędzie.

Czy jesteś ekspertem w pisaniu raportu o błędzie? Podziel się swoimi przemyśleniami w sekcji komentarzy poniżej.

rekomendowane lektury

^