Defekty możemy podzielić (w najprostszym ujęciu) na znalezione i na nieznalezione. Znalezienie defektu nie oznacza jego naprawienia. Są dziesiątki powodów, dla których defekt nie zostanie naprawiony (część z nich zapewne znacie):
- to nie jest (prawdziwy) defekt
- nie da się odtworzyć defektu
- defekt ze zbyt dużym impaktem na inne funkcjonalności. Poprawka może wprowadzić np. destabilizację
- defekt zbyt kosztowny do naprawienia.
- trywial, będzie naprawiony jeśli w zespole progarmistycznym pojawi się nuda
- to nie defekt, to funkcjonalność
- itd.
W każdym z tych przypadków tester (autor raportu) zostaje postawiony przed koniecznością bronienia swojego stanowiska. Może uznać, że defekt rzeczywiście nie musi być poprawiony, czym jednocześnie przyznaje się do błędu raportowania defektu, który defektem nie jest. Może również bronić swojego stanowiska. Upór musi jednak mieć trwalsze podstawy niż zwykłe "bo tak". Jednym z podstawowych narzędzi będzie tu budowanie wokół pojedynczego defektu analizy biznesowej. Co wydarzy się jeśli defekt zostanie znaleziony przez użytkownika? Jakie są potencjalne konsekwencje finansowe względem nakładu i wysiłku na poprawkę. Ostatecznie zawsze należy pamiętać o perspektywie użytkownika, który prędzej powie: "Nie działa", "Utraciłem dane" niż: "Znalazłem defekt".
Inspirowane: http://testobsessed.com/2012/08/bugs-spread-disease/
Grafika: http://imgrin.pl/@tester/all/meme/357