TESTER.PL. Z pozdrowieniami. Zarząd Stowarzyszenia Jakości Systemów Informatycznych. Strona 1 z 34

Transkrypt

1 Równo rok temu, 26 czerwca 2003, odbył się zjazd założycielski naszego Stowarzyszenia Stowarzyszenia Jakości Systemów Informatycznych SJSI. Zebrało się wówczas 27 osób. Dzisiaj jednym z namacalnych dowodów działalności SJSI jest pierwszy numer kwartalnika Tester.pl, który właśnie oddajemy do rąk czytelników Po roku nasze szeregi liczą ponad 70 członków i wielu, wielu sympatyków. Rozpoczęliśmy współpracę z firmami komercyjnymi: producentami narzędzi, organizatorami szkoleń. Uruchomiliśmy stronę www naszego Stowarzyszenia. Przez cały rok odbywały się spotkania cykliczne, na których omawialiśmy zagadnienia z obszaru zapewnienia jakości oprogramowania. SJSI było patronem merytorycznym lub organizacją wspierającą dla kilku konferencji, w tym międzynarodowych. Nawiązaliśmy współpracę z ISTQB International Software Testing Qualifications Board. Co dalej? Przede wszystkim zamierzamy przeprowadzić pierwsze egzaminy Foundation Certificate in Software Testing w języku polskim oraz wprowadzić kurs i egzamin na poziom Advanced. Będziemy aktywnie współorganizować kolejne konferencje, również międzynarodowe. We wrześniu, po przerwie wakacyjnej, wznowimy cykl naszych comiesięcznych spotkań, organizując je równolegle w Warszawie na Politechnice Warszawskiej i w Krakowie, na Akademii Ekonomicznej. W październiku zamierzamy sami zorganizować konferencję. Okazją jest pierwsza rocznica powstania Stowarzyszenia. Konferencji będzie towarzyszył drugi numer kwartalnika Tester.pl Plany są ambitne. Aby je zrealizować, potrzebna jest współpraca wszystkich członków Stowarzyszenia. Osoby, które chciałyby się aktywniej włączyć w prace (redakcja strony www, kwartalnika, współpraca z ISTQB, współorganizacja konferencji, pozyskiwanie nowych członków, w tym również firm) prosimy o kontakt z Zarządem. Pracy jest wiele, ale niewątpliwie satysfakcja z współtworzenia pierwszego w Polsce i Europie środkowowschodniej stowarzyszenia testersko jakościowego może być duża. Razem kształtujemy oblicze Stowarzyszenia, a każdy dokładając cegiełkę swojej pracy sprawia, że jego idea jest żywa. Życząc miłej lektury dziękujemy wszystkim tym, którzy przyczynili się do powstania tego kwartalnika, a także wszystkim, dzięki którym SJSI się rozwija. Z pozdrowieniami Zarząd Stowarzyszenia Jakości Systemów Informatycznych Strona 1 z 34

2 Od redaktora Oddajemy do Waszych rąk, Drodzy Czytelnicy, pierwszy numer kwartalnika TESTER.PL. Zgodnie z zamierzeniami jest to pismo dla ludzi zajmujących się głównie, ale nie tylko, testowaniem oprogramowania. Powstało wraz z naszą organizacją Stowarzyszeniem Jakości Systemów Informatycznych i jak ta organizacja, służyć ma przede wszystkim rozpowszechnianiu wiedzy o zasadach testowania oprogramowania i różnym metodo, temu służącym. W tym numerze cztery pozycje: 1. Bogdan Bereza Jarociński o potrzebie testowaniu, lekko i dowcipnie, 2. Lucjan Stapp o wpływie lekkiej metodyki XP na testowanie, 3. Piotr Kałuski o swoich doświadczeniach z kilku lat walki z papierkami, 4. Robert Rzeszotek o PureTest - shareware owym narzędziu do testowaniu. Ponieważ, chcemy tego czy nie, roboty testowe staja się teraźniejszością, a na pewno będą przyszłością branży zajmującej się zapewnieniem jakości oprogramowania (patrz np. felieton Bogdana Berezy Jarocińskiego), ostatni artykuł to początek planowanej serii o różnych automatach testowych. Równocześnie chciałbym gorąco zachęcić wszystkich czytelników tego periodyku do aktywnej współpracy. Z przyjemnością zamieścimy Wasze uwagi, artykuły, felietony mieszczące się w spektrum naszych zainteresowań. Redaktor Strona 2 z 34

3 Tekst sponsorowany Software-Konferencje Sp. z o.o. ul. Lewartowskiego Warszawa tel.+ 48 (22) fax.+ 48 (22) Firma Software Konferencje, dostawca profesjonalnych szkoleń i konferencji dla branży IT zaprasza wszystkich, którym tematyka jakości oprogramowania jest szczególnie bliska do wzięcia udziału w szkoleniach poświęconych właśnie tym zagadnieniom. W naszej ofercie znajdą Państwo miedzy innymi: Podstawy Testowania Oprogramowania Trzydniowy kurs posiadający akredytację ISEB i kończący się egzaminem na certyfikat ISEB SW Foundation Certificate Techniki Testowania Oprogramowania Zarządzanie Testowaniem Oprogramowania. Narzędzia wspierające zarządzanie testowaniem Pozyskiwanie i zarządzanie wymaganiami w projekcie informatycznym Dwudniowy kurs posiadający akredytację IEEE Computer Society. Kurs przygotowuje do egzaminu na Certified Software Development Professional, który można zdać w Polsce za pośrednictwem naszej firmy. Software Quality Assurance Management. Testowanie i zarządzanie jakością w procesie tworzenia oprogramowania. Doroczne spotkanie osób zarządzających testowaniem, kierowników projektów i testerów, osób oceniających wymagania projektów informatycznych. Strona 3 z 34

4 Szczegółowe informacje na temat organizowanych szkoleń znajdą Państwo na stronie: Informacje o firmie: Software-Konferencje Sp. z o.o. działa na rynku od sześciu lat. Organizujemy konferencje, seminaria i warsztaty dotyczące wiedzy i technologii IT. Nasza oferta kierowana jest do osób i instytucji zajmującym się profesjonalnie informatyką. Podczas organizacji imprez współpracujemy z funkcjonującymi na polskim rynku IT organizacjami i instytucjami, wiodącymi polskimi i zagranicznymi firmami informatycznymi, firmami doradczymi oraz grupą niezależnych specjalistów i konsultantów. Strona 4 z 34

5 Test w banku Bogdan Bereza-Jarociński bbjtest Bogdan Bereza-Jarociński Psycholog z Uniwersytetu Warszawskiego i Londyńskiego, informatyk z uniwersytetu w Lund. Testował, zarządzał, automatyzował, koordynował lub ulepszał procesy testowe zarówno w zastosowaniach wbudowanych (telekomunikacja Ericsson, sygnalizacja kolejowa Bombardier) jak i otwartych (bazodanowe, Java). Lubi udzielać się na międzynarodowych konferencjach i prowadzic szkolenia z dziedziny testowania. Od 2002 roku prowadzi w Polsce szkolenia m. in. na certyfikat ISEB. Strona 5 z 34

6 Test w banku Bogdan Bereza-Jarociński bbjtest Komputery to czarodziejskie urządzenia robią za nas automatycznie to, co wcześniej musieliśmy mozolnie wykonywać ręcznie. Co więcej, projektowanie i budowa nowych komputerowych robotów nie wymaga mozolnej pracy zespołów architektów, stolarzy, murarzy i mechaników. Wszystko daje się szybko i sprawnie wymodelować i zrealizować w jednym, magicznym tworzywie oprogramowaniu komputera. Nikt lepiej niż banki nie docenia możliwości, jakie daje zastąpienie wielkiej sali pełnej sfrustrowanych, omylnych urzędników cierpliwym i usłużnym komputerem, a kosztownej sieci bankowych oddziałów dostępną w trybie 24 * 365 aplikacją internetową. Zarazem jednak nikt lepiej niż banki nie zdaje sobie sprawy, jakie straty może spowodować jeden na pozór niegroźny błąd w obliczeniach, chwilowe nawet ograniczenie dostępności banku internetowego czy wreszcie włamanie się hackera do systemu. Pisanie o testowaniu i zapewnieniu jakości systemów informatycznych przypomina często żmudną pracę misyjną: przekonywanie niewiernych, że test naprawdę nie jest kosztownym luksusem, że się opłaca, ba jest konieczny! Wobec banków mam nadzieję nie ma takiej potrzeby. Można od razu przejść do tematów zaawansowanych. Praca żmudna, mozolna, ale za to jaka jałowa! Testowanie polega bardzo często na tym, że sprawdza się ponownie wielokrotnie, obsesyjnie to, co działało wcześniej. Osobę, która przemalowawszy sufit w łazience, sprawdza, czy nadal funkcjonuje kuchenka w kuchni, uznalibyśmy za nieco zneurotyzowaną. Niestety, własnością magicznego tworzywa zwanego oprogramowaniem jest to, że takie właśnie zależności mogą zaistnieć liczne przykłady zna każdy programista, użytkownik czy administrator systemu z własnego doświadczenia. Dlatego nawet zmiany pozornie niewinne: dodanie jednej nowej funkcji, inna konfiguracja, nowa platforma sprzętowa, instalacja systemu w innym środowisku wymagają ponownego przetestowania całości systemu. Ta czynność, zwana w dialekcie branżowym funkcjonalnym testowaniem regresyjnym, jest piętą achillesową wielu projektów informatycznych. Sprzymierzeńcem mogą być narzędzia. Tak jak istnieje oprogramowanie automatyzujące żmudną pracę urzędnika bankowego, tak istnieją też narzędzia automatyzujące żmudną pracę testera. Szczególną popularnością cieszą się od kilku lat programy typu zarejestruj odtwórz (capture - playback), pozwalające na automatyczne testowanie poprzez interfejs użytkownika. Takie narzędzia potrafią m.in. symulować pracę klawiatury i myszki, kontrolować poprawność tego, co pojawia się na ekranie. Nietrudno wyobrazić sobie, jakim usprawnieniem może być automatyczne wykonanie szeregu testów na przykład przy wdrożeniu nowej wersji systemu bankowego lub podczas instalacji aplikacji w wielu oddziałach tego samego banku. Kontrola instalacji wodnej pod ciśnieniem Oprogramowanie stosowane przez banki zwykle jest wykorzystywane przez wiele osób jednocześnie. W szczególnym przypadku banku internetowego można mieć do Strona 6 z 34

7 czynienia z dziesiątkami czy wręcz setkami tysięcy jednoczesnych użytkowników systemu. Każdy klient banku zna sytuację, kiedy załatwianie sprawy trwało dłużej, niż by się chciało, bo pracownik banku kilkakrotnie długo oczekiwał na odpowiedź komputera. Każdy menedżer banku dobrze wie, jakie są koszty sytuacji, gdy niedostateczne osiągi (czasy odpowiedzi) systemu powodują, że jego pracownicy są w stanie obsłużyć, dajmy na to, tylko połowę liczby transakcji, jaką mogliby załatwić mając do dyspozycji szybszy system. Jakie znaczenie ma dostępność i czasy odpowiedzi dla aplikacji internetowej, nikomu nie trzeba tłumaczyć. Co grosza, każda efektowna awaria serwera dużego systemu internetowego zwykle stanowi wydarzenie na tyle medialne, że pisze o nim prasa. Dlatego tak zwane testy wydajnościowe (testy osiągów, testy przepustowości) systemów bankowych są szczególnie ważne właśnie dla aplikacji bankowych. Czy można je wykonywać bez użycia narzędzi? Niełatwo - wyobraźmy sobie scenę, gdy np. 500 pracowników firmy zostaje w nadgodzinach, kierownik testów zamawia 500 pizz i cocacoli, po czym pada komenda wszyscy się wlogowują! Koszt mimo wszystko spory, precyzja wątpliwa, kontrola wyników dyskusyjna, powtarzalność zerowa. Nic dziwnego, że narzędzia do testów wydajnościowych sprzedają się jak ciepłe bułeczki. Według Annual Load Test Market Summary and Analysis 2003 (Newport Group, Inc.) rynek na tego typu narzędzia wynosił w 2003 roku 750 milionów dolarów, a jego wzrost w latach ponad 30% rocznie! Pozazdrościć, a kto wie, czy nie uwzględnić tego faktu przy podejmowaniu decyzji o lokacie oszczędności? Testy wydajnościowe pozwalają nie tylko stwierdzić, czy system spełnia wymagania, ale przede wszystkim umożliwiają poprawę osiągów, kiedy nie są spełnione. Znaczne oszczędności można osiągnąć, jeśli zastosować narzędzia ułatwiające dostrajanie systemu. Zamiast poprawiać osiągi poprzez kosztowne zakupy sprzętu (takie rozwiązanie wystarcza zresztą tylko na pewien czas), można zwykle uzyskać nawet wielokrotną poprawę osiągów odpowiednią konfiguracją systemu i serwerów. Pociągi pod specjalnym nadzorem Główną cechą Internetu jest zmienność i niepewność. System, nawet starannie przetestowany dla przewidywanego poziomu obciążenia, może zacząć zdradzać nieoczekiwane słabości, kiedy obciążenie wzrośnie ponad pewną granicę. Czas odpowiedzi systemu może nieoczekiwanie zacząć wzrastać nawet wykładniczo po przekroczeniu pewnego progu obciążenia. Aby mieć kontrolę obciążenia i osiągów używanego systemu i móc na czas reagować, gdy przestaje spełniać wymagania dostępności, konieczne jest monitorowanie systemów. Straty, bezpośrednie i pośrednie, jakie może spowodować choćby kilkugodzinna awaria systemu bankowego, trudno przecenić. Zapobiec im można, monitorując najważniejsze parametry systemu i uruchamiając automatyczne alarmy, gdy pojawiają się zwiastuny kłopotów. Ma to również znaczenie dla zapewnienia bezpieczeństwa systemu, o czym niżej. Szukanie dziury w całym Nie każdy się do tego przyznaje, ale zwykle jakość przelicza się na pieniądze. Znamy wszyscy firmy, które znakomicie prosperują mimo nie najwyższej jakości i niezawodności swych produktów. Oznacza to, że w tym segmencie rynku, gdzie działają, koszty bezpośrednie i pośrednie ewentualnych awarii są względnie niskie. Inaczej wygląda sytuacja w sektorze finansowym. Tutaj awarie zwykle kosztują tak dużo, że warto zainwestować w zapobieganie.. Strona 7 z 34

8 Szczególnie istotne jest zagadnienie bezpieczeństwa (security) systemu. Pod tym pojęciem rozumiemy zdefiniowanie poziomu ryzyka sytuacji, że osoba niepowołana może się do niego dostać, lub że użytkownik może dokonywać przy pomocy systemu operacji, do których nie ma uprawnień. Testowanie bezpieczeństwa to trudna sztuka, polegająca m.in. na szukaniu nadmiarowej funkcjonalności, czyli tego, co system robi, choć w świetle wymagań nie musi, a co często jest wykorzystywane jako nielegalne boczne wejście do systemu. Narzędzia nie zrobią za nas testów bezpieczeństwa, ale potrafią je ułatwić. Na przykład pełne przetestowanie wszelkich kombinacji identyfikatorów i haseł użytkowników, możliwe przy użyciu narzędzi nagraj-odegraj, pozwala zlikwidować wiele typowych błędów bezpieczeństwa. Wiele błędów bezpieczeństwa ujawnia się, gdy system jest przeciążony. Błędy te również łatwiej odkryć, gdy dysponujemy narzędziami pozwalającymi zarówno obciążyć system, jak i monitorować w tym czasie działanie jego poszczególnych elementów. Czego użytkownik nie lubi najbardziej? Nie lubimy (bo przecież każdy z nas jest od czasu do czasu użytkownikiem!), gdy programy traktują nas źle, arogancko, nie informują o swoim działaniu, gdy są nadmiernie gadatliwe lub przeciwnie gdy potrzebną nam informację skrzętnie ukrywają. Innymi słowami, gdy są nieprzyjazne użytkownikowi, niewygodne w użytkowaniu. Tradycyjnie systemy informatyczne lekceważyły użytkowników, a ci z pokorą przyjmowali niewygodę. Od kilku lat sytuacja zmienia się, zaś systemy internetowe wręcz ją odwróciły. Niekiedy ocenia się, że dla systemów internetowych użyteczność i osiągi są ważniejsze, niż funkcjonalność! Łatwość posługiwania się bankiem internetowym może już wkrótce dla pewnych grup klientów stać się kryterium wyboru banku. Użyteczność systemów ma także wpływ na ich bezpieczeństwo. Wyobraźmy sobie np. system, wymagający tylu różnych haseł, że zmusza prawie użytkowników do notowania ich na przylepianych do monitora karteczkach... Jakość jest za darmo Już w latach 70-ych napisano, że jakość jest za darmo w tym sensie, że koszty zapewnienia jakości w tym testowania są zwykle znacznie niższe niż koszty awarii spowodowanych brakiem testowania. Tam gdzie koszty awarii są szczególnie wysokie, nakłady na jakość i testowanie powinny być odpowiednio wyższe w przeciwnym razie oszczędności w projektach okażą się pozorne. Systemy informatyczne w bankowości zarządzają naszymi pieniędzmi, a chyba nikt nie chce, by jego pieniądze były zarządzane i pilnowane niedbale, wadliwie i nieskutecznie. Strona 8 z 34

9 Tekst sponsorowany OPTANE DLA ROZWIĄZAŃ SAP Optymalizacja rozwiązań SAP Aby sprostać unikalnym potrzebom przedsiębiorstw, każde wdrożenie zawiera własną kombinację procesów biznesowych i wymagań odnośnie infrastruktury. Aby uniknąć takich problemów, jak niemożność współdziałania architektur, ograniczona skalowalność, słaba wydajność serwera aplikacji i zakłócenia funkcjonalności, należy starannie przetestować aplikacje przed ich wdrożeniem, a następnie dostrajać i monitorować ich pracę w środowisku produkcyjnym. Setki klientów SAP z powodzeniem stosują rozwiązania BTO firmy Mercury do wdrażania, modernizacji i utrzymania swoich aplikacji. Ponadto, SAP stosuje pakiet Optane wraz z innymi rozwiązaniami do wewnętrznych testów swojego oprogramowania. W skład Optane for SAP Solutions wchodzą następujące moduły: TestDirector, QuickTest Professional, LoadRunner, ProTune oraz Topaz. JAK DZIAŁA OPTANE FOR SAP SOLUTIONS Optymalizacja aplikacji pod kątem ich gotowości do pracy, wydajności i dostępności ma podstawowe znaczenie, jeżeli mają one spełniać surowe i zmieniające się wymagania biznesowe. Optane Suite zapewnia wszystko, co jest potrzebne do zintegrowanego zarządzania fazą testową, wszechstronnych testów funkcjonalnych, testów pod obciążeniem, wdrożenia i zarządzania nieprzerwaną dostępnością. WSZECHSTRONNE TESTY GOTOWOŚCI APLIKACJI TestDirector tworzy i nadzoruje proces testowy, który umożliwia podjęcie decyzji, czy aplikacja SAP jest gotowa do wdrożenia. Szybko przekłada analizę procesu biznesowego na obszerny zestaw testów, składający się z ręcznych i zautomatyzowanych testów funkcjonalnych i testów regresywnych, a także ze scenariuszy pracy pod obciążeniem. Wszystkie wyniki testów związanych z projektem gromadzone są w jednym miejscu. Dzięki swojej otwartej architekturze TestDirector płynnie integruje się z aplikacjami do zarządzania cyklem eksploatacji od narzędzi do zarządzania konfiguracją po systemy pomocy. QuickTest Professional automatycznie przechwytuje i odtwarza interakcje użytkowników. W ten sposób umożliwia wychwycenie błędów, a procesy biznesowe przebiegają płynnie od samego początku. QuickTest Professional został zaprojektowany z myślą o takich rozwiązaniach, jak mysap Enterprise Portal, które integrują w sobie rozwiązania SAP z aplikacjami firm trzecich. QuickTest Professional może rejestrować, odtwarzać i weryfikować procesy biznesowe z wykorzystaniem interfejsu graficznego SAP do Windows lub za pomocą klientów HTML z możliwością personalizacji na bazie Javy Strona 9 z 34

10 i Microsoft.NET. Tak szerokie możliwości umożliwiają przedsiębiorstwom testowanie dowolnych połączeń różnych komponentów lub rozwiązań przemysłowych. Tekst sponsorowany Po zakończeniu fazy weryfikacji procesów biznesowych o krytycznym znaczeniu i stwierdzeniu, że pracują prawidłowo należy użyć modułu LoadRunner do testów obciążeniowych, wydajnościowych i testów skalowalności. LoadRunner to narzędzie testowe, które prognozuje zachowanie i wydajność systemu. Z poziomu pojedynczego punktu kontrolnego LoadRunner obejmuje swoim działaniem całą infrastrukturę, łącznie z graficznym interfejsem SAP do Windows lub klientami HTML, serwerami aplikacyjnymi i bazodanowymi oraz serwerami internetowymi. Emulując tysiące wirtualnych użytkowników LoadRunner mierzy wydajność transakcyjną systemów i prowadzi testy rozproszonych scenariuszy. DOSTRAJANIE APLIKACJI DO OPTYMALNEJ WYDAJNOŚCI Rozwiązanie ProTune umożliwia optymalizację aplikacji zarówno w fazie przygotowania, jak i w czasie eksploatacji. Dział informatyki może ocenić konfigurację aplikacji, a także dokonać kwantyfikacji ogólnej wydajności systemu. ProTune zawiera specyficzne dla aplikacji biblioteki komponentów testowych, monitory i tunery, które automatycznie dostosowują się do rzeczywistych środowisk biznesowych, takich jak mysap Enterprise Portal. Korzyść polega na zmniejszeniu całkowitego kosztu posiadania poprzez eliminację niepotrzebnych zakupów sprzętu i oprogramowania. PROAKTYWNE MONITOROWANIE DOSTĘPNOŚCI 24/7 Rozwiązanie Topaz umożliwia zarządzanie wszystkimi procesami biznesowymi o krytycznym znaczeniu w celu uzyskania maksymalnej i nieprzerwanej wydajności. Topaz zapewnia podgląd aplikacji w czasie rzeczywistym zarówno z punktu widzenia użytkownika, jak i informatyka. Definiując alarmy bazujące na procesach biznesowych informatycy mogą nadać działaniom naprawczym zróżnicowane priorytety, zależnie od tego, jakie grupy użytkowników zostały dotknięte awarią lub jaki jest wpływ awarii na ogólne działanie przedsiębiorstwa. INFORMACJE O FIRMIE MERCURY Mercury jest światowym liderem w zakresie optymalizacji technologii biznesowych (BTO). Pakiet rozwiązań Optane pomaga poprawiać jakość, obniżać koszty i dostosowywać technologię IT do wymagań biznesowych. Kontakt: Lubomir Stojek, Mercury, lstojek@mercury-eur.com. Strona 10 z 34

11 extreme TESTING (TESTOWANIE EKSTREMALNE) Lucjan Stapp Wydział Matematyki i Nauk Informacyjnych Politechnika Warszawska Lucjan@mini.pw.edu.pl Lucjan Stapp Doktor nauk matematycznych (bo gdy robił doktorat nie było jeszcze doktoratów z informatyki). Wieloletni pracownik naukowy Politechniki Warszawskiej Wielokrotnie pracował też jako kierownik zespołów projektowych i zespołów zapewnienie jakości w dużych i małych projektach. Zwolennik lekkich metodyk, także w testowaniu. Strona 11 z 34

12 extreme TESTING (TESTOWANIE EKSTREMALNE) Lucjan Stapp Wydział Matematyki i Nauk Informacyjnych Politechnika Warszawska W ciągu ostatnich kilku lat metodologia extreme Programming (XP) zrobiła oszałamiająca karierę w inżynierii oprogramowania. Metodologia ta zaproponowana prawie pięć lat temu [1] dorobiła się własnej konferencji (już czwarta konferencja poświęcona tej metodologii odbyła się w maju 2003 w Genui). Zwolennicy tej metodologii wykorzystują też własną stronę internetową [5]. Jakie są podstawowe zasady extreme Programming? Każdy analityk wymieni bez namysłu kilka haseł: write test first: najpierw twórz testy. Zasada ta ma uzmysłowić programistom, że przed przystąpieniem do tworzenia fragmentu oprogramowania (klasy) należy przygotować sobie testy weryfikujące poprawność interfejsu dla projektowanej klasy pair programming : pisanie w parach. Jedna osoba w parze tworzy kod, druga ją wspomaga, zwracając szczególna uwagę na poprawność tworzonego kodu ścisła współpraca z odbiorcą: przez cały czas tworzenia aplikacji istnieje możliwość zweryfikowania założeń analitycznych przez uprawnionego przedstawiciela zleceniodawcy częste tworzenie kolejnych wersji aplikacji: po sprawdzeniu poprawności nowego fragmentu oprogramowania należy go dołączyć do tworzonego oprogramowania i sprawdzić działanie. Ken Beck ojciec metodologii XP w [2] proponuje jednak nieco inne podstawowe zasady tworzenia oprogramowania w metodologii XP: simplicity(prostota): eliminowanie wszystkiego co niepotrzebne przy produkcji oprogramowania, Tym samym przepływ informacji należy w maksymalnym stopniu na oprzeć na: communication (komunikacja): współpracy oparta o bezpośrednią wymianę informacji między programistami, analitykami i testerami, Musimy też zapewnić feedback (sprzężenie zwrotne): maksymalnie szybkie uwzględnianie uwag odbiorcy. Zapewni to: aggressiveness (ofensywność, przebojowość): szybka realizacja oprogramowania I te zasady są też podstawą extreme Testing (XT). XT jest pochodną XP, ma ułatwić i przyspieszyć testy przygodo-wywanej aplikacji. Jest to metodologia testów dla aplikacji przygotowywanych wg metodologii XP. Pierwsze pytanie, które należy w tym momencie postawić to pytanie o potrzebę testów aplikacji przygotowywanych w tej metodologii: przecież były one już sprawdzane ( write test first ). Rzeczywistość pokazuje, że programiści ograniczają się głównie do testowania poprawności tworzonych klas (np. przy użycie JUnit [6]). Testy integracyjne, akceptacyjne, nie wspominając już o testach wydajnościowych i testach bezpieczeństwa, pozostają w dalszym ciągu zadaniem zespołu testerów. Tym samym podstawowym zadaniem testera w XP są testy akceptacyjne odbiorcze dla kolejnej iteracji. Zgodnie z metodyką XP testowanie kodu modułów to zajęcie Strona 12 z 34

13 deweloperów, nie należy pozwolić, by zadanie to zostało przerzucone na testerów. Testerzy testują testy funkcjonalne (oraz wydajnościowe, integracyjne itp.). Są to testy typu grey box (pomiędzy white box i black box ). Innymi słowy tester XP głównie sprawdza zachowanie się całej aplikacji (jej kolejnej iteracji) metodą czarnej skrzynki, jednak przy wykryciu błędu stara się go zlokalizować analizując fragmenty kodu (testowanie typu white box ). Podstawowe zasady XT to: 1. najpierw należy stworzyć (zaprojektować) testy (I) należy zacząć jak najwcześniej (najpóźniej równolegle z deweloperami), lepiej, gdy można to zrobić podczas odbioru prac analitycznych (II) dążymy do maksymalnego zrozumienia testów nie należy zakładać wzajemnego zrozumienia się, w przypadku jakichkolwiek niejasności należy uszczegółowić problem 2. testy mają równy priorytet z tworzeniem kodu (I) w większości przypadków testy są spychane na sam koniec procesu produkcji oprogramowania, wielu projekt menadżerów zgadza się na skrócenie czasu poświęconego na testy. W XT ta zasada ma nie mieć zastosowania, bez pozytywnego przejścia wskazanych testów nie ma odbioru aplikacji (jej kolejnej iteracji) 3. dążenie do 100% pokrycie przypadkami testowymi (TC) wszystkich warstw systemu. 4. jasno określony cel testowania (I) pożądana jakość produktu; ponieważ nie można przetestować wszystkich możliwych przebiegów aplikacji, należy z góry określić te przebiegi które muszą bezwzględnie zachowywać się poprawnie; co więcej dopuszczamy nieprawidłowe zachowanie się aplikacji w pewnych sytuacjach. Przykładem może tu być układ klawiszy CTRL+ALT+DEL we wczesnych wersjach systemu Windows; użytkownicy zostali nauczeni, że po naciśnięciu tego układu klawiszy Windows zachowuje się niepoprawnie (kończy działanie). Tak więc czasem łatwiej jest nauczyć użytkownika końcowego odpowiedniego działania niż zbudować dostateczne zabezpieczenia w systemie. (II) satysfakcja odbiorcy (III) minimalizacja zmian w przeciwieństwie do XP nie należy codziennie testować przygotowywanej aplikacji, tu należy dążyć do otrzymywania z produkcji wersji pełnej (oczywiście ze względu na wskazaną funkcjonalność). (IV) akceptacja na podstawie z góry ustalonych funkcjonalnych testów akceptacyjnych w przypadku stwierdzenia innych błędów iteracja jest akceptowana, poprawianie to kolejna iteracja 5. testowanie parami (I) co dwie pary oczu to nie jedna (II) zwiększenie bezpieczeństwa testów a). mamy tu możliwość tworzenia różnych par testerów np. doświadczony niedoświadczony, znający problem biznesowy nowicjusz itp. b). należy zapewnić rotację testerów w parach, będzie to skutkowało zmniejszeniem zarządzania ryzykiem odejście dobrego testera nie skutkuje dużymi stratami w projekcie 6. dążenie do maksymalnego uproszczenia dokumentacji testowej (I) (II) podstawowymi metodami komunikacji i to zarówno w zespole testowym jak i między zespołem testowym a programistami ma być komunikacja werbalna i poglądowa. By to osiągnąć, należy wzmocnić współpracę testerów i deweloperów. Osiągnąć to można poprzez Strona 13 z 34

14 a). integracja zespołu poprzez częste spotkania (np. 2 razy w tygodniu lub krótka 5 10 minut odprawa raz dziennie) b). wzajemne przeglądy testów (testerzy sprawdzają testy deweloperów, deweloperzy uczestniczą w przygotowywaniu testów akceptacyjnych 7. automatyzacja testów: należy dążyć do maksymalnej automatyzacji testów. Ułatwia to i zdecydowanie przyspiesza testy regresji, które należy wykonać przy odbiorze kolejnej iteracji powstającej aplikacji. Należy jednak pamiętać o tym, by myśleć już o tworzeniu skryptów testowych już na etapie projektowania testów, jak najwcześniej należy też przystąpić do tworzenia tych skryptów. Ponieważ testy rozpoczynają się równocześnie z tworzeniem, więc początkowy okres nim zostaną wyprodukowane pierwsze fragmenty nadające się do testowania poświęcić na projektowanie i tworzenie skryptów testowych. Należy też zdawać sobie sprawę z faktu, że pomimo dość wysokiej ceny profesjonalnych automatów testowych wydatek ten zwraca się stosunkowo szybko. Przy niedużych projektach można stosować shareware owe lub freeware owe automaty testowe. Ich możliwości są zdecydowanie słabsze, ale i tak zdecydowanie przyspieszają proces testowania. 8. codzienne raportowanie stanu testów: (I) Zalecane jest stworzenie codziennie odświeżanej i dostępnej dla wszystkich prezentacji bieżącego stanu testów, najlepiej w postaci graficznej. Na tej prezentacji należy wskazać, które testy już przeszły (oznaczamy je np. kolorem zielonym),, które się zawaliły (na czerwono), których jeszcze nie można sprawdzać (na żółto). Zwiększanie się liczby zielonych wpływa mobilizująco także na zespól wykonawców. Prócz powyższych zasad obowiązują standardowe zasady tworzenia testów wydajnościowych. Należy tworzyć i uruchamiać je w najwcześniejszych możliwych fazach testowania. Należy także pamiętać o ciągłym refactoringu skryptów testowych i dodawaniu nowych TC zwłaszcza związanych z sytuacjami, gdy wykryto błąd spoza zakresu testów akceptacyjnych aktualnej iteracji. Czy XT jest uniwersalną metodologią testowania aplikacji? Odpowiedź brzmi zdecydowanie nie. By móc ją stosować należy sobie zapewnić co najmniej stosowanie podstawowych zasad XP przez zespól programistów. Co więcej, konieczny jest bezpośredni kontakt z odbiorcą aplikacji umożliwi to budowę rzeczywiście interesujących testów akceptacyjnych. Nawet przy najpełniejszej analizie zadania zawsze pozostają niedomówienia i niedookreślenia, które należy wyjaśnić na jak najwcześniejszym etapie prac. Wydaje się także, że metodologia ta ma zdecydowanie lepsze zastosowania przy tworzeniu programów o krótkich cyklach produkcyjnych (kilku lub kilkunastotygodniowych). Przy dłuższych cyklach produkcji zatraca się jasność sytuacji i bez bogatej dokumentacji (a tej w XT nie ma) trudno jest osiągnąć zamierzony cel. XT nie jest metodologią pozbawioną wad. W szczególności trudno się zgodzić z pkt. 5 nakazującym testowanie parami. Zwiększa to koszty testów, a wszystkie zalety można osiągnąć przez wymianę scenariuszy testowych między testerami ścisłą integrację zespołu testerów. Zdecydowanie trudno stosować też XT przy geograficznym rozproszeniu zespołu. Oczywiście współczesne środki komunikacji ułatwiają komunikację pomiędzy członkami zespołu, ale jednak nie jest to współpraca bezpośrednia. Strona 14 z 34

15 Niepokój budzi też akceptacja iteracji mimo znalezionych błędów. Każdy tester będzie starał się podciągnąć taki błąd pod istniejące scenariusze i wykazać jego istotność, bojąc się podejrzenia o niekompletność testów. Natomiast ciekawym pomysłem wydaje się określenie z góry jakości produktu i nie testowanie ścieżek wykraczających poza przyjęte kryterium. Wydaje się jednak, ze metodologia XT umożliwia przynajmniej częściowo realizację standardowego problemu testów: Które dwa z trzech czynników brać pod uwagę w procesie testowania: koszt czas jakość i jej dalszy rozwój powinien usprawnić i ułatwić proces testowania nowotworzonych aplikacji. Przy pisaniu powyższego artykułu korzystałem z następujących źródel: [1]. Beck, K., Extreme Programming Explained: Embrace Change, Addison-Wesley Publish Co; 1999 [2]. Beck, K., Fowler, M., Planning Extreme Programming, Addison -Wesley Publishing Co; 2001 [3]. Berbet, T., Extreme testing, [4]. Jeffries, R., Anderson, A., Hendrickson, C., Extreme Programming Installed, Addison -Wesley Pub Co; 2001 [5]. [6]. [7]. Strona 15 z 34

16 Strona 16 z 34

17 Jakościowe pułapki Piotr Kałuski CGI Piotr Kałuski Jest absolwentem Wydziału Elektroniki i Technik Informacyjnych Politechniki Warszawskiej, kierunek informatyka. Od 1995 uczestniczył w wielu projektach informatycznych jako programista analityk, projektant i kierownik zespołu. Obecnie jest pracownikiem firmy CGI i jako konsultant jest członkiem zespołu System Test w firmie Polkomtel. Dziedzina jego zainteresowań to sposoby usprawnienia procesu testowania i wykorzystanie narzędzi Open Source w procesie wytwarzania i testowania oprogramowania. Szczegóły można znaleźć pod adresem Strona 17 z 34

18 Jakościowe pułapki Piotr Kałuski CGI 1. Wstęp nikt nie chce pisać złego kodu Są wśród informatyków tacy, których świadomość w kwestii jakości oprogramowania jest niska. Z drugiej strony nikt nie siada do klawiatury z intencją napisania złego kodu. Niestabilność i nieczytelność kodu, brak jasnej dokumentacji u większości informatyków wywołuje frustrację. Wszyscy chcemy pisać dobre oprogramowanie z dobrą dokumentacją. Jednak pomimo szczerych chęci osób zaangażowanych w projekty informatyczne, niezadowalająca jakość kodu i dokumentacji jest wciąż zmorą wielu firm. Przyczyn na pewno jest wiele i jest to temat godzien opasłego tomiska. Ja skupiam się na jednej, moim zdaniem, dość ważnej przyczynie. Odnoszę wrażenie, że wiele osób nie zdaje sobie sprawy z rzeczywistych kosztów związanych z implementacją procedur zapewnienia jakości powszechnie obecnych w opracowaniach na temat jakości oprogramowania. Świadomość rzeczywistych kosztów przychodzi dopiero w trakcie projektu, kiedy większość procedur jest już wdrożonych. Wycofanie się z nich i wdrożenie innych jest wtedy zbyt kosztowne. Z drugiej strony budżet projektu nie zawsze jest w stanie udźwignąć całego narzutu wnoszonego przez wybrane przez nas metody zapewnienia jakości. W efekcie zasady, których przestrzeganie jest fundamentem zapewnienia jakości, są przestrzegane połowicznie (bo na pełne przestrzeganie nie ma czasu ani pieniędzy), co prowadzi czasami do większego chaosu niż gdyby tych zasad nie było. Chcę być dobrze zrozumiany. Projekt, w którym nie ma żadnego systematycznego podejścia do zagadnienia jakości, jest z góry skazany na zagładę. Z drugiej strony procedury i narzędzia zapewnienia jakości podlegają tym samym podstawowym prawom, co inne narzędzia ich eksploatacja kosztuje. Kosztuje ich zakup (w przypadku oprogramowania niekoniecznie. Dla niektórych narzędzi istnieją nie gorsze, darmowe odpowiedniki), kosztuje ich utrzymanie, kosztuje ich eksploatacja, kosztuje czas potrzebny do przyuczenia innych jak tych narzędzi używać. Jako homo sapiens, potrafimy i powinniśmy korzystać z narzędzi. Ważne jest byśmy potrafili dobrać narzędzia na miarę naszych potrzeb i możliwości. Pozwolę sobie użyć porównania z usługami transportowymi. Nie każda firma świadcząca usługi transportowe może sobie pozwolić na zakup najnowocześniejszych samochodów. Jeżeli nie ma odpowiedniej bazy klientów to cena eksploatacji i ubezpieczenie może przekroczyć jej możliwości finansowe. Tego typu pułapek jest przy wytwarzaniu oprogramowania kilka. Ja chcę się skupić na niektórych aspektach dokumentacji, procedur i aplikacji narzędziowych. Następnie postaram się zasygnalizować, że nawet przy ograniczonym budżecie można odnieść sukces. Trzeba po prostu narzucić sobie pewne reguły, które oceniamy jako realistyczne i twardo się tych reguł trzymać. 2. Dokumentacja Temat rzeka. Właściwie, to w dużym uproszczeniu, można powiedzieć, że procedury zapewnienia jakości określają głównie: kto, kiedy i jaki ma napisać dokument. Ale, nawet bez czytania norm ISO przeciętny programista wie, jak ważna jest poprawnie spisana specyfikacja wymagań i dokumentacja implementacji z diagramami modułów. Trochę mniej programistów zdaje sobie sprawę z tego jak ważne jest, aby ta dokumentacja była napisana prostym i Strona 18 z 34

19 zrozumiałym językiem. Nie zmienia to faktu, że świadomość wagi dobrej dokumentacji jest powszechna. Dużo mniej powszechna jest świadomość, co tak naprawdę oznacza dobre, porządne wykonanie danego dokumentu. I jakie są związane koszty ze zrobieniem tego naprawdę dobrze. Oraz jakie są skutki zrobienia tego byle jak. Chcę tu zwrócić uwagę na kilka niebezpieczeństw. Ostrożnie z diagramami Doczesne miejsce w dokumentacji technicznej zajmują diagramy. Diagramy modułów w systemie jako całości, diagramy interakcji między obiektami, diagramy hierarchii klas, scenariusze itd. W niektórych sytuacjach kilka czytelnych diagramów potrafi przekazać więcej niż kilkanaście stron tekstu. Dlatego, przy tworzeniu czytelnej i zrozumiałej dokumentacji, diagramy są niezastąpione. Istnieje co najmniej kilka programów ułatwiających tworzenie prostych i czytelnych diagramów (włączając w to narzędzia do rysowania dostępne w Wordzie). Warto wybrać sobie narzędzie, które najbardziej nam pasuje i go używać. Podkreślam nic nie zastąpi czytelnego diagramu. Przy podejmowaniu decyzji o tworzeniu diagramu powinniśmy kierować się zdrowym rozsądkiem. Przestrzegam przed postanowieniami typu diagram dla każdego scenariusza, diagram dla każdego obiektu. Przyjęcie takich zasad spowoduje, że będą tracone godziny lub dni na diagramy ilustrujące rzeczy na tyle proste, że można je opisać w kilku linijkach tekstu. Diagram nie jest celem samym w sobie. Celem rysowania diagramu jest ilustracja rzeczy trudniejszych do opisania słowami. Nowoczesne narzędzia wychodzą nam tu naprzeciw, automatyzując tworzenie niektórych diagramów na podstawie definicji obiektów. Jednak opierając tworzoną dokumentację na dużej ilości diagramów (a będzie ich dużo, jeśli będziemy je tworzyć, dla np. każdego obiektu) musimy być świadomi kosztów ich wykonania oraz kosztów dbania o to, by były aktualne. Możemy skorzystać z programu, który bardzo pomaga przy rysowaniu takich obiektów. Takie programy nie tylko same rysują klocki z odpowiednimi atrybutami. Dają one możliwości tworzenia repozytorium obiektów i odwoływania się do diagramów danych obiektów z różnych dokumentów. Mówiąc ogólnie - pomagają zarządzać zagadnieniami i obiektami, które występują w projekcie. Musimy mieć jednak na uwadze kilka czynników. Trzeba pamiętać, że repozytorium obiektów w dużym projekcie często się zmienia. W związku z tym, ktoś musi tym administrować. Musi też istnieć jakiś sposób określania, które repozytorium odpowiada danej wersji oprogramowania. Wyobraźmy sobie następujący przykład. Mamy obiekt, który jest obecny na wielu diagramach. I ten obiekt się zmienia. Dochodzi nowa ważna metoda, bądź usuniętych jest 5 atrybutów. W związku z tym każdy dokument, który ma w sobie diagram z tym obiektem, musi zostać uaktualniony lub powinna zostać stworzona nowa wersja tego dokumentu. Już samo to zajmuje czas. A jak jeszcze są diagramy, które importują inne diagramy (np. za pomocą OLE) to uchowaj Boże. Używałem takiego narzędzia ze 4 lata temu. Zmiana głupiego obiektu zajmowała mi kilka dni, bo program działał wolno i się sypał. Ale 4 lata to dużo czasu. Dzisiaj takie rzeczy są bardziej stabilne. Jednakże narzut administracyjny pozostaje. I zależności między wersjami też. Pamiętajmy, że jeżeli bawimy się w repozytoria obiektów, to musimy się też bawić w administrowanie wersjami tych obiektów. W przeciwnym razie, będzie to bezwartościowe, bo każdy programista czy analityk, będzie się głowił, czy diagram, który widzi to jest akurat aktualna wersja. Oczywiście, są obiekty, których ilustracje, ze względu na ważność tych obiektów, muszą pojawić się w wielu dokumentach. Jeżeli zmieni się obiekt, który jest bardzo ważny w architekturze systemu, to wtedy nie ma wyjścia dokumentacja musi być uaktualniona. Jeżeli jednak w dokumentacji Strona 19 z 34

20 umieścimy szczegółowe diagramy obiektów poślednich, to skazujemy się na pracochłonne uaktualnianie prawie wszystkich dokumentów po każdym cyklu rozwoju oprogramowania. Dokumentacja użytkownika W bardzo wielu projektach dokumentację użytkownika piszą programiści. Nie piszą jej dlatego, że mają żyłkę do znajdowania najbardziej prostych opisów złożonych zjawisk. Ani nie piszą jej dlatego, że rozkoszują się zabawą słowem. Najczęściej, programiści piszą dokumentację, bo muszą. Jeżeli oczarowuje nas jakość dokumentacji tworzonej przez renomowane firmy, to proszę pozwolić, że opiszę jak wygląda proces jej wytwarzania. Zajmuje się tym osobny dział, składający się z ludzi, którzy potrafią dobrze pisać (pisać teksty do czytania a nie oprogramowanie). Ponieważ takim ludziom zdarza się nie znać od środka zagadnienia, o którym piszą, robią tak: na podstawie wymagań piszą pierwszą wersję. Potem dają tę wersję do przejrzenia programistom i testerom, którzy opisywaną funkcjonalność implementowali i testowali. Nanoszą oni uwagi i dokument jest poprawiany. Jeżeli trzeba, cykl jest powtarzany. A pod sam koniec, dokumentacja jest testowana (tzn. próbuje się wykonywać poszczególne funkcje programu kierując się instrukcjami z dokumentacji). Sami musimy ocenić czy nasz projekt na to stać czy nie (dotyczy to zwłaszcza niedużych projektów tworzonych przez małe i średnie firmy). 3. Narzędzia Po pierwsze narzędzia wspomagające proces testowania i zarządzania nim są drogie. Istnieją oczywiście darmowe narzędzia (Open Source) i wiele z nich ma bardzo dobrą reputację. Jednak wciąż pokutuje mit (moim zdaniem - fałszywy), że dla narzędzi Open Source nie ma wsparcia. Mit wzmocniony jeszcze propagandą firm komercyjnych (patrz FUD, Odstrasza to skutecznie wielu managerów. Po drugie musimy mieć na uwadze, że wbrew temu, co mówią często materiały marketingowe, korzystanie z narzędzi komercyjnych wcale nie jest proste. Nie jest proste skonfigurowanie ich w sposób w pełni odpowiadający naszym potrzebom. Nie jest także proste nauczyć się nimi efektywnie posługiwać. Każdy projekt ma swoje niuansiki i przystosowanie narzędzia do tych niuansików wymaga dużej wiedzy i czasu (albo pieniędzy na konsultanta, który to zrobi, (jeżeli to możliwe) i wystawi rachunek nie za rozwiązanie, lecz za spędzony w projekcie czas). Pamiętajmy, że znane pakiety dają nie tylko oprogramowanie narzędziowe. Dają one też metodologię, którą do jakiegoś stopnia będziemy musieli wdrożyć w projekcie. Uwzględnijmy to i dodajmy do kosztów licencji i wsparcia technicznego. Weźmy też pod uwagę, że wdrożenie nowego narzędzia w jednym departamencie, może za sobą pociągnąć konieczność wdrożenia tego narzędzia w departamentach współpracujących. Wtedy suma cen licencji zaczyna gwałtownie rosnąć. Komercyjne narzędzia nęcą też bardzo ciekawymi funkcjami, które zaimplementowane w projekcie, mogą rzeczywiście wnieść nową jakość do procesu. Bądźmy jednak czujni. Często się okazuje, że skorzystanie z tej funkcjonalności wymaga podporządkowania się pewnym regułom, które mogą być trudne lub prawie niemożliwe do spełnienia (przynajmniej w naszym projekcie). Ale tak nie musi być zawsze. Jeżeli uznamy jakąś funkcjonalność za pociągającą, sprawdźmy, co dokładnie musimy zrobić, aby móc z niej skorzystać. Może akurat w przypadku naszego projektu nie będzie trzeba zrobić wiele a zyski będą znaczące. Musimy to sami ocenić. 4. Zapewnianie jakości kodu Poza dbaniem o dobrą dokumentację, jakość można też podnieść wdrażając procedury polepszające proces kodowania. Chyba we wszystkich poważnych tekstach na temat tworzenia dobrego kodu jest jasno powiedziane, że najlepszą metodą jego weryfikacji, jest przejrzenie go przez innych. Nazywa Strona 20 z 34

21 się to code walkthrough lub code review (code walkthrough to analiza programu przez wykonanie go w myśli linia po linii). Bez wątpienia jest to metoda skuteczna, ale bardzo droga. Kod nie przejrzy się sam. Muszą na to poświęcić czas inni programiści. Żeby ich komentarze były coś warte, muszą mieć oni czas, aby "wgryźć" się w kod. W przeciwnym razie nie będą mieli do powiedzenia nic bardziej odkrywczego ponad to, że wcięcia im się nie podobają lub, że nazwa zmiennej jest myląca. Są też narzędzia typu Bounds Checker, które pozwalają badać kod w trakcie uruchomienia. Sprawdzają na przykład czy nie ma jakichś dziwnych alokacji lub dealokacji pamięci. Z cenami takich narzędzi jest różnie. BoundsChecker CompuWare kosztuje 800$. Nie mam doświadczenia z tym narzędziem, ale opinie, które znalazłem na jego temat są w przeważającej mierze pozytywne. Ja korzystałem z Rational Purify. Są też narzędzia Open Sourcowe tu też nie mam doświadczenia. Z tego co wiem nowe wersje kompilatorów i środowisk deweloperskich mają wbudowane tego typu narzędzia. Ogólnie oceniam, że nie jest to zła rzecz. Uruchomienie tego nie zajmuje znowuż tak dużo czasu, a uzyskane informacje są cenne. Należy jednak pamiętać o tym, że kod uruchamiany w takim trybie potrzebuje więcej zasobów komputera. Te jednak są tanie, więc warto się tym tematem zainteresować. 5. Planujmy uwzględniając nasze realne możliwości Zanim zaplanujemy, co będzie robione w projekcie, aby polepszyć jakość, zastanówmy się, na co nas stać. Weźmy pod uwagę budżet, ilość ludzi i terminy. Musimy też sobie uczciwie odpowiedzieć na pytanie czy implementujemy procedury zapewnienia jakości, bo chcemy być kryci przed zwierzchnikami lub czy dlatego że chcemy zwiększyć prawdopodobieństwo produkcji lepszego kodu. Jeżeli tylko chcemy być kryci, to właściwie nie widzę jakiś konkretnych barier dla naszej kreatywności. Możemy wymyślać, jakie tylko chcemy procedury. Programiści zapewnią, że to wszystko będzie działać. Będą tworzone na czas odpowiednie dokumenty, rysowane diagramiki, dostarczane będą rezultaty testów. To nic, że dokumentacja będzie bezwartościowa i niezrozumiała. To nic, że diagramy będą nieaktualne. To nic, że jak się przyjrzymy testom, to stwierdzimy, że są napisane tak, żeby zawsze przechodziły. I to nic, że oprogramowanie nie będzie działać. Przecież to nie o to w tym chodzi. Chodzi o możliwość wykazania, że trzymaliśmy się procedur. A programiści chętnie pomogą, bo zawsze znajdą sposób, żeby spełnić wymogi procedury. Każdej. Pamiętajmy: W obliczu deadline-u, wszystkie procedury mogą zostać ominięte i oszukane. Programista musi być tylko wystarczająco inteligentny i chcieć. A chcieć znaczy móc. A w obliczy perspektywy pracy w wariackich nadgodzinach, chęć pojawi się sama. Jeżeli jednak chcemy zrobić coś żeby produkt był lepszy to starajmy się unikać tworzenia zasad, które raczej na pewno będą łamane, bo będą nierealistyczne. Prawo, które musi być łamane jest demoralizujące. Starajmy się utworzyć zbiór zasad, które będę możliwe do spełnienia. Stawiajmy realistyczne wymagania i wtedy egzekwujmy je z całą bezwzględnością. 6. Sugerowane minimum Oto moje realistyczne minimum, będące wynikiem moich obserwacji w trakcie 8 lat pracy przy wytwarzaniu oprogramowania: Dobrze spisane wymagania Z biznesowego punktu widzenia, jest to jeden z najważniejszych dokumentów. To on opisuje, jaką funkcjonalność ma program zawierać. Powyżej przekonywałem, że niektóre rzeczy można sobie darować, bo są za drogie i nie wnoszą aż tyle, aby warto było ponosić koszty z nimi związane. Ale dobrze spisanych wymagań nie możemy sobie darować. I jeżeli zamierzamy oszczędzać na tworzeniu dokumentacji, to na tworzeniu wymagań powinniśmy starać się oszczędzić jak najmniej. Dobrze spisane wymagania mogą nas obronić przed Strona 21 z 34

22 żądaniami klienta, który twierdzi, że zrozumiał, że funkcjonalności będzie dwa razy więcej od tej, którą mu dostarczono. Źle spisane - są w statystykach źródłem największych strat finansowych w informatyce. Pisanie dobrych wymagań to bezcenna umiejętność i wielka sztuka, którą się zgłębia przez całe życie. Komentarze w kodzie Każda funkcja w kodzie powinna zawierać krótki opis co dana funkcja robi. Każdy moduł powinien mieć nagłówek, z krótkim opisem co dany moduł robi. (Wiem, wiem - to oczywiste. Wciąż jednak ta reguła nie jest przestrzegana, nawet w firmach przez duże F). Zrozumiała, krótka dokumentacja techniczna Do każdego większego modułu powinien istnieć odpowiedni, co najwyżej kilkustronicowy dokument. Powinien on przedstawiać - możliwie najprostszym językiem i używając klarownych ilustracji - funkcjonalność modułu. Stylem powinien bardziej przypominać opowiadanie niż specyfikację techniczną. Celem tego dokumentu jest danie osobie czytającej wyobrażenia do czego moduł tak naprawdę służy i na jakiej zasadzie działa. Jeżeli dokumentację czyta osoba nietechniczna, to ten poziom szczegółowości jest z zasady wystarczający. Jeżeli czyta ją programista i potrzebuje więcej szczegółów, może ich poszukać w kodzie źródłowym modułu. Jeżeli kod będzie miał te minimum komentarzy, o których mówię powyżej i programista będzie znał przeznaczenie i ogólne zasady działania modułu wtedy poruszanie się po kodzie będzie dużo łatwiejsze. System kontroli wersji. Istnieją co najmniej 2 darmowe, sprawdzone przez rzesze informatyków, narzędzia do kontroli wersji RCS i CVS. Nie znam żadnego racjonalnego powodu, żeby systemu kontroli wersji nie stosować. Znam za to szereg kataklizmów, jakie mogą być efektem nieużywania takich systemów. Stosujmy kontrolę wersji zarówno do kodu programu jak i do dokumentacji. Tylko po wdrożeniu tego minimum możemy zacząć myśleć o czymś bardziej zaawansowanym jak na przykład tworzenie szczegółowej dokumentacji technicznej czy też wdrożenie systemu zarządzania testami, automatyzacji testów etc. Jeżeli nie mamy zasobów do wdrożenia tego minimum to nasz projekt można porównać do spaceru po linie na przepaścią. Widzę 3 wytłumaczenia takiej sytuacji: Znaczny rozrost wymagań w trakcie projektu (scope creep) Ktoś planujący budżet projektu nie za bardzo się na planowaniu znał Ktoś planujący budżet projektu znał się na tym, ale planowane zyski ze zrealizowania projektu są tak wysokie, że zaakceptowano tak wysokie ryzyko. Warto mieć świadomość, że brak tego minimum jakości, czyni projekt misją wysoce ryzykowną wtedy, gdy w projekcie pracuje 4-5 osób. Dla projektów 10 i więcej osobowych jest to już po prostu misja samobójcza. Na koniec jeszcze drobna sugestia: Preferujmy komunikację ustną nad pisemną przy przekazywaniu wiedzy Nie utrudniajmy testerom dostępu do programistów. Żaden dokument nie zastąpi rozmowy ze specjalistą/autorem modułu, który odpowie nam na nasze pytania. Jeżeli jest Strona 22 z 34

23 dostępna zarówno dokumentacja jak i programista modułu, nie skazujmy testera na czytanie dokumentacji pisanej przez programistów, którzy traktują dokumentację jako dopust boży. Pozwólmy testerowi porozmawiać z programistą. 7. Życie nie jest takie proste... Dla większości uogólniających tez i rad istnieją kontrprzykłady i dziedziny gdzie te tezy są fałszywe a rady się nie stosują. Mój artykuł nie jest tu wyjątkiem. I to jest nieuniknione. Jak już zaznaczyłem, zagadnienia zapewnienia jakości są zbyt złożone, żeby je podsumować na kilku stronach. Zdaję sobie sprawę, że to co piszę może nie przystawać (przynajmniej wprost) do rzeczywistości niektórych projektów. Niestety, nie tylko my (wytwórcy oprogramowania) decydujemy o tym, jaka ma być dokumentacja. Czasami klient narzuca nam, co ma być tworzone. Warto mieć przynajmniej świadomość, jakie koszty pociąga za sobą tworzenie dokumentacji. Może jak się to uświadomi klientowi, to zrezygnuje on z części dokumentów. Niektórzy są na wyrafinowane procedury zapewnienia jakości skazani z definicji - systemy sterowania elektrownią jądrową, systemy wojskowe, NASA (której próby oszczędzania nie wyszły na dobre). Dla tych firm dokumentacja jest nie tylko informacją techniczną. Jest też dowodem przy wystąpieniu jakichkolwiek problemów. A koszty ewentualnej awarii są tak wysokie, że wielokrotnie przewyższają ogromne nakłady na zapewnienie jakości. Pomimo to wciąż jest wiele projektów, gdzie takich odgórnych wymogów nie ma. I wtedy warto mieć świadomość, jakie dana procedura zapewniania jakości niesie ze sobą narzuty. Czasami są one tak duże, że lepiej ją sobie darować, bo jej wdrożenie zje czas i budżet naszego projektu. Strona 23 z 34