Dlaczego nasze defekty nie są defektami?
4.8 (31 ocen) , ostatnia aktualizacja 4.06.2020 r.
Należy zacząć od definicji wyniku fałszywie pozytywnego (false-positive) czyli takiego który nieprawidłowo wskazuje na obecność defektu, kiedy w rzeczywistości
go nie ma. Wg słownika testerskiego SJSI rezultat fałszywie niezaliczony (czyli fałszywie pozytywny) to "Test, w którym defekt został zaraportowany,
chociaż defekt wcale nie występuje." W słowniku ISTQB® wersji angielskiej znajdziemy też określenie false-positive result czyli "A test result in which a defect
is reported although no such defect actually exists. Synonyms: false-fail result" Dlaczego więc nasz defekt nie jest klasyfikowany jako defekt? Najczęściej pojawią się odpowiedź,
że to przecież wina tego który sprawdza. Kto inny jak nie tester jest odpowiedzialny za to, że zgłoszony błąd jest tak naprawdę prawidłowym zachowaniem?
Przyjrzyjmy się temu bliżej.
Zmiana wymagań w trakcie pracy
Często zdarza się, że pracujemy zgodnie z wymaganiami, które są w między czasie zmieniane, poprawiane, rozbijane na kilka innych. Niestety, ale wtedy bardzo często tester jest osobą, która dowiaduje się o zmianach dopiero w momencie, gdy jego defekt zostanie zwrócony. Innymi słowy to nie defekt...
Niejednoznaczne wymagania albo ich brak
Bywa i tak, że ciężko nam jednoznacznie stwierdzić czy to jest defekt czy być może tak ma być. Weźmy na przykład logowanie do systemu, które trwa w nieskończoność, ale zawsze się udaje. Czy możemy to rozpatrywać jako defekt? Rozsądny użytkownik raczej tego nie zaakceptuje. Z drugiej strony nie ma jednoznacznego wymagania niefunkcjonalnego, które określa, ile czasu powinna trwać taka operacja. Dochodzimy tutaj do znanego już określenia 'its not a bug, its a feature'. Jeśli wcześniej nie pomyśleliśmy o tym jak nasz system w podanym scenariuszu powinien się zachować to może zaimplementujmy nową funkcjonalność. I znowu dochodzimy do sytuacji, gdzie nasz defekt nie jest defektem...
Nie naprawiamy (Won`t fix)
Zdarza się, że niezależnie od tego czy nasz defekt opisuje poprawne zachowanie czy nie to nie jest naprawiany. Dlaczego? Projekt może być tak bardzo zaawansowany, wręcz na ukończeniu i nikt nie chce wprowadzać kluczowych zmian - o ile np. są konieczne do spełnienia kluczowych wymagań systemu. Może być też tak, że naprawa defektu nie wnosi żadnej wartości biznesowej i z punktu widzenia klienta naprawa może nie mieć żadnego znaczenia.
Jak widać sporo defektów, które ostatecznie nie są klasyfikowane jako defekty nie mogą świadczyć o niskiej jakości pracy testerów. Składa się na to zarówno praca testerów, developerów, to czy znajdujemy się w obiegu informacji oraz ogólnie mówiąc jakości prowadzonego projektu.
Autor: Paweł Kwasik