Nie tylko dla testerów
- Bogdan Bereza,
- 12.09.2005
Mamy nową książkę w dziedzinie, która - jeśli chodzi o krajową ofertę wydawniczą - wciąż dopiero raczkuje. Być może ukazanie się ''Sztuki testowania oprogramowania'' Glenforda J. Myersa okaże się jakimś punktem zwrotnym.
Mamy nową książkę w dziedzinie, która - jeśli chodzi o krajową ofertę wydawniczą - wciąż dopiero raczkuje. Być może ukazanie się ''Sztuki testowania oprogramowania'' Glenforda J. Myersa okaże się jakimś punktem zwrotnym.
W październiku br. pojawi się jeszcze jedna pozycja wydawnictwa MIKOM - "Praktyka i teoria testowania programów". Wydaje się, że ten rok rzeczywiście okaże się datą zwrotną: odtąd będziemy obserwować bezprecedensowy, gwałtowny wzrost podaży i popytu w zakresie jakości oprogramowania na polskim rynku informatycznym. Nie tylko polskim zresztą, podobne zjawiska można zauważyć w Czechach, na Słowacji, Węgrzech, Ukrainie i w Krajach Bałtyckich.
Klasyka odświeżona
Obecne wydanie książki Myersa różni się od tego z 1979 r. przede wszystkim dwoma zupełnie nowymi rozdziałami: "Testowanie ekstremalne" oraz "Testowanie aplikacji internetowych". Przyzwyczajeni do oszałamiającego niekiedy tempa zmian w technologiach informatycznych i komputerowych, zadajemy sobie pytanie, na ile książka sprzed ćwierć wieku, nawet odświeżona dwoma nowymi rozdziałami, jest w stanie cokolwiek istotnego nam powiedzieć dzisiaj, czy nie stała się raczej antykwarycznym kuriozum?
Otóż odpowiedź jest jednoznaczna: książka Myersa jest dzisiaj tak samo aktualna jak w roku pierwszego wydania. Może nawet stała się bardziej aktualna, bo choć w informatyce jako nauce jej treść nie jest dzisiaj niczym nowym, to w praktyce funkcjonowania przemysłu informatycznego - jakże większego dzisiaj niż dawniej - przyjdzie jej jeszcze niejednokrotnie pełnić rolę pionierską.
Profesor Bogdan Wiszniewski we wstępie do książki pisze: "Zasady dynamiki Newtona są stabilne i już dosyć stare, a zgodnie z nimi latał zarówno pierwszy samolot braci Wright, jak też będą latać hipernaddźwiękowe samoloty pasażerskie będące dopiero w fazie futurystycznych rozważań". Pojawiły się zupełnie nowe języki programowania, nowe platformy sprzętowe, nowe paradygmaty projektowania systemów oraz organizacji przedsięwzięć informatycznych, co jednak w najmniejszym stopniu nie podważa tego, o czym piszą Myers i współautorzy.
Nomenklatura
Będąc tłumaczem pierwszej wydanej po polsku książki o testowaniu, z oczywistą ciekawością sięgnąłem po recenzowaną pozycję, aby zobaczyć, jak tłumacz Andrzej Grażyński poradził sobie z licznymi pułapkami terminologii w tej dziedzinie. Kto wie, może miałem cichą nadzieję, że uda mi się przyłapać kolegę po fachu na jakimś spektakularnym lapsusie językowym?
Generalnie tłumaczenie robi bardzo korzystne wrażenie. Oczywiście, znajduję sformułowania, co do których mam zastrzeżenia. Na przykład zamiast "analiza wartości granicznych" wolę "analiza wartości brzegowych" (boundary-value analysis), zamiast "testowanie ochrony danych" - "testowanie zabezpieczeń" (security testing), zamiast "efektywność" wolę "wydajność" (performance), zamiast "testowanie funkcji ratunkowych" - "testowanie odtwarzania" (recovery testing), wreszcie zamiast "testowanie możliwości obsługi" wolę "testowanie łatwości utrzymania" (maintenance testing). Z drugiej strony, wśród polskich określeń zastosowanych przez tłumacza kilka nowatorskich wybitnie przypada mi do gustu. Zdecydowanie ładniejsza jest "wędrówka" niż stosowane dotąd przeze mnie "przejrzenie" jako odpowiednik specyficznej formy przeglądu, po angielsku zwanej walkthrough. Tak samo bardziej podoba mi się "testowanie zstępujące" zamiast "odgórne", tam gdzie w angielskim oryginale jest napisane top-down testing.
Można przytoczyć wiele przykładów w jedną i w drugą stronę, ale tak naprawdę dyskusja o terminologii między dwiema osobami - choćby bardzo fachowymi - nie ma większego sensu. Z jednej strony, wielu informatyków i tak posługiwać się będzie na co dzień brzydkim "polenglish", czyli mieszanką polskiej i angielskiej terminologii, gdzie ta ostatnia brutalnie zniekształcana jest w trybach polskiej koniugacji i deklinacji (często zupełnie niepotrzebnie, bowiem w miejsce istniejących od dawna wyrażeń, np. osobodni, wprowadzane są fonetyczne kalki językowe, np. mendejsy). Ponadto firmy, zwłaszcza duże, i tak tworzą własne, specyficzne dialekty, niezrozumiałe lub co gorsza rozumiane opacznie przez osoby z innego "obszaru etnograficznego". Weźmy dla przykładu nazwę dokumentu, zawierającego listę i w miarę szczegółowy opis testów, które planuje się wykonać. Osobiście najchętniej posługuję się nazwą "specyfikacja testów" (lub "specyfikacja testowa"), natomiast zetknąłem się z terminami "procedura testowa", "instrukcja testowa", "scenariusz testowy", "skrypt testowy", "plan testów", a nawet "lista warunków".
Z drugiej strony, jednolita i dobrze zdefiniowana terminologia jest potrzebna, po to by teksty oficjalne (np. prezentacje konferencyjne, książki, artykuły, normy i standardy) były jednoznaczne i dla wszystkich zrozumiałe. Dlatego nie od rzeczy będzie w tej recenzji wspomnieć o godnej pochwały inicjatywie Stowarzyszenia Jakości Systemów Informatycznych (http://www.sjsi.org ), które podjęło się stworzenia takiej terminologii. Prace są już znacznie zaawansowane. Dodatkową zaletą terminologii opracowanej przez SJSI jest jej zgranie z propagowaną przez ISTQB (International Software Testing Qualifications Bard), dzięki czemu może też ona służyć jako praktyczny polsko-angielsko-niemiecko-holendersko-hiszpański słownik terminologii inżynierii oprogramowania. Sądzę, że po odpowiednim utrwaleniu się tej terminologii w środowisku, pożądane będzie jej sformalizowanie jako polskiej normy.
Glenford J. Myers, "Sztuka testowania oprogramowania" Helion 2005