Menu

Proces zarządzania defektami: jak skutecznie zarządzać defektem

  • Główny
  • Inny
  • Proces zarządzania defektami: jak skutecznie zarządzać defektem

defect management process

Wypróbuj Nasz Instrument Do Eliminowania Problemów

Wprowadzenie do procesu zarządzania defektami:

Bardziej skoncentrowany proces i testy pozwolą na mniej błędnego oprogramowania na rynku.

Zapobieganie defektom jest znacznie bardziej wydajny i skuteczny w zmniejszaniu liczby defektów, a także jest bardzo opłacalny w usuwaniu defektów wykrytych na wczesnym etapie procesu tworzenia oprogramowania. Większość organizacji prowadzi Wykrywanie defektów , Usunięcie wady i wtedy Udoskonalenie procesu który jest zbiorczo znany jako Proces zarządzania defektami .

Proces zarządzania defektami

wstaw węzeł w drzewie binarnym java

Czego się nauczysz:

Cele procesu zarządzania defektami (DMP)

Poniżej podano różne cele tego procesu:

  • Zapobiec wady
  • Wczesne wykrycie
  • Zminimalizuj wpływ
  • Rozwiązanie wady
  • Udoskonalenie procesu

Zanim zbadamy proces zarządzania defektami, najpierw zrozummy czym właściwie jest wada lub błąd?

Cykl życia zarządzania defektami

Gdy system daje inne wyniki niż rzeczywiste wymagania biznesowe, tj. Gdy występuje odchylenie od rzeczywistego lub pierwotnego wymagania biznesowego, możemy powiedzieć, że występuje defekt w systemie / oprogramowaniu.

Kiedy zespół testujący wykonuje przypadki testowe, natrafia na sytuację, w której rzeczywisty wynik testu różni się od oczekiwanego. Ta odmiana jest określana jako Wada .

Zasadniczo defekt oprogramowania to stan, który nie spełnia wymagań oprogramowania. Wada to błąd lub usterka, która powoduje nieoczekiwane lub nieprawidłowe zachowanie w systemie.

Aby odpowiednio obsłużyć projekty, musisz wiedzieć, jak radzić sobie z rozwojem i wydaniem, ale jednocześnie musisz wiedzieć, jak radzić sobie z defektami.

Wyobraź sobie, co się stanie, jeśli zespół testowy zgłosi usterki ustnie, a zespół programistów również ustnie zaktualizuje stan defektu? Proces będzie bardziej skomplikowany, ponieważ te wady obejmują wszystkie usterki, takie jak faktycznie naprawione i działające zgodnie z oczekiwaniami, naprawione, ale nadal nie działają, odrzucone, przełożone i proces trwa.

W powyższym przypadku, wraz ze wzrostem liczby usterek i komunikacją werbalną, wkrótce sytuacja będzie bardzo gorsza. Aby skutecznie kontrolować defekt i radzić sobie z nim, potrzebny jest odpowiedni cykl życia defektu.

Cykl życia defektu zapewnia, że ​​proces jest jednolity i ustandaryzowany. Wada osiąga różne stany w cyklu życia. Po wykryciu wady przechodzi ona przez różne etapy swojego życia i jest powszechnie znana jako Cykl życia wady .

Ogólnie rzecz biorąc, cykl życia defektu zaczyna się od etapu, w którym defekt zostanie znaleziony lub zgłoszony przez zespół testujący, a kończy się, gdy defekt zostanie zamknięty, poprzez zapewnienie, że nie da się go odtworzyć lub odrzucenie przez zespół programistów. Liczba stanów, przez które przechodzi defekt, różni się w zależności od projektu.

Dalsze czytanie:

Co to jest cykl życia defektów / błędów w testowaniu oprogramowania? Samouczek dotyczący cyklu życia wady

Uwaga: Poniższy cykl nieco różni się w zależności od organizacji.

Poniższy cykl życia wady obejmuje wszystkie możliwe stany:

Schemat blokowy cyklu życia defektu

  • Za każdym razem, gdy zespół testujący znajdzie usterkę w aplikacji, zgłasza tę usterkę do statusu „ NOWY ”.
  • Gdy nowa usterka jest sprawdzana przez kierownika ds. Kontroli jakości i jeśli wada jest ważna, wówczas stan usterki będzie następujący: „ otwarty ”I jest gotowy do przydzielenia do zespołu programistów.
  • Gdy kierownik ds. Kontroli jakości przypisuje usterkę do odpowiedniego dewelopera, stan usterki będzie oznaczony jako „ Przydzielony ”. Na tym etapie deweloper powinien rozpocząć analizę i naprawę usterki.
  • Gdy deweloper uważa, że ​​wada nie jest autentyczna lub ważna, wówczas deweloper odrzuca wadę. Status wady jest oznaczony jako „ Odrzucony ”I ponownie przydzielony zespołowi testującemu.
  • Jeśli rejestrowana wada wada zostanie powtórzona dwukrotnie lub oba zgłoszone wady mają podobne wyniki i kroki do odtworzenia, wówczas stan jednego z defektów zostanie zmieniony na „ Duplikować ”.
  • Jeśli w bieżącej wersji występują problemy lub przeszkody związane z naprawą określonej usterki, wada zostanie uwzględniona w przyszłych wersjach zamiast w bieżącej wersji, a następnie zostanie oznaczona jako „ Odroczony ”Lub„ Przełożone ”.
  • Jeśli programista nie jest w stanie odtworzyć wady za pomocą kroków opisanych przez zespół testowy w sekcji „Kroki prowadzące do odtworzenia”, może oznaczyć usterkę jako „ Niereprodukowalny' . Na tym etapie zespół testujący powinien przedstawić programistom szczegółowe kroki odtwarzania.
  • Jeśli deweloper nie ma jasności co do kroków reprodukcji dostarczonych przez QA w celu odtworzenia wady, może oznaczyć ją jako „ potrzebujesz więcej informacji ”. W takim przypadku zespół testujący musi dostarczyć wymagane szczegóły zespołowi programistycznemu.
  • Jeśli wada jest już znana i obecnie występuje w środowisku produkcyjnym, wówczas wada jest oznaczana jako „ Znana wada ”.
  • Gdy deweloper wprowadza niezbędne zmiany, wada jest oznaczana jako „ Naprawiony ”.
  • Deweloper przekazuje teraz usterkę zespołowi testującemu w celu weryfikacji, więc zmienia status na „ Gotowy do ponownego testu ”.
  • Jeśli wada nie ma dalszych problemów i jest prawidłowo zweryfikowana, wówczas tester oznacza usterkę jako „ Zamknięte ”.
  • Podczas ponownego testowania wady, jeśli tester stwierdził, że wada jest nadal odtwarzalna lub częściowo naprawiona, wówczas wada zostanie oznaczona jako „ Ponownie otwarte ”. Teraz deweloper musi ponownie przyjrzeć się tej wadzie.

Dobrze zaplanowany i kontrolowany cykl życia defektu podaje całkowitą liczbę defektów wykrytych w jednym lub wszystkich wersjach. Ten ustandaryzowany proces daje jasny obraz tego, jak kod został napisany, jak prawidłowo przeprowadzono testy, jak defekt lub oprogramowanie zostało wydane, itp. Zmniejszy to liczbę defektów w produkcji poprzez znalezienie defektów w testowaniu sama faza.

Proces zarządzania defektami

Proces zarządzania defektami

Proces zarządzania defektami został szczegółowo wyjaśniony poniżej.

# 1) Zapobieganie defektom:

Zapobieganie defektom to najlepsza metoda eliminacji usterek na wczesnym etapie testowania, zamiast znajdowania usterek na późniejszym etapie, a następnie ich naprawiania. Ta metoda jest również opłacalna, ponieważ koszt potrzebny do usunięcia defektów wykrytych na wczesnych etapach testowania jest bardzo niski.

Jednak nie jest możliwe usunięcie wszystkich usterek, ale przynajmniej można zminimalizować wpływ wady i koszty jej naprawy.

Główne kroki związane z zapobieganiem defektom są następujące:

  • Zidentyfikuj krytyczne ryzyko : Zidentyfikuj krytyczne ryzyka w systemie, które będą miały większy wpływ, jeśli wystąpią podczas testowania lub na późniejszym etapie.
  • Oszacuj oczekiwany wpływ : Dla każdego ryzyka krytycznego oblicz, jak duży byłby wpływ finansowy, gdyby ryzyko faktycznie wystąpiło.
  • Zminimalizuj oczekiwany wpływ : Po zidentyfikowaniu wszystkich krytycznych zagrożeń, podejmij najwyższe ryzyko, które w przypadku napotkania może być szkodliwe dla systemu i spróbuj zminimalizować lub wyeliminować ryzyko. W przypadku ryzyk, których nie można wyeliminować, zmniejsza prawdopodobieństwo ich wystąpienia i jego skutki finansowe.

# 2) Podstawa dostarczenia:

Kiedy element dostarczany (system, produkt lub dokument) osiąga wstępnie zdefiniowany kamień milowy, możesz powiedzieć, że element dostarczany jest punktem odniesienia. W tym procesie produkt lub element dostawy przenosi się z jednego etapu do drugiego, a gdy element dostawy przechodzi z jednego etapu do drugiego, istniejące wady systemu są również przenoszone do następnego etapu lub etapu.

Na przykład, rozważ scenariusz kodowania, testowania jednostkowego, a następnie testowania systemu. Jeśli programista wykonuje kodowanie i testy jednostkowe, wówczas zespół testujący przeprowadza testy systemowe. Tutaj kodowanie i testy jednostkowe to kamień milowy, a testy systemowe to kolejny kamień milowy.

Tak więc podczas testów jednostkowych, jeśli deweloper znajdzie jakieś problemy, nie jest to nazywane defektem, ponieważ problemy te są identyfikowane przed upływem terminu ważności. Po zakończeniu kodowania i testów jednostkowych programista przekazuje kod do testowania systemu, a następnie można powiedzieć, że kod jest „Bazowy” i gotowy na kolejny kamień milowy, w tym przypadku jest to „testowanie systemu”.

Teraz, jeśli problemy zostaną zidentyfikowane podczas testowania, jest to nazywane defektem, ponieważ jest identyfikowany po zakończeniu wcześniejszego etapu, tj. Kodowania i testowania jednostkowego.

Zasadniczo wyniki są ustalane na podstawie punktu odniesienia, gdy zmiany w produktach są finalizowane, a wszystkie możliwe wady są identyfikowane i naprawiane. Następnie ten sam element jest przekazywany następnej grupie, która będzie nad nim pracować.

# 3) Wykrywanie defektów:

Niemożliwe jest usunięcie wszystkich defektów z systemu i uczynienie systemu wolnym od defektów. Możesz jednak zidentyfikować usterki wcześnie, zanim staną się bardziej kosztowne dla projektu. Można powiedzieć, że wykryta wada oznacza, że ​​jest ona formalnie zgłaszana zespołowi programistów i po przeanalizowaniu tej usterki zespół opracowujący defekt również zaakceptował ją jako wadę.

Kroki związane z wykrywaniem defektów są następujące:

  • Znajdź defekt : Zidentyfikuj usterki, zanim staną się poważnym problemem dla systemu.
  • Zgłoś usterkę : Gdy tylko zespół testujący znajdzie usterkę, jego obowiązkiem jest uświadomienie zespołowi programistycznemu, że zidentyfikowano problem, który należy przeanalizować i naprawić.
  • Potwierdź defekt : Gdy zespół testujący przypisze usterkę zespołowi programistycznemu, jego obowiązkiem jest potwierdzenie usterki i dalsze jej naprawianie, jeśli jest to ważna usterka.

# 4) Rozwiązanie wady:

W powyższym procesie zespół testujący zidentyfikował usterkę i zgłosił ją zespołowi programistycznemu. Teraz zespół programistów musi przystąpić do rozwiązania wady.

Kroki związane z usunięciem usterki są następujące:

  • Ustal priorytety ryzyka : Zespół programistów analizuje usterkę i nadaje priorytet jej naprawieniu. Jeśli wada ma większy wpływ na system, wówczas naprawienie wady ma wysoki priorytet.
  • Napraw usterkę : Na podstawie priorytetu zespół programistów naprawia usterkę, defekty o wyższym priorytecie są usuwane jako pierwsze, a usterki o niższym priorytecie są naprawiane na końcu.
  • Zgłoś rezolucję : To zespół programistów jest odpowiedzialny za upewnienie się, że zespół testujący jest świadomy, kiedy defekty będą wymagały naprawy i w jaki sposób usterka została naprawiona, tj. Poprzez zmianę jednego z plików konfiguracyjnych lub wprowadzenie pewnych zmian w kodzie. Będzie to pomocne dla zespołu testującego w zrozumieniu przyczyny defektu.

# 5) Doskonalenie procesu:

Chociaż w procesie rozwiązywania defektów usterki są traktowane priorytetowo i naprawiane, z perspektywy procesu nie oznacza to, że defekty o niższym priorytecie nie są ważne i nie mają dużego wpływu na system. Z punktu widzenia doskonalenia procesu, wszystkie zidentyfikowane defekty są takie same jak defekt krytyczny.

Nawet te drobne usterki dają możliwość nauczenia się, jak usprawnić proces i zapobiegać występowaniu wszelkich usterek, które mogą mieć wpływ na awarię systemu w przyszłości. Identyfikacja usterki mającej mniejszy wpływ na system może nie być wielkim problemem, ale występowanie takiej wady w samym systemie to wielka sprawa.

Aby usprawnić proces, wszyscy uczestnicy projektu muszą spojrzeć wstecz i sprawdzić, skąd pochodzi usterka. Na tej podstawie można wprowadzać zmiany w procesie walidacji, dokumencie bazowym, procesie przeglądu, który może wychwycić defekty na wczesnym etapie procesu, które są tańsze.

Wniosek

Proces zarządzania defektami powinien być przestrzegany podczas całego procesu tworzenia oprogramowania, a nie tylko w przypadku określonych czynności testowych lub programistycznych.

Jeśli defekt wykryty w fazie testowania, można postawić pytanie, czy jeśli defekt zostanie wychwycony w tej fazie, to co z innymi defektami, które są żywe w systemie, które mogą spowodować awarię systemu, jeśli wystąpią i nie zostaną jeszcze wykryte.

Dlatego wszystkie procesy, takie jak proces przeglądu, testowanie statyczne, inspekcja itp., Muszą zostać wzmocnione, a wszyscy uczestnicy projektu powinni poważnie podchodzić do procesu i wnosić wkład w razie potrzeby. Kierownictwo wyższego szczebla w organizacji powinno również rozumieć i wspierać proces zarządzania defektami.

Podejścia do testowania, proces przeglądu itp. Powinny być wybierane w oparciu o cel projektu lub proces organizacyjny.

jak stworzyć firewall od podstaw

Mam nadzieję, że ten artykuł informacyjny na temat procesu zarządzania defektami będzie dla Ciebie bardzo pomocny.

rekomendowane lektury

^