jak poprawnie zgłosić błąd
Błąd, bug, issue, defekt, usterka to to czego szukamy w aplikacjach w czasie testów.

Integralną częścią naszej pracy jest zgłaszanie błędów znalezionych w aplikacji. Ważne zatem byśmy wiedzieli jak to zrobić by nasza i całego zespołu praca stała się bardziej efektywna. Dobrze opisane zgłoszenie to też mniej problemów we współpracy testera z programistą. W tym artykule opowiem, jakie są kolejne pola w formularzu zgłaszania defektu. Na koniec umieściłem przykład zgłoszenia defektu dla hipotetycznego błędu logowania do aplikacji.

Czym jest błąd?

Jest to zdarzenie w systemie niezgodne z dokumentacją biznesową lub analityczną.

Przykładowo
W dokumentacji czytamy: A + B = 2.
W aplikacji widzimy: A + B = 3.

Jak widać, na powyższym przykładzie aplikacja nie jest spójna z dokumentacją. A to znaczy, że należy zgłosić defekt.

Elementy zgłoszenia defektu

Kategoria / Tagowanie

Kategoria dotyczy rodzaju zgłoszenia. Projekt nie tylko ma błędy, ale też np. pytania do analityka (questions), główne zadania tak zwane (story), pod zadania (subtask).

Powtarzalność

W tej formatce określamy na ile prób, błąd udaje się powtórzyć. Dzięki tej informacji programista wie, że powinien kilka razy podjąć próbę odtworzenia defektu, zanim przyjdzie do nas z pytaniami o to, jak to zrobić. Jest to również ważna informacja dla testerów podczas retestów błędów.

Priorytet

Przeważnie mamy do dyspozycji sześć stopni ważności zgłoszenia. Wymieniając od najmniej ważnego będą to: Trywialny, Mniejszy, Normalny, Wysoki, Krytyczny oraz Blokujący. Szczegółowo na temat wartości pól Priorytet i Ważność napisałem w jednym z moich artykułów. Wartość w polu Priorytet ustalamy, odpowiadając sobie na następujące pytania.

  • Czy istnieje obejście problemu dzięki, któremu użytkownik może używać aplikacji?
  • Czy problem jest globalny i dotyczy całej aplikacji, czy też lokalny i dotyczy funkcjonalności w aplikacji?
  • Czy problem dotyczy nowej funkcjonalności, którą chcemy dodać do wersji produkcyjnej?
  • Czy trudno jest go powtórzyć i jak wielka jest szansa na to, że “normalny” użytkownik na niego trafi?
Temat / tytuł błędu

Krótki opis mówiący co nie działa w aplikacji. Tytuł powinien w sposób jasny i czytelny mówić co nie działa w aplikacji.

Tytuł błędu podobnie jak pozostałe pola nie powinien posiadać literówek ani błędów ortograficznych. Literówki i błędy ortograficzne sprawią, że nie będzie możliwe wyszukanie błędu po słowie kluczowym na liście błędów zgłoszonych do systemu. Jest to szczególnie ważne, gdy system testowany jest duży, ilość błędów zarejestrowanych w bug tracker jest również duża oraz gdy aplikację testuje więcej niż jeden tester.

Opis

W tym polu wpisujemy dane opisowe błędu. Mogą to być informacje szczegółowe na temat tego, jaki komunikat się wyświetlił. Albo dodatkowe informacje początkowe, jakie muszą zaistnieć, np. jeśli błąd wystąpi tylko wtedy gdy użytkownik wyczyści cash przeglądarki.

Kroki testowe

Moim zdaniem najważniejsza część zgłoszenia błędu. W tym polu opisujemy krok po kroku, tak jakbyśmy tłumaczyli komuś, kto nigdy aplikacji na oczy nie widział, co trzeba zrobić, by błąd odtworzyć. Zasady, których warto się trzymać:

  • Każdy krok opisu umieść w nowej linijce.
  • Numeruj kolejne kroki.
  • Stosuj krótkie proste zdania (niezłożone).
  • Pisz w formie drugiej osoby.
  • Nazwy pól i przycisków umieść tak jak widnieją w aplikacji (nie odmieniaj) dodatkowo warto je umieścić w cudzysłów.

Najczęstszymi błędami testerów podczas opisania kroków testowych jest niedbałość o szczegóły. Mylne założenie, że przecież wiadomo co trzeba zrobić, by powtórzyć błąd. Podanie w krokach testowych linku do aplikacji i zrzutu ekranu nie sprawia, że każdy będzie w stanie odtworzyć kroki testowe.

Testerze zapamiętaj, programista bardzo często nie zna całej aplikacji. Im dokładniejszy opis błędu, tym mniejsze prawdopodobieństwo na stratę czasu przy próbie jego reprodukcji.

Przypisanie

Zazwyczaj jest to rozwijalna lista, na której wybieramy imię i nazwisko programisty, który powinien zająć się danym zgłoszeniem. Przeważnie nad aplikacją pracuje więcej niż jedna osoba, a sama aplikacja jest całkiem spora. Powoduje to konieczność rozłożenia tejże aplikacji na obszary, za które są odpowiedzialne konkretne osoby. Jeśli zgłaszamy błąd, to staramy się go przypisać do osoby, która odpowiada za dany obszar.

Środowisko

Dla aplikacji WEB podajemy w tym polu nazwę przeglądarki, jej wersję oraz wersję aplikacji.
Jeśli defekt wystąpił w aplikacji mobilnej, to podajemy wersję aplikacji oraz wersję systemu Android/IOS a czasami też model telefonu.
W przypadku aplikacji na komputery podajemy system operacyjny oraz wersję aplikacji, na której znajduje się błąd.

Załączniki

Wszystkie dodatkowe informacje pomagające programiście namierzenie błędu, w szczególności są to: logi skopiowane z przeglądarki, zrzut ekranu (format .png), filmik (.mp4). 

Pamiętaj, że załącznik (zrzut, filmik) powinien pokazywać możliwie jak najwięcej by pomóc odnaleźć błąd. Dobrą praktyką jest zaznaczyć na zrzucie ekranu gdzie jest błąd (najprościej użyć w tym celu Paint i ramką czerwoną otoczyć właściwe miejsce na obrazku).

Zgłaszanie błędu na przykładzie programu Mantis

Na prowadzonych przeze mnie szkoleniach testowania oprogramowania wiele uwagi poświęcam na ćwiczenia praktyczne. Mantis jest jednym z programów, na którym odbywają się takie właśnie ćwiczenia. Program jest na licencji GNU, co oznacza, że bez opłat możecie go pobrać i ćwiczyć na nim zgłaszanie błędów.

Wracając do przykładu

Załóżmy, że masz do przetestowania ekran logowania do aplikacji. Po wpisaniu poprawnego loginu i hasła, kliknięciu zaloguj, otrzymałeś komunikat o błędzie jak na poniższym obrazku.

przykładowy komunikat o błędzie
Przykład - Komunikat o błędzie

Dla upewnienia sprawdzasz jeszcze dwa razy – błąd występuje za każdym razem. Przechodzisz zatem do jego opisu.

Mantis przykład zgłoszenia błędu
Mantis, zgłoszenie błędu, pola "Temat", "Opis" oraz "Kroki, by powtórzyć"
Czy każdy znaleziony błąd powinien być zgłoszony?

Uważam, że nie. Przykładowo, załóżmy, że po wgraniu aplikacji na środowisko testowe i uruchomieniu jej od razu mamy błąd i nie możemy pracować. Myślę, że w tej sytuacji efektywniej będzie pójść do odpowiedniego programisty i poprosić go o rzucenie okiem na środowisko i jego naprawę. Ważne, aby pamiętać, że wszyscy mamy wspólny cel, czyli dobry produkt oddany do klienta w skończonym czasie. Nie ma więc sensu tracić siły czas i energię na zgłaszanie takiego błędu.

Co się dzieje z błędem po jego zgłoszeniu?

Po zapisaniu błędu w systemie otrzymuje on status “Otwarty”. Jeśli opisaliśmy zgłoszenie tak jak należy, czyli nie będzie wątpliwości gdzie jest błąd i na czym polega, to powinniśmy do niego wrócić, gdy otrzyma status “Do sprawdzenia”. Ale zanim go otrzyma, będzie on powtórzony przez programistę, następnie przez niego poprawiony. Kolejnym krokiem będzie review poprawki zrobiony przez innego programistę niż, ten który poprawił defekt. Więcej o cyklu życia defektu przeczytasz w jednym z moich artykułów.

Waldemar Szafraniec

Nazywam się Waldemar Szafraniec. Karierę testera rozpocząłem w 2012 roku. Od początku pracy w zawodzie wiedziałem, że będzie to coś więcej niż tylko praca. Obecnie praca jest również moim hobby. Jednym z moich obowiązków w obecnym miejscu pracy jest rekrutowanie nowych testerów oraz szkolenie ich. Sam stale podnoszę swoje kwalifikacje uczestnicząc w szkoleniach (ISTQB, ISTQB Advanced Level – Test Analyst). Szkolę ludzi w dziedzinie testów manualnych od 2014 roku. Jestem trenerem, ponieważ wiem, że dobrze mi wychodzi przekazywanie wiedzy, wiem jak praca testera wygląda oraz mam doświadczenie w rekrutacji.

Dodaj komentarz

Zamknij