Defect Detection Ratio - jak mierzyć skuteczność zanim cokolwiek trafi na produkcję

Seria: QA Leadership · Artykuł 2 z 9

Wchodzisz na 1:1 z Engineering Managerem. Pada jedno pytanie: „Ile z tych bugów łapiecie zanim trafią do klienta?" - i rozmowa zaczyna się sypać. Nie dlatego, że źle testujecie. Dlatego, że nie macie jednej liczby.

I wtedy rozmowa zaczyna się sypać. Nie dlatego, że źle testujecie. Dlatego, że nie macie liczby, która odpowiada na to pytanie wprost. Jednej. Konkretnej. Gotowej.

Ta liczba istnieje. Nazywa się Defect Detection Ratio - i jest tematem tego artykułu.

Czym jest DDR - i czym nie jest

Defect Detection Ratio to odsetek defektów wykrytych przez QA przed trafieniem na produkcję w stosunku do wszystkich defektów znalezionych łącznie - zarówno przed, jak i po releasie. Innymi słowy: spośród wszystkich problemów, które ostatecznie wyszły na jaw - ile złapaliście sami, zanim zobaczył je klient?

To jest metryka skuteczności procesu testowania. Nie aktywności. Odpowiedź na pytanie: jak dobrze działamy jako filtr przed produkcją?

DDR pyta o coś fundamentalnie innego niż pass rate czy coverage: czy Twój proces testowania faktycznie wyłapuje to, co ważne?

DDR to nie to samo co pass rate. Możesz mieć pass rate 99% i DDR 50% - jeśli testy nie pokrywają obszarów, w których siedzą bugi.

DDR to nie to samo co coverage. Możesz przelecieć przez 90% kodu i nie sprawdzić ani jednego krytycznego scenariusza biznesowego. Dotknięcie to nie to samo co weryfikacja.

Od prostej do zaawansowanej formuły

Wersja podstawowa

Wersja z wagami krytyczności

Podstawowa formuła traktuje każdego buga jednakowo. Ale bug blokujący płatności waży więcej niż literówka w tooltipie. Warto rozszerzyć formułę o wagi.

Kalkulator DDR

Wpisz swoje dane i sprawdź wynik. Włącz tryb ważony, by uwzględnić krytyczność bugów.

Jak czytać wynik - progi i kontekst

DDR nie jest absolutną prawdą. Jest wskaźnikiem - i jak każdy wskaźnik, wymaga interpretacji. Ale pewne progi branżowe warto znać jako punkt odniesienia.

Kontekst branżowy ma znaczenie. W systemach finansowych i medycznych 90%+ to minimum, nie aspiracja. W szybko iterującym startupie 80% przy wysokiej częstotliwości releasów może być świadomym, akceptowalnym kompromisem.

Dlaczego nie możesz zacząć od dziś - dane historyczne

Jeden z najczęstszych błędów przy wdrażaniu DDR: zespół zaczyna mierzyć od bieżącego sprintu i po miesiącu ma jeden punkt danych. Jeden. Z którego nie da się wyciągnąć żadnego wniosku.

DDR bez historii jest jak mapa bez skali. Wiesz, że jesteś gdzieś - ale nie wiesz, w jakim kierunku idziesz i jak szybko.

Zanim zaczniesz mierzyć “od teraz”, zrób coś znacznie cenniejszego: odtwórz dane wstecz. Większość organizacji ma wszystkie niezbędne dane - tylko nikt ich jeszcze nie połączył w ten konkretny sposób.

Skąd wziąć dane historyczne

project = MYAPP AND issuetype = Bug AND created >= "2025-01-01"
ORDER BY created ASC

Sezonowość i prawidłowości

Gdy masz 12 miesięcy danych, zaczynasz widzieć prawidłowości, których intuicja nie wychwyci.

Minimum viable approach - jak zebrać dane praktycznie

Case study - od 74% do 94% w cztery kwartały

Siedmioosobowy zespół (5 devów, QA, automatyk), platforma SaaS dla klientów korporacyjnych. Na początku roku DDR 74% - trzy na dziesięć bugów ląduje na produkcji.

„Każde 5 punktów procentowych DDR to średnio 4 mniej escaped bugów na kwartał, przy koszcie 8 godzin każdy - to jest 32 godziny seniorów. Na jeden kwartał." - Budżet zatwierdzony.

Kiedy DDR kłamie - trzy pułapki

Każda metryka ma słabe strony. DDR ma trzy konkretne - i warto je znać, zanim zaczniesz jej ufać ślepo.

DDR w rękach biznesu - najniebezpieczniejsza pułapka

Tej pułapki nie znajdziesz w podręczniku ISTQB. A jest najgroźniejsza, bo dotyka nie metody pomiarowej, lecz sposobu interpretacji przez osoby, które nie znają kontekstu.

Wyobraź sobie: pokazujesz Product Ownerowi DDR 94%. Jest zadowolony. Mówi: „świetnie, jesteśmy bezpieczni, releasujemy.” Ale nie wie, że w tym samym kwartale liczba releasów wzrosła z 3 do 10.

DDR rośnie przez wszystkie cztery kwartały. Wygląda świetnie. Ale liczba escaped bugów w liczbach bezwzględnych rosła przez Q1-Q3. Klient przez trzy kwartały odczuwał więcej problemów na produkcji - mimo rosnącego DDR.

DDR nigdy nie działa samotnie. Ma pełny sens tylko razem z Escaped per Release (artykuł 5) i Number of Releases (artykuł 6). Prezentując DDR stakeholderom - zawsze pokazuj go z co najmniej jedną metryką kontekstową.

Jak wdrożyć DDR w czterech krokach

Dość teorii. Oto co zrobić w najbliższym tygodniu.

DDR w rozmowie z biznesem

Trzy konteksty. Trzy poziomy szczegółowości. Jeden wskaźnik u podstawy każdej rozmowy.

Co DDR mówi - i czego nie mówi

Używaj DDR jako jednej z pięciu liter alfabetu. Razem tworzą słowo. Osobno - to tylko literki.

W następnym artykule

Artykuł trzeci tej serii dotyczy Escaped Bugs & Problems - i zaczyna się od pytania, które większość QA zadaje zbyt rzadko: czy naprawdę mierzymy wszystko, co ucieka na produkcję?

Spoiler: prawie nigdy. I to, co pomijamy, jest często ważniejsze niż to, co liczymy.

Linki w serii