Recenzja na SJSI

Na stronach SJSI pojawiła się moja recenzja książki "Teoria i praktyka testowania programów". Jest to dokładanie ta sama recenzja, którą można przeczytać na tym blogu (tutaj).

Ranking defektów

Postanowiłem dzisiaj sprawdzić czy da się znaleźć w Internecie listę lub ranking najbardziej ciekawych defektów. Niestety nic takiego nie znalazłem, ale przyszło mi do głowy, że można by taką listę dzielić na kilka kategorii. Oto te które przyszły mi do głowy (oczywiście chodzi o defekty zaraportowane):

• nieistniejący defekt
• defekt związany z czasem
• UI defekt
• najgroźniejszy defekt (showstoppers)
  
• nic nie znaczący defekt
• defekt bezpieczeństwa
• najgłupszy defekt
• najtrudniejszy defekt do znalezienia
• znaleziony, nienaprawiony defekt

Może ktoś ma więcej pomysłów...

Szara skrzynka pełna plusów i minusów

Termin "szara skrzynka" pojawia się mniej lub bardziej formalnie na stronach książek, w internecie lub pismach branżowych. Z moich obserwacji nie istnieje żadna zestandaryzowana definicja tej techniki. To bardzo dobrze! Dla mnie oznacza to mniej więcej następujący proces:

1. Analiza dostępnej dokumentacji i danych historycznych (jeśli istnieją)
   Wszelka dokumentacja zaczynając od wymagań, poprzez dokumenty techniczne a na rozmowach z architektami kończąc.
   Jeśli jest to kolejna wersja systemu lub projekt integracyjny to nie powinno być problemów z uzyskaniem takich danych. W przypadku nowego projektu, warto jest poczytać o podobnych rozwiązaniach.
   
   
2. Weryfikacja statusu implementacji rozwiązania
   Jeśli faza kodowania jest bardzo wczesna to nie ma nawet sensu zaglądać do kodu bo zmieni się on jeszcze wiele razy. Warto natomiast obserwować rewizje komitowane do systemu kontroli wersji... mówi to bardzo dużo o łatwych i trudnych implementacyjnie obszarach
   
   
3. "Przejście" po kodzie i zidentyfikowanie fragmentów ryzykownych
   Na tym etapie - jeśli oczywiście kod jest wystarczająco "dojrzały" - wystarczy po prostu przeglądać go i identyfikować takie elementy jak: "duże" w sensie linii kodu funkcje, nieuporządkowane fragmenty (gdzie stosuje się np. różne konwencje standardu kodowania), "dużo" wykomentowanego kodu, "dziwne" nazwy zmiennych, wartości wpisywane na stałe (tzw. hardkodowanie), itp. (Warto jest utrzymywać plik z listą kontrolną takich "gadżetów").
   
   
4. Porównanie znalezisk z wymaganiami
   Należy dokładnie wiedzieć, jakich funkcjonalności dotyczą potencjalnie niebezpieczne obszary i w jaki sposób widoczne są w "runtime".
   
   
5. Pierwsze podejście do testów - plan ogólny
   Spisanie sobie ogólnego planu zawierającego także wstępną listę przypadków testowych
   
   
6. Analiza dokumentów z procesu produkcji oprogramowania
   Chodzi tutaj generalnie o analizę raportów z testów jednostkowych, inspekcji kodu, jak również obserwację częstotliwości komitów do repozytorium.
   
   
7. Uszczegółowienie planu testów
   Dopisanie brakujących przypadków testowych.
   
   
8. Dokładna analiza "trudnych" fragmentów
   Ten etap znajduje zastosowanie przeważnie w kolejnych cyklach testowania, kiedy okazuje się, że klasyczne podejście do testów jest niewystarczające. Chodzi o zidentyfikowanie - na podstawie defektów - obszarów najbardziej "zarobaczonych" i przyjrzenie się sposobowi w jaki jest on zaimplementowany w kodzie. Następnie należy zaprojektować przypadki testowe odpowiadającemu zastanemu stanowi. Najczęściej oznacza to duże obłożenie warunków brzegowych oraz zagęszczanie klas równoważności.
   
   
9. Ponowne uszczegółowienie planu testów
   

Tak naprawdę to dotarcie do punktu nr. 5 daje bardzo duże efekty. Ale np. korzystanie z takiej dokumentacji jak raporty z testów jednostkowych lub protokoły z inspekcji kodu nadwyraz wydajnie pozwalają sprytnemu testerowi identyfikować groźne obszary (ale to temat na całą książkę) i wcale nie muszą być wykorzystywane w sekwencji przedstawionej powyżej.

Zastanawiając się na wadami i zaletami takiego podejścia, następujące punkty przyszły mi do głowy:

Plusy

1. Testowanie czarną skrzynką opiera się na domniemaniu, że kod napisany jest zgodnie z zasadami inżynierii oprogramowania a praktyka pokazuje, że tak jest często ale nie zawsze i nie w pełnym zakresie.
   
   
2. Termin "inżynieria oprogramowania" nie oznacza z punktu widzenia testów absolutnie nic. Przysłowiowe "Hello world" może być zakodowane w jednym języku na milion sposobów i każdy z nich będzie spełniał różne wymagania co pociąga za sobą różne podejścia przy projektowaniu testów.
   
   
3. Analiza kodu pozwala na identyfikację potencjalnie ryzykownych miejsc. Oczywiście ma to swoje ograniczenia. W przypadku systemów czasu rzeczywistego nie zidentyfikuje się w ten sposób defektów związanych z zależnościami czasowymi ale na pewno pozwoli zaoszczędzić czas na "walcowaniu" całości poprzez większy nacisk na miejsca ryzykowne.
   
   
4. Pozwoli inżynierowi do spraw testów zrozumieć architekturę samego rozwiązania (z mojego doświadczenia wynika, iż wewnętrzne szkolenia poświęcone implementowanej architekturze są naprawdę rzadkością!?) co w sposób znakomity usprawnia proces projektowania testów poprzez uprzednie dostarczenie wiedzy na temat wysokopoziomowej struktury testowanego rozwiązania.
   
   
5. Nie ma konieczności czytania całego kodu. Ponieważ nie sprawdzamy poprawności działania każdej struktury/obiektu/klasy czy usługi. Na potrzeby testów behawioralnych potrzebne są nam fragmenty przetwarzające logikę biznesową.
   
   
6. W sytuacji gdy zmuszeni jesteśmy zatrudniać ludzi, którzy testowanie widzą jedynie jako etap pozwalający przejść do programowania, może być to doskonałe narzędzie do wykorzystania ich potencjału jak również motywowania.
   
   
7. Eliminuje ryzyko testowania rozwiązania wbrew jego logice. To znaczy gdy nasze przypuszczenia co do implementacji są drastyczne różne od założeń implementatora. To ryzyko może być groźne w sytuacji kiedy mamy czas tylko na pobieżne testy w celu określenia jak bardzo jest dany obszar niebezpieczny. Po testach dymnych może wyglądać, że rozwiązanie działa dobrze a w środowisku rzeczywistym pojawi się katastrofa.
   

Minusy

1. Praca nad kodem może łatwo przerodzić się w zabawę z kodem trwającą bez końca. Może to prowadzić do kompletnej indolencji testowej przy jednoczesnym ogromnym obłożeniu zespołu pracą
   
   
2. Kod bardzo często jest w postaci sote a wiec bez komentarzy. Dodatkowo, jeśli w danym środowisku wykorzystuje się komponenty dostawców zewnętrznych, komponenty generyczne lub inne kompleksy integrowane, których implementacja poprzez interfejs jest skomplikowana to czytanie takiego kodu staje się niemożliwe bez głębszej wiedzy.
   Ten problem jest częściowo niwelowany przez "Plus" nr. 5
   
   
3. Osoby zatrudniane na stanowisko testera często nie posiadają kompetencji rozumienia kodu - "bo przecież nie potrzeba". Ale zawsze w zespole testowym znajdzie się osoba, która trochę programowała lub ma zacięcie w tym kierunku. Należy to wykorzystać, zlecając jej analizę kodu pod względem identyfikacji potencjalnych ryzyk. Czasami wystarczą pobieżne oględziny i odrazu widać miejsca, z którymi programista strasznie ciężko walczył. Pomocą tutaj mogą być raporty z przeglądu kodu - jeśli takie praktyki są prowadzone.
   
   
4. Rozpoczęcie projektowania testów jest możliwe tylko gdy faza kodowania jest mocno rozwinięta i można korzystać zarówno z kodu jak i z raportu o zmianach wersji (co często bywa pomocne przy identyfikowaniu "kłopotliwych" obszarów).
   
   
5. Istotnym ograniczenie jest znajomość języków. Jeśli trafimy na projekt napisany w zupełnie obcej nam technologii to nie jesteśmy w stanie efektywnie korzystać z tej techniki.

Powyższy opis procesu nie stanowi całości ale to chyba punkty, które mnie najbardziej interesują i których usystematyzowania odczuwałem potrzebę.

Słownik testowy

Kiedyś na starych stronach SJSI dostępny był słownik testowy. Wersja, do której się odnoszę nosiła numer 1.0. Zaskoczyło mnie w niej, że brakuje polskiego tłumaczenia definicji takich angielskich terminów jak "pass/fail", "evaluate", "valid/invalid", "input", "release notes" czy "severity". A przecież są to zupełnie podstawowe terminy z dziedziny testowania. Ale nawet przy tych brakach było on bardzo pomocny! Ciekawe dlaczego został zdjęty?

Lektura obowązkowa czyli o praktykach teoretycznych

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.

TiddlyWiki - notes i encyklopedia

Od dawna brakowało mi narzędzia do zarządzania notatkami. Typowe pliki tekstowe nie są zbyt atrakcyjne zwłaszcza gdy mówimy o kategoryzowaniu (a przecież drzewo kategorii nigdy nie jest zafiksowane).

A dzisiaj chyba znalazłem odpowiedź. Narzędzie nazywa się TiddlyWiki (http://www.tiddlywiki.com/) i działa tak jak system "Wiki" włącznie z tagowaniem. Wykonałem dzisiaj parę prób i naprawdę zapowiada się super tym bardziej, że jest to po prostu plik w JavaScripcie więc można go sobie zmodyfikować do własnych potrzeb.

Pomoc do tego narzędzia (nie jest wcale fantastyczna ale na początek wystarczy) znajduje się na stronach http://danielbaird.com/tiddlywikiguides/userguide-sample.html.