Co to jest Defect Triage?
Defect Triage jest procesem, w którym testerzy odkrywają błąd i przypisują mu stopień ryzyka, ponownego wystąpienia i ciężkości. Stopień ten zasadniczo nadaje priorytet błędowi, który ma być leczony w pierwszej kolejności.
Triaż jest jednak terminem medycznym, który w zasadzie oznacza próbę lub wypróbowanie. Kiedy przyjeżdżasz na oddział ratunkowy, pierwsza ocena medyczna jest wykonywana przez pielęgniarkę.
W oddziale ratunkowym, jest to zazwyczaj wykonywane w pokoju triage. W tym czasie bardzo ważne jest, aby pacjent opisał swój problem pielęgniarce, aby mogła ona dokładnie ocenić, co należy zrobić dalej.
Based on the severity or urgency of another person’s medical condition, they may be taken back quicker than you. To jest dokładnie to, co dzieje się, gdy tester oprogramowania prowadzi triage wad lub błędów.
Przypisują stopień ciężkości do każdego błędu i błąd, który wydaje się bardziej poważny lub błąd, który ma większy potencjał, aby zagrozić integralności systemu jest brany pod uwagę w pierwszej kolejności.
Spotkania dotyczące usuwania błędów
Spotkania dotyczące usuwania błędów są ułatwiane przez szefa działu QA i są koordynowane z analitykami biznesowymi, szefem działu IT, kierownikiem projektu, a nawet kierownikiem produktu.
Podczas fazy rozwoju lub testowania, testerzy napotykają wiele problemów lub błędów, które przeszkadzają wszystkim. Aby zająć się tymi błędami, organizowane jest spotkanie dotyczące usuwania usterek.
Głównym celem tego spotkania jest kategoryzacja, priorytetyzacja i śledzenie problemów.
Spotkania dotyczące usuwania usterek odbywają się co jakiś czas, czasami nawet 3 – 4 razy w tygodniu, w zależności od wielkości projektu, sytuacji projektowej, harmonogramu i liczby usterek. Wiele czynników odgrywa rolę w określeniu liczby spotkań triage potrzebnych do wyeliminowania błędu raz na zawsze.
Wszystkie te spotkania obejmują dyskusje na temat złożoności defektu, ryzyka z nim związanego, przypisania, ponownego przypisania i odrzucenia. Wszystkie te aktualizacje są rejestrowane w systemie śledzenia błędów.
Dla uzyskania najlepszych wyników, QA lead powinien wysyłać raport błędów z istniejącymi lub nowymi defektami na każde spotkanie.
Każdy defekt powinien być przeanalizowany, aby sprawdzić, czy został przypisany prawidłowy priorytet i waga. Głównym motywem tego spotkania jest naprawienie wszystkich problemów w sposób terminowy, stały i dokładny.
Podczas spotkania, każdy błąd jest kategoryzowany do jednej z trzech kategorii:
- BEZZWŁOCZNE DZIAŁANIE, ABY NAPRAWIĆ BŁĄD: Usterka należy do tej kategorii z dwóch powodów. Pierwszym powodem jest to, że istnieją wystarczające zasoby w zespole, aby naprawić błąd, a drugim powodem jest to, że błąd może spowodować problemy w przyszłości, dlatego ważne jest, aby naprawić błąd natychmiast.
- DZIAŁANIE NA BŁĄD W PUNKCIE PÓŹNIEJSZYM W CZASIE: Błąd należy do tej kategorii, gdy zespół wie, że nie jest to coś poważnego i może być wyleczony po jakimś czasie.
- BŁĄD BEZ DZIAŁANIA: To w zasadzie oznacza, że błąd jest bardzo mały i nie ma żadnego wpływu na cały system. Dlatego, nie ma potrzeby podejmowania działań na takim błędzie.
Kroki usuwania defektów
Zespół usuwania defektów składa się z kierownika projektu, testera, kierownika testów, dewelopera, kierownika środowiska, kierownika testów i analityka biznesowego. Istnieją 3 kroki w selekcji defektów: przegląd defektu, ocena defektu i przypisanie defektu. Każdy z tych kroków jest szczegółowo omówiony poniżej:
- PRZEGLĄD DEFEKTÓW: Wszyscy pracownicy wymienieni powyżej zagłębiają się w pochodzenie i konsekwencje każdego defektu, próbując je naprawić.
- OCENA DEFEKTÓW: W tym kroku, defekty są podzielone na 2 kategorie; do naprawienia i wstrzymane. Powaga wady jest główną podstawą tej segregacji. Wyżej wymieniony personel wspólnie podejmuje decyzję, którą wadę należy natychmiast naprawić, a która powinna zostać wstrzymana: Teraz, gdy zespół ma listę defektów, które muszą być traktowane z pierwszej ręki, przypisuje każdy defekt do odpowiedniej osoby. Wszystko to odbywa się po tym, jak defekt został prawidłowo i wszechstronnie oceniony.
Role i obowiązki każdego członka w Zespole Triage
- LIDER TESTU: Lider testu jest tym, który zaczyna wszystko. Lider testu wysyła formalne zaproszenie do wszystkich członków zespołu triage wraz ze szczegółowym raportem defektu. Lider testu jest pierwszą osobą, która identyfikuje i przypisuje stopień ciężkości każdemu defektowi. Jednym z głównych obowiązków lidera testów jest przygotowanie prezentacji dla zespołu triage, która da im lepszy wgląd w każdy defekt. Prezentacja ta pomaga członkom zespołu szybko dotrzeć do źródła problemu.
- KIEROWNIK PROJEKTU: Kierownik projektu odgrywa kluczową rolę w nadawaniu priorytetów defektom, tworzeniu listy defektów i pośredniczeniu w całym spotkaniu. Dba również o to, aby wszyscy członkowie zespołu triage byli obecni podczas dyskusji. Czasami dyskusja się zaognia i wtedy wkracza kierownik projektu, aby pozwolić członkom zespołu wyrazić rzeczy z ich perspektywy.
- LIDER ZESPOŁU ROZWOJOWEGO: Lider zespołu rozwojowego i kierownik projektu wspólnie ustalają priorytety defektów. Główną funkcją kierownika rozwoju jest informowanie o ryzyku i poziomie złożoności każdego defektu. Ponadto, to on przydziela zadania różnym członkom zespołu triage.
W zespole są inni członkowie, ale kierownik projektu, lider testów i lider zespołu rozwojowego są kluczowymi osobami. Spotkanie nie dojdzie do skutku, jeśli zabraknie którejkolwiek z nich.
Co się dzieje na spotkaniu dotyczącym usuwania defektów?
Spotkanie dotyczące usuwania defektów jest podzielone na 3 części: przed spotkaniem, podczas spotkania i po spotkaniu. Zanim spotkanie się rozpocznie, lider testów wysyła raport do wszystkich członków zespołu triage, tak aby byli oni w pewnym stopniu świadomi najnowszych błędów.
- PRE-MEETING: Testerzy mają kluczową rolę do odegrania w spotkaniu wstępnym. Testerzy przekazują informacje o błędach zespołowi i kategoryzują każdy błąd w różnych sekcjach na podstawie wagi i priorytetu. Tak więc w zasadzie sesja przedspotkaniowa należy do testerów.
- DURING MEETING: Nie zawsze zdarza się, że wszystkie kwestie na spotkaniu są rozwiązane. Niektóre sprawy oczekujące na rozwiązanie z poprzedniego spotkania dotyczącego usuwania błędów są omawiane przed przejściem do nowych spraw. Następnie omawiany jest postęp w rozwiązywaniu poprzednich problemów. Od tego momentu, każdy punkt jest notowany na temat ciężkości istniejących defektów. Członkowie zespołu wspólnie podejmują decyzję, który z defektów należy naprawić natychmiast, a który można odłożyć na później. Jeśli termin jest bliski, błędy o wyższym stopniu nasilenia będą traktowane jako pierwsze, a mniej poważne błędy będą wstrzymane. Jednakże, jeśli nie ma presji terminów, nawet najdrobniejsze błędy mogą zostać naprawione na początku projektu. Na tej podstawie, lista błędów jest aktualizowana i to właśnie tutaj następuje przydział zadań. Ostatnie słowo na spotkaniu należy do kierownika testów. Szybko podsumowuje całe spotkanie i przekazuje natychmiastowe kierunki działania odpowiednim członkom zespołu.
- POST-MEETING: MOM (minutes of the meeting) jest udostępniany zespołowi zajmującemu się usuwaniem usterek po zakończeniu spotkania. Dokument ten zawiera kluczowe punkty omówione podczas spotkania.
Zawartość raportu z badania błędów
- DEFECT ID: Każdy defekt ma przypisany unikalny numer, który odróżnia go od innych defektów.
- DEFECT DESCRIPTION: Jest to związane z tym, w jaki sposób defekt powoduje nieprawidłowe działanie systemu.
- CREATION DATE: Jest to data, w której błąd został zauważony po raz pierwszy.
- TWÓRCA: Twórca jest osobą, która jako pierwsza zauważyła i zgłosiła błąd.
- POWAŻNOŚĆ: Jest to miara tego, jak poważny jest błąd.
- PRIORYTET: Priorytet może być wysoki, średni lub niski. Wysoki priorytet oznacza, że błąd wymaga natychmiastowej uwagi, średni priorytet oznacza, że błąd może być rozwiązany po jakimś czasie i nie wymaga natychmiastowego działania, a niski priorytet oznacza, że błąd nie ma znaczącego lub zauważalnego wpływu na projekt i dlatego może lub nie może być rozwiązany.
- STATUS: To, czy błąd jest nowy, w trakcie przeglądu, w toku lub ukończony, jest określane przez odniesienie do statusu błędu.
- ASSIGNMENT DATE: Jest to data, w której błąd został przypisany do odpowiednich osób w celu jego rozwiązania.
- ASSIGNED TO: W tym polu znajduje się nazwisko osoby, do której błąd został przypisany w celu jego rozwiązania.
- RESOLUTION: Co jest robione w celu rozwiązania błędu.
- DATE OF RESOLUTION: Szacowana data, w której defekt zostanie całkowicie rozwiązany.
- ESTIMATED TIME: Przewidywany czas rozwiązania defektu.
- ACTUAL TIME: Całkowity czas, jaki upłynął do rozwiązania wady.
- ROOT CAUSE DESCRIPTION: To pole zawiera informacje związane z tym, dlaczego błąd pojawił się w pierwszej kolejności.
Dlaczego potrzebujemy Triage Defect?
Główną korzyścią, jaką zyskujesz z tego procesu jest to, że Twój zespół będzie miał możliwość oceny wagi błędu, opracowania planów jego wyłowienia oraz dojścia do wniosku dotyczącego zasobów, które należy przeznaczyć na ten proces. Triage defektów jest głównie używany w zwinnej metodologii testowania
KONKLUZJA
Aby rozwiązać defekt, zwołuje się spotkanie triage’u defektów. Kierownik testów, kierownik projektu i kierownik zespołu deweloperskiego muszą być obecni wśród wszystkich członków zespołu triage.
Spotkanie triage składa się z 3 etapów: przed spotkaniem, podczas spotkania i po spotkaniu. Po tym wszystkim, kierownik testów przygotowuje szczegółowy raport z triage’u.
Raport zawiera wszystkie informacje począwszy od tego, kiedy wada została początkowo zauważona, aż do pierwotnej przyczyny wady.
Częstotliwość triage’u zależy od wielkości projektu. Może być organizowana co tydzień, co miesiąc lub codziennie.
Częstotliwość triage zależy od wielkości projektu.