Jak poprawnie zgłosić błąd: praktyczny przewodnik po raporcie, którego nikt nie odrzuci

Jak poprawnie zgłosić błąd? Tak, żeby osoba, która go dostanie, mogła go zrozumieć, odtworzyć i ocenić bez dopytywania. Dobry raport błędu ma konkretny tytuł, ponumerowane kroki odtworzenia, osobno wynik oczekiwany i rzeczywisty, dane środowiska, ważność, priorytet i dowody. ISTQB definiuje raport defektu jako dokumentację wystąpienia, charakteru i statusu defektu, a cała reszta tego artykułu to praktyka, jak tę definicję wypełnić treścią.

Samo znalezienie defektu to połowa pracy. Druga połowa to opis, który nie wraca z komentarzem „u mnie działa”. Poniżej dostajecie gotowy szablon zgłoszenia do skopiowania w wersji Markdown i Jira, wypełniony przykład, macierz priorytetu i ważności oraz listę kontrolną na 30 sekund przed kliknięciem „Utwórz”.

Te liczby pochodzą z badania sprzed lat, ale opisują rzecz, która się nie zestarzała: to, czego deweloper potrzebuje najbardziej, jest jednocześnie najtrudniejsze do napisania. Dlatego warto mieć standard i szablon, zamiast liczyć na to, że każdy tester sam wymyśli dobrą strukturę.

Jak poprawnie zgłosić błąd: co powinien zawierać raport?

Jak poprawnie zgłosić błąd, gdy w zespole każdy pisze inaczej? Zacząć od struktury. Dobry raport błędu ma powtarzalną strukturę, w której każde pole odpowiada na jedno pytanie osoby naprawiającej. Nie chodzi o biurokrację, tylko o to, żeby deweloper nie szukał tych samych informacji w trzech miejscach. Poniższa tabela pokazuje pola, które warto mieć w każdym zgłoszeniu, i to, na co odpowiadają.

Nie każde zgłoszenie musi być długie. Literówka w stopce nie potrzebuje pliku HAR. Ważne jest, żeby raport był kompletny dla swojego problemu, a decyzję, które pola są obowiązkowe, zespół podejmuje raz, w szablonie, a nie przy każdym tickecie. Jeśli chcecie przećwiczyć pisanie raportów, przypadków testowych i checklist na realnych przykładach, robimy to na szkoleniu Tworzenie dokumentacji testowej.

Jak napisać tytuł zgłoszenia, który od razu mówi, co się psuje?

Jak poprawnie zgłosić błąd, jeśli ktoś przeczyta tylko tytuł? Tak, żeby sam tytuł wystarczył do triage. Tytuł to pierwsze, co widzi deweloper, lider QA i Product Owner, często tylko na liście w backlogu. Wytyczne Mozilla Bug Writing Guidelines radzą, żeby podsumowanie zmieściło się w mniej niż 60 znakach i opisywało problem, a nie proponowane rozwiązanie. Dobry tytuł odpowiada na trzy pytania: którego obszaru dotyczy błąd, co dzieje się nieprawidłowo i w jakim kontekście.

Dobry tytuł ułatwia też wyszukiwanie duplikatów i rozmowę na triage. Tytuł „Nie działa” ma jedną zaletę: pasuje do każdego błędu w historii informatyki, łącznie z tymi, których jeszcze nie popełniono.

Jak opisać kroki odtworzenia, wynik oczekiwany i rzeczywisty?

Jeśli macie zapamiętać jedną rzecz o tym, jak poprawnie zgłosić błąd, niech to będą kroki. Kroki odtworzenia to najważniejsza część zgłoszenia, co potwierdza zarówno badanie Bettenburga z 2008 roku, jak i wytyczne Mozilli, które nazywają je wprost najważniejszą częścią każdego raportu. Zapisujecie je jako ponumerowaną listę prostych czynności, wykonalnych przez osobę, która nie siedziała obok Was podczas testów. Każdy krok to jedna akcja, bez skrótów typu „zaloguj się i przejdź do koszyka”.

1. Wejdź na stronę sklepu w środowisku staging.
2. Kliknij „Moje konto” w prawym górnym rogu.
3. Wpisz adres e-mail aktywnego konta testowego qa.client@example.com.
4. Wpisz poprawne hasło do tego konta.
5. Kliknij przycisk „Zaloguj”.
6. Obserwuj stronę, na którą trafia użytkownik.

Zaraz pod krokami dwa osobne pola. Wynik oczekiwany: użytkownik zostaje zalogowany i trafia do panelu klienta. Wynik rzeczywisty: aplikacja przekierowuje na stronę błędu 404, użytkownik nie jest zalogowany. Różnica między nimi to istota defektu. W testach automatycznych to samo porównanie wykonuje asercja, o czym piszemy w artykule o asercjach w Selenium.

Jeśli błąd jest sprzeczny z konkretnym wymaganiem albo kryterium akceptacji, podajcie jego numer. To ucina spór „błąd czy funkcja”, zanim się zacznie. Jeśli błąd pojawia się tylko czasem, napiszcie, jak często: „3 na 10 prób” mówi deweloperowi znacznie więcej niż „czasami”.

Czym różni się priorytet od ważności błędu?

Ważność (severity) mówi, jak mocno błąd wpływa na działanie produktu. Priorytet (priority) mówi, jak szybko trzeba go naprawić. Ważność ocenia zwykle tester, myśląc jak inżynier, a priorytet ustala Product Owner albo zespół na triage, myśląc jak biznes. Te dwie oceny często się rozjeżdżają, i to jest w porządku.

Praktyczna skala ważności, którą możecie przyjąć od razu:

• Bloker: uniemożliwia korzystanie z aplikacji albo blokuje dalsze testy.
• Krytyczny: dotyczy kluczowej funkcji, danych, płatności albo bezpieczeństwa.
• Wysoki: mocno utrudnia działanie, ale istnieje obejście.
• Średni: utrudnia korzystanie z funkcji, nie blokuje głównego procesu.
• Niski: drobny defekt wizualny albo tekstowy bez wpływu na kluczowe funkcje.

Jeśli w Waszym zespole priorytety ustala ten, kto głośniej mówi na daily, to znak, że brakuje zasad triage. Uporządkowanie tego procesu ćwiczymy na szkoleniu Zarządzanie testami oprogramowania.

Jakie dane o środowisku i jakie załączniki dodać?

Ten sam błąd może występować na stagingu, a na produkcji nie, tylko w jednej przeglądarce, tylko dla jednej roli albo tylko na konkretnych danych. Bez opisu środowiska deweloper testuje w innych warunkach i nigdy nie zobaczy Waszego problemu. Minimum to: środowisko i adres URL, wersja aplikacji albo numer buildu, przeglądarka z wersją, system operacyjny, urządzenie i rozdzielczość, rola użytkownika oraz dane testowe, jeśli mają znaczenie.

Gotowy szablon zgłoszenia błędu do skopiowania

Najprostsza odpowiedź na pytanie, jak poprawnie zgłosić błąd w Waszym narzędziu, to gotowy szablon. Poniżej ten sam szablon w dwóch wersjach. Wersja Markdown sprawdzi się w GitHub Issues, GitLab, Azure DevOps i w Jira Cloud, której edytor rozpoznaje skróty Markdown podczas pisania. Wersja w notacji wiki przyda się tam, gdzie pole opisu używa renderera wiki, co spotkacie głównie w instalacjach Jira Data Center. Skopiujcie, usuńcie nawiasy, wypełnijcie.

Szablon w Markdown

## Tytuł
[Obszar]: [co się dzieje] [w jakich warunkach]

## Opis i wpływ
[1 do 3 zdań: czego dotyczy błąd, kogo dotyka, czy blokuje testy lub release]

## Kroki odtworzenia
1. [krok]
2. [krok]
3. [krok]

## Wynik oczekiwany
[co powinno się stać, z odwołaniem do wymagania lub kryterium akceptacji]

## Wynik rzeczywisty
[co stało się naprawdę, z dokładnym komunikatem błędu]

## Środowisko
- Środowisko i URL: [staging / test / produkcja, adres]
- Wersja aplikacji lub build: [numer]
- Przeglądarka lub urządzenie: [nazwa i wersja]
- System: [nazwa i wersja]
- Rola i konto testowe: [rola, login]

## Częstotliwość
[np. 10 na 10 prób / 3 na 10 prób]

## Ważność i priorytet
- Ważność: [bloker / krytyczny / wysoki / średni / niski]
- Priorytet: [proponowany, ostatecznie ustala triage]

## Dowody
- [nagranie, zrzut, log z konsoli, plik HAR oczyszczony]

## Powiązania
- [user story, przypadek testowy, podobne zgłoszenia]

Szablon w notacji wiki dla Jira

h3. Opis i wpływ
[1 do 3 zdań: czego dotyczy błąd, kogo dotyka, czy blokuje testy lub release]

h3. Kroki odtworzenia
# [krok]
# [krok]
# [krok]

h3. Wynik oczekiwany
[co powinno się stać]

h3. Wynik rzeczywisty
[co stało się naprawdę]
{code}
[dokładny komunikat błędu lub fragment logu]
{code}

h3. Środowisko
||Pole||Wartość||
|Środowisko i URL|[staging, adres]|
|Wersja lub build|[numer]|
|Przeglądarka|[nazwa i wersja]|
|System|[nazwa i wersja]|
|Rola i konto|[rola, login]|

h3. Częstotliwość
[np. 3 na 10 prób]

h3. Dowody
* [nagranie]
* [log z konsoli]
* [plik HAR oczyszczony]

Tytuł, ważność, priorytet i komponent w Jira wpisujecie w osobne pola formularza, nie w opis, bo tylko wtedy da się po nich filtrować i budować raporty. Składnię notacji wiki opisuje dokumentacja Atlassian Wiki Markup, a sam szablon najlepiej ustawić jako domyślną treść pola opisu dla typu zgłoszenia Bug, żeby nikt nie musiał go kopiować. Konfigurację szablonów i workflow w Jira przechodzimy krok po kroku na szkoleniu JIRA dla testerów.

Przykład wypełnionego zgłoszenia

Co zrobić z duplikatem i z błędem, którego nie da się odtworzyć?

Przed utworzeniem zgłoszenia przeszukajcie backlog po nazwie funkcji, komunikacie błędu, kodzie HTTP, adresie URL, nazwie przycisku i słowach z planowanego tytułu. Jeśli podobne zgłoszenie istnieje, dopiszcie do niego komentarz z nowym środowiskiem, nagraniem albo logiem, zamiast tworzyć nowe. Osobne zgłoszenie ma sens dopiero wtedy, gdy objaw jest podobny, ale przyczyna, obszar albo potrzebna poprawka są inne.

Błąd, którego nie umiecie powtórzyć na żądanie, też warto zgłosić, ale uczciwie. Napiszcie, ile razy wystąpił na ile prób, o której godzinie, na jakim koncie i co robiliście tuż przed nim. Dołączcie wszystko, co zostało: log, HAR, nagranie z ostatnich minut. Takie zgłoszenie oznaczcie jako sporadyczne, żeby nikt nie zamknął go po pierwszej nieudanej próbie odtworzenia.

Jak wygląda cykl życia zgłoszenia i kto za co odpowiada?

Status zgłoszenia mówi całemu zespołowi, na jakim etapie jest błąd. Workflow powinien odpowiadać faktycznemu procesowi: zbyt rozbudowany przestaje być aktualizowany, zbyt prosty nie pokazuje realnego stanu pracy. Poniżej układ, który sprawdza się w większości zespołów.

Zgłoszenie bez przypisanej osoby albo zespołu potrafi leżeć tygodniami, bo każdy myśli, że zajmuje się nim ktoś inny. Atlassian opisuje śledzenie błędów w Jira jako rejestrowanie, przypisywanie, priorytetyzowanie i śledzenie, i to przypisywanie jest tym krokiem, który w naszych projektach najczęściej pomija się w praktyce.

Jakie błędy w zgłoszeniach popełniamy najczęściej?

Nawet doświadczeni testerzy zgłaszają czasem za szybko, szczególnie pod presją wydania. Z naszego doświadczenia te same problemy wracają w większości zespołów, które audytujemy i szkolimy:

• tytuł ogólny, który pasuje do dziesięciu różnych błędów
• kroki pisane skrótem albo zaczynające się w połowie procesu
• wynik oczekiwany i rzeczywisty sklejone w jedno zdanie
• brak wersji aplikacji, przez co nie wiadomo, czy błąd jest już naprawiony
• kilka różnych defektów w jednym zgłoszeniu
• mylenie priorytetu z ważnością
• emocjonalny język: „znowu nie działa”, „to bez sensu”
• brak informacji, czy błąd występuje zawsze, czy tylko czasem

Raport błędu opisuje zachowanie systemu, nie ocenia ludzi. Najlepsze zespoły traktują zgłoszenie jako informację o ryzyku w produkcie, a nie jako dowód, że ktoś źle wykonał pracę. To podejście buduje zaufanie między QA i developmentem, a testerzy przestają być postrzegani jako osoby „wrzucające błędy”.

Lista kontrolna przed wysłaniem

Ta lista to ostatni etap odpowiedzi na pytanie, jak poprawnie zgłosić błąd. Najważniejsze pytanie brzmi: czy deweloper będzie musiał o coś dopytać, zanim zacznie analizę? Jeśli nie, raport jest gotowy.

Jak wdrożyć standard zgłaszania błędów w całym zespole?

Gdy każdy w zespole wie, jak poprawnie zgłosić błąd, zmienia się cały proces, nie tylko pojedyncze tickety. Pojedynczy dobry raport pomaga w jednej naprawie. Wspólny standard pomaga w całym procesie: zgłoszenia przestają zależeć od stylu testera, a dane z backlogu nadają się do analizy, które moduły psują się najczęściej i jakie błędy wracają po kolejnych wydaniach. Wdrożenie mieści się w czterech krokach.

1. Szablon jako domyślna treść. Szablon z tej strony ustawiony w narzędziu dla typu Bug, z polami obowiązkowymi tam, gdzie brak informacji najczęściej blokuje analizę.
2. Zasady triage. Stały termin przeglądu nowych zgłoszeń, skala ważności, kto ustala priorytet i kiedy zgłoszenie wraca do autora z prośbą o uzupełnienie.
3. Jedna metryka jakości zgłoszeń. Na przykład odsetek zgłoszeń zamkniętych jako „nie do odtworzenia” albo odesłanych do uzupełnienia. Mierzycie co miesiąc i rozmawiacie o trendzie, nie o osobach.
4. Przegląd po wydaniu. Błędy, które dotarły na produkcję, wracają do planu testów jako nowe przypadki regresji.

Jeśli chcecie zobaczyć, jak ten sam problem wygląda z perspektywy całej organizacji, na Strefie QA opisujemy najczęstsze antywzorce w testowaniu oprogramowania i sposoby ich naprawy. Szerszy kontekst dokumentacji, w której raport błędu jest tylko jednym z elementów, daje artykuł o tym, jak napisać plan testów.

Powiązane na blogu Quality Island

• Jak napisać plan testów: kompletny przewodnik po dokumencie
• Narzędzia do testowania oprogramowania: przegląd dla QA
• 7 zasad testowania oprogramowania według ISTQB
• Asercje w Selenium: porównanie wyniku oczekiwanego z rzeczywistym w kodzie
• Testy manualne: na czym polegają i kiedy mają sens

Pełna lista źródeł

• N. Bettenburg, S. Just, A. Schröter, C. Weiss, R. Premraj, T. Zimmermann, What Makes a Good Bug Report?, ACM SIGSOFT FSE 2008. Ankieta wśród deweloperów i zgłaszających projektów Apache, Eclipse i Mozilla, 466 odpowiedzi.
• Mozilla, Bug Writing Guidelines, Bugzilla, wersja dostępna w 2026 roku.
• ISTQB, Glossary: defect report, słownik terminów ISTQB, 2026.
• Google, Chrome DevTools: Network features reference, zapis HAR, 2024.
• Atlassian, Śledzenie błędów w Jira, 2026, oraz Confluence Wiki Markup, 2026.
• Microsoft, Przechwytywanie zrzutów ekranu za pomocą narzędzia Wycinanie, pomoc techniczna Windows, 2026.