Błędy to chleb powszedni testera. Każdego dnia spotykacie się z mnóstwem niepoprawnego zachowania aplikacji, czy błędów znalezionych już na etapie czytania dokumentacji. Jak wszyscy doskonale wiemy, błędy znalezione na etapie dokumentacji, błędne zaprojektowane ścieżki biznesowe, są największym zagrożeniem dla wytworzenia dobrej jakości kodu i przede wszystkim wypuszczenia na rynek w pełni działającej i przydatnej funkcjonalności.

W trakcie szukania pracy i uczestniczenia w rozmowach kwalifikacyjnych praktycznie zawsze spotykałam się z pytaniami, dotyczącymi nie tylko wiedzy teoretycznej z zakresu błędów np. Jak dzielą się błędy ze względu na ich poziom istotności?, ale również z zadaniem dotyczącym napisania przykładowego zgłoszenia błędu. Zadanie to bardzo często spotyka się na rozmowach kwalifikacyjnych, ponieważ pozwala ono rekrutującym sprawdzić podstawową umiejętność testerską, do której między innymi należy zgłaszanie wszelkiego rodzaju błędów, ale również rekrutowany ma szansę, pokazać swoje umiejętności właśnie z tego zakresu obowiązków. Wiele osób może powiedzieć, że zgłaszanie błędów jest bardzo proste i nie wymaga większej wiedzy, jednak według mnie jest kilka bardzo ważnych elementów, które mają istotny wpływ na to, czy zgłoszony błąd będzie przejrzysty, właściwie zrozumiały przez inne osoby i zawierający najbardziej istotne informacje pozwalające go odtworzyć i przedstawić to, z czym jest problem i jakie powinno być jego poprawne zachowanie.

Zanim przejdę do pokazania Wam, jak zgłosić prawidłowo błąd, chciałabym, abyście mieli świadomość, dlaczego ten element waszej pracy jest ważny i dlaczego w ogóle warto się nad nim pochylić. Oto kilka przykładów, dlaczego poprawne zgłaszanie błędów jest ważne:

To tylko kilka sytuacji, które bardzo jasno pokazują, że tak naprawdę prawidłowe zgłoszenie błędu wpływa na pracę wielu osób i przez brak dokładności może spowodować wiele problemów. Ludzie poświęcają dodatkowy czas na zdobycie odpowiednich informacji o nim a firma traci pieniądze, ponieważ mogliby oni ten czas poświęcić na tworzeniu kolejnych rzeczy w backlog-u.

Pora na część praktyczną 🙂 W bardzo wielu firmach platformą, stosowaną między innymi do zgłaszania błędów jest Jira. W kilku wcześniejszych wpisach dokładnie przyjrzałam się tej platformie, więc jeśli chcecie się z nią zapoznać, wystarczy przejść do wcześniejszych wpisów.

Jakie elementy są niezbędne przy zgłaszaniu błędu:

  1. Tytuł -> powinien być krótki i treściwy, na samym początku powinien zawierać słowo klucz (jeśli jest to możliwe) co nie działa, czyli np. Button, Field, Window itp. a następnie rozwinąć związany z nim problem.

    Kilka przykładów tytułów zgłaszanych błędów:

    – Po naciśnięciu przycisku „Save” na ekranie pojawia się komunikat z błędem
    – Dodając produkt do koszyka, jego ilość zwiększa się dwukrotnie i nie można go usunąć
    – Po wprowadzeniu złego formatu danych w polach rejestracji, nie podkreślają się pola, które są wypełnione błędnymi danymi.
  2. Priorytet
    Pozwala określić, jak szybko dany problem musi zostać rozwiązany, czy jest to błąd blokujący, krytyczny, ważny czy może mało istotny z biznesowego punktu widzenia i nie wpływa on na resztę serwisu.
  3. Środowisko / Wersja / Zespół / Urządzenie
    Te pola pozwalają przekazać dokładne informacje, na jakim środowisku wystąpił dany błąd, czy było to środowisko testowe produkcyjne, czy jeszcze inne. Co więcej, ważną informacją jest to, w jakiej wersji naszej aplikacji dany błąd wystąpił i dodatkowo warto zaznaczyć pole w jakiej wersji, powinien on zostać naprawiony. Dzięki temu można lepiej zaplanować pracę i tym samym naprawiać błędy, które są w określonym momencie najbardziej istotne. Przypisanie błędu do danego zespołu, wymaga zdobycia wiedzy, przez kogo ten błąd mógł wystąpić, ta informacja wnosi wiele pozytywów. Zespół, który zajmował się daną funkcjonalnością, szybciej naprawi błąd niż zespół, który tego nie robił. Wpisanie urządzenia, na którym występuje dany błąd, jest dużym ułatwieniem dla programistów, którzy próbują ten błąd zdebugować. Nie zawsze jest tak, że błąd występuje na wszystkich urządzeniach a doprecyzowanie tej informacji, może skrócić czas jego naprawy i retestu tego błędu przez testera.
  4. Opis
    Krótki, konkretny, pomoże zdobyć szybką informację na temat tego, o co chodzi w tym błędzie i być może nakierować programistę, z czego dany błąd wynika.
  5. Kroki
    Dokładnie opisana instrukcja krok po kroku, co należy zrobić, aby dany błąd wystąpił, jest ogromnym ułatwieniem zarówno dla programistów, jak i testerów, którzy będą testować poprawiony błąd. Dobą praktyką jest wykorzystywanie kroków zawartych w często powtarzających się błędach do napisania do nich Test Cases i dzięki temu obszar narażony na występowanie w nim poważnych błędów może być sprawdzany cyklicznie np. w ramach regresji.
  6. Obecny rezultat
    Czyli wytłumaczenie co dokładnie jest dla nas błędem, czy pokazujący się nadmierny komunikat, czy też może brak walidacji na polu itp.
  7. Oczekiwany rezultat
    Krótki opis tego, jak po wykonaniu opisanych wyżej kroków aplikacja powinna się zachować i jeśli posiadamy dokumentację opisującą daną część -> pokazanie, jak według dokumentacji lub wytycznych powinno to działać.
  8. Załączniki
    Wszelkiego rodzaju zrzuty ekranu, filmiki, logi z konsoli, wszystko to, co może pomóc w określeniu miejsca, gdzie dany błąd występuję i co jest jego przyczyną.

Myślę, że te punkty są niezbędne do stworzenia poprawnego zgłoszenia błędu. Czasem warto skupić większą uwagę nad tym, co powinien zawierać nasz błąd, aby nikt nie musiał nas dopytywać o dodatkowe informacje i żeby był on jasny nie tylko dla inżynierów, ale również dla ludzi związanych z produktem, analityków itp.

Zostaw odpowiedź

Twój adres e-mail nie zostanie opublikowany.

Ten serwis wykorzystuje pliki cookies. Korzystanie z witryny oznacza zgodę na ich zapis lub odczyt wg ustawień przeglądarki. Więcej
Zgoda