1. TESTER.PL
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. TESTER.PL
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.
2.
3.
4.
Bogdan Bereza Jarociński o potrzebie testowaniu, lekko i dowcipnie,
Lucjan Stapp o wpływie lekkiej metodyki XP na testowanie,
Piotr Kałuski o swoich doświadczeniach z kilku lat „walki” z papierkami,
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. TESTER.PL
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.
Strona 3 z 34

4. TESTER.PL
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.
Strona 4 z 34

5. TESTER.PL
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. TESTER.PL
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. TESTER.PL
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 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..
Strona 7 z 34

8. TESTER.PL
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. TESTER.PL
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. TESTER.PL
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.
Strona 10 z 34

11. TESTER.PL
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.
Strona 11 z 34

12. TESTER.PL
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. TESTER.PL
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)
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
Strona 13 z 34

14. TESTER.PL
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. TESTER.PL
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].
[2].
[3].
[4].
[5].
[6].
[7].
Beck, K., Extreme Programming Explained: Embrace Change, Addison-Wesley
Publish Co; 1999
Beck, K., Fowler, M., Planning Extreme Programming, Addison -Wesley Publishing
Co; 2001
Berbet, T., Extreme testing , www.ayeconference.com/articeles/extremetesting.html
Jeffries, R., Anderson, A., Hendrickson, C., Extreme Programming Installed, Addison
-Wesley Pub Co; 2001
www.extremeprogramming.org
www.junit.org
www.xptester.org
Strona 15 z 34

16. TESTER.PL
Strona 16 z 34

17. TESTER.PL
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.
Strona 17 z 34

18. TESTER.PL
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. TESTER.PL
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. TESTER.PL
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
Strona 20 z 34

21. TESTER.PL
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. TESTER.PL
żą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. TESTER.PL
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

24. TESTER.PL
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
Strona 24 z 34

25. TESTER.PL
-
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!
Strona 25 z 34

26. TESTER.PL
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.
Strona 26 z 34

27. TESTER.PL
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.
Strona 27 z 34

28. TESTER.PL
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.
Strona 28 z 34

29. TESTER.PL
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ą
Strona 29 z 34

30. TESTER.PL
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.1bin. 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.
Strona 30 z 34

31. TESTER.PL
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.
Strona 31 z 34

32. TESTER.PL
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.
Strona 32 z 34

33. TESTER.PL
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
Strona 33 z 34

34. TESTER.PL
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.
2.
3.
4.
www.pureload.com,
PureTest 3.1
Scenario Editor 3.1,
Testing Web Application 3.1
Strona 34 z 34