Redakcja
DDP jest skrótem od Defect Detection Percentage i na polski tłumaczy się jako odsetek wykrytych defektów (OWD). Definicja słownikowa nie jest zbyt pomocna w zrozumienie jej sensu:
Liczba defektów wykrytych na poziomie testowania, podzielona przez liczbę defektów wykrytych w całym cyklu życia oprogramowania (na poziomie testów i później).
Czym jest DDP?
Z wyjaśnieniem DDP przychodzi nam nieoceniona Dorothy Graham, wraz z "MEASURING TESTING EFFECTIVENESS USING DEFECT DETECTION PERCENTAGE". Jest to metryka, która pokazuje naszą (głównie testerską) zdolność do wykrywania problemów. Zestawiamy nasze osiągnięcia ze wszystkimi defektami znalezionymi w projekcie. Czym bliżej 100%, tym skuteczniejszym zespołem jesteśmy.
Jak policzyć DDP?
Aby obliczyć tę metrykę, bierzemy pod uwagę dwie wartości związane z defektami i zestawiamy je zgodnie z poniższym wzorem:
A – defekty, które mogły być wykryte przez technikę/metodę/typ testów, ale z jakiegoś powodu zostały wykryte później,
B – liczbę defektów związanych z jakąś techniką/metodą/typem testów,
A+B – wszystkie znane defekty w oprogramowaniu.
Przykład:
A - Liczba defektów, wykrytych już po wydaniu danej wersji oprogramowania.
B - Liczba defektów, które udało się znaleźć przed wydaniem oprogramowania
Wzór do wyliczenia DDP:
DDP = B/(A+B) * 100
Używając prawdziwych wartości możemy to zobrazować w następujący sposób:
Jak interpretować DDP?
Jak napisaliśmy na wstępie, najlepsze zespoły powinny dążyć do 100% DDP. Jest to oczywiście nieosiągalne i pewien margines jest dopuszczalny:
-
98% i więcej traktuje się jako testowanie na bardzo wysokim poziomie,
-
95% do 98% to dobra skuteczność testów,
-
poniżej 95% mówimy o problemach w testowaniu, które trzeba zidentyfikować i wprowadzić korekty,
-
poniżej 60% mówimy o testach bardzo niskiej jakości.
Kontrowersje DDP
-
Jak każdą metryką, tą również można manipulować. Jeśli nie wyróżnia się w niej krytyczności znalezionych defektów, to zespół testowy może "pompować" wartość A przy pomocy zgłoszeń trywialnych.
-
O czym mówi nam liczba defektów? Czy jest to miara jakości (braku jakości)? Wielu ekspertów podkreśla, że to, ile defektów znajduje się w oprogramowaniu, nie mówi nam wystarczająco wiele o produkcie. Wyjątkiem będzie sytuacja, kiedy same defekty są krytyczne lub też blokujące kluczowe funkcje oprogramowania.
-
Metryka nie uwzględnia również czasu poświęconego na testy. Jeśli czas testów przed wydaniem był znacząco mniejszy od tych po wydaniu, to wyniki mogą być bardzo zaburzone.
-
Samo zebranie danych do metryki wymaga dużo czasu i często odbywa się po tym, jak zespół projektowy zostaje już rozwiązany.
-
Liczba defektów musi być znacząca. Za mała próbka to niewiarygodne wyniki.
-
Metryka nie nadaje się (jak każda inna ilościowa) do oceny indywidualnych osób.
