Redakcja
Zasada 4 - Kumulowanie się błędów
Pracochłonność testowania jest dzielona proporcjonalnie do spodziewanej oraz zaobserwowanej gęstości błędów w modułach. Niewielka liczba modułów zwykle zawiera większość usterek znalezionych przed wydaniem lub jest odpowiedzialna za większość awarii na produkcji.
Źródło [2]
Jest to swoiste odzwierciedlenie zasady Pareto 80/20, według której 20% kodu będzie przyczyną 80% problemów.
20% of the code will cause 80% of the problems.
Źródło [3]
Znajomość tej zasady może być pomocna podczas planowania testów.
Focusing on defects can help us plan our tests
Reviewing defects and failures in order to improve processes allows us to improve our testing and our requirements, design and development processes. One phenomenon that many testers have observed is that defects tend to cluster. (…) Testers will often use this information when making their risk assessment for planning the tests, and will focus on known 'hot spots'.
Źródło [3]
Powinniśmy zatem wyciągać wnioski z zaobserwowanych defektów i awarii, aby usprawnić proces testowy poprzez bardziej świadomą ocenę ryzyka i skupienie na "gorących punktach" podczas planowania testów.
Uważne monitorowanie i kontrola procesu testowego pozwala na zlokalizowanie "podejrzanych" modułów i przetestowanie ich w pierwszej kolejności. Dzięki temu małym nakładem pracy w szybkim czasie wykryjemy znaczną liczbę usterek.
Źródło [1]
Zasada jednak mówi nie tylko o zaobserwowanej, ale również spodziewanej gęstości błędów, czyli ilości błędów na (K)LOC – ang. (Kilo) Lines Of Code, w modułach. Jak więc możemy wykorzystać wiedzę o kumulowaniu się błędów podczas procesu planowania, zanim w nasze ręce trafi testowany program?
Możemy przewidywać, gdzie wystąpią "klastry błędów" na podstawie wielkości danego modułu i chociaż intuicyjnie wydaje się, że im więcej linii kodu, tym więcej powinno być defektów, to w rzeczywistości najbardziej podejrzane są największe i najmniejsze moduły.
W inżynierii oprogramowania zaobserwowano także inny fenomen – okazuje się, że rozkład gęstości defektów w funkcji rozmiaru modułu jest rozkładem U-kształtnym. Angielska nazwa tego typu krzywej to bathtube curve. (…) w pierwszej kolejności należy zwrócić uwagę na moduły bardzo małe i bardzo duże, gdyż w niech może znajdować się największa liczba defektów.
Źródło [1]
Możemy ponadto wzbogacić wstępną analizę o dane historyczne, by z większym prawdopodobieństwem wyznaczyć moduły podejrzane, a nawet optymalny rozmiar modułu pod kątem gęstości defektów (do którego powinien dążyć zespół developerski).
Oczywiście (…) optymalny rozmiar modułu, będzie zależeć od wielu różnych czynników, takich jak:
- użytego języka programowania;
- typu projektu;
- rodzaju środowiska produkcyjnego;
- umiejętności zespołu deweloperskiego.
Źródło [1]
Jakie mogą być przyczyny kumulowania się błędów i U-kształtnego rozkładu gęstości defektów w funkcji rozmiaru modułu?
This can happen because an area of the code is particularly complex and tricky, or because changing software and other products tends to cause knock-on defects.
Źródło [3]
"Klastry" błędów mogą pojawiać się w szczególnie skomplikowanym kodzie lub być spowodowane zmianami w oprogramowaniu.
Można również spróbować wytłumaczyć zależność U-kształtną, porównując moduły o podobnej funkcjonalności, lecz innej wielkości (strukturze kodu) .
Załóżmy, że mamy rozmiar modułu o określonej gęstości defektów. Im moduł będzie większy, tym więcej będzie okazji do popełnienia błędów, zatem gęstość defektów wzrośnie. Jednocześnie, jeśli rozmiar modułu będzie coraz mniejszy, to – aby utrzymać podobną funkcjonalność – jego wewnętrzna struktura będzie coraz bardziej skomplikowana, co również stwarza więcej okazji do popełnienia błędów.
Źródło [1]
Powstało wiele publikacji opisujących empiryczne badania korelacji ilości błędów w stosunku do złożoności, czy też wielkości modułu oprogramowania. Udowadniają one występowanie zjawiska kumulowania się błędów.
Kończąc, chcę przytoczyć wyniki i spostrzeżenia opisane w trzech publikacjach często cytowanych przy okazji opisywania zjawiska klasteryzacji defektów.
Wyniki pracy Basili & Perricone [4]:
Autorzy stwierdzili kumulowanie się błędów w mniejszych modułach. Było to dla niech zjawisko zaskakujące, które tłumaczyli następująco:
Some tentative explanations for this behavior are that: the majority of the modules examined were small (…), causing a biased result; larger modules were coded with more care than smaller modules because of their size; and errors in smaller modules were more apparent. There may still be numerous undetected errors present within the larger modules since all the "paths" within the larger modules may not have been fully exercised.
Źródło [4]
Wyniki pracy Withrow [5]:
Autorka i współpracownicy zebrali i usystematyzowali wyniki w dużym projekcie, stwierdzając kumulowanie defektów w małych i dużych modułach (na diagramie widać wyraźnie rozkład U-kształtny) oraz wysnuwając hipotezę o istnieniu optymalnego, średniego rozmiaru modułu o najmniejszej gęstości defektów.
Model Malaiya & Denton [6]:
Bazując na wcześniejszych badaniach, autorzy zaproponowali model umożliwiający wyznaczenie optymalnego rozmiaru modułu pod kątem gęstości defektów:
It provides an interpretation for both declining defect density for smaller modules and gradually rising defect density for larger modules. We observe that for several projects, distribution of module sizes is given by an exponential expression. (…) We identify the condition for optimal distribution. A model for characterizing variation of defect density due to module size variation has been obtained which can be used as a sub-model for a multi-factor defect density model.
Źródło [6]
Podsumowując, zjawisko kumulowania się defektów zostało udowodnione i jest już od dawna elementem testerskiego uzusu. Dzięki jego świadomości możemy lepiej planować test, skupiając się na modułach obarczonych największym ryzykiem, przyjmując za nie moduły najmniejsze i największe (gdy bazujemy jedynie na teorii), lub moduły wyznaczone na podstawie modelu i/lub danych historycznych w podobnych projektach.
Pamiętajmy jednak, że istnieją wyjątki od każdej zasady, dlatego też pozostańmy czujni podczas wykonywania testów, aby świadomość częstego występowania "klastrów" defektów nie sprawiła, że przeoczymy pojedyncze bugi.
O autorze
Małgorzata Ciwoniuk
Oprogramowanie testuję od ponad 3 lat. Zaczynałam w software house’ach, gdzie testowałam głównie aplikacje webowe, w mniejszym stopniu desktopowe i mobilne. Obecnie pracuję w Amazon Development Center na stanowisku Quality Assurance Engineer, gdzie mam możliwość testowania wiodących rozwiązań w technologii Text-to-Speech. Ukończyłam Politechnikę oraz Wyższą Szkołę Bankową w Gdańsku. Wierzę, że największą siłą oraz potencjałem branży IT jest gotowość do współpracy i dzielenia się wiedzą.
Opracowanie zostało przygotowane w ramach konkursu zorganizowanego przez organizatorów TestingCup 2018 oraz testerzy.pl.
