Redakcja
Proces zarządzania defektami w danej organizacji i narzędzie używane do zarządzania defektami mają ogromne znaczenie nie tylko dla pracy zespołu testowego, ale również dla wszystkich zespołów biorących udział w procesie rozwoju oprogramowania. Informacja zebrana w trakcie skutecznego procesu zarządzania defektami pozwala na ustalenie statusu realizacji projektu w całym cyklu życia wytwarzania oprogramowania, a poprzez gromadzenie i analizowanie danych na przestrzeni czasu, może pomóc zlokalizować obszary potencjalnego doskonalenia testów i procesu wytwórczego.
Defekty są wprowadzane do oprogramowania wtedy, gdy ktoś popełni błąd podczas tworzenia jakiegoś produktu pracy. Takim produktem może być specyfikacja wymagań, historyjka użytkownika, dokumentacja techniczna, przypadek testowy, kod programu czy dowolny inny produkt powstały w procesie rozwoju oprogramowania lub na etapie procesu utrzymania. Defekty mogą być wprowadzane w dowolnym etapie cyklu wytwarzania oprogramowania i w każdym produkcie powstałym w procesie wytwórczym, dlatego każda faza cyklu wytwarzania oprogramowania powinna obejmować działania mające na celu wykrycie i usunięcie ewentualnych defektów. Na przykład, statyczne techniki testowania (tj. przeglądy i analiza statyczna) mogą być używane do weryfikacji specyfikacji projektu, specyfikacji wymagań i kodu przed przekazaniem tych produktów do kolejnych czynności. Podczas testów dynamicznych, takich jak testy modułowe, testy integracji i testy systemowe, obecność defektu staje się widoczna w momencie, gdy powoduje on awarię, która skutkuje rozbieżnością pomiędzy rzeczywistymi a oczekiwanymi wynikami testu (tj. anomalia). Jeśli tester dostrzega anomalię, pojawia się sytuacja, która wymaga dalszego zbadania. Badanie to rozpoczyna się od wypełnienia raportu o defekcie.
Za zarządzanie defektami zgłoszonymi w projekcie może odpowiadać międzyfunkcjonalny zespół. Oprócz Kierownika Testów, uczestnikami komitetu zarządzania usterkami (lub konsylium nad defektami) są zwykle przedstawiciele zespołu wytwarzającego oprogramowanie, zarządzania projektem, zarządzania produktem oraz inni interesariusze zainteresowani rozwijanym oprogramowaniem.
Gdy anomalie są wykrywane i zgłaszane w narzędziu do zarządzania defektami, komitet zarządzania usterkami powinien odbywać spotkania mające na celu określenie, czy każdy raport o defekcie zawiera poprawny opis zidentyfikowanego defektu i czy powinien być on naprawiony, czy też odroczony. Decyzja ta wymaga, by komitet zarządzania usterkami rozważył korzyści, ryzyka i koszty związane z naprawą lub brakiem naprawy danego defektu. Jeśli defekt ma zostać naprawiony, zespół powinien ustalić priorytet naprawy defektu względem innych prac projektowych. Kierownik Testów oraz zespół testerski mogą zostać poproszeni o konsultacje dotyczące względnej ważności defektu i należy wówczas dostarczyć dostępne i obiektywne informacje z nim związane.
Cykl życia i stany defektu
Większość organizacji testerskich używa narzędzi do zarządzania raportami o defektach z zaimplementowanym cyklem życia defektu. Raport o defekcie zazwyczaj jest przesuwany poprzez przepływ zadań i w trakcie swojego cyklu życia przechodzi przez sekwencję stanów. W przypadku większości z tych stanów, właścicielem raportu jest jeden uczestnik cyklu życia defektu i to on jest odpowiedzialny za realizację zadania, które po ukończeniu będzie powodować, że raport o defekcie zostanie przeniesiony do następnego stanu (i przypisany do kolejnej odpowiedzialnej osoby). W stanach końcowych takich jak ten, w którym raport o defekcie jest zamykany (co zwykle oznacza, że defekt został naprawiony i zweryfikowany przez testy potwierdzające), anulowany (co zwykle oznacza, że raport o defekcie jest nieprawidłowy), nieodtwarzalny (co zwykle oznacza, że anomalii nie da się już zaobserwować) lub odroczony (co zwykle oznacza, że anomalia dotyczy prawdziwego defektu, ale defekt ten nie będzie naprawiony w trakcie realizacji projektu), raport nie ma właściciela, ponieważ nie są konieczne żadne dalsze działania.
W przypadku defektów wykrytych przez testerów podczas testów, istnieją trzy stany, które wymagają działania zespołu testowego:
- Stan początkowy
W tym stanie jeden lub więcej testerów zbiera informacje niezbędne dla osoby odpowiedzialnej za rozwiązywanie defektu, by odtworzyć anomalię (patrz punkt 4.3. dla uzyskania dodatkowych informacji na temat danych, które mają być uwzględnione w raporcie o defekcie). Stan ten może być również określony jako "otwarty" lub "nowy". - Stan zwrócony
W tym stanie odbiorca raportu odrzucił raport lub prosi testera o dostarczenia dodatkowych informacji. Stan ten może wskazywać na braki w procesie zbierania wstępnych informacji lub braki w samym testowaniu, w związku z czym Kierownicy Testów powinni monitorować nadmierne wskaźniki tego stanu. Tester musi dostarczyć dodatkowe informacje lub potwierdzić, że raport rzeczywiście powinien zostać odrzucony. Stan ten może być również określony jako "odrzucony" lub "do wyjaśnienia". - Stan testu potwierdzającego
W tym stanie tester będzie uruchamiać testy potwierdzające (często wykonując kroki do odtworzenia błędu z samego raportu o defekcie), aby stwierdzić, czy poprawka rzeczywiście rozwiązała problem. Jeśli test potwierdzający wskazuje, że defekt został naprawiony, tester powinien zamknąć raport. Jeśli test potwierdzający wskazuje, że defekt nie został naprawiony, tester powinien ponownie otworzyć raport, powodując przypisanie go do poprzedniego właściciela, który może następnie ukończyć prace niezbędne do naprawy defektu. Stan ten może być również określony jako "rozwiązany" lub "weryfikacja".
Przykłady cyklu życia defektów
Poniżej przedstawiamy przykłady przepływów stanów defektów. Nazwy poszczególnych stanów mogą się różnić od tych przytoczonych powyżej.
Cykl życia defektów promowany przez Bogdana Berezę
Choć cykl na pierwszy rzut oka wygląda poprawnie, to swego czasu wzbudzał wiele kontrowersji wynikających z niezrozumiałych stanów oraz wymuszeń. Bez pełnego opisu ciężko jednoznacznie ocenić jego poprawność.
Cykl życia ze standardu IEEE 1044
Cykl pochodzi z naprawdę wiekowego standardu, ale jego wysokopoziomowa struktura przetrwała test czasu.
Cykl życia z Bugzilli
Bugzilla to swego czasu bardzo popularne narzędzie do zarządzania defektami. Cykl życia z tego projektu jest jednak ostatnio bardziej znany niż samo narzędzie.
Obrazek przetłumaczony na potrzeby książki "Java. Praktyczne narzędzia" autorstwa John Ferguson Smart.
Cykl życia błędu (w systemie Bugzilla) rozpoczyna się w chwili jego zdefiniowania przez testera lub użytkownika. Nowo tworzone błędy mogą się znajdować w stanie NEW, ASSIGNED lub UNCONFIRMED. W największym skrócie — błąd w stanie UNCONFIRMED wymaga potwierdzenia przez pracownika działu zapewniania jakości, zanim będzie mógł przejść w stan NEW i zostać przypisany programiście odpowiedzialnemu za jego usunięcie.
