Redakcja
Poświęcamy wiele czasu, aby weryfikować jakość oprogramowania i poszukiwać defekty. Kiedy je znajdziemy poświęcamy dużo czasu, aby je zaraportować. Na końcu okazuje się, że wiele z nich jest odrzucanych. Zadajemy sobie wtedy pytanie: dlaczego?
Odrzucenie zgłoszeń defektów przez "projekt" jest jednym z najważniejszych demotywatorów w naszej pracy. Mając przekonanie o słuszności naszych racji otrzymujemy informację o niepoprawności naszego myślenia. Jeżeli wstępnie skreślamy opcję, że to my mamy rację, a wszyscy inni się mylą to pozostaje kilka innych możliwości.
Oto 10 głównych powodów odrzucania zgłoszeń:
- Złe zrozumienie wymagania przez testera. Należy przyznać się do błędu, nauczyć się na tym przykładzie i żyć (testować) dalej.
- Brak wymagania. Problem wynikający zazwyczaj z braku komunikacji. My jako testerzy zakładamy, że ta funkcja powinna być zaimplementowana, ale programista jej nie zaimplementował ponieważ dostał inne wytyczne. Defekt do zamknięcia, a ogólna rekomendacja dla projektu to usprawnić przepływ informacji.
- Niejasne wymaganie, które można interpretować na wiele sposobów. Defekt jest odrzucony dla oprogramowania, ale problem warto eskalować do osób odpowiedzialnych za jakość wymagań. Próba poprawy wymagania na pewno pomoże w dalszych etapach projektu.
- Zmiana w wymaganiach. W międzyczasie wymaganie się zmieniło, ale informacja o zmianie nie dotarła do testera. Kolejny problem komunikacyjny z rekomendacją do kierownika projektu.
- Poza zakresem. Testujemy obszar, którego nie powinniśmy z wielu powodód testować. Komunikacja po raz trzeci. Nasza praca bazuje na informacji i jeśli jej nie dostaniemy na czas to marnujemy swój czas i innych osób.
- Defekt środowiska. Zła konfiguracja, lub po prostu błąd w sprzęcie doprowadza do problemu, który nie jest realnie problemem oprogramowania. Tu przyczyn źródłowych może być wiele, ale gdzieś w tle pojawi się brak instrukcji, złe wymagania lub powtarzany już problem komunikacji.
- Dane testowe. W naszych testach zastosowaliśmy dane, które nie powinny być użyte. Możemy wykryć błąd walidacji, ale nie problem funkcji. Konieczność zdefiniowania i śledzenia danych testowych.
- Duplikat. Ktoś zaraportował to przed nami. Klasyczny błąd testera oprogramowania. Przed napisaniem własnego raportu upewnij się, że ktoś nie znalazł tego problemu i już go nie opisał.
- Zły opis dla defektu. Opis jest niezrozumiały, albo nie daje wystarczającego uzasadnienia dla defektu. Jest to najprawdopodobniej brak umiejętności raportowania i wymaga szybkiego naprawienia (nauczenia).
- Niereprodukowalny. W przypadku gdy sami nie jesteśmy w stanie zreprodukować defektu, taki sam problem będzie miał (prawdopodobnie) programista. Defekt zostanie odrzucony, co wcale nie znaczy, że ma być zamknięty. Musi być obserwowany podczas dalszych testów.
Kilka dobrych rad jak raportować defekty: http://testerzy.pl/artykuly/raportowanie-defektow-dla-nie-testerow
Inspirowane: www.softwaretestinghelp.com/why-your-bugs-are-getting-rejected/
