Piramida defektów

Piramida defektów
Defekty możemy podzielić ze względu na ich krytyczność, co często jest kluczowym parametrem w zgłoszeniach. Defekty mają również swoją hierarchię, którą można zaprezentować w postaci piramidy.

Ważność defektu określa, jak duży wpływ na system będzie miał dany problem i z jakimi konsekwencjami się on wiąże. Podział ze względu na wagę defektu może wyglądać następująco:

 

Krytyczny

Opis: Awaria systemu z ryzykiem utraty danych; system nie może zostać wydany.

Najwięcej defektów krytycznych pojawia się we wczesnych fazach tworzenia oprogramowania. Występują one w całym procesie i zazwyczaj związane są z prostymi błędami programistów lub niekontrolowanymi zmianami w systemach. Zazwyczaj jest ich niewiele.

 

Bardzo poważny

Niespełnione lub niepoprawnie zaimplementowanie wymagania; obiekt testowy może być używany, ale przy zachowaniu pewnych reguł.

Takie defekty występują w całym procesie wytwarzania oprogramowania.

 

Poważny

Niezgodny z wymaganiami lub tylko częściowo zaimplementowany; obiekt testowy może być użyty z pewnymi restrykcjami.

Defekty popularne i wynikające przede wszystkim z problemów związanych ze zrozumieniem wymagań. Wykrywane są zazwyczaj przy testach systemowych.

 

Średni

Pomniejsze odchyłki; obiekt testowy może być używany bez restrykcji. Zazwyczaj jest ich wiele i znajdywane są w późnych etapach wytwarzania oprogramowania.

 

Trywialny

Literówki, kolory na ekranie; obiekt testowy może być używany. Takich defektów jest bardzo dużo i wykrywane w całym procesie wytwórczym.

 

Ze względu na liczbę defektów w testowanym obiekcie mogą być one ułożone w odwróconą piramidę, gdzie liczność każdej z grup odpowiada mniej więcej zajmowanej powierzchni.

Defekty trywialne mają najmniejszą wagę i jest ich najwięcej. Defektów krytycznych jest najmniej, ale są one ekstremalnie ważne. Występowanie defektów krytycznych, które blokują uruchomienie innych funkcji (tzw. blokery) może uniemożliwić znajdowanie innych defektów.

W różnych publikacjach często mówi się, że testowanie eksploracyjne może nie znaleźć najbardziej krytycznych defektów ze względu na brak specyfikacji. Jest to prawda, ale nie odnosi się to tylko do testowania bazującego na kontekście. Testowanie oparte na specyfikacji może nie znaleźć wszystkich krytycznych defektów ze względu na wymagania opisane jednym priorytetem. Testowanie oparte na ryzyku również może nie znaleźć najbardziej krytycznych defektów przy błędnej (o co nie trudno) analizie ryzyk.

 

Bibliografia

http://testerzy.pl/baza-wiedzy/waznosc-i-priorytet-ocena-defektow

 

 

 
6873

Powiązane szkolenia

05-06
czerwca
2023
Jarosław Hryszko
online
Praktyka testowania
1 750PLN
Testowanie aplikacji internetowych
12
Wolnych miejsc
Rezerwuj
06-07
marca
2023
Arnika Hryszko
online
Praktyka testowania
1 770PLN
Testowanie użyteczności
9
Wolnych miejsc
Rezerwuj
20-21
kwietnia
2023
Rafał Stańczak
online
Dobre praktyki testowania
1 700PLN
Testowanie w metodykach Agile
12
Wolnych miejsc
Rezerwuj
23-24
marca
2023
Krzysztof Kołodziejczyk
online
Praktyka testowania
1 770PLN
Testowanie aplikacji mobilnych - Android
9
Wolnych miejsc
Rezerwuj
12-13
czerwca
2023
Krzysztof Skarbiński
online
Automatyzacja testowania
1 800PLN
Testowanie REST API dla początkujących w języku python
11
Wolnych miejsc
Rezerwuj
27-28
lutego
2023
Krzysztof Kołodziejczyk
online
Języki programowania dla testerów
1 800PLN
JavaScript dla testerów oprogramowania
9
Wolnych miejsc
Rezerwuj
24-26
kwietnia
2023
Krzysztof Kołodziejczyk
online
Praktyka testowania
3 000PLN
Tester gier
11
Wolnych miejsc
Rezerwuj
13
marca
2023
-09
kwietnia
2023
Krzysztof Kołodziejczyk
online
Automatyzacja testowania
5 500PLN
Praktyka automatyzacji testowania
5
Wolnych miejsc
Rezerwuj

To powinno Cię zainteresować