TESTER.PL

Strona 1 z 34

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

TESTER.PL

Strona 2 z 34

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

TESTER.PL

Strona 3 z 34

Tekst sponsorowany

Software-Konferencje Sp. z o.o. ul. Lewartowskiego 6 00-190 Warszawa tel.+ 48 (22) 860 17 22 fax.+ 48 (22) 860 17 71

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.

TESTER.PL

Strona 4 z 34

Szczegółowe informacje na temat organizowanych szkoleń znajdą Państwo na stronie: www.konferencje.software.com.pl 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.

TESTER.PL

Strona 5 z 34

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.

TESTER.PL

Strona 6 z 34

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

TESTER.PL

Strona 7 z 34

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 coca-coli, 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 2001 – 2002 –2003 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..

TESTER.PL

Strona 8 z 34

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.

TESTER.PL

Strona 9 z 34

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

TESTER.PL

Strona 10 z 34

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, e-mail: lstojek@mercury-eur.com.

TESTER.PL

Strona 11 z 34

eXtreme TESTING (TESTOWANIE EKSTREMALNE)

Lucjan Stapp

Wydział Matematyki i Nauk Informacyjnych

Politechnika Warszawska www.mini.pw.edu.pl/~lucjan

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.

TESTER.PL

Strona 12 z 34

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

TESTER.PL

Strona 13 z 34

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ą bez-wzglę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) 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.

(II) By to osiągnąć, należy wzmocnić współpracę testerów i deweloperów. Osiągnąć to można poprzez

TESTER.PL

Strona 14 z 34

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.

TESTER.PL

Strona 15 z 34

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 , www.ayeconference.com/articeles/extremetesting.html [4]. Jeffries, R., Anderson, A., Hendrickson, C., Extreme Programming Installed, Addison

-Wesley Pub Co; 2001 [5]. www.extremeprogramming.org [6]. www.junit.org [7]. www.xptester.org

TESTER.PL

Strona 16 z 34

TESTER.PL

Strona 17 z 34

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 www.piotrkaluski.com.

TESTER.PL

Strona 18 z 34

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

TESTER.PL

Strona 19 z 34

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

TESTER.PL

Strona 20 z 34

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, http://en.wikipedia.org/wiki/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

TESTER.PL

Strona 21 z 34

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

TESTER.PL

Strona 22 z 34

żą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

TESTER.PL

Strona 23 z 34

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.

TESTER.PL

Strona 24 z 34

Tekst sponsorowany

Szanowni Państwo,

Chciałabym bardzo serdecznie zaprosić Państwa do udziału w kursie pt. Certyfikowany Test Manager, który odbędzie się w dniach 30 sierpnia – 1 września 2004 r. w Warszawie. Ten trzydniowy, certyfikowany kurs da Państwu wiedzę na temat technicznych i organizacyjnych aspektów procesu testowania. Udział w tym spotkaniu umożliwi Państwu efektywne i optymalne wykorzystanie angażowanych w testowanie zasobów. Najważniejsze zagadnienia kursu:

Zasady testowania systemów informatycznych Projekt budowy systemu informatycznego Miejsce testów w procesie budowy systemu informatycznego Formalna rola i zadania szefa zespołu testowania Normy i standardy odnoszące się do wytwarzania systemów informatycznych

Szczegółowy program kursu „Certyfikowany Test Manager” dostępny jest pod adresem www.iir.pl/sem/WC0027.html W trakcie kursu będzie miało miejsce sprawdzenie nabytych przez Państwa umiejętności na podstawie praktycznych testów. Zdobyta wiedza potwierdzona zostanie wspólnym certyfikatem wystawionym przez Stowarzyszenie Jakości Systemów Informatycznych - partnera merytorycznego tego kursu oraz IIR. Certyfikat będzie udokumentowaniem Państwa fachowej wiedzy. W razie jakichkolwiek pytań proszę o kontakt pod nr tel. (022) 520 09 00 w. 120 lub za pośrednictwem poczty elektronicznej: ekowalska@iir.pl Z poważaniem

Ewa Kowalska Conference Director Institute for International Research Sp. z o.o. Polecamy również seminaria:

- Efektywne metody i techniki zarządzania ludźmi dla managerów IT – 23-24 sierpnia 2004 r., Warszawa

- Zarządzanie finansowe – 24-25 sierpnia 2004 r., Warszawa - Zarządzanie incydentem, zarządzanie problemem – 30-31 sierpnia 2004 r., Warszawa - Service Level Agreements wobec klienta wewnętrznego – 2-3 września 2004 r., Warszawa

TESTER.PL

Strona 25 z 34

- Certyfikowany IT-Security Manager – 13-17 września 2004 r., Warszawa - Kompleksowe zarządzanie usługami IT – 21-22-23 września 2004 r., Warszawa - Aspekty prawne i formalne umów IT – 27-28 września 2004 r., Warszawa - Certyfikowany HelpDesk Manager – 11-15 października 2004 r., Warszawa - Bezpieczeństwo informacji – 11-12-13 października 2004 r., Warszawa

szczegółowe informacje można znaleźć na stronie www.iir.pl Institute for International Research, największa międzynarodowa firma organizująca konferencje i seminaria przede wszystkim dla najwyższej kadry zarządzającej, obecna jest na rynkach światowych od prawie 30 lat a w Polsce od ponad ośmiu. Jest dla nas niezwykle ważne aby być postrzeganym przez naszych klientów przez pryzmat jakości usług i prestiż. Właśnie dzięki prestiżowi oraz temu, że jesteśmy całkowicie niezależną i neutralną instytucją, możemy liczyć na wsparcie wszystkich ważnych uczestników życia gospodarczego, najbardziej opiniotwórczych mediów a także przedstawicieli rządu. Biorąc pod uwagę wyłącznie rynek polski rocznie przygotowujemy prawie dwieście tematów dla ponad dwóch tysięcy uczestników. Nasz system pracy pozwala na pełną elastyczność i szybkie reagowanie na zmiany, podejmowanie coraz to nowych tematów i proponowanie ich w formie dostosowanej do poziomu i potrzeb potencjalnych uczestników (konferencje, seminaria, warsztaty, kursy certyfikowane, seminaria „in-house” etc.) Wydarzenia IIR wspierane są hasłem „wiedza najwyższej próby”. Taka dewiza zobowiązuje, więc począwszy od pomysłu na każdy z tematów, które podejmujemy, poprzez zaproszenie najlepszych prelegentów aż do wyboru miejsca, gdzie odbywa się seminarium czy konferencja, wybieramy zawsze tę „najwyższą próbę” - możemy więc liczyć na zgłoszenia najlepszych delegatów. U nas wiedzę poszerzają eksperci!

TESTER.PL

Strona 26 z 34

PureTest – automatyczne testowanie za darmo

Robert Rzeszotek Impaq

rrzeszotek@impaq.com.pl

Robert Rzeszotek Jest analitykiem do spraw Zapewnienia Jakości w firmie Impaq. Zajmuje się testowaniem oprogramowania od 2 lat. Uczestniczył - od strony zapewnienia jakości - w projektach z branż: telekomunikacja, finanse, sektor publiczny.

TESTER.PL

Strona 27 z 34

PureTest – automatyczne testowanie za darmo

Robert Rzeszotek Impaq

rrzeszotek@impaq.com.pl

Wszyscy w swej codziennej pracy borykamy się z problemem powtarzania testów, co pochłania dodatkowo jakże cenny nasz czas. Automatyzacja testów szczególnie funkcjonalnych pozwala nam na oszczędność czasu. Przegotowane i nagrane raz scenariusze testowe umożliwiają kolejne wykonanie testów oszczędzając czas. Po uruchomieniu narzędzia wykonuje ono za nas zadania testowe, nam pozostaje jedynie odczytać wyniki wykonanych zadań oraz ich zaraportowanie (oczywiście tylko wtedy gdy narzędzie nie posiada modułu do raportowania). Barierą w tym przypadku są oczywiście koszty związane z zakupem licencji na oprogramowanie wspomagające proces testowania. W wielu przypadkach bardziej opłacalnym jest by tester sprawdził jeszcze raz wszystkie scenariusze niż zakup drogiego oprogramowania. Niniejszy problem będę się starał rozwiązać poprzez prezentację darmowych narzędzi do testowania. Pierwszym z narzędzi jest PureTest.

Rozwiązanie Pure oferuje zintegrowane rozwiązanie to testowania i weryfikacji aplikacji serwerowych. Zawiera ono PureTest narzędzie do testów funkcjonalnych, PuteLoad to testów obciążeniowych oraz PureAgent do monitorowania wyników.

Niestety tylko PureTest jest darmowym narzędziem z całego pakietu. Może on działać samodzielnie bez pozostałych narzędzi.

W niniejszym artykule zostanie przybliżona konfiguracja tego narzędzia, opis przygotowywania scenariuszy testowych, wykonywanie scenariuszy testowych i odczyt wyników wykonanych testów.

PureTet jest napisany w Javie i powinien pracować na każdej platformie z wspomaganiem Java 2.

PureTest posiada graficzny interfejs używany do projektowania scenariuszy, ustawiania parametrów testowych jak również generator danych.

Rys. 1 Graficzny interfejs PureTest.

TESTER.PL

Strona 28 z 34

PureTest zawiera dwa narzędzia umożliwiające testowanie aplikacji okienkowych. Web Crawler Sprawdza i liczy na stronie informacje o źródłach, zerwanych linkach, statystykach itp.

Rys. 2 Okno ustawień Web Crawlera.

Działanie Web Crawlera jest bardzo proste. Należy wpisać stronę, którą chcemy przetestować zdefiniować, ograniczenie do domeny, serwera bądź bez ograniczeń, poziom zagłębienia, wybrać z menu Run -> Start Crawler lub wybrać przycisk . W wynikach otrzymujemy następujące informacje:

- statystyki zawierające liczbę zasobów z podziałem na rodzaje plików, wielkość zasobów z podziałem na rodzaje plików,

- widok na strukturą testowanej strony oraz na ewentualne błędy. W oknie tym możemy wyśledzić zerwane linki wraz z ich lokalizacją, obejrzeć listę wszystkich stron wraz z opisem ich rozmiaru, liczby linków przychodzących i wychodzących, informacje o rodzajach plików jakie zawiera strona.

HTTP Recorder – konfiguracja, nagrywanie i odtwarzanie scenariuszy testowych.

Nagrywa wszystkie odpowiedzi i parametry pomiędzy przeglądarką internetową a serwerem. Rezultaty nagrywania są uporządkowane w scenariuszu zawierającym kolejne zadania testowe oraz indywidualne zadania reprezentujące każdą odpowiedź HTTP.

Poniższy rysunek ilustruje środowisko dla HTTP Recorder. HTTP Recorder uruchamia się z konsoli PureTesta używając menu: Tools -> HTTP

Recorder.

TESTER.PL

Strona 29 z 34

Rys.3 Okno dialogowe HTTP Recorder

Uruchamiając HTTP Recorder najpierw należy go skonfigurować. W zakładce

Właściwości należy ustawić parametry Proxy Serwera. Najważniejsze z nich to parametry: Host: localhost, Port: 7070. Kolejnym krokiem jest konfiguracja proxy dla przeglądarki internetowej. Opisana tu zostanie najpopularniejsza przeglądarka internetowa Internet Explorer. Konfiguracja IE przebiega następująco: Narzędzia -> Opcje -> Połączenia -> LAN Ustawienia -> Zaawansowane. Ustawiamy Proxy Serwer, definiując HTTP i Secure podając port. Konfigurację obrazują poniższe rysunki.

Rys. 4 Konfiguracja przeglądarki IE.

Po skonfigurowaniu HTTP Recordera można rozpocząć nagrywanie skryptu.

Wykonamy prosty test na logowanie się do aplikacji. Scenariusz testowy logowania zostanie nagrany tylko dla jednego użytkownika. Dane wejściowe zostaną dodane za pomocą

TESTER.PL

Strona 30 z 34

Generatora parametrów. Danymi wejściowymi będzie lista kilku użytkowników z podanymi ID i hasłami.

Rozpoczęcie nagrywania rozpoczynamy przez wybranie Run -> Start Proxy bądź używając przycisku . Nagrywanie zostaje uruchomione i możemy zacząć wykonywać zadanie w przeglądarce internetowej. Wykonujemy czynności, które chcemy by zostały nagrane w naszym przypadku wpisujemy ID i hasło w ekran logowania i potwierdzamy. HTTP Recorder nagrywa i konwertuje zadanie i pokazuje w okienku Scenaruisz rezultaty nagrywania.

Po zakończeniu zadania w przeglądarce należy zatrzymać nagrywanie przez wybór Run -> Stop Proxy lub używając przycisku Stop.

Po zatrzymaniu należy zapisać nagrany skrypt najlepiej w katalogu ..\PureTest_3.1\bin. Zapisanie w tym katalogu oszczędzi nam wpisywania lokalizacji pliku podczas wykonywania scenariusza testowego.

Aby edytować skrypt należy otworzyć go w PureTest. W oknie możemy zdefiniować ilość iteracji danego scenariusza, jego nazwę, czas odpowiedzi, adres strony, parametry wejściowe dla danego skryptu, kody odpowiedzi pozwalające na identyfikowanie problemu podczas odtwarzania skryptu.

Rys. 5 Okno edycji scenariusza testowego.

Dane wejściowe mogą być eksportowane z Generatora parametrów. Definiujemy

generator w zakładce Parametry Generatora. Wybierając View->Create możemy dodać źródło danych. Są cztery możliwości generowania danych: Counter – generator liczb, który generuje liczby od – do w zależności, jaki zakres nas interesuje. File – generuje dane z pliku. Można eksportować dane np. z MS Excela. List – generuje dane z listy, którą użytkownik sam tworzy na potrzeby testu. Calendar – Generuje dane kalendarzowe.

TESTER.PL

Strona 31 z 34

Rys. 6 Okno dialogowe zakładki Generatora parametrów.

Mając nagrany podstawowy test logowania możemy dodać do niego listę logujących

się użytkowników. W tym celu używamy zakładki Generator parametrów. Dla naszych celów opisze to na przykładzie danych exportowanych z pliku oraz z listy. W pliku definiujemy użytkowników używając do tego celu np. excela zapisując plik w formacie csv. Listę danych tworzymy używając przycisku Add i wpisując dane wejściowe. Przycisk Test pozwala na sprawdzenie danych w jaki sposób będą używane w scenariuszu testowym.

Rys. 7. Zdefiniowana lista danych wejściowych.

Zdefiniowanie pliku wejściowego z danymi polega na podaniu nazwy generatora,

podaniu jego lokalizacji, separatora pól w pliku oraz danych z pliku. Przycisk Test służy jak w poprzednim przypadku służy do sprawdzenia danych wejściowych.

TESTER.PL

Strona 32 z 34

Funkcja ta jest szczególnie przydatna jeśli do danego scenariusza testowego używamy różnych danych wejściowych. Tego typu funkcje są również przydatne do testów obciążeniowych i stabilnościowych.

Rys.8 Zdefiniowane dane z pliku.

Dane z generatora można podpiąć do skryptu w okienku HTTP Parametry. W

kolumnie Wartości należy podpiąć dane z genaratora. Klikamy w kolumnie na „...” i ybieramy interesujący nas generator poprzednio zdefiniowany. W naszym przypadku jest to dla klucza j_username lista a dla j_password plik.

Rys. 9 Okno zadań podczas definiowania generatora danych wejściowych.

TESTER.PL

Strona 33 z 34

Rys. 10. Okno po zdefiniowaniu generatora danych.

By test był wykonany dla czterech użytkowników w polu Iteracje ustawiamy na 4.

W polach gdzie został podpięty generator danych pojawiły się czerwone znaczniki ˇ. Tak przygotowany scenariusz po zapisaniu jest gotowy do uruchomienia. Wykonywanie test skryptów

Wykonywanie test skryptów odbywa się w Linii komend. Uruchomienie skryptu odbywa się przez wpisanie komendy w katalogu gdzie jest zainstalowany PureTest: puretest runner <katalog gdzie zapisany jes plik> nazwapliku.plc.

Rys. 11 Okno Linii komend podczas uruchamiania i odczytywania wyników.

W naszym przypadku test się nie powiódł. Została wyświetlona informacja o

przyczynie niepowodzenia testu, czasie wykonania zadania. W naszym przypadku był to problem z połączeniem się do serwera testowego. Jeśli zadany czas zadania zostanie przekroczony pojawi się informacja: 1 timeout.

Gdy jest wykonany test skrypt również w Linii komend jest wyświetlany rezultat testu.

PureTest jest łatwym w użyciu narzędziem do testowania aplikacji „okienkowych”. Podczas moich prac z tym narzędziem używałem go głównie to testów wydajnościowych

TESTER.PL

Strona 34 z 34

i stabilnościowych korzystając z generatora parametrów. Również za pomocą tego generatora szybko napełniałem bazę danych co było bardzo pomocne w testach stabilnościowych. Wykonywanie testu realizowane jest w Linii komend, co może nie jest zaletą w czasach aplikacji okienkowych ale jednak ma i swoje plusy. Jednym z takich plusów jest prostota, z jaką można uruchamiać zestaw testów jeden za drugim. Możemy to zrobić pisząc komendy DOSowe uruchamiające kolejno skrypty testowe i zapisać je w pliku .bat. Rezultaty również są wyświetlane w Linii komend, więc chcąc sporządzić raport z wykonanych testów należ przejrzeć listę w Linii komend. Czyni to PureTesta trochę niedoskonałym gdyż większość narzędzi szczególnie płatnych posiada moduły raportujące wyniki wykonanych testów. W testach funkcjonalnych PureTest wypada trochę gorzej niż w testach wydajnościowych. Narzędzie cały skrypt testowy wykonuje w tle, więc nie widzimy jakie wykonuje operacje ani jakie komunikaty się pojawiają. Podczas prac z PureTestem pojawił się kolejny mankament, jakim jest nie sprawdzanie walidacji w polach aplikacji. PureTest zapisywał wszystkie dane pomimo tego, że aplikacja nie pozwalała tego zrobić podczas nagrywania scenariusza testowego.

Opisane funkcje narzędzia, są tylko podstawowymi funkcjami umożliwiającymi stworzenie prostego scenariusza testowego. Jednak narzędzie posiada również możliwość rozbudowy skryptów umożliwia to zakładka Typ zadania.

Zainteresowanych pogłębieniem wiedzy na temat tego narzędzia odsyłam do literatury.

1. www.pureload.com, 2. PureTest 3.1 3. Scenario Editor 3.1, 4. Testing Web Application 3.1