Defect (defekt, wada, potocznie „bug") to niezgodność działania systemu z wymaganiami lub uzasadnionymi oczekiwaniami użytkownika. Defekt przechodzi cykl życia: zgłoszenie → analiza i priorytetyzacja (triage) → naprawa → retest → zamknięcie. Dobre zgłoszenie zawiera: kroki reprodukcji, wynik oczekiwany, wynik faktyczny, środowisko i dowód (zrzut, log).
Gdzie tu analityk? W roli, której nikt inny nie zagra: arbitra w sporze „defekt czy nowe wymaganie". Zgłoszenie „system nie wysyła SMS-a po odwołaniu wizyty" brzmi jak błąd - ale czy takie wymaganie w ogóle istniało? Jeśli tak (i jest w specyfikacji), to defekt naprawiany w ramach projektu. Jeśli nie - to zmiana zakresu, z osobną decyzją i wyceną. Bez analityka i porządnej dokumentacji wymagań ten spór rozstrzyga się siłą głosu.
Przykład z MediFlow: tester zgłasza, że da się umówić dwie wizyty na tę samą godzinę u tego samego lekarza. Analityk sprawdza wymaganie REQ-12: „slot grafiku może mieć dokładnie jedną aktywną rezerwację" - jednoznacznie defekt, do tego poważny, bo podwójne rezerwacje w 12 przychodniach to awantury w poczekalniach. Naprawa przed pilotażem.
Rozróżnienie, które myli wielu: severity (dotkliwość: jak duży wpływ techniczny/biznesowy ma defekt) to nie priority (priorytet: jak szybko naprawiamy). Literówka w nazwie firmy na wydruku potwierdzenia ma niskie severity, ale wysoki priorytet - bo widzi ją każdy pacjent. I odwrotnie: poważny błąd w funkcji używanej raz w roku może poczekać.
Pojęcia powiązane: przypadek testowy, kryteria akceptacji, severity/priority, retest, change request.
Defekt techniczny, wada, usterka, bug - jedno zjawisko, pięć nazw
W polskich zespołach to samo zdarzenie ma kilka nazw i każda ciągnie za sobą inne oczekiwanie. To nie jest spór o słowa. Od nazwy zależy, kto to naprawia i w jakim trybie.
| Słowo | Gdzie pada | Co realnie znaczy |
|---|---|---|
| Defekt (defekt techniczny) | dokumentacja, narzędzie do zgłoszeń, raporty jakości | neutralne: system zachowuje się inaczej, niż wynika z wymagań |
| Wada | umowa, protokół odbioru, rozmowa z dostawcą | to samo, ale ze skutkiem formalnym |
| Usterka | rozmowa bieżąca | zwykle coś drobnego, bez wpływu na proces biznesowy |
| Błąd | wszędzie | najszersze i najbardziej mylące, bo miesza przyczynę ze skutkiem |
| Bug | żargon zespołu | to samo co defekt, tylko po angielsku |
Różnica praktyczna zaczyna się przy słowie „wada". Dopóki mówimy o defekcie, rozmawiamy o pracy zespołu. Kiedy w protokole odbioru pada „wada", uruchamia się ścieżka z umowy: zamawiającemu przysługują roszczenia, a to, czy dostawca ma usunąć wadę, obniżyć cenę czy zrobić coś innego, wynika z zapisów kontraktu, rękojmi albo gwarancji. Szczegóły zależą od konkretnej umowy i przepisów, więc to nie jest porada prawna, tylko powód, żeby przed odbiorem sprawdzić, którego słowa używamy i na jakiej podstawie.
W rozmowie mów, jak mówi zespół. W zgłoszeniu i w dokumencie trzymaj jedno słowo. Jeżeli w jednym projekcie połowa zgłoszeń nazywa się „bug", a połowa „wada", nie zrobisz z tego żadnej sensownej statystyki.
Co dokłada przymiotnik „techniczny"
„Defekt techniczny" pada zwykle wtedy, gdy ktoś chce powiedzieć: to nie jest problem z pomysłem, tylko z wykonaniem. Kod działa inaczej, niż zaprojektowano.
To rozróżnienie ma sens operacyjny, bo kieruje zgłoszenie do właściwych ludzi. Ma też jedną pułapkę: bywa używane, żeby zamknąć rozmowę. „To defekt techniczny" brzmi jak „sprawa dla programistów, analityk może wracać do swoich dokumentów". Tymczasem większość sporów o defekty to spory o to, czego wymaganie w ogóle wymagało. Rozstrzygnięcie „techniczny czy nie" zapada dopiero po sprawdzeniu zapisu, nie przed.
W praktyce spotkasz trzy sytuacje i tylko pierwsza jest defektem technicznym w ścisłym sensie:
- Wymaganie było jednoznaczne, wykonanie się z nim rozjeżdża. To defekt.
- Wymaganie było wieloznaczne, każda strona odczytała je inaczej. To defekt w wymaganiu, a naprawa zaczyna się od uzgodnienia treści, nie od kodu.
- Wymagania nie było wcale, a odbiorca uważa, że system powinien tak działać. To wniosek o zmianę, czyli change request, z osobną decyzją i wyceną.
Defekt, incydent, problem, awaria
Cztery pojęcia, które w raportach ciągle się zlepiają w jedno.
- Defekt siedzi w produkcie. To konkretna niezgodność w tym, co zbudowaliśmy. Żyje, dopóki ktoś jej nie naprawi.
- Incydent to pojedyncze zdarzenie: przerwa w działaniu albo spadek jakości usługi. Może go zgłosić użytkownik, ale równie dobrze może go wychwycić monitoring, zanim ktokolwiek zadzwoni.
- Problem to sprawa otwarta po to, żeby ustalić przyczynę jednego albo wielu incydentów. Powtarzalność nie jest warunkiem: jedna dotkliwa awaria wystarczy, żeby założyć problem. Defekt w produkcie bywa właśnie tą przyczyną, ale bywa nią też błędna konfiguracja albo zmiana po stronie systemu, z którym się integrujemy. Dlatego są to dwa różne byty: problem to prowadzone dochodzenie, defekt to jedno z możliwych ustaleń.
- Awaria w polskich umowach to zwykle klasa dotkliwości zdefiniowana w kontrakcie, najczęściej po stronie niedostępności usługi, rozliczana zgodnie z SLA. To nie synonim „coś nie działa", tylko kategoria z konsekwencją finansową.
Konsekwencja jest prosta i bolesna: zamknięcie incydentu nie zamyka defektu. Jeżeli wsparcie odpisało użytkownikowi „proszę odświeżyć stronę" i zamknęło zgłoszenie, incydent jest zamknięty, a defekt dalej pracuje i jutro wygeneruje kolejnych dwadzieścia zgłoszeń. Analityk, który patrzy tylko na liczbę zamkniętych zgłoszeń, zobaczy sprawny proces tam, gdzie jest nieusunięta przyczyna.
Jak wygląda zgłoszenie, którego nie da się odrzucić
Zgłoszenie defektu to dokument, nie wiadomość. Teoria brzmi znajomo, więc zamiast kolejnej listy pól - wypełniony przykład z MediFlow, systemu rejestracji wizyt z naszych ćwiczeń.
Tytuł: Grafik pozwala zarezerwować dwie wizyty w tym samym slocie u jednego lekarza
Środowisko: test, wersja 2.14.0, przeglądarka Chrome w wersji bieżącej, konto
rejestracja_testDane wejściowe: lekarz Kowalski (id 4412), 12.09.2026, slot 10:00, pacjenci PES-1029 i PES-3341
Kroki odtworzenia: 1. Zaloguj się jako rejestratorka. 2. Wejdź w Grafik, wybierz lekarza Kowalski i dzień 12.09.2026. 3. Kliknij slot 10:00, zarezerwuj wizytę dla PES-1029, zapisz. 4. Kliknij ten sam slot 10:00 ponownie, zarezerwuj wizytę dla PES-3341, zapisz.
Wynik oczekiwany (REQ-12): system odrzuca drugą rezerwację i pokazuje komunikat o zajętym slocie. Wymaganie: „slot grafiku może mieć dokładnie jedną aktywną rezerwację".
Wynik faktyczny: obie rezerwacje zapisane, w grafiku widoczne dwie wizyty na 10:00, brak ostrzeżenia.
Dowód: zrzut ekranu grafiku, log z zapisu drugiej rezerwacji (załączone).
Trzy rzeczy, które robią tu całą robotę. Kroki zaczynają się od zalogowania, a nie od „w kalendarzu" - dzięki temu odtworzy je ktoś, kto tego ekranu nie zna. Dane wejściowe są konkretne, bo bardzo często defekt siedzi w danych brzegowych, nie w ścieżce. A wynik oczekiwany ma numer wymagania i to jedno zdanie zamienia kłótnię w sprawdzenie.
Komplet tych pól warto uczynić warunkiem przyjęcia zgłoszenia do przeglądu. Jeżeli zespół pracuje z Definition of Ready, to jest naturalne miejsce na taki zapis. Wtedy standard przestaje być dobrą praktyką, o której wszyscy wiedzą i nikt jej nie stosuje.
Dlaczego zgłoszenia wracają: 18, 7 i 5
W jednym z ćwiczeń w kursie „Wprowadzenie do analizy biznesowej" prowadzimy zespół przez konflikt między deweloperami a testerami. Liczby są poglądowe, ułożone pod ćwiczenie:
- 18 defektów zgłoszonych w sprincie,
- 7 odrzuconych jako „nie potrafię odtworzyć",
- 5 z kompletnymi krokami odtworzenia,
- 2,5 dnia roboczego średnio od zgłoszenia do pierwszej reakcji.
Zespół czyta to jako złą wolę. Deweloperzy mówią, że zgłoszenia są nieczytelne. Testerzy mówią, że ich zgłoszenia są ignorowane. Retrospektywa zamienia się we wzajemne pretensje, a tempo pracy spada.
Tylko że z tych czterech liczb wynika co innego. Kroki odtworzenia miało 5 zgłoszeń z 18, czyli 28 procent. Przy takim udziale 7 odrzuceń to przewidywalny skutek, nie sabotaż. Do tego 2,5 dnia ciszy każdy odczyta jako lekceważenie, niezależnie od tego, ile pracy w tym czasie wykonano.
Rola analityka w tym momencie nie polega na przyznaniu komuś racji. Polega na zamianie rozmowy o nastawieniu w rozmowę o procesie: uzgodnić standard zgłoszenia, wprowadzić zasadę pierwszej reakcji w ciągu jednego dnia i krótki przegląd nowych defektów przy codziennym spotkaniu. Mierzalny cel na następny sprint: udział zgłoszeń z kompletnym opisem z 28 procent w górę.
Skale dotkliwości i priorytetu
Dotkliwość i priorytet to dwie osobne osie i właśnie dlatego opisuje się je osobnymi skalami. Nazewnictwo bywa różne, ale układ jest zwykle ten sam.
Dotkliwość (severity) - skutek dla systemu i dla biznesu:
| Poziom | Co oznacza |
|---|---|
| S1 / Blocker | proces nie da się dokończyć, brak obejścia |
| S2 / Critical | proces działa, ale z poważnym skutkiem: błędne dane, ryzyko prawne |
| S3 / Major | funkcja działa źle, istnieje obejście |
| S4 / Minor | drobiazg, głównie kosmetyka i wygoda |
Priorytet (priority) - kolejność naprawy, od P1 (bierzemy natychmiast) do P4 (gdy będzie miejsce). To, ile czasu kryje się za każdym poziomem, zespół ustala u siebie: gdzieś P2 znaczy „w tym sprincie", gdzie indziej „w tym tygodniu". Ważne, żeby było ustalone raz i tak samo dla wszystkich.
Te dwie osie potrafią iść w przeciwne strony i wtedy decyzja robi się ciekawa. Błędne zaokrąglenie w naliczaniu odsetek to S2, bo dotyczy pieniędzy i danych sprawozdawczych, ale jeśli najbliższe naliczenie jest za sześć tygodni, spokojnie dostaje P3. Odwrotnie: rozjechany układ nagłówka w e-mailu potwierdzającym zamówienie ma S4, a mimo to bywa P1, bo wychodzi codziennie do wszystkich klientów i psuje pierwsze wrażenie.
Dotkliwość opisuje skutek, techniczny i biznesowy. Priorytet opisuje kolejność, na którą firma może sobie teraz pozwolić - i to jest decyzja biznesowa, w której analityk ma coś do powiedzenia.
Kto co robi na pięciu etapach
| Etap | Kto prowadzi | Co robi analityk | Typowa wpadka |
|---|---|---|---|
| Zgłoszenie | tester, wsparcie, użytkownik | pilnuje kompletu opisu | zgłoszenie w formie zdania na czacie |
| Przegląd (triage) | zespół | przygotowuje rozstrzygnięcie „defekt czy zmiana", podpina numer wymagania | przegląd jako licytacja, kto głośniej krzyczy |
| Naprawa | deweloper | jest dostępny do pytań o intencję wymagania | analityk znika i wraca dopiero na demo |
| Retest | tester | sprawdza, czy kryteria akceptacji są spełnione | retest tylko ścieżki z opisu, bez testów regresywnych |
| Zamknięcie | zespół | sprawdza, czy naprawiono przyczynę, nie objaw | zamknięcie po odpowiedzi „u mnie działa" |
Defekt czy zmiana zakresu: test trzech pytań
Trzy pytania, które ten spór rozstrzygają, w tej kolejności:
- Czy istnieje wymaganie, które to opisuje? Bez śledzenia wymagań odpowiedź brzmi „chyba tak" i rozmowa idzie w emocje. Z numerem wymagania w ręku trwa minutę.
- Czy tekst wymagania da się odczytać tylko w jeden sposób? Jeśli nie, to nie jest defekt techniczny, tylko wieloznaczność, którą trzeba domknąć zapisem.
- Czy odbiorca mógł tego rozsądnie oczekiwać, mimo braku zapisu? Czasem tak, na przykład przy wymaganiach prawnych. Wtedy i tak zapada decyzja, kto płaci, ale przynajmniej zapada świadomie.
Odpowiedź „to nie było w wymaganiach, więc nie nasza sprawa" jest formalnie poprawna i biznesowo kosztowna. Zamiast niej: nazwij to zmianą, wyceń i pokaż decydentowi wybór. Zgłoszenia rozstrzygane siłą głosu zamiast zapisem to prosta droga do rozpełzania zakresu.
Defekt znaleziony na produkcji
Ten sam defekt na produkcji to inna sprawa niż na środowisku testowym, bo zderza się z ruchem i z ludźmi, którzy właśnie pracują. Kolejność jest odwrotna niż w projekcie: najpierw ograniczasz skutek, potem szukasz przyczyny.
- Skala. Ilu użytkowników, które procesy, czy powstają błędne dane. To decyduje o wszystkim dalej.
- Obejście. Jeśli istnieje sposób ominięcia problemu, wsparcie dostaje je natychmiast, zanim zacznie się naprawa.
- Poprawka doraźna albo planowa. Naprawa wypuszczana poza normalnym cyklem skraca czas skutku, ale omija część testów. To decyzja o ryzyku, nie formalność.
- Wpis do rejestru i test regresywny. Bez tego ten sam defekt wraca za trzy miesiące w innym miejscu.
Rola analityka jest tu wąska i konkretna: przetłumaczyć skutek techniczny na język skutku biznesowego. „Nie zapisuje się status wizyty" to dla decydenta pusta informacja. „Rejestracja w dwunastu przychodniach prowadzi grafik na papierze i wieczorem trzeba go przepisać ręcznie" to informacja, na podstawie której da się zdecydować o poprawce doraźnej.
Najtańszy defekt to ten znaleziony w wymaganiu
Defekt w kodzie kosztuje naprawę, retest i opóźnienie. Ten sam problem złapany w wymaganiu kosztuje poprawienie jednego zdania. Dlatego przegląd wymagań jest częścią pracy z jakością, a nie osobną biurokracją. Praktyczne techniki i checklistę przeglądu opisaliśmy w artykule jak testować wymagania i weryfikować jakość dokumentacji.
Rozjazdy, które widać dopiero przy integracji
Osobny rodzaj rozjazdu wychodzi dopiero przy integracjach. Kiedy analityk sam wywoła interfejs i porówna odpowiedź z własną specyfikacją, każda rozbieżność wpada do jednego z trzech koszyków: defekt, luka w specyfikacji albo pytanie do dewelopera. Trzy koszyki, trzy różne ścieżki: pierwszy idzie do zespołu, drugi wraca do dokumentu, trzeci kończy się rozmową na dziesięć minut. Rozdzielenie ich zanim rozbieżność znajdzie odbiorca na produkcji to jedna z tańszych rzeczy, jakie analityk może zrobić.
Trzy błędy, które analitycy popełniają przy defektach
- Przepisywanie zamiast rozstrzygania. Przeniesienie zgłoszenia z maila do narzędzia nie wnosi nic. Wartość powstaje przy podpięciu numeru wymagania i nazwaniu, czy to defekt, czy zmiana.
- Zgoda na „naprawimy przy okazji". Defekt bez terminu i bez właściciela wraca przed samym wdrożeniem, kiedy nie ma już czasu.
- Mierzenie ludzi zamiast procesu. Statystyka „kto zgłosił najwięcej defektów" produkuje nagięte dane w dwa sprinty. Testerzy przestają zgłaszać drobiazgi, deweloperzy zaczynają negocjować kwalifikację.
Co mierzyć, żeby wiedzieć, czy proces działa
Cztery liczby wystarczą:
- udział zgłoszeń z kompletnym opisem,
- czas od zgłoszenia do pierwszej reakcji,
- odsetek defektów odrzuconych jako nieodtwarzalne,
- liczba defektów, które wróciły po retescie.
Dwie pierwsze wyciągniesz z dowolnego narzędzia do zgłoszeń od ręki. Dwie ostatnie wymagają, żeby proces w narzędziu rozróżniał powód odrzucenia i ponowne otwarcie - jeśli tego nie ma, to jest pierwsza rzecz do ustawienia.
Najczęstsze pytania
Czym różni się defekt od usterki? To ta sama rzecz nazwana inaczej. „Usterka" sugeruje coś drobnego, więc bywa używana, żeby obniżyć wagę zgłoszenia. Jeśli słowo pada w rozmowie o odbiorze, sprawdź, czy nie chodzi o wadę w rozumieniu umowy.
Czy każdy defekt trzeba naprawić? Nie. Część świadomie zostaje: niska dotkliwość, wysoki koszt naprawy, brak wpływu na proces. Warunek jest jeden - decyzja ma być zapisana i podjęta przez kogoś, kto może ją podjąć, a nie przemilczana.
Kto decyduje, czy to defekt, czy nowe wymaganie? Decyzję podejmuje właściciel produktu albo sponsor, ale materiał do niej przygotowuje analityk: numer wymagania, jego treść i to, czy da się ją odczytać na dwa sposoby.
Czy defekt w dokumentacji to też defekt? Tak, jeśli dokumentacja jest częścią tego, co dostarczamy. Instrukcja opisująca ekran, którego nie ma, jest niezgodnością tak samo jak błąd w kodzie.
Gdzie iść dalej
- Scenariusz testowy i przypadki testowe - z czego bierze się dobry opis kroków odtworzenia.
- UAT - moment, w którym defekty znajduje odbiorca, a nie zespół. Procedurę krok po kroku opisaliśmy we wpisie UAT: jak przeprowadzić testy akceptacyjne.
- Kryteria akceptacji - najtańszy sposób, żeby spór „defekt czy nie" w ogóle nie powstał; jak je pisać, pokazujemy w poradniku o kryteriach akceptacji.
- Change request i zarządzanie zmianą - co się dzieje, gdy zgłoszenie okaże się jednak nową potrzebą.
- Plan testów i środowisko testowe - gdzie w ogóle łapie się defekty, zanim zrobi to klient.
Ćwiczenie z konfliktem dev-QA, z którego pochodzą liczby 18, 7 i 5, ma rubrykę oceny i wzorcową odpowiedź. Siedzi w module o współpracy z zespołem, w kursie „Wprowadzenie do analizy biznesowej" - to materiał dla kont z pełnym dostępem. Konto darmowe otwiera pierwszą lekcję każdego kursu i daje trzy podejścia do testów wiedzy w miesiącu, więc możesz najpierw sprawdzić, czy nasz sposób prowadzenia zajęć Ci odpowiada. Załóż darmowe konto.
Treść uzupełniona 15 sierpnia 2026.