Cykl życia defektów we Flutterze

Testowaniem opracowywanych, utrzymywanych i rozwijanych aplikacji webowych zajmują się nie tylko programiści, którzy odpowiedzialni są za kod źródłowy, ale także testerzy. Przy pomocy zautomatyzowanych i manualnych testów da się zweryfikować pod kątem obecności błędów każdy rodzaj oprogramowania. Dzięki wsparciu profesjonalistów można uniknąć nieprzyjemnej sytuacji, w której rozeźleni użytkownicy sami zgłaszają wykryte wady i defekty. Aby ustrzec się od lawiny biznesowych problemów, zidentyfikowane błędy trzeba z reguły jak najszybciej usunąć i naprawić. Jako że każdy bez trudu domyśli się, jak zaczyna i kończy się cykl życia defektu, w poniższym artykule skupimy się przede wszystkim na tym, co dzieje się pomiędzy identyfikacją, a eliminacją wady oprogramowania.

Co to jest bug?

Pomimo tego, iż większość programistów używa terminów takich jak błąd czy defekt zamiennie, warto zaznaczyć, iż z perspektywy testera oprogramowania błąd (ang. bug) odnosi się przede wszystkim do pomyłki w kodzie. Defekt, zwany także wadą, rozpatrywany jest w kategorii wyniku błędnego kodu, który ze strony użytkownika bądź testera skutkuje awarią (tzn. złym działaniem aplikacji lub częściowym brakiem funkcjonalności). Mając na uwadze, iż wiele osób w branży IT w charakterze synonimów używa również terminów takich jak incydent, anomalia, problem czy issue, w poniższym artykule nie będziemy się skupiać na różnicach semantycznych.

Z jakich etapów składa się cykl życia wady oprogramowania?

W zależności od skali projektu i wypracowanego w danej firmie workflow cykl życia błędu oprogramowania może składać się z nawet kilkunastu etapów. Za zarządzanie cyklem życia defektów odpowiedzialne są z reguły osoby na stanowiskach takich jak Project Manager czy Lead Tester. Zanim przejdziemy do omówienia wszystkich statusów, skupimy się wpierw na poszczególnych etapach, z jakich składać się może cykl życia błędów we Flutterze i niemalże każdym innym frameworku.

1. Nowy błąd (New)

Wszystkie wykryte i zgłoszone błędy trafiają w pierwszej kolejności „na biurko” Project Managera, który następnie wprowadza je do systemu (np. Jira, Asana, Trello itp.). Niewpływające zbytnio na funkcjonalność aplikacji błędy mogą w natłoku zadań otrzymać status odroczonych (Deferred), ale z reguły dzieje się tak tylko, jeśli zostaną one automatycznie załatane przy zbliżającej się i zaplanowanej aktualizacji oprogramowania.

2. Przypisany (Assigned)

Zdecydowaną większość zgłaszanych błędów sprawdzają najpierw Ci programiści, którym Project Manager przypisał konkretne zadanie.

3. Otwarty (Open)

Na tym etapie przypisani odgórnie developerzy starają się zidentyfikować błąd w kodzie źródłowych aplikacji. W przypadku rozbudowanego i zaawansowanego oprogramowania może to być znacznie trudniejsze, niż mogłoby się w pierwszej chwili wydawać.

4. Naprawiony (Fixed)

Zanim cykl życia defektu zakończy się sukcesem developera, zaproponowane rozwiązanie trzeba jeszcze przetestować w praktyce. Zgłoszone i naprawione błędy trafiają do tego etapu w oczekiwaniu na weryfikację ze strony zawodowego testera.

5. Oczekiwanie na ponowny test (Pending retest)

Zaangażowani w cykl życia błędów testerzy muszą upewnić się, czy zaproponowane przez developera rozwiązanie problemu jest skuteczne. Etap ten powstał ze względu na to, iż jest to dosyć skomplikowane i czasochłonne zajęcie dla kogoś, kto z doskoku musi zapoznać się z mniej lub bardziej naglącym zgłoszeniem.

6. Ponowny test (Re-test)

Re-test to etap, który rozpoczyna się, gdy tester zabiera się do przygotowania szeregu testów manualnych i automatycznych. 

7. Zweryfikowany (Verified)

Na tym etapie publikowane są wyniki i wnioski z przeprowadzonych uprzednio testów. Testerzy mogą zaakceptować zweryfikowane pod kątem skuteczności rozwiązania programistów lub odrzucić je do ponownej naprawy.

8. Ponownie otwarty (Reopened)

Ponownie otwarte zgłoszenia wracają do programisty, który na podstawie uzyskanych w trakcie testów informacji musi poprawić swój kod. Zasugerowane na tym etapie rozwiązanie będzie musiało oczywiście ponownie przejść testy, nim zostanie zatwierdzone.

9. Zamknięty (Closed)

Zdawać by się mogło, iż cykl życia defektu w testowaniu oprogramowania kończy się na tym etapie, ale nie do końca tak jest. Historia dotycząca błędu i jego rozwiązania zostanie w systemie, ponieważ informacje te mogą przydać się podczas naprawy innych defektów w przyszłości. Jeśli zgłoszony pierwotnie problem zacznie ponownie występować (np. przy innej wersji aplikacji), można go w ten sposób znacznie szybciej zidentyfikować i wyeliminować.

Jeżeli chodzi o cykl życia błędu w testowaniu oprogramowania, wyróżnić można jeszcze kilka statusów, które programista, tester lub Project Manager może w pewnym momencie przypisać do zgłoszenia. Najczęściej stosuje się je w przypadku zduplikowanych (Duplicate), odroczonych (Deferred), odrzuconych (Rejected) i niebędących błędami (Not a bug) zgłoszeń.

Podsumowanie

Sprawne eliminowanie błędów i defektów oprogramowania jest niezwykle istotne z perspektywy utrzymania wysokiego poziomu zadowolenia użytkowników. Mając na uwadze jak wartościowy i przydatny potrafi być feedback z ich strony, łatwo zrozumieć można, dlaczego tak wiele przedsiębiorstw zaczyna korzystać z programów typu Bug Bounty.