Bug… dla niektórych synonim koszmaru i dodatkowych godzin spędzonych przed ekranem monitora. Dla innych powód do dumy i potwierdzenie skuteczności umiejętności testerskich.
Przyjrzymy się, czym są bugi, zwane też defektami, robakami, pluskwami czy błędami. Jak wygląda proces radzenia sobie z nimi? Jak się je opisuje? Zapraszamy do czytania!
Czym jest bug
Według Słownika wyrażeń związanych z testowaniem (wersja 2.3), przygotowującego do certyfikatu ISTQB, bug, czyli defekt, to:
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.
Na portalu programista-IT możemy znaleźć taką definicję:
Bug (z angielskiego: pluskwa) – niezamierzony błąd w programie albo grze. Niektórzy błędnie określają tym terminem wirusy, robaki albo trojany. Należy jednak pamiętać, iż „bug” jest niezamierzony, w trakcie, gdy złośliwy kod jest celowym wykorzystaniem komputera użytkownika do szkodliwych celów.
Określeń opisujących czym jest bug, oczywiście istnieje znacznie więcej i każdy może znaleźć definicję, która odpowiada mu najbardziej i najlepiej wyjaśnia zjawisko.
Jeśli chcielibyście się dowiedzieć, kto wprowadził do słownika informatycznego pojęcie buga,
to zapraszamy do lektury naszego posta Testerka też była kobietą. Część I.
Jednak sama wiedza o tym, czym w istocie jest defekt, nie wystarczy nam do skutecznego zmierzenia się z problemem. Jeśli chcemy go wykryć i usunąć na wczesnym etapie rozwoju, śledzenie bugów i cyklu tworzenia oprogramowania, powinny rozpoczynać się jednocześnie.
Cykl życia buga
Pamiętajmy, iż cykl życia buga może się różnić od tego podanego przez nas. Wszystko zależy od tego, co testujemy i jakiego programu do wykrywania defektów używamy.
- Wykrycie nowego defektu
- Sprawdzenie błędu przez program (np. Development) lub menedżera testów
- Ustawienie statusu defektu. Menedżer testów może ustawić status błędu jako Otwarty, może przypisać buga developerowi lub ustawić status Odroczony i tym samym odłożyć defekt do następnego wydania.
- Gdy bug zostanie przypisany do programisty, może on rozpocząć proces pracy nad nim. Określa status zaraportowanego błędu. Może oznaczyć go, jako taki, którego nie naprawi, nie może odtworzyć, o którym potrzebuje więcej informacji lub że defekt został naprawiony.
- Jeśli developer będzie potrzebował więcej danych o defekcie lub określi buga, jako Naprawiony, to defekt trafia do QA, który podejmuje kolejną akcję.
- Jeśli błąd został naprawiony, wówczas tester weryfikuje defekt i w zależności od korekty, ustawić status buga na Zweryfikowany i Zamknięty, lub ponownie otwiera cykl naprawczy.
Opisywanie statusu defektu
- New (Nowy) – gdy tester zgłosi nowy defekt
- Deferred (Odroczony) – jeśli błąd nie jest związany z bieżącą kompilacją, nie można go naprawić w tej wersji lub nie jest wymagane, by naprawić go w danym momencie, menedżer projektu (lub inna osoba odpowiedzialna) może ustawić jego status jako Odroczony
- Assigned (Przypisany) – przypisanie defektu do konkretnego developera przez menedżera projektu lub inną osobę odpowiedzialną za projekt
- Resolved/Fixed (Rozwiązany/Naprawiony) – gdy developer dokonał niezbędnych napraw w kodzie i zweryfikował te zmiany, może określić błąd jako Naprawiony. Defekt zostanie wówczas przesłany do zespołu testującego i tam ponownie sprawdzony
- Could not reproduce (Nie można odtworzyć) – jeśli programista nie jest w stanie odtworzyć buga, według kroków określonych przez testera w raporcie, wówczas może go oznaczyć jako CNR. Defekt trafia do QA, który sprawdza, czy buga da się odtworzyć i może przypisać go do developera wraz ze szczegółowym raportem odtwarzania
- Need more information (Potrzeba więcej informacji) – jeśli programista nie ma pewności, jakie kroki odtwarzania defektu zostały zawarte w raporcie testera, wówczas może oznaczyć go jako wymagającego więcej informacji. Wtedy QA tworzy bardziej szczegółowy raport o błędzie i z powrotem przydziela buga developerowi
- Reopen (Ponowne otwarcie) – jeśli tester nie jest zadowolony z naprawy defektu, jeśli bug nadal jest odtwarzalny, wtedy może oznaczyć go jako wymagającego ponownego otworzenia, by programista mógł wykonać odpowiednie czynności
- Closed (Zamknięty) – jeśli defekt został zweryfikowany przez testera i jeśli naprawa kodu przyniosła spodziewane rezultaty i problem został rozwiązany, to tester może oznaczyć go jako Zamknięty
- Rejected/Invalid (Odrzucony/Nieważny) – zdarza się, że system działa według określonych specyfikacji, mimo zaraportowanego błędu. W takim przypadku może on wynikać z nieprawidłowej interpretacji i zostać oznaczony, jako Odrzucony lub Nieważny
Możemy natrafić też na takie określenia defektów:
- Wontfixed (Nie zostanie naprawiony) – opisany defekt jest błędem w kodzie, ale nie zostanie naprawiony
- Duplicate (Powtórzenie) – zaraportowany bug jest duplikatem już istniejącego
- Worksforme – wszelkie próby odtworzenia defektu nie powiodły się. Przyczyny pojawienia się buga nie są znane. Gdy pojawi się więcej informacji na ten temat, defekt zostanie ponownie otworzony
- Moved (Przeniesiony) – zaraportowany defekt jest charakterystyczny dla innego produktu. Przeniesiono go do bazy danych błędów związanych z tym produktem
Zanim zaraportujemy jakikolwiek błąd, sprawdźmy dokładnie, czy ktoś przed nami nie zgłaszał podobnego defektu. Upewnijmy się również, że nasz raport zawiera możliwie jak najdokładniejszą lokalizację defektu; ułatwimy tym samym pracę innym.
Bądźmy wytrwali w wyszukiwaniu i opisywaniu błędów. Od naszego zaangażowania zależy jakość programu końcowego. A więc do dzieła testerze, do dzieła testerko!
