How to Write a Bug Report with Examples

Co to jest raport o błędzie? Dlaczego potrzebujesz dobrego raportu o błędach?

Raport o błędzie to ważny dokument w STLC, który oferuje zespołowi testującemu szereg korzyści. track wszystkich defektów, błędów, pomyłek i innych niezgodności wykrytych podczas testowania oprogramowania i raportuje je.

Celem tej dokumentacji potestowej jest dostarczenie zainteresowanemu zespołowi specjalistów informacji na temat poziomu błędów napotkanych podczas procesu testowania.

Twoje inżynier rozwoju oprogramowania can be made aware of all the defects and issues present in the software using this type of report. It also lets you figure out what is wrong with a bug, so you can use the best method to fix it. It also helps you to save your time and money by helping wyłapujesz błędy i problemy.

Dlaczego warto dbać o dobre wyjaśnienia błędów?

Oto kwestia, którą należy wziąć pod uwagę, pisząc dobry, szczegółowy raport o błędach oprogramowania:

• Działa jako przewodnik pomagający uniknąć tego samego błędu w przyszłych wydaniach.
• Oszczędź czas na komunikację (e-maile, połączenia telefoniczne).
• Less pracuj dla programistów (zrobią dokładnie to, czego chcesz).
• Będziesz mieć mniej wąskich gardeł w projekcie; błędy będą naprawiane szybciej i skuteczniej.
• Modern teams using Jira, Linear, or Azure DevOps can also link bug reports to sprint tickets and release pipelines, ensuring traceability across QA and DevOps workflows.

Jak napisać raport o błędzie (szablon raportu o błędzie)

Nie ma konkretnego szablonu zgłaszania błędów, ponieważ zależy to od Twojego błędu.tracsystem królewski. Twój szablon może być inny.

Jednakże zawsze, gdy chcesz napisać raport o błędzie, potrzebne są następujące wspólne pola:

• Identyfikator błędu/tytuł.
• Ważność i priorytet.
• OPIS
• Środowisko
• Kroki ku reprodukcji.
• Spodziewany wynik.
• Aktualny rezultat.
• Załączniki (zrzuty ekranu, filmy, tekst)

Let us look at all these bug-tracking components one by one:

1) Tytuł/identyfikator błędu:

Każdy błąd powinien mieć unikalny numer identyfikacyjny. Narzędzia do zgłaszania błędów powinny mieć unikalne numery dla nowo zgłoszonych błędów, abyśmy mogli łatwo zidentyfikować błąd.

Przykłady:

❌ Źle: „Ponownie nie widzę produktu, piszę, że nie.”

• Niejasny
• Agresywny
• Zbyt rozwlekłe

zwraca się z prośbą o wdrożenie rozwiązania.

✅ Dobrze: „KOSZYK – Nowe pozycje dodane do koszyka, które się nie pojawiają”.

• Ten rodzaj tytułu natychmiast lokalizuje problem (KOSZYK)
• Koncentruje się na rzeczywistym problemie technicznym.

2) Waga błędu:

Ważność błędu jest bardzo ważnym czynnikiem w raporcie o błędzie. Opisuje wpływ defektu na działanie aplikacji.

• Blokery: Ten błąd powoduje awarię aplikacji.
• Kierunek: Błąd krytyczny wskazuje na poważną zmianę w logice biznesowej.
• Mniejszy: Problem, który nie wpływa na funkcjonalność aplikacji, ale wpływa na oczekiwane rezultaty.
• Trywialny: Nie wpływa to na funkcjonalność ani działanie aplikacji. Może to być błąd typograficzny.

3) Priorytet błędu:

Poniżej przedstawiono ogólną gradację służącą do określania priorytetu błędów:

• Wysoka: Obejmuje wszystko, co wpływa na przepływ lub blokuje korzystanie z aplikacji.
• Medium: Wpływa to niekorzystnie na doświadczenie użytkownika.
• Mniejszy: Wszystkie inne błędy, takie jak (literówki, brakujące ikony, problemy z układem itp.).

4) Środowisko:

Błąd może pojawić się w określonym środowisku, a nie w innym. Na przykład czasami pojawia się błąd podczas uruchamiania strony internetowej Firefoxlub nieprawidłowe działanie aplikacji tylko podczas pracy na komputerze Android urządzenie i działa dobrze na iPhonie.

Te raporty o błędach można zidentyfikować jedynie podczas testów w różnych przeglądarkach lub na różnych urządzeniach. Dlatego zgłaszając błąd, osoby odpowiedzialne za kontrolę jakości powinny być w stanie określić, czy błąd powinien zostać zaobserwowany w jednym, czy w większej liczbie określonych środowisk.

5) Podsumowanie:

However, adding only the Title in the bug report does not serve the purpose. So, if your Title is not enough, you can add a short report summary.

Twoje podsumowanie w jak najmniejszej liczbie słów, zawierające informację o tym, kiedy i jak wystąpił błąd. Twój tytuł i opis błędu powinny być również używane podczas wyszukiwania, dlatego musisz upewnić się, że uwzględniłeś ważne słowa kluczowe.

Przykłady:

• Źle: „Próbowałem dodać coś do testu, ale nic się nie pojawiło, gdy to zrobiłem lub kliknąłem przycisk”.
• Dobry: „Kiedy próbowałem dodać [PRODUKT] do sklepuping „dodałem produkt do koszyka, ale nic się nie działo, gdy kliknąłem przycisk „Dodaj” na stronie z przeglądem konkretnego produktu.”

6) Kroki do odtworzenia:

When reporting a bug, it is important to specify the steps to reproduce it. You should also include actions that may cause the bug. Here, do not make any generic statements.

Określ szczegółowo kroki, jakie należy wykonać:

Oto przykład dobrze napisanej procedury:

Kroki:

1. Wybierz produkt X1.
2. Kliknij Dodaj do koszyka.
3. Kliknij Usuń, aby usunąć produkt z koszyka.

7) Oczekiwany wynik:

W raportach błędów ważne jest opisanie oczekiwanego wyniku według zadania technicznego, projektu wyników przypadku testowego lub zgodnie z opinią testera. Wszystko to pomaga programistom skoncentrować się na szybkim znalezieniu potrzebnych informacji.

Na przykład:

Wymagane pola powinny zostać podświetlone na czerwono po kliknięciu przycisku „Prześlij”.

8) Rzeczywisty wynik:

Jak sama nazwa wskazuje, to pole opisuje rzeczywisty efekt błędu. Bardzo ważne jest, aby napisać jasny opis rzeczywistego wyniku.

Na przykład:

Pola wymagane są podświetlane na zielono po kliknięciu przycisku „Wyślij”.

9) Załączniki (zrzuty ekranu i filmy):

W przypadku raportów o błędach najlepszą praktyką jest załączanie plików do raportów o błędach, co ułatwia dostrzeżenie informacji, gdy trzeba je wyświetlić wizualnie:

Na przykład:

• Screenshot: Zrzuty ekranu pozwalają łatwo skorygować błędy w programie; jest to wygodne, gdy błąd jest wyróżniony określoną adnotacją, okręgiem lub obrazem strzałki).
• Wideo: Sometimes, it is difficult to describe the bug in words, so it is better to create a video so that developer can rectify the defect in the program).

10) Wersja, której dotyczy problem:

Jest to wersja oprogramowania, której dotyczy problem, w której zgłaszany jest błąd.

11) Napraw wersję:

Jest to wersja oprogramowania, w której usunięto błąd. Kiedy więc osoba przeprowadzająca kontrolę jakości, która zgłosiła błąd, sprawdza, czy została naprawiona, używa właściwej wersji oprogramowania.

12) Target wersja:

Wersja docelowa, w której błąd powinien zostać naprawiony. Dlatego też, gdy zespół programistów pracuje nad naprawieniem błędu, jego celem jest głównie konkretna wersja aplikacji.

13) Data zamknięcia:

Jest to data zamknięcia błędu przez zespół testujący oprogramowanie. Zamykanie błędu jest istotną i integralną częścią testowania oprogramowania.

14) Stan:

Kiedy zostanie utworzony nowy błąd, jego status powinien być otwarty. Następnie przechodzi przez etapy takie jak W toku, Naprawiono, Działa, Ponownie otwiera itp.

Wskazówki dotyczące pisania raportów o błędach

Oto kilka ważnych wskazówek, o których warto pamiętać podczas pisania skutecznego raportu o błędzie:

• Be specific when creating bug reports. Make sure you do not include any useless or irrelevant facts.
• Musisz zgłosić błąd natychmiast po jego wykryciu.
• Przygotuj szczegółowy raport, aby umożliwić programiście wykorzystanie faktów i informacji do debugowania problemu.
• Powinieneś przetestować to samo wystąpienie błędu w innych podobnych modułach w celu sprawdzenia poprawności.
• Revprzejrzyj raport o błędzie przynajmniej raz przed jego przesłaniem.
• Należy upewnić się, że raport o błędzie zawiera opis tylko jednego błędu.
• Wreszcie, nie powinieneś bać się poprosić Menedżera Projektu o pomoc, jeśli czujesz się niejasny w jakiejś kwestii.
• Use AI-assisted triage features in Jira or Linear to auto-classify severity, suggest duplicates, and route the report to the right component owner.

Narzędzia do raportowania błędów

Proces raportowania błędów, wykonywany ręcznie, jest obecnie realizowany za pomocą różnych narzędzi do raportowania błędów dostępnych na rynku.

• Jira
• Liniowy
• Azure DevOps
• Błąd Zoho Tracker
• Bugzilla

Możesz sprawdzić naszą szczegółową recenzję najlepsze narzędzie do zgłaszania błędów.

Typowy problem i rozwiązanie podczas pisania raportu o błędzie:

Oto kilka typowych problemów i ich rozwiązań podczas pisania raportu o błędzie:

Przykład raportu o błędzie	Problem
Przy mnożeniu 2 przez 3 odpowiedź będzie dodatnia.	Zgłoś wzór, a nie przykład.
Aby tego uniknąć, podczas dodawania nowego elementu lista zostanie uporządkowana alfabetycznie.	Do not only describe what is wrong
Na przykład: Aby to zrobić, musisz otworzyć przeglądarkę i wpisać adres witryny URL. You will find the first field, ‘username,’ misspelled.	Zawsze bezpośrednio do rzeczy (Nigdy nie opowiadaj historii!).
Imię i nazwisko klienta w raporcie zostało błędnie zapisane. Priorytet: wysoki, ważność: wysoki	Nigdy nie mieszaj priorytetu i wagi.
Wzór obliczenia podatku jest NIEPRAWIDŁOWY !!??	Nie używa wielkich liter, czerwonych liter, czerwonych kółek, „!”,
I do not think that the home page Ul design is good.	Do not use your judgment.
Przykład niejasnego opisu: W związku z naszą dzisiejszą dyskusją, wykonaj wymagane działania dla tej strony.	Spraw, aby Twój opis był zrozumiały dla każdego.
Tło strony powinno być niebieskie, pomarańczowe lub zielone. Możesz też ustawić je w kolorze czarnym lub białym. Nie jest to dobre rozwiązanie, ponieważ nie jest jasne, czego potrzebuje zespół zajmujący się tworzeniem i projektowaniem stron internetowych	Zminimalizuj opcje
Formuła obliczania podatku czasami nie działa zgodnie z oczekiwaniami.	The golden rule: Do not use the word ‘Sometimes’.

Przykład raportu o błędzie

Oto mały przykład raportu o błędzie:

[MOJE KONTO] Podkreślenie jest wyświetlane po najechaniu myszką na przycisk Aktualizuj.

Descriptjon: Musimy usunąć podkreślenie po najechaniu myszką na przycisk Aktualizuj w sekcji Moje konto.

Połączyć: http://test.com/mv-account/

Przeglądarka/system operacyjny: Chrome 25. OSX Yosemite 10.10.2

Kroki ku reprodukcji:

1. Przejdź do www.test.com

2. Zaloguj się za pomocą danych logowania

3. Przejdź do Mojego konta

4. Najedź myszką na przycisk Aktualizuj

Aktualny rezultat: jest podkreślenie.

Spodziewany wynik: bez podkreślenia.

Dane logowania: test@test.com / mysecretpass12

Należy unikać błędów w pisaniu raportów o błędach

Oto kilka ważnych błędów, których należy unikać podczas pisania raportu o błędzie:

• Do not write about your dissatisfaction, and never include your personal feelings.
• Irytuje to osoby, które chcą się skupić na zadaniu, gdy przeładowujesz swój post wieloma emotikonami.
• Nigdy nie przeciążaj swojego postu wykrzyknikami; nie przyspiesza to pracy.
• Nikt nie chce czuć się urażony. Niszczy motywację i spowalnia realizację problemu.

FAQ