Cześć! Uczysz się testowania? Na pewno nie raz spotkałeś się z pojęciem „kumulowania się błędów”. Wiesz zapewne, że jest to jedna z siedmiu zasad testowania oprogramowania. Ciekawi mnie natomiast, czy rozumiesz jego znaczenie?
W moim odczuciu ta właśnie zasada testowania jest jedną z tych formułek, które na sucho brzmią przerażająco dla osób zaczynających. Wiem to, bo niejednemu kursantowi musiałem ją wytłumaczyć. Wpisem tym spróbuję ją uprościć tak, byś po przeczytaniu bez problemu mógł wyjaśnić, o co w niej chodzi 😉.
Przygotowałem wersję mp3 tego wpisu. Nie jest to słowo w słowo czytanie a opowiedzenie tego samego tematu.
Kumulowanie się błędów – w internecie przeczytasz
„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.
lub
Jest to swoiste odzwierciedlenie zasady Pareto 80/20, według której 20% kodu będzie przyczyną 80% problemów.
Fragment ten pochodzi z fajnego wpisu: https://testerzy.pl/baza-wiedzy/kumulowanie-sie-defektow-jest-mozliwe-i-mozna-to-udowodnic
20% of the code will cause 80% of the problems.
Pewnie w tym momencie się trochę przestraszyłeś, bo brzmi to skomplikowanie. Nie ma się czego bać!
W zrozumieniu tej zasady testowania i jak do niej podejść pomoże prosta analogia. Wyobraź sobie, że w tym konkretnym przypadku nasza aplikacja jest drogą, którą podróżujesz na co dzień. Dodatkowo załóżmy, że droga ta jest długa i prosta.
Zadaj sobie teraz bardzo ważne pytanie: Czy trudno o wypadek na drodze prostej?
Odpowiedź brzmi oczywiście, to zależy (bo jak wiesz w testowaniu, na wiele pytań odpowiedź zaczniesz od „to zależy”). Uwzględnić należy bowiem podłoża, widoczność, pogodę i inne rzeczy. Natomiast załóżmy warunki idealne do jazdy. W takim wypadku szansa na wypadek jest raczej nikła.
Teraz zadaj sobie pytanie: A co jeżeli dołożymy do tej drogi ruchliwe skrzyżowanie albo rondo?
Tak masz rację! Szanse na wypadek rosną. Dodanie ruchliwego skrzyżowania komplikuje trasę do pracy.
Wróćmy do aplikacji, która czasami jest dokładnie jak ta droga do pracy. Jeśli jest prosta i bezproblemowa, to w takim wypadku zapewne możesz spodziewać się, że w danym module/obszarze aplikacji nie będzie większych problemów.
Natomiast są elementy aplikacji bardzo zawiłe i skomplikowane. Takie, których działanie trudno zrozumieć, co za tym idzie, ciężko jest przewidzieć, jak ma ona działać. To jest dokładnie ten fragment aplikacji, który może powodować kumulowanie się błędów. Istnieje bowiem duże prawdopodobieństwo, że poza Tobą, również i programista miał problem ze zrozumieniem działania aplikacji. Co za tym idzie, błędy w tym miejscu oprogramowania mogą się kumulować bardziej niż tam, gdzie zasada działania jest prosta i zrozumiała dla wszystkich.
To oczywiście duże uproszczenie, bo czynników wpływających na jakość aplikacji jest więcej i oczywiście mogą one sprawić, że Twoje odczucia będą ewoluować. No właśnie! Dobrze widzisz, Twoje odczucia, bo jeżeli chodzi o kumulowanie się błędów to nie tylko kwestia skomplikowania aplikacji, ale też innych czynników, jakie występują. Przykładem może być tak zwane „Spaghetti kodu”, ale czynników może być znacznie więcej. Czasami mamy taką presję czasu, że musimy zaimplementować możliwie jak najszybciej dane zadanie i robimy to tak, aby działało. Działało to słowo klucz, ponieważ wówczas nie dbamy o jakość kodu. Przyjmuje się, że kiedyś temat wyprostujemy – jednak często się to nie dzieje. W takich przypadkach nasza aplikacja potrafi generować dodatkowe błędy ze względu na słabą jakość kodu (wracając do analogii z drogą, w tym wypadku jest ona dziurawa i można koło na niej stracić).
