Why good Bug Report?

Jeśli twój raport o błędzie jest skuteczny, wtedy jego szanse na naprawę są większe. Tak więc naprawa błędu zależy od tego, jak skutecznie go zgłosisz. Raportowanie błędów jest niczym innym jak umiejętnością i wyjaśnię, jak tę umiejętność osiągnąć.

„Celem pisania raportu o problemie (raportu o błędzie) jest naprawienie błędu” – Cem Kaner. Jeśli tester nie zgłosi błędu poprawnie, programista najprawdopodobniej odrzuci ten błąd stwierdzając, że jest on niereprodukowalny.

To może zranić morale testera, a czasami także jego ego. (Sugeruję, aby nie utrzymywać żadnego rodzaju ego. Ego typu „Zgłosiłem błąd poprawnie”, „Mogę go odtworzyć”, „Dlaczego on/ona odrzucił błąd?”, „To nie moja wina” itd.).

What Are The Qualities Of A Good Software Bug Report?

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

Powinieneś być w stanie odróżnić przeciętny raport o błędach od dobrego raportu o błędach. Jak odróżnić dobry raport o błędach od złego? To bardzo proste, zastosuj poniższe cechy i techniki, aby zgłosić błąd.

Charakterystyki i techniki obejmują

#1) Posiadanie jasno określonego Numeru Błędu: Zawsze przypisuj unikalny numer do każdego zgłoszenia błędu. To z kolei pomoże ci zidentyfikować zgłoszenie błędu. Jeśli używasz jakiegokolwiek zautomatyzowanego narzędzia do zgłaszania błędów, ten unikalny numer będzie generowany automatycznie za każdym razem, gdy zgłaszasz błąd.

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

#2) Odtwarzalność: Jeśli twój błąd nie jest powtarzalny, to nigdy nie zostanie naprawiony.

Powinieneś jasno opisać kroki, które należy podjąć, aby odtworzyć błąd. Nie zakładaj ani nie pomijaj żadnego kroku reprodukcji. Błąd, który jest opisany krok po kroku jest łatwy do odtworzenia i naprawienia.

#3) Bądź konkretny: Nie pisz eseju o problemie.

Bądź konkretny i w punkt. Postaraj się streścić problem w minimalnej ilości słów, ale w skuteczny sposób. Nie należy łączyć wielu problemów, nawet jeśli wydają się podobne. Napisz inny raport dla każdego problemu.

Efektywne raportowanie błędów

Raportowanie błędów jest ważnym aspektem testowania oprogramowania. Skuteczny raport o błędach dobrze komunikuje się z zespołem programistów i pozwala uniknąć nieporozumień lub błędnej komunikacji.

Dobry raport o błędach powinien być jasny i zwięzły, bez brakujących kluczowych punktów. Każdy brak jasności prowadzi do nieporozumień i spowalnia proces rozwoju, jak również. Pisanie i raportowanie błędów jest jednym z najważniejszych, ale zaniedbanych obszarów w cyklu życia testowania.

Dobre pisanie jest bardzo ważne przy zgłaszaniu błędów. Najważniejszym punktem, o którym tester powinien pamiętać, jest to, aby nie używać rozkazującego tonu w raporcie. To łamie morale i tworzy niezdrowe relacje w pracy. Używaj sugestywnego tonu.

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

Zduplikowany błąd jest obciążeniem w cyklu testowania. Sprawdź całą listę znanych błędów. Czasami, deweloperzy mogli znać problem i zignorować go dla przyszłego wydania. Narzędzia takie jak Bugzilla, które automatycznie wyszukują zduplikowane błędy, mogą być również użyte. Jednakże, najlepiej jest ręcznie wyszukać każdy zduplikowany błąd.

Informacje importowe, które musi przekazać raport o błędzie to „Jak?” i „Gdzie?”. Raport powinien jasno odpowiadać, jak test został wykonany i gdzie dokładnie wystąpił defekt. Czytelnik powinien łatwo odtworzyć błąd i znaleźć miejsce jego wystąpienia.

Pamiętaj, że celem pisania raportu o błędzie jest umożliwienie programiście wizualizacji problemu. On/ona powinien jasno zrozumieć defekt z raportu o błędzie. Pamiętaj, aby podać wszystkie istotne informacje, których poszukuje programista.

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

Zgłaszaj każdy błąd jako oddzielne zagadnienie. W przypadku wielu problemów w jednym raporcie błędu, nie możesz go zamknąć dopóki wszystkie problemy nie zostaną rozwiązane.

Więc najlepiej jest podzielić problemy na osobne błędy. Zapewnia to, że każdy błąd może być obsługiwany oddzielnie. Dobrze napisany raport błędu pomaga programiście odtworzyć błąd na swoim terminalu. To pomaga im również zdiagnozować problem.

Jak zgłosić błąd?

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

To jest prosty format raportu o błędzie. Może się on różnić w zależności od narzędzia do zgłaszania błędów, którego używasz. Jeśli piszesz raport ręcznie, niektóre pola muszą być wymienione specjalnie, jak np. numer błędu, który powinien być przypisany ręcznie.

Reporter: Twoje imię i adres e-mail.

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

Wersja: Wersja produktu, jeśli istnieje.

Component: Są to główne podmoduły produktu.

Platforma: Wymień 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. Wspomnij także o różnych wersjach systemu operacyjnego, takich jak Windows NT, Windows 2000, Windows XP etc, jeśli dotyczy.

Priorytet: Kiedy błąd powinien zostać naprawiony? Priorytet jest zazwyczaj ustalany od P1 do P5. P1 jako „Napraw błąd z najwyższym priorytetem” i P5 jako „Napraw, gdy czas na to pozwoli”.

Severity: To opisuje wpływ błędu.
Typy dotkliwości:

• Blocker: Nie można wykonać dalszych prac testowych.
• Critical: Awaria aplikacji, Utrata danych.
• Major: Poważna utrata funkcji.
• Drobna: Niewielka utrata funkcji.
• Trywialne: Niektóre ulepszenia UI.
• Ulepszenie: Prośba o nową funkcję lub pewne ulepszenie istniejącej.

Status: Kiedy logujesz błąd do jakiegokolwiek systemu śledzenia błędów, wtedy domyślnie status błędu będzie 'Nowy’.
Później, błąd przechodzi przez różne etapy jak Naprawiony, Zweryfikowany, Ponownie otwarty, Nie Naprawię, etc.

=> Kliknij tutaj aby przeczytać więcej o szczegółowym cyklu życia błędu.

Przydziel 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, Menadżer przypisze błąd do dewelopera. Ewentualnie dodaj adres e-mail menedżera do listy CC.

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

Summary: Krótkie podsumowanie błędu, najczęściej w 60 słowach lub poniżej. Upewnij się, że podsumowanie odzwierciedla to, na czym polega problem i gdzie on występuje.

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

Użyj następujących pól dla pola opisu:

• Kroki odtworzenia: Wyraźnie, wymień kroki, aby odtworzyć błąd.
• Oczekiwany rezultat: Jak powinna zachowywać się aplikacja po wykonaniu wyżej wymienionych kroków.
• Rzeczywisty wynik: Jaki jest rzeczywisty rezultat wykonania powyższych kroków, tj. zachowanie błędu.

To są ważne kroki w raporcie błędu. Możesz także dodać „Typ raportu” jako jeszcze jedno pole, które będzie opisywać typ błędu.

Typy raportów zawierają:

1) Błąd kodowania
2) Błąd projektu
3) Nowa sugestia
4) Problem z dokumentacją
5) Problem ze sprzętem

Important Features In Your Bug Report

Poniżej podano ważne cechy raportu o błędach:

#1) Bug Number/id

Numer błędu lub numer identyfikacyjny (jak swb001) sprawia, że zgłaszanie błędów i odnoszenie się do nich jest znacznie łatwiejsze. Programista może łatwo sprawdzić czy dany błąd został naprawiony czy nie. To sprawia, że cały proces testowania i ponownego testowania jest gładszy i łatwiejszy.

#2) Tytuł błędu

Tytuł błędu jest czytany częściej niż jakakolwiek inna część raportu o błędzie. Powinien on mówić wszystko o tym, co znajduje się w błędzie.

Tytuł błędu powinien być na tyle sugestywny, aby czytelnik mógł go zrozumieć. Jasny tytuł błędu sprawia, że jest on łatwy do zrozumienia i czytelnik może wiedzieć, czy błąd został zgłoszony wcześniej lub czy został naprawiony.

#3) Priorytet

W oparciu o wagę błędu, priorytet może być dla niego ustalony. Błąd może być Blocker, Critical, Major, Minor, Trivial, lub sugestią. Priorytet błędu od P1 do P5 może być nadany tak, aby ważne błędy były przeglądane w pierwszej kolejności.

#4) Platforma/środowisko

Konfiguracja systemu operacyjnego i przeglądarki jest niezbędna do przejrzystego zgłoszenia błędu. Jest to najlepszy sposób na przekazanie informacji o tym, jak błąd może zostać odtworzony.

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

#5) Opis

Opis błędu pomaga deweloperowi zrozumieć błąd. Opisuje on napotkany problem. Zły opis spowoduje zamieszanie i zmarnuje czas deweloperów i testerów, jak również.

Niezbędne jest jasne komunikowanie o skutkach opisu. Zawsze pomocne jest używanie pełnych zdań. Dobrą praktyką jest opisywanie każdego problemu osobno, zamiast rozkładania ich na czynniki pierwsze. Nie używaj określeń takich jak „myślę” lub „wierzę”.

#6) Kroki do odtworzenia

Dobry raport o błędzie powinien jasno wymieniać kroki do odtworzenia. Kroki powinny zawierać działania, które powodują błąd. Nie rób ogólnych stwierdzeń. Bądź konkretny w krokach do wykonania.

Dobry przykład dobrze napisanej procedury jest podany poniżej

Kroki:

• Wybierz produkt Abc01.
• Kliknij na 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 nakreślenie, jaki jest wynik testu i czego użytkownik powinien się spodziewać. Czytelnik powinien wiedzieć, jaki jest prawidłowy wynik testu. Wyraźnie wspomnij, co się stało podczas testu i jaki był wynik.

#8) Zrzut ekranu

Obraz jest wart tysiąca słów. Zrób zrzut ekranu przedstawiający przypadek awarii z odpowiednimi podpisami, aby podkreślić defekt. Podkreśl nieoczekiwane komunikaty o błędach jasnoczerwonym kolorem. To przyciąga uwagę do wymaganego obszaru.

Kilka dodatkowych wskazówek do napisania dobrego raportu o błędach

Poniżej podano kilka dodatkowych wskazówek do napisania dobrego raportu o błędach:

#1) Zgłoś problem natychmiast

Jeśli znajdziesz jakikolwiek błąd podczas testowania, nie musisz czekać, aby napisać szczegółowy raport o błędach później. Zamiast tego, napisz raport o błędzie natychmiast. To zapewni dobry i powtarzalny raport o błędach. Jeśli zdecydujesz się napisać raport o błędzie później, wtedy są duże szanse na pominięcie ważnych kroków w twoim raporcie.

#2) Odtwórz błąd trzy razy przed napisaniem raportu o błędzie

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

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

Czasami programista używa tego samego kodu dla różnych podobnych modułów. Istnieją więc większe szanse, że błąd w jednym module wystąpi również w innych podobnych modułach. Możesz nawet spróbować znaleźć poważniejszą wersję błędu, który znalazłeś.

#4) Napisz dobre podsumowanie błędu

Podsumowanie błędu pomoże deweloperom szybko przeanalizować naturę błędu. Słabej jakości raport niepotrzebnie wydłuży czas rozwoju i testowania. Komunikuj się dobrze z podsumowaniem swojego raportu błędów. Pamiętaj, że streszczenie błędu jest używane jako odniesienie do wyszukiwania błędów w spisie błędów.

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

Przeczytaj wszystkie zdania, sformułowania i kroki, które są użyte w raporcie o błędzie. Sprawdź, czy jakieś zdanie nie tworzy dwuznaczności, która może prowadzić do błędnej interpretacji. Mylące słowa lub zdania powinny być unikane w celu uzyskania jasnego raportu błędu.

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

To miło, że wykonałeś dobrą robotę i znalazłeś błąd, ale nie używaj tego kredytu do krytykowania dewelopera lub atakowania jakiejkolwiek osoby.

Konkluzja

Nie ma wątpliwości, że twój raport błędów powinien być dokumentem wysokiej jakości.

Skup się na pisaniu dobrych raportów błędów i poświęć trochę czasu na to zadanie, ponieważ jest to główny punkt komunikacji pomiędzy testerem, deweloperem i menedżerem. Menedżerowie powinni uświadomić swojemu zespołowi, że pisanie dobrych raportów błędów jest podstawowym obowiązkiem każdego testera.