To jest nowa seria na tym blogu – Podstawy Testowania. Postaram się odpowiedzieć na pytania, które mi często zadajecie i zebrać wszystkie informacje w jednym miejscu.
Zacznijmy od podstaw!
Co to jest bug?
defekt (zwany potocznie bugiem): Wada modułu lub systemu, która może spowodować, że moduł lub system nie wykona zakładanej czynności, np. niepoprawne wyrażenie lub definicja danych. Defekt, który wystąpi podczas uruchomienia programu, może spowodować awarię modułu lub systemu.
[Słownik wyrażeń związanych z testowaniem Wersja 2.0]
Możemy spierać się o definicje, ale mówiąc wprost – gdy oprogramowanie nie działa, nie zachowuje się lub nie wygląda zgodnie z oczekiwaniami zawartymi w specyfikacji – ma defekt.
Defekty mogą być zgłaszane podczas: kodowania, analizy statycznej, przeglądów, testów dynamicznych lub korzystania z oprogramowania.
Dodatkowo, mogą być raportowane w przypadku problemów z kodem lub działającym systemem, mogą też dotyczyć błędów w dokumentacji, w tym także w: wymaganiach, historiach użytkowników i kryteriach akceptacji, dokumentach programistycznych, dokumentach testowych, podręcznikach użytkownika lub instrukcjach instalacji.
Aby uzyskać skuteczny i wydajny proces zarządzania defektami, organizacje mogą zdefiniować standardy dotyczące atrybutów, klasyfikacji i przepływu defektów w procesie wytwarzania oprogramowania.
Po co zgłaszać defekty?
W każdym projekcie istnieje nieco inny sposób zgłaszania błędów. Zależy to również od tego, czy zespół siedzi razem w jednym pokoju, czy też pracuje zdalnie w projekcie rozproszonym. Istnieją narzędzia do zgłaszania błędów, ale jednym z priorytetów w procesie poprawy jakości oprogramowania jest wykrycie defektu, poinformowanie osoby, która może ją naprawić lub samodzielne naprawienie go i, w konsekwencji, usunięcie błędu.
Aby to osiągnąć, dobrze jest udokumentować defekt. Raportowanie i przechowywanie bugów w jakimś narzędziu ułatwiającym zarządzanie procesem testowania, takim jak: Jira, XRay, HP ALM (Quality Center), Bugzilla, Excel (sic!) umożliwi Wam również w przyszłości powrót do niektórych starych problemów, które po pewnym czasie mogą ponownie pojawić się w systemie.
W niektórych moich – bardziej zwinnych (agilnych 😀 ) – projektach staraliśmy się unikać niepotrzebnej dokumentacji dotyczącej samego testowania, ale zgłaszanie błędów uznaliśmy za konieczność. Z drugiej jednak strony, w przypadku większych projektów, z obszernymi umowami z klientem, naprawa większości usterek o poziomie ważności 1 lub 2 może być objęta umową, więc zespół developerski zobowiązany jest wszystkie defekty śledzić i zgłaszać.
Jak zgłosić buga?
Najprościej jest stosować się do zaleceń spisanych w sylabusie ISTQB Foundation Level i dopilnować, aby w narzędziu do zgłaszania bugów, dla każdego znalezionego defektu znalazły się poniższe elementy:
- unikalny identyfikator
- data zgłoszenia (data odkrycia błędu)
- autor
- określenie elementu konfiguracji oprogramowania lub systemu
- faza cyklu życia oprogramowania
- zatwierdzanie jako błąd; §krótki opis problemu
- priorytet wykonania
- wpływ zmiany wynikającej z defektu na inne obszary oprogramowania
- odnośniki: identyfikator przypadku testowego, który ujawnił problem.
W przypadku korzystania z narzędzi takich jak: Jira, HP ALM lub dowolnego innego – część z tych informacji (identyfikator, reporter, data itp.) macie już automatycznie wypełnione podczas raportowania, część z nich będziecie musieli dopisać.
Co więcej, dobrą praktyką jest podanie jak największej ilości dodatkowych informacji, aby uzyskać szybką odpowiedź od osoby odpowiedzialnej za priorytetyzację usterki podczas spotkania Bug Triage (takie spotkania odbywają się w dużych projektach) lub od programisty odpowiedzialnego za naprawę defektu. Warto też dołączyć zrzuty ekranu lub krótkie gify przedstawiające problem – w myśl zasady, że jedno zdjęcie jest warte tysiąca słów 🙂
Ponadto do opisu buga warto dołaczać takie elementy jak:
- tytuł i krótkie podsumowanie zgłaszanej usterki – zgodnie z konwencją nazewnictwa zastosowaną w Twoim projekcie
- logi, zrzuty bazy danych
- oczekiwane i rzeczywiste wyniki (co jest naprawdę ważne dla odtworzenia usterki)
- zakres lub stopień wpływu (wagi) usterki na interesariuszy
- wnioski, zalecenia i zgody (approvale)
- historia zmian, na przykład sekwencja działań podjętych przez członków zespołu projektowego w odniesieniu do usterki w celu wyodrębnienia, naprawy i potwierdzenia jej usunięcia.
Przykład opisu defektu można znaleźć w standardzie ISO – (ISO/IEC/IEEE 29119–3).
Cykl życia defektu
Na koniec kilka dodatkowych informacji, jak obchodzić się z bugiem w procesie wytwarzanie oprogramowania i go nie zgubić.
Jak zwykle – to zależy od tego jak raportujecie defekty, jakich narzędzi używacie etc. Poniżej dość złożony przykład z Bugzilli:
W każdym projekcie można ten proces dostosować do potrzeb zespołu i wewnętrznych ustaleń.
Wtem!
Bądź miły dla członków swojego zespołu i, jako tester, staraj się być raczej profesjonalny niż przesadnie zadowolony z siebie, gdy znajdziesz buga.
A na koniec, cytat z mojej ulubionej testerki oprogramowania – Maaret:
We don’t break the code. We brake illusions about the code.
Maaret Pyhäjärvi
Kinga Witko 