Redakcja
W dużym uproszczeniu defekt może powstać w następujący sposób:
- klient wyraża się nieprecyzyjnie,
- analityk źle rozumie wymagania klienta,
- programista koduje zgodnie z błędnymi wymaganiami,
- tester znajduje defekt jako niespójność między tym, co klient naprawdę chce, a tym, co zostało dostarczone.
Działania, które prowadzą do znajdywania defektu, to tzw. kosztów złej jakości:
- koszt przygotowania warunków do zweryfikowania oprogramowania,
- koszt uruchomienia weryfikatorów,
- koszt znalezienia defektu.
Dalsze działania są już jedynie gaszeniem pożaru, któremu potencjalnie można było zapobiec oraz dalszym marnotrawstwem:
- czas potrzebny na zaraportowanie defektu,
- czas potrzebny na analizę zgłoszenia,
- czas potrzebny na znalezienie przyczyny źródłowej problemu,
- czas na naprawienie defektu.
Kolejne kroki to już działania testerskie takie jak:
- uruchomienie retestu i potwierdzenie, że defekt został usunięty,
- wykonanie testu regresji, aby potwierdzić, że wprowadzona poprawka nie spowodowała skutków ubocznych.
A to i tak jest optymistyczny scenariusz, czyli happy flow, bo jest wiele możliwości zejścia z tej uproszczonej ścieżki, np.:
- defekt wraca do testera jako niezrozumiały,
- defekt nie może być naprawiony ze względu na wyższe priorytety innych defektów,
- defekt może być podstawą do zmiany wymagań i negocjacji projektowych,
- i wiele więcej.
Poniższa tabela pokazuje, jakie koszty ponosi się na defekty w zależności od tego, kiedy zostają wprowadzone i kiedy zostaną naprawione.
W projekcie, na pojedynczym defekcie przepalono więc dużo czasu, a przez to i pieniądze, zaangażowano wiele ról i wdrożono narzędzia do obsłużenia problemu. Staje się jasne, że zapobieganie powstaniu defektów (czyli zapewnienie jakości) może być mniej kosztowne niż ich znajdowanie i usuwanie (czyli kontrola jakości).
Oczywiście nie jest też tak, jak w klasycznym "nie o to chodzi, by złowić króliczka, ale by gonić go". Jeśli już defekt się pojawi, to chcemy go zaraportować, ale gros naszej pracy to jedynie uruchomienie oprogramowania, aby potwierdzić, że ono działa. Powinniśmy też mieć świadomość, że zarówno znajdywanie, jak i nieznajdywanie defektów jest OK.
To pierwsze powoduje, że mamy świadomość istnienia problemu, mamy więc również szansę na jego poprawienie. Nieznajdowanie defektów, choć może być objawem nieskutecznego testowania, częściej będzie potwierdzeniem, że dostarczamy rozwiązanie wysokiej jakości.
