Subiektywna ocena krytyczności zgłoszenia

Rafał Mianowicz na swoim blogu geekuj.pl krytycznie odniósł się do tego, jak zawody oceniają umiejętności testerów.

Przez blisko 7 lat pracy w zawodzie Testera Oprogramowania zostałem nauczony, że jedną z najważniejszych rzeczy podczas testów aplikacji jest jej weryfikacja zgodności z dokumentacją techniczną/funkcjonalną.

I dalej pisze: Jeden z zapisów opisu funkcjonalnego testowanej podczas kwalifikacji aplikacji brzmi:“brak możliwości wklejenia danych do specyficznych pól tekstowych – textarea”Okazuje się jednak, że jest to nieprawda i ISTNIEJE możliwość wklejana danych do pól tekstowych typu = textarea.

Zostało to zgłoszone jako defekt, ale nie zostało uznane jako warte większej uwagi (1 na 10 punktów), z czym autor nie może się zgodzić.

Jak w prowadzonej dyskusji odpowiedziała mu Agnieszka Jeruzalska jej interpretacja była zgoła inna: [...] ponieważ sekcja nazywała się "znane ograniczenia" to uznałam, że tego mam nie sprawdzać, nie patrzyłam na to jak na dokumentację, ale raczej jako wskazówki dla uczestnika kwalifikacji - czy słusznie, nie wiem. Zauważyłam, że da się wklejać w textarea (bo zdaje się, że o tym błędzie rozmawiamy), ale nie powodowało to nieprawidłowego działania aplikacji, więc niespecjalnie zwróciłam na to uwagę.". W dalszym komentarzu napisała: "Ocena krytyczności defektu zawsze będzie subiektywna.

W skrócie: defekt polega na tym, że aplikacja ma znane ograniczenia dla specyficznych pól, a tester uznał, że jednak część pól tych ograniczeń nie ma.

Na pytanie, czy można to potraktować jako defekt i jak bardzo jest on krytyczny powinna odpowiedzieć dalsza analiza:

1. Jak krytyczne jest to dla użytkownika? Skoro użytkownik może zrobić coś ponad to, co jest opisane i jest to dla niego korzyść, czy jest to defekt?
2. Czy opis niebędący specyfikacją produktu, a listą znanych ograniczeń jest defektem opisu czy aplikacji?
3. Jak krytyczne jest to dla użytkownika / projektu / produktu?
4. Ile można stracić na tym problemie?
5. Jakie ryzyka są z tym związane?
6. Itd.

Odpowiedź na wszystkie te pytania wymagają głębszej analizy kontekstu i zrozumienia celu powstania aplikacji i środowiska jej użycia. Analiza na końcu powinna wskazać, jak krytyczny jest ten defekt i czy opłaca się go naprawiać. Widać, że projekt, który zbudował ten produkt uznał to za coś możliwego do pominięcia i nieważnego.

W prawdziwym świecie tester ma często bardzo podobną sytuację i musi zmierzyć się z podobnym problemem. Raportując defekt przekazujemy go do człowieka lub grupy, która musi podjąć decyzję na temat krytyczności defektu. Osoby podejmujące decyzję to w wielu przypadkach kierownicy testowania, jakości czy projektu. Czasami są to również klienci biznesowi, a w najgorszym przypadku pojedynczy programista. To oni powiedzą, czy defekt jest ważny i czy trzeba to naprawić. Czy ta ocena jest subiektywna? Częściowo oczywiście TAK. Wynika z innej, często szerszej, perspektywy.

Tester raportujący defekt, którego krytyczność określa jako najwyższą musi liczyć się z tym, że Projekt uzna defekt jako mało znaczący problem i obniży jego wagę. Można oczywiście z tym polemizować, ale ostateczna decyzja rzadko kiedy należy do testera. Eskalacja problemu otrzeć się może o najwyższe szczeble decyzyjne w organizacji i to one podejmą decyzję o krytyczności. 

Źródła