Testuj albo giń – kilka słów o błędach

Paweł Krysiak | Quality Assurance | 18 września 2019

Wiemy, dlaczego błędy w oprogramowaniu powstają i jak – nieraz katastrofalne – mogą mieć skutki. Wiemy również, że w świecie pełnym wymagających użytkowników i milionów konkurujących o ich uwagę aplikacji jakość to klucz do sukcesu. W dzisiejszym artykule nie odpowiem na pytanie, jak unikać błędów – to temat na osobny artykuł. Chciałbym jednak napisać kilka słów o błędach i o tym, dlaczego kontrola jakości to absolutna podstawa.

Lokalny koszt błędów

Jakie mogą być lokalne koszty błędów oprogramowania? Dla przykładu, w sierpniu 2017 roku firma Provident Financial straciła w ciągu jednego dnia ponad półtora miliarda funtów (dokładnie: 1,7) na giełdzie po tym, jak jej prezes oznajmił, że ich nowa aplikacja była w stanie zebrać tylko 57% długów na czas (spadek z 90%). Sam prezes zrezygnował ze swojej funkcji, a system, który kosztował 21 milionów funtów, przyniósł roczną stratę na poziomie 120 milionów funtów.

Należy zauważyć, że błędy w oprogramowaniu to nie tylko straty finansowe i wizerunkowe, ale również w skrajnych przypadkach zagrożenie dla ludzi. I chodzi zarówno o zagrożenie zdrowia, jak i nawet życia. W 2017 roku z powodu błędu w oprogramowaniu singapurskiego metra dwa pociągi zderzyły się, powodując urazy u 38 ludzi. W sierpniu 2009 roku miała miejsce awaria, w wyniku której samochód Lexus ES350 zaczął sam przyspieszać do ponad 160 km/godz. i rozbił się, zabijając czterech pasażerów. To zdarzenie również było wywołane błędem w oprogramowaniu, a konkretnie – w oprogramowaniu systemu ABS. Akcja naprawcza w koncernie Toyota to koszt szacowany na 3 miliardy dolarów. 

Przeczytaj także:

Dlaczego testy oprogramowania są ważne

Testy BDD – czy są na prawdę potrzebne?

Testuj lbo giń

Firma Tricentris analizuje anglojęzyczne doniesienia prasowe o błędach, wyciekach danych i innych nieprawidłowościach związanych z działaniem oprogramowania i na tej podstawie estymuje ich koszty i zasięg, a następnie przedstawia wyniki analizy w corocznym raporcie. Najnowszy pochodzi z 2017 r. i skupię się na kilku liczbach, które możemy w nim znaleźć. Zachęcam jednak do zapoznania się z całością, bo sam raport jest dosyć prostą w odbiorze lekturą.

Raport podsumowuje 606 różnych błędów (ponad 1,5 błędu dziennie), które dotknęły 314 firm i 3 683 212 665 (trzy miliardy sześćset osiemdziesiąt trzy miliony dwieście dwanaście tysięcy sześćset sześćdziesiąt pięciu) użytkowników, czyli około połowę populacji Ziemi. Naprawdę imponującą liczbą jest jednak oszacowany koszt tych wszystkich błędów. Wynosi on… 1 715 430 778 504 (bilion siedemset piętnaście miliardów czterysta trzydzieści milionów siedemset siedemdziesiąt osiem tysięcy pięćset cztery) dolary.

Tak duże liczby trudno sobie wyobrazić, więc dodam, że jest to ponad trzykrotność polskiego PKB w 2018 r. To kwota, za jaką można by kupić 94 mln Volkswagenów Golfów, czyli ponad 2 dla każdego Polaka.

Testuj albo giń

Czym jest błąd i co może powodować?

Co możemy nazwać błędem? Odpowiedź według mnie najprostsza brzmi: każde zachowanie oprogramowania inne niż zakładane jest błędem. ISTQB, czyli International Software Testing Qualifications Board, rozróżnia te zachowania na: defekty, awarie i błędy. W swojej zawodowej karierze nie spotkałem nikogo, kto nie używałby tych pojęć zamiennie. Jeżeli jesteście zainteresowani tym podziałem, to można go znaleźć w sylabusie ISTQB poziomu podstawowego w rozdziale pierwszym. A jakie mogą być skutki błędów? Jak wynika z mojej prostej definicji: ciężko przewidzieć. Pisząc bardzo ogólnie, błędy mogą powodować utratę czasu, pieniędzy, reputacji, a nawet – jak w przypadku podanych przykładów metra i koncernu Toyota – zdrowia i życia użytkowników oprogramowania.

Skąd się biorą błędy?

Niektóre awarie oprogramowania mogą powstawać wskutek przyczyn niezależnych od nas. Mam na myśli sytuacje, w których np. wyładowania atmosferyczne czy promieniowanie powodują wadliwe funkcjonowanie sprzętu, co może (ale nie musi) powodować błędy w działaniu oprogramowania. Wspomniane sytuacje najczęściej dotyczą oprogramowania wbudowanego czy IoT, a przed błędami wywołanymi czynnikami zewnętrznymi trudno się obronić.

Na potrzeby artykułu skupiam się na błędach w oprogramowaniu, których wystąpienie zależy od kultury organizacji oraz poziomu procesu wytwórczego, w którym istotną rolę odgrywają kompetencje testerów, programistów, analityków itd. Błędy w oprogramowaniu pojawiają się, ponieważ ludzie nie są nieomylni, a oprogramowanie – jest skomplikowane. Nie pomaga także to, że powstaje ono w wielu etapach i jest tworzone przez zespoły złożone z wielu specjalistów z różnych dziedzin. Nieporozumienia, niedopowiedzenia, presja czasu i zwyczajne ludzkie zmęczenie to kolejne czynniki, które mogą powodować powstawanie błędów w tworzonym oprogramowaniu. Ostatnią podstawową przyczyną jest  poziom skomplikowania kodu oraz jego ilość. Wszystko to są przyczyny, które można zniwelować w obrębie zespołu i procesu.  

Kiedy powstają błędy?

Według raportu firmy Infostrech 56% błędów pojawia się bezpośrednio na etapie definiowania wymagań, 27% na etapie projektowania gotowych rozwiązań, a tylko pozostałe 17% – podczas samej implementacji i wdrożenia aplikacji. Jak widać, błędy w oprogramowaniu pojawiają się szybciej niż samo oprogramowanie. Wynika to poniekąd z prostego faktu, że źle wymyślona i zaprojektowana funkcjonalność, zawierająca np. błędy logiczne, jest niemożliwa do zaimplementowania poprawnie, a kontrola jakości odbywa się zazwyczaj po powstaniu gotowego kodu. Jest to sytuacja na tyle niekorzystna, że wielu ludzi na wielu etapach pracuje na podstawie danych i założeń zawierających błędy, co jest przyczyną utraty dużej ilości czasu i pieniędzy. Jeżeli dodamy do tego proces naprawy błędów, to dochodzi kolejny koszt dla naszej organizacji. O tym, jak duży on może być, pisałem we wcześniejszej części artykułu.

Jaki jest dzisiejszy użytkownik?

Dlaczego powinniśmy się tym wszystkim przejmować? Przecież oprogramowanie powstaje od lat i do tej pory jakoś sobie radziliśmy z faktem, że nie jest wolne od błędów. Problem w tym, że w obecnych czasach powstaje ogromna ilość oprogramowania, kolejne aspekty naszego życia opierają się na działaniu programów używanych przez nas (świadomie lub nie) każdego dnia i w zasadzie do życia niezbędnych (wyobraźmy sobie działanie gospodarki bez oprogramowania!). Użytkownicy są coraz bardziej wybredni, świadomi i niecierpliwi, a konkurencja – większa niż kiedykolwiek. Nawet mało istotne błędy mogą skłonić użytkownika do zmiany systemu czy aplikacji na inną, wolną od błędów lub działającą szybciej. Dla twórcy to koszt zarówno finansowy, jak i wizerunkowy, a odzyskanie zaufania użytkownika jest niezwykle trudne.

Dlaczego kontrola jakości jest tak ważna?

Chęć ominięcia testowania i unikania kosztów z nim związanych często jest argumentowana tym, że przecież programiści piszą kod wysokiej jakości i nie trzeba testów, bo nie powinno być błędów. Jak starałem się pokazać na przytoczonych przykładach, nie jest to prawda. Nikt z nas na co dzień nie podważa potrzeby przeprowadzania kontroli jakości, twierdząc, że przecież zdolni inżynierowie poprawnie zaprojektowali wszystkie elementy, a w fabryce wszyscy pracują dobrze. Zapewne nikt z nas nie wsiadłby za kierownicę samochodu, jeżeli nie byłaby uprzednio przeprowadzana kontrola jakości na każdym etapie jego produkcji.

Podsumowanie

W moim artykule podałem przykłady z życia, które dowodzą, jak ważna jest kontrola jakości i ciągła praca nad nią. Podobne argumenty powinniśmy brać pod uwagę w przypadku testów oprogramowania, gdyż ono także często odpowiada za prawidłowe funkcjonowanie systemów niezbędnych w naszym codziennym życiu. Chciałbym, aby ten tekst przyczynił się do dalszej dyskusji na temat błędów oraz minimalizacji kosztów ich naprawy. W kolejnych wpisach postaram się szerzej przedstawić te zagadnienia.

Przeczytaj także: Testerze, eksploruj

Autorem wpisu jest:

Tester

Od dwóch lat związany z JCommerce jako tester oprogramowania. Prywatnie miłośnik kina i piwnej rewolucji. Uważa, że testowanie to sztuka zadawania odpowiednich pytań, a zapobieganie błędom jest ważniejsze niż ich szukanie.

Dodaj komentarz: