Zasada Pareto w testowaniu: 83% defektów w 20% plików

Czas czytania: około 12 minut

Czasu na testy zawsze jest mniej niż funkcji do sprawdzenia. Zasada Pareto podpowiada, co z tym zrobić: nie testować wszystkiego po równo, tylko znaleźć tę niewielką część systemu, w której siedzi większość błędów i większość ryzyka, i tam postawić najwięcej uwagi.

Pokażemy, co naprawdę mówią badania o regule 80/20 w oprogramowaniu, gdzie ta reguła zawodzi i jak w jeden sprint wyznaczyć Wasze 20 procent na danych, które już macie.

Spis treści

Co to jest zasada Pareto w testowaniu oprogramowania
Skąd wzięła się reguła 80/20
Co mówią badania o skupiskach defektów
Ryzyko projektowe i ryzyko produktowe, czyli dwa różne 20 procent
Jak znaleźć 20 procent ryzyka w Waszym produkcie
Macierz ryzyka: prawdopodobieństwo razy wpływ
Testowanie oparte na ryzyku w sześciu krokach
Zasada 80/20 a AI w testowaniu
Pięć pułapek, w które wpadają zespoły
Od czego zacząć w tym tygodniu

Co to jest zasada Pareto w testowaniu oprogramowania

Definicja

Zasada Pareto w testowaniu oprogramowania mówi, że większość defektów i awarii pochodzi z niewielkiej części systemu. W sylabusie ISTQB to czwarta z siedmiu zasad testowania: defekty mają tendencję do skupiania się, a przewidywane i zaobserwowane skupiska są wejściem do testowania opartego na ryzyku.

Liczby 80 i 20 nie są prawem natury, tylko skrótem myślowym. Ważna jest nierówność: błędy nie rozkładają się po kodzie jak masło na chlebie, tylko zbijają się w grudki. Jeśli wiecie, gdzie są grudki, możecie rozdzielić ograniczony czas testów tak, żeby chronił to, co dla Waszych użytkowników i dla biznesu znaczy najwięcej.

Sylabus ISTQB Foundation Level w wersji 4.0.1 z 2024 roku opisuje to wprost jako ilustrację zasady Pareto i od razu łączy ją z zarządzaniem ryzykiem. To dobra wiadomość dla każdego, kto musi obronić swoje priorytety przed kierownikiem projektu: nie bronicie intuicji, tylko jednej z podstawowych zasad zawodu, której uczy się na szkoleniu Foundation Level.

Skąd wzięła się reguła 80/20

Vilfredo Pareto, włoski ekonomista, zauważył, że około 80 procent ziemi we Włoszech należy do około 20 procent ludności. Kilkadziesiąt lat później Joseph Juran przeniósł tę obserwację do zarządzania jakością i nazwał ją zasadą „nielicznych istotnych i licznych użytecznych”. Juran celowo nie pisał o „bezwartościowej większości”, bo pozostałe 80 procent też trzeba obsłużyć, tylko z mniejszym nakładem.

Do oprogramowania reguła trafiła najgłośniej w 2002 roku. Według relacji CRN z października 2002 roku Steve Ballmer napisał klientom Microsoftu, że około 20 procent błędów powoduje 80 procent wszystkich awarii zgłaszanych przez system raportowania błędów, a 1 procent błędów odpowiada za połowę z nich. Sam Ballmer dopisał, że ta druga liczba go zdumiała, więc jeśli Wy też unieśliście brwi, jesteście w dobrym towarzystwie.

Co mówią badania o skupiskach defektów

Reguła 80/20 brzmi zgrabnie, ale warto sprawdzić, na czym stoi. Trzy badania są tu cytowane najczęściej i każde mówi coś trochę innego:

83%

defektów w 20 procent plików wskazanych przez model, średnio (Ostrand, Weyuker, Bell, 2005)

80/20

około 80 procent defektów z 20 procent modułów (Boehm, Basili, 2001)

90/10

około 90 procent przestojów z najwyżej 10 procent defektów (Boehm, Basili, 2001)

50%

modułów bez defektów w tym samym zestawieniu (Boehm, Basili, 2001)

Źródło	Na czym oparte	Co wynika
Boehm i Basili, IEEE Computer, 2001	Zestawienie dziesięciu empirycznych prawidłowości z projektów	Około 80 procent defektów pochodzi z 20 procent modułów, a około połowa modułów nie ma defektów
Fenton i Ohlsson, IEEE TSE, 2000	Dwa wydania dużego systemu komercyjnego	Mała liczba modułów zawiera większość błędów z testów przedwydaniowych, a bardzo mała większość błędów z produkcji
Ostrand, Weyuker i Bell, IEEE TSE, 2005	Dwa duże systemy przemysłowe, 17 i 9 wydań	20 procent plików wytypowanych przez model zawierało od 71 do 92 procent wykrytych defektów
ISTQB CTFL v4.0.1, 2024	Sylabus, zasady testowania	Defekty się skupiają; skupiska są wejściem do testowania opartego na ryzyku

Według badania Ostranda, Weyuker i Bella z 2005 roku model przewidujący liczbę defektów na podstawie historii zmian i błędów wskazał 20 procent plików, w których było średnio 83 procent wykrytych defektów. Jeszcze ciekawsze jest to, że mocno uproszczona wersja tego modelu wskazała pliki z 73 i 74 procent defektów w dwóch badanych systemach, jak podaje ten sam artykuł. Nie potrzebujecie więc zespołu data science, żeby zacząć.

Z tego zestawienia wynika też rzecz mniej oczywista. Boehm i Basili w tym samym artykule z 2001 roku podają, że około 80 procent możliwej do uniknięcia pracy poprawkowej pochodzi z 20 procent defektów. Ważniejsze od tego, gdzie jest najwięcej błędów, bywa więc pytanie, które błędy kosztują najwięcej.

Wbrew pozorom

Fenton i Ohlsson w badaniu z 2000 roku sprawdzili, czy moduły z największą liczbą błędów przed wydaniem są też najbardziej awaryjne na produkcji. Wyszło odwrotnie: moduły najbardziej błędogenne przed wydaniem należały do najmniej błędogennych po wydaniu, a te, które sypały się u użytkowników, przed wydaniem wyglądały spokojnie. Zasada Pareto działa, ale Wasze 20 procent się przesuwa. Kto wyznaczy je raz i zapomni, będzie pilnował miejsca, które już zostało naprawione.

Ryzyko projektowe i ryzyko produktowe, czyli dwa różne 20 procent

Stary tytuł tego artykułu mówił o ryzyku projektowym, a większość przykładów dotyczyła ryzyka produktowego. To częsta pomyłka i warto ją rozplątać, bo każde z nich ma swoje 20 procent i inne narzędzia. Sylabus ISTQB rozdziela je tak:

	Ryzyko projektowe	Ryzyko produktowe
Czego dotyczy	Zarządzania i kontroli projektu	Cech jakościowych produktu (model ISO 25010)
Przykłady	Opóźnienia dostaw, złe szacunki, braki kompetencji, konflikty, zmiana zakresu, awaria dostawcy	Brakująca lub błędna funkcja, złe obliczenia, wolna odpowiedź, słaba użyteczność, podatności bezpieczeństwa
Skutek	Harmonogram, budżet albo zakres projektu	Niezadowolenie użytkowników, utrata przychodu, kary, szkody wizerunkowe
Co robi tester	Sygnalizuje wcześnie, planuje bufor, dopasowuje zakres testów	Priorytetyzuje testy, dobiera techniki i głębokość testowania
Gdzie szukać 20 procent	W zależnościach od ludzi, dostawców i terminów	W modułach, funkcjach i danych, od których zależą pieniądze użytkownika

Oba rodzaje ryzyka mierzy się tak samo, czyli prawdopodobieństwem i wpływem. W naszych projektach widzimy jednak, że zespoły świetnie liczą ryzyko produktowe, a projektowe zostawiają kierownikowi, aż do dnia, w którym środowisko testowe dostaje się tydzień po terminie. Jeśli chcecie przećwiczyć to na własnych przykładach, zajrzyjcie do programu szkolenia Zarządzanie ryzykiem w projektach IT.

Jak znaleźć 20 procent ryzyka w Waszym produkcie

Nie trzeba zaczynać od modelu statystycznego. Większość danych potrzebnych do wyznaczenia pierwszej wersji Waszych 20 procent już leży w narzędziach zespołu:

Historia defektów

Eksport zgłoszeń z JIRA z ostatnich 6 do 12 miesięcy, pogrupowany po module. Liczy się też krytyczność, nie tylko liczba.

Incydenty produkcyjne

To, co zgłosili użytkownicy i monitoring. Po badaniu Fentona i Ohlssona wiecie, że to inne 20 procent niż z testów.

Częstotliwość zmian

Pliki zmieniane najczęściej w repozytorium. Model Ostranda opierał się właśnie na historii zmian.

Ruch i przychód

Funkcje, przez które przechodzi najwięcej użytkowników i pieniędzy: logowanie, koszyk, płatność, rezerwacja.

Nowość i złożoność

Nowa technologia, nowa integracja, nowy zespół. Brak historii to też sygnał ryzyka.

Wymogi prawne

Obszary objęte regulacją, gdzie błąd kosztuje karę, a nie tylko zgłoszenie.

Połączcie te źródła w jednej tabeli i zobaczycie, że kilka modułów pojawia się w trzech albo czterech kolumnach naraz. To są Wasi pierwsi kandydaci. Jeśli zgłoszenia błędów w JIRA są opisane byle jak, najpierw poprawcie jakość zgłoszeń, bo analiza Pareto na złych danych daje bardzo pewne siebie złe wnioski. Pomoże w tym przewodnik, jak poprawnie zgłosić błąd.

Macierz ryzyka: prawdopodobieństwo razy wpływ

Sylabus ISTQB opisuje poziom ryzyka jako połączenie dwóch czynników: prawdopodobieństwa, że coś się wydarzy, i wpływu, jaki to zdarzenie będzie miało. W praktyce wystarczy skala od 1 do 5 dla każdego z nich i iloczyn jako wynik. Przykład dla sklepu internetowego:

Obszar	Prawdopodobieństwo	Wpływ	Wynik	Co z tym robimy
Płatność i potwierdzenie zamówienia	4	5	20	testy głębokie, automatyzacja regresji, testy wydajności przed szczytem
Koszyk i kody rabatowe	4	4	16	testy głębokie, dane brzegowe, kombinacje rabatów
Wyszukiwarka produktów	3	4	12	testy średniej głębokości, testy wydajności zapytań
Rejestracja i logowanie	2	5	10	testy bezpieczeństwa, regresja automatyczna
Lista życzeń	3	2	6	testy podstawowe
Strona „O nas”	1	1	1	test dymny przy wydaniu

Liczby w tabeli są przykładem, nie normą. Ważne, żeby ocenę robiły razem co najmniej trzy perspektywy: tester, programista i ktoś, kto zna biznes. Tester przeszacowuje to, co widział, programista to, co pisał, a biznes to, co ostatnio zepsuło mu kwartał. Średnia z trzech jest zwykle bliżej prawdy niż którakolwiek z nich osobno.

W projekcie dla Argos, firmy z branży e-commerce, automatyzacja testów i uporządkowanie procesów QA z naciskiem na stabilność checkoutu i płatności dały efekt, który z danych klienta wygląda tak: regresja przed releasem skróciła się z 5 dni do 10 godzin, a błędów krytycznych na produkcji jest o 46 procent mniej. Pełny opis znajdziecie w artykule jak skrócić testy regresyjne z 5 dni do 10 godzin.

Testowanie oparte na ryzyku w sześciu krokach

Sylabus ISTQB nazywa podejście, w którym czynności testowe wybiera się, priorytetyzuje i prowadzi na podstawie analizy ryzyka, testowaniem opartym na ryzyku. Tak wygląda ono w zespole, który ma dwa tygodnie sprintu i nie ma czasu na dokumentację dla dokumentacji:

Zbierzcie dane z sześciu źródeł opisanych wyżej i ułóżcie listę obszarów produktu. Wystarczy arkusz.
Oceńcie prawdopodobieństwo i wpływ w trzyosobowym składzie, najlepiej na jednym spotkaniu, które trwa krócej niż godzinę.
Wyznaczcie próg. Obszary z najwyższym wynikiem, zwykle kilka pozycji na kilkadziesiąt, dostają testy głębokie i automatyzację regresji.
Dobierzcie techniki do poziomu ryzyka. Tam, gdzie ryzyko wysokie, wartości brzegowe, tablice decyzyjne i testy przejść stanów. Gdzie niskie, test dymny. Warstwy i techniki porządkuje artykuł o piramidzie testów.
Raportujcie w języku ryzyka. Nie „wykonaliśmy 412 przypadków”, tylko „obszary o najwyższym ryzyku są pokryte, dwa ryzyka zostają otwarte”. Wzór takiego raportu opisujemy w tekście raport z testów: must have.
Wracajcie do listy po każdym wydaniu. Incydenty z produkcji przesuwają Wasze 20 procent szybciej, niż się wydaje.

Zarząd rzadko pyta o liczbę przypadków testowych, za to zawsze pyta, czy wydanie jest bezpieczne. Jak przełożyć mapę ryzyka na liczby, które rozumie finansista, pokazujemy w artykule KPI dla zarządu: jak przełożyć wyniki QA na język CFO. A jeśli chcecie zobaczyć, ile kosztuje dzień opóźnienia wydania, gdy regresja nie ma priorytetów, Strefa QA opisała to w tekście regresja przed releasem: ile kosztuje dzień opóźnienia wydania.

Zasada 80/20 a AI w testowaniu

Część z Was trafia tu z pytaniem o zasadę 80/20 w kontekście sztucznej inteligencji. W testowaniu to połączenie ma sens w jednym konkretnym miejscu: AI i modele statystyczne dobrze radzą sobie z typowaniem, gdzie pojawią się defekty, bo to zadanie na dużych danych historycznych. Model Ostranda z 2005 roku był właśnie takim przewidywaniem, tylko bez modnej nazwy.

Gdzie AI pomaga: grupowanie i odduplikowanie zgłoszeń, wskazywanie plików o ryzykownej historii zmian, podpowiadanie, które testy regresji uruchomić po konkretnej zmianie w kodzie.
Gdzie AI nie zastąpi zespołu: ocena wpływu biznesowego, wymogi prawne i wiedza, że w przyszłym miesiącu rusza kampania, która podwoi ruch w koszyku.
Gdzie AI samo jest ryzykiem: funkcje oparte na modelach językowych trafiają do Waszego produktu i zwykle od razu powinny wejść do górnych 20 procent, bo zachowują się niedeterministycznie.

Zanim kupicie narzędzie, które obiecuje automatyczną analizę ryzyka, przejdźcie listę pytań z tekstu zanim zapłacicie za AI w testowaniu: siedem pytań na Strefie QA. Oszczędza sporo rozczarowań po pierwszym kwartale.

Pięć pułapek, w które wpadają zespoły

Pozostałe 80 procent bez żadnych testów. Juran mówił o licznych użytecznych, nie bezużytecznych. Niski priorytet to mniej testów, nie zero.
Liczenie błędów zamiast ich kosztu. Sto literówek w panelu administracyjnym waży mniej niż jeden błąd w naliczaniu płatności.
Jednorazowa analiza. Badanie Fentona i Ohlssona pokazuje, że skupiska przesuwają się między testami a produkcją. Lista ryzyk sprzed pół roku opisuje produkt sprzed pół roku.
Tylko dane z testów. Testy widzą to, co testowaliście. Incydenty produkcyjne i zgłoszenia użytkowników pokazują to, czego nie testowaliście.
Pareto jako wymówka. „Tego nie testujemy, bo to nie nasze 20 procent” bez zapisanej analizy to zwykłe cięcie zakresu. Decyzja o ryzyku ma być jawna i podpisana przez kogoś, kto za nie odpowiada.

Z naszego doświadczenia najdroższa jest pułapka numer 3. Macierz ryzyka z początku projektu łatwo zamienia się w rozkład jazdy na cały rok: moduł dawno ustabilizowany dalej dostaje testy głębokie, a nowa integracja z dostawcą płatności przechodzi z testem dymnym. Gdy chcecie niezależnego spojrzenia na to, gdzie dziś są Wasze ryzyka, to dokładnie zakres audytu QA, a jego przebieg i koszty rozpisaliśmy w tekście audyt procesów QA: zakres, przebieg, ile to kosztuje.

Od czego zacząć w tym tygodniu

Nie potrzebujecie nowego narzędzia ani zgody zarządu, żeby w tym tygodniu zrobić pierwszy krok:

wyeksportujcie defekty z ostatnich 6 miesięcy i policzcie je po module z podziałem na krytyczność,
dopiszcie obok incydenty z produkcji z tego samego okresu,
na jednym spotkaniu z programistą i właścicielem produktu oceńcie prawdopodobieństwo i wpływ dla 15 do 20 obszarów,
porównajcie wynik z tym, gdzie dziś idzie najwięcej czasu testów, i przesuńcie jedną rzecz w najbliższym sprincie.

Jeśli przesunięcie wymaga zmian w organizacji testów całej firmy, a nie jednego zespołu, to już temat na strategię jakości oprogramowania. Tam, gdzie największym ryzykiem jest długa regresja, pomagamy w ramach testów regresyjnych. A jeśli chcecie, żeby kierownik testów w Waszym zespole robił to sam, zajrzyjcie do programu szkolenia z zarządzania testami oprogramowania albo do kalendarza szkoleń. Ukryty koszt odkładania tej pracy dobrze pokazuje tekst o długu technologicznym.

Co zabrać z tego artykułu

01Zasada Pareto w testowaniu to czwarta zasada z sylabusa ISTQB: defekty się skupiają, a skupiska są wejściem do testowania opartego na ryzyku.

02Badania potwierdzają nierówny rozkład: w pracy Ostranda, Weyuker i Bella 20 procent plików wskazanych przez model zawierało średnio 83 procent defektów.

03Wasze 20 procent się przesuwa. Fenton i Ohlsson pokazali, że moduły najbardziej błędogenne przed wydaniem bywają najspokojniejsze na produkcji.

04Ryzyko projektowe i produktowe to dwie osobne listy. Obie mierzy się prawdopodobieństwem i wpływem.

05Liczy się koszt błędu, nie liczba zgłoszeń: 80 procent pracy poprawkowej pochodzi z 20 procent defektów.

06Niski priorytet oznacza mniej testów, a nie brak testów. Decyzję o ryzyku zapisujcie i wracajcie do niej po każdym wydaniu.

Chcecie sprawdzić, czy Wasze testy chronią dziś właściwe 20 procent? W audycie QA mapujemy ryzyka produktu i pokazujemy, gdzie czas testów daje najwięcej ochrony.

Sprawdźmy szczegóły