defect severity priority testing with examples
W tym samouczku dowiesz się, czym jest dotkliwość i priorytet defektów w testowaniu, jak ustawić priorytet defektu i poziomy ważności z przykładami, aby jasno zrozumieć koncepcję.
Omówimy również szczegółowo, jak sklasyfikować defekty w różnych grupach i ich znaczenie w cyklu życia defektu. Omówimy również kluczową rolę klasyfikacji za pomocą żywego zestawu przykładów.
Wady zgłoszenia są bardzo integralną częścią część cyklu życia testowania oprogramowania . Istnieje kilka najlepszych praktyk zdefiniowanych dla skuteczne raportowanie defektów przez Internet lub w organizacjach.
Czego się nauczysz:
- Przegląd śledzenia defektów
Przegląd śledzenia defektów
Jednym z ważnych aspektów cyklu życia defektu na poziomie ogólnym jest śledzenie defektów. Jest to ważne, ponieważ zespoły testowe otwierają kilka defektów podczas testowania fragmentu oprogramowania, który jest zwielokrotniany tylko wtedy, gdy konkretny testowany system jest złożony. W takim scenariuszu zarządzanie tymi defektami i analizowanie ich w celu doprowadzenia do zamknięcia może być trudnym zadaniem.
Zgodnie z procesami konserwacji defektów, kiedy którykolwiek tester zgłasza defekt - oprócz metody / opisu odtworzenia zauważonego problemu, musi on również dostarczyć pewne kategoryczne informacje, które pomogłyby w niedokładnej klasyfikacji wady. To z kolei pomogłoby w efektywnym śledzeniu / konserwacji defektów i stworzyłoby podstawę do szybszego usuwania defektów.
Dwa główne parametry, które stanowią podstawę skutecznego śledzenia i rozwiązywania defektów, to:
- Priorytet defektów w testowaniu
- Ciężkość defektu w testowaniu
Są to często mylące pojęcia i są prawie używane zamiennie nie tylko w zespołach testowych, ale także w zespołach programistycznych. Istnieje cienka granica między nimi i ważne jest, aby zrozumieć, że rzeczywiście istnieją między nimi różnice.
Przyjrzyjmy się pokrótce teoretycznym definicjom dwóch parametrów w następnej sekcji.
Jaka jest waga i priorytet defektu?
Priorytet według angielskiej definicji jest stosowany przy porównywaniu dwóch rzeczy lub warunków, w przypadku których jeden musi mieć większe znaczenie niż inny (e) i musi zostać rozwiązany / rozwiązany najpierw przed przejściem do następnego (-ych). W związku z tym w kontekście usterek priorytet wady wskazywałby na pilność, z jaką należałoby ją naprawić.
Surowość według angielskiej definicji jest używana do opisania wagi niepożądanego zdarzenia. W związku z tym, jeśli chodzi o błędy, ich waga wskazywałaby na wpływ, jaki ma on na system.
Kto je definiuje?
Kontrola jakości klasyfikuje defekt według odpowiedniego poziomu w oparciu o złożoność i krytyczność defektów.
Wszyscy interesariusze biznesowi, w tym kierownicy projektów, analitycy biznesowi, właściciel produktu, określają priorytet defektów.
Poniższy rysunek przedstawia rolę właściciela i klasyfikuje krytyczność i wagę defektów.
Jak wybrać te poziomy?
Jak już omówiliśmy, parametr ważności jest oceniany przez testera, podczas gdy parametr priorytetowy jest oceniany głównie przez menedżera produktu lub w zasadzie zespół triage. Nawet jeśli tak jest, powaga wady jest zdecydowanie jednym z czynników rządzących i wpływających na priorytetyzację wady. Dlatego jako tester ważne jest, aby wybrać odpowiednią wagę, aby uniknąć nieporozumień z zespołami programistów.
Różnica między dotkliwością a priorytetem
Priorytet jest powiązany z planowaniem, a „dotkliwość” jest związana ze standardami.
„Priorytet” oznacza, że coś zostało przyznane lub zasługuje na wcześniejszą uwagę; pierwszeństwo ustalane według ważności (lub pilności).
„Nasilenie” to stan lub jakość bycia poważnym; surowe oznacza przestrzeganie rygorystycznych standardów lub wysokich zasad i często sugeruje surowość; ciężki charakteryzuje się lub wymaga ścisłego przestrzegania rygorystycznych norm lub wysokich zasad, Na przykład, surowy kodeks zachowania.
W śledzeniu błędów pojawiają się słowa „priorytet” i „waga”.
Dostępnych jest wiele komercyjnych narzędzi oprogramowania do śledzenia / zarządzania problemami. Narzędzia te, ze szczegółowym wkładem inżynierów testujących oprogramowanie, dostarczają zespołowi pełnych informacji, dzięki czemu programiści mogą zrozumieć błąd, zorientować się w jego „wadze”, odtworzyć go i naprawić.
Poprawki są oparte na „Priorytetach” projektu i „Wadze” błędów.
„Waga” problemu jest określana zgodnie z oceną ryzyka klienta i zapisywana w wybranym narzędziu do śledzenia.
Błędne oprogramowanie może „poważnie” wpływać na harmonogramy, co z kolei może prowadzić do ponownej oceny i renegocjacji „priorytetów”.
Co to jest priorytet?
Priorytet, jak sama nazwa wskazuje, polega na ustalaniu priorytetów defektu w oparciu o potrzeby biznesowe i stopień wady. Priorytet oznacza wagę lub pilność naprawy usterki.
Podczas otwierania usterki tester zazwyczaj początkowo przypisuje priorytet, gdy patrzy na produkt z perspektywy użytkownika końcowego. Zgodnie z nimi istnieją różne poziomy:
Ogólnie rzecz biorąc, pierwszeństwo wad można sklasyfikować w następujący sposób:
Priorytet 1) Natychmiastowy / Krytyczny (P1)
Należy to naprawić natychmiast w ciągu 24 godzin. Zwykle ma to miejsce w przypadkach, gdy cała funkcjonalność jest zablokowana i nie można z tego powodu przeprowadzić żadnych testów. Lub w niektórych innych przypadkach, jeśli występują znaczące wycieki pamięci, ogólnie wada jest klasyfikowana jako priorytet -1, co oznacza, że program / funkcja nie nadaje się do użytku w bieżącym stanie.
Każda usterka wymagająca natychmiastowej uwagi, która ma wpływ na proces testowania, zostanie sklasyfikowana w kategorii bezpośredniej
Wszystkie Krytyczna dotkliwość wady należą do tej kategorii (chyba że zostaną ponownie nadane priorytetom przez firmę / interesariuszy)
Priorytet 2) Wysoki (P2)
Po naprawieniu krytycznych defektów defekt mający ten priorytet jest kolejnym kandydatem, który musi zostać naprawiony, aby każde działanie testowe spełniało kryteria „wyjścia”. Zwykle, gdy funkcja nie nadaje się do użytku tak, jak powinna, z powodu usterki programu lub gdy trzeba napisać nowy kod, a czasami nawet dlatego, że jakiś problem środowiskowy musi zostać rozwiązany przez kod, defekt może kwalifikować się do priorytetu 2 .
To jest wada lub problem, który powinien zostać rozwiązany przed wydaniem. Te wady powinny zostać usunięte po rozwiązaniu problemów krytycznych.
Wszystkie Poważny surowość wady należą do tej kategorii.
Priorytet # 3) Średni (P3)
Usterka z tym priorytetem musi konkurować, aby została naprawiona, ponieważ może również rozwiązać problemy z funkcjonalnością, które nie są zgodne z oczekiwaniami. Czasami nawet błędy kosmetyczne, takie jak oczekiwanie odpowiedniego komunikatu o błędzie podczas awarii, mogą kwalifikować się jako defekt o priorytecie 3.
Ta usterka powinna zostać usunięta po naprawieniu wszystkich poważnych błędów.
Po usunięciu błędów krytycznych i błędów o wysokim priorytecie możemy przejść do błędów o średnim priorytecie.
Wszystkie Mniejszy surowość wady należą do tej kategorii.
Priorytet 4) Niski (P4)
Usterka o niskim priorytecie wskazuje, że zdecydowanie istnieje problem, ale nie trzeba go naprawiać, aby spełniał kryteria „wyjścia”. Jednak należy to naprawić przed zakończeniem GA. Zazwyczaj niektóre błędy w pisaniu, a nawet błędy kosmetyczne, jak omówiono wcześniej, można tutaj sklasyfikować.
Czasami otwierane są również defekty o niskim priorytecie, aby zasugerować pewne ulepszenia w istniejącym projekcie lub żądanie zaimplementowania niewielkiej funkcji w celu zwiększenia komfortu użytkowania.
Ta wada może zostać usunięta w przyszłości i nie wymaga natychmiastowej uwagi Niska dotkliwość wady należą do tej kategorii.
Jak już wspomniano, priorytet określa, jak szybko musi być czas naprawy defektu. Jeśli jest wiele defektów, priorytet decyduje, który defekt należy naprawić i zweryfikować natychmiast, a który można naprawić nieco później.
Co to jest dotkliwość?
Istotność określa stopień, w jakim dana usterka może mieć wpływ na aplikację lub system.
Istotność to parametr określający wpływ defektu na system - jak krytyczny jest defekt i jaki jest wpływ defektu na funkcjonalność całego systemu? Istotność jest parametrem ustawianym przez testera, gdy otwiera on usterkę i głównie kontroluje testera. Ponownie, różne organizacje mają różne narzędzia do wykorzystania w przypadku defektów, ale na ogólnym poziomie są to następujące poziomy ważności:
Na przykład, Rozważ następujące scenariusze
- Jeśli użytkownik próbuje zrobić zakupy online, a aplikacja nie ładuje się lub pojawia się komunikat o niedostępności serwera.
- Użytkownik dokonuje dodania towaru do koszyka, ilość dodanych ilości jest nieprawidłowa / zostaje dodany zły produkt.
- Użytkownik dokonuje płatności i po dokonaniu płatności zamówienie pozostaje w koszyku jako zarezerwowane zamiast potwierdzone.
- System przyjmuje zamówienie, ale ostatecznie anuluje zamówienie po pół godzinie z powodu jakichkolwiek problemów.
- System akceptuje opcję „Dodaj do koszyka” tylko po dwukrotnym kliknięciu zamiast jednego kliknięcia.
- Przycisk Dodaj do koszyka jest zapisany jako Dodaj do koszyka.
Jakie byłyby wrażenia użytkownika, gdyby którykolwiek z powyższych scenariuszy mógł się wydarzyć?
Ogólnie wady można sklasyfikować w następujący sposób:
# 1) Krytyczny (S1)
Defekt, który całkowicie utrudnia lub blokuje testowanie produktu / funkcji, jest defektem krytycznym. Przykładem może być przypadek testowania interfejsu użytkownika, w którym po przejściu przez kreatora interfejs użytkownika po prostu zawiesza się w jednym okienku lub nie przechodzi dalej, aby uruchomić funkcję. Lub w innych przypadkach, gdy funkcja została opracowana samodzielnie, a nie ma jej w kompilacji.
Z jakiegokolwiek powodu, jeśli aplikacja ulegnie awarii lub stanie się bezużyteczna / nie będzie w stanie kontynuować, wada może zostać sklasyfikowana jako krytyczna.
Wszelkie katastrofalne awarie systemu mogą doprowadzić użytkownika do nieprzydatności aplikacji, które można sklasyfikować jako krytyczne
Na przykład, W dostawcach usług e-mail, takich jak Yahoo czy Gmail, po wpisaniu poprawnej nazwy użytkownika i hasła, zamiast logowania, system zawiesza się lub wyświetla komunikat o błędzie, ta wada jest klasyfikowana jako krytyczna, ponieważ ta wada sprawia, że cała aplikacja jest bezużyteczna.
Omawiany powyżej scenariusz z punktu 1 można zaklasyfikować jako krytyczny błąd, ponieważ aplikacja internetowa staje się całkowicie bezużyteczna.
# 2) Major (S2)
Każda zaimplementowana główna funkcja, która nie spełnia jej wymagań / przypadków użycia i zachowuje się inaczej niż oczekiwano, może zostać sklasyfikowana w kategorii Duża ważność.
Poważna wada występuje, gdy funkcja działa znacznie odbiegając od oczekiwań lub nie robi tego, co powinna. Przykładem może być: Załóżmy, że na przełączniku musi zostać wdrożona sieć VLAN i używasz szablonu interfejsu użytkownika, który wyzwala tę funkcję. Gdy ten szablon do konfigurowania sieci VLAN zawiedzie na przełączniku, zostaje sklasyfikowany jako poważna wada funkcjonalności.
Na przykład, W przypadku dostawcy usług poczty e-mail, takiego jak Yahoo lub Gmail, jeśli nie możesz dodać więcej niż jednego odbiorcy w sekcji DW, ta wada jest klasyfikowana jako poważna wada, ponieważ główna funkcjonalność aplikacji nie działa poprawnie.
Jakie jest oczekiwane zachowanie sekcji CC w poczcie, powinno to pozwolić użytkownikowi na dodanie wielu Użytkowników. Zatem gdy główna funkcjonalność aplikacji nie działa poprawnie lub gdy zachowuje się inaczej niż oczekiwano, jest to poważna usterka.
Scenariusze w punktach 2 i 3 omówione powyżej można zaklasyfikować jako poważną wadę, ponieważ oczekuje się, że kolejność przejdzie płynnie do następnej fazy cyklu życia zamówienia, ale w rzeczywistości różni się zachowaniem.
Każda wada, która może prowadzić do nieprawidłowego trwałości danych, problemów z danymi lub niewłaściwego zachowania aplikacji, może być ogólnie sklasyfikowana jako poważna.
# 3) Drobne / Umiarkowane (S3)
Każda zaimplementowana funkcja, która nie spełnia jej wymagań / przypadków użycia i zachowuje się inaczej niż oczekiwano, ale wpływ jest do pewnego stopnia nieistotny lub nie ma dużego wpływu na aplikację, można sklasyfikować w kategorii Minor Severity.
Umiarkowana wada występuje, gdy produkt lub aplikacja nie spełnia określonych kryteriów lub nadal wykazuje pewne nienaturalne zachowanie, jednak nie ma to wpływu na funkcjonalność jako całość. Na przykład w powyższym wdrożeniu szablonu VLAN wystąpiłby umiarkowany lub normalny błąd, gdy szablon zostanie pomyślnie wdrożony na przełączniku, jednak nie ma żadnego wskazania wysyłanego do użytkownika.
Na przykład, W dostawcy usług e-mail, takim jak Yahoo lub Gmail, dostępna jest opcja „Warunki” iw tej opcji będzie wiele linków dotyczących warunków i stanu witryny internetowej. Gdy jeden z wielu linków nie działa prawidłowo, Nazywa się to Minor Severity, ponieważ wpływa tylko na niewielką funkcjonalność aplikacji i nie ma dużego wpływu na użyteczność aplikacji.
Scenariusz z punktu 5 omówiony powyżej można zaklasyfikować jako drobną wadę, ponieważ nie ma utraty danych ani awarii w porządku przepływu systemu, ale niewielka niedogodność, jeśli chodzi o wrażenia użytkownika.
Tego typu defekty powodują minimalną utratę funkcjonalności lub doświadczenia użytkownika.
# 4) Niska (S4)
Wszelkie defekty kosmetyczne, w tym błędy ortograficzne, problemy z wyrównaniem lub wielkość liter, można sklasyfikować w kategorii Niska istotność.
Drobny błąd o niskiej wadze występuje, gdy nie ma prawie żadnego wpływu na funkcjonalność, ale nadal jest to ważny defekt, który należy naprawić. Przykładami mogą być błędy ortograficzne w komunikatach o błędach drukowanych do użytkowników lub wady poprawiające wygląd i działanie funkcji.
Na przykład, W przypadku dostawcy usług e-mail, takiego jak Yahoo lub Gmail, można zauważyć „stronę licencji”, jeśli na stronie występują błędy ortograficzne lub błędy wyrównania, ta wada jest klasyfikowana jako niska.
Omawiany powyżej scenariusz z punktu 6 można sklasyfikować jako Niski Defekt, ponieważ przycisk Dodaj jest wyświetlany w niewłaściwej obudowie. Ten rodzaj usterki nie będzie miał żadnego wpływu na zachowanie systemu, prezentację danych, utratę danych lub przepływ danych, a nawet wrażenia użytkownika, ale będzie bardzo kosmetyczny.
Podsumowując, poniższy rysunek przedstawia szeroką klasyfikację defektów w oparciu o ważność i priorytet:
Przykłady
Jak już wspomniano, ponieważ różne organizacje używają różnych rodzajów narzędzi do śledzenia defektów i związanych z nimi procesów, staje się on wspólnym systemem śledzenia na różnych poziomach zarządzania i personelu technicznego.
Ponieważ Ważność Wady mieści się bardziej w zakresie funkcjonalności, Inżynier Testów ustala wagę wady. Czasami programiści biorą udział w wpłynięciu na wagę defektu, ale w większości zależy to od testera, który ocenia, jak bardzo dana funkcja może wpłynąć na ogólne funkcjonowanie.
Z drugiej strony, jeśli chodzi o ustalanie priorytetów defektów, chociaż początkowo inicjator usterki ustala priorytet, w rzeczywistości jest on definiowany przez Menedżera produktu, ponieważ ma on ogólny pogląd na produkt i jak szybko należy usunąć daną wadę . Tester nie jest idealną osobą do wyznaczania priorytetu defektu.
Choć może się to wydawać szokujące, istnieją dwa wyraźne przykłady, dlaczego:
Przykład 1) Weź pod uwagę, że istnieje sytuacja, w której użytkownik znajdzie błąd w nazewnictwie samego produktu lub jakiś problem z dokumentacją interfejsu użytkownika. Tester normalnie otworzyłby drobną / kosmetyczną wadę i może być bardzo prosty do naprawienia, ale jeśli chodzi o wygląd i wrażenia użytkownika / odczucia produktu, może to mieć poważny wpływ.
Przykład nr 2) Mogą zaistnieć pewne warunki, w których wystąpi konkretna wada, co może być niezwykle rzadką lub żadną możliwością uderzenia w środowisko klienta. Nawet jeśli z punktu widzenia funkcjonalności może się to wydawać testerowi wadą o wysokim priorytecie, biorąc pod uwagę jej rzadkość występowania i wysoki koszt naprawy - zostanie to sklasyfikowane jako defekt o niskim priorytecie.
W efekcie priorytet defektu jest zwykle ustalany przez menedżera produktu na spotkaniu „selekcji defektów”.
Różne poziomy
Priorytety i dotkliwość mają wśród nich pewne klasyfikacje, które pomagają w określeniu, jak należy postępować z defektem. Wiele różnych organizacji ma różne narzędzia do rejestrowania defektów , więc poziomy mogą się różnić.
Przyjrzyjmy się różnym poziomom zarówno priorytetu, jak i wagi.
- Wysoki priorytet, wysoki poziom ważności
- Wysoki priorytet, niski poziom ważności
- Wysoka ważność, niski priorytet
- Niska waga, niski priorytet
Poniższy rysunek przedstawia klasyfikację kategorii w jednym fragmencie.
dobry downloader mp3 dla Androida za darmo
# 1) Wysoka waga i wysoki priorytet
Każda krytyczna / poważna awaria przypadku biznesowego jest automatycznie promowana do tej kategorii.
Wszelkie usterki, z powodu których testy nie mogą być kontynuowane za wszelką cenę lub powodują poważną awarię systemu, należą do tej kategorii. Na przykład, kliknięcie określonego przycisku nie powoduje załadowania samej funkcji. Lub wykonanie określonej funkcji powoduje konsekwentne wyłączenie serwera i powoduje utratę danych. Czerwone linie na powyższym rysunku wskazują tego rodzaju wady.
Na przykład,
System ulega awarii po dokonaniu płatności lub gdy nie można dodać produktów do Koszyka, ta wada jest oznaczana jako wada o wysokim stopniu ważności i wysokim priorytecie.
Inny przykład byłaby funkcja waluty automatycznej do bankomatu, w której po wprowadzeniu poprawnej nazwy użytkownika i hasła, maszyna nie wydaje pieniędzy, ale odlicza przelew z Twojego konta.
# 2) Wysoki priorytet i niska waga
Wszelkie drobne wady, które mogą bezpośrednio wpłynąć na wrażenia użytkownika, są automatycznie promowane do tej kategorii.
Wady, które muszą zostać naprawione, ale nie mają wpływu na aplikację, należą do tej kategorii.
Na przykład, oczekuje się, że funkcja wyświetli użytkownikowi określony błąd w odniesieniu do jego kodu powrotu. W takim przypadku funkcjonalnie kod zwróci błąd, ale komunikat będzie musiał być bardziej odpowiedni dla wygenerowanego kodu powrotu. Niebieskie linie na rysunku wskazują tego rodzaju wady.
Na przykład,
Logo firmy na pierwszej stronie jest błędne, uważa się, że jest Wysoki priorytet i niski poziom ważności wada .
Przykład 1) W witrynie zakupów online, gdy logo FrontPage jest napisane nieprawidłowo, na przykład zamiast Flipkart jest zapisane jako Flipkart.
Przykład 2) W logo banku zamiast ICICI jest napisane jako ICCCI.
Jeśli chodzi o funkcjonalność, nie wpływa to na nic, więc możemy oznaczyć jako niską wagę, ale ma to wpływ na wrażenia użytkownika. Ten rodzaj usterki musi być naprawiony z wysokim priorytetem, mimo że ma bardzo mniejszy wpływ na stronę aplikacji.
# 3) Wysoka waga i niski priorytet
Każda usterka, która funkcjonalnie nie spełnia wymagań lub ma jakiekolwiek konsekwencje funkcjonalne dla systemu, ale jest odsunięta na drugi plan przez interesariuszy, jeśli chodzi o krytyczne znaczenie biznesowe, automatycznie zostaje przeniesiona do tej kategorii.
Wady, które trzeba naprawić, ale nie od razu. Taka sytuacja może wystąpić zwłaszcza podczas testowania ad hoc. Oznacza to, że ma to duży wpływ na funkcjonalność, ale obserwuje się go tylko wtedy, gdy używane są pewne nietypowe parametry wejściowe.
Na przykład, dana funkcjonalność może być używana tylko w późniejszej wersji oprogramowania, więc aby to zweryfikować - tester faktycznie degraduje swój system i przeprowadza test oraz obserwuje poważny problem z funkcjonalnością, który jest prawidłowy. W takim przypadku usterki zostaną zaklasyfikowane do tej kategorii oznaczonej różowymi liniami, ponieważ zwykle oczekuje się, że użytkownicy końcowi będą mieli wyższą wersję oprogramowania układowego.
Na przykład,
W serwisie społecznościowym, jeśli zostanie wydana wersja beta nowej funkcji, a na dzień dzisiejszy niewielu aktywnych użytkowników korzysta z tej funkcji. Każda usterka znaleziona w tej funkcji może zostać sklasyfikowana jako o niskim priorytecie, ponieważ funkcja zajmuje drugie miejsce ze względu na klasyfikację biznesową jako nieważną.
Chociaż ta funkcja ma wadę funkcjonalną, ponieważ nie ma ona bezpośredniego wpływu na klientów końcowych, interesariusz biznesowy może zaklasyfikować usterkę do niskiego priorytetu, chociaż ma ona poważny wpływ na funkcjonalność aplikacji.
Jest to błąd o wysokim poziomie istotności, ale może mieć priorytet niski, ponieważ można go naprawić w następnej wersji jako żądanie zmiany. Interesariusze biznesowi również traktują tę funkcję priorytetowo jako rzadko używaną funkcję i nie wpływają na żadne inne funkcje, które mają bezpośredni wpływ na wrażenia użytkownika. Ten rodzaj usterki można sklasyfikować w kategorii Wysoka waga, ale niski priorytet Kategoria.
# 4) Niska waga i niski priorytet
Wszelkie błędy w pisowni / wielkość liter / brak wyrównania w akapicie 3r & Dlub 4thna stronie wniosku, a nie na stronie głównej lub tytułowej.
Te wady są sklasyfikowane w zielonych liniach, jak pokazano na rysunku i występują, gdy nie ma wpływu na funkcjonalność, ale nadal nie spełniają standardów w niewielkim stopniu. Generalnie błędy kosmetyczne lub powiedzmy wymiary komórki w tabeli w interfejsie użytkownika są klasyfikowane tutaj.
Na przykład,
Jeśli w polityce prywatności serwisu jest błąd ortograficzny, usterka ta zostaje ustawiona jako Niska waga i niski priorytet.
Wytyczne
Poniżej znajdują się wskazówki, których każdy tester musi przestrzegać:
- Po pierwsze, dobrze zrozum pojęcia priorytetu i wagi. Unikaj mylenia jednego z drugim i używania ich zamiennie. Zgodnie z tym postępuj zgodnie z wytycznymi dotyczącymi ważności opublikowanymi przez organizację / zespół, aby wszyscy byli na tej samej stronie.
- Zawsze wybieraj poziom istotności w oparciu o typ problemu, ponieważ wpłynie to na jego priorytet. Oto kilka przykładów:
- W przypadku krytycznego problemu, takiego jak awaria całego systemu i nic nie można zrobić - tej wagi nie należy używać do usuwania usterek programu.
- W przypadku poważnego problemu, na przykład w przypadkach, gdy funkcja nie działa zgodnie z oczekiwaniami - tę wagę można wykorzystać w celu rozwiązania nowych funkcji lub poprawy bieżącej pracy.
Pamiętaj, że wybranie odpowiedniego poziomu dotkliwości z kolei nada wadzie, jest to należny priorytet.
- Jako tester - zrozumieć, w jaki sposób dana funkcjonalność, raczej drążyć dalej - zrozumieć, jak określony scenariusz lub przypadek testowy wpłynie na użytkownika końcowego. Wymaga to dużej współpracy i interakcji z zespołem programistów, analitykami biznesowymi, architektami, kierownikiem testów, kierownikiem ds. Rozwoju. W swoich dyskusjach musisz również wziąć pod uwagę, ile czasu zajmie naprawa wady w oparciu o jej złożoność i czas na weryfikację tej wady.
- Wreszcie , zawsze właściciel produktu ma prawo weta do wydania, w którym wada powinna zostać naprawiona. Ponieważ jednak sesje selekcji defektów zawierają różnych członków, którzy przedstawiają swoje spojrzenie na defekt na podstawie przypadku, w takim momencie, jeśli programiści i testerzy są zsynchronizowani, z pewnością pomaga to wpłynąć na decyzję.
Wniosek
Podczas otwierania defektów obowiązkiem testera jest przypisanie im odpowiedniej wagi. Nieprawidłowa dotkliwość, a tym samym mapowanie priorytetów, może mieć bardzo drastyczne konsekwencje dla całego procesu STLC i produktu jako całości. W kilku rozmowach kwalifikacyjnych - pojawia się kilka pytań dotyczących priorytetu i wagi, aby upewnić się, że jako tester masz nieskazitelnie jasne koncepcje.
Widzieliśmy również na żywo przykłady klasyfikowania defektu w różnych grupach ważności / priorytetów. Żałuję, że do tej pory nie masz wystarczających wyjaśnień na temat klasyfikacji defektów zarówno w grupach dotkliwości / priorytetów.
Mam nadzieję, że ten artykuł jest kompletnym przewodnikiem do zrozumienia priorytetów defektów i poziomów ważności. Daj nam znać swoje przemyślenia / pytania w komentarzach poniżej.
rekomendowane lektury
- Co to jest technika testowania oparta na defektach?
- Co to jest cykl życia defektów / błędów w testowaniu oprogramowania? Samouczek dotyczący cyklu życia wady
- Proces zarządzania defektami: jak skutecznie zarządzać defektem
- Jak odtworzyć niepowtarzalną usterkę i sprawić, by wysiłek związany z testowaniem był tego wart
- 7 Zasady testowania oprogramowania: grupowanie defektów i zasada Pareto
- Metody i techniki zapobiegania defektom
- Dokładna różnica między weryfikacją a walidacją z przykładami
- 3 strategie radzenia sobie z defektem blokującym