Cel działu

Na tej stronie znajdziesz informacje o dostępnych publikacjach na temat jakości oprogramowania (polskich i zagranicznych). Naszym głównym celem jest nie tyle wypisanie dostępnych pozycji na ten temat. Te informacje możesz znaleźć za pomocą jednego zapytania w google. My chcemy stworzyć miejsce, w którym otrzymasz rzetelną informację o tym ile dana książka lub artykuł są naprawdę warte. Ty także możesz pomóc dodając swoją recenzję.
Ważne: SJSI zachęca do pisania recenzji i służy pomocą ich autorom. Jednak treść recenzji prezentuje wyłącznie pogląd jej autora i SJSI nie ponosi za nią żadnej odpowiedzialności.

Jak działa system recenzji.

Recenzji książek jest w internecie wiele. Naszym celem jest utworzyć miejsce, w którym recenzje będą bardzo rzetelne i wiarygodne. Dlatego procedury dodawania nowych recenzji opracowaliśmy w taki sposób aby jak najlepiej móc kontrolować ich jakość.

Jak wysłać recencję.

Oczywiście pierwszym krokiem jest jej napisanie.

Aby usprawnić pracę, zebraliśmy kilka wskazówek i reguł, które warto mieć na uwadze przy pisaniu recenzji. Oto one.

1. W celu zwiększenia wiarygodności recenzji, wymagamy abyś podpisał(a) się pod nią z imienia i nazwiska.
2. Pisz tylko o książce/artykule, który sam przeczytałeś(aś). Unikaj pisania recenzji na podstawie czyichś opinii.
3. Staraj się uzasadnić dlaczego uważasz, że książka jest zła lub dobra.
4. Nie wahaj się skrytykować publikacji jeżeli uważasz, że jest niskiej jakości. Jednak pamiętaj, że nazywając daną książkę „książką dla debili” obrażasz nie tylko autora ale i tych, którym ta książka się podobała. Krytyka jest najbardziej druzgocąca wtedy, jeżeli pokazuje czarno na białym, odwołując się do faktów i konkretnych fragmentów publikacji, na czym polega błąd/niewiedza autora.
5. Jakkolwiek jest miło, jeżeli Twój komentarz jest napisany potoczyście, najważniejsza jest treść merytoryczna. Nie bój się wysłać swoich uwag tylko dlatego, że jesteś przekonany, że nie potrafisz pisać dobrze stylistycznie. Zawsze Ci trochę możemy pomóc. Po drugie, jeżeli Twój tekst będzie rzetelny, to nikt nie będzie się stylu czepiał.
6. Oceniając użyj oceny od 1 do 5 (5 oznacza najlepszą ocenę).

Jak już skończysz pisać, wyślij swoją recenzję na adres s.kulinski@sjsi.org. Daj nam chwilkę czasu, abyśmy mogli to spokojnie przeczytać. Na pewno się do Ciebie odezwiemy. Możemy mieć kilka uwag. Jak już uzgodnimy ostateczną wersję tekstu, publikujemy go. I w ten sposób dołączasz do grona szanownych recenzentów.

Testing Computer Software

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.