Redakcja
Aby to zrobić na pierwszym miejscu musimy zrozumieć kontekst projektu i otoczenie naszego użytkownika. Kupujący oprogramowanie nie rzuci się na nie w poszukiwaniu błędów, a będzie próbował realizować zadania, jakie wspiera dane narzędzie. Czy będzie to gra komputerowa czy oprogramowanie do tworzenia procesów, użytkownik pokłada wiarę, że będzie ono dobrze mu służyło. Dlaczego więc tester oprogramowania miałby koncentrować się na wyszukiwaniu najmniejszych problemów oprogramowania? Dlaczego miałby być zorientowany na problemy, zamiast koncentrować się na scenariuszach pracy użytkownika?
Kiedy zależy nam na projekcie i chcemy pokazać nasze umiejętności, znalezienie defektu staje się naszą małą obsesją. Zaczynamy testować oprogramowanie i póki nie znajdziemy tego pierwszego, ważnego defektu pojawia się denerwujące poczucie braku realizacji celu. Kiedy się już jednak go znajdzie, pojawia się to wyjątkowe uczucie pewności siebie. Te emocje można, a nawet trzeba, zachować dla siebie. Nikt w projekcie nie zrozumie jeśli, niczym piłkarz po strzeleniu gola, będziemy na kolanach przejeżdżać między boksami w przestrzeni biurowej, ciesząc się i krzycząc "Jest!". Nikt nie ucieszy się na widok wystrzelonego w górę konfetii, kiedy natrafimy na defekt blokujący wejście oprogramowania na produkcję.
Poszukiwanie defektów jest ekscytujące, ale ich znajdywanie nie cieszy użytkowników, programistów czy kierowników. Coś, co testerom dostarcza emocji, resztę może mocno zdenerwować. Z jednej strony lepiej mieć świadomość, że defekt w oprogramowaniu jest i możemy go usunąć niż przepuścić go na produkcję. Najlepiej jednak kiedy udałoby się wyprodukować oprogramowanie bez poważnych defektów.
Warto więc zamiast szukania defektów koncentrować się na informacji. Ilość znalezionych defektów także jest informacją, ale nie warto z tej informacji robić najważniejszej wiadomości dnia. Oprogramowanie z defektami może wyjść do klienta pod warunkiem, że mamy pełną informację o konsekwencjach defektów i przekonanie, że klient jest w stanie działać wydajnie pomimo ich obecności. Nie da się tego osiągnąć jeśli naszym jedynym celem jest znajdywanie defektów.
Inspirowane: blog.smartbear.com/testing/hunt-for-information-not-bugs/
