Project Quality
  • Home
  • Blog
  • 18 Narzędzi dla testera
  • Testowanie oprogramowania dla początkujących
  • Kontakt
15 sierpnia, 2020 przez admin

Zgłaszanie błędów – jak zrobić to dobrze

Zgłaszanie błędów – jak zrobić to dobrze
15 sierpnia, 2020 przez admin

Zgłaszanie błędów – jak zrobić to dobrze

W dzisiejszym wpisie zajmiemy się kolejnym zagadnieniem ważnym z perspektywy zarówno testera, jak i developera. Poruszymy temat jakim jest zgłaszanie błędów. Jak robić to skutecznie, klarownie, przejrzyście oraz w taki sposób, żeby wiadomość była czytelna dla wszystkich zainteresowanych.

Trociny dla devów

Usłyszałem kiedyś to określenie i bardzo mi zapadło w pamięć — czym są trociny, które czasem testerzy przekazują developerom? Są to wszystkie informacje, które są niepełne, niekompletne, takie które zostawiają dużo niedopowiedzeń bez faktów.

Zapewne znasz sytuacje, gdy znalazłeś błąd, czas goni, szybka informacja w tickecie i wracasz do poszukiwania następnych błędów. Zastanówmy się tylko co dzieje się z taką informacją na kolejnych etapach.

a) tester znajduje błąd
b) opisuje błąd dość niedokładnie, nie podając wszystkich istotnych informacji
c) ticket z błędem otrzymuje ją developer
b) developer próbuje zreplikować błąd, jednak podczas próby trafia na niepełne informacje
e) przerywa proces
f) prosi o więcej informacji
g) tester po jakimś czasie stara dopisać więcej szczegółów i odpisać na pytania developera (o ile pamięta więcej detali i znów nie musi poświęcić czasu na odtwarzanie tego błędu)

Zastanówmy się teraz ile mamy w procesie zmarnowanego czasu z powodu sprawy tak trywialnej, jak nieprawidłowe opisanie błędu.

Gdybyśmy chcieli zrobić to idealnie, proces wyglądałby tak.

a) tester znajduje błąd
b) dokonuje opisu, podaje wszystkie niezbędne informacje
c) developer odczytuje wiadomość i implementuje poprawkę
d) tester robi retesty i akceptuje

Zobaczmy, o ile skrócił się nasz proces z powodu tylko i wyłącznie opisania błędu w sposób czytelny, klarowny, który nie pozostawia przestrzeni na domysły i jest wypełniony informacjami.

Pomyślmy również o komforcie, jaki zyskuje developer i tester pracując nad naprawą takiego błędu.

Pozorny zysk

Czemu powstają więc niedokładnie zaraportowane błędy? Myślę, że jednym z głównych czynników jest pozorna oszczędność oraz presja. Oszukujemy siebie sami, że raportując szybciej i mniej dokładnie zyskujemy więcej czasu na eksploracje i poszukiwanie błędów. Prada jest jednak inna i takie praktyki nie są niczym innym jak marnowaniem cennego zasobu, jakim jest czas zespołu.

Jak zaraportować dobrze

To oczywiście zależy, zależy od typu aplikacji, specyfiki testowanego oprogramowania czy projektu. Poniższy szablon jest ogólnym przedstawieniem raportu, może być on dobrym punktem wyjścia do pracy nad Waszymi szablonami do raportowania błędów.

  • Tytuł — klarowny i czytelny stanowi podstawę dobrze zaraportowanego błędu.
  • Środowisko — jest to istotny punkt, gdyż niektóre błędy mogą być spowodowane samym środowiskiem testowym, a nie kodem — błędy wynikające z konfiguracji / środowiska.
  • Priorytet — poinformuj również developera, jak pilny jest to błąd. Skala priorytetu zależy od organizacji firmy.
  • Label —  (zależy od projektu i procesu).
  • Warunki wstępne — czasem zreplikowanie błędu nie jest łatwe ani oczywiste. Warto podać developerowi informacje o warunkach wstępnych, jakie należy spełnić, aby odtworzyć błąd.
  • Opis błędu — klarowny i czytelny, czym więcej informacji zawrzemy w tym punkcie, tym łatwiejsze powinno być debugowanie przez developera błędu.
  • Kroki do reprodukcji błędu — również w tym punkcie opiszmy klarownie i czytelnie jak odtworzyć nasz błąd.
  • Oczekiwany rezultat — co powinno się dziać z naszą aplikacją.
  • Wersja aplikacji / branch
  • Urządzenie / przeglądarka / wersja
  • Załączniki — wszelkie zdjęcia, video czy logi, które posiadamy, dodajemy do tej sekcji.


Produktywny tester

Warto tutaj zauważyć, że możemy dodatkowo przyśpieszyć nasze raportowanie błędów i spowodować, że będzie efektywniejsze. Kluczem do tego jest przygotowanie sobie odpowiednich materiałów.

Nie wyobrażam sobie przepisywać szablonu do raportowania błędu za każdym razem, kiedy chce zaraportować o nieprawidłowościach. Tutaj dobrze przygotować sobie wcześniej zdefiniowane szablony (przykładowo GitLab ma możliwość dodawania takich szablonów).

Można też używać dodatkowego oprogramowania, które przy odpowiednim skrócie klawiszowym wygeneruje za nas szablon do zaraportowania.

Zgłaszanie błędów – raport idealny

Pamiętaj, że pisanie czytelnych raportów to kwestia wprawy, chęci oraz współpracy z developerami. Możesz porozmawiać z nimi, czego ich zdaniem brakuje w zgłaszanych błędach przez Ciebie bądź Twój zespół. Feedback ze strony programistów może pomóc Ci nakierować raporty w lepszym bardziej produktywnym kierunku.

Zadanie na koniec wpisu

Porozmawiaj z zespołem programistów, z którym pracujesz, co ich zdaniem możecie jako testerzy poprawić w raportowaniu błędów. Następnie najczęściej pojawiające się uwagi do Waszego raportowania zamień w zadania i wdróż do procesu poprawki opierające się na feedbacku.

Pozwoli Wam to oszczędzać czas, dostarczać lepszej jakości oprogramowania w krótszym czasie — same korzyści. : )

Koniecznie daj znać w komentarzu, jako poszło!

Każdy tester potrzebuje dobrych narzędzi 💻

Zapisz się do newslettera i poznaj 18 narzędzi które wspierają pracę testera!

Twój dokument już czeka na Ciebie 🎉

Wejdź na swoją skrzynkę e-mail i pobierz dokument „18 narzędzi dla testera aplikacji webowych”

.

Więcej artykułów z podstawami testowania znajdziesz pod linkiem: https://projectquality.it/testowanie-oprogramowania-podstawy/

Podziel się:

  • Twitter
  • Facebook
Poprzedni wpisTypy testów - testowanie oprogramowaniatypy testówNastępny wpis Odwrócona piramida testów - testowy rożek do lodówOdwrócona piramida testów - testowanie oprogramowania

Dodaj komentarz Anuluj pisanie odpowiedzi

Twój adres e-mail nie zostanie opublikowany. Wymagane pola są oznaczone *

Ostatnie wpisy

7 zasad testowania w 5 minut8 stycznia, 2022
Role w obszarze zapewniania jakości18 grudnia, 2021
Shift-left testing, czyli testuj jak najwcześniej25 listopada, 2021

Kategorie

  • Automatyzacja testów
  • Kariera testera
  • Narzędzia
  • podsumowanie
  • Produktywność
  • programowanie
  • Quality
  • Testowanie oprogramowania
  • Testowanie oprogramowania podstawy
  • ui
  • Uncategorized
  • warsztaty

Wpadnij na nasze social media

Jeśli jesteś pasjonatem jakości dołącz do naszej grupy!

Polityka prywatności

Rife Wordpress Theme ♥ Proudly built by Apollo13

About This Sidebar

You can quickly hide this sidebar by removing widgets from the Hidden Sidebar Settings.

Ostatnie wpisy

7 zasad testowania w 5 minut8 stycznia, 2022
Role w obszarze zapewniania jakości18 grudnia, 2021
Shift-left testing, czyli testuj jak najwcześniej25 listopada, 2021

Kategorie

  • Automatyzacja testów
  • Kariera testera
  • Narzędzia
  • podsumowanie
  • Produktywność
  • programowanie
  • Quality
  • Testowanie oprogramowania
  • Testowanie oprogramowania podstawy
  • ui
  • Uncategorized
  • warsztaty

Meta

  • Zaloguj się
  • Kanał wpisów
  • Kanał komentarzy
  • WordPress.org