Państwowe Wydawnictwo Naukowe wespół z wydawnictwem MIKOM wydało w 2006 książkę "Teoria i praktyka testowania programów" autorstwa Bogdana Wiszniewskiego i Bogdana Berezy-Jarocińskiego. Pozycja wyszła w serii "Biblioteka Programisty".
Wydanie
Wydanie nie zaskakuje niczym szczególnym. Biały papier, naćkany drobną czarną czcionką z wąziutkimi marginesami. Gęsto poszatkowane rozdziały. Na 460 stronach zamieszczono 10 a właściwie 12 rozdziałów plus bibliografia i skorowidz. Całość zamknięta tekturowymi, polakierowanymi okładkami i sklejona jedynie klejem. Standard estetyki poligraficznej na polskim rynku wydawniczym.
Zaskoczyło mnie - chyba nie mile - to, że prace pani Anny Bobkowskiej, pana Łukasza Garsteckiego i pani Magdaleny Sławińskiej zostały niejawnie wplecione do książki. Ale cóż, skoro zgodzili się sami twórcy to rozumiem, że autorzy wymieni pod tytułem książki mieli w tym jakiś cel, który niestety dla mnie pozostanie nieodgadniony.
Co od ilustracji to jakość nie jest porażająca ale nie odbiega od standardu wydania. I chyba dobrze bo jak mniemam oszczędności na jakości pozwoliły - w opinii zarządu wydawnictwa - wydać książkę w przystępnej cenie.
Treść
Właściwie są to dwie książki, których rozdziały zostały poprzekładane! Jedna napisana przez postać znaną mi jako weteran szkoleń o tematyce związanej z inżynierią oprogramowania oraz tłumacz książki Rona Pattona "Testowanie oprogramowania". Druga to napisana bez polotu, przeładowana akademickim żargonem opowieść o tym na ile sposobów można zastosować narzędzie gdb.
Sami autorzy stwierdzają, że książka jest pisana z myślą o "[...] studentach informatyki, którzy zgłębiają zagadnienia jakości [...] zawodowych informatykach [...], planistach przedsięwzięć informatycznych [...], kierownikach projektów". Niestety szkoda, że adresatem nie są ludzie profesjonalnie zajmujący się kontrolą jakości oprogramowania. Nie jestem również przekonany czy znani mi kierownicy projektów mieliby cierpliwość przeczytać ten miks. A ponieważ książka jest skierowana do tak szerokiego grona, efektem ubocznym jest np. autorytatywnie brzmiące zdanie:
"Praktycznie wytworzenie jakiegokolwiek programu bez testowania jest działaniem jałowym, ćwiczeniem wykonywanym na papierze (strona19)."
Z punktu widzenia teorii można się z tym zgodzić. Jednak z punktu widzenia rzeczywistego przedsiębiorstwa testowanie jest taką samą aktywnością jak każda inna i podlega takim samym procesom i prawidłom (przede wszystkim zasadność, celowość i ekonomiczności). Zdanie to zdziwiło mnie w świetle wcześniej przeczytanej definicji głównej przyczyny macoszego traktowania jakości:
"Kontrola jakości - w tym także test - również sporo kosztuje, jednak sama z siebie nie tworzy produktów, za które ktokolwiek jest gotów zapłacić. Właśnie z tego powodu pokusa oszczędzania na testowaniu jest tak silna i tak rozpowszechniona (strona 14)."
... zastrzegając, że w mojej opinii jakość jest tym produktem. To że firmy mają problem z jej mierzeniem (postrzeganiem) to już zupełnie inne zagadnienie. Które zręczni kierownicy testów mogą wykorzystać uwzględniając zasadę, że zmierzone jest to co się mierzy.
Nie zgadzam się także z autorami w kwestii definicji celu testowania. Takich definicji może być wiele natomiast autorzy książki informują tylko o jednym i to w sposób jakby to był cel jedyny.
"Testując, usiłujemy wywołać awarie systemu, aby umożliwić znalezienie i usunięcie powodujących je błędów[...] (strona 14)."
Traktowanie błędu jako wskaźnika jakości nie jest dobrą miarą, kiedy staje się jedyną. Raport z defektu to tylko jeden z produktów testowania.
Rozdział pierwszy książki autorstwa obydwu panów traktuje przekrojowo problematykę procesów i systematyki testów. Na początku następuje ogólnikowy w zamierzeniu opis czynności rozciągający się od konfiguracji środowiska po opis weryfikacji wyników wykonanych testów. Następnie autorzy przechodzą do zgrabnego opisu zasadności i natury procesu w cyklu wytwarzania oprogramowania.
Po opisie modeli kaskadowego, V, W, ewolucyjnego i przyrostowego autorzy przechodzą do budowania świata idealnego, w którym następuje weryfikacja wymagań, projektu i ocena kodu. Następnie wspominają dokładniej o systematykach testów od jednostkowych do akceptacyjnych i od obciążeniowych do funkcjonalnych.
Wszystko to kończą próbą zdefiniowania co to jest defekt oraz opisem modelu testowania, moim zdaniem nie wnoszącego kompletnie nic nowego do prezentowanej treści.
To, czego mi zabrakło to zaprezentowanie kilku wybranych podejść do jakości z omówieniem różnic. Autorzy mogli np. wykorzystać poziomy świadomości organizacyjnej zdefiniowane przez Beizera (którego wymieniają w bibliografii) lub wykazać te różnice opisując różne konteksty testowania (outsourcing, oddzielne zespoły, kontrola i zapewnianie jakości, itd).
Skoro książka jest zaadresowana do studentów, zabrakło mi tutaj informacji o celach i zasadach klasyfikacji defektów czyli tak zwanych taksonomiach.
Nie należy zapominać w tym miejscu o rozdziale "Literatura", który jest bardzo ciekawy i pouczający.
Książka naukowca
Zacznijmy od części trudniejszej autorstwa pana Wiszniewskiego. Szczerze mówiąc dużo nerwów i cierpliwości kosztowało mnie przedzieranie się przez liczne wzory i formuły, których armia studentów będzie musiała nauczyć się na pamięć. Dodatkowo zadanie utrudnione było poprzez - moim zdaniem - nadużywanie terminologii naukowej, ale rozumiem, że celem było uzyskanie jak największej precyzji pojęć!? Dla mnie jednak nazbyt często brzmiało to niejasno.
Na początku autor opisuje liczne modele (działania programu, błędu czy środowiska). Następnie przechodzi do opisu implementacji testu (dodam iż chodzi o testy, które powszechnie nazwalibyśmy testami "białej skrzynki") wykorzystując jako przykład narzędzie gdb. I choć wcześniej książka prezentuje nam modele V i W, w tym miejscu – nie wiem dlaczego – autor postanowił oprzeć się o model kaskadowy!?
Omawiając czarną i białą skrzynkę autor sprawia wrażenie jak by namawiał to generowania jak największej liczby przypadków testowych nie wspominając ani razu jak zarządzać efektywnie tak dużymi zbiorami. Z drugiej strony brakowało mi opisu technik pozwalających minimalizować zasoby procedur testowych.
Wśród zawieruchy słownictwa i wzorów pan Wiszniewski zwraca uwagę na - moim zdaniem - bardzo ważną kwestię kontekstów użycia danych. Jednak nie wiązałbym jej tylko z testami na kodzie – tak jak uczynił autor – ale także w testach behawioralnych.
Na koniec mamy rozdział 8, którego zadaniem jest pokazanie czytelnikom jak wygląda praktyczne zastosowanie omawianych wcześniej problemów. Ten rozdział jest praktycznie w całości napisany przez niejawnych autorów książki wymienionych wyżej w tym tekście.
Książka szkoleniowca
Część napisana przez pana Berezę-Jarocińskiego nie jest przesiąknięta precyzyjnym językiem nauki, co zdecydowanie ułatwia czytanie i jednocześnie nie generuje strat na precyzyjności. Autor stara się opisać różne aspekty projektu informatycznego takie jak różnice pomiędzy zapewnianiem a kontrolowaniem jakości, zarządzanie testowaniem, kierowanie projektem, narzędzia wspierające testerów i kierowników testów. Dosyć szczegółowo opisuje proces planowania testów wraz z opisem ról i organizacji oraz głównych prawideł rządzących zespołem ludzi (nie tylko testerów). Poświęca także, kilkanaście akapitów motywacji testerów, co jest chyba unikalne pośród polskiej literatury fachowej.
Zabrakło mi tutaj informacji o zagrożeniach jakie niesie niedodefiniowanie roli zespołu testów. Owszem autor wspomina tu i tam, że taka lub inna czynność czy odpowiedzialność powinna być jasno zdefiniowana. Ale brakuje mi tutaj wskazówek czysto praktycznych na temat komunikacji z kierownikami projektów czy zarządem, próby wytworzenia własnego systemu kryteriów wypuszczenia produktów, gdy nie istnieją oficjalne, definiowania misji i celów zespołu testowego, itd., itp.
Przy opisie problematyki defektów zabrakło rozróżnienia na defekty i incydenty. Przy zastosowaniu czarnej skrzynki - gdzie źródło problemu często nie jest możliwe do zidentyfikowania - możemy mówić o incydentach, które następnie mogą, ale nie muszą być zaklasyfikowane jako defekty. Trudno jest czasami stwierdzić czy dany symptom jest objawem defektu czy objawem funkcji zaimplementowanej zgodnie z wymaganiami. Konsekwentnie, incydenty powinny podlegać regularnym przeglądom, co z kolei staje się problematyczne w środowiskach wielo-projektowych.
Następnie autor dostarcza nam kilka metryk. Większość z nich jest jednak oparta o defekty, co jak zostało powiedziane wyżej, nie jest jedyną miarą jakości.
Rozdział 9 to opis narzędzi typu CAST. Tutaj wszystko szło dobrze do momentu, gdy zacząłem czytać fragment poświęcony automatyzacji testów. Uderzył mnie fakt, iż najistotniejszy element automatyzacji testów, jakim jest automatyzacja weryfikacji wyników testów została zupełnie pominięta. A to właśnie ten aspekt automatyzacji jest najbardziej zapalny i jednocześnie owocny. To przecież możliwość uzależniania wykonania przypadku TC1a lub TC1b od wyniku wykonania przypadku TC1 daje dopiero potężne narzędzie do ręki analityka testów. Bez takiego wsparcia testy automatyczne to tylko automatyczny generator danych, które następnie i tak muszą być przetworzone ręcznie.
Ostatni rozdział merytoryczny poświęcony jest standardom, normom i certyfikacji. Można się z niego dowiedzieć kilku ciekawych rzeczy na temat konferencji branżowych organizowanych w Polsce i Europie co chyba szczególnie interesujące powinno być dla studentów oraz osób rozpoczynających swoją przygodę z testowaniem oprogramowania.
Uwagi końcowe
Uważam, że ta książka - mimo swych oczywistych wad - jest cenna. Po pierwsze, dlatego że jest jedną z nielicznych. Po drugie, dlatego że napisana została przez polskich autorów uwzględniających polskie realia prowadzenia projektów. A po trzecie, dlatego że napisanie książki o tematyce jakości oprogramowania oraz wydanie jej jest dla mnie symbolem i potwierdzeniem rozwoju tej branży w Polsce.
Książce można oczywiście wiele zarzucić jednak "jak się nie ma, co się lubi to się lubi, co się ma". Być może wśród czytelników znajdzie się ktoś, kto spróbuje napisać to lepiej, przejrzyściej i prościej. Jednak w jakiś tam sposób będzie to zasługa tej właśnie książki.
Brakowało czegoś, co nazwałbym "bardziej przyjaznym interfejsem". Porównując tą pracę do podobnych anglojęzycznych robi mi się smutno. Używanie wzorów powinno być naprawdę uzasadnione, słownictwo powinno ułatwiać a nie utrudniać zrozumienie treści tym bardziej, iż książka traktuje o jakości... jakości odbioru także.
Choć zaciemnia pewne terminy (np. przy opisie technik czarnej skrzynki przez domniemanie zakłada dostęp do kodu (sic!)) i rozmywa znaczenie innych, książkę tę poleciłbym dokładnie temu gronu, do którego zaadresowali ją autorzy. Doświadczonym inżynierom testów radziłbym traktować to jako swojego rodzaju "lekturę obowiązkową" bo "nie wypada" a nie jako źródło nowych i świeżych idei.
