Poradnik początkującego testera – #1 Jak dobrze zgłaszać błędy

Zapraszamy do cyklu artykułów z serii „Poradnik początkującego testera” , w którym to zostaną omówione podstawowe obowiązki oraz umiejętności szczególnie przydatne w trakcie rozpoczęcia swojej przygody związanej z testowaniem oprogramowania.

Jednym z podstawowych celów, wynikających z pracy testera, jest wyszukiwanie defektów w testowanym oprogramowaniu oraz ich skuteczne zgłaszanie osobom odpowiedzialnym za ewentualne ich rozwiązywanie i zarządzanie nimi w czasie. Umiejętność ta jest szlifowana w trakcie całej kariery testera, ale warto już od samego początku wyrobić sobie dobre nawyki, aby być skuteczną osobą w raportowaniu swoich zgłoszeń. Warto również zaznaczyć, że dobrą praktyka jest posiadanie w organizacji spisanego „procesu zarządzania incydentami” oraz sposobu ich klasyfikacji W ramach zarządzania incydentami wchodzą takie czynności jak:

  • analiza incydentów (może się okazać, że incydent jest defektem),
  • zgłaszanie incydentów/defektów w odpowiedni sposób – klasyfikacje, priorytety, przepływy,
  • czynności określające, w jaki sposób należy postępować z incydentami oraz defektami.
Sposób raportowania incydentów ma wpływ na ogólny obraz pracy testera oraz na ostateczny sukces projektu. Raportowanie zgłoszeń pozwala na:
  • dostarczenie programistom i innym osobom zaangażowanym w projekt informacji na temat problemów występujących w systemie – ich identyfikacja, i naprawę, jeśli okażą się defektami;
  • śledzenie w czasie rzeczywistym jakości testowanego systemu oraz postępu testów osobom odpowiedzialnym za projekt;
  • określenie miejsc, w których należy udoskonalić zarówno proces testowy, jak i deweloperski;
  • określenie słabych punktów systemu, w których występuje wiele defektów i które to powinny zostać poddane refaktoryzacji.

Sposób komunikacji o defektach

W sytuacji wykrycia defektów istnieją dwa sposoby komunikacji o ich wykryciu. Nasz wybór zależy od zasad oraz praktyk panujących w organizacji, rozmiaru projektów czy sposobie zarządzania projektem, ale zazwyczaj oba przeplatają się pomiędzy sobą.
  • Komunikacja ustna
Komunikacja ta polega na przekazywaniu informacji o wykrytym defekcie w sposób bezpośredni osobie zainteresowanej danym zgłoszeniem (np. zgłoszenie do programisty, analityka, projekt menadżera itp). Technika ta jest bardzo szybka, ale obarczona sporym ryzykiem błędów, gdyż przy nadmiarze przekazywanych informacji nasz odbiorca może zapomnieć o kluczowych rzeczach, które zostały mu przekazane lub przekazujący nie powie o istotnych elementach wykrytego defektu. Warto tutaj zastosować zasadę #1 Komunikacja ustna jest tylko uzupełnieniem komunikacji pisemnej mimo tego, że jest ona zdecydowanie szybsza od formy pisemnej.
Kolejnym ryzykiem stosowania jedynie komunikacji ustnej przy informowaniu o defektach jest to, że przy dużych projektach wykrywamy często dziesiątki błędów w trakcie dniówki i komunikacja taka spowoduje, że osoby zainteresowane będą odrywane od np. prac programistycznych, a wiadomo, że potrzeba skupienia przy takich pracach jest ważna, aby być efektywnym programistą.
  • Komunikacja pisemna
Komunikacja pisemna polega na robieniu notatek (pisanie e-maili, raportowanie zgłoszeń do systemów typu BTS, ang. Bug Tracking System, itp.) z wykrytych przez siebie defektów. Zazwyczaj błędy te są adresowane do osób odpowiedzialnych za dany obszar w sposób automatyczny (jak np. za pomocą narzędzia Mantis) lub bezpośrednio w formie np. e-maila do konkretnej osoby. Taka forma wymaga zawierania precyzyjnych informacji na temat wykrytych defektów, tak aby odbiorca na podstawie przekazanych informacji był w stanie zdiagnozować problem i go poprawić. Warto tutaj wspierać się komunikacją ustną, jeśli występują wątpliwości, zamiast „przerzucać się” zgłoszeniem pomiędzy programistą a testerem z komentarzem typu „nie działa” i odpowiedzią „u mnie działa” .

Co raportować

Podczas przeprowadzania testów będziemy mieć pewnie sytuacje, podczas których będziecie się zastanawiać, czy dane zgłoszenie jest błędem czy też nie i czy warto je raportować, czy jednak nie.
Nasza odpowiedź na takie pytanie jest krótka: zasada #2 Jeśli masz wątpliwości, czy coś zaraportować, czy nie, wspomóż się bardziej doświadczonym testerem, a jeśli go nie ma, zaraportuj zdarzenie.
W takiej sytuacji mamy pewność, że nie ominęliśmy istotnej rzeczy, która może mieć wpływ na finalne działanie aplikacji. Warto przyjąć zasadę, że powinniśmy informować o wszystkich znaczących, nieplanowanych zdarzeniach, które wystąpiły w trakcie testowania oprogramowania i które wymagają zbadania oraz często też rozwiązania, naprawy. Należy pamiętać, że nawet w sytuacji, gdy uda nam się wykryć błąd lecz niestety nie jesteśmy w stanie go powtórzyć, trzeba takie zdarzenie odnotować (np. w systemie zgłaszania błędów z informacją, że błędu nie da się powtórzyć). Podstawowe rzeczy, które powinniśmy uznać za konieczne do zaraportowania, to:
  • oprogramowanie nie działa zgodnie z oczekiwaniami (wiedza na podstawie wymagań czy też doświadczenia),
  • wynik rzeczywisty różni się od wyniku oczekiwanego,
  • wystąpiła utrata danych,
  • elementy graficzne dostępne w aplikacji źle się wyświetlają.
Oprócz wykrytych defektów systemy BTS posiadają w swoich funkcjonalnościach możliwość zgłaszania pytań, propozycji czy nowych funkcji. Zazwyczaj są to osobne typy zgłoszeń (poza defektami) lub tworzone np. na podstawie analizy danego zgłoszenia. Wiele jednak zależy od tego, w jaki sposób organizacja, w której pracujemy, działa.
Często początkujący tester ma problem przy ogromie pojęć, jakimi jest zasypywany na początku swojej pracy, takimi jak defekt, błąd, pluskwa itp., dlatego przedstawiamy slide z prezentacji z jednego z Naszych szkoleń, który mamy nadzieję rozjaśni wątpliwości.
PoradnikPoczątkującegoTesteraPojęcia

Stworzenie dobrego przepływu wykrytych defektów

Od stworzenia dobrego przepływu wykrytych defektów zależy, jak skutecznie będziemy raportować wykryte defekty. Musimy pamiętać, że narzędzie typu BTS jest podstawowym narzędziem w naszej pracy i powinno być stworzone w taki sposób, aby zarówno wspierało pracę testera, jak i innych osób zaangażowanych w proces testowania. Narzędzia takie będą opisane w jednym z poniższych podpunktów, a teraz chcielibyśmy przedstawić, jak wygląda poprawny przepływ raportowania defektów. Zasada #3 Nie ma jednego słusznego przepływu pracy, wiele zależy od rozmiaru zespołu, sposobu pracy i tego, jakie cele chcemy za pomocą tego osiągnąć. Tutaj przedstawiamy domyślny oraz zmodyfikowany przepływ, który wykorzystujemy w niektórych z Naszych projektów.
Przepływ zmodyfikowany na potrzeby klienta
PoradnikPoczątkującegoTesteraPrzepływ
Domyślny przepływ zgłoszeń błędów w narzędziu JIRA
Poradnik początkującego testera - default

Jakie informacje powinny znaleźć się w dobrze zaraportowanym zgłoszeniu

Raport incydentu powinien zawierać w sobie wiele informacji pozwalających w łatwy sposób na analizę i identyfikację potencjalnego defektu. Wszystko zależy jednak od tego, jak wygląda proces zarządzania incydentami w naszej organizacji i jakie elementy są wymagane do zamieszczenia w raporcie. Strukturę raportu incydentu można również znaleźć w dokumencie „Standard for Software Testing Documentation” (IEE STD 829-1998). Poniżej przedstawiamy, jakie informacje według Nas powinny znaleźć się w dobrze zaraportowanym incydencie:
  • data zgłoszenia incydentu
  • autor zgłoszenia
  • środowisko, na którym został wykryty potencjalny defekt
  • temat zgłoszenia
Temat zgłoszenia powinien być zwięzły, krótki i nawiązywać do wykrytego ewentualnego defektu. Należy tutaj unikać ogólników np. „System nie działa”, „Funkcjonalność nie działa”, „Rozjechany wygląd”, „Wydruk DCT – elementy”. Przykłady poprawnych nazw tematów, z których wynika, jaki element systemu nie działa mogą wyglądać następująco: „Pole wniosku w obszarze dokumentów nie podświetla się na żółto”, „Wydruk – Raport osób sporządzających dokumentację – ucięte nazwy statusów na wydruku”, „Kandydata o statusie odrzucony można zaprosić na rozmowę rekrutacyjną”, „Literówka na formatce dodawania nowego zastępstwa”.
  • opis incydentu / kroki do powtórzenia incydentu
Opis samego incydentu powinien w szczegółach wyjaśniać, jaki element systemu nie zadziałał. Tutaj powinny znaleźć się wszystkie informacje dotyczące samego zgłoszenia oraz kroki, jakie należy wykonać, aby doprowadzić do takiej samej sytuacji.
  • stopień wpływu na system
  • priorytet
W zależności od wykorzystywanego narzędzia mamy możliwość klasyfikacji błędu do odpowiedniego priorytetu. Należy sobie jasno zdefiniować, jakie mamy rodzaje priorytetów oraz co te priorytety oznaczają. Priorytety wykorzystywane w Naszych projektach to: „Bloker”, „Wysoki”, „Normalny”, „Niski”, „Trywialny”.
  • wersja testowanej aplikacji
  • kategoria incydentu
Możemy stworzyć własną listę kategorii, do której chcemy przypisywać wykrywane incydenty. Pozwoli nam to na weryfikację, w których obszarach systemu znajduje się najwięcej defektów. Przykładowa lista kategorii może wyglądać następująco (listę należy dostosować do potrzeb projektu): Interfejs użytkownika, Wydajność, Bezpieczeństwo, Baza Danych, Dokumentacja, Inne.
  • status incydentu – szczegóły omówione w poprzednim rozdziale

Dobre praktyki raportowania defektów

Podczas pracy na stanowisku testera nabieramy sporo doświadczenia, które później warto przekuć na garść dobrych praktyk i zastosować w organizacji. Jedną z takich „list” mogą być dobre praktyki przydatne przy zgłaszaniu incydentów. Warto taką listę rozbudować o własne pomysły, doświadczenia i regularnie poddawać ją analizie, aby dostosowywać do potrzeb firmy. Poniżej znajdziecie kilka dobrych praktyk, które znalazły się na Naszej liście.
  • W jednym raporcie zawieraj opis jednego defektu
Nie należy robić listy defektów w ramach jednego zgłoszenia. Taka sytuacja powoduje uciążliwe „panowanie” nad aktualnym stanem rozwiązanych punktów zgłoszenia. W sytuacji, gdy mamy wiele zgłoszeń dotyczących podobnej sytuacji można zastosować kontenery podzgłoszenia.
  • Raportuj błędy zaraz po wykryciu
Z doświadczenia wiemy, że lepiej raportować zgłoszenia natychmiast po ich wykryciu. Nie odkładajmy tego na koniec dnia, bo później mamy np. 20 defektów do zaraportowania, a programiści mogliby już stopniowo część z nich rozwiązywać.
  • Pilnuj własnych zgłoszeń
Warto tutaj skorzystać z komunikacji ustnej. Jeśli widzimy, że jakieś zgłoszenie długo jest przypisane do któregoś z programistów lub czeka w kolejce, a zbliża się wydanie wersji, warto zainteresować się swoimi zgłoszeniami i dopytać o aktualny stan rzeczy.
  • Obiektywnie zgłaszaj błąd – nie uderzaj personalnie w osobę tworzącą system
Sytuacja, w której zgłaszamy błąd, nie powinna być okazją do pokazania np. wyższości nad programistami. Pamiętajmy – gramy do jednej bramki, nie przeciwko sobie. Im lepsza współpraca, typ lepszy późniejszy efekt.
  • Dokładnie przedstawiaj procedurę odtworzenia defektu
Zawsze powinna zostać dokładnie opisana procedura dojścia do tego, kiedy „ujawnił” nam się wykryty defekt. Kroki takie powinny być przedstawione w sposób jednoznaczny i najlepiej wsparte screenshotami. Pamiętaj również, że wykorzystane dane testowe mają wpływ na to, czy błąd występuje czy nie, więc nie zapomnij zamieścić ich w procedurze odtworzenia defektu.
  • Przed wysłaniem zgłoszenia przeczytaj jego treść
  • Sprawdzaj listę zgłoszonych defektów celem uniknięcia duplikatów
  • Przed zamknięciem zgłoszenia przeprowadź retest
  • Dodawaj do swoich zgłoszeń dobrze opisane zrzuty ekranu
  • Stosuj szablon rejestracji incydentów
Celem ujednolicenia zgłoszeń w ramach całego Działu Testów warto przygotować sobie szablon, w jaki sposób będziemy tworzyć zgłoszenia. W Naszym wypadku wygląda to tak, że mamy w systemie JIRA jedno zgłoszenie „szablon”, które zawiera informacje o tym, w jaki sposób oczekujemy, aby zgłoszenia były wprowadzane. Poniżej przykład z jednego z Naszych projektów:

Szablon rejestracji incydentów

Środowisko testów: (http://tu.wklejamy.adres/w_całości_z_okienka_adresu.url)

Login i hasło testera: (użytkownik, na którym testowano)

Priorytet: (stopień znaczenia błędu)

Powtarzalność: (jak często można uzyskać opisany rezultat)

Przeglądarka: (przeglądarka z numerem wersji – jeśli dotyczy)

Lokalizacja występowania problemu: ( tu > wpisujemy > ścieżkę >)

Kroki do powtórzenia:

(1. Tutaj opisujemy,
2. wykonane kroki,
3. które wywołały błąd.)

Rezultat testów: (otrzymany wynik)

Stwórz własną checklistę – jak poprawnie raportować zgłoszenia

Stwórz własną checklistę ze standardami obowiązującymi w twojej organizacji odnośnie tego, jak poprawnie zgłaszać wykryte defekty. Poniżej znajdziesz przykład takiej checklisty z firm, z którymi współpracujemy.

CheckList- Poprawne Raportowanie Zgłoszeń

Narzędzia wspierające raportowanie zgłoszeń

Dostępnych jest wiele narzędzi wspierających zarządzanie defektami. Stworzyliśmy listę wraz z krótkim opisem najpopularniejszych narzędzi służących do raportowania zgłoszeń tzw. Bug Tracking Software.
Narzędzia testera

BTS - Bug Tracking Software

Lista popularnych narzędzi wspierających prace testera oprogramowania

Narzędzia testera