Definicja #
Bug reporting (raportowanie błędów) to umiejętność tworzenia kompletnych i precyzyjnych zgłoszeń defektów, które umożliwiają deweloperom szybką reprodukcję i naprawę problemu. Jest kluczową kompetencją QA Engineer i QA Analyst.
Składniki dobrego raportu błędu:
- Tytuł — zwięzły, opisowy; format: "[Moduł] Co się dzieje zamiast czego oczekiwano"; unikaj tytułów jak "aplikacja nie działa"
- Kroki reprodukcji — numerowana lista kroków prowadzących do błędu; każdy krok ma być atomowy i jednoznaczny; tester bez znajomości kontekstu musi odtworzyć błąd
- Oczekiwane zachowanie — co powinno się stać zgodnie z wymaganiami lub zdrowym rozsądkiem
- Rzeczywiste zachowanie — dokładny opis tego co się dzieje; copy-paste komunikatu błędu, nie parafrazowanie
- Środowisko — OS i wersja, przeglądarka/urządzenie, wersja aplikacji, dane testowe; determinizm reprodukcji zależy od precyzji środowiska
- Severity — waga techniczna błędu: Critical (blokuje testowanie/produkcję), High (poważna funkcjonalność nie działa), Medium (funkcjonalność ograniczona), Low (kosmetyczny)
- Priority — pilność naprawy z perspektywy biznesowej; severity i priority mogą się różnić (literówka na stronie głównej: Low severity, High priority)
- Załączniki — screenshoty, nagranie ekranu, logi konsoli, stack trace; screenshoty z adnotacjami strzałkami i kółkami
Narzędzia: Jira (standard enterprise), Bugzilla (legacy open-source), GitHub Issues, Azure DevOps Work Items, TestRail.
Zastosowania #
- Raportowanie błędów w testach funkcjonalnych — dokumentowanie defektów znalezionych podczas testów manualnych i automatycznych
- Bug bash sesje — intensywne, krótkie sesje testowania całego zespołu (dev, PM, design) przed releasem; raporty błędów w czasie rzeczywistym
- Triage i priorytetyzacja — cykliczne spotkania zespołu do oceny i priorytetyzacji zgłoszonych błędów; decyzja o naprawie w bieżącym sprincie
- Regresja po naprawie — weryfikacja czy zgłoszony błąd został naprawiony i czy naprawa nie wprowdziła nowych problemów
- Analiza root cause — zgłoszenia z dokładnymi logami i stack trace umożliwiają analizę przyczyn źródłowych i zapobieganie podobnym błędom
Ścieżka nauki #
Bug reporting to praktyczna umiejętność rozwijana przez aktywne testowanie — teoria jest prosta, jakość raportów poprawia się z doświadczeniem.
Zacznij od:
- Szablon raportu: tytuł, kroki reprodukcji, oczekiwane/rzeczywiste, środowisko, severity — stosuj go konsekwentnie
- Jira: utwórz konto (atlassian.com, bezpłatny plan), stwórz projekt testowy, wejdź w rolę testera i zgłaszaj błędy
- Ćwiczenie: testuj znane aplikacje (Wikipedia, YouTube) i zgłaszaj hipotetyczne błędy używając szablonu
Następnie pogłębiaj:
- Severity vs Priority: naucz się klasyfikować i uzasadniać; poczytaj o ISTQB Foundation Level wymaganiach dotyczących defectów
- Nagrywanie ekranu: Loom, ShareX (Windows), QuickTime (Mac) — video bug report wartszy tysiąc słów
- Logi przeglądarki: DevTools Console i Network tab — kopiowanie błędów JavaScript i odpowiedzi API do raportu
- Certyfikacja ISTQB Foundation Level — rozdział o zarządzaniu defektami jest częścią egzaminu
FAQ #
- Czym różni się severity od priority w bug reportingu?
- Severity to waga techniczna błędu — jak bardzo wpływa na funkcjonowanie systemu (Critical/High/Medium/Low). Priority to pilność biznesowa naprawy — jak ważne jest naprawienie tego błędu z perspektywy produktu. Literówka w nazwie firmy na stronie głównej: Low severity (kosmetyczne), High priority (wizerunek marki). Crash w rzadko używanej funkcji: High severity, Low priority.
- Co powinien zawierać dobry tytuł raportu błędu?
- Dobry tytuł raportu błędu powinien być krótki (do 100 znaków) i opisywać: co, gdzie i kiedy. Przykład: "[Koszyk] Przycisk 'Zamów' nieaktywny gdy produkt jest w magazynie" zamiast "Nie można złożyć zamówienia". Zawieraj moduł w nawiasach kwadratowych, opisz obserwowane zachowanie i, jeśli możliwe, warunki jego wystąpienia.
- Jakie narzędzia do bug trackingu są najpopularniejsze?
- Jira (Atlassian) to de facto standard enterprise — rozbudowane workflow, integracja z Confluence i Bitbucket, zaawansowane raportowanie. GitHub Issues jest prosty i dobrze integruje się z repozytoriami GitHub — popularne w open-source i mniejszych teamach. Azure DevOps Work Items używany w środowiskach Microsoft. Bugzilla to klasyczne, starsze narzędzie (używane m.in. przez Mozilla). TestRail to specjalistyczne narzędzie łączące zarządzanie przypadkami testowymi z bug trackingiem.
- Jak raportować błędy które nie są w 100% reprodukowalne?
- Dla błędów sporadycznych (flaky bugs): zanotuj jak często się pojawiają (1 na 5 prób, 1 na 10), opisz dokładne kroki i timing, dołącz screenshot/video jeśli udało się uchwycić, sprawdź logi w momencie wystąpienia, opisz co poprzedzało błąd. Zaznacz w tytule lub etykiecie że błąd jest intermittent/flaky. Próbuj odtworzyć w różnych środowiskach i na różnych danych testowych.