O testowaniu przekrojowo i kompletnie – recenzja książki “Testowanie i jakość oprogramowania”

Testowanie oprogramowania jest tak samo stare jak tworzenie oprogramowania. Pierwotnie sądzono, że po utworzeniu oprogramowania będzie dało się w sposób matematyczny i automatyczny udowodnić jego poprawność (bądź zaprzeczyć), używając logiki Hoare’a i dowodząc formalnie poprawności algorytmu poprzez udowodnienie, że algorytm, jeśli się zakończy, da poprawny wynik oraz, że zawsze się zakończy dla dowolnych danych testowych. Niestety, szybko okazało się to zadanie zbyt skomplikowane i w efekcie nierozstrzygalne. Z czasem inżynieria testowania wyrosła do tak samo skomplikowanej dziedziny wiedzy jak samo tworzenie oprogramowania, a mimo to często traktowana jest po macoszemu. Osoby, których praca polega na testowaniu oprogramowania często nie są traktowane równorzędnie w stosunku do zespołu projektowego, a to właśnie od nich zależy finalna jakość produktu.

Paradoksalnie kontrolę jakości oprogramowania, zwłaszcza w polskich firmach, powierza się osobom początkującym, praktykantom, błędnie uważając, że to przecież tylko klikanie i patrzenie w ekran czy nic się nie popsuło. Takie postępowanie wynika z braku zrozumienia przez kadrę kierowniczą czym jest testowanie oraz jak złożonym zagadnieniem jest zapewnienie jakości. Pamiętajmy, im później wykryty błąd, tym większy koszt jego usunięcia. Tymczasem zachodnie i dorosłe firmy (albo po prostu firmy, które w swojej historii boleśnie się sparzyły na wytworzonym przez siebie oprogramowaniu niskiej jakości), zdając sobie sprawę z wagi jakości oprogramowania, dokonują rzetelnych audytów swoich projektów. Sprawdzają czy spełniają normy ISO 9001, określają poziom dojrzałości procesów według modelu CMMI (Compatibility Maturity Model Integration) czy też inwestują w rozwój pracowników odpowiedzialnych za zapewnienie jakości poprzez certyfikowana szkolenia, jak na przykład ISTQB.

Na własny użytek dzielę książki o inżynierii oprogramowania na dwie kategorie. Jedne to takie, które prezentują coś nowego, coś przełomowego, skupiając się tylko na tym jednym aspekcie, takie jak na przykład “GoF” czy “Clean Code” Roberta C. Martin’a. Druga kategoria to książki zbierające całą wiedzę z danej dziedziny i prezentujące aktualny, kompletny zakres wiedzy na obecną chwilę. Książka autorstwa Adama Romana “Testowanie i jakość oprogramowania” z podtytułem “Modele, techniki, narzędzia” wydana przez Wydawnictwo Naukowe PWN należy zdecydowanie do tej drugiej kategorii. To kompendium wiedzy z zakresu testowania. Wskazuje na to już sama objętość – przeszło tysiąc stron. Oznacza to, że mamy kontakt z naprawdę olbrzymią ilością wiedzy z zakresu testowania oprogramowania. Ale nie tylko.

Autor dotrzymał słowa danego w podtytule, opisując szeroko dostępne modele i narzędzia. Jako pracownik naukowy wydziału Matematyki Dyskretnej Instytutu Informatyki Uniwersytety Jagiellońskiego nie jest jednak suchym teoretykiem, ale swoją książkę bogato ilustruje przykładami. To, że Adam Roman jest pracownikiem naukowym jest momentami dosyć mocno widoczne. Użyty język jest bardzo ścisły, rozpoczęcie jakiegoś tematu wiąże się z podaniem formalnej definicji (aż się boję, że dalej pójdzie jak to na wykładach twierdzenie i dowód twierdzenia). Są fragmenty, a jest ich sporo, gdzie autor nie stroni od podania matematycznych wzorów. Dlatego czytając “Testowanie i jakość oprogramowania”, dobrze jest mieć matematyczne podstawy na poziomie uniwersyteckim. Jeśli komuś tej wiedzy brakuje, na końcu książki jest stosowny dodatek, który opiszę niżej.

Merytoryczna zawartość tej pozycji jest spójna, logiczna i podzielona na 7 większych tematów. Początek to oczywiście podstawy z teorii testowania oraz potrzebne definicje. Kolejno mamy opis i charakterystykę metod testowania z uwzględnieniem technik oraz wiedzy jaką posiadamy (biało-skrzynkowe / czarno-skrzynkowe). Następna część to charakterystyka technik projektowania testów w zależności od tego, co chcemy osiągnąć i nad czym się skupić.

W dalszej części mamy opis formalnych dokumentów związanych z zapewnieniem jakości. Z dokumentami miałem problem. Nigdy nie widziałem projektu, który by miał aż tak sformalizowany i tak udokumentowany aparat testowania jak opisane to zostało w tej książce. Wiedząc, że mam za sobą ileś naście lat pracy jako inżynier programista oraz kolejne lata jako project manager, udałem się do osoby, która ma naście lat doświadczenia w testowaniu. Dowiedziałem się, że opisane dokumenty czasem, w niektórych przypadkach faktycznie się tworzy. Są to przypadki kiedy jakość jest krytyczna (na przykład testowanie zaawansowanych systemów medycznych), dlatego przytoczone typy dokumentacji związanej z testowaniem należy traktować w kategorii – czasem robi się aż tak formalnie. W większości projektów, przy których pracowałem tak złożonej dokumentacji do testów nie widziałem.

Idąc dalej, w dalszej części książki “Testowanie i jakość oprogramowania” mamy zarządzanie projektem w pigułce, bo mamy tutaj opis pracy z zespołem, narzędzia oraz coś co jest nierozerwalnie związane z prowadzeniem projektów, czyli ciągły proces doskonalenia i optymalizacji procesu, na przykładzie testowania.

Ostatni, spory rozdział jest wyzwaniem dla osób o słabszym tle matematycznym i w zasadzie według mnie jest przeznaczony bardziej do celów naukowych niż praktycznych, a są tutaj opisane w sposób formalny wszystkie znane metryki dotyczące prawdopodobieństwa wystąpienia awarii, złożoności kodu itd. Jednym słowem, bez dobrej znajomości analizy matematycznej nawet nie podchodź. Ale od czego mamy dodatki na końcu książki.

Teraz nadmienione już dodatki, które znajdziecie na końcu książki “Testowanie i jakość oprogramowania”. Pierwszy to informacja o istniejących normach ISO. Drugi zawiera spis organizacji zajmujących się poszerzaniem wiedzy z zakresu testowania wraz z listą dostępnych na dzień dzisiejszy rozpoznawanych na rynku certyfikatów dla testerów. Ostatni dodatek, o którym wspomniałem wcześniej, to skrócony wstęp do matematyki, co wyraźnie widać – napisany przez osobę o matematycznym zacięciu, obejmujący również podstawową wiedzę z zakresu algebry, teorii mnogości, żywcem wyjętą z książek Kuratowskiego. Jest też krótkie przypomnienie analizy matematycznej. Ten matematyczny dodatek, tak jak pisałem, ma w zamyśle autora pomóc czytelnikowi, któremu brakuje podstaw z matematyki na poziomie uniwersyteckim. Na szczęście tylko do poziomu wymaganego przez zaprezentowany materiał.

Nie ma wiedzy bardziej zaawansowanej, która nie znalazłaby potrzeby w postaci zaprezentowanych formalizmów matematycznych. I tak, jeśli chodzi o analizę matematyczną są omówione pochodne i całki, nie ma równań różniczkowych, jeśli wcześniej pisałem o algebrze i teorii mnogości, to jest pojęcie relacji, iloczynu kartezjańskiego, ale autor darował sobie wykład z topologii, bo do zaprezentowanego materiału nie jest do niczego potrzebna. Jest również trochę statystyki, w tym rozkłady niebędące rozkładami normalnymi.

Jedyne czego osobiście żałuję, autor trochę po macoszemu podszedł do tematu długu technologicznego. Mnie ten temat jest szczególnie bliski w związku z własnymi doświadczeniami, które mam, z drugiej strony, wydaje się oczywiste, że zjawisko nadmiernego długu technologicznego jest dosyć ściśle związane z jakością.

Podsumowując, początkujący tester po lekturze książki “Testowanie i jakość oprogramowania” szybko zdobędzie wiedzę, którą nabywa się latami. Osoby chcące przygotować się do egzaminu ISTQB śmiało będą mogły planować zdobycie certyfikatu. Ogromnym atutem tej pozycji jest również to, że jest ona doskonałym źródłem wiedzy nie tylko dla testerów. Książkę polecam także początkującym kierownikom projektów. Praktycznie znajdziemy tu całość zaprezentowanej wiedzy z zakresu zarządzania projektami. Dotyczy to budowania zespołów, rozwoju ludzi, szkolenia ich, ustawiania indywidualnych celów, pracy grupowej, oszacowania kosztu prac, wprowadzania zmian itd.

Szczególnie polecam “Testowanie i jakość oprogramowania” wyższej kadrze kierowniczej IT celem głębszego zrozumienia czym jest testowanie, jakość produktu oraz w celu zrozumienia, że w dłuższej perspektywie testowanie jest opłacalne. Na pierwszy rzut oka testowanie nie wnosi żadnej wartości dodanej do produktu. Wręcz przeciwnie, może się wydawać, że stanowi tylko koszt, bo przecież produkt nie zmienia się w sposób widoczny, a ponoszone koszty są znaczne. I nie chodzi o sam koszt wykrycia usterki, ale dodatkowo koszt jej naprawienia. Tutaj autor powołuje się na rezultat badań J. Jurana – im wyższe poniesione koszty kontroli, tym niższe koszty wynikające później z awarii. Finalnie, z punktu widzenia klienta, pozytywne zaskoczenie niższym kosztem produktu, zostaje szybko wyparte przez negatywne i dłużej trwające zaskoczenie spowodowane niską jakością.