Redakcja
Naszą uwagę przykuła odpowiedź Asi pod jednym z komentarzy na TestingCup: http://testingcup.pl/koniec-zapisow-na-zawody-beda-kwalifikacje/
W tegorocznych kwalifikacjach do TestingCup będzie zadanie polegające na przetestowaniu specyfikacji. W jednym z pytań pojawiła się następująca wątpliwość: "Czy defekty typu literówki (i pokrewne) – każdy zgłoszony osobno – będą traktowane jako duplikaty? Jeśli znajdziemy np. kilkanaście takich literówek – powinniśmy wszystkie sklasyfikować jako jeden bug?"
Asia odpowiedziała:
"Defekt w specyfikacji jest problemem powiązanym z tym, że coś jest niejasne.
Możliwe są następujące zdarzenia:
- pojedynczy błąd w specyfikacji powoduje pojedynczą niejasność – przygotowujemy jeden raport
- grupa błędów przekłada się na jedną niejasność – przygotowujemy jeden raport
- pojedynczy błąd powoduje szereg niejasności – przygotowujemy jeden raport z silnym wskazaniem przyczyny źródłowej
- grupa błędów przekłada się na szereg niejasności – przygotowujemy raporty osobno dla każdej niejasności."
Choć uwaga ta może nie być przydatna w 100% przypadków, to osobiście znajdzie zastosowanie w większości znanych nam projektach.
Dalej już na przykładzie:
“Orpogramwanie ma być zgodne z WCAG 2.0″ – jest podwójną literówką w jednym słowie – jeden raport. “Orpogramwanie ma by zgdone z WCAG 2.0″ – jest niejasnością wynikającą z wielu literówek – jeden raport.
Wszędzie gdzie się da, próbujemy redukować do jednego raportu.
Raport pod tytułem “Literówki” z wypisanymi wszystkimi miejscami z literówkami będzie traktowany jako błędny."
Podkreślimy dodatkowo jedną część odpowiedzi: Wszędzie gdzie się da, próbujemy redukować do jednego raportu.
Testowanie oprogramowania nie jest wyścigiem, kto zaraportuje najwięcej defektów. Jest to próba uzyskania najlepszej miary jakości możliwie najmniejszym kosztem. Uwzględnia to również nie marnowanie naszego (i innych członków zespołu) czasu na pisanie i czytanie dzięsiątek czy też setek raportów z trywialnymi zgłoszeniami.
