Zarządzanie defektami — jak robić to dobrze

Ten wpis jest częścią serii ISTQB Foundation Level. Jeśli nie czytałeś poprzedniego wpisu, zajrzyj najpierw do Części 9 — Zarządzanie testami.

Wprowadzenie — defekt jako artefakt komunikacyjny

Raport defektu to nie skarga. To nie notatka dla siebie. To artefakt komunikacyjny — kontrakt między testerem, który znalazł problem, a deweloperem, który musi go naprawić.

Gdy raport defektu jest niejasny, niekompletny lub mylący, dzieje się jedna z trzech rzeczy: deweloper nie może go odtworzyć i oznacza „Nie można odtworzyć”, naprawiana jest zła rzecz, albo zgłoszenie siedzi w backlogu tygodniami, bo nikt nie ma kontekstu, żeby zacząć działać.

Słabe raporty defektów spowalniają zespoły, niszczą zaufanie między QA a deweloperami i pozwalają defektom pozostawać na produkcji dłużej niż to konieczne. Świetne raporty defektów działają odwrotnie: dają deweloperom wszystko, czego potrzebują, żeby odtworzyć, zrozumieć i naprawić problem przy minimalnej wymianie wiadomości.

Ten wpis obejmuje wszystko, co musisz wiedzieć, żeby pisać raporty defektów, które faktycznie są naprawiane — cykl życia defektu według ISTQB, kluczowe rozróżnienie między wagą a priorytetem, anatomię świetnego raportu i typowe antywzorce, które czynią raporty bezużytecznymi.

Cykl życia defektu — ISTQB 5.6

ISTQB definiuje cykl życia defektu (defect lifecycle) jako zbiór stanów, przez które przechodzi defekt od odkrycia do zamknięcia.

Standardowy cykl życia wygląda następująco:

[Nowy] → [Przypisany] → [W trakcie] → [Naprawiony] → [Gotowy do testu]
                                                              ↓
                                                        [Zweryfikowany]
                                                              ↓
                                                         [Zamknięty]

Ścieżki boczne:
[Nowy]         → [Odrzucony]   (nie jest prawdziwym defektem)
[W trakcie]    → [Odroczony]   (prawdziwy defekt, celowo nie naprawiany teraz)
[Zweryfikowany]→ [Ponownie otwarty] → [W trakcie]

Przejdźmy przez każdy stan:

Nowy — Defekt został zgłoszony i wprowadzony do systemu śledzenia defektów. Nie został jeszcze nikomu przypisany. To stan wejściowy dla każdego nowego zgłoszenia.

Przypisany — Deweloper (lub team lead) został przypisany jako osoba odpowiedzialna za zbadanie i naprawę defektu.

W trakcie — Deweloper aktywnie pracuje nad poprawką.

Naprawiony — Deweloper uważa, że defekt został rozwiązany i przesłał poprawkę. Zmiana kodu jest gotowa do weryfikacji.

Gotowy do testu — Poprawka została wdrożona na środowisko testowe i czeka na weryfikację przez testera.

Zweryfikowany — Tester potwierdził, że poprawka rozwiązuje zgłoszony defekt. To jest inny stan niż Zamknięty — zweryfikowany oznacza „poprawka działa”, nie „skończyliśmy”.

Zamknięty — Defekt został zweryfikowany i wszystkie strony zgadzają się, że jest rozwiązany. To stan końcowy.

Odrzucony — Defekt nie jest prawdziwym defektem. Może być nieporozumieniem co do wymagań, oczekiwanym zachowaniem, duplikatem lub problemem konfiguracyjnym. Odrzucone defekty powinny zawierać jasne wyjaśnienie.

Ponownie otwarty — Defekt, który był Zweryfikowany lub Zamknięty, pojawia się ponownie. Wraca do cyklu życia w odpowiednim stanie, zazwyczaj W trakcie lub Przypisany.

Odroczony — Defekt jest prawdziwy i uznany, ale celowo podjęto decyzję, żeby nie naprawiać go w bieżącym wydaniu. Odroczenie wymaga zgody interesariuszy — nie jest to jednostronna decyzja dewelopera. Częste powody: dotknięty obszar jest przestarzały i będzie usunięty, wpływ na biznes jest niski względem ryzyka naprawy, albo termin wydania jest bliski. Odroczone defekty muszą być ponownie rozpatrzone w następnym cyklu planowania.

:::danger[Weryfikacja jest obowiązkowa] Nigdy nie zamykaj defektu bez weryfikacji przeprowadzonej przez kogoś innego niż deweloper, który go naprawił. Deweloper weryfikujący własną poprawkę to konflikt interesów i błąd procesowy. Cały sens stanu Zweryfikowany polega na niezależnym sprawdzeniu, że poprawka faktycznie działa. :::

Waga a priorytet

To jeden z najczęściej źle rozumianych tematów w zarządzaniu defektami — i pewny temat egzaminacyjny ISTQB.

Waga — ustawiana przez QA

Waga (severity) opisuje wpływ na system. To techniczna miara tego, jak poważnie defekt psuje rzeczy. Wagę określa tester lub zespół QA.

Waga	Definicja	Przykład
Krytyczna	Awaria systemu, utrata danych, całkowite niepowodzenie funkcji bez obejścia	Przetwarzanie płatności zwraca HTTP 500 dla wszystkich użytkowników
Wysoka	Główna funkcja nie działa, obejście jest kłopotliwe lub dotyka wielu użytkowników	Przesyłanie plików po cichu kończy się błędem dla plików > 5 MB
Średnia	Funkcja działa, ale niepoprawnie lub niekompletnie; obejście istnieje	Datepicker pokazuje zły rok w lutym w roku przestępnym
Niska	Problem kosmetyczny, drobna niedogodność, brak wpływu funkcjonalnego	Tekst przycisku jest obcięty w Safari przy 110% powiększeniu

Priorytet — ustawiany przez właściciela produktu

Priorytet (priority) opisuje pilność biznesową — jak szybko defekt musi zostać naprawiony względem innej pracy. Priorytet określa właściciel produktu lub interesariusz biznesowy, nie QA.

Kiedy się rozchodzą

Ciekawe przypadki — i te, które pojawiają się na egzaminie ISTQB — to sytuacje, gdy waga i priorytet wskazują w różnych kierunkach:

Wysoka waga, niski priorytet — Krytyczna awaria występuje w rzadko używanej starszej funkcji, która jest zaplanowana do usunięcia w następnym kwartale. System jest zepsuty, ale nikt nie będzie tego teraz naprawiał.

Niska waga, wysoki priorytet — Imię CEO jest błędnie napisane na stronie „O nas”. Technicznie problem kosmetyczny (niska waga). Ale CEO zauważył to dziś rano, więc zostanie naprawione przed lunchem (wysoki priorytet).

Krytyczna waga, odroczony — Przestarzały endpoint API zwraca uszkodzone dane. Krytyczne, jeśli wywołany, ale endpoint jest usuwany za dwa tygodnie i ma zero aktywnych wywołujących. Odroczony za zgodą interesariuszy.

:::tip[Wskazówka egzaminacyjna ISTQB] Egzamin lubi scenariusze, w których trzeba odróżnić wagę od priorytetu. Pamiętaj: waga dotyczy wpływu technicznego (ustawia QA), priorytet dotyczy pilności biznesowej (ustawia PO/interesariusz). Błąd krytycznej wagi może mieć niski priorytet, a błąd niskiej wagi może mieć wysoki priorytet. To niezależne wymiary. :::

Pisanie świetnych raportów defektów

Pełny szablon

Tytuł:            [Strona/Funkcja] - Krótki opis symptomu
Środowisko:       System operacyjny, przeglądarka, wersja aplikacji, rola użytkownika, dane testowe
Waga:             Krytyczna / Wysoka / Średnia / Niska
Priorytet:        Wysoki / Średni / Niski
Kroki do odtworzenia:
  1. Przejdź do /checkout
  2. Dodaj produkt do koszyka
  3. Kliknij "Przejdź do płatności"
  4. Wpisz numer karty: 4111111111111111
  5. Kliknij "Zapłać"
Oczekiwany wynik: Płatność przetwarza się pomyślnie, przekierowanie na stronę potwierdzenia
Rzeczywisty wynik: Zwrócony błąd 500, płatność nie przetworzona
Załączniki:       screenshot.png, network_log.har

Przejdźmy przez to, co sprawia, że każde pole jest wartościowe.

Jakość tytułu

Tytuł to pierwsza rzecz, którą czyta deweloper. Musi mówić mu o funkcji, warunkach i symptomie — wszystko w jednej linii.

Zły tytuł: nie działa
Nikt nie wie, co to „to”, co „nie działa” oznacza ani w jakich warunkach.

Nieco lepszy: Płatność się nie udaje
Lepiej, ale wciąż niejasno. Jaki rodzaj płatności? Jaki rodzaj błędu? Kiedy?

Dobry tytuł: Checkout — Płatność kartą Visa na urządzeniu mobilnym kończy się błędem (HTTP 500)
To mówi deweloperowi: funkcja (Checkout), warunek (karta Visa na urządzeniu mobilnym) i symptom (HTTP 500). Może przeszukać logi, znaleźć odpowiednią ścieżkę kodu i zacząć badać, zanim przeczyta kolejne słowo.

Format [Funkcja/Strona] — [Warunek] — [Symptom] to niezawodny szablon dla klarownych tytułów.

Kroki do odtworzenia

Kroki do odtworzenia są najważniejszą częścią raportu defektu. Jeśli deweloper nie może odtworzyć defektu, nie może go naprawić.

Zasady świetnych kroków do odtworzenia:

Numeruj każdy krok — łatwo się odwołać (“błąd przy kroku 4”)
Każdy krok powinien być atomowy — jedno działanie na krok, bez łączenia
Uwzględnij warunek początkowy — w jakim stanie jest system przed krokiem 1? Świeże logowanie? Konkretna rola użytkownika? Konkretne dane?
Zawrzyj dane testowe explicite — nie mów “wpisz numer karty”, powiedz “wpisz 4111111111111111 (testowa karta Visa)”
Precyzuj nawigację — “Idź do kasy” jest niejasne; “Przejdź do /cart i kliknij ‘Przejdź do kasy’” jest precyzyjne

Oczekiwany wynik

Oczekiwany wynik powinien idealnie odwoływać się do wymagania, historyjki użytkownika lub specyfikacji. „Oczekiwane: płatność się udaje” jest oczywiste i bezużyteczne. „Oczekiwane: płatność przetwarza się pomyślnie i użytkownik zostaje przekierowany do /confirmation z wyświetlonym ID zamówienia (zgodnie z AC-3 w US-142)” daje deweloperowi kontekst i odniesienie do weryfikacji.

Odtwarzalność

Podaj procent odtwarzalności i warunki. „Odtwarzalne 100% czasu” vs „Odtwarzalne 3/5 prób, zawsze w Chrome, nigdy w Firefox” vs „Odtworzono raz, nie można ponownie odtworzyć” — to zupełnie inne implikacje dla sposobu badania przez dewelopera.

Triage defektów

Triage defektów to proces przeglądania nowych defektów w celu przypisania wagi, priorytetu, właściciela i docelowego wydania.

Rytm: Zazwyczaj codziennie dla aktywnych projektów lub na początku każdego cyklu planowania sprintu.

Uczestnicy: Lead testów lub przedstawiciel QA, właściciel produktu, lead deweloperów, opcjonalnie: menedżer wydania lub kierownik projektu.

Agenda:

Przegląd wszystkich defektów w stanie „Nowy” od ostatniego triage
Potwierdzenie lub korekta wagi (ustawionej przez QA w zgłoszeniu)
Przypisanie priorytetu (właściciel produktu)
Przypisanie do dewelopera lub zespołu
Decyzja: naprawić w bieżącym sprincie, odroczyć lub odrzucić

Wynik: Każdy defekt w stanie Nowy wychodzi z triage ze stanem (Przypisany, Odroczony lub Odrzucony), właścicielem i priorytetem. Żaden defekt nie powinien wychodzić z triage w niejednoznacznym stanie.

Spotkania triage powinny mieć ograniczony czas. Jeśli defekt wymaga znaczącej dyskusji o przyczynie źródłowej lub podejściu, ta dyskusja odbywa się poza spotkaniem triage.

Analiza przyczyn źródłowych

Naprawienie defektu usuwa symptom. Analiza przyczyn źródłowych (RCA — Root Cause Analysis) identyfikuje, dlaczego defekt wystąpił, żeby można było zająć się podstawową przyczyną — zapobiegając powracaniu tej samej klasy defektów.

Technika 5 Dlaczego

5 Dlaczego to prosta, iteracyjna technika drążenia do przyczyny źródłowej:

Problem: Płatność kartą Visa na urządzeniu mobilnym kończy się błędem.

Dlaczego? — API płatności zwraca HTTP 500.
Dlaczego? — Formater numeru karty usuwa myślniki przed wysłaniem do API.
Dlaczego? — Formater został napisany dla wprowadzania na desktopie (bez myślników) i nie został zaktualizowany gdy dodano wprowadzanie mobilne.
Dlaczego? — Nie było przypadku testowego pokrywającego format wprowadzania karty na urządzeniu mobilnym.
Dlaczego? — Pokrycie testami obsługi danych wejściowych modułu płatności nigdy nie zostało zdefiniowane w planie testów.

Przyczyna źródłowa: Brakujące definicje pokrycia testami obsługi danych wejściowych płatności dla różnych typów wejść.

Naprawa na poziomie przyczyny źródłowej: Dodaj wymagania dotyczące pokrycia testami danych wejściowych płatności do strategii testów. Naprawa kodu jest konieczna, ale sama w sobie nie zapobiega tej samej klasie defektów.

Kategorie defektów

Kategoryzowanie defektów (defekt wymagań, defekt projektu, defekt kodu, defekt danych testowych, defekt konfiguracji itp.) pozwala dostrzec wzorce. Jeśli 40% defektów w ostatnim kwartale to „defekty wymagań”, masz problem z procesem wymagań, a nie z jakością kodu.

Używaj danych RCA do doskonalenia procesu: aktualizuj listy kontrolne, poprawiaj wytyczne przeglądu kodu, dodawaj zasady pokrycia testami lub zajmij się wieloznacznością w wymaganiach na wcześniejszym etapie.

Typowe antywzorce

„Nie można odtworzyć” jako rozwiązanie — Używane, gdy deweloper nie ma odpowiedniego środowiska, danych testowych lub kontekstu. Naprawa: wymagaj od deweloperów udokumentowania tego, co próbowali, zanim oznaczą Nie można odtworzyć, i niech QA z deweloperem razem próbują odtworzyć problem.
Zamykanie bez weryfikacji — Deweloper naprawia, oznacza jako zamknięty, a tester nigdy nie weryfikuje. Naprawa: wymuś stan Zweryfikowany jako wymagany krok przed Zamkniętym.
Mieszanie wagi i priorytetu — Deweloper ustawia priorytet na podstawie trudności naprawy. QA ustawia wagę na podstawie wpływu biznesowego. Produkt ustawia priorytet na podstawie pilności biznesowej. Każda rola powinna być właścicielem swojego pola.
Niejasne oczekiwane wyniki — „Oczekiwane: działa” nie jest wymaganiem. Jeśli nie możesz określić, jak wygląda poprawne zachowanie, nie masz wystarczających informacji do napisania raportu.
Brak informacji o środowisku — Połowa defektów, które mówią „zawsze odtwarzalne”, znika, bo brakowało informacji o środowisku. Zawsze uwzględniaj system operacyjny, wersję przeglądarki, wersję aplikacji i wszelką istotną konfigurację.

Podsumowanie

Zarządzanie defektami to jedna z najbardziej opłacalnych umiejętności w QA. Świetny raport defektu przyspiesza cały cykl naprawy: deweloper natychmiast rozumie problem, naprawa jest celowana i prawidłowa, weryfikacja jest jednoznaczna, a defekt jest zamykany z pewnością.

Działanie na ten tydzień: Wyciągnij 5 ostatnich raportów defektów z twojego projektu i oceń każdy z nich według szablonu z tego wpisu. Ile ma kompletne kroki do odtworzenia? Jasne oczekiwane wyniki? Explicit informacje o środowisku? Luki, które znajdziesz, powiedzą ci dokładnie, gdzie twój proces zgłaszania defektów wymaga poprawy.

Syllabus podstawowy ISTQB obejmuje zarządzanie defektami w sekcji 5.6. Kluczowe terminy: cykl życia defektu (defect lifecycle), Waga (severity), Priorytet (priority), odroczony (uznany defekt celowo nie naprawiany w bieżącym wydaniu) i analiza przyczyn źródłowych (root cause analysis).

Następny wpis: Część 11 — Narzędzia testowe, ROI automatyzacji i ryzyka