Jestem osobą, której trudno jest się oprzeć pokusie generalizowania. Pewnie dlatego, że kiedy to robię to mam poczucie, że sięgam wzrokiem dalej od innych i potrafię dostrzec wzorce i prawidłowości przed innymi ukryte. Ta przyjemność jest jednak obarczona dużym ryzykiem, bo właściwie dla każdej generalizacji można znaleźć jakiś kontrprzykład, który ją podważa.
Jednak nie oprę się tej pokusie i pozwolę sobie na pewną syntezę, wyniki której użyję później do oceny książki.
Otóż – moim zdaniem -w książkach i artykułów o testowaniu i jakości można zaobserwować 2 szkoły myśli. Pierwsza mówi, iż jest dokładnie wiadomo co trzeba zrobić, żeby testować dobrze. Wierzy, że można a priori określić dokładnie jakie czynności należy wykonać, stworzyć odpowiednie formalizmy i jedyne czego potrzeba aby projekt informatyczny zakończył się sukcesem to ścisłe trzymanie się tych wytycznych. Fakt, iż wciąż jest tyle nieudanych projektów, tłumaczy się tym, że natura ludzka jest „niedoskonała i grzeszna”. Najlepszym rozwiązaniem jest więc praca nad tą ułomną naturą, i dokładanie wszelkich starań, aby jednak trzymać się istniejących wytycznych.
Druga szkoła opiera się na założeniu, że skoro natura ludzka od początku świata konsekwentnie była i jest ułomna, to pewnie jeszcze przez długi czas taka pozostanie. I może ta ułomność nie jest wynikiem marności rodzaju ludzkiego, ale bezpośrednią konsekwencją tego w jaki sposób jesteśmy skonstruowani i jak funkcjonujemy. W związku z tym, zamiast walczyć z tym, że ludzie są ludźmi, szkoła ta proponuje aby fakt, iż testowanie jest wykonywane przez ludzi był jednym z podstawowych czynników determinującym sposób testowania. Nie sprowadza się to do obniżenia oczekiwań. Polega raczej na takim zorganizowaniu procesu testowania aby do maksimum wykorzystać fakt, że jest ono wykonywane przez ludzi. Chodzi o wdrożenie zasady Drucker’a z jego świetnej książki “The effective executive” – “Build on strengths, not on weaknesses”. Trudno mi to zwięźle przetłumaczyć. Rzecz sprowadza się do tego, żeby przy organizacji pracy, unikać modelu, w którym identyfikujemy zespół cech potrzebnych do wykonywania danego zadania i potem wymagamy od ludzi tych cech. Zamiast tego, należy wziąć pod uwagę to w czym są dobre jednostki, z którymi pracujemy i tak zorganizować pracę aby do maksimum wykorzystać ich zalety. Człowiek w wielu dziedzinach, wciąż góruje nad maszyną. Więc zamiast na siłę robić z niego maszynę, lepiej jest skupić się na wykorzystaniu jego przewag.
Kaner jest jedną z czołowym postaci tego drugiego nurtu, zwanego “Context oriented approach”. Nie będę podejmował próby tłumaczenia tego zwrotu. Szkoła ta opiera się na założeniu, że nie istnieje coś takiego jak uniwersalne “best practices” („najlepsze praktyki”). Przydatność i skuteczność danej metody są zdeterminowane przez kontekst, w jakim te metody są użyte. Procedury i narzędzia, które doskonale sprawdzają się przy opracowywaniu systemu do kontroli pracy reaktora jądrowego, mogą okazać się gwoździem do trumny dla firm operujących na szybko zmieniających się rynku usług. Oczywiście czynnik ludzki jest jednym z kluczowych aspektów kontekstu.
Przy analizowaniu czynnika ludzkiego łatwo można wpaść w pewną pułapkę. Otóż po dojściu do wniosku, że człowiek funkcjonuje inaczej niż maszyna, ale nie oznacza to, że funkcjonuje gorzej – idzie się za ciosem i stawia się tezę, że człowiek jest w swej naturze dobry i chętny do pracy. Jedyne co trzeba zrobić to stworzyć mu odpowiednie warunki, aby te jego cnoty mogły się objawić. Kanerowi, Falkowi i Nguyenowi udało się tej pułapki uniknąć. We wstępie swojej książki, autorzy piszą – “Ta książka jest o testowaniu w sytuacji kiedy twoi współpracownicy nie przestrzegają, nie będą przestrzegać i nie muszą przestrzegać żadnych reguł.” Trzeba przyznać, że dotrzymują słowa. Z drugiej strony z dużym dystansem odnoszą się do wszelkiego rodzaju standardów i głęboko wierzą, że nie zastąpią one zaangażowania i wiedzy ludzi. We wstępie jest fragment, który jest kwintesencją mojego rozumienia procesu wytwarzania oprogramowania. Pozwolę go sobie tu przytoczyć w wersji oryginalnej, aby nieudolnością tłumaczenia (poniżej) nie spłaszczyć jego głębi:
“The quality of a great product lies in the hands of the individuals designing, programming, testing, and documenting it, each of whom counts. Standards, specifications, committees and change controls will not assure quality, nor do software houses rely on them to play that role. It is the commitment of the individuals to excellence, their mastery of tools of their crafts, and their ability to work together that makes the product, not the rules”.
Można to przetłumaczyć mniej więcej tak –
„Jakość dobrego produktu zależy od jednostek, które go projektują, implementują, testują i tworzą dla niego dokumentację. Standardy, specyfikacje, komisje i kontrola zmian nie zapewnią jakości. I firmy żyjące z produkcji oprogramowania bynajmniej nie mają względem tych bytów takich oczekiwań. To co czyni produkt dobrym to dążenie do doskonałości ludzi pracujących nad nim, ich biegłość w korzystaniu z narzędzi i ich umiejętność współpracy – a nie reguły.”
Przejdźmy w takim razie do szczegółów omawianej książki. Jest ona podzielona na 3 części. Część pierwsza zawiera wprowadzenie w dziedzinę testowania i jest ona adresowany do czytelnika dopiero wchodzącego w temat. Wyjaśnione są podstawowe pojęcia i techniki.
Część druga, rozwija bardziej szczegółowo ważniejsze obszary testowania. Te obszary to:
- systemy do raportowania błędów,
- tworzenie scenariuszy testowych,
- testowanie sprzętu,
- testowania lokalizacji,
- testowania dokumentacji,
- narzędzia,
- planowanie i dokumentowanie testów.
Część trzecia jest przeznaczona dla czytelników bardziej zaawansowanych – porusza tematy związane z zarządzaniem procesem testów i zespołem testerów. Bardzo ciekawy jest też rozdział o aspektach prawnych (w kontekście prawa USA) związanych z jakością, wadami oprogramowania i odpowiedzialnością za nie.
Cały czas w książce przewija się wątek ludzki. Autorzy każdą opisywaną przez siebie metodę i wskazówkę analizują pod kontem jej rzeczywistej użyteczności w rękach ludzi, w warunkach ograniczonego czasu, budżetu i komunikacji dalekiej od idealnej (czyli w warunkach typowych dla 99% projektów). Za to niejednokrotnie nie odmawiają sobie przyjemności skrytykowania wszelkiego rodzaju standardów i formalizmów. Oto co piszą na temat zgodności ze standardami (str 200):
“Glass (1992, p. 92) states a conclusion we strongly agree with: >>Efforts to measure quality in terms of standards conformance are doomed to letting poor quality software slip through undetected.<< We suggest that you keep out of standards compliance business. Help programmers write and evaluate compliance checking tools, but let them define and enforce their own standards.”
Tłumaczenie – „Glass (1992, p. 92) dochodzi do wniosku, z którym bardzo się zgadzamy >>Jakiekolwiek wysiłki aby miarą jakości była zgodność ze standardami są z góry skazane na to, że software marnej jakości jakoś się prześlizgnie niezauważony.<< Dlatego radzimy, żebyś trzymał się z dala od tematów zgodności ze standardami. Pomóż programistom pisać i oceniać narzędzia sprawdzające zgodność ze standardami. Ale pozwól im samym definiować i wymuszać swoje standardy”.
Nie bez znaczenia jest fakt, że część autorów, szczególnie Kaner, zajmuje się głównie testowaniem aplikacji dla odbiorcy masowego. To na pewno rzutuje na ocenę niektórych metod przez autorów. Warto to też mieć na uwadze, przy wdrażaniu zaleceń z tej książki na własnym poletku. Mam wrażenie że obecnie, większość z nas pracuję przy rozwoju oprogramowania dla jednego bądź wąskiej grupy klientów.
Nie zmienia to faktu, że bardzo tę książkę polecam, szczególnie osobom zaczynającym swoją przygodę z testowaniem.