Przygotowałem nagranie mp3 tego wpisu, jeśli zatem wolisz słuchać niż czytać, to zachęcam do pobrania pliku :).
W celu pobrania pliku kliknij w obrazek ze słuchawkami.
Czy widziałeś kiedykolwiek odcinek „Alternatywy 4”, w którym fachowcy pojawiają się w mieszkaniu, aby zaproponować poprawę układu rur z ciepłą wodą? Kiedy zapytano ich, dlaczego nie ułożyli rurek od razu w odpowiedni sposób, odpowiedzieli: „No, ale tak było na planie!” Ta scena skojarzyła mi się z tematem „works as designed”.
Dzisiejszy wpis ma charakter promocyjny mojej książki dotyczącej testowania oprogramowania, zmiany zawodu oraz poszukiwania pracy. Książkę możesz kupić w moim sklepie. Tymczasem zachęcam do przeczytania krótkiego fragmentu.
Pamiętasz cykl życia błędu, który opisałem w poprzednim rozdziale? Ostatnim etapem jest zamknięcie błędu i nadanie mu jednego z wyników (w Jira jest to pole resolution): as designed, duplicated, resolved lub inny zdefiniowany w aplikacji do zgłaszania błędów. Jak zapewne się domyślasz, wynik ustawiony jako resolved oznacza, że błąd jest poprawiony, zretestowany i już nie występuje. O tym, co znaczą, pozostałe dwie wartości przeczytasz w tym i następnym rozdziale.
Co oznacza status Works as Designed?
Jak już zapewne wiesz, zanim zaczniemy zgłaszać błędy do aplikacji, powinniśmy najpierw zapoznać się z dokumentacją aplikacji. Powinniśmy poznać jej specyfikację, czyli zrozumieć jak ona ma działać.
Błędy zamknięte z resolution Works As Designed to defekty, których zgłoszenie jest niezasadne, ponieważ aplikacja działa zgodnie z makietą/dokumentacją jednym słowem są zgodne z zamysłem osoby decyzyjnej.
Dlaczego zgłaszamy błędy Works as Designed?
Myślę, że najczęstszym powodem jest używanie niezaktualizowanej dokumentacji. Powiesz pewnie, ale jak to możliwe?
Czasami zdarza się, że ustalenia mailowe czy to słowne nie są przenoszone do dokumentacji. Przyczyn może być kilka, od braku czasu po zapomnienie. Jako tester możesz być bardzo zaskoczony, może nawet oburzony, że błąd jest zamknięty jako Works As Designed. Przeczytałeś przecież dokumentacje, znasz projekt. A jednak. Niestety nie ma co walczyć, trzeba zaktualizować dokumentację i przejść do dalszej pracy.
Błąd Duplicated
Duplicated czyli zduplikowany? No nie, wiadome, że nie kopiujemy/duplikujemy nowych zgłoszeń ze starych. Resolution Duplicated oznacza, że defekt opisany przez nas jest taki sam jak inny zgłoszony już do systemu wcześniej. Nie ma zatem sensu by oba zgłoszenia pozostały na liście błędów do poprawienia, dlatego jeden z nich jest zamykany (zwykle ten zgłoszony jako drugi).
Dlaczego zgłaszamy błędy Duplicated?
Najczęsciej błędy zduplikowane pojawiają się w zespołach większych i słabo skoordynowanych, pracujących nad długim i dużym projektem.
Czasami spieszymy się by zgłosić defekt i zapominamy sprawdzić poprzez wyszukanie na liście błędów już zgłoszonych, czy podobny błąd był już zgłoszony.
Do tego dochodzi kwestia kiepskiej organizacji zgłoszeń w Jira. Przykładowo brak struktury typu Story -> Subtask/Bug przypisany do konkretnego Story/Epica odnoszącego się do konkretnej funkcjonalności.
