Nie wystarczy zauważyć błąd, należy też go zgłosić. Z tego artykułu dowiesz się, jak się za to zabrać.

 

Głównym zadaniem testera jest sprawdzanie, czy produkt działa zgodnie z założeniami lub wymaganiami. Gdy podczas badania aplikacji czy programu natkniesz się na defekt, znany też w testerskim żargonie jako bug, Twoim najważniejszym zadaniem będzie jego zgłoszenie.

Podstawowe elementy zgłoszenia błędu to:

  • Tytuł;
  • Środowisko, w którym natknąłeś się na błąd;
  • Kroki reprodukcji;
  • Zachowanie oczekiwane;
  • Zachowanie rzeczywiste;
  • Załączniki.

Dodatkowe można zawrzeć:

  • ID;
  • Klasyfikację błędu;
  • Pilność naprawy;
  • Kategorię błędu;
  • Powtarzalność.

Jeśli dopiero zaczynasz swoją przygodę z testowaniem i chcesz zgłosić defekt, nie musisz od razu określać jego rodzaju i kategorii, ani oceniać jak pilna jest konieczność jego naprawy. Na to przyjdzie czas wraz ze zdobywanym doświadczeniem. Na początek skup się na elementach najważniejszych z punktu widzenia programisty/twórcy produktu. Co on/ona chcieliby wiedzieć o błędzie w swoim oprogramowaniu?

Tytuł, czyli krótki, acz bogaty w informacje opis, o co chodzi

Oczywistą oczywistością jest to, że nie wystarczy w tytule napisać, że oprogramowanie źle działa. Bardziej wartościowe będzie zawarcie w kilku słowach wszystkich ważnych informacji, które potem rozwiniesz w kolejnych elementach zgłoszenia.

Dobrym pomysłem jest zapisanie na początek tytułu roboczego, następnie wypisanie pozostałych szczegółów (środowisko, kroki, zachowanie oczekiwane a rzeczywiste) i wtedy powrócenie do tytułu, żeby sprawdzić, czy trafnie opisuje całość elementów składowych zgłoszenia.

Optymalnym rozwiązaniem byłoby też, gdyby tytuł pozwalał szybko znaleźć błąd. Można w tym celu podać ścieżkę dostępu do miejsca, gdzie występuje defekt (np. [Moje konto/Zmiana numeru telefonu] - brak walidacji pola) lub zawrzeć w tytule funkcjonalność (np. Filtr wyszukiwania - nieprawidłowe wyświetlanie wyników dla zastosowanego filtra). Ewentualnie, tytuł może stanowić krótkie zdanie typu: „Podczas przechodzenia na kolejne strony wyników wyszukiwania, nie zostaje zastosowane sortowanie po cenie”. Ważne: Strona bierna to  przyjaciel testera. Nie pisz w pierwszej osobie ani nie oceniaj tego, co zastałeś. 

Środowisko, czyli „a u mnie działa”

To, że jakiś błąd występuje w Twoim telefonie lub przeglądarce, nie oznacza, że występuje też w innych. Jak ma się to do zgłaszania defektów? Przykładowo, jeśli w Twoim telefonie klawiatura służąca do wpisywania hasła i loginu przysłania przeznaczone na to pola, warto w zgłoszeniu zamieścić model telefonu i nazwę przeglądarki, których dotyczy defekt.

Dane o dokładnej nazwie modelu telefonu znajdziesz w ustawieniach, klikając w informacje o systemie/telefonie. Oprócz tego warto również wyszukać wśród zaawansowanych informacji wersję systemu operacyjnego, z którego korzysta telefon, np. Android 9. W spisie wszystkich aplikacji, klikając na ikonę konkretnej apki, znajdziesz szczegóły dotyczące jej wersji (często poprzez rozwinięcie informacji zaawansowanych).  Dane dotyczące przeglądarek najczęściej można wyszukać w menu (kropki lub paski) w prawym rogu ekranu, wybierając „Ustawienia” lub „Pomoc”. 

Kroki reprodukcji, czyli co po kolei zrobić, żeby pokazać znaleziony błąd

Kroki wypisuje się, wykorzystując numerację liczbową i tryb rozkazujący, czyli:

  1. Wejdź na stronę  https://nazwa_strony.com/
  2. Kliknij <Moje konto> w prawym górnym rogu
  3. Wpisz poprawne dane logowania i kliknij <Zaloguj>

Należy tak opisać wszystkie czynności, aby doprowadzić osobę czytającą zgłoszenie do znalezionego defektu. Po wypisaniu wszystkich kroków warto wykonać je jeszcze raz — a nawet kilka razy, jeśli dopiero zaczynasz przygodę ze zgłaszaniem bugów. Dobrze jest mieć pewność, że nie pominęło się żadnego szczegółu, który mógłby okazać się kluczowy w odtworzeniu sytuacji, w której zaistniał błąd.

Pamiętaj, że jeśli wpisałeś w któreś pole jakąś sekwencję znaków, która wywołała defekt, koniecznie powinieneś umieścić ją w cudzysłowie w jednym z kroków. 

Zachowanie oczekiwane a rzeczywiste, czyli miało być tak pięknie, a wyszło jak zawsze

Zachowanie oczekiwane i zachowanie rzeczywiste wypisuje się w osobnych akapitach lub polach, ale warto zadbać, żeby odwoływały się one do siebie, bo są ze sobą ściśle powiązane. Jako użytkownicy technologii często mamy konkretne oczekiwania co do tego, jak powinna ona działać. W części „Oczekiwane rezultaty” warto więc wspomnieć, jak wyobrażaliśmy sobie, że system się zachowa oraz co powinno się wydarzyć lub dzieje się w takim samym momencie w innych aplikacjach/stronach/programach. Następnie, postaraj się przedstawić obiektywnie, bez emocjonalnego wartościowania, co zdarzyło się po wykonaniu wszystkich działań ze spisu kroków do powtórzenia.

Może się okazać, że twórcy danego oprogramowania nie brali pod uwagę oczekiwań, jakie Ty w stosunku do niego żywiłeś. Mimo to, warto zgłaszać zachowania, które uznasz za odchylenia od oczekiwanego stanu. Nawet jeśli twoje sugestie nie zostaną uznane za buga, w przyszłości mogą przyczynić się do podniesienia wygody użytkowania. 

Załączniki, czyli dowody zbrodni

Mówi się, że jeden obraz wart jest więcej niż tysiąc słów. Tak więc, nawet jeśli tytuł zgłoszenia nie jest idealny, a opisowi kroków daleko do doskonałości, wszystko może uratować krótki film pokazujący, jak doszło do znalezienia defektu lub zrzut ekranu opatrzony strzałkami, zakreśleniami i komentarzami wskazującymi, w czym tkwi sedno problemu.

Zachęcam do używania narzędzi, pozwalających na nagrywanie działań na komputerze (np. Screenpresso lub Screencast-O-Matic) i edytowanie zarejestrowanych obrazów (np. Skitch, edytor obrazów w Screenpresso). Jest tego w Internecie mnóstwo — na pewno każdemu świeżo upieczonemu testerowi uda się znaleźć coś dla siebie. Pamiętaj tylko, aby zapisywać swoje „dowody” w rozszerzeniach .png lub .jpg — zajmują one relatywnie mniej miejsca.

Listę defektów na początku najczytelniej będzie zebrać w arkuszu Excel lub w arkuszu online Google. Dokument online łatwo jest udostępnić odbiorcy za pomocą linku. Nie ma konieczności wysyłania sporej wielkości danych i dokumentów.

Najprostszy raport defektu może wyglądać mniej więcej tak (aby powiększyć, kliknij tabelę):

prosty-raport-bledu-testowanie-oprogramowania.png

Sposób wyświetlania załącznika w powyższym przykładzie związany jest ze stworzeniem katalogu z zebranymi zrzutami ekranu i filmami na dysku Google Drive, który należy udostępnić odbiorcy. W takim przypadku link do konkretnego pliku (zdjęcia lub filmu) można po prostu skopiować i wkleić do tabeli. Istnieje wiele innych narzędzi do zgłaszania defektów takich jak Jira, Mantis, Testlink, ale we wszystkich potrzebne są wymienione wcześniej elementy raportu. 

To już wszystko, jeśli chodzi o najważniejsze kroki zgłaszania błędów. Życzę udanego polowania na bugi i efektywnego raportowania!