TESTER.PL

Strona 1 z 49

Rozpoczął się nowy rok, który winien przynieść nowe pomysły i perspektywy. Każdy z nas stawia sobie kolejne cele i wyzwania.

Podobnie SJSI postawiło sobie cele na ten rok. Pod koniec lutego wspólnie z IIR organizujemy II edycję warsztatów Certyfikowany Test Manager. W drugiej połowie maja mamy zamiar zorganizować II edycję konferencji SJSI.

Jesteśmy partnerem dla dużej i prestiżowej konferencji ICSTEST, która odbędzie się w dniach 6-8.04.2005 w Dusseldorfie. W Państwa ręce oddajemy trzeci numer kwartalnika TESTER.PL. Wszystko wskazuje na to, że ukażą się kolejne.

Spójrzmy przez chwilę na to, co udało się nam osiągnąć w ubiegłym roku.

Aktualnie w szeregach Stowarzyszenia jest prawie 100 „zadeklarowanych” członków, przy czym stale korespondujemy z ponad 200 osobami. Kilka dużych firm jest naszymi członkami wspierającymi. Kolejnych kilka zadeklarowało chęć współpracy. Cześć członków Stowarzyszenia aktywnie uczestniczy w pracach International Software Testing Qualification Board. Co miesiąc spotykamy się na ciekawych wykładach na Politechnice Warszawskiej. Z sukcesem zorganizowaliśmy I konferencję SJSI (sprawozdanie na www.sjsi.org oraz w niniejszym wydaniu kwartalnika).

Korzystając z okazji, wszystkim członkom, współpracownikom i naszym „dobrodziejom” składam w imieniu Zarządu Stowarzyszenia życzenia sukcesów i wszelkiej pomyślności w 2005 roku.

Z pozdrowieniami

W imieniu Zarządu

Wojciech Jaszcz

Prezes SJSI

TESTER.PL

Strona 2 z 49

Od redaktora

Wraz z początkiem Nowego Roku (w połowie lutego ☺) dostajecie kolejny – już trzeci - numer kwartalnika TESTER.PL.

W tym numerze cztery pozycje:

1. Bogdan Bereza Jarociński o certyfikatach w testowaniu, ich rodzajach, zaletach i wadach

2. Wywiad z James Bachem, guru lekkich metodyk testowania - dzięki uprzejmości Mariusza Janczewskiego

3. Piotr Kałuski o narzędziu L- Report, open source’owym projekcie ułatwiającym prace testerom

4. Robert Rzeszotek o BadBoy’u – kolejny artykuł o automatach wspomagających testowanie Numer otwiera sprawozdanie Wojciecha Jaszcza z I Konferencji Stowarzyszenia

Jakości Systemów Informatycznych, która odbyła się w Zegrzu, w dniach 18 – 19 listopada 2005. Jako jej uczestnik, pozwolę sobie stwierdzić, że była to bardzo udana impreza i z radością witam informację o kolejnej jej edycji.

W numerze także zaproszenie na System & Software Quality Conferences w Dusseldorfie. Jeśli ktoś ma tylko możliwość, by tam być na początku kwietnia, gorąco polecamy. Nasze Stowarzyszanie jest jedną z organizacji wspierających dla tej bardzo ciekawej konferencji, a właściwie trzech konferencji przeprowadzanych równocześnie. Jeżeli ktoś z Państwa będzie uczestniczył w System & Software Quality Conferences, będziemy wdzięczni za przekazanie nam swych wrażeń, wskazania nowych kierunków w teorii i praktyce zwiększania jakości oprogramowania.

Chciałbym także zwrócić uwagę na informację o konferencji (z warsztatami) Certyfikowany Test Manager, które nasze Stowarzyszenie przeprowadza wspólnie z IIR. Szkolenie odbędzie się w Warszawie, w drugiej połowie lutego.

Chciałbym gorąco zachęcić wszystkich czytelników tego periodyku do aktywnej współpracy. Cały czas czekamy na Państwa uwagi, artykuły, felietony – wszystko, co Was interesuje, co chcielibyście przeczytać, czego się dowiedzieć. Jeżeli tylko będziemy mogli, postaramy się zrealizować Państwa postulaty.

Na „pokładzie” redakcyjnym witamy równocześnie nowego członka, p. Kamilę Dec z Poznania. Dzięki jej istotnemu wkładowi w działalność redakcyjną dostajecie dziś, Drodzy Czytelnicy, ten numer TESTERA.PL

TESTER.PL

Strona 3 z 49

I Konferencja

Stowarzyszenia Jakości Systemów Informatycznych

W dniach 18-19 listopada 2004, nad Zalewem Zegrzyńskim koło Warszawy odbyła się I konferencja SJSI. Pomimo, że pogoda nie rozpieszczała (przypomnę – był pierwszy atak zimy i jazda przez Warszawę trwała do 2godziny), to w Hotelu 500 w Zegrzu zebrało się prawie 70 osób.

Pierwszym punktem programu był panel o wiele mówiącej nazwie „good enough quality”, który poprowadziła Lilianna Wierzchoń. Debata trwała prawie dwie godziny, co świadczy z jednej strony o burzliwej dyskusji wśród uczestników konferencji, a z drugiej o rzeczywistej potrzebie dialogu w tej materii. W „komisji” panelowej, obok prowadzącej Lilianny Wierzchoń, zasiedli: Tomasz Byzia, Wojciech Jaszcz, Lucjan Stapp oraz Piotr Wąsikowski.

Pomimo jesienno-zimowej, ponurej aury, wykłady, które odbyły się pierwszego dnia wzbudziły niemałe zainteresowanie. Wśród tematów, jakie zostały poruszone warto wymienić prelekcje dotyczące najnowszej normy ISO/IEC 90003:2004 (Bolesław Szomański), wdrożeń standardów jakości w organizacji (Maciej Bodych), metody wyboru miar GQM (Joanna Nowakowska), sposobu projektowania przypadków testowych przy wykorzystaniu analizy biznesowej w UML (Lucjan Stapp) oraz warsztaty z organizacji procesu zarządzania zespołem QA (Marcin Stachura). Pierwszy dzień zakończyła uroczysta kolacja, dyskusje kuluarowe zaś trwały do późnych godzin nocnych.1

Drugi dzień konferencji był w większości poświęcony narzędziom związanym z automatyzacją procesu testowania. Swoje rozwiązania przedstawiła firma Compuware (Główny Sponsor konferencji). Sposób, w jaki skutecznie i opłacalnie wykorzystać profesjonalne narzędzia w dużej korporacji, zaprezentowała firma ComputerLand S.A.

Kolejne, niezwykle ciekawe wykłady dotyczyły sposobu na integrację nazywanego Continuous Integration (Jan Topiński), narzędzi do automatycznego tworzenia dokumentacji (Michał Rowicki, Piotr Krachel), sposobów generowania danych testowych (Jan Sabak), sposobu przeprowadzania testów wydajnościowych aplikacji (Tomasz Wodziński, Wawrzyniec Żurowski) oraz narzędzi do raportowania wyników zapytań – LReport (Piotr Kałuski).

Wszystkim uczestnikom, prelegentom i sponsorom, bez których zorganizowanie tej konferencji byłoby niemożliwe, chcielibyśmy bardzo podziękować.

Liczymy na Waszą obecność i wsparcie kolejnych inicjatyw Stowarzyszenia Jakości Systemów Informatycznych!

Zarząd Stowarzyszenia Jakości Systemów Informatycznych

1 Jako uczestnik Konferencji, pozwolę sobie stwierdzić, że jest to pewne niedomówienie – dyskusje

kuluarowe trwały do wczesnych godzin rannych (Redaktor)

TESTER.PL

Strona 4 z 49

Sponsorzy:

- Sponsor Główny

- Sponsor

- Patron medialny

Prelegenci: Bodych Maciej, Premium Technology Sp. z o.o.

Byzia Tomasz, Premium Technology Sp. z o.o.

Dróżdż Marek, Compuware

Jaszcz Wojciech, ComputerLand S.A.

Kałuski Piotr, CGI

Krachel Piotr, Polkomtel S.A.

Mazur Michał, ComputerLand S.A.

Michalik Sławomir, Projekty Bankowe POLSOFT Sp. z o.o.

Nowakowska Joanna, Rodan Systems S.A.

Rowicki Michał Polkomtel S.A.

Sabak Jan, Infovide S.A.

Stachura Marcin, K2 Consulting Sp. z o.o.

Stapp Lucjan, Politechnika Warszawska

Szomański Bolesław, Politechnika Warszawska

Topiński Jan, Infovide S.A.

Wąsikowski Piotr, Sollers Consulting Sp. z o.o.

Wierzchoń Lilianna, ComputerLand S.A.

Wodziński Tomasz, Polkomtel S.A.

Żurowski Wawrzyniec, Polkomtel S.A.

TESTER.PL

Strona 5 z 49

Podziękowania: Szczególne podziękowania należą się Joannie Nowakowskiej, Wojciechowi

Jaszczowi, Adamowi Suskiewiczowi i Jankowi Sabakowi, bez których zaangażowania, profesjonalnego podejścia i niezwykłej umiejętności radzenia sobie w sytuacjach kryzysowych ta konferencja nie doszłaby do skutku, a także Joannie Wiśniewskiej i Sylwii Wicik oraz wszystkim życzliwym tu niewymienionym za pomoc w organizacji konferencji.

Zapraszamy na drugą edycję konferencji, która odbędzie się w dniach 20 – 21 maja 2005 roku.

Wszystkich chętnych zapraszamy do nadsyłania propozycji tematów referatów na adres: sjsi@sjsi.org.

TESTER.PL

Strona 6 z 49

Certyfikowany Test Manager

23-24-25 lutego 2005 r., hotel Bristol, Warszawa

Program seminarium Dzień pierwszy

Wprowadzenie Ogólne zasady budowy systemu informatycznego

Przykładowe metodyki stosowane przy realizacji projektów informatycznych

Klasyczna metodyka "kaskadowa"

Metoda "spirali"

Lekkie metodyki na przykładzie XP

Zasady i praktyka budżetowania projektów informatycznych - Jak powstaje budżet projektu

Zarządzanie wymaganiami

Współpraca niezbędnym czynnikiem sukcesu

Zarządzanie ryzykiem

Testowanie w różnych metodykach wytwarzania oprogramowania

Związek testów z etapami realizacji projektu: modele V i W

Test Driven Development

Zakres, przygotowanie oraz metody prowadzenia podstawowych poziomów testów

Testy modułów

Testy integracyjne "małe"

Testy systemowe

Testy integracyjne "duże"

Testy akceptacyjne

Testy pielęgnacyjne

Zakres, przygotowanie oraz metody testów właściwości

Testy wydajnościowe

Testy architektury i koncepcji

Testy użyteczności

Testy bezpieczeństwa

Inne

Testy regresji i ich rola w procesie testowania

Przeglądy

Przegląd wybranych norm związanych z jakością i testowaniem

TESTER.PL

Strona 7 z 49

Dzień drugi

Zarządzanie procesem testowym

Planowanie prac

Szacowanie pracochłonności

Struktura dokumentacji testowej

Przeprowadzenie testów

Rejestrowanie wyników testów

Kontrola postępu prac

Zarządzanie zgłoszeniami problemów i zmian

Zarządzanie wersjami oprogramowania i danych

• Definicja testware ("testaliów")

• Zarządzanie wersjami

• Metody opisu i przechowywania przypadków i scenariuszy testowych

Dzień trzeci

Zarządzanie procesem testowym - cd

Zarządzanie środowiskami o Struktura środowiska testowego o Testy w projekcie rozproszonym

Testowanie a zmiany wymagań

Jakość procesu testowego

Kryteria oceny jakości systemu informatycznego

Narzędzia

Egzamin

Kierowanie zespołem testów

Budowanie zespołu

Role w zespole

Cechy dobrego testera

Zadania szefa zespołu

Przywództwo

Zarządzanie konfliktem

Sztuka kompromisu

Podsumowanie

Wręczenie certyfikatów

TESTER.PL

Strona 8 z 49

TESTER.PL

Strona 9 z 49

Międzynarodowe i krajowe certyfikaty w dziedzinie zapewnienia jakości i testowania oprogramowania

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 prowadzić szkolenia z dziedziny testowania. Od 2002 roku prowadzi w Polsce szkolenia m. in. na certyfikat ISEB.

TESTER.PL

Strona 10 z 49

Międzynarodowe i krajowe certyfikaty w dziedzinie zapewnienia jakości i testowania oprogramowania

Bogdan Bereza-Jarociński

Niniejszy artykuł zawiera sporo informacji szczegółowych na temat certyfikatów w dziedzinie zapewnienia jakości i testowania oprogramowania, takich jak: wymagania na poszczególne certyfikaty, ich dostępność w Polsce itp. Są to dane, które mogą się zmieniać w czasie. Informacje zawarte w artykule odpowiadają stanowi na maj 2004 roku.

„Many software vendors, training companies and vendor-independent groups have created their own brand of certification since the 1960s. When the rapidly emerging field of computer technology began to experience exponential growth in the 1980s more than 200 different certifications emerged. Computing professionals now face a complex and confusing array of choices for determining and demonstrating competence.” (IEEE Computer Society)

Sens certyfikacji w przemyśle informatycznym

Informatyka: duża zmienność w czasie i w przestrzeni W wielu branżach – nie tylko w informatyce – istnieją – oprócz dyplomów uczelni –

rozmaite formy certyfikatów, potwierdzających określone zawodowe umiejętności.

W informatyce i produkcji oprogramowania certyfikaty mają do spełnienia rolę szczególną, a to z dwóch powodów.

Po pierwsze, zmiany w tej branży dokonują się szybciej i dynamiczniej niż w większości przemysłów „tradycyjnych”, toteż dyplom uczelni sprzed – powiedzmy – 20 lat potwierdza kwalifikacje o treści raczej historycznej niż aktualnej. Stąd nieustanne kształcenie się i nabywanie nowych umiejętności stało się koniecznością dla każdego programisty, analityka systemów czy kierownika informatycznych projektów.

Po drugie, między produkcją oprogramowania a innymi branżami konstrukcyjnymi czy produkcyjnymi istnieje pewna zasadnicza różnica. Branże tradycyjne wytwarzają pewne dobrze zdefiniowane, niezbyt - w porównaniu z oprogramowaniem - zróżnicowane produkty: na przykład domy, mosty albo samochody. Proces wytwórczy daje się tam zdefiniować względnie precyzyjnie i "testowanie" - wszelkie czynności kontrolno-weryfikacyjne - są z tym procesem w sposób ścisły zintegrowane, zrośnięte.

Inżynierię oprogramowania można zaś nazwać "inżynierią robienia wszystkiego", tyle, że przy użyciu - zamiast betonu czy stali - "materii" instrukcji wykonywanych przez mikroprocesory komputerów. System bazodanowy, rozbudowany portal internetowy, gra komputerowa, oprogramowanie sterujące centralą telefoniczną, system wbudowany kierujący silnikami samolotu, hamulcami ABS czy pralką, system operacyjny, kompilator - to wszystko jest "oprogramowaniem". Stąd wyniesione z uczelni ogólne umiejętności rychło muszą zostać uzupełnione nowymi, dostosowanymi do zakresu wykonywanej pracy, co powoduje zasadność istnienia potwierdzających takie umiejętności certyfikatów.

TESTER.PL

Strona 11 z 49

Certyfikacja w dziedzinie zapewnienia jakości i testowania Zapewnienie jakości i test są w informatyce o tyle szczególne, że nie do końca są

dziedziną skodyfikowaną, gdzie umiejętności mają charakter precyzyjnych, dających się wyuczyć zasad i algorytmów. Mówi się niekiedy, że test oprogramowania to w jednej trzeciej dająca się sprawdzić i przeegzaminować wiedza, w jednej trzeciej – nabywane wraz z doświadczeniem umiejętności rzemieślnicze, a w jednej trzeciej – po prostu sztuka.

Nie wnikając, na ile powyższa definicja jest precyzyjna, przyznać trzeba, że wiele istotnych do zapewnienia jakości i skutecznego testowania programów umiejętności nabywa się raczej w praktyce projektowej niż w uczelnianej ławce. Widać to zresztą wyraźnie, kiedy przyjrzymy się programom studiów informatycznych: niezależnie od profilu, zapewnienie jakości (podobnie jak – z analogicznych powodów – np. zarządzanie projektami) zajmuje w nich marginalną pozycję. Zagadnienia zapewnienia jakości pojawiają się w szerszym zakresie dopiero w ramach prowadzonych przez niektóre uczelnie podyplomowych studiów z inżynierii oprogramowania.

Ta sytuacja powoduje, że np. „dyplomowanych testerów” po prostu nie ma i przypuszczalnie nie będzie, co oczywiście stanowi dodatkowe uzasadnienie dla istnienia certyfikatów.

Rodzaje certyfikatów Każdy szanujący się producent narzędzi - sprzętowych i programowych – służących

do budowy systemów komputerowych, sieci i oprogramowania lub wspierających projektowanie i wytwarzanie sprzętu i oprogramowania, wystawia własne certyfikaty. Taki certyfikat poświadcza, że jego posiadacz jest fachowcem od określonego programu lub narzędzia.

W tym opracowaniu nie będziemy się tego rodzaju certyfikatami zajmować, a to z dwóch powodów. Po pierwsze, jest ich wielka obfitość i różnorodność, a po drugie – ich tematyka i zakres są jednoznaczne i precyzyjnie określone.

Natomiast interesujące są certyfikaty o szerszym zakresie, mające przynajmniej deklarowane ambicje obiektywności i ogólności, pozwalającej na zastosowanie potwierdzonej certyfikatem wiedzy w wielu różnorodnych sytuacjach. Nie ma ich tak wiele. „Zapewnienie jakości”, a zwłaszcza „testowanie”, choć w rzeczywistości wykonywane, a nawet opisywane w podręcznikach informatyki od co najmniej 40 lat, jako odrębne i świadome swej odrębności dziedziny są znacznie młodsze, co najwyżej 15-letnie. Toteż zawodowa certyfikacja w tych dziedzinach także jest zjawiskiem względnie nowym.

Pożytki z certyfikatów Dla zawodu testera czy specjalisty w zakresie zapewnienia jakości istnienie

certyfikatów podkreśla odrębność tej dziedziny i umiejętności, co z kolei przyczynia się do podniesienia jej statusu – z którym, jak wiemy, nie zawsze jest najlepiej.

Stworzenie certyfikatu wymaga uprzedniego usystematyzowania i ujednoznacznienia wiedzy w danej dziedzinie, z czego korzyści są niezaprzeczalne. Przy okazji powstaje również zdefiniowana terminologia. W ten sposób ułatwia się komunikację między uczestnikami projektu informatycznego, a także między klientami a dostawcami i producentami.

Dla pracodawców certyfikat może ułatwić proces rekrutacji pracowników z określonym profilem umiejętności. Oczywiście, wymaga to zarówno znajomości certyfikatu, jak i poprawnego zrozumienia przez obie strony procesu rekrutacji jego treści

TESTER.PL

Strona 12 z 49

i roli. Jeśli np. pracodawca poszukuje doświadczonego kierownika zespołu testowego, a zatrudnia początkującego testera, mającego 4-miesięczne doświadczenie i legitymującego się świeżo uzyskanym dyplomem „ISEB Software Testing Foundation Certificate” [patrz poniżej], to oczywiście popełnia poważny błąd.

Dla osób wykonujących pracę w danej branży poprzedzające egzamin certyfikacyjny szkolenia mogą stać się znakomitą okazją do usystematyzowania swej wiedzy i doświadczenia, a także do uzupełnienia wiadomości tam, gdzie zakres certyfikatu wykracza poza dotychczasową praktykę. Ponadto certyfikacja stanowi niejednokrotnie formę drogowskazu, wskazującego możliwy kierunek dalszego zawodowego rozwoju. Niekiedy może się także przydać w trakcie negocjacji płacowych...

Zagrożenia Certyfikat to kawałek papieru, którego zdobycie poprzedził trwający 1-3 godziny

egzamin (zwykle testowy), a ten z kolei poprzedził okres dość intensywnej zwykle nauki. Certyfikat nie jest więc gwarancją doświadczenia, ani nie zapewnia umiejętności sprawnego wykorzystania nabytej wiedzy w praktyce. I na pewno nie zastąpi myślenia i umiejętności organizacyjnych!

Nie wszyscy są zgodni, jakie umiejętności dany certyfikat powinien obejmować. Np. popularny „ISEB Software Testing Foundation Certificate” krytykowany jest przez niektórych znawców przedmiotu za zbyt szeroki zakres, (po co „zwykłemu” testerowi szczegółowa wiedza na temat różnych typów inspekcji i przeglądów oraz na temat zarządzania testami, mówią krytycy) i niedostateczne uwzględnienie wielu konkretnych, dobrych praktyk projektowania i wykonywania testów.

Dobrze, jeśli certyfikat opiera się na znanej i dostępnej normie, międzynarodowej lub krajowej. Kiedy tak nie jest, programowi certyfikatu zagraża chaotyczność i niespójność. Z drugiej strony, tworzenie norm jest bardzo czasochłonne, zaś certyfikat będący egzaminem z zakresu normy przypuszczalnie stanie się zbyt obszerny, zbyt sformalizowany i teoretyczny.

Sporo zarzutów kierowanych jest pod adresem form egzaminu. Wiele egzaminów certyfikacyjnych to egzaminy testowe, co budzi niekiedy wątpliwości, na ile umiejętność rozwiązania w krótkim czasie kilkudziesięciu czy kilkuset pytań-zagadek jest trafnym miernikiem czyichś faktycznych umiejętności?

Jak już zostało powiedziane wyżej, mówi się niekiedy, że zapewnienie jakości i test to w 33% dająca się zweryfikować wiedza, w 33% to rzemiosło i w 33% - sztuka. Podobnie, skuteczny tester czy szef testów musi, owszem znać metody i techniki testowe, ale ponadto również dziedzinę, w której działa testowany system (np. bankowość, ubezpieczenia, zarządzanie przedsiębiorstwem) oraz platformę systemu. Tych umiejętności, odmiennych dla różnych produktów i projektów, żaden certyfikat nie potwierdzi.

ASQ Certified Reliability Engineer American Society for Quality (ASQ) jest właścicielem rozpowszechnionego

w Stanach od wielu lat certyfikatu ”Certified Reliability Engineer”. Tłumacząc tę nazwę na język polski, chyba zręczniej będzie brzmiało określenie ”Certyfikowany Inżynier Jakości” niż ”Certyfikowany Inżynier Niezawodności”.

Egzamin na certyfikat jest testowy, składa się ze 150 pytań, trwa 4 godziny. Dostępny wyłącznie w języku angielskim.

Egzamin certyfikacyjny obejmuje następujące dziedziny.

TESTER.PL

Strona 13 z 49

Zarządzanie niezawodnością (zarządzanie strategiczne, zarządzanie procesem kontroli niezawodności, bezpieczeństwo produktów i odpowiedzialność prawna).

Teoria prawdopodobieństwa i statystyka (podstawowe pojęcia, wnioskowanie statystyczne).

Niezawodność w projektowaniu i programowaniu (techniki projektowania niezawodności, dobór materiałów, zarządzanie komponentami i systemem).

Modelowanie i przewidywanie niezawodności.

Testowanie niezawodności (planowanie testów niezawodności, testowanie w procesie wytwarzania, testowanie ukończonego produktu).

Utrzymanie i dostępność systemu (zarządzanie utrzymaniem i dostępnością, analiza łatwości i skutków zmian).

Pozyskiwanie i wykorzystanie pomiarów (pozyskiwanie danych, analiza i wykorzystanie danych, narzędzia i metody do analizy danych).

IEEE Certified Software Development Professional Organizacja IEEE (Institute of Electrical and Electronics Engineers) powstała w 1884,

początkowo nosiła nazwę AIEE (American Institute of Electrical Engineers). Obecnie zrzesza ponad 380 000 członków w 150 krajach, jest jedną z największych na świecie organizacji standaryzujących: wyprodukowała prawie 900 aktywnych standardów, prowadzone są prace nad ponad 700 nowymi.

IEEE składa się z 37 stowarzyszeń. Największe z nich to IEEE Computer Society, założone w 1946 roku. Liczy 100 000 członków.

Koncepcja, na której opiera się certyfikat CSDP (Certified Software Development Professional), przedstawiona jest na poniższej ilustracji.

CSDP jest pierwszym z serii przygotowanych przez IEEE CS certyfikatów, których celem będzie stworzenie społeczności profesjonalnych twórców oprogramowania (Leading Software Development Professionals and Practitioners). Na razie jest to jedyny tego typu certyfikat przyznawany przez IEEE Computer Society. Certyfikat jest dostępny od połowy 2002 roku.

W celu otrzymania certyfikatu trzeba spełnić następujące warunki:

• wykazać się doświadczeniem zawodowym (minimum 9000 godzin przepracowanych w przynajmniej 6 z 11 obszarów wiedzy, w przeciągu ostatnich 4 lat co najmniej 2 lata przepracowane z inżynierią programowania)

Rozwój jednostki

Edukacja początkowa

Pełny status profesjonalny

Doskonalenie

Doskonalenie umiejętności

Certyfikaty, licencje

Kodeks etyczny

TESTER.PL

Strona 14 z 49

• posiadać odpowiednie wykształcenie: co najmniej tytuł licencjata z informatyki lub dziedziny pokrewnej

• zobowiązać się do przestrzegania Software Engineering Code of Ethics and Professional Practice

• zdać egzamin potwierdzający opanowanie Body of Knowledge (11 obszarów wiedzy, 180 pytań testowych, 3 godziny)

Tematyka CSDP obejmuje dziedziny:

Inżynieria oprogramowania i społeczeństwo („kryzys oprogramowania”, ekonomika inżynierii oprogramowania, normy inżynierii oprogramowania, profesjonalne praktyki).

Proces inżynierii oprogramowania (znaczenie procesów, modele procesów, model CMM dla oprogramowania).

Wymagania dla oprogramowania (proces inżynierii wymagań, pozyskiwanie i analiza wymagań, specyfikacja wymagań oprogramowania, zarządzanie wymaganiami oprogramowania).

Projektowanie oprogramowania (główne pojęcia, strategie projektowania oprogramowania, architektura oprogramowania, metodyki specjalne).

Konstruowanie oprogramowania (komponenty konstrukcji, projekt – organizacja – dokumentacja, integracja i wdrożenie systemu).

Testowanie oprogramowania (przegląd tematyki, projektowanie testów, poziomy testów).

Pielęgnacja oprogramowania (co to jest pielęgnacja, proces pielęgnacji oprogramowania, pomiary łatwości pielęgnacji, zarządzanie i dokumentacja pielęgnacji).

Zarządzanie inżynierią oprogramowania (funkcje i tryby zarządzania, proces zarządzania, planowanie projektu, zarządzanie projektem – proces, monitorowanie, zmiany).

Pomiary w produkcji oprogramowania (podstawy, wybór miar, pozyskiwanie danych).

Procesy wspierające inżynierii oprogramowania (zarządzanie konfiguracją, weryfikacja i walidacja, zapewnienie jakości, przeglądy i audyty).

QAI Certified Quality Analyst oraz Certified Software Test Engineer

QAI (Quality Assurance Institute) QAI rozpoczął działalność w roku 1980, zrzeszając osoby zajmujące się

zapewnieniem jakości w branży informatycznej. Prace nad wprowadzeniem certyfikatów rozpoczęto w roku 1985, a pierwsze egzaminy odbyły się w 1990 roku. Dziś na świecie działa ok. 10 000 osób mających (jeden z trzech) certyfikatów QAI w krajach głównie pozaeuropejskich (Australii, Belgii, Brazylii, Kanadzie, Indiach, Izraelu, Korei, Meksyku, Nowej Zelandii, Arabii Saudyjskiej, Singapurze, RPA, Wielkiej Brytanii i w USA).

Certified Quality Analyst Wymogi certyfikacyjne: minimum licencjat i dwa lata doświadczenia w branży

informatycznej (lub – jeśli ktoś nie ma licencjatu – minimum sześć lat doświadczenia

TESTER.PL

Strona 15 z 49

zawodowego), referencja – rekomendacja od innej osoby z branży oraz zobowiązanie do przestrzegania kodu etyki zawodowej. Ponadto trzeba oczywiście zdać egzamin z zakresu Body of Knowledge (podstawy jakości, procesy wytwarzania, zakupu i użytkowania oprogramowania, modele jakości, ocena jakości, zarządzanie jakością, zapewnienie jakości, monitorowanie jakości, metody definiowania, konstruowania, wdrażania i usprawniania procesów, metody ilościowe).

Certified Software Test Engineer Wymogi pozamerytoryczne takie same jak dla CQA (z tym, że wymagane

doświadczenie musi dotyczyć branży testowej).

Body of Knowledge: podstawowe zasady i pojęcia testowe, rola testerów w wytwarzaniu i zakupie oprogramowania, zarządzanie testami, konstrukcja środowiska testowego, analiza ryzyka, planowanie testów, projektowanie testów, wykonywanie testów, śledzenie i naprawianie błędów, testy akceptacyjne, śledzenie statusu testów, raportowanie testów.

BCS/ISEB: SW Testing Foundation Certificate, SW Testing Practitioner Certificate

BCS (British Computer Society) jest brytyjską organizacją o profilu podobnym do PTI (Polskiego Towarzystwa Informatycznego). BCS składa się z wielu grup zainteresowań (Interest Groups). Osoby zajmujące się testowaniem oprogramowania i systemów informatycznych zrzeszone są w prężnie działającej grupie testerów (Special Interest Group In SW Testing, SIGIST).

BCS jest merytorycznie odpowiedzialne za szereg certyfikatów z różnych dziedzin branży elektronicznej, komputerowej i informatycznej. Praktyczną realizacją tych certyfikatów (administracja, publikowanie i archiwizacja materiałów merytorycznych, akredytacja dostawców szkoleń, przygotowanie materiałów egzaminacyjnych, przeprowadzanie i sprawdzanie egzaminów, dystrybucja certyfikatów) zajmuje się firma ISEB (Information Systems Examination Board), w której radzie nadzorczej zasiada przedstawiciel ISEB.

Najnowszym produktem BCS/ISEB jest seria trzech certyfikatów w dziedzinie testowania oprogramowania:

SW Testing Foundation Certificate (dostępny od 1998 roku, egzamin poprzedzony 3-dniowym - nieobowiązkowym – szkoleniem, ponad 18 000 certyfikowanych testerów w całej Europie oraz w Australii, Izraelu i Meksyku).

SW Testing Professional Certificate (dostępny od 2002 roku, poprzedzony minimum 8-dniowym – nieobowiązkowym – szkoleniem, dotąd uzyskało go kilkaset osób, głównie w Wielkiej Brytanii oraz w Irlandii).

SW Testing Professional Diploma (trwają prace nad jego przygotowaniem).

Certyfikat podstawowy ISEB (SW Testing Foundation Certificate) „wstrzelił” się w istniejące zapotrzebowanie idealnie – tym należy tłumaczyć jego ogromną popularność, także poza Wielką Brytanią i Irlandią. Jednocześnie ta popularność spowodowała rozpoczęcie prac nad międzynarodową wersją certyfikatu - patrz poniżej.

Tematyka certyfikatu podstawowego:

TESTER.PL

Strona 16 z 49

Wprowadzenie (typy i cele certyfikatów, organizacja procesu certyfikacji, przebieg i taktyka egzaminu, organizacja materiału szkoleniowego)

Podstawowe zasady testowania (terminologia, dlaczego testowanie jest konieczne, podstawy procesu testowania, psychologia testowania, testowanie regresyjne, wyniki testów)

Testowanie w różnych fazach cyklu wytwarzania oprogramowania (modele procesu wytwarzania oprogramowania, ekonomika testowania, planowanie testowania, testowanie komponentów, testowanie integracyjne, testowanie systemu, testowanie właściwości, testowanie akceptacyjne, testowanie pielęgnacyjne)

Dynamiczne techniki testowania (techniki "czarnej skrzynki", techniki "szklanej skrzynki", zgadywanie błędów)

Testowanie statyczne (udział przeglądów w procesie testowania, rodzaje przeglądów i inspekcji, analiza statyczna)

Podstawy zarządzania testowaniem (organizacja, zarządzanie konfiguracją, kontrolowanie testowania, śledzenie błędów, normy w dziedzinie testowania)

Narzędzia stosowane do testowania oprogramowania (podstawowe typy narzędzi, elementy procesu wdrożenia automatycznego wykonywania testów).

Egzamin trwa 1 godzinę i składa się z 40-stu pytań testowych.

ISTQB: certyfikaty międzynarodowe Popularność certyfikatu ISEB w wielu krajach spowodowała działania mające na celu

przekształcenie go w certyfikat międzynarodowy. Jesienią 2001 roku podczas konferencji „EuroSTAR 2001”, odbywającej się wówczas w Sztokholmie, zebrała się grupa przedstawicieli z 9 europejskich krajów i w ciągu kilku godzin wypracowano podstawy działania ISTQB – International SW Testing Qualifications Board.

Począwszy od jesieni 2003 roku działania nabrały rozmachu – wcześniej przeszkodę stanowił konflikt między ISEB a niemieckim stowarzyszeniem ASQF („Association for Software Quality Frankonia”). Po zlikwidowaniu tego konfliktu sytuacja i cele ISTQB wyglądają następująco:

W ramach ISTQB współpracują organizacje z USA, Austrii, Danii, Holandii, Finlandii, Niemiec, Indii, Izraela, Norwegii, Polski, Portugalii, Szwecji, Szwajcarii i Wielkiej Brytanii.

ISTQB stawia sobie za cel udoskonalenie treści dotychczasowego certyfikatu ISEB.

W przyszłości powstanie jeden, wspólny międzynarodowy certyfikat ISTQB. Jego wersja podstawowa będzie w języku angielskim, zaś organizacje wszystkich krajów, które sobie tego życzą, będą mogły przetłumaczyć materiały i pytania na język krajowy. W ten sposób certyfikat ISTQB będzie pierwszym międzynarodowym certyfikatem w tej branży, mającym wiele – merytorycznie w 100% równoważnych – wersji językowych.

Organizacje krajowe wezmą na siebie akredytację kandydatów na dostawców szkoleń w swoich językach.

Przeprowadzanie egzaminów organizacje krajowe będą mogły albo organizować we własnym zakresie (przestrzegając wymogów ISTQB w celu uniknięcia nadużyć) lub zlecić organizację działającym obecnie instytucjom akredytacji i certyfikacji, tj. ISEB lub ASQF.

TESTER.PL

Strona 17 z 49

PSTB (Polish SW Testing Board) i jego rola w ISTQB Latem 2003 roku zostało zarejestrowane pierwsze w Polsce zrzeszenie osób

zajmujących się zapewnianiem jakości oraz testowaniem: Stowarzyszenie Jakości Systemów Informatycznych (SJSI). W ramach SJSI działa Polish SW Testing Board (PSTB), które reprezentuje Polskę w ISTQB, a w przyszłości przekształci się w organizację odpowiedzialną za akredytację podmiotów, które będą chciały prowadzić szkolenia zakończone egzaminem ISTQB w języku polskim.

Dobiegają końca prace nad tłumaczeniem wspólnego słownika terminologii z dziedziny testowania oprogramowania na język polski. Ten słownik będzie stanowił podstawę zarówno do tłumaczenia na język polski pytań egzaminacyjnych, jak i do produkcji materiałów szkoleniowych.

Dostępność certyfikatów w Polsce W Polsce certyfikat SW Testing Foundation Certificate dostępny jest od lipca 2002

roku (szkolenie w języku polskim, materiały i ćwiczenia w języku angielskim, egzamin w języku angielskim). Dotychczas w szkoleniach wzięło udział około 250 osób, z czego 180 przystąpiło do egzaminu na certyfikat, a około 75% zdało egzamin i uzyskało certyfikat. Szkolenia otwarte prowadzone są regularnie co 2 miesiące w Warszawie przez współpracujące firmy bbjTest i Software Konferencje. Możliwe jest także przeprowadzenie szkoleń zamkniętych w firmach.

Certyfikat SW Testing Professional Certificate na razie nie jest w Polsce dostępny. Możliwe jest zorganizowanie egzaminu eksternistycznego, jeśli znajdzie się co najmniej kilka osób zainteresowanych.

Szkolenia na IEEE Certified Software Development Professional organizowane są przez Software Konferencje.

Źródła 1. BCS, Information Systems Examination Board, SW Testing (tamże dostępne

szczegółowe dane nt. zakresu tematyki, egzaminów, akredytowanych dostawców szkoleń itp.): www.bcs.org.uk/iseb/st

2. IEEE Computer Society, CSDP: www.computer.org/certification 3. Yahoo CSDP Study Group: groups.yahoo.com/group/ieee_csdp 4. IEEE: www.ieee.org 5. SWEBOK, IEEE SW Engineering Body of Knowledge: www.swebok.org 6. QAI, Certified SW Quality Analyst: www.softwarecertifications.com/qai_cqa.htm 7. QAI, Certified SW Tester: www.softwarecertifications.com/qai_cste.htm 8. Certyfikaty QAI: www.softwarecertifications.com/ 9. QAI: www.qaiusa.com 10. ASQ, Certified Reliability Engineer: www.asq.org/cert/types/cre/ 11. ASQ Certified Reliability Engineer Body of Knowledge:

www.asq.org/cert/types/cre/bok.html 12. ISTQB: www.istqb.org/vision.php

TESTER.PL

Strona 18 z 49

13. ASQF: www.asqf.de 14. Stowarzyszenie Jakości Systemów Informatycznych, Polish SW Testing Board:

www.sjsi.org/pstb 15. bbjTest (informacje na temat certyfikacji, realizacja szkoleń, w tym na SW Testing

Foundation Certificate): www.bbj.com.pl 16. Software Konferencje (realizacja szkoleń otwartych na SW Testing Foundation

Certificate oraz CSDP): www.software.com.pl/konferencje 17. International SW Quality Institute ISQI (ISTQB is part of it): www.isqi.org

TESTER.PL

Strona 19 z 49

CENTRA TESTOWANIA I OPTYMALIZACJI SYSTEMÓW IT

Rynek dostawców aplikacji do optymalizacji jakości stał się jednym z najważniejszych i najbardziej strategicznych obszarów inwestycyjnych dla przemysłu informatycznego. Firmy porzucają strategię testowania poszczególnych projektów i przekształcają się w przedsiębiorstwa dostarczające aplikacje kompleksowo.

Od ponad 15 lat firma Mercury pomaga tysiącom klientów optymalizować jakość i wydajność ich aplikacji. W swoim raporcie Gartner Magic Quadrant for Distributed Testing firma Gartner ocenia firmę Mercury jako lidera rynku. Według instytutu IDC firma Mercury jest najlepszym na świecie dostawcą aplikacji, posiadającym 55,6% udział w rynku zautomatyzowanych produktów testowania jakości i wydajności oprogramowania (ASQ). IDC z optymizmem wyraża się o perspektywie wzrostu rynku dostawców aplikacji i przewiduje, że całościowy dochód rynku ASQ osiągnie 1,3 miliarda USD w 2008 r.

Wyniki najnowszych badań przeprowadzonych przez Economist Intelligence Unit (EIU) i obejmujących ponad 750 dyrektorów z branży IT potwierdzają trzy największe wyzwania stojące przez europejskimi firmami IT:

• Poprawa jakości IT (69%) • Pomiar i wykazanie wartości IT dla biznesu (63%) • Obniżenie kosztów (56%)

Centra Optymalizacji Mercury – Każde z czterech centrów optymalizacji Mercury

oferuje zintegrowane oprogramowanie, usługi i najlepszą praktykę.

• Centrum jakości i wydajności Mercury - dla działów testów pre-produkcyjnych aplikacji

• Centrum zarządzania IT - do zarządzania całym działem IT • Centrum dostępności biznesowej systemów IT - do zarządzania aplikacjami

Centrum jakości Mercury skupia główne zadania związane z dostarczaniem

aplikacji, m.in. zarządzanie testami, testy procesów biznesowych i testy funkcjonalne, co ma na celu poprawę jakości oprogramowania strategicznego. Centrum jakości pozwala klientom scentralizować funkcjonowanie ich firm, co zapewnia oszczędność czasu, obniżenie kosztów i powoduje poprawę wydajności krytycznych zadań IT.

Zalety Centrum jakości Mercury:

• Szybsza dostawa i poprawa jakości na poziomie produkcji • Konsekwentny, wielokrotny i sprawdzony proces testowania

TESTER.PL

Strona 20 z 49

• • Centralne raportowanie (przez przeglądarkę internetową, portale lub konsole

kierownicze) o statusie bieżących projektów, projektów nadchodzących i wynikach poprzednich zadań

• Technologia automatyzacji i testowania oraz wiedza specjalistyczna w zakresie wykorzystania technologii

• Skalowalność od poziomu departamentu do zastosowań globalnych dla aplikacji rozproszonych

• Konsola zarządzająca dla widoku w czasie rzeczywistym procesów testowania jakości i wydajności

• Zarządzanie centrum jakości (Usługi zarządzania Mercury) na żądanie Centrum wydajności Mercury skupia główne zadania związane z dostarczaniem

aplikacji, m.in. testy obciążenia, diagnostyka aplikacji oraz planowanie wydajności wszystkich strategicznych aplikacji biznesowych. Centrum wydajności umożliwia poszczególnym zespołom IT wykonywanie zadań w sposób scentralizowany, co oszczędza czas, ogranicza koszty i powoduje znaczny wzrost wydajności krytycznych zadań IT.

Zalety Centrum wydajności Mercury:

• Szybsza dostawa i poprawa jakości na poziomie produkcji • Zoptymalizowana infrastruktura poprzez analizę, testy i lepszą wydajność • Centralny widok (przez przeglądarkę internetową, portale lub konsole kierownicze)

statusu bieżących projektów, projektów nadchodzących i wyników poprzednich zadań • Skalowalność od poziomu departamentu do zastosowań globalnych dla aplikacji

rozproszonych • Kompleksowy widok zapewniający optymalizację aplikacji lub procesu biznesowego

przed wprowadzeniem go na rynek i wymaganych dla niego zasobów • Odpowiednio wczesne wykrywanie „wąskich gardeł” pozwalające zwiększyć

wydajność aplikacji • Planowanie wydajności, m.in. symulacja hipotetycznych scenariuszy. • Skrócenie średniego czasu naprawy, dzięki zastosowaniu rozwiązań diagnostycznych • Konsola kierownicza dla widoku w czasie rzeczywistym przebiegu procesu jakości

i wydajności • Zarządzanie centrum wydajności (Usługi zarządzania Mercury) na żądanie

TESTER.PL

Strona 21 z 49

Wywiad z Jamesem Bachem2

James Bach, współautor książki "Czego dowiedziałem się testując oprogramowanie" (tytuł oryginału "Lessons Learned in Software Testing"), to osoba dosyć popularna w świecie testów ze względu na swoje niekonwencjonalne idee. Jego strona internetowa jest dostępna w sieci pod adresem www.satisfice.com.

Witryna WhatIsTesting przeprowadziła z nim wywiad. Mam nadzieję, że wywiad Was zainteresuje i okaże się użyteczny.

James, proszę powiedz nam coś o sobie, o swoim wykształceniu i dotychczasowej pracy. Co najbardziej interesuje Ciebie poza testowaniem i co porabiasz w wolnym czasie?

Urodziłem się w stanie Iowa w USA. Dziecięce lata spędziłem w cichej, wiejskiej miejscowości Vermont.

W szkole nie było łatwo, szczególnie po piątej klasie. Przeczytałem w konstytucji Stanów Zjednoczonych, że "Nie będzie w Stanach Zjednoczonych lub jakimkolwiek miejscu podległym ich władzy ani niewolnictwa, ani przymusowych robót, chyba jako kara za przestępstwo, którego sprawca został prawidłowo skazany". Na podstawie tego fragmentu podjąłem postanowienie, że nie będę już odrabiał zadanych prac domowych. Odmowa ta przekształciła się w generalne odrzucenie całej szkolnej biurokracji i niechęć do władzy w ogóle. Dzisiaj wydaje się to absurdalne. Ale kiedy miałem 16 lat - w roku 1982 - mój ojciec (który napisał książkę pod tytułem "Jonathan Livinston Seagull" mówiącą o dorastaniu i kierowaniu swoim życiem) doradził mi, abym rzucił szkołę. Tak zrobiłem i kontynuowałem naukę na swój sposób.

Dostałem pracę w sklepie komputerowym, gdzie przez sześć miesięcy nic nikomu nie sprzedałem, ale wkrótce zostałem zatrudniony przez inna firmę, w której pisałem gry komputerowe na Apple i Commodore 64. Po kilku latach pracy na stanowisko kierownika testów zatrudniła mnie firma Apple Computer. Jestem przekonany, że byłem wtedy najmłodszym kierownikiem w firmie. Nie miałem żadnego przygotowania z zakresu zarządzania ani związanego z testowaniem, ale to nie stanowiło problemu. Niewiele osób miało w ogóle pojęcie o testowaniu. Postanowiłem zostać ekspertem od spraw testowania, dlatego spędzałem całe godziny w kafejce naprzeciwko mojej pracy czytając książkę za książką i próbując odkryć tajemnice testowania.

2 Wywiad został zamieszczony dzieki Mariuszowi Janczewskiemu, który jest także tłumaczem tego wywiadu. Mariusz Janczewski jest współpracownikiem Tester.PL, aktualnie pracuje w Gdansku, w firmie Atena, Usługi informatyczne i finansowe, Sp. z.o.o. www.atena.pl

TESTER.PL

Strona 22 z 49

Ponieważ mam "antyestabliszmentowe" korzenie, nigdy nie czułem się zobligowany do ograniczenia się do tylko jednej dziedziny. Miało to swoje wady, jak i zalety. Nigdy nie byłem częścią systemu, który przekonywał ludzi, że pewien guru odnalazł prostą i skuteczną metodę wytwarzania oprogramowania. Nie wierzę takim osobom. Nie ma prostych przepisów, poza tą jedną, najbardziej prostą regułą wymagającą wielkiej umiejętności skorzystania z własnego rozumu ("use your mind"!).

Mam szczególne uznanie dla dwóch rzeczy: metod naukowych oraz szczęścia zwykłych ludzi. W innych sprawach jestem bardzo sceptyczny.

Twoja strona internetowa nosi nazwę "satisfice", jakie jest znaczenie tego słowa? Co oznaczają słowa "epistemologia dla każdego", na które możemy trafić na Twojej stronie?

"Satisfice" oznacza dążenie do rozwiązania wystarczająco dobrego. Zostało ono po raz pierwszy użyte przez Herberta Simona, który otrzymał Nagrodę Nobla za swoje badania dotyczące sposobu, w jaki organizacje podejmują decyzję. Skomplikowane decyzje, takie jak odpowiedzi na pytania czy produkt jest gotowy do wypuszczenia na rynek, nie są podejmowane wyłącznie na podstawie oczywistych racjonalnych przesłanek, ale w wyniku procesu, który bywa czasem "mglisty". Proces ten Simon nazwał ograniczonym racjonalizmem. To, czym się zajmuję, cała moja praca, polega na określeniu, w jaki sposób mogę podejmować najlepsze decyzje w sytuacji, kiedy nie znam wszystkich faktów, kiedy jestem przez to niedoskonały. To jest to, co tak bardzo interesuje mnie i moich Klientów.

Epistemologia jest dziedziną filozofii zajmującą się teorią poznania, określeniem sposobu, w jaki poznajemy. Cała dziedzina nauki zajmuje się tym zjawiskiem. "Epistemologia dla każdego" jest nawiązaniem do dawnego hasła firmy Apple Computer "komputery dla każdego". Podobnie jak Apple, staram się przekazać coś ze świata specjalistów do codziennego użycia. Taka jest moja filozofia testowania i wytwarzania oprogramowania.

James, to może być krótkie pytanie i długa odpowiedź. Czy możesz opisać Twój związek ze szkołą "context-driven testing"? W jaki sposób szkoła ta powstała? Jak dojrzewała? Proszę opowiedz o historii i o tym jak widzisz przyszłość tej szkoły.

Termin "context-driven testing" powstał podczas wspólnej kolacji w dniu 21 listopada 1999. W spotkaniu braliśmy udział Cem Kaner, Brian Marick i ja. Było to w drodze na ósme warsztaty z testowania oprogramowania w Los Altos. Dwa tygodnie później założyliśmy grupę dyskusyjną na Yahoogroups poświęconą "context driven testing". W roku 2001 wraz z Cem'em, Bret'em Pettichord sformułowaliśmy siedem zasad testowania "context-driven" i opublikowaliśmy pierwszą książkę na ten temat pod tytułem "Lessons Learned in Software Testing".

Chociaż termin nie był stosowany przed rokiem 1999, to grupa, którą nazwaliśmy społecznością "context-driven" wyrosła na rozpoznawalne zjawisko jeszcze przed naszym spotkaniem podczas wcześniejszego LAWST w roku 1997. Spotkanie to stanowiło przełom. LAWST to skrót od "Los Altos Workshops on Software Testing". LAWST to nie komercyjne, tygodniowe dyskusje, w których biorą udział małe grupy osób, żeby dzielić się swoim doświadczeniem w dziedzinie testów. Pierwsze LAWST zostało zorganizowane przez Cem'a Kaner'a i Brian'a Lawrence'a. Odbyło się już czterdzieści spotkań tych oraz innych związanych z LAWST spotkań.

TESTER.PL

Strona 23 z 49

Podczas spotkań LAWST, żaden prelegent nie jest chroniony przed wnikliwymi pytaniami i krytycyzmem. Podejście krytyczne wymaga od uczestników umiejętności i wiedzy, w jaki sposób uzasadniać swoje racje i przedstawiać argumenty. Osoby trafiające na LAWST w poszukiwaniu "najlepszych praktyk" są często rozczarowane, ponieważ znajdują więcej pytań niż odpowiedzi i więcej kontrowersji niż zgody. Wiele osób uczestniczy w kilku spotkaniach, a następnie rezygnuje z kolejnych, ale osoby, które uczestniczą we wszystkich spotkaniach pozyskują cenne umiejętności w zakresie sztuki testowania. Dzięki temu LAWST i inne bliźniacze konferencje są odpowiedzialne za wzrost nowej wrażliwości, która mówi, że żadna praktyka może być dobrą praktyką i że żadna praktyka może być złą praktyką, w zależności od kontekstu, a kontekst jest zawsze zależny od ludzi, którzy go tworzą.

Zatem „context-driven testing” nie jest techniką, jest raczej profesjonalnym sposobem podejścia do technik. Aby prowadzić „context-driven testing” należy ustalić świadome, jasne, samokrytyczne relacje pomiędzy procesem testowym i środowiskiem (czyli kontekstem), w którym testy są prowadzone. Tester prowadzący testy zgodnie z „context-driven testing” dąży do pełnej odpowiedzialności za swój własny proces testowania.

Metodę „context-driven testing” spostrzegam w przyszłości jako rozwijającą się powoli w atmosferze spotkań zbierających się w małych grupach myślicieli, próbujących pisać wnikliwe artykuły o testowaniu. Nie sądzę, że kiedykolwiek będzie ich więcej niż kilka procent wśród całego środowiska testerów. Tak jak niewiele jest entuzjastów "ham radio"3

w porównaniu z liczbą użytkowników zwykłych telefonów komórkowych. Wierzę, że w nie tak odległej przyszłość (za jakieś 30 lat) wartość "context-driven testing" zostanie doceniona i będzie ono stanowiło wartościowe uzupełnienie innych metod testowania oraz będzie rozpoznawane po prostu jako "wykwalifikowane testowanie". Etykieta "context-driven" nie będzie już konieczna, ponieważ doświadczeni testerzy będą traktowali w oczywisty sposób, że to kontekst dominuje praktykę.

Jest jeszcze jeden fragment historii, na który pragniemy rzucić nieco światła. Proszę opowiedz nam o testowaniu eksploracyjnym i Twoim związku z nim. W jakim kierunku będzie rozwijało się testowanie eksploracyjne? W jaki sposób szkoła "context-driven" przyjmuje elementy testowana eksploracyjnego?

Testowanie eksploracyjne jest szczególną rodziną praktyk testowych zdefiniowanych jako "równoczesna nauka, projektowanie testów i wykonywanie testów". Może ono być traktowane jako mentalna sztuka walki. Sam termin został wymyślony (w każdym razie na polu oprogramowania) przez Cema Kanera w późnych latach osiemdziesiątych, ale nie został wówczas opublikowany i niewiele osób korzystało z niego. Podjąłem ten termin w roku 1994 po nieudanych próbach przekonania ludzi, że testowanie ad hoc jest umiejętnością, której można uczyć, która stanowi wyrafinowaną formę testowania. Ad hoc nie oznacza "byle jaki", ale wielu ludziom wydaje się, że taki właśnie jest, zatem uznałem, że na moje potrzeby termin testowanie eksploracyjne będzie lepszy. Dzisiaj jest to relatywnie dobrze znany termin, zarówno Cem jak i ja jesteśmy znani z działalności na tym polu.

3 ham - someone who receives and sends radio messages for fun rather than as their job

TESTER.PL

Strona 24 z 49

Także Elisabeth Hendrickson wykonała z nami znaczną pracę w tym zakresie, podobnie jak James Whittaker. Niezbyt wiele osób w aktywny sposób pracowało nad rozwojem i opisem tej praktyki, co przypomina sytuację związaną z pracami nad testowaniem eksploracyjnym na innym polu.

Eksploracja jest z natury czynnością, którą trudno jest opisać za pomocą prostego, konkretnego przepisu, tak wielu kierowników obawia się jej. Myślę, że testowanie eksploracyjne stanowi podstawowe podejście do testowania. Innymi słowy, według mnie tester staje się wykwalifikowany wtedy, kiedy dobrze przeprowadza testy eksploracyjne, jest to pierwsza umiejętność, której uczę nowych testerów, którzy dla mnie pracują. Podstawowy fenomen testowania eksploracyjnego można poznać studiując kontekst medyczny, inżynierię, filozofię nauki, ekonomię, wodzenie teorii, teorię gier, kreatywne myślenie, sztukę, nawigację, edukację, i sztuczną inteligencję. To wskazuje na listę książek, które musiałem przeczytać.

Eksploracja jest rdzeniem lekkiego sposobu wytwarzania oprogramowania. Według mnie nikt nie może uważać się za osobę wyedukowaną w zakresie testowania, utrzymując, że eksploracja jest dodatkowym luksusem, który można przeprowadzać tylko wtedy, kiedy wszystkie skrypty testowe zostaną wykonane. W tej sytuacji według mnie trudno jest traktować poważnie autorów i konsultantów określających testowanie eksploracyjne jako proces nieuporządkowany, którego nie można nauczać, którym nie można zarządzać. Mam nadzieję, że spostrzegą oni to, że rok 1985 już minął i nasze rzemiosło nieco się rozwinęło.

Jakie jest miejsce testowania skryptowego w szkole kontekstowej? Jak spostrzegasz zmiany zachodzące w testowaniu skryptowym w ostatnim czasie?

Szkoła testowania kontekstowego nie ma jakichkolwiek preferencji w zakresie stosowanych praktyk, tak długo jak praktyki te nie są sprzeczne z jedną z siedmiu zasad stojących u podstaw tej szkoły, podanych na stronie www.context-driven-testing.com. Oznacza to, że testowanie skryptowe należy do szerokiej rodziny praktyk testowych: tester kontekstowy zadaje sobie trud pojęcia dynamiki testowania skryptowego i poszukuje sposobu, w jaki praktyka ta może pomóc mu w rozwiązania problemu, nad którym pracuje.

Tester kontekstowy stosuje te sposoby testowania, które najlepiej odpowiadają bieżącym wyzwaniom. Na przykład jako tester kontekstowy, zwracam uwagę na dziewięć powodów, dla których powinienem powtórzyć test i to wpływa na wybraną przeze mnie formę dokumentowania przypadków testowych. Bez względu na kwestię powtarzalności czynności testowych występują także inne ważne powody decydujące o przygotowywaniu skryptów testowych. Mimo to nadal jestem zdania, że w przypadku bardziej skomplikowanych projektów, jeśli Twoim głównym celem jest znalezienie ważnych błędów, testowanie nie powinno być zbytnio oparte na przygotowanych skryptach. Zadaniem testowania eksploracyjnego jest lokalizacja możliwie największej liczby błędów, w możliwie krótkim czasie.

Testowanie skryptowe oznacza, że tworzysz test zanim go przeprowadzisz i nie zmieniasz go podczas realizacji testu ani w jego wyniku. Ten sposób podejścia do testowania stanowi oczywistą opozycję względem testowania eksploracyjnego, ale spostrzegam także, że testowanie zwykle zawiera elementy obydwóch podejść - pewne elementy testowania skryptowego oraz eksploracyjnego realizowane bywają równocześnie. Właśnie to, że testowanie zawiera elementy obydwóch stylów, stanowi największą zmianę mojego sposobu myślenia na temat testowania w ostatnich kilku latach.

TESTER.PL

Strona 25 z 49

Jaka jest Twoja rada dla firm, które utkwiły w "modelu testowania starego typu"? Jakie kroki powinny one podjąć, aby otrzymać lepsze oprogramowanie?

Moja rada to bądźcie uważni. Uczcie się widzieć, co się naprawdę dzieje. Bądźcie samokrytyczni.

Tak wiele firm kontynuuje swoje oparte o teorie produktywności i jakości podejście do testowania, które rozpada się w pył, gdy okazuje się, że np. 85% błędów (to oszacowanie oparte na moim doświadczeniu z klientami) jest lokalizowanych dzięki technikom eksploracyjnym lub kiedy orientują się, że dokumentacja testowa przygotowana przez nich już nie pomaga im w poprawie testów, a raczej stała się powodem utraty mnóstwa czasu i energii. Wiele osób zakłada, że nowi testerzy zyskają dzięki zapoznaniu się ze starą dokumentacją, ale wystarczy obserwować nowych testerów, aby zorientować się, że takie założenie zwykle jest kompletnie błędne. Testerzy uczą się poprzez eksplorację oraz poprzez udział w projektach z innymi ludźmi.

Warto czytać książki Gerald'a M. Weinberg'a. Szczególne jego serię o zarządzaniu jakością oprogramowania.

W jaki sposób powstało: "Czego nauczyłem się testując oprogramowanie"?

Cem Kaner i ja braliśmy udział w konferencji poświęconej tworzeniu "wzorców" testowych i zaczęliśmy frustrować się, kiedy zaczęto zadawać nam pytania dotyczące "zakręconych" i mało użytecznych formatów. Wówczas to Cem wpadł na pomysł, aby spisać zestaw prostych idei, każda z bardzo interesującym i wdzierającym się w pamięć tytułem. Idee te stanowiły nasz zbiór wzorców. Przekazaliśmy szkic naszego opracowania Bretowi Pettichord, który dołączył do projektu i ruszyliśmy do pracy.

Początkowo, podobnie jak we wszystkich projektach, w których brałem udział, niewiele się działo. Ale wkrótce Cem zawarł umowę dotyczącą publikacji naszego opracowania, co stanowiło znak, że należy szybko ruszyć do pracy. Zebraliśmy się razem w moim laboratorium i w wyniku burzy mózgów zebraliśmy 522 idee dotyczące testowania, którymi chcieliśmy podzielić się z innymi, kiedy zabieraliśmy się za to rzemiosło. Potem podzieliśmy je na rozdziały i zabraliśmy się za nie.

Pisanie książki polegało na pisaniu mnóstwa email'i pomiędzy nami. Założeniem było napisanie książki, która trafi do zapracowanego testera i z której będzie mógł korzystać bez potrzeby czytania jej w określonym porządku.

Jaka jest według Ciebie najważniejsza lekcja, którą każdy tester powinien poznać czy to na podstawie doświadczenia innych, czy też własnego?

TESTER.PL

Strona 26 z 49

Oto ona: Testowanie jest w Twojej głowie4. To znaczy, że najważniejsze w testowaniu jest to jak myślisz, co myślisz, co widzisz i co zapamiętujesz. Czynnik ludzki w testowaniu jest fundamentalny i nie może być zastąpiony przez automatyzację tego procesu.

Jestem przekonany, że większość książek o testowaniu została napisana przez ludzi, którzy nie mają zbyt dużego pojęcia o tym temacie. Mają pewne doświadczenie i dlatego myślą, że wiedzą o co chodzi. Ale testowanie jest zagadnieniem bardzo wymagającym. Podobnie jak psychologia wymyka się prostym opisom i analizom. Stąd kolejna lekcja: "Większość książek o testowaniu nie mówi prawdy o testach".

Należy zatem uczyć się następujących umiejętności:

• w jaki sposób obserwować to co się dzieje, • jak stosować metody naukowe, • jak myśleć systematycznie, • jak współpracować z ludźmi, • jak stać się częścią społeczności samokrytycznej.

Czy pracujesz nad kolejną książką?

Co pewien czas przygotowuję materiał do kolejnego wydania książki Kaner'a "Testing Computer Software" i stale pracuję nad książką o niekonwencjonalnym poznaniu.

Co miałeś na myśli określając indyjskich testerów swoim blogu mianem "Śpiącego Giganta"? W jaki sposób mogą się oni "przebudzić"?

Nie widzę znaczących przeciwskazań stojących na drodze Indii ku staniu się międzynarodowym centrum wykształconych testerów, jeśli oczywiście mieszkańcy Indii będą chcieli zajmować się testami.

Zanim nie odwiedziłem Indii myślałem, że istnieją bariery edukacyjne i kulturowe. Myliłem się. Proszę testerów z Indii o przyjęcie moich przeprosin.

Nie wiem, co powoduje ludźmi, że budzą się rano. Zastanawiam się jak to możliwe, że budzę się każdego ranka. W jednym momencie śpię, a w następnym budzę się. To zaś, co mogę stwierdzić, to fakt, że początkowo myślałem, że ludzie z którymi pracowałem i których uczyłem w dwóch firmach w Bangalore nie interesują się testowaniem i mają ograniczone pojęcie o nim. Ale grupa szybko robiła postępy i mogłem obserwować znaczącą poprawę w ich zdolności do stawiania czoła zadaniom, które przed nimi stawiałem. W niektórych grupach spostrzegłem też bardzo wiele chęci i entuzjazmu do nauki testowania. Sądzę, że czynnikiem, który wpływa na pracowników indyjskiej społeczności technicznej, to dążenie do uzyskania przewagi konkurencyjnej. Ci ludzie pragną stać się liderami światowego społeczeństwa testerów, nie chcą być tymi słabszymi. Obecnie nie znam nikogo, kto wypowiada się o Indiach jako kraju wiodącym prym w jakimkolwiek intelektualnym

4 Testing Is In Your Head

TESTER.PL

Strona 27 z 49

zagadnieniu dotyczącym testowania. Tak pozostanie tak długo aż niektórzy z nich nie pokażą się "online" oraz w ramach różnych społeczności, i to nie jako nieśmiali "podsłuchiwacze", czy osoby powtarzające historyczne idee z lat osiemdziesiątych (ciągle jest sporo takich osób), ale jako praktycy wspierający rozwój najnowszych idei dotyczących testowania.

Te najnowsze idee, to według mnie lekkie wytwarzanie, usprawnianie procesu oparte na umiejętnościach, testowanie heurestyczne oraz wyrafinowane psychologiczne teorie związane z testowaniem.

Gdybyś przeprowadzał wywiad sam ze sobą, jakie pytania byś sobie zajął?

Oto one:

Co zajmuje Ci najwięcej czasu?

Przez większość czasu jestem w drodze, prowadzę kursy szybkiego testowania5 i testowania opartego na ryzyku6, biorę udział w konferencjach. Czasami pracuję jako ekspert lub biegły w sprawach sądowych.

Co najbardziej lubisz robić?

Chciałbym więcej testować, jestem zmęczony ciągłym mówieniem o tym przez cały czas. Projekt, który dał mi najwięcej radości, to testowanie Windows XP Embedded podczas sprawy przeciwko firmie Microsoft w roku 2002. To wielki wstyd, że nie mogę napisać co wówczas wykryłem podczas testowania, ani jakiej metody użyłem. Może kiedyś zostanę zwolniony z umowy dotyczącej tajemnicy zawodowej.

5 rapid software testing 6 risk-based software testing

TESTER.PL

Strona 28 z 49

TESTER.PL

Strona 29 z 49

LReport – narzędzie do prezentacji i weryfikacji wyników zapytań bazodanowych

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 30 z 49

LReport – narzędzie do prezentacji i weryfikacji wyników zapytań bazodanowych

Piotr Kałuski

CGI

Streszczenie

W artykule tym zaprezentuję narzędzie do czytelnej prezentacji wyników zapytań i automatycznego porównywania tych wyników z oczekiwaniami. Spróbuję przekonać, że czytelna dokumentacja wyników testów nie tylko cieszy oko, ale jest ważnym elementem procesu wytwarzania i wdrażania oprogramowania wysokiej jakości. Będę też bronił tezy, że w wielu sytuacjach skuteczna automatyzacja testów wcale nie musi obejmować automatyzacji akcji na GUI. Podstawowe tezy przedstawione poniżej były prezentowane na I Konferencji Stowarzyszenia Jakości Systemów Informatycznych.

Dokumentowanie testów – odwieczny problem testerów Myślę, że większość testerów w swojej codziennej pracy, często staje przed

dylematem

– czy powinniśmy więcej czasu poświęcić na stworzenie rzetelnej, czytelnej dokumentacji testów, które już wykonaliśmy

– czy też powinniśmy, kosztem jakości dokumentacji, postarać się wykonać jak największą ilość scenariuszy.

W większości przypadków decydujemy się na drugie wyjście. Dokumentujemy gorzej bądź wcale, aby móc przetestować jak najwięcej funkcjonalności. Bądź co bądź, najważniejszym zadaniem testera jest jak najdokładniej przetestować powierzone mu oprogramowanie.

Jednak posiadanie czytelnej dokumentacji testów ma pewne zalety, wobec których nie powinniśmy przechodzić obojętnie. W procesie wytwarzania oprogramowania wysokiej jakości, odgrywa ona dosyć ważną rolę w przepływie dokumentacji i wiedzy w firmie. Dobra dokumentacja:

• Pozwala szybko i sprawnie weryfikować wyniki testów To oczywiste. Łatwiej jest wyłowić błędne dane, jeżeli są one podane w

sposób przejrzysty i czytelny.

• Jest bazą wiedzy o testowanej funkcjonalności. Ten drugi punkt chciałbym trochę rozwinąć. W firmach, w których proces

wytwarzania oprogramowania jest na wysokim poziomie, dla każdego modułu jest tworzony zestaw dokumentacji – wymagania, specyfikacja funkcjonalna, architektura. Jednak praktyka uczy, że te dokumenty, jakkolwiek niejednokrotnie kompletne i rzetelne, nie są najlepszą lekturą dla osób, które chcą szybko zrozumieć szczegóły działania systemu. Do wielu najlepiej przemawiają dobrze zilustrowane przykłady. Stąd taka popularność tutoriali. Czytelny opis przebiegu testu jest właśnie takim

TESTER.PL

Strona 31 z 49

tutorialem. W związku z tym może być cennym źródłem wiedzy o tym jak działa testowana aplikacja. Źródłem wiedzy zarówno dla osób doświadczonych, jak i dla osób nowych, które dopiero system poznają.

Niestety, tworzenie czytelnej dokumentacji testów zajmuje czas. Różnica w czasie potrzebnym do starannego i niedbałego opisu rezultatów jest znaczna. Dlatego decyzję o przykładaniu dużej wagi do jakości dokumentacji trzeba dobrze przemyśleć, z pełną świadomością jej kosztów. Lub też mieć pomysł jak te koszty zmniejszyć.

Niektórzy nie mają wyboru. Kontrakt wymusza na nich tworzenie kompletnej dokumentacji wyników testów. Wtedy ich problemem nie jest czy tworzyć dokumentację tylko raczej – jak to robić najbardziej efektywnie.

Niezależnie od tego czy jesteśmy do tego zobligowani kontraktem czy nie, skorzystanie z narzędzia, które usprawni proces dokumentacji i weryfikacji rezultatów testów może przynieść nam znaczne korzyści. LReport jest właśnie takim narzędziem.

LReport LReport jest narzędziem do prezentacji wyników zapytań i ich weryfikacji.

Jakkolwiek nie wszystkie scenariusze testowe zawierają w sobie operacje na bazie danych, to w większości aplikacji komercyjnych modyfikacje w bazie danych są jednym z głównym efektów wykonania większości operacji. Jeżeli więc usprawnimy dokumentowanie tego aspektu zachowania aplikacji, korzyści mogą być znaczne.

Co konkretnie LReport robi? Najłatwiej będzie mi to zilustrować przykładem.

Przykład Wyobraźmy sobie, że testujemy aplikację dla firmy usługowej. Testujemy dodawanie

nowej usługi klientowi. Wiemy, że dodanie nowej usługi spowoduje modyfikację w 3 tabelach – CUSTOMERS, SERVICES, INVOICES. Scenariusz testu jest następujący – dodaj nową usługę dla konta 12345. Rzetelne wykonanie tego testu wymaga abyśmy sprawdzili i udokumentowali stan bazy danych przed wykonaniem testu, wykonali test i sprawdzili i udokumentowali stan bazy danych po teście. W naszym przykładzie oznacza to umieszczenie w dokumencie rezultatów następujących zapytań:

select * from CUSTOMERS where CUSTOMER_ID = 12345 select * from SERVICES where CUSTOMER_ID = 12345 select * from INVOICES where CUSTOMER_ID = 12345

Najszybszym sposobem udokumentowania zawartości bazy danych jest skorzystanie z narzędzia typu RapidSQL, OraTool czy SQLPlus do wykonania zapytania i następnie skopiowanie wyników zapytań do dokumentu. W naszym przypadku wyglądałoby to tak:

Select * from CUSTOMERS where CUSTOMER_ID = 12345

TESTER.PL

Strona 32 z 49

CUSTOMER_ID LAST_NAME FIRST_NAME FISCAL_NUMBER TAX REGION BANK_ACCOUNT EMPLOYER LAST_KNOWN_SALARY PHONE ADDRESS PREFFERED_TIME_TO_CONTACT PROFESSION CREDIT_CARD_NUMBER FATHERS_NAME MOTHERS_NAME MOTHERS_MAIDEN_NAME MAIDEN_NAME DATE_OF_BIRTH CUSTOMER_SEGMENT VIP BAD_DEBTS IN_COLLECTION LAST_NOTE DATE_OF_CREATION NUMBER_OF_SERVICES DISCOUNT_PLAN STATUS EDUCATION RESPONSIBLE_PERSON ELIGIBLE_FOR_PROMOTIONS REASON_OF_DEACTIVATION DEACTIVATION_DATE COMMENTS

12345 Green Marjorie 345-348-34-34 VAT22 Warsaw 12356232-238923-239238 Kaluski&Kaluski 10000 415 986-7020 309 63rd St. #411 Afternoon Programmer 2562-2389-2376-2321 Jan Anna Kowalska 14-07-1984 INDIVIDUAL N N N 01-03-2003 2 HJ-KDISC AC MSC Jan Nowak Y Moved to our company from competitors

Select * from SERVICES where CUSTOMER_ID = 12345

CUSTOMER_ID SERVICE_NUMBER SERVICE_TYPE START_DATE SERVICE_CHARGE STATUS COMMENTS ADDRESS DEACTIVATION_REASON DEACTIVATION_DATE ON_HOLD LAST_COMPLAINT LEVEL_OF_SATISFACTION DISCOUNT

12345 1 SUPPORT 19-09-2004 24.5 AC First service activated for the customer. 309 63rd St. #411 N 31-09-2004 7 30

12345 2 QUICK_DELIVERY 29-09-2004 4.0 AC On customer's request. 235 3rd St. #89 N 10 0

Select * from INVOICES where CUSTOMER_ID = 12345

CUSTOMER_ID INVOICE_ID ISSUES_DATE PAYMENT_DATE PAYMENT_TYPE PAYED_ON_TIME AMOUNT AMOUNT_NOT_PAID DISCOUNTS ALTERNATE_ADDRESS PAYMENT_DELAY TOTAL_TAX TOTAL_NET ISSUED_BY IN_SAP REVIEWED_BY REVIEWED_ON REJECTION_REASON

12345 12345/1 01-09-2004 11-09-2004 CD Y 1238.57 0.00 23.80 200.00 1038.57 pkaluski N lkowalski 02-09-2004

12345 12345/2 08-09-2004 18-09-2004 CD N 57.45 3.00 0.00 7.45 50.00 pkaluski N lkowalski 09-09-2004

TESTER.PL

Strona 33 z 49

12345 12345/3 15-09-2004 25-09-2004 CS Y 500.00 300 5.00 200.00 300.00 pkaluski Y lkowalski 16-09-2004

12345 12345/4 22-09-2004 01-10-2004 CD Y 5000.00 0 250.14 2000.00 3000.00 pkaluski N zjankowsk 02-10-2004

Jak widać, dane są kompletne, ale trudno je nazwać czytelnymi. Jeżeli ktoś ciągle sądzi, że te dane są czytelne to mam dla niego prosty test. Proszę w ciągu 10 sekund określić, jaka jest wartość pola LAST_NOTE w wierszu z tabeli CUSTOMERS.

Jakkolwiek można trochę nad tymi danymi popracować i ich prezencję upiększyć, to wyraźnie widać pewną sprzeczność między czytelnością a kompletnością raportu. Im bardziej kompletne dane zamieszczamy w raporcie (zapytania na wszystkich zmodyfikowanych tabelach, wszystkie kolumny) tym raport staje się mniej czytelny ze względu na natłok danych. Z drugiej strony, wybiórcze umieszczanie danych w raporcie ma 2 wady:

• jest czasochłonne (zawsze jest łatwiej napisać “select *” niż select z nazwami poszczególnych kolumn)

• selekcjonując dane, możemy nie udokumentować wierszy, kolumn, których zawartość na początku wydawała się nieważna a potem okazała się mieć duże znaczenie.

LReport radzi sobie z tą sprzecznością, co zademonstruję w tym przykładzie.

Oto jak wygląda raport, wygenerowany przez LReport dla stanu sprzed testu:

Rysunek 1 - Stan bazy danych przed wykonaniem testu

TESTER.PL

Strona 34 z 49

Jak widać nie wszystkie kolumny są uwzględnione w dokumencie. Co więcej, niektóre są pokolorowane, dzięki czemu łatwiej jest zidentyfikować, do jakich kolumn należą dane wartości. Powyższy raport jest utworzony w formacie RTF. Dzięki temu łatwo jest go skopiować i wkleić do dokumentu w formacie Word. Poza tym, LReport tworzy we wskazanym katalogu pliki tekstowe CSV, w których znajdują się pełne rezultaty wszystkich interesujących nas zapytań. Dzięki temu, z jednej strony mamy czytelny raport a jednocześnie mamy zapisany komplet danych, do którego możemy się odwołać w przypadku, gdy będzie potrzebna dokładniejsza analiza.

Po wykonaniu scenariusza (w naszym przypadku – dodaniu usługi), LReport pomaga nam sporządzić raport ze stanu po wykonaniu testu:

Rysunek 2 - Stan bazy danych po wykonaniu testu

LReport nie tylko zaprezentował wyniki zapytań po wykonaniu testu. Dodatkowo, uwypuklił zmiany, jakie zaszły w bazie danych. W tabeli CUSTOMERS pole NUMBER_OF_SERVICES jest wydrukowane kursywą, pogrubione i podkreślone. Oznacza to, że wartość tego pola zmieniła się po wykonaniu testu. Rzeczywiście, przed wykonaniem testu była to wartość 2, a po wykonaniu - 3.

W tabeli SERVICES, ostatni wiersz jest wydrukowany kursywą, pogrubiony i podkreślony. W ten sposób oznaczony jest nowy wiersz, tzn. taki, którego przed wykonaniem testu nie było w tabeli. Z tego samego powodu ostatni wiersz tabeli INVOICES ma taki sam format.

Podsumujmy. LReport stworzył za nas czytelny, ładnie sformatowany raport z wyników interesujących nas zapytań. Jednocześnie, zachował komplet danych w plikach

TESTER.PL

Strona 35 z 49

tekstowych, dzięki czemu łatwo będzie przeanalizować komplet danych w przyszłości, gdyby okazało się, że w raporcie nie zawarliśmy ważnych kolumn.

Oczywiście, LReport nie jest tak mądry, aby samemu zdecydować o sposobie formatowania wyników. Musimy go sami skonfigurować. Jak to robimy, pokażę później.

Teraz chciałbym powiedzieć o drugiej ważnej funkcjonalności LReport – porównywaniu rezultatów zapytań z oczekiwaniami.

Automatyzacja testów Śledząc różne opracowania na temat automatyzacji testów można by odnieść

wrażenie, że najważniejszą gałęzią tej dziedziny jest automatyzacja operacji na GUI. Jakkolwiek są aplikacje i środowiska, w których część GUI-owa testów zajmuje dużo czasu, to jest też wiele sytuacji, kiedy jest wręcz przeciwnie. Operacje GUI-owe zajmują wprawnemu testerowi mało czasu w porównaniu w innymi czynnościami, które musi wykonać, aby w pełni przeprowadzić testy. Do takich czynności należą:

• Znajdowanie danych spełniających warunki początkowe scenariusza testowego. Np. mamy reaktywować klienta, który był dezaktywowany 2 miesiące temu i

w momencie dezaktywacji miał określoną grupę przywilejów. Często okazuje się, że znalezienie w bazie testowej takiego klienta zajmuje dużo więcej czasu niż przeprowadzenie potem testu

• Weryfikacja rezultatów Jeżeli testujemy transakcję, która modyfikuje 5 tabel, to dokładna weryfikacja

rezultatów jest zadaniem żmudnym, czasochłonnym, przy którym łatwo popełnić pomyłkę.

• Dokumentacja rezultatów Test automatyczny też jest testem. W związku z tym też musi być

udokumentowany, najlepiej automatycznie.

LReport nie pomoże nam przy wyszukiwaniu danych testowych. Ale może być bardzo użyteczny przy automatycznej weryfikacji i dokumentowaniu rezultatów. Przejdźmy od razu do przykładu.

Przykład – cd. Wyobraźmy sobie, że testujemy funkcjonalność z poprzedniego przykładu. Tym

razem jednak w testowanej aplikacji jest błąd. Błąd polegający na tym, że po dodaniu jednej nowej usługi:

• Pole NUMBER_OF_SERVICES w tabeli CUSTOMERS ma złą wartość • W tablicy SERVICES zamiast jednego, dodawane są 2 wiersze • W tablicy INVOICES powinien być dodany jeden nowy wiersz. Tymczasem, zamiast

tego usunięty zostaje jeden z istniejących.

Oto jak LReport raportuje ten problem dla tablicy CUSTOMERS:

TESTER.PL

Strona 36 z 49

Rysunek 3 - Raportowanie błędu dla tablicy CUSTOMERS

LReport prezentuje wynik zapytania. Poniżej informuje, że pewne wartości w wierszu różnią się od oczekiwanych. Informacja ta jest przekazana w postaci tabelki. Pierwsze kolumny to klucz tabeli (w tym przypadku CUSTOMER_ID). Następnie pokazane są wszystkie kolumny, dla których wartości są inne niż oczekiwane. Pierwszy wiersz zawiera wartości oczekiwane, drugi – faktyczne. Jak widać, po dodaniu jednej usługi, w polu NUMBER_OF_SERVICES pojawiła się wartość 7 zamiast oczekiwanej wartości 3.

Przejdźmy do tabeli SERVICES:

Rysunek 4 - Raportowanie błędu dla tablicy SERVICES

Zamiast jednego, pojawiają się dwa nowe wiersze. Czyli jeden wiersz pojawił się nieoczekiwanie. Zostajemy o tym poinformowani przez LReport.

Tabela INVOICES:

TESTER.PL

Strona 37 z 49

Rysunek 5 - Raportowanie błędu dla tablicy INVOICES

Zamiast dodać jeden wiersz, program jeden wiersz usunął. Efekt jest taki, że brak dwóch oczekiwanych wierszy. Tego, co istniał i został błędnie usunięty oraz tego, który powinien być wstawiony. LReport informuje o tym w sekcji oczekiwanych, ale nie znalezionych wierszy. Przy okazji, proszę zwrócić uwagę na prezentację wierszy, które zostały usunięte - czyli poprzednio były, a teraz ich nie ma. Są one prezentowane z użyciem czcionki przekreślonej.

Konfiguracja narzędzia. LReport jest obiektowo zorientowaną biblioteką napisaną w Perlu. Pakiet instalacyjny

w formacie obsługiwanym przez program ppm, jest dostępny na stronie http://lreport.sourceforge.net. Zainstalowanie go nie powinno być trudne.

Osobnym tematem jest definicja układów raportów i definicja oczekiwań dla weryfikacji rezultatów. Oto przykład definicji układu raportu dla tablicy CUSTOMERS i SERVICES:

TESTER.PL

Strona 38 z 49

Rysunek 6 - Definicja raportu dla tabel CUSTOMERS i SERVICES

Do definicji używamy pliku XML. Dla każdej tabeli (a tak naprawdę zapytania) tworzymy tag SELECT. Zawiera on takie składowe jak STATEMENT, która określa jakie zapytanie jest bazą danego raportu, KEY, określająca kolumny, które jednoznacznie identyfikują wiersz. Kolumny, które się pokażą w raporcie i ich ewentualne kolory definiujemy za pomocą tagów COLUMN. Tym samym fragment:

<COLUMN name=”NUMBER_OF_SERVICES”

color=”yellow” />

określa, że prezentacja wyników zapytania na tabeli CUSTOMERS będzie zawierać kolumnę NUMBER_OF_SERVICES i wartości w tej kolumnie zostaną pokolorowane na żółto.

Jest więcej szczegółów konfiguracyjnych. Nie będę ich tu teraz przedstawiał, bo nie jest celem tego artykułu przedstawienie kompletnej instrukcji obsługi narzędzia LReport. Chciałem raczej przedstawić jego możliwości. Dokumentację można znaleźć na stronie http://lreport.sourceforge.net. Szczególnie polecam tutorial.

TESTER.PL

Strona 39 z 49

Zakres zastosowań LReport jest narzędziem, które niewątpliwie może przynieść duże oszczędności czasu

potrzebnego na testowanie. Jednak definicja raportów a już tym bardziej specyfikacja oczekiwań do weryfikacji rezultatów zajmują czas. Dlatego LReport powinien być używany do pomocy w operacjach powtarzających się. Jeżeli testujemy daną funkcjonalność co miesiąc to wtedy warto sięgnąć po LReport. Jeżeli przy testach różnych funkcjonalności zawsze interesują nas zmiany w tych samych tabelach to wtedy warto sięgnąć po LReport. Warto też sięgnąć po LReport przy automatyzacji testów i tworzeniu testów regresyjnych. We wszystkich tych przypadkach, początkowa inwestycja szybko się zwróci.

Są jednak inne sytuacje. Czasami testujemy nową funkcjonalność, która często gruntownie się zmienia, co powoduje, że w każdym teście wykonujemy inne zapytania i już do nich nie wracamy. Czasami badamy aplikację, tworząc szereg jednorazowych zapytań. Wtedy LReport nie jest najlepszym wyborem. Lepiej wtedy skorzystać z narzędzia typu RapidSQL, OraTool czy SQLPlus. Doskonale nadają się one do tych celów i trudno mi sobie wyobrazić coś lepszego.

Teraźniejszość i przyszłość LReport LReport jest rozwijany jako projekt open source na stronie Source Forge

(www.sourceforge.net). Na razie narzędzie rozwijam sam. Jestem otwarty na wszelkie sugestie, uwagi i pomoc. Pierwszą wersję narzędzia używam w codziennej pracy w zespole System Test w Polkomtelu.

TESTER.PL

Strona 40 z 49

Badboy – nie taki zły jak nazwa wskazuje

Robert Rzeszotek

Robert Rzeszotek

Jest absolwentem Wydziału Elektrycznego Politechniki Warszawskiej. Od ponad dwóch lat uczestniczy w projektach informatycznych jako tester. Jest pracownikiem firmy IMPAQ. Dziedzina jego zainteresowań to wykorzystanie narzędzi Open Source w procesie testowania.

TESTER.PL

Strona 41 z 49

Badboy7 – nie taki zły jak nazwa wskazuje

Robert Rzeszotek

Kiedy testy regresyjne doprowadzają testera do szału wciąż powtarzającą się pracą, zazwyczaj przychodzą myśli o automatyzacji, jako złotego środka na pozbycie się rutyny. Tu pojawiają się problemy: jakie narzędzie wybrać, ile będzie to kosztować i ile czasu zajmie nam przygotowanie scenariuszy testowych. W niniejszym artykule chciałbym zaprezentować narzędzie do automatyzacji testów aplikacji okienkowych, narzędzie darmowe, które nie wymaga poświęcania ogromnej ilości czasu na przygotowanie scenariuszy testowych. Narzędziem tym jest Badboy. Badboy znacznie ułatwia testowanie poprzez nagrywanie skryptów testowych i późniejsze ich odtwarzanie. Nie posiada żadnych skomplikowanych funkcji, jest prostym intuicyjnym narzędziem do wykonywania testów jednostkowych.

Badboy działa monitorując aktywną przeglądarkę Internet Explorer, która jest widoczna w jego oknie. Zapisuje interesujące nas wydarzenia, które można potem zobaczyć, jeśli się zechce, oraz powtórzyć nagrany scenariusz. Narzędzie to pozwala na odtwarzanie scenariuszy testowych tak, by użytkownik widział kroki, jakie wykonuje narzędzie, jeśli nie interesuje nas obserwowanie kroków, scenariusz testowy możemy uruchomić w tle.

Badboy jest zbudowany z trzech głównych okien:

• Okna przeglądarki, gdzie dokonuje się nagrywania jak również gdzie obserwuje się działanie scenariusza testowego.

• Okna scenariusza testowego, gdzie widzimy wszystkie przypadki testowe, kroki tych przypadków, zmienne jakie należy zdefiniować, odpowiedzi i ich czas.

• Okno narzędzi, gdzie widzimy: o wyniki wykonywanych testów wraz ze średnim czasem, który był poświęcony

na odtworzenie scenariusza, o wartości zmiennych jakie są używane w danym teście. Podczas wykonywania

testu są wyświetlane tylko te zmienne, które są używane akurat w tym momencie.

o wykres czasów wykonywania poszczególnych scenariuszy w czasie, o opcje dostępne przy tworzeniu scenariuszy testowych, o listę dostępnych form w nagranym scenariuszu.

7 http://www.badboy.com.au/

TESTER.PL

Strona 42 z 49

Rys. 1 Interfejs narzędzia Badboy

Poniżej zostanie przedstawiony przykład scenariusza testowego, który umożliwi zaprezentowanie niektórych funkcji tego narzędzia. Scenariusz testowy będzie testował wysyłanie sms’a ze strony jednego z operatorów GSM. Dodatkowo zostanie zmodyfikowany tak, by wysyłał na różne numery, które będzie pobierał z pliku.

Nagrywanie

Nagrywanie może być włączone bądź wyłączone. Jeśli Badboy jest w trybie nagrywania, w nagłówku okna przeglądarki pojawia się komunikat.

Jeśli naciśniemy przycisk Play bądź Stop, nagrywanie zostanie zakończone. Jeśli naciśniemy przycisk Play, automatycznie zostanie zatrzymane nagrywanie, a skrypt testowy zostanie uruchomiony. Można ponownie zacząć nagrywanie poprzez naciśnięcie na czerwony przycisk Nagrywania w pasku narzędzi.

Tak więc można zacząć nagrywać nasz scenariusz testowy znając podstawową funkcję tego narzędzia. Naciskamy czerwony przycisk nagrywania wybierając go z paska narzędzi. W polu Url: wpisujemy stronę http, którą chcemy przetestować i naciskamy przycisk Go. Strona zostanie załadowana do okna BadBoy’a. Wykonujemy odpowiednie czynności na stronie, które umożliwią nam wysłanie sms’a; czyli wpisanie numeru, na który zostanie wysłany sms, oraz treści, jaka ma być wysłana. Wysyłamy przez naciśnięcie przycisku Wyślij. Zatrzymujemy nagrywanie przez naciśnięcie przycisku Stop w pasku narzędzi. Wykonane w oknie operacje zostały zapisane w formie kroków w oknie kroków scenariusza

Okno przeglądarki

Okno kroków scenariusza testowego

Okno narzędzi

TESTER.PL

Strona 43 z 49

testowego. Zostały również zapisane dane, które wprowadzaliśmy nagrywając ten scenariusz testowy.

W ten nieskomplikowany sposób mamy już sporządzony prosty scenariusz testowy, który możemy wykonać przez naciśnięcie przycisku Play. Wynik każdego z kroków zostanie zapisany przy każdym kroku scenariusza testowego. Dodatkowo zostanie też zapisany czas odpowiedzi każdego z kroków.

Mając nagrany scenariusz testowy możemy go przeanalizować. Postaram się opisać ten scenariusz testowy.

Rys. 2. Okno dialogowe scenariusza testowego

Każdy scenariusz testowy posiada swój nagłówek, pod którym są umieszczone kroki testowe jakie narzędzie wykonuje podczas odtwarzania scenariusza. W pierwszym kroku zawsze znajduje się lokalizacja serwera, gdzie zainstalowana jest aplikacja. W zależności od testowanej strony, w krokach pojawiają się zmienne i odpowiedzi. Zmienne pojawiają się w tych krokach, w których jest zapis danych. Natomiast odpowiedzi pojawiają się w każdym wykonanym kroku. W odpowiedziach podany jest dodatkowo czas odpowiedzi. Pojawienie się odpowiedzi informuje o wykonaniu kroku. Jeśli test jest powtarzany, wiemy ile razy, ponieważ liczba powtórzeń jest zliczana.

Nagłówek testu

Krok testu

Odpowiedzi testu

Zmienne

TESTER.PL

Strona 44 z 49

Zmienne jakie po nagraniu scenariusza znajdują się w krokach są to zmienne, które wprowadziliśmy podczas nagrywania testu. Każda zmienna odpowiada jednemu polu w aplikacji, do którego została wprowadzona dana. Możemy je modyfikować poprzez dwukrotne kliknięcie zmiennej. Pojawi nam się okno gdzie możemy dokonać

Rys. 3 . Okno właściwości zmiennych

Rys. 4. Okno dialogowe dołączania źródła zmiennych

zmiany wartości zmiennej, jak też

nazwy samej zmiennej (rys. 3).

Mamy już wykonany

główny test, który został

uruchomiony i działa. Teraz do tego

scenariusza dodamy sprawdzanie

różnych danych. Dane w Badboy

mogą być pobierane bezpośrednio

z bazy danych, arkusza

kalkulacyjnego, Accessa, bazy

FoxPro. W niniejszym przykładzie

dane będą wprowadzone w Excelu.

Po zdefiniowaniu tablicy

zmiennej naciskamy przycisk Next.

Pojawia nam się okno: preferencje źródła

danych. Mamy w jednym okienku

zmienne, a w drugim wartości. Możemy

je odpowiednio sformatować

w zależności od typu danych. Jeśli to

mają być dane tekstowe, powinniśmy

odznaczyć pierwszą opcję w poniższych

polach. Jeśli danymi mają być liczby

całkowite, odhaczamy drugą opcję, a jeśli

TESTER.PL

Strona 45 z 49

Rys. 5 . Okno dialogowe preferencji źródła danych

dane mają być z miejscami po przecinku, wtedy należy wybrać opcję trzecią (rys 5).

Gdy mamy już zdefiniowane źródło danych, musimy dla każdej zmiennej w polu wartości wpisać nazwę zmiennej, która będzie pobierana np. z excela. W naszym przypadku nazwy zmiennych w arkuszu excela zostały tak samo nazwane, jak zmienne ze scenariusza testowego. Aby zdefiniować zmienne tak, by były pobierane z arkusza excela, należy kliknąć na zmienną prawym klawiszem myszy i wybrać opcję Add as variable. W polu wpisujemy nazwę zmiennej, jaka jest zdefiniowana w arkuszu. Po modyfikacji zmiennych okno scenariusza testowego wygląda jak pokazano na rysunku 6.

Rys. 6. Okno dialogowe scenariusza testowego o wprowadzeniu nazw zmiennych

Gdy już mamy ustawione zmienne musimy ustawić pętlę, która pomoże nam, by te zmienne przyrastały. Dokonujemy tego w następujący sposób: klikamy prawym klawiszem na krok testu, który odpowiada za wprowadzanie danych do aplikacji i wybieramy z menu rozwijalnego Insert -> Increment. Otrzymujemy okno dialogowe właściwości przyrostu zmiennych. Pierwsza opcja to przyrost wszystkich zmiennych, natomiast druga opcja to przyrost specyficznej zmiennej, która może być wybrana z listy rozwijalnej.

Dodatkowo w oknie zmiennych

pojawiły się zmienne, które zostały

dodane. Jeśli klikniemy prawym

klawiszem myszy, będziemy mieli

kilka opcji, które można użyć, by

zmienne dostosować do scenariusza

testowego. Możemy dodać zmienną,

włączyć bądź wyłączyć automatyczny

przyrost zmiennych. Ustawimy dla

wybranych zmiennych automatyczny

przyrost na „yes”. Dzięki temu dla

każdego wykonania testu będzie

pobierana inna dana ze zbioru

zmiennych. Ustawienia

automatycznego dokonujemy klikając

na zmienną w oknie zmiennych,

prawym klawiszem otwieramy menu

i wybieramy opcję Auto increment on.

TESTER.PL

Strona 46 z 49

Rys. 7. Okno właściwości przyrostu zmiennych

Teraz, aby scenariusz był wielokrotnie powtarzalny, należy ustawić mu ilość powtórzeń. Dokonujemy tego w następujący sposób:

Klikamy prawym klawiszem myszy na nagłówek testu i wybieramy z menu rozwijalnego Properties. Pojawia się nam okno dialogowe, w którym mamy możliwość zdefiniowania nazwy scenariusza i liczby powtórzeń dla wszystkich zmiennych oraz dla zmiennej, którą wybierzemy z rozwijalnej listy.

Rys. 8. Okno właściwości przypadku testowego

Aby scenariusz testowy był kompletny, należy dodatkowo ustawić warunek, który ma być sprawdzany przez nasz scenariusz testowy. W naszym scenariuszu testowym będzie to informacja o potwierdzeniu wysłania smsa. Ustawienia tego warunku dokonujemy przez dodanie go do odpowiedniego kroku, wykorzystując funkcję Assertion. W oknie dialogowym możemy dokładnie zdefiniować jak ma być wykonywane to sprawdzenie. Czy ma być sprawdzany tekst, który ma istnieć na tej stronie czy nie; czy ma być sprawdzany we wszystkich ramkach czy tylko na górze.

Otrzymujemy okno dialogowe

właściwości przyrostu zmiennych. Pierwsza

opcja to przyrost wszystkich zmiennych,

natomiast druga opcja to przyrost

specyficznej zmiennej, która może być

wybrana z listy rozwijalnej.

Zmienne, które

chcemy by były zmieniane

podczas wykonywania testu,

zostały ustawione.

TESTER.PL

Strona 47 z 49

Rys. 9 Okno dialogowe do definiowania właściwości sprawdzania warunków

Rys. 10 Skonstruowany scenariusz testowy

Tak skonstruowany scenariusz testowy pojawi nam się w oknie scenariusza testowego w formie jak na rysunku 10.

Gdy scenariusz testowy jest już gotowy możemy zacząć go używać. Uruchomienie zostaje wywołane poprzez komendę Run. Test zostaje wykonany, a jego wyniki pokazane w oknie wyników.

Możemy zrobić zrzut ekranu

w przypadku niepoprawności, możemy

ustawić poziom zawiadomienia nas

o wystąpieniu nieprawidłowości oraz dalsze

zachowanie scenariusza po wykryciu

niepoprawności. W naszym scenariuszu

zostało ustawione szukanie wyrażenia

zawartego we wszystkich ramkach. Jeśli

zostanie wykryta jakaś nieprawidłowość,

zostanie wysłane powiadomienie,

a wykonywanie scenariusza testowego

zostanie przerwane w miejscu, gdzie

wystąpiła nieprawidłowość.

Tak zaprojektowany scenariusz

testowy możemy uruchomić

przyciskiem Run z paska narzędzi.

Wykona on 10 takich samych

scenariuszy, ale dla każdego ze

scenariuszy, dla każdej zmiennej,

będzie pobierana inna wartość z pliku

zewnętrznego.

TESTER.PL

Strona 48 z 49

Rys. 11 Okno wyników

Przy dużej ilości scenariuszy testowych i dużej ilości powtórzeń można uruchomić scenariusz testowy w tle. Można to zrobić w łatwy sposób uruchamiając Tools -> Run Background Treads. Uruchamiając w ten sposób scenariusze nie mamy jednak wyników. Jednak przy testach stabilności, bądź też przy testach wydajności, ta funkcja jest niezwykle przydatna.

Rys. 12 Okno dialogowe właściwości wykonywania testów w tle

Dodatkowo nie musimy uruchamiać scenariusza, przez otwieranie Badboya, lecz używając do tego linii poleceń. Szczególnie jest to użyteczne kiedy nie zależy nam na obserwacji czynności, które wykonuje narzędzie i chcemy np. uruchomić zestaw scenariuszy testowych na całą noc.

To jedna z podstawowych funkcji tego narzędzia, umożliwiająca tworzenie nieskomplikowanych automatycznych testów dla aplikacji okienkowych. Jak każde narzędzie, i to ma swoje ograniczenia, ale posiada również swoje zalety.

Prezentacja wyników jest dla każdego kroku, nie

dla całego scenariusza, co przy skomplikowanych

scenariuszach testowych może być kłopotliwe, jeśli

przyjdzie nam znaleźć krok, który nie przeszedł testu.

Możemy w tym oknie

ustawić ilość wątków, jakie

mają być wykonywane,

czyszczenie odpowiedzi, a także

opóźnienie z jakim ma być

wykonywane kolejne

powtórzenie. Uruchomienie

następuje poprzez naciśnięcie

przycisku Start.

TESTER.PL

Strona 49 z 49

Do zalet narzędzia należy zaliczyć prostotę w użyciu. Obsługa jest prawie intuicyjna, więc aby wykorzystywać to narzędzie do pracy nie jest konieczne żadne szkolenie, wystarczy trochę czasu by przeczytać może część instrukcji i „pobawić się” narzędziem, nagrywając jakieś scenariusze testowe. Dodatkowym plusem jest to, że efekty tego co narzędzie robi, pojawią się w jego oknie dialogowym.

Niewątpliwą wadą narzędzia jest ograniczona ilość powtórzeń danego scenariusza. Maksymalnie można powtórzyć skrypt testowy 500 razy. Jeśli skrypt zostanie wykonany 500 razy, tester ponownie musi włączyć skrypt. Również blokujące są odpowiedzi, czyli wyniki każdego z kroków. Przy dużych scenariuszach testowych będzie powstawało dużo tego typu informacji, co będzie spowalniało narzędzie. Co jakiś czas należy wyczyścić odpowiedzi. Nie ma tego problemu, jeśli testy będą wykonywane w tle. Wadą jest również niemożliwość zapisania wyników w pliku, który po serii testów można by poddać analizie.

Narzędzie Badboy jest wciąż udoskonalane. Co jakiś czas pojawiają się nowe wersje zawierające nowe funkcjonalności pozwalające na konstruowanie coraz bardziej zaawansowanych scenariuszy. Może za jakiś czas to narzędzie będzie porównywalne do komercyjnych narzędzi do automatyzacji testów.