RonPatton TestowanieOprogramowania

Okadka, 8 I 2002
Strona 1 (3)
[okadka strona 1-a]
Ron Patton
Testowanie Oprogramowania
Opanowanie zasad
1. Skutki bdw oprogramowania i znaczenie
testowania
2. Umiejtnoci niezbdne, aby znajdowa bdy
we wszystkich typach programw
3. Skuteczne planowanie testw, informowanie o
znalezionych bdach i ocena wasnych
osignicia jako specjalisty
Zastosowanie nowych umiejtnoci
4. Uycie nowonabyte umiejtnoci nie tylko do
testw oprogramowania, ale take do
weryfikacji specyfikacji produktu, do kodu
rdowego, a nawet do podrcznikw
uytkownika
5. Testowanie oprogramowania pod wzgldem
kompatybilnoci, prostoty uytkowania i
specyfiki kulturowej
6. Udoskonalenie wydajnoci testowania za
pomoc automatyzacji
Okadka, 8 I 2002
Strona 2 (3)
[okadka strona 4-a]
Testowanie Oprogramowania to ksika dla pocztkujcych i ambitnych

specjalistw, ktrzy chc nauczy si czego wicej na temat tej kluczowej
fazy procesu wytwarzania oprogramowania. Zoono i wielko
dzisiejszych aplikacji jest taka, e nawet bardzo dowiadczeni programici
nie s w stanie napisa kodu zupenie wolnego od bdw. W poczniu ze
wzrastajcym uzalenieniem ludzi od oprogramowania nawet przy
wykonywaniu zwykych, codziennych czynnoci, a take w zwizku z
wszechobecnoci oprogramowania w subie zdrowia, telekomunikacji, w
procesach produkcyjnych i w brany finansowej, bdy mog grozi
katastrof.
Oprogramowania o wysokiej jakoci nie da si stworzy przy pomocy
dorywczego polowania na bdy w niepenym wymiarze godzin. Konieczna
jest systematyczna i zdyscyplinowana metodyka zapobiegania, znajdowania
bdw oraz informowania o nich. Testowanie Oprogramowania uczy jak z
powodzeniem testowa oprogramowanie i jak znajdowa niebezpieczne
bdy - zanim natrafi na nie klienci.
Ron Patton ma ponad 15 lat dowiadczenia w testowaniu oprogramowania i

w zapewnianiu jakoci jako tester, kierownik zespou i meneder w firmach
Texas Instruments, Siemens i Microsoft. Pracowa w rnych projektach:
poczwszy od testowania krytycznego dla produkcji, automatycznego
oprzyrzdowania fabryki , poprzez laboratorium wytwarzania aplikacji
multimedialnych, produkcj urzdze peryferyjnych, a do ruchomej lalki
Barney. Obecnie pracuje jako konsultant komputerowy w stanie
Washington, a ponadto zajmuje sie ochotniczo zarzdzanmiem logistyk w
Czerwonym Krzyu w Seattle.
ZASADY I ICH ZASTOSOWANIE

7. Podstawowe metody stosowane do wytwarzania
oprogramowania
8. W jaki sposb testowanie wchodzi w skad
procesu wytwarzania oprogramowania
9. Podstawowe techniki uywane do testu
programw i do znajdowania bdw
10. Zastosowanie technik testowania niezalenie od
rodzaju, wielkoci i zoonoci oprogramowania
11. Wiedza o tym, e celem jest znajdowa bdy
jak najwczeniej i jak najskuteczniej to
zrealizowa
Okadka, 8 I 2002
Strona 3 (3)
12. Ilo moliwego testowania (i znajdowanych
bdw) jest ograniczona
13. Zidentyfikowanie polityki przedsibiorstwa
dotyczcej testowania
14. Zastosowanie rozmaitych narzdzi do
automatyzacji testowania
15. Jak planowa testw i ledzi ich przebieg
16. Jak taktownie poinformowa programist, e w
jego kodzie s bdy
17. Zanjom kierunkw rozwoju przemysu
infomratycznego i umiejtno pokierowania
wasn kerier w tym kierunku
[okadka strona 2-a]
Co eksperci powiedzieli na temat "Testowania

Oprogramowania" Rona Pattona
"Ta ksika uatwi nowym i niedowiadczonym testerom napyw do
pczkujcego sektora testowania oprogramowania. Listy kontrolne i pytania
kontrolne na kocu kadego rozdziau s bezcenne dla pocztkujcych
testerw, ktrzy chc rzeczywicie dobrze opanowa materia. atwy styl
Pattona i jego nacisk na rozwj umiejtnoci czytelnika pozwalaj take
dowiadczonym testerom na wykorzystanie tej ksiki jako rampy startowej
do dalszej kariery."
-
Susan Archer, dyrektor Software Testing Institute. Susan Archer ma 14letnie dowiadczenie w zakresie testowania oprogramowania i
automatyzacji testowania w branach telekomunikacyjnej, bankowej,
ubezpieczeniowej, Intenetowej i w doradztwie. Susan Archer jest te
prelegentem na konferencjach oraz autorem artykuw powiconych
testowaniu oprogramowania.
"Podoba mi si podzia na rne rodzaje testowania, takie jak testowanie

aplikacji Internetowych, lokalizacji itd. Mam wraenie, e nauczywem si
sporo nowych "chwytw" podczas lektury niektrcyh rozdziaw.
Zastosowany w ksice podzia uatwi take wykorzystanie jej jako
podrcznika."
-
Rick Craig jest popularnym prelegentem na wielu konferencjach i

cenionym nauczycielem na szkoleniach w zakresie testowania.
Uczestniczy i zarzdza wieloma projektami, zarwno systemw
tradycyjnych jak i wbudowanych. Jest wspautorem studium
powiconemu ocenie metodyk powszechnie stosowanych w przemyle
informatycznym. By redaktorem czasopisma Software Quality
Management.
"Test Oprogramowania Pattona jest przystpnym i nietrudnym wstpem do

wiata zawodowego testowania oprogramowania. Pocztkujcy tester
zdobdzie podstawy potrzebnych wiadomoci oraz wskazwki, jakie
bardziej zaawansowane umiejtnoci mog by przydatne w dalszej
karierze. Ta ksika jest dobrze napisana, ma dobry ukad i jest atwa i
przyjemna w lekturze."
- Danny R. Faught, Software Alchemist, Cigital, Inc. Danny Faught jest
twrc FAQ [listy odpowiedzi na najczstsze pytania] do grupy dyskusyjnej
comp.software.testing oraz wspzaoycielem dyskusyjnej listy pocztowej
swtest-discuss. Publikowa w czasopimie Software Testing and Quality
Engineering oraz wystpowa na konferencjach, midzy innymi Quality
Week oraz STAR.
Spis treci oryginau:

Przedmowa od tumacza (str.11)
Wprowadzenie (str.15)
Cz I. Obraz oglny (str.21)
1. Test oprogramowania - to (str.23)
Opisy niesawnych bdw oprogramowania (str.24)
Krl Lew w wytwrni Disneya, 1994-1995 (str.24)
Bd dzielenia zmiennoprzecinkowego w procesorze Pentium, 1994 (str.
24)
Ldownik NASA na Marsie, 1999 (str.25)
Pocisk obrony przeciwrakietowej Patriot, 1991 (str.26)
Bd roku 2000-ego, okoo 1974 (str.27)
Co to jest bd? (str.27)
Terminologia awarii oprogramowania (str.27)
Bd oprogramowania: formalna definicja (str.29)
Czemu zdarzaj si bdy? (str.31)
Koszt bdw (str.32)
Co waciwie robi si testujc oprogramowanie? (str.33)
Jak zosta dobrym testerem? (str.34)
Podsumowanie (str.36)
Pytania (str.36)
2. Wytwarzanie oprogramowania (str.39)
Skadniki produktu informatycznego (str.39)
Jak powstaje oprogramowanie? (str.40)
Z czego skada si produkt informatyczny? (str.44)
Zesp wytwarzajcy oprogramowanie (str.45)
Modele cykli yciowych wytwarzania oprogramowania (str.46)
Metoda skokowa (Wielki Wybuch) (str.47)
Metoda prb i bdw (str.48)
Metoda kaskadowa (str.49)
Metoda spiralna (str.51)
Pytania (str.53)
3. Rzeczywisto testowania oprogramowania (str.51)
Aksjomaty testowania (str.52)
Programu nie da si przetestowa cakowicie (str.52)
Testowanie oprogramowania jest ryzykowne (str.53)
Test nie udowodni braku bdw (str.55)
Im wicej bdw si znalazo, tym wicej bdw pozostaje (str.55)
Paradoks pestycydw (str.56)
Nie wszystkie znalezione bdy zostan naprawione (str.56)
Trudno powiedzie, kiedy bd jest bdem (str.58)
Specyfikacje produktu nigdy nie s gotowe (str.59)
Testerzy nie s najbardziej lubiani w zespole (str.59)
Testowanie oprogramowania to zawd cile techniczny (str.60)
Terminologia i definicje w testowaniu oprogramowania (str.60)
Precyzja a trafno (str.61)
Weryfikacja i walidacja (str.62)
Jako i niezawodno (str.62)
Test i zapewnienie jakoci (QA) (str.63)
Pytania (str.64)
Cz II. Podstawy testowania (str.65)
4. Badanie specyfikacji (str.67)
Od czego zacz (str.68)
Metody czarnej skrzynki i metody szklanej skrzynki (str.69)
Testowanie statyczne i dynamiczne (str.70)
Test specyfikacji: statyczny test metod czarnej skrzynki (str.70)
Oglny przegld specyfikacji (str.71)
Wejcie w skr klienta (str.72)
Zbadanie istniejce standardw i zbiorw regu (str.72)
Przegld i przetestowanie podobnego oprogramowania (str.74)
Techniki szczegowego testowania specyfikacji (str.74)
Kontrolna lista atrybutw specyfikacji (str.74)
Kontrolna lista terminologii (str.75)
Pytania (str.77)
5. Test z klapkami na oczach (str.79)

Dynamiczne testowanie metodami czarnej skrzynki: z zawizanymi oczami
(str.80)
Test pozytywny i test negatywny (str.82)
Metoda klas rwnowanoci (str.84
Testowanie danych (str.87)
Warunki graniczne (str.88)
Wewntrzne warunki graniczne (str.93)
Warto domylna, warto pusta, spacja, warto zerowa, brak danych
(str.96)
Dane nieprawidowe, bdne, mylne i mieci (str.97)
Testowanie zmian stanw (str.97)
Test przepywu przej midzy stanami programu (str.99)
Negatywne testowanie stanw (str.103)
Inne techniki czarnej skrzynki (str.107)
Zachowa si jak gupi uytkownik (str.107)
Szuka bdw tam, gdzie ju si jakie znalazo (str.107)
Posucha wasnego dowiadczenia, intuicji i przeczu (str.108)
Pytania (str.109)
6. Analiza kodu (str.111)
Statyczne testowanie metodami szklanej skrzynki: badanie projektu i kodu
(str.112)
Formalne przegldy (str.113)
Kontrole koleeskie (str.115)
Rczny sprawdzian (str.115)
Inspekcje (str.116)
Standardy i reguy programowania (str.116)
Przykady standardw i regu programowania (str.117)
Skd wzi standardy? (str.120)
Lista kontrolna do przegldw kodu (str.120))
Bdy w odwoaniach do zmiennych (str.120)
Bdy w deklarowaniu zmiennych (str.121)
Bdy obliczeniowe (str.121)
Bdy w porwnaniach (str.122)
Bdy przepywu sterowania (str.122)
Bdy w parametrach procedur (str.123)
Bdy wejcia i wyjcia (str.123)
Inne kontrole (str.124)

Pytania (str.125)
7. Testowanie rentgenem (str.127)
Dynamiczne testowanie metodami szklanej skrzynki (str.128)
Dynamiczne testowanie a lokalizowanie i usuwanie bdw (str.129)
Testowanie kawakw (str.130)
Test komponentw i test integracyjny (str.131)
Przykad testu moduu (str.133)
Pokrycie danych (str.136)
Przepyw danych (str.137)
Wewntrzne wartoci graniczne (str.137)
Wzory i rwnania (str.138)
Wymuszanie awarii (str.139)
Pokrycie kodu (str.140)
Pokrycie wiersza kodu i instrukcji (str.141)
Pokrycie rozgazie programu (str.142)
Pokrycie warunkw logicznych (str.143)
Pytania (str.144)
Cz III. Zastosowanie umiejtnoci w praktyce (str.143)
8. Testowanie konfiguracji (str.145)
Przegld testowania konfiguracji (str.146)
Lokalizacja bdw konfiguracji (str.149)
Dobr wielkoci zadania (str.151)
Jak podej do zadania (str.153)
Zdefiniowanie potrzebnych rodzajw sprztu (str.153)
Okrelenie dostpnych marek, modeli i programw obsugi urzdze (str.
153)
Zdefiniowanie moliwych cech, trybw pracy i opcji (str.154)
Zmniejszenie liczby konfiguracji do dajcej si opanowa iloci (str.155)
Zidentyfikowanie tych szczeglnych cech oprogramowania, ktrych
dziaanie zaley od konfiguracji sprztu (str.156)
Skonstruowanie zada testowych do uycia na kadej konfiguracji (str.
157)
Wykonanie testw na kadej konfiguracji (str.157)
Ponowne wykonywanie zada testowych a do skutku (str.158)

Jak zdoby potrzebny sprzt (str.158)
Jak zidentyfikowa standardy sprztu (str.159)
Testowanie konfiguracji innych typw sprztu (str.160)
Pytania (str.161)
9. Testowanie kompatybilnoci (str.163)
Przegld testowania kompatybilnoci (str.164)
Rne platformy i wersje aplikacji (str.165)
Kompatybilno wprzd i wstecz (str.166)
Skutki testowania rnych wersji (str.167)
Standardy i normy (str.168)
Standardy i normy wysokiego poziomu (str.169)
Standardy i normy niskiego poziomu (str.170)
Kompatybilno wsplnych danych (str.170)
Pytania (str.173)
10. Testowanie rnych wersji jzykowych (str.175)
Aby sowa i rysunki miay sens (str.176)
Kwestie tumaczenia (str.177)
Rozszerzanie tekstu (str.177)
ASCII, DBCS i Unicode (str.178)
Klawisze skrtu (str.180)
Rozszerzone znaki (str.180)
Obliczenia na znakach (str.180)
Czytanie od lewej do prawej i od prawej do lewej (str.181)
Teksty w grafice (str.182)
Tekst naley przechowywa z dala od kodu (str.182)
Kwestie lokalizacji (str.183)
Zawarto (str.183)
Formaty danych (str.185)
Zagadnienia konfiguracji i kompatybilnoci (str.186)
Midzynarodowe konfiguracje platform (str.187)
Kompatybilno danych (str.188)
Jak dugo trzeba testowa? (str.189)
Pytania (str.192)
11. Test atwoci korzystania (str.191)

Testowanie interfejsu uytkownika (str.192)
Na czym polega dobry interfejs uytkownika? (str.192)
Zgodno ze standardami i reguami (str.194)
Intuicyjno (str.195)
Spjno (str.196)
Elastyczno (str.197)
Wygoda (str.198)
Poprawno (str.199)
Uyteczno (str.200)
Testowanie dostpnoci dla osb niepenosprawnych (str.201)
Takie jest prawo (str.202)
Funkcje dostpnoci oprogramowania (str.202)
Pytania (str.205)
12. Testowanie dokumentacji (str.207)
Rodzaje dokumentacji oprogramowania (str.207)
Znaczenie testowania dokumentacji (str.210)
Pod jakim ktem testowa dokumentacj (str.211)
Rzeczywisto testowania dokumentacji (str.213)
Pytania (str.215)
13. Testowanie witryn WWW (str.217)
Podstawowe wiadomoci na temat stron WWW (str.218)
Testowanie metodami czarnej skrzynki (str.220)
Tekst (str.221)
cza (str.222)
Grafika (str.223)
Formularze (str.223)
Obiekty i inne elementy zoone (str.224)
Testowanie metod szarej skrzynki (str.224)
Testowanie metodami szklanej skrzynki (str.227)
Testowanie konfiguracji i kompatybilnoci (str.229)
Testowanie uytecznoci (str.230)
Wprowadzanie automatyzacji (str.233)
Pytania (str.234)
Cz IV. Czym wesprze testowanie (str.235)
14. Testowanie automatyczne i narzdzia do testowania (str.237)
Poytki z automatyzacji i z narzdzi (str.238)
Narzdzia do testowania (str.239)
Analizatory i monitory (str.240)
Sterowniki (str.241)
Namiastki (str.243)
Narzdzia do testowania przeciajcego i na obcienie (str.244)
Generatory zaburze i szumu (str.245)
Narzdzia analityczne (str.246)
Automatyzacja testu oprogramowania (str.247)
Nagrywanie i odtwarzanie (str.247)
Programowane makroprogramy (str.250)
W peni programowalne automatyczne narzdzia do testowania (str.251)
Testowanie na chybi-trafi: mapy i goryle (str.254)
Gupie mapy (str.255)
Pgupie mapy (str.256)
Bystre mapy (str.257)
Uycie narzdzi i automatyzacja testowania w rzeczywistoci (str.258)
Pytania (str.260)
15. Polowanie na bdy i testowanie beta (str.261)
Nie wszystko da si zauway (str.261)
Jak podzieli si testowaniem (str.263)
Testowanie beta (str.264)
Jak zleci testowanie innej firmie (str.265)
Pytania (str.267)
Cz V. Dokumentacja testowania (str.269)
16. Planowanie testowania (str.271)
Cele planowania testw (str.272)

Tematyka planowania (str.273)
Oczekiwania (str.273)
Ludzie, miejsca i rzeczy (str.2740
Definicje (str.275)
Podzia odpowiedzialnoci (str.277)
Co testowa, czego nie testowa (str.277)
Fazy testowania (str.279)
Strategia testowania (str.279)
Wymagania dotyczce zasobw (str.280)
Zadania dla testerw (str.280)
Harmonogram testw (str.281)
Zadania testowe (str.283)
Raporty o bdach (str.283)
Pomiary i statystyka (str.283)
Ryzyko (str.284)
Pytania (str.285)
17. Jak pisa zadania testowe i rejestrowa ich wyniki (str.287)
Cele planowania zada testowych (str.287)
Przegld planowania zada testowych (str.289)
Grupy zada testowych (str.291)
Zadania testowe (str.293)
Procedury testowe (str.295)
Organizacja i zarzdzanie zadaniami testowymi (str.298)
Pytania (str.300)
18. Raportowanie wynikw (str.303)
Co zrobi, eby bdy byy naprawiane (str.304)
Izolowanie i odtwarzanie bdw (str.310)
Bd bdowi nierwny (str.312)
Cykl yciowy bdu (str.314)
Systemy ledzenia bdw (str.317)
Standard: raport o incydencie (str.318)
Rczne raportowanie i ledzenie bdw (str.319)
Automatyczne raportowanie o bdach i ledzenie ich (str.321)
Pytania (str.325)
19. Pomiar sukcesu (str.327)
Wykorzystanie danych z bazy raportw o bdach (str.328)
Pomiary stosowane w testowaniu (str.329)
Typowe pomiary stosowane w projekcie (str.335)
Pytania (str.341)
Cz VI. Przyszo (str.339)
20. Zapewnienie jakoci oprogramowania (str.341)
Jako jest za darmo (str.342)
Test i zapewnienie jakoci w przedsibiorstwie (str.343)
Testowanie oprogramowania (Software Testing) (str.344)
Zapewnienie jakoci (Quality Assurance, QA (str.345)
Inne nazwy dla zespou odpowiedzialnego za test (str.346)
Zarzdzanie testowaniem a struktury organizacyjne (str.347)
CMM (model poziomu jakoci procesu wytwrczego) (str.350)
ISO 9000 (str.353)
Pytania (str.356)
21. Kariera testera oprogramowania (str.357)
Praca testera (str.358)
Jak znale prac jako tester? (str.359)
Jak zdoby praktyczne dowiadczenie? (str.360)
Wyksztacenie, szkolenia, certyfikaty (str.361)
Doczenia internetowe (str.362)
Organizacje (str.363)
Dalsza lektura (str.364)
Pytania (str.365)
Dodatek A. Odpowiedzi na pytania (str.367)
Skorowidz (str.389)
Strona 1 (2)
Przedmowa od tumacza
Test oprogramowania? A c to za nowa specjalno? Czy krawiec potrzebuje
osobnego specjalisty od sprawdzania jakoci kroju i wytrzymaoci szww, a
budowniczy mostw - testera mostw, specjalizujcego si w bieganiu z
centymetrem w trakcie budowy i w sprawdzaniu, czy wymiary konstrukcji zgodne
s z planami? Dlaczeg to jedna z faz - chyba nienajwaniejsza? - procesu
konstrukcyjnego, miaby uzyska a tak nadzywaczajn nobilitacj do godnoci
osobnej specjalizacji?
Oto seria rozpowszechnionych nieporozumie. Bior si one z prby stosowania
kryteriw stosownych w tradycyjnych branach do informatyki, w ktrej
obowizuj nieco innne zasady. Owszem, brana galanteryjna ani budownictwo
drogowe nie przewiduj osobnej specjalnoci testera. Jednak rnica midzy
nimi a wytwarzaniem oprogramowania jest olbrzymia. Wszystkie ubrania czy
mosty s w jaki sposb - mimo wszelkie rnice - do siebie podobne, podczas gdy
struktura, funkcja, zakres i sposb dziaania rnych typw oprogramowania
bywaj tak odmienne, jak odmienne s np. ksiegowo przedsibiorstwa od
algorytmu dziaania automatycznej centrali telefonicznej. Systemy
oprogramowania s najbardziej zoonymi konstrukcjami stworzyonymi przez
czowieka. Dlatego ich weryfikacja - od fazy specyfikacji i planowania poczwszy,
na tecie akceptacyjnym w trakcie wdroenia skoczywszy - wymaga wielu
specjalnych umiejtnoci, odrbnych od tego, co trzeba umie by zaprojektowa
architektur lub by zaprogramowa system.
Ponadto - wbrew pozorom - dziedzina zwana testowaniem oprogramowania nie jest
wcale nowa, raczej nieco zapomniana i zaniedbana. W wydanej po raz pierwszy w
1975 roku, klasycznej dzi ksice The Mythical Man-Month (co mona
przeoy na Mityczny osobodzie), jej autor - F. P. Brooks - twierdzi, e w
typowym projekcie informatycznym testowanie zajmuje w sumie okoo 50% czasu,
podczas gdy pisanie kodu - mniej ni 20%. Od tego czasu proporcje te nie ulegy
wikszym zmianom. Skoro wic bez sprzeciww akceptuje si istnienie
specjalnoci programisty, czemu jest tyle oporw wobec zasadnoci wyrnienia
zawodu testera?
Wszyscy - producenci i klienci, integratorzy, programici i uytkownicy ponosimy dzi koszty systemw informatycznych niedopracowanych, niezgodnych
z faktycznymi potrzebami zleceniodawcy, wykonanych niechlujnie, zawodnych,
niszczcych nasze dane, nasz wysiek, czas, pienidze i nerwy. wiadomo, e ten
stan rzeczy musi si zmieni wzrasta i jednoczenie systematycznie wzrasta status
zawodu testera. W Stanach Zjednoczonych istniej dzi tysice firm
specjalizujcych si w usugach testowych, rynek oferuje setki rozmaitych narzdzi
sucych do automatyzacji rnych etapw procesu testowania. W Europie proces
ten rwnie nabra rozmachu w cigu ostatnich omiu - dziesiciu lat. Trwaj
obecnie midzy innymi prace nad stworzeniem oglnoeuropejskiego systemu
zawodowych certyfikatw dla testerw, co powinno przyczyni si wybitnie do
wzrostu odrbnoci, statusu i poziomu tego zawodu.
Strona 2 (2)
Na polskim rynku usug, narzdzi i szkole oferta testowa jest na razie bardzo
uboga. Polski przemys informatyczny przeywa dotd okres rozwoju
ekstensywnego, napdzanego wzgldn tanioci pracy oraz olbrzymim popytem
niezaspokojonych potrzeb, spowodowanych dekadami rozkadu przed nadejciem
roku 1989. Wymagania kolejnej fazy rozwoju - integracja z gospodark Eurolandu,
przestawienie si przemysu informatycznego w kierunku eksportu - bd
trudniejsze. Dzi tylko nieliczne, co wiksze firmy informatyczne mog si
pochwali wiadom polityk dotyczc jakoci i osobnym dziaem testowania.
Istnieje wprawdzie troch polskojzycznych publikacji powiconych testowaniu,
ale s to prace naukowe lub przynajmniej przeznaczone dla rodowiska
akademickiego, trudne i niezbyt przydatne dla przecitnego, zawalonego prac
programisty, testera, kierownika projektu lub menedeera.
Ksika Rona Pattona Test oprogramowania (tyyu oruginau: "Software
Testing") znakomicie trafia w t luk. Napisana jest bardzo prosto i przystpnie, ale
zarazem nie stroni od podejmowania tematw trudniejszych. Wywd wsparty jest
wielk iloci konkretnych przykadw, pozwalajcych zrozumie praktyczne
konsekwencje omawianego zagadnienia. Wiekszo przykadw pochodzi ze
wiata doskonale znanego nam wszystkim - systemu Windows i jego najczciej
spotykanych aplikacji oraz Internetu. Wreszcie dua iloc starannie dobranych
wicze i pyta na zakoczenie kadego rozdziau pozwala na to, by zmierzy swj
poziom opanowania tematu. Nie trzeba by informatykiem, by mc odnie z tej
ksiki korzy, ale rwnie dowiadczony programista moe si z niej wiele
nauczy. Chocia autor wielokrotnie podkrela, e jest to ksika dla
pocztkujcych testerw, jest ona take znakomitym wprowadzeniem do tematu dla
menedera czy kierownika projektu, ktry pragnie szybkiego, zrozumiaego i
skutecznego wprowadzenia w t tematyk, kluczow dla powodzenia projektw
informatycznych.
Lietratura i zasoby internetowe powicone testowaniu o kontroli jakoci
oprogramowania s bogate - uzupenilimy ksik o obszerny spis literatury
fachowej, ktrego nie byo w wydaniu oryginalnym. Ksika Pattona jest
doskonaym punktem startowym, wstpem do zapoznania si z caym tym
dostpnym bogactwem. Rwnie student informatyki, przygotowujcy si na
przykad do podjcia podyplomowego studium inynierii oprogramowania
(niektre polskie wysze uczelnie oferuj takie kursy), na pewno nie poauje
kilkunastu godzin spdzonych na lekturze tej ksiki. Z myl o takich
czytelnikach, doczony do ksiki zosta spory sowniczek angielsko-polski i
polsko-angielski terminologii.
W trakcie lektury bdzie mona czasem - czytajc przypisy tumacza - odnie
wraenie, e tumacz nie we wszystkim zgadza si z autorem. To prawda. Te
polemiki jednak na pewno nie przynosz szkody czytelnikowi, przeciwnie pozwalaj nauczy si myle samodzielnie i zapozna si z rnymi moliwymi
podejciami do opisywanych zagadnie.
Powodzenia w testowaniu!
Bogdan Bereza
bogdan@victo.eu
www.victo.eu
Pocztek, strona 1 (7)
19 IX 2001
Testowanie Oprogramowania
Ron Patton
Tumaczenie: Bogdan Bereza
Skrcony spis treci

<do uzupenienia>
19 IX 2001
19 IX 2001
Spis treci
<do uzupenienia>
O autorze
Ron Patton mieszka w stanie Waszyngton, gdzie pracuje jako konsultant
komputerowy. Ma bogate i urozmaicone dowiadczenie w dziedzinie
testowania oprogramowania: od systemw krytycznych ze wzgldu na
bezpieczestwo po programy do malowania dla dzieci. W roku 1984
otrzyma licencjat z informatyki. Prac rozpocz w przedsibiorstwie Texas
Instruments, gdzie by inynierem od zapewnienia jakoci, testujc systemy
wbudowane i interfejs uytkownika w automatycznych urzdzeniach
przemysowych. W roku 1992 zacz prac w Microsofcie jako kierownik
zespou testujcego dla aplikacji Multimedia Viewer. Nastpnie zosta
menederem testw na wydziale produktw dla dzieci, gdzie wwczas
skonstruowano wiele popularnych aplikacji. Ostatnio jest menederem
testw w dziale sprztu, Microsoft Hardware Group, gdzie produkuje sie
oprogramowanie dla myszy, klawiatur, sprztu do gier i telefonii.
Projektem, ktry Ron pamita najlepiej, by testowanie sprztu i
oprogramowania dla lalki Barney. Ron wspomina, e Micorsoft paci nam
za to, e trzlimy, piekli, zamraali, odmraali, rozcigali, rzucali,
przewracali i wstrzsali dziesitki prototypw lalki Barney, ktre
obracalimy w elektroniczny zom i purpurowe strzpy. Trudno o peniejsz
satysfakcj dla kogo zajmujcego si testem.
Komentarze, propozycje zmian albo raporty o znalezionych bdach mona
przsa do Rona na adres test@valart.com.
Dedykacja
Mojej najdroszej onie i przyjacice Valerie, ktra powicia lato
cierpliwie czekajc a skocz t ksik. Hej, Valerie, moemy ju wyj na
spacer!
Podzikowania
Jak przekaza nam swoj opini
19 IX 2001
Czytelnicy ksiki s dla nas najwaniejszymi krytykami i komentatorami.

Cenimy sobie opinie czytelnikw i chcemy wiedzie co robimy dobrze, co
moemy poprawi, w jakich dziedzinach czytelnicy chcieliby widzie nasze
kolejne publikacje.
Piszc do nas, prosimy poda tytu i autora ksiki oraz wasne imi,
nazwisko, numer telefonu i nyumer faksu.
Nasz adres:
Fax:
+1-317-581-4770
E-poczta:
adv_prog@mcp.com
Adres pocztowy:
Associate Publisher
Sams
201 West 103rd Street
Indianapolis, IN 46290 USA
Wstp
19 IX 2001
Wydaje si, jakby codziennie pojawiaa si jaka nowa historia o awarii

oprogramowania komputerowego: bank zawiadamia o bednym
podsumowaniu zawartoci kont, ldownik na Marsa znika w Kosmosie,
skaner w supermarkecie policzy za duo za banany, wreszcie zej sawy bad
roku 2000-ego.
Czemu tak si dzieje? Czy programici nie potrafi znale sposobu, eby
oprogramowanie najzwyczajniej dziaao poprawnie? Niestety, nie. Im
bardziej zoone, wielofunkcyjne i pene licznych zewntrznych pocze
staje si oprogramownaie, tym trudniej stworzy programy pracujce besz
potkni. Bez wzgldu na to, jak dobrzy s porogramici i ile stara sie
dooy, problemy z oprogramowaniem bd zawsze.
Tutaj wanie jest miejsce na test oprogramowania. W procesie produkcji
rozmaitych towarw dziaaj kontrolerzy jakoci. Tak samo
oporgramowanie potrzebuje kontrolerw. Wiele duych wytwrni
oproramownia zaczo stawiac na jakoc do tego stopnia, e zatrudnia tyle
samo lub wicej testerw1 ni programistw. Znajdzie si tych ludzi przy
wytwarzaniu oprogramowania gier, poprzez uatomatyczne linie produkcyjne
a do aplikacji biznesowych.
Ta ksika, Test Oprogramowania, jest wprowadzeniem do podstawowych
zasad testu: uczyc nie tylko podstawowych umiejtnoci technicznych, ale
rwnie organizacyjnych, potrzebnych aby odnie sukces w dziedzinie
testu oprogramowania. Mona si z niej nauczy, jak szybko znale bdy
w kadym programie komputerowym, jak zaplanowa efektywny sposb
podejcia do test, jak sprzdza przejrzyste raporty na temat znalezionych
bdw i jak stwierdzi, czy program jest ju dostaecznej jakoci, eby
wypuci go do klinta czy na rynek.
Kto powinien korzystac z tej ksiki?
Tumaczenie sowa tester jako osoba zjamujca si testowaniem jest niezrczne i na pewno bez
szans na przyjcie si w potocznym jzyku zawodowym. Specjalista testowania i analityk
testowania to nieco domienne funkcje. Dlatego decydujemy si na tumaczenie angielskiego sowa
tester na tester, ktre tak fonetycznie, jak i pod wzgldem moliwoci deklinacji dobrze pasuje do
jzyka polskiego.
19 IX 2001
Ksika skierowana jest do trzech rnych grup czytelnikw:

1. Studenci albo hobbyci zainteresowni
testowaniem jako prac. Naley przyczyta t
ksik przed pojciem na pierwszy wywiad
albo przed pierwszym dniem w nowej pracy, aby
rzeczywicie mz ziamponowac nowemy
szefowi.
2. Osoby pragnce zmienic karier ze swojej
obecnej brany do brany komputerowej. Dla
osb nie majcych doiwadczenia z produkcj
oprogramowania istnieje rwnie wiele okazji,
aby zastosowa swoj wiedz to testowania
oprogramowania. Na przykad, instruktor latania
moe testowa gr symulujc pilota, ksigowy
aplikacj do przygotowaywania deklaracji
podatkowych, a nauczyciel programy
edukacyjne dla dzieci.
3. Programistw, meneder projektw i innych
osb wchodzcych w skad zespou
projektowego, ktrzy chc poszerzy i pogbic
swoja wiedz na temat testu oprogramowania.
Do czego suy ta ksika

Z tej ksiki mozna si nauczy czego na temat niemal wszystkich apektw
testu oprogramowania:
4. W jaki sposb testowanie wchodzi w skad
procesu wytwarzania oprogramowania
5. Bodstawowe i zaawansowane techniki testowe
6. Jak stosowa te umijtnoci do typowych zada
testowych
7. Jak ulepszy skuteczno testw przy pomocy
automatyzacji
8. Planowanie i dokumentowanie testw
9. Skuteczne raportowanie znalezionych bdw
10. Dokonywanie pomiarw pracy testowej i
postpw w wytwarzaniu produktu
11. Zrozumie rnic midzy testowaniem a
zapewnieniem jakoci
12. Znale zatrudnienie jako specjalista w
dziedzinie testowania
Oprogramowanie potrzebne do tej ksiki
19 IX 2001
Przedstawione w ksice metody s oglne i mona je stosowa do

testowania kadego typu oprogramowania. Aby uatwi zrozumienie
przykadw, zostay oparte na takich powszechnie znanych i prostych
programach jak Kalkulator, Notatnik i NotatnikWord dostepnych w
Windowsach 95/98 oraz w Winpowsach NT/2000.
Nawet jeli nie ma si do dyspozycji PC z Windowsami, prawdopodobnie
ma si do dyspozycji podobne programy na kadym innym typie komputera,
ktre dadz sie zastosowa do przykadw. Bd twrczy! Bycie twrczym
to jedna z cech dobrego specjalisty od testowania.
Znajdujce si w ksice przykady rozmaitych aplikacji, bdw w
programach oraz narzdzi do testowania w adnym wypadku nie maja za
cel ani poparcia, ani dyskredytowania tych porduktw. Przykady te uyte
s wycznie w celu zilustrowania poj z dziedziny testu
oprogramowania.
Organizacja ksiki
Ksika ma za cel by dla czytelnika przewodnikiem w drodze do zostania
kompetentnym specjalist w dzidzinie testu oprogramowania. Testowanie
nie polega na waleniu na olep w klawiatutr z nadzij, e w kocu uda si
zawiesi komputer. Kryje siza nim nauka i umiejtnoci inynierskie,
dyscyplina i planowanie, a przy okazji wiele frajdy jak ju wkrtce bdzie
si mozna przekona.
Cz I: Obraz oglny
Cz II: Podstawowe zasady testowania
Cz III: Zastosowanie umiejtnoci w
dziedzinie testowania
Cz IV: Metody dodatkowe
Cz V: Praca z dokumentacj testu
Cz VI: Przyszo
Dodatek
Konwencje stosowane w ksice
Ron Patton Test oprogramowania
Cz I
Cz I, strona 1 (44)
Obraz oglny
Kiedy zawiesza si program konkurencji, to jest awaria. Kiedy zawiesza si

wasny program, to jest drobiazg. Czsto, po awarii pojawia si
komunikat typu DR 02. DR to skrt od drobiazg, a nastpujca po
nim liczba wskazuje, przez ile jeszcze miesicy produkt informatyczny
powinien by testowany.
Guy Kawasaki, The Macintosh Way
Uwielbiam ostateczne terminy. Zwaszcza podoba mi si wist, jaki wydaj

kiedy nas mijaj.
Douglas Adams, autor The Hitch Hiker`s Guide to the Galaxy
W TEJ CZCI
Test oprogramowania: to
Proces wytwarzania oprogramowania
Test oprogramowania w rzeczywistoci
Wersja 9 padziernika 2001, Bogdan Bereza-Jarociski
Rozdzia 1
Cz I, strona 2 (44)
Test oprogramowania - to
W TYM ROZDZIALE
Opisy niesawnych bdw oprogramowania
Co to jest bd?
Czemu zdarzaj si bdy?
Koszt bdw
Co waciwie robi si testujc oprogramowanie?
Jak zosta dobrym specjalist od testowania?
W roku 1947, komputery byy wielkimi maszynami zajmujcymi cay
pokj, pracujcymi na mechanicznych przekanikach i arzcych si
lampach elektronowych. Szczytem techniki by wwczas komputer Mark
II, olbrzym budowany na Uniwersytecie Harwardzkim. Technicy wanie
dokonywali rozruchu nowego komputera, ktry nagle si zatrzyma.
Rzucono si szuka przyczyny i znaleziono m, wcinit midzy dwa
przekaniki gboko we wntrznociach komputera. Najwyraniej ma,
zwabiona wiatem i ciepem, wleciaa do wntrza urzdzenia i zostaa
zabita przez prd, kiedy wyldowaa na przkaniku.
Tak narodzi si komputerowy bug1. W porzdku, ten bug akurat zgin,
ale wiadomo, o co chodzi.
Zapraszamy do pierwszego rozdziau Testu Oprogramowania. Mona si
w nim zapozna z histori kilku bdw i z histori testowania
oprogramowania.
Najwaniejsze tematy w tym rozdziale to midzy innymi:
1. Jak bdy w oprogramowaniu wpywaj na
codzinne ycie
2. Co to s bdy i dlaczego si pojawiaj
3. Kim s testerzy oprogramowania i co robi
Opisy niesawnych bdw oprogramowania
Angielskie sowo bug oznacza owada, ale od kilkudziesiciu lat podobno wanie od opisanego tu
wydarzenia z m rwnie bd w programie komputerowym (przyp. tumacza).
Cz I, strona 3 (44)
atwo dzisiaj traktowa programy komputerowe jak co oczywistego i nie

do koca zdajemy sobie spraw, jak gboko wnikny w nasze ycie
codzienne. W roku 1947, Mark II wymaga zespou programistw do
obsugi i serwisu. Przecitny czowiek nawet sobie nie wyobraa, e
pewnego dnia bdzie mie do dyspozycji wasny, domowy komputer.
Dzisiaj pyty CD-ROM znajduje si czasem doczone do pudeek z
patkami niadaniowymi, a komputer do gier dziecinnych ma w sobie wicej
oprogramowania ni prom kosmiczny. To, co kiedys byo gadetem dla
zamonych wielbicieli techniki, jak telefony komrkowe, dzi jest
powszechne. Wielu ludzi nie spdza ani jednego dnia nie wlogowujc si
cho raz na Internet i nie sprawdzjc swojej elektronicznej poczty.
Oprogramowanie jest wszdzie. Jednak pisz je ludzie a wic nie jest
doskonae, jak wymownie pokazuj ponisze przykady.
Krl Lew Disneya, 1994-1995
Jesieni 1994 roku Disney wypuci na rynek swoj pierwsz gr
multimedialn dla dzieci, The Lion King Animated Storybook (Animowane
historie o Krlu Lwie). Cho wiele innych firm ju od lat sprzedawao
programy dla dzieci, bya to pierwsza prba Disneya na tym rynku, mocno
reklamowana i wspierana. Sprzeda szybko osigna wysoki poziom, to by
dziecinny szlagier sezonu. Wkrtce jednak nastpia wielka katastrofa. 26
grudnia, dwa dni po Wigilii, telefony do obsugi klienta u Disneya zaczy
dzwoni, dzwoni i dzwoni. Technicy serwisu zostali zalani lawin
telefonw och rozgniewanych rodzicw i paczcych dzieci, nie bdcych w
stanie uruchomi programu. Pojawiy si liczne artykuy prasowe i
programy telewizyjne na ten temat. Okazao si, e Disney nie przetestowa
gry dostatecznie na wszystkich dostepnych na rynku modelach PC. Program
funkcjonowa poprawnie na kilku typach systemw zapewne na tych,
ktrymi posugiwali si piszcy gr programici ale nie na wielu
najpopularniejszych modelach.
Bd dzielenia zmiennoprzecinkowego w procesorze Pentium,
1994
Wprowadziwszy nastpujce rwnie do kalkulatora dostpnego na PC:
(4195835 / 3145727) * 3145727 4195835
jesli otrzyma si wynik zero, komputer jest w porzdku. Jeli otrzyma si

inny wynik, znaczy to e w komputerze jest stary model mikroprocesora
Intel z bdem w dzieleniu zmiennoprzecinkowym: bd oprogramowania
wprowadzony na stae w konstrukcj ukadu scalonego i powielony
wielokrotnie w procesie produkcji.
Cz I, strona 4 (44)
30-ego padziernika 1994, dr Thomas R. Nicely odkry, e przyczyn

nieoczekiwanego wyniku w jednym z jego dowiadcze by bd w
dzieleniu, ktry wystpi na komputerze wyposaonym w mikroprocesor
Pentium. Odkrycie opublikowa na Internecie i wkrtce wybucha burza:
wiele osb usiowao powtrzy jego obliczenia i w rezultacie znajdowano
nowe sytuacje, w ktrych wyniki oblicze byy bdne. Cae szczcie, byo
tych sytuacji niewiele i wystpowaywyacznie w zaawansowanych
matematycznie, naukowych obliczeniach. Wikszo uytkownikw nigdy
by na ten bd nie natrafia, wykonujc obliczanie podatku dochodwego albo
posugujc si programami do zarzdzania przedsibiorstwem.
Godny uwagi jest w tej histrorii nie tyle sam bad, co sposb, w jaki firma
Intel usiowaa poradzi sobie z sytuacj:
4. Programici Intela wykryli problem juz
wczeniej, podczas swoich wasnych testw,
prowadzonych jeszcze przed wypuszczeniem
procesora na rynek. Kierownictwo Intela
zadecydowao jednak, e bd nie by ani
dostatecznie powany, ani dostatecznie
prawdopodobny by go naprawi, ani nawet by
jego istnienie ujawni.
5. Kiedy bd zosta ju odkryty przez
uytkownikw, Intel usiowa pomniejsza jego
znaczenie poprzez oficjalne owiadczenia i
notatki w prasie.
6. Pod naciskiem opinii Intel zaproponowa w
kocu wymian wadliwego procesora, ale tylko
tym uytkownikom, ktrzy bd w stanie
wykaza, e zostali przez ten bd w jaki
sposb poszkodowani.
Opinia publiczna bya oburzona, grupy dyskusyjne na Internecie pene byy
listw od klientw, domagajcych sie, by Intel naprawi bd. Publikacje
prasowe nazyway postaw Intelu jako lekcewac i niegodn zaufania. W
kocu Intel przeprosi swoich wszystkich klientw za sposb, w jaki
usiowa zatuszowa znaczenie bdu i zgodzil si wyasygnowa sum
ponad 400 milionw dolarw na pokrycie kosztw wymiany wadliwych
procesorw. Obecnie Intel informuje o wszstkich znanych problemach na
swojej witrynie internetowej i uwanie ledzi gosy klientw na rnych
internetowych grupach dyskusyjnych.
Cz I, strona 5 (44)
28-ego sierpnia roku 2000, wkrtce przed pierwszym wydaniem tej

ksiki, Intel ogosi, e wycofuje wszystkie procesory Pentium III
1,13 MHz, ktre zostay dostarczone klientom w pierwszym miesicu
po rozpoczciu produkcji. Odkryto, e wykonanie niektrych instrukcji
programu mogo spowodowa zawieszenie si procesora. Producenci
komputerw planowali wycofanie wszystkich komputerw ju
bdcych w rkach klientw i obliczali koszty wymiany wadliwych
procesorw.
Ldownik NASA na Marsie, 1999
Trzeciego grudnia 1999 roku, ldownik marsjaski NASA znikn podczas
podejcia do ldowania na powierzchni Marsa. Komisja dokonujca
inspekcji awarii stwierdzia, e najbardziej prawdopodobn przyczyn
awarii byo nieprzewidziane ustawienie wartoci jednego bitu. Najbardziej
jednak zatrwaajce byy przyczyny, dla ktrych bd nie zosta
wychwycony przez wykonywane przez dostawc testy.
W teorii, ldowanie miao wyglda nastpujco: zbliajc si do
powierzchni Marsa, ldownik mia otworzy spadochron zmniejszajcy
szybko opadania. Kilka sekund po otworzeniu spadochronu, trzy nogi
prbnika miay si otworzy i zatrzasn w pozycji do ldowania. Na
wysokoci okolo 1800 metrw, ldownik mia odczepi spadochron i
uruchomi silniki do ldowania, aby agodnie opa na powierzchni.
Dla oszczdnoci, algorytm podejmowania decyzji o wyczeniu silnikw
ldownika zosta znacznie uproszczony. Zamiast uywanego w innych
pojazdach kosmicznych kosztownego radaru, umieszczono tani przecznik
kontaktowy na kocu nogi ldownika. Przecznik ustawia jeden bit w
rejestrze komputera, ktry nakazywa programowi odcicie dopywu paliwa
do silnika. Silniki miay zatem pracowa a do momentu dotknicia
powierzchni Marsa przez nogi ldownika.
Podczas inspekcji stwierdzono, e w czasie testw wykryto nastpujcy
bd: mechaniczny wstrzs spowodowany otworzeniem si ng uruchamia
rwnie przecznik kontaktowy, ktry ustawia feralny bit. Jest bardzo
prawdopodobne, e identyczna awaria nastpia w czasie ldowania i e
komputer, mylc e prbnik dotkn powierzchni, wyczy silniki i
ldownik roztrzska si, runwszy z 1800 metrw na powierzchni planety.
Skutki byy katastrofalne, ale ich przyczyna - banalna. Ldownik by
poddawany testom przez kilka oddzielnych zespow. Jeden zesp testowa
procedur rozkadania ng pojazdu, a inny zesp kolejne fazy procesu
ldowania. Pierwszy zesp nigdy nie sprawdza wartoci bitu
oznaczajcego kontakt z powierzchnia to przecie leao poza zakresem
ich testw. Drugi zesp zawsze przed przystpieniem do testw resetowa
komputer, co kasowao bit. Obie procedury funkcjonoway doskonale kada
z osobna, ale nie razem.
Cz I, strona 6 (44)
Pocisk obrony przeciwrakietowej Patriot, 1991

Amarykaski system obrony przeciwrakietowej Patriot jest zredukowan
wersj Strategicznej Inicjatywy Obronnej1, stworzonej przez prezydenta
USA Ronalda Reagana. Po raz pierwszy zastosowano ten system podczas
wojny nad Zatok Persk jako obron przed irackimi pociskami Scud.
Chcia prasa zamiecia wiele historii o sukcesie systemu, Patriot
zawodzi wielokrotnie, midzy innymi nie zdoa zniszczy posisku, ktry
zabi 28 amerykaskich onierzy w w Dhahran w Arabii Saudyjskiej.
Analiza ujawnia, e przyczyn niepowodzenia by bd w oprogramowaniu.
Nieznaczny bd w zegarze systemu kumulowa si tak, e po upywie 14
godzin system naprowadznia przestawa by dostatecznie dokadny. Podczas
ataku w Dhaharan, system pracowa wczeniej przez ponad 100 godzin.
Bd roku 2000-ego, okoo 1974
Gdzie na pocztku lat 70-ych nieznany programista pracowa nad
systemem listy pac dla firmy. Komputer mia bardzo ograniczon pami,
co zmuszao programist do oszczdzania kadego dostpnego bajtu. Nasz
nieznany programista by bardzo dumny, e potrafi upchn dane cianiej
ni pozostali koledzy. Jedn z jego sztuczek byo skrcenie dat z formatu
czterocyfrowego, jak 1973, na dwucyfrowy, jak 73. Poniewa program
wytwarzajcy list pac wykonywa wiele operacji wykorzystujcych dat,
mona byo w ten sposb zaoszczdzi naprawd duo pamici. Programista
zdawa sobie spraw, e to moe spowodowa kopoty, jeli program bdzie
pracowa w roku 2000-ym i zacznie wykonywa operacje na dacie 00.
Zdecydowa jednak, e program bez wtpienia zostanie zastpiony innym
przez te 26 lat, a biece sprawy byy bardziej palce ni zaprztanie sobie
gowy problemem tak bardzo odlegym w czasie. Okazao si, e w roku
1995 list pac tworzy nadal ten sam program, nieznany programista
przeszed ju na emerytur i nikt nie wiedzia, jak sprawdzi, czy program
jest zabezpieczony przed problemem roku 2000-ego, ani tym bardziej jak
mona by go naprawi.
Oszacowuje si, e koszty zastpienia takich programw nowymi oraz
koszty unaczeniania innych programw, wyniosy w sumie na caej Ziemi
kilkaset miliardw dolarw.
Co to jest bd?
Strategic Defense Initiative
Cz I, strona 7 (44)
Zapoznalimy si wanie z kilkoma przykadami tego, co si dzieje kiedy

oprogramowanie zawodzi. Moe to by tylko niewygodne, jak kiedy gra
komputerowa nie dziaa poprawnie, albo moe spowodowa katastrof, a
nawet mier ludzi. W opisanych przykadach nie byo wtpliwoci, e
oprogramowanie nie dziaao poprawnie. Jednak wikszo awarii, z
ktrymi spotykaja si testujcy oprogramowanie, nie jest rwnie oczywista.
W wikszoci ma si do czynienia z maymi, drobnymi usterkami w
dziaaniu, czsto tak nieznacznymi, e trudno jednoznacznie oceni, ktre z
nich to prawdziwe awarie.
Nazwy awarii oprogramowania
W rnych przedsibiorstwach i organizacjach uywa si rnych okrele
na sytuacj, kiedy oprogramowanie zawodzi. Oto niektre z nich:
Defekt, bd, problem, pomyka, incydent, nieprawidowo, rozbieno,
awaria, niezgodno, cecha1.
Jest te wiele wiele okrele nieprzyzwoitych, ktrych programici uywaj
zwykle tylko we wasnym towarzystwie.
Zadziwiajce, e jest tak wiele rnych nazw na okrelenie awarii
oprogramowania. Dlaczego? Moe to zalee od specyfiki obyczajw w
danym przedsibiorstwie czy od typu procesu, ktry przedsibiorstwo
stosuje przy opracowywaniu oprogramowania. Zajrzawszy do sownika,
zobaczymy e wszstkie te sowa mog si nieco od siebie rni
znaczeniem. Ich znacznie moe te si zmienia w zalenoci od kontekstu
w codziennym uyciu.
Na przykad sowa bd, awaria i defekt sugeruj sytuacj naprawd
powan, moe nawet goron. Okrelenie niewaciwego odcienia uytej
ikony bdem wydaje si niewaciwe. To sowo zdaje si te implikowa
win: To jego wina e program zawid.2
Nieprawidowo, incydent czy rozbieno nie brzmi rwnie negatywnie i
sugeruj raczej niezamierzone dziaanie ni cakowit awari: Zdaniem
dyrektora, nieprawidowo oprogramowania spowodowaa zejcie pocisku
z wynaczonego kursu.
Lista terminologii na kocu ksiki zawiera angielsko-polski i polsko-angielski sowniczek
Brytyjski standard BS 7295-1 nadaje niektrym z tych nazw zupenie rne znaczenia.
Pomyka (error) oznacza przyczyn powstania bdu w kodzie (np. zmczenie programisty,
niejednoznaczna specyfikacja konstrukcji). Bd (fault) to sam fizyczny bad, np. znajdujca si w
kodzie bdna instrukcja, niewaciwy operator czy mylna warto. Natomiast awaria (failure)
nastpuje wtedy, kiedy dziaajcy program produkuje na skutek znajdujcego si w nim bdu
faszywe wyniki. Awaria to dajcy si zaobserwowa skutek bdu. Autor tej ksiki nie wprowadza
podobnego rozrnienia, co powoduje pewn niejasno jego wywodw: wszystkie podane nazwy
odnosz si do awarii (failure).
Cz I, strona 8 (44)
Problem, pomyka i bd to chyba najczciej uywane3, oglne okrelenia.

Nie warto marnowa czasu na spory terminologiczne
Jest zastanawiajce, e wiele firm i zespow powica dugie godziny
cennego czasu na spory i debaty dotyczcce terminologii. w pewnym
znanym przedsibiorstwie komputerowym spdzono wiele tygodni na
dyskusjach, eby podj decyzj o zmanie nazwy z Raport
Nieprawidowoci na Raport Incydentu. Wydano wiele pienidzy na to,
by zdecydowa ktra z tych nazw jest lepsza. Kiedy podjto decyzj,
wszystkie wzory dokumentw, kod itd. musiay by zmienione aby
zaadoptowac now nazw. Nie wiemy, czy przyczynio si to w
jakimkolwiek stopniu do podniesienia produktywnoci programistw
albo osb testujcych program.
Po c wic porusza ten temat? Tester powinien rozumie osobow
zespou, z ktrym wsppracuje. To, jak okrela si problemy wsytpujce w
oprogramowaniu jest znaczcym sygnaem mwicym, jakie jest w ogle
podejcie do procesu konstrukcyjnego. Czy zesp jest ostrony, uwany,
bezporedni czy wrcz lubi wali prosto z mostu?
W tej ksice wszystkie problemy z oprogramowaniem bdzie si nawywa
bdami1. Niewane, czy chodzi o bdy due, mae, zamierzone, czy
przypadkowe, czy zranione zostan uczucia osoby, ktra spowodowaa bd.
Nie warto dzieli wosa na czworo: bd to bd.
Bd oprogramowania: formalna definicja
atwo jest nazwa kady problem z oprogramowaniem bdem, ale sama
nazwa jeszcze niczego nie rozwizuje. Teraz trzeba by zdefiniowa, co to
jest problem. eby nie wpa w bdne koo, potrzebna jest jednoznaczna
definicja, czym jest bd.
Najpierw potrzebne jest pojcie wspieriajce: specyfikacja produktu.
Specyfikacja produktu, czasem nazywana po prostu specyfikacj, jest
umow spisan dla zespou projektowego. Specyfikacja definiuje produkt,
ktry ma by wytworzony: co to ma by, jak to ma dziaa, co ma robi, a
czego nie robi. Taka umowa moe mie rne formy, poczwszy od
zwykego ustnego porozumienia, a skoczywszy na dokumentacji spisanej
wedug formalnych regu. W rozdziale Proces wytwarzania
oprogramowania dowiemy si wicej na temat specyfikacji i na teamt
procesu wytwarzania, ale chwilowo powysza definicja musi wystarczy.
Autor ma na myli angielskie sowa problem, error oraz bug; trudno powiedzie, jaki jest rozkad
czstoci uywania analogicznych sw w jzyku polskim.
1
Autor uywa okrelenia bug.
Cz I, strona 9 (44)
Dla potrzeb tej ksiki i wikszej czci przemysu produkujcego

oprogramowanie, bd oprogramowania ma miejsce, kiedy speniony jest
jeden lub wicej z nastpujcych piciu warunkw:
1. Oprogramowanie nie wykonuje czego, co
wedle specyfikacji powinno wykonywa.
2. Oprogramowanie robi co, czego wedle
specyfikacji powinno nie robi.
3. Oprogramowanie wykonuje co, o czym
specyfkacja w ogle nie wspomina.
4. Oprogramowanie nie wykonuje czego, czego
specyfikacja wprawdzie nie wspomina ale
powinna.
5. Oprogramowanie jest trudne do zrozumienia,
trudne do uytkowania, powolne albo zdaniem
testera bdzie w oczach uytkownika po
prostu nieprawidowe1.
Aby lepiej zrozumie kady z tych warukw, zostan one zilustrowane na
przykadzie popularnego kalkulatora.
Specyfikacja dla kalkulatora przypuszczalnie definiuje, e musi on
wykonywa poprawnie dodawanie, odejmowanie, mnoenie i dzielenie. Jesli
tester naciska bez rezultatu klawisz +, to mamy do czynienia z bdem2 ze
wzgldu na warunek nr 1 powyej. Jeli wynik dziaania bdzie bdny, to
jest rwnie bd ze wzgldu na ten sam warunek.
Specyfikacja produktu moe take stwierdza, e kalkulator nie powinien
nigdy ulega awarii, blokowa si ani zawiesza. Jeli po naciniciu
klawiszy kalkulator przestaje reagowa na dane wejciowe, jest to bd ze
wzgldu na warunek nr 2.
Czemu zdarzaj si bdy?

Skoro wiemy ju, co to s bdy, zaczynamy si zastanawia, skd si bior.
Zaskoczy moe wiadomo, e wikszoc nie jest wcale powodowana
przez pomyki w programowaniu. Przeprowadzono wiele bada na
projektach od bardzo maych do bardzo wielkich i uzyskane wyniki s
zawsze takie same. Gwn przyczyn powstawania bdw jest
specyfikacja (zob. rysunek 1.1).
Autor troch miesza w tej licie kwestie dotyczce weryfikacji (zgodno produktu z jego
bezporedni specyfikacj) i walidacji (zgodnoci produktu ze specyfikacj wymaga lub wobec jej
braku z faktycznymi oczekiwaniami klienta). Ponadto pomieszane s wymagania funkcjonalne i
niefunkcjonalne jak wydajno, atwo uytkowania itd.
2
cilej, z awari, tj. nieprawidowym dziaaniem; bdu, czyli przyczyny awarii, na razie nie da si
zidentyfikowa.
Cz I, strona 10 (44)
Rysunek 1.1 Wiele jest powodw powstawania bdw, ale gwnym

pozostaj specyfikacje
Jest kilka przyczyn, dla ktrych specyfikacje s najwikszymi producentami
bdw. W wielu wypadkach po prostu nie pisze si specyfikacji1. Kiedy
indziej specyfikacja moe nie by dostatecznie dokadna, albo nieustannie
si zmienia, albo nie jest wystarczajco znana wszystkim osobm nalecym
do zespou. Planowanie oprogramowania jest szczeglnie wane: jeli nie
zrovi si tego prawidowo, powstan poniej powane bdy.
Drugim wielkim rdem bdw jest projekt produktu, gdzie programici
tworz plany architektury systemu. Mona to porwna do architekta
sporzdzajcego rysunek techniczny nowego budynku. Bdy w projekcie
mog powsta z tego samego powodu, co w specyfikacji wymaga: gdy robi
si go zbyt popiesznie, gdy si zmienia lub nieprecyzyjnie przekazuje
innym jego tre.
Jest stare angielskie przysowie: Czego nie da si powiedzie, tego nie
da si te zrobi. To pasuje znakomicie do wytwarzania i testowania
oprogramowania.
Bdy kodowania znane s doskonale wszystkim programistom. Ich
przyczyny to zwykle zoono programu, kiepska dokumentacja (zwaszcza
w kodzie, ktry si unaczenia lub zmienia), wymagania harmonogramu
projektu albo zwyke, gupie pomyki. Warto jednak zauway, e wiele
bdw wydajcych si na pierwszy rzut oka pomykami w programowaniu,
w rzeczywistsci bierze si z bdw specyfikacji wymaga albo z projektu
konstrukcji. Czsto mona usysze, jak programista mwi: Ach, wic to
wanie mia ten program robi! Gdyby mi o tym powiedziano, nie
napisabym kodu w inny sposb.
Dokadniej, specyfikacji wymaga
Reszta to oglna kategoria dla wszelkich pozostaych przyczyn. Niektre

bdy to zamaskowane bedy: sytuacje o ktrych najpierw sdzono, e s
poprawne, potem jednak okazay si bdami. Istniej te bdy zdublowane
lub wielkorotne, wynikajce z tej samej podstawowej przyczyny. Przyczyn
niektrych bdw mog by te pomyki w testowaniu. Ostatecznie jednak
tego typu bw jest tak niewiele, e nie warto si nimi przejmowa.
Koszt bdw
Jak dowiemy si w rozdziale 2-im, oprogramowanie zwykle nie powstaje
jak za dotkniciem rdki czarodziejskiej jest wynikiem zaplanowanego,
metodycznego procesu wytwarzania. Groba pojawienia si bdw istnieje
od samego pocztku tego procesu, poprzez planowanie, programowanie,
testowanie - a do uytkownia. rysunek 1.2 pokazuj, jak koszt naprawy
bdw wzrasta, im pniej w procesie wytwarzania si je znaduje.
Rysunek 1.2 Koszt naprawy bdwwzrasta dramatycznie wraz z czasem

Wzrost kosztw moe by gwatowny, zwiksza si nawet dziesitki razy
wraz z upywem czasu. Bd znaleziony na wczesnym etapie, na przykad w
czasie pisanie specyfikacji wymaga, mona czsto naprawi niemal za
darmo. Ten zam bd znaleziony w czasie testowanie ju napisanego
programu kosztuje o wiele wicej. Znaleziony przez uytkownika, moe
kosztowa miliony.
Dla przykadu rozwamy opisany wczeniej wypadek Krla Lwa Disneya.

Bd polega na tym, e program nie dziaa na bardzo pupularnym modelu
komputera osobistego. Gdyby we wczesnym etapie konstruowania
specyfikacji wymaga zbadano, jakie modele komputerw osobistych s
najpopularniejsze i wyszczeglniono, e program naley konstruowa i
testowa na nich wanie, koszty tego byyby znikome. Skoro tego nie
zrobiono, istniaa moliwoc zebrania przez zesp testujcy popularnych
modeli PC-tw i przetestowania na nich programu. Bd zostaby
znaleziony, ale byoby to znacznie kosztowniejsze, gdy naleaoby
zlokalizowa jego przyczyn, naprawi program i przetetstowa ponownie.
Jeszcze inn moliwoci byoby przekazanie wczesnej wersji programu
maej grupie klientw w ramch tak zwanego testu beta. Jest prawdopodobne,
e reprezentatywna grupa klientw wykonujcych ten test odkryaby bd.
Nie zrobiono jednak adnej z tych rzeczy i tysice pyt CD-ROM znalazo
si w rkach klientw. Disney musia ponie koszty telefonicznego serwisu
dla klientw, zwrotw, wysyki nowych pyt z programem, jak rwnie
koszty kolejnego cyklu lokalizowanie bdu naprawa ponowny test. Jeli
powany bd trafi w rce klienta, koszty mog atwo pochon cay zysk z
produktu i gorzej.
Co waciwie robi si testujc oprogramowanie?

Widzielimy ju przykady rzeczywicie gronych bdw, znamy definiecj
bdu i wiemy, jak wysokie mog by jego koszty. Wobec tego wiemy ju
chyba , jaki jest cel pracy testera oprogramowania:
Celem testera oprogramowania jest znajdowanie bdw.
Spotyka si zespoy, wymagajce od swojego zespou testowego po proostu
potwierdzenia, e program dziaa, a nie poszukiwania bdw.
Przypomnijmy sobie przykad ldownika marsjaskiego, a zrozumiemy,
dlaczego to jest niewaciwe podejcie. Jeli testowa tylko to, co powinno
dziaa i ustawia zadania testowe tak, eby przechodzily z wynikem
poprawnym, przeoczy si to, co nie dziaa przeoczy si bdy.
Przeoczenie bdw powoduje koszty dla projektu i dla firmy. Testerom nie
moe wytarcza samo znalezienie bdw powinni starar si znale je w
jak najwczeniejszej fazie procesu wytwarzania, kiedy naprawa jest
najtasza.
Celem testera oprogramowania jest znajdowanie bdw jak
najwczeniej.
Samo znajdowanie bdw, nawet jak najwczeniej, nie wystarcza jednak.
Przypomnijmy sobie definicj bdu. Testerzy s przedstawicielami klienta,
pierwszymi uytkownikami programu. Reprezentuj interesy klienta i musz

domaga si doskonaoci1.
Celem testera oprogramowania jest znajdowanie bdw jak
najwczeniej i dopatrzenie, eby zostay naprawione.
Ta ostatnia definicja jest szczeglnie wana2. Naley j zapamita i wraca
do niej podczas lektury dalszych rozdziaw tej ksiki.
Jak zosta dobrym testerem?

W filmie Star Treck II, jego bohater Spock powiada: W historii Kosmosu
zawsze byo atwiej niszczy ni tworzy. Na pierwszy rzut oka moe si
wydawa, e testowanie powinno by atwiejsze ni programowanie.
amanie kodu i znajdowanie bdw musi przecie by atwiejsze ni
napisanie kodu. Mona si zdziwi, ale tak nie jest. Metodyczne i
zdyscyplinowane podejcie do testu oprogramowania czego uczy niniejsza
ksika wymaga rwnie cikiej pracy i zaangaowania, co
programowanie. Przydatne s podobne umiejtnoi, i chocia tester nie
musi by dowiadczonym programist, znajomoc programowania bardzo
si przydaje.
Dzi wikszo przedsibiorstw traktuje ju test jako techniczny,
inynieryjny zawd3. Uznaje si, e obecno testerw w zespoach
projektowych pozwala na konstruowanie lepszej jakoci oprogramowania.
Oto lista cech, ktre powinien mie dobrych tester oprogramowania:
7. By odkrywc. Testerzy nie mog si obawia
nieznanych sytuacji. Uwielbiaj dosta nowy
program, zainstalowa na swoim komputerze i
zobaczy, co te si stanie?
8. By owc problemw. Testerzy musz szybko
si domyla, czemu co nie dziaa. Uwielbiaj
amigwki.
Doskonao to nieosigalna mrzonka przetestowanie wszystkiego jest niezwykle kosztowne i

zwykle niewykonalne nawet w teorii. Ilo i jako testu naley dostosowa do poziomu ryzyka (przyp.
tumacza).
2
Niewielu specjalistw zgodzi si z tym pogldem. Obcienie testerw rwnie odpowiedzialnoci

za naprawienie bdu zaciera granic midzy testowaniem i konstruowaniem, co obnia jako
testowania i utrudnia planowanie harmonogramu testw (nie wiadomo, ile bdw si znajdzie, jak
trudna bdzie ich lokalizacja i ile czasu zajmie naprawa).
3
S pod tym zgldem znaczne rnice midzy krajami i branami.
9. By nieustpliwym. Testerzy prbuj raz za

razem. Zdarza si, e dostrzeg awari, ktra
potem szybko znika albo trudno j wywoa
ponownie. Zamiast j zlekceway, bd
prbowa wszelkich sposobw, aby j
odtworzy.
10. By twrczym. Testowanie tego, co oczywiste
nie wystarcza. Praca testera polega na
wymylaniu twrczych i nawet zwariowanych
sposobw szukania bdw.
11. By (dojrzaym) perfekcjonist. Dy do
doskonaoci, ale wiedzie kiedy nie da si jej
osign i umiec poprzesta na zblieniu si do
doskonaoci.
12. Wykazywa si rozsdkiem i umiejtnoci
podejmowania decyzji. Specjalici od testu
musz podejmowa decyzje co bd testowa,
przez jak dugo i czy przyczyn zaobserwowanej
awarii rzeczywicie jest bd oprogramowania?
13. By taktownym i dyplomatycznym. Testerzy
zawsze przynosz ze wiadomoci. Musz
opowiedzie programistom, e ich ukochane
dziecitko nie jest doskonae. Dobrzy
specjalici od testu potrafi zrobi to taktownie i
profesjonalnie i umieja wsppracowa z
programistami, ktrzy przecie sami nie zawsze
s taktowni i dyplomatyczni.
14. Umie przekonywa. Nie zawsze znalezione
przez testerw bdy traktuje si jako
dostatecznie powane, eby je naprawi.
Testerzy musz umie jasno wytumaczyc swj
punkt widzenia, zademonstrowa dlaczego dany
bd rzeczywicie musi by naprawiony i
dopilnowa, eby zosta faktycznie naprawiony .
Testowanie oprogramowania to frajda!
Podstawow cech testerw jest to, e po prostu lubi usiowa psu
rne rzeczy. Lubi znajdowa trudno uchwytne awarie systemw.
Znajduj wielk satysfakcj z psucia najbardziej nawet zoonych
programw. Czsto si widzi, jak skacz z zachwytu, skadaj sobie
nawzajem gratulacje i tacz, gdy uda im si zama system.
Najwaniejsze s proste, yciowe przyjemnoci.
Dodatkowo, wyksztacenie w dziedzinie programowania jest duym plusem.

Jak zobaczymy w rozdziale 6-ym Badajc kod, znajomo sposobu
pisania programu pozwala znajdowa bdy z innej perspektywy, co czyni
testera wydajniejszym i skuteczniejszym. Umiejtnoci programowania
przydadz si take przy uywaniu narzdzi do testowania opisanych w
rozdziale 14-ym Automatyczne testowanie i narzdzia do testowania.
Wreszcie, osoba bdca specjalist w jakiej dziedzinie nie-komputerowej,
moe by bardzo cenna dla projektu opracowujcego nowy produkt
informatyczny. Dzisiejsze programy dziaaj dosownie wszdzie, dlatego
znajomo pedagogiki, gotowania, samolotw, stolarki, medycyny czy
jakiejkolwiek innej brany moe by ogromn pomoc w poszukiwaniu
bdw w programach przeznaczonych dla tych dziedzin.
Podsumowanie
Test oprogramownia ma kluczowe znaczenie. Wielko i zoono
wspczesnych programw wymaga, aby testowanie wykonywa
profesjonalnie i skutecznie: ryzyko jest zbyt wielkie. Nie potrzeba nam
wicej wadliwych ukadw scalonych ani utraconych ldownikw na
Marsie.
W pozostaych rozdziaach czci I-ej dowiemy si wicej na temat
organizacji wytwarzania oprogramowania i tego, jakie miejsce zajmuje w
nim test. Zrozumnienie tego jest konieczne, by mc zastosowa w praktyce
techniki testowania opisane w dalszych czciach tej ksiki.
Pytania
Pytania maj na celu uatwienie zrozumienia. W aneksie A Odpowiedzi do
pyta znajduj si prawidowe rozwizania ale nie naley ciga!
1.Czy w opisanym przykadzie powstania bdu roku 2000-ego programista
popeni jaki bd?
2.Prawda czy falsz: to wane, jakim sowem firma albo zesp nazywa
problem w programie.
3.Dlaczego sprawdzenie tylko tego, e program dziaa tak jak powinien, nie
jest wystarczajce?
4.O ile drosze jest naprawienie bdu znalezionego ju po wypuszczeniu
produktu ni bdu znalezionego na samym pocztku projektu?
5.Jakie cele maj testerzy?
6.Prawda czy fasz: dobry fachowiec w dziedzinie testowania nieugicie
dy do doskonaoci.
7.Podaj kilka przyczyn, dla ktych najwikszym rdem bdw programu
jest zwykle specyfikacja produktu.
Rozdzia 2
Proces wytwarzania oprogramowania
W TYM ROZDZIALE
Skadniki produktu informatycznego
Personel w projekcie wytwarzania oprogramowania
Modele cykli wytwarzania oprogramowania
Aby skutecznie testowa programy komputerowe, dobrze mie przynajmniej
oglne zrozumienie jak wyglda proces wytwarzania oprogramowania.
Piszc mae programy jako studenci czy amatorzy, posugujemy si innymi
metodami ni wielkie przedsibiorstwa. Stworzenie nowego programu moe
wymaga dziesitek, setek a nawet tysicy osb majcych najrozmaitsze
role i wsppracujcych w ramach cisego harmonogramu. Proces
wytwarzania oprogramowania skada si si ze szczegowej specyfikacji co
ci ludzie robi, jak si ze sob kontaktuj, jak podejmuj decyzje.
Celem tego rozdziau nie jest wykad wszystkiego na temat procesu
wytwarzania na to potrzeba by caej osobnej ksiki! Celem jest
przekazanie podstaw wiedzy o tym, z jakich czci skada si
oprogramowanie i jakie s gwne stosowane dzi metody jego
wytwarzania. Ta wiedza pozwoli skuteczniej stosowa umiejtnoci
testowania, ktrych mona si nauczy z dalszych rozdziaw tej ksiki.
Najwaniejsze punkty tego rozdziau:
15. Z jakich podstawowych skadnikw zbudowane
jest oprogramowanie
16. Jakie osoby i umiejtnoci potrzebne s w
procesie wytwarzania oprogramowania
17. Jak wyglda droga od pomysu do kocowego
produktu informatycznego
Skadniki produktu informatycznego

Co to waciwie jest oprogramowanie? Wiele osb wyobraa je sobie jako
program, ktry instaluje si z dyskietki czy dysku CD-ROM i ktry dziaa
potem na domowym komputerze. To do trafny opis, ale w rzeczywistoci,
wiele niewidocznych elementw uczestniczy w wytwarzaniu tego programu.
Wiele innych elementw oprogramowania jest tak oczywistych, e wrcz si
o ich istnieniu zapomina. Zapomnie atwo, ale tester musi by wiadomy
ich istnienia, bo mog si w nich kry bdy.
Jak powstaje oprogramowanie?
Przyjrzyjmy si najpierw jak robi si program. rysunek 2.1 ilustruje ten
proces.
Rysunek 2.1 Wiele sabo widocznej pracy trzeba woy w powstanie

produktu informatycznego.
C wic, poza samym kodem, wchodzi w skad oprogramowania? Na
pierwszy rzut oka wszystkie pozostae skadniki s mniej konkretne ni
wydruk napisanego porzez programist kodu rdowego. Na pewno nie
znajdzie si ich na dysku CD-ROM z programem.
W przemyle wytwarzajcym oprogramowanie uywa si okrelenia
dostawa1 na okrelenie elementu oprogramowania, ktre kiedy powstao
przekazuje si komu innemu. Najprociej objani czym s dostawy dzielc
je na kilka gwnych kategorii.
Wymagania klienta
Oprogramowanie pisze si, aby zaspokoio czyje potrzeby. Tych, ktrcyh
potrzeby maj by zaspokojone, nazwijmy klientami. Aby rzeczywicie
zaspokoi potrzeby klienta, zesp projektowy musi dowiedzie si, czego
waciwie klient oczekuje. Niektre zespoy poprzestaj na domysach, ale
wikszo usiuje zebra szczegowe dane drog bada, gromadzenia
informacji na temat poprzednich wersji tego samego programu, produktw
konkurencji, artykuw prasowych i przy pomocy innych metod, formalnych
lub nieformalnych. Zebrane dane analizuje si, skraca i poddaje
interpretacjom, aby w kocu zdecydowa, jakie funkcje ma mie
wytwarzany produkt2.
Zbieranie wymaga poprzez wywiady z grup uykownikw
Ang. deliverable lub delivery (przyp. tumacza).
Ten akapit to do skrcony opis dziedziny inynierii oprogramowania zwnej inynieri wymaga
(requirement engineering). Inynieria wymaga uwaana jest za bardzo wan w zapewnieniu jakoci
produktw, ale w tej ksice doczekaa si tylko powierzchownego potraktowania (przyp. tumacza).
Popularn metod zbierania danych bezporednio od potencjalnych

uytkownikw programu jest przeprowadzanie wywiadw z losowo
wybran grup uytkownikw. Wywiady takie przeprowadzane s
czsto przez wyspecjalizowane firmy. Przeprowadzajcy wywiad
chtnie wykorzystuj centra handlowe, gdzie pytaj przechodzce
osoby, czy zechc wzi udzia w badaniu. Najpierw zadaje si kilka
pyta w celu przeprowadzenia wstpnej kwalifikacji, na przykad: Czy
masz w domu komputer? Czy uywasz programu X? Ile czasu spdzasz
podczony do Internetu? itp. Jeli osoba badana naley do grupy
potencjalnych uytkownikw, proponuje si jej uczestniczenie w
obszerniejszym, kilkugodzinnym badaniu z udziaem kliku osb. W
trakcie badania zadaje si im bardziej szczegowe pytania na temat
oprogramowania. Na przykad daje si do wyboru kilka rnych
programw i poleca wybra ulubiony, albo grupa prowadzi dyskusje o
tym, jakie funkcje pragnaby mie w nowym programie. Czas
spdzony na badaniu jest opacany.
Wikszo tego typu bada przeprowadza si tak, by zlecajca firma
pozostaa dla osb badanych nieznan. Zwykle jednak nietrudno si
domysli, jaka to firma1.
Specyfikacje
Wyniki bada wymaga klientw to waciwie dopiero wstpne dane. Nie
opisuj one proponowanego produktu, tylko potwierdzaj (lub nie) e na
produkt istnieje zapotrzebowanie i jakich funkcji oczekuj potencjalni
klienci. Specyfikacja2 gromadzi t informacj plus wszelkie pominite, ale
konieczne wymagania i ostatecznie definiuje, czym ma by produkt, co ma
robic i jak wyglda.
Specyfikacje mog wyglda bardzo rnorodnie. Niektre przedsibiorstwa
zwaszcza te, co wytwarzaj produkty dla instytucji publicznych, firm
lotniczych, finansowych oraz medycznych posuguj si bardzo
szczegowym procesem z wieloma punktami kontrolnymi. W jego wyniku
powstaje bardzo dokadna i wyczerpujca specyfikacja, ktr si zamraa,
co oznacza e zmiany dozwolone s tylko w szczeglnych wypadkach.
Kady w caym zespole wie dokadnie, co ma by wytwarzane.
Inne zespoy projektowe, zwaszcza jeli wytwarzaj oprogramowanie dla
aplikacji mniej krytycznych, posuguj si specyfikcj produktu spisan na
serwetce, jeli w ogle j maj. Elastyczno jest du zalet takiego
podejcia, ale ryzyko nieporozumie - znaczne. Na dobitk, nikt dokadnie
nie wie co jest wytwarzane, a do chwili wypuszczenia produktu.
Ta metoda jest tylko jednym z wielu sposobw zbierania wymaga, stosowanych w inynierii
wymaga. Znajduje zastosowanie wobec produktw oprogramowania nie majcych z gry okrelonego
uytkownika, sprzedawanaych masowo (przyp. tumacza).
2
cilej specyfikacja wymaga (requirements specification) przyp. tumacza.
Harmonogramy
Kluczow czci projektu jest harmonogram. Kiedy projekty staj si coraz
wiksze i bardziej zoone, kiedy na kocowy produkt skada si wiele
czci i pracuje nad nim wiele osb, konieczne staja si mechanizmy
pozwalajce na kontrol przebiegu projektu. Te mechanizmy mog by
najprostsze - jak lista zada do wykonania, poprzez bardziej zoone - jak
schematy Gantta (zob. rysunek 2.2) , a po zastosowanie oprogramowania
pozwalajcego na szczegow kontol wszelkich, nawet drobnych
czynnoci.
Celem harmonogramu jest kontrola nad tym, ile pracy ju wykonano, ile
jeszcze pozostao do zrobienia i kiedy cao bdzie ukoczona.
Rysunek 2.2 Schemat Gnatta to wykres, na ktrym poszczeglne zadania

projektu przedstawia si linie rwnolege do poziomej osi czasowej.
Dokumentacja w projekcie oprogramowania
Rozpowszechnione jest bdne mniemanie, e programista konstruujcy
program po prostu siada i zaczyna pisa kod rdowy. Tak robi si niekiedy
w maych, niesformalizowanych projektach, ale dla kadego wikszego
programu potrzebny jest proces wytwarzania, ktry pozwala zaplanowa,
jak oprogramowanie zostanie napisane. Mona to porwna z niniejsz
ksik - najpierw musiano mie zarys spisu treci, zanim przystpiono do
pisania, albo z budynkiem najpierw robi si rysunki techniczne, a dopiero
potem wylewa beton. Tak samo planowane powinno by wytwarzanie
oprogramowania.
Konstruktorzy sporzdzaja rne rodzaje dokumentacji zalenie od
przedsibiorstwa, typu projektu i zespou projektowego, ale ich cel jest ten
sam: planowanie i organizacja wytwarzania kodu.
Oto lista powszechnie stosowanych rodzajw dokumentacji:
18. Specyfikacja architektury. Dokument
opisujcy w oglnym zarysie konstrukcj
oprogramowania, jego gwne czci i ich
wspdziaanie.
19. Schemat przepywu danych. Diagram

opisujcy przepyw danych w programie.
Czasem nazywa si go diagramem
bbelkowym, poniewa rysuje si go przy
pomocy k i strzaek1.
20. Diagram stanw programu. To kojeny rodzaj
sformalizowanego diagramu, ktry opisuje
podstwaowe stany systemu oraz okrela warunki
przej midzy nimi.
21. Schemat blokowy. Tradycyjna metoda opisu
logiki programu. Schematy blokowe nie s dzi
zbyt popularne, ale jeli z nich korzytsa,
napisanie kodu na podstawie szczegowego
schematu blokowego jest bardzo proste.
22. Komentarze w kodzie rdowym. Mwi si,
e kod pisze si tylko jeden raz, ale cyta co
najmniej dziesi razy. Uyteczne komentarze
wbudowane w kod programu niezwykle
uatwiaj programistom majcym konserwowa
kod zorientowanie sie, co i dlaczego kod
wykonuje.
Dokumenty testu
Dokumentacja testu opisana jest szczegowo w rozdziaach 17 19, ale
wspomina si o niej ju tutaj, poniewa jest wanym elementem procesu
wytwarzania oprogramowania. Testerzy, podobnie jak programici, musz
planowa i udokumentowa swoj prac. Nierzadko zdarza si, e zesp
testujcy produkuje wicej dostaw ni programici.
Oto lista wanych elementw dostawy:
23. Plan testu opisuje metody, ktre bd uyte, by
zweryfikowa zgodno oprogramowania ze
specyfikacjami i z potrzebami klienta. Plan testu
zwiera opis celw jakociowych, potrzebnych
zasobw, harmonogramy, zlecenia, metody itd.
24. Lista zada testowych okrela jakie komponenty
systemu trzeba przetestowa i opisuje
szczegowo czynnoci, ktre trzeba wykona
aby zweryfikowa system2.
Opis przepywu danych przy uyciu k i strzaek to po prostu opis przy pomocy skierowanego
grafu (przyp. tumacza).
2
Ten typ dokumentu jest znany powszechniej jako specyfikacja testu (test specification) przyp.
tumacza.
25. Raporty o bdach opisuj problemy

znajdowane w czasie wykonywania testw.
Mog by robione na papierze, ale czsto
gromadzi si je w bazie danych.
26. Wyniki pomiarw, dane statystyczne i
podsumowania informuj o postpach w
procesie wytwrczym. Maja czsto form
grafw, wykresw albo pisemnych raportw.
Z czego skada si produkt informatyczny?

Jak dotd biecy rozdzia nauczy nas, jakie czynnoci potrzebne s, aby
wytworzy produkt informatyczny. Warto zda sobie spraw, e produkt,
gotowy do zapakowania i wysyki, to nie tylko kod. W jego skad wchodz
elementy serwisu (rysunek 2.3). Poniewa wszystkie skadniki porduktu
bd stosowane przez uytkownika, musz rwnie zosta przetestowane.
Niestety, te wanie czci s nieraz pomijane w procesie testowania. Kady
na pewno prbowa si posugiwa wbudowan pomoc, ktra nie bya zbyt
pomocna, albo co gorsza wrcz bdna. Albo, sprawdziwszy
wydrukowane z boku opakowania wymogi sprztowe programu, z
zaskoczeniem stwierdzamy, e wbrew opisowi oprogramowanie nie dziaa
na wanie naszym modelu PC. Przetetstowanie tego byoby trywialnie
proste, ale przypuszczalnie nikt o tym nawet nie pomyla przed podjciam
decyzji o wypuszczeniu produktu. Uytkownik owszem.
W dalszych czciach tej ksiki opisane s elementy produktu nie bdce
oprogramownaiem i sposoby ich testowania. Na razie poprzestamy na
licie przykadw:
27. pliki pomocnicze
28. prbki i przykady
29. informacja na temat serwisu
30. komunikaty o awariach
31. konfigurowanie i instalacja
32. podrczniki uytkownika
33. etykietki
34. ikony i elementy graficzne
35. ogoszenia i reklamy
36. plik readme
Rysunek 2.3 Dyskietka albo CD-ROM z programem to tylko jeden ze

skadnikw produktu programowego.
Nie zapomina o komunikatach o awarii
Komunikaty o awariach to jedna z najbardziej lekcewaonych czci
produktu informatycznego. Pisane s zwykle przrz programistw, a nie
przez wyksztaconych pisarzy technicznych. Rzadko kiedy s
planowane, zwykle si je robi w popiechu przy okazji naprawiania
bdw. Testerzy maj trudnoci ze znalezieneim, wywoaniem i
sprawdzeniem wszystkich. Nie pozwlmy, aby takie komunikaty o
awariach wkrady si do naszego oprogramowania:
Bd: brak klawiatury. Nacinij F1 aby
kontynuowa.
Nie mona zinstancjowa tej rzeczy od wideo.
Widnowsy znalazy nieznane urzdzenie i
instaluj dla niego program obsugi.
Nastpi bd krytyczny 006 pod adresem
0000:0000007.
Personel w projekcie wytwarzania oprogramowania

Dowiedziawszy si o wszstkim, co wchodzi w skad produktu i jest razem z
produktem wysyane do sprzeday, pora dowiedzie si wicej na temat
ludzi, ktrzy oprogramowanie wytwarzaj. Oczywicie, to zaley w duym
stopniu od przedsibiorstwa i rodzaju projektu Role s jednak podobne,
rnice gwnie terminologiczne.
Na licie poniej znajduj si najwaniejsi aktorzy projektu wytwarzania
oprogramowania i opisy ich funkcji. Uyte s okrelenia
najpowszechniejsze, ale spotyka si wiele innych.
37. Kierownicy projektw, kierownicy programw

albo producenci prowadz projekt od pocztku
a do koca. Ponosz odpowiedzialno za
specyfikacj produktu, za zarzdzanie
harmonogramem, za podejmowanie
najwaniejszych decyzji.
38. Architekci albo inynierowie systemu s
technicznymi specjalistami w zespole. Maj
zwykle due dowiadczenie i dlatego projektuj
architektur caego systemu albo
oprogramowania. Blisko wsppracuj z
programistami.
39. Programici, osoby piszce oprogramowanie
albo osoby piszce kod rdowy1 projektuj,
pisz i naprawiaj bdy w oprogramowaniu.
Wsppracuj blisko z architektami systemu i z
kierownikami projektu przy wytwarzaniu
oprogramowania. Wspdziaaj te z testerami,
kiedy maj usuwa znalezione przez nich bdy.
40. Testerzy albo odpowiedzialni za jako2 znajduj
i raportuj problemy w oprogramowaniu.
Wsppracuj blisko z caym zespoem podczas
wytwarzania i wykonywania testw oraz
raportowania znalezionych bdw. W rozdziale
20-ym Zapewnienie jakoci oprogramowania
opisane s szczegowo rnice midzy
zadanimi testowania oprogramowania i
zapewnienia jakoci.
41. Autorzy tekstw technicznych, obsuga klienta,
szkolenia klientw, autorzy podrcznikw
uytkownika, ilustratorzy produkuja papierow i
elektroniczn dokumentacj towarzyszc
produktowi.
42. Zarzdzajcy konfiguracj3 albo budowniczy
zarzdza procesem cznia w cao
oprogramowania napisanego przez
programistw z dokumentcj.
W jzyku angielskim: programmers, developers, coders (przyp. tumacza).
Po angielsku: QA (Quality Assurance) w USA czsto uywane na okrelenie testerw, za w

Europie - zwykle w szerszym znaczeniu osb odopowiedzialnych za zapewnienie jakoci (przyp.
tumacza).
3
Autor uywa do szczeglnej definicji zarzdzania konfiguracj. Powszechnie traktuje si

zarzdzanie konfiguracj jako czenie elementw w cao, kontrol wersji itd. w czasie caego
projektu, a nawet ycia produktu, a nie tylko w fazie czenia oprogramowania z dokumentcj (przyp.
tumacza).
Jak wida, oprogramowanie powstaje dziki wsplnym wysikom caej

grupy ludzi. Due zespoy mog mie setki wsppracownikw. Aby mc si
skutecznie porozumiewa i organizowa, potrzebny jest plan: opis metody,
jak dosta si z punktu A do punktu B. Tej tematyce powicony jest
nastpny rozdzia.
Modele cykli yciowych wytwarzania oprogramowania

Wedle popularnego w komputerowej brany przysowia, trzech rzeczy nie
naley oglda w czasie wytwarzania: praw, kiebasy i oprogramowania. Ich
tworzenie jest tak niechlujne, e najlepiej poczeka na wynik kocowy.
Moe to nie jest cakiem prawd, ale w starych powiedzonkach zawsze tkwi
ziarno prawdy. Czasem oprogramowanie wytwarza si w sposb
zdyscyplinowany, godny mistrzw dobrego rzemiosa, czasem poprzez
kontrolowany chaos, a czasem skleja si tam i gum do ucia. Zwykle
klienci s w stanie zorientowa si, w jaki sposb przebiega proces
wytwarzania programu. Proces wytwarzania oprogramowania, poczwszy
od pomysu a skoczywszy na publicznym wypuszczeniu produktu na
rynek, nosi nazw modelu procesu wytwarzania oprogramowania.
Jak powiedziane zostao poprzednio, rne s moliwe sposoby
wytwarzania oprogramowania i adem model nie jest na pewno najlepszy
dla wszystkich projektw. Cztery modele spotyka si najczciej, wikszo
pozostaych to ich odmiany:
43. metoda skokowa
44. metoda prb i bdw
45. metoda kaskadowa
46. metoda spiralna
Kada z nich ma swoje wady i zalety. Tester natknie si przypuszcalnie na
kad z nich i powinien umie dopasowa sposb testowania do metody
uywanej w biecym projekcie. W czasie lektury reszty tej ksiki
zastanwmy si, jak zastosowa rne techniki testowania do kadej z tych
metod.
Metoda skokowa (Big-Bang)
Jedn z teorii powstania wszechwiata jest teoria Big-Bang (wielkiego
wybuchu). Wedug niej, miliardy lat temu, wszechwiat powsta w wyniku
jednego gigantycznego wybuchu o wielkiej sile. Wszystko, co istnieje,
powstao jako skutek poczenia energii i materii: ta ksika, dyskietki,
nawet Bill Gates. Gdyby atomy nie ustawiy si waciwie, wszstko
mogoby by tylko trzsc si, bezmyln galaret.
Model skokowy wytwarzania oprogramowania, zilustrowany na rysunku
2.4, stosuje si do bardzo podobnej zasady. Wielk ilo materii (ludzi i
pienidzy) czy si razem, mnstwo energii wyzwala si czsto
gwatownie i powstaje doskonay produkt albo nie.
Rysunek 2.4 Metoda skokowa jest zdecydowaniem najprostszym sposobem

wytwarzania oprogramowania.
Pikno metody skokowej polega na jej prostocie. Nie stosuje si albo
niewiele palnowania, harmonogramw, formalnych metodyk wytwarzania.
Cay wysiek jest powicony wytwarzaniu programu i pisaniu kodu. Ten
proces pasuje doskonale do sytuacji, kiedy wymagania nie s jasne, a data
ostatecznego wypuszczenia produktu elastyczna. Potrzbni s te wyjtkowo
elastyczni klienci, poniewa nie bd wiedzie a do ostatniej chwili, co
waciwie dostan.
Zwrmy uwag, e na rysunku 2.4 brak testowania. W metodzie skokowej
zwykle stosuje si mao formalnego testowania. Jeli test si pojawia, to
wcinity w ostatniej chwili tu przed wypuszczeniem produktu. Pozostaje
tajemnic czemu testowanie w ogle wprowadza si do tej metody, ale
zapewne po to, eby mie czyste sumienie.
Testowanie produktu wytwarzanego metod skokow jest zarwno atwe jak
i trudne. Poniewa oprogramowanie jest ju gotowe, ma si do dyspozycji
doskona specyfikacj wynaga sam produkt! Poniewa i tak nie da si
ju nic poradzi na znalezione bdy, zadaniem testera jest jedynie zoenie
raportu na temat znalezionych bdw, eby mona o nich poinformowa
klientw.
Z stron tej sytuacji jest to, e w oczach kierownictwa projektu produkt
jest ju gotowy do wysyki, wic praca testera tylko opnia dostaw do
klienta. Im duej pracuje tester i im wicje bdw znajduje, tym bardziej
zapalna robi si sytuacja. Najlepiej unika testowania w projektach
posugujcych si metod skokow.
Metoda prb i bdw
Metoda prb i bdw, pokazana na rysunku 2.5, jest zwykle stosowana
przez wszystkie zespoy, ktre nie podjy wiadomego wysiku
zastosowania innych metod. W stosunku do metody skokowej jest to postp
wymaga przynajmniej jakiego rozeznania, jakie s wymagania dotyczce
produktu.
Rysunek 2.5 Metoda prb i bdw powtarza si a do upadego.

Kto mdry kiedy powiedzia: nigdy nie ma si czasu eby co zrobi
dobrze, ale jest zawsze czas eby musie zrobi to od pocztku. To dobre
podsumowanie metody prb i bdw. Zesp ktry si ni posuguje,
zwykle zaczyna od przyblionego rozeznania, co ma by zrobione,
wykonuje wstpny projekt, po czym wdaje si w dugi, powtarzajcy si
cykl kodowania, testowania i poprawiania znalezionych bdw. W kocu
podejmuje si decyzj co za duo, to niezdrowo i wypuszcza si produkt.
Jako e niewiele czasu trzeba powici na planowanie i dokumentacj,
zesp szybko moe pochwali si jakim konkretnym wynikiem. Z tego
powodu metoda prb i bdw dzaia znakomicie dla maych projektw,
ktre trzaba wykona jak najszybciej, a wkrtce potem mona wyrzuci na
przykad dla wytwarzania prototypw i programw do demonstracji. Ale
metoda prb i bdw bya stosowana rwnie przy wytwarzaniu wielu
duych i dobrze znanych produktw. Jeli nasz program do przetwarzania
tekstu czy arkusz kalkulacyjny ma peno drobnych bdw albo po prostu
wydaje si niewykoczony, zapewne zostal stworzony metod prb i
bdw.
Podobnie jak w modelu skokowym, w metodzie prb i bdw test nie ma
zapewnionego miejsca, ale odgrywa istotn rol w fazie midzy
kodowaniem a naprawianiem.
Bdc testerem w projekcie prowadzonym metod prb i bdw, warto
pamita e razem z programistami bdzie si uczestniczy w nieustannej
karuzeli. Nawet codziennie bdzie si otrzymywa now, unaczenion
wersj programu i trzeba si bdzie bra za jej testowanie. Puszcza si testy,
pisze raporty bdw i wkrtce dostaje si now wersj oprogramowania.
Zanim skoczyo si testowa wczeniejsz wersj, przychodzi ju kolejna,
ktra moe mie nieznane cechy, czsto nowe funkcje. W kocu jednak
przetestuje si wikszo funkcji, ilo znajdowanych bdw zacznie
male. Wtedy kto albo harmonogram zadecyduje e produkt jest ju
gotowy.
Metod prb i bdw kady chyba napotka w czasie kariery testera. Jest
niezym wprowadzeniem do wytwarzania oprogramownaia i pomoe
zrozumie inne, bardziej formalne metody.
Metoda kaskadowa
Studenci programowania ucz si najpierw metody kaskadowej. Istniaa
zawsze. Jest prosta, elegancka i rozsdna. Funkcjonuje dobrze we
waciwym projekcie. Rysunek 2.6 pokazuje fazy tej metody.
Rysunek 2.6 W modelu kaskadowym proces wytwrczy przepywa z jednej

fazy do drugiej.
Projekt stosujcy metod kaskadow przechodzi przez szereg faz,
poczwszy od pomysu a do kocowego produktu. Na kocu kadej fazy
zesp dokonuje przegldu aby zadecydowa, czy jest si gotowym do
przejcia do nastpnej fazy. Jeli nie, projekt pozostaje w tej samej fazie
dopki nie osignie wymaganej gotowoci.
Zwrmy uwag na trzy istotne cechy metody kaskadowej:
47. Duy nacisk kadzie si na specyfikacj
produktu. Kodowanie jest tylko jedn z kilku
faz!
48. Fazy s oddzielne i nie zazbiaj si.
49. Nie ma molliwoci powrotu. Kiedy osigno
si jedn faz, pozostaje si w niej a do skutku
bez moliwoci cofnicia si do wczeniejszej
fazy.1
Odmiany modelu kaskadowego rozluniaj nieco te wymogi, zezwalajc na pewne zazbianie si faz
i moliwo cofnicia si do poprzedniej fazy w razie koniecznoci (przyp. autora).
Te ograniczenia mog wydawa si i s bardzo krpujce, ale

funkcjonuj dobrze w projektach z dobrze zdefiniowanym produktem i ze
zdyscyplinowanym personelem. Chodzi o to, by okreli wszystkie
niewiadome i ustali wszystkie szczegy zanim zostanie napisana pierwsza
linijka kodu. Wad takiego podejcia jest to, e we wspczesnej szybko
zmieniajcej si cywilizacji, gdzie produkty wytwarza si w czasie
Internetowym, pierwotna koncepcja produktu czsto musi zosta zmieniona
zanim dokadnie przemyli si j i zdefiniuje w szczegach.
Z punktu widzenia testowania, model kaskadowy jest znacznym postpem w
porwaniu z modelami opisanymi wczeniej. Wszystko specyfikuje si
starannie i dokadnie. Kady szczeg zostaje przemylany i zapisany zanim
oprogramowanie dotrze do zespou testujcego1. Na tej podstawie zesp
moe sporzdzi precyzyjny plan i harmonogram. Wie si dokadnie, co si
testuje i nie ma wtpliwoci, czy co jest funkcj - czy bdem.
Obok zalet ma ta sytuacja take spore wady. Poniewa testowanie pojawia
si dopiero w kocowej fazie projektu, zasadnicze problemy mog nie
zosta odkryte a do ostatniej chwili przed zaplanowanym wypuszczeniem
produktu. Pamitamy z rozdziau 1-ego Test oprogramowania - to, jak
dramatycznie wzrasta koszt usunicia bdu w miar posuwania si projektu
do przodu? Potrzebny jest wobec tego model, ktry przewiduje wczeniejsze
testowanie, zanim stanie si ono zbyt kosztowne.
Metoda spiralna
Cho nie jest utopi, model spiralny (rysunek 2.7) rzeczywicie rozwizuje
wiele spord problemw, z ktrymi borykaj si inne metody, a przy okazji
dostarcza kilku eleganckich rozwiza2.
W tym miejscu autor zdaje si utosamia testowanie z testowaniem systemu, ktre robi si dopiero
po napisaniu kodu. Zwrmy jednak uwag, e test moe (i powiniem) pojawi si ju we
wczenijeszych fazach procesu wytwarzania co zreszt autor mwi wyranie w innych miejscach
ksiki (przyp. tumacza).
2
Pomija si tu inne modele, ktre cho prostsze ni model spiralny take unikaj wielu wad
modelu kaskadowego. Chodzi tu o model V i model W oraz bardzo dzi popularne metodyki
przyrostowe. Dane na ich temat mona znale w licie literatury (przyp. tumacza).
Rysunek 2.7 Model spiralny zaczyna w maej skali i stopniowo si poszerza,

gdy projekt staje si lepiej zdefiniowany i stabilnijeszy.
Model spiralny zosta zaproponowany przez Barryègo Boehma w 1986
roku i opisany w jego referacie Model spiralny wytwarzania i ulepszania
oprogramowania. Stosuje si go wzgldnie czsto i udowodniono, e jest
efektywnym sposobem podejcia do wytwarzania oprogramowania.
Model spiralny upiera si na zasadzie, e nie wszystkie szczegy musz by
dopite na samym pocztku. Naley zacz w maej skali, okreli
najwaniejsze funkcje, wyprbowa je, otrzyma informacje zwrotn od
klientw, potem mona przenie si na kolejny poziom. Powtarza si to,
dopki nie otrzyma si kocowego produktu.
Kade okrenie spirali obejmuje sze faz:
1.Okrelenie celw, alternatyw i ogranicze
2. Identyfikacja i zapobieganie ryzyku
3. Ocena rozwiza alternatywnych
4. Wytworzenie i przetestowanie aktualnego
poziomu.
5. Planowanie nastpnego poziomu.
6. Definicja metodyki testowania w nastpnym
poziomie
W modelu spiralnym znajduje si fragmenty modelu kaskadowego (fazy
analizy, projektowania, kodowania i testu), nieco modelu prb i bdw
(kade nowe okrenie spirali) i troch modelu skokowego (kiedy spojrze
na cao od zewntrz). Poczywszy to ze zmniejszonymi kosztami
naprawy wczeniej znalezionych bdw, otrzymujemy cakim niez
metod wytwarzania oprogramowania.
Testerzy lubi ten model, ktry pozwala im wywrze wpyw na produkt ju
we wczesnych fazach. Widzi si, skd projekt si wzi i dokd poda. Na
samym kocu projektu nie ma si uczucia, e jest si zmuszonym do
testowania na ostatni chwil. Test by przecie wykonywany przez cay
czas, tak sic ostatni etap powiniem tylko potwierdzi, e wszystko nadal
jest w porzdku.
Podsumowanie
Na tym etapie rozumiemy ju, w jaki sposb powstaje oprogramowanie co

si na nie skada i jak czy si te elementy w cao. Nie ma jednego,
jedynie susznego sposobu. Pokazane tutej cztery rne modele to tylko
przykady. Istnieje wiele innych modeli i rne ich odmiany. Kade
przedsibiorstwo, kady projekt i kady zesp wybierze to, co najbardziej
mu odpowiada. Czasem wybr bdzie trafny, czasem bdny. Zadaniem
testera jest poradzi sobie jak najlepiej w tym modelu, w ktrym przyszo
mu dziaa1, stosujc umiejtnoci nabyte z tej ksiki tak, aby przyczyni
si do zbudowania oprogramowania o jak najwyszej jakoci.
Pytania
Pytania s po to, aby lepiej zrozumie przeczytany materia. W Dodatku A
Odpowiedzi na pytania kontrolne, znajduj si rozwizania, ktre warto
przeczyta ale nie ciga!
1.Wymie klika czynnoci, ktre powinno si wykona zanim programici
zaczn pisa pierwsze linijki kodu programu.
2.Jakie s ze strony formalnej, zamknitej specyfikacji wymaga?
3.Jaka jest najlpesza cecha modelu skokowego wytwarzania
oprogramowania?
4.Skd wiadomo przy uyciu metody prb i bdw kiedy
oprogramowanie jest gotowe do wypuszczenia?
5.Czemu model kaskadowy moe by niewygodny?
6.Dlaczego testerzy czsto wol model spiralny od innych?
Mona si tu z autorem nie zgodzi zadaniem specjalisty od testowania powinna by rwnie ocena
i poprawa jakoci procesu, w ktrym wytwarzanie si odbywa, a nie tylko bierne testowanie programu
i robienie dobrej miny do zej gry (przyp. tumacza).
Rozdzia 3
Test oprogramowania w rzeczywistoci
W TYM ROZDZIALE
Aksjomaty testowania
Terminologia i definicje w testowaniu oprogramowania
W rozdziaach pierwszym i drugim zapoznalimy si z podstawami
testowania oprogramowania i z procesami wytwarzania oprogramowania.
Podane tam wiadomoci miay charakter przegldowy i zapewne nieco
idealistyczny jak mgby by prowadzony projekt wytwarzania
oprogramowania. Niestety, w rzeczywistym wiecie nigdy pewnie nie spotka
si projektu, ktry bezbdnie spenia wymogi np. spiralnego modlu
wytwarzania. Nigdy nie dostanie si w peni szczegowej specyfikacji
wymaga, ktra bezbdnie opisuje wszystkie faktyczne potrzeby klienta. To
si po prostu nie zdarza. Skuteczny tester powinien jednak rozumie
wymogi procesu idealnego, aby mc dy w tym kierunku.
Celem tego rozdziau jest pohamowa idealizm porcj realizmu podanego z
punktu widzenia testera oprogramowania. Pomoe to zrozumie, e w
praktyce niezbdne s rne ograniczenia i ustpstwa w caym cyklu
wytwarzania oprogramowania. Wiele z nich dotyczy wanie testowania
oprogramowania. Znajdowane bdy i problemy, ktrym si zapobiega,
wywieraj na projekt znaczny wpyw. Po przeczytaniu tego rozdziau
bdziemy dokadniej rozumie role, wpywy i odpowiedzialno testowania
i bdzie nam atwiej zaakceptowa zakulisowe decyzje, ktre musz by
podejmowane, aby produkt mg powsta.
Gwne punkty tego rozdziau to:
50. Czemu oprogramowanie nigdy nie jest
doskonae
51. Czemu test oprogramowania to nie jest tylko
techniczne zagadnienie
52. Terminologia powszechnie uywana przez
testerw
Aksjomaty testowania
Pierwsza cz tego rozdziau jest list aksjomatw, czyli oczywistoci.
Naley je potraktowa jako kodeks testowania albo porady yciowe
obowizujce w wytwarzaniu i testowaniu oprogramowania. Kada z tych
zasad to fragment wiedzy, pozwaljcy dostrzec jaki aspekt caoci we
waciwym wietle.
Programu nie da si przetestowa cakowicie
Nieopierzony tester moe sobie wyobraa, e da si wzi program do rki,

przetestowa go w peni, znale wszystkie bdy i zagwarantowa, e
program po korektach - jest doskonay. Niestety, to jest zupenie
niemoliwe, nawet dla zupenie prostych programw, z czterech
podstawowcyh przyczyn:
53. Ilo moliwych danych wejciowych jest
ogromna
54. Ilo moliwych danych wyjciowych jest
ogromna
55. Ilo moliwych cieek prowadzcych przez
program jest ogromna
56. Specyfikacja wymaga jest subiektywna1:
mona powiedzie, e o bdzie decyduje
obserwator, nie autor.
Przemnoywzy przez siebie te cztery ogromne liczby moliwoci,
otrzymuje si ilo moliwych warunkw testowych ktra jest zbyt wielka,
by mc si z ni zmierzy. Jeli trudno w to uwierzy, przyjrzyjmy si
przykadowi pokazanemu na rysunku 3.1, Kalkulatorowi MS Windows.
Rysunek 3.1 Nawet prosty program, jak Kalkulator w Windowsach, jest zbyt
zoony by mc go w caoci przetestowa.
Przyjmijmy, e otrzymalimy zadanie przetestowa Kalkulator
Windowsw. Postanawiamy zacz od dodawania. Prbujemy 1+0=.
Otrzymujemy wynik 1, poprawny. Potem prbujemy 1+1=. Otrzymujemy 2.
Ile jeszcze prb powinno si wykona? Kalkulator przyjmuje liczby 32cyfrowe, wic trzeba wyprbowa wszystkie moliwoi a do
1+99999999999999999999999999999999=
Wyczerpawszy ten cig, moemy przystpi do 2+0=, 2+1=, 2+2= i tak
dalej. W kocu wreszcie dojdziemy do
Naley tutaj doda, e w ogle definicje jakoci s subiektywne i rzadko kiedy mierzlane (przyp.
tumacza).
99999999999999999999999999999999+9999999999999999999999999999
9999=
Nastpnie trzeba si zabra za wszystkie zmienne z jednym miejscem
dziesitnym: 1.0+0.1, 1.0+0.2 i tak dalej.
Sprawdziwszy e zwyke liczby dodawane s poprawnie, naley
wyprbowac wszystkie niedozwolone dane wejciowe, aby upewni si, czy
program waciwie z nimi sobie radzi. Nie musi si klika na cyfry na
ekranie, mona wprowadza przecie dane do programu rwnie przy
pomocy klawiatury komputera. Mona zacz na przykad od 1+a, z+1,
1a1+2b2 Takich kombinacji s miliardy miliardw.
Trzeba te przetestowa dane wejciowe, ktre zostay edytowane.
Kalkulator Winows pozwala na uycie klawisza cofnicia kursora i klawisza
kasujcego, wic trzba je wyprbowa. 1<cofnicie>2+2 powinno da
wynik rwny 4. Wszystko, co zostao dotd przetestowane, trzeba
przetestowa ponownie, tyle e dodatkowo naciskajc klawisz cofnicia dla
kadego znaku, dla kadej pary znakw i tak dalej.
Jeli tester - lub jego spadkobiercy zdoaj wykona wszytkie ta zadania
testowe, mozna bdzie wtedy przystpi do dodawania trzech liczb, potem
czterech liczb
Jest tak wiele moliwych kombinacji danych wejciowych, e nigdy nie
daoby si ich wyczerpa, nawet jeliby stosowa superkomputery do
wprowadzania ich do Kalkulatora. A to dopiero pocztek, dodawanie.
Pozostao jeszcze odejmowanie, mnoenie, dzielenie, pierwiastki drugiego
stopnia, procenty i odwrotnoci.
Ten przykad mia pokaza i uzmysowi, e niewykonalne jest cakowite
przetestowanie programu, nawet tak prostego jak kalkulator. Rezygnujc z
ktregokolwiek zadania testowego, poniewa wydaje si nadmiarowe albo
zbdne, czy te po prostu dla zaoszczdzeniua czasu, rezygnujemy z
tesstowania cakowitego.
Testowanie oprogramowania jest ryzykowne
Decyzja, e nie kady z olbrzymej iloci moliwych scenariuszy testowych
bdzie wykonany, oznacza podjcie ryzyka. W przykadzie z kalkulatorem,
co bdzie jeli nie przetestuje si 1024+1024=2048? Nie mona z gry
wykluczy, e z jakiego powodu programista popeni bd, ktry ujawni
si dla tego wanie zestawu wartoci. Jeli tego nie przetestowa,
uytkownik kocowy i tak na pewno wykona to dziaanie i bd si ujawni.
Bdzie to kosztowny bd, jeli odkry go dopiero wtedy, gdy program jest
ju w rkach klienta.
Wszystko to razem brzmi gronie. Nie da si przetestowa wszysktigo, ale

jeli nie przetestouje si wszystkiego, prawdopodobnie przeoczy si jakie
bdy. Produkt trzeba wypuci, wic trzeba go w ktrym momencie
przesta testowa, ale jeli przesta zbyt wczenie, pozostawi si
nieprzetestowane funkcje. Co robi?
Podstawow umiejtnoci, ktr musz opanowa testerzy, to zmniejszenie
olbrzymigo zbioru moliwych zada testowych do zbioru dajcego si
wykorzysta w rzeczywistoci, co oznacza podejmowanie w mdry sposb
ryzykownych decyzji, co trzeba przetestowa, a co mona pomin.
Rysunek 3.2 ilustruje zwizek midzy iloci wykonanych testw a iloci
odkrytych bdw. Jeli prbowa przetestowa wszystko, koszty wzrastaja
dramatycznie, a ilo przeoczonych bdw pozostaych w programie malaje
w kocu tak, e dalsze testowanie przestaje si opaca. Jeli testuje si zbyt
krtko albo podejmuje bdne decyzje co do zakresu testw, koszty bd
niskie, ale wiele bdw nie zostanie odkrytych. Chodzi o to, by utrafi w
optymalny punkt: testowa ani nie za duo, ani nie za mao.
Rysunek 3.2 W kadym projekcie ustnieje jaki optymalny poziom iloci

testw.
W rozdziaach 4 7 nauczymy si, jak konstruowa i wybiera zadania
testowe tak, eby zminimalizowa ryzyko i zoptymizowa poziom
testowania.
Test nie jest w stanie udowodni braku bdw
Warto zastanowic si nad tym przez chwil. Osoba walczca ze szkodnikami
ma za zadanie skontrolowa dom, czy nie ma w nim robactwa. Przeszukuje
si dom i znajduje ywe owady, martwe owady, gniazda. Nie ma
wtpliwoci, e w domu jest robactwo.
W innym domu nie znajduje si adnych ladw istnienia owadw. Szukajc

w typowych miejscach nie znajdujemy adnych typowych symptomw.
Moe znalazo si kilka martwych owadw i kilka gniazd, ale nic nie
wskazuje na istnienie ywych owadw. Czy mona powiedzie z zupen,
absolutna pewnoci, e w domu nie ma adnego robactwa? Nie. Jedyne co
moemy stwierdzi, to e w wyniku poszukiwa nie udao si znale
adnych ywych owadw. Jei nie chce si rozmontowa caego domu na
kawaeczki a do piwnic, zawsze istniej moiwo, e po prostu przeoczyo
si gdzie dobrze ukryte owady.
Praca testera oprogramowania jest podobna. Mona pokaza znalezione
bdy, ale nie da si udowodni, e adnych bdw na pewno nigdzie nie
ma. Mona wykona wszystkie zaplanowane testy, znale bdy i napisa
na ich temat raporty, ale nigdy, w adnym momencie nie jest si w stanie
zagwarantowa, e nie ma ju wicej adnych ukrytych bdw. Jedyne co
mona zrobi to testowa dalej i by moe znale jeszcze klika sztuk.
Im wicej bdw si znalazo, tym wicej bdw pozostaje
Istniej liczne podobiestwa midzy prawdziwymi owadami a bdami
pluskwami- w oprogramowaniu. Jedne i drugie chtnie pojawiaj si w
grupach. Jeli zobaczyo si jednego, to zapewne inne znajduj si w
pobliu.
Czsto tesuje si przez dugi czas bez skutku. Potem znajduje si jaki bd,
i zaraz potem kolejne. Jest kilka przyczyzn tego stanu rzeczy:
57. Programici miewaj gorsze dni. Jak
wszystkim, programistom te zdarzaj si
kiepskie dni. Kod napisany jednego dnia moe
by wietny, a innego dnia niestaranny. Jeden
bd czsto bywa znakiem, e w pobliu s inne
bdy.
58. Programici czsto powtarzaj ten sam bd.
Kady ma swoje zwyczaje. Programista skonny
do pewnego typy pomyek czsto je powtarza.
59. Niektre bdy to tylko czubek gry lodowej.
Czsto architektura opogramowania jest z
gruntu wadliwa. Tester znajduje kilka bdw,
na pierwszy rzut oka pozbawionych zwizku, a
w kocu znajduje si ich wspln, gbsz
przyczyn.
Warto zauway e zasada odwrotna do opisanej tu bdy wystpuj
stadami jest take prawdziwa. Jeli nie znajduje si adnych bdw mimo
usilnych stara, to by moe program jest po prostu czysto napisany i
rzeczywicie nie ma w nim wielu bdw do znalezienia.
Paradoks pestycydw
W 1990 roku Boris Beizer uy w swojej ksice Techniki Testowania

Oprogramowania1 okrelenia paradoks pestycydw na zjawisko swoistego
uodparniania si oprogramowania na testy. To samo dzieje si z owadami i
rodkami owadobjczymi (rysunek 3.3). Jeli wci stosowa ten sam
rodek, owady uodparniaj si na niego - i przestaje dziaa.
Rysunek 3.3 Program, poddawany wci tym samym testom, w kocu staje
si na nie odporny.
Przypomnijmy sobie spiralny model wytwarzania opisany w rozdziale 2-im.
Proces testowy powtarza si za kad ptl spirali. Przy kadej nowej
iteracji, tester otrzumuje oprogramowanie do przetestowania. W kocu, po
kilku obrotach, wszystkie bdy ktre te testy mog odkry zostaj odkryte i
powtarzanie ich staje si bezuyteczne2.
Przezwycienie paradoksu pestycydw wymaga znajdowania wci
nowych zada testowych, ktre skontroluj nowe czci programu i
zapewne odnajd nowe, dotd ukryte bdy.
Nie wszystkie znalezione bdy zostan naprawione
Jednym z przykrych realiw testowania jest to, e po caej cikiej pracy
testrw, nie kady przez nich znaleziony bd zostanie rzeczywicie
skorygowany. Nie czujmy si zanadto rozczarowani to nie oznacza
jeszcze, e nie zdoalimy osign celu testowania, ani e produkt
wypuszczony przez nasz projekt bdzie marnej jakoci. Oznacza to jednak,
e trzeba bdzie si odwoa do listy podanych cech testera z rozdziau
pierwszego wykaza rozsdek i wiedzie, kiedy denie za wszelk cene
do doskonaoci nie jest do osignicia. Tester i jego zesp musi niekiedy
zgodzi si na kompromisy, na podjcie szeregu ryzykownych decyzji, ktre
bdy musz by naprawione, a ktre mona pozostawi3.
1
Software Testing Techniques, drugie wydanie.
Mona, a nawet naley stosowa je nadal w ramach testowania regresywnego, ale nie oczekuje si
wwczas odkrycia nowych bdw (przyp. tumacza).
3
Ta decyzja nie powinna nalee do zespou testujcego ani do programistw, tylko do kierownictwa
projektu lub produktu (przyp. tumacza).
Istnieje kilka powodw, dla ktrych mona si zdecydowa nie naprawiac

bdu:
60. Nie ma do czasu. W kadym projekcie jest
zawsze zbyt wiele funkcji, a zbyt mao osb
ktre je mog zaprogramowa i przetestowa,
oraz za mao czasu w harmonogramie. Jei
pracuje si nad programem przygotowujcym
dekleracj podatkow, data kiedy deklaracja ma
by gotowa nie ulegnie zmianie po prostu
program musi by gotowy na czas.
61. To tak naprawde nie jest bd. Syszy si
niekiedy zwrot to nie bd, to funkcja! Czsto
zdarza si, e nieporozumienia, pomyki w
testowaniu oraz zmiany specyfikacji (o ktrych
nie wszyscy s powiadomieni) powoduj, e
potencjalne bdy zaklasyfikowane s jako
normalne funkcje.
62. Zbyt wielkie ryzyko prby naprawy. Niestety,
to si czsto zdarza. Oprogramowanie jest
delikatne, pene wzajemnych zalenoci i czsto
przypomina sw struktur spltany talerz
makaronu. Mona wtedy, naprawiwszy jeden
bd, spowodowa zmiany, w wyniku ktrych na
wiato dzienne wyjd inne bdy wczeniej
ukryte. Pod naciskiem wymaga
harmonogramu, niektre zmiany mog by zbyt
ryzykowne. Uznaje si wwczas niekeidy, e
pozostawienie ju znanego bedu jest mniejszym
zem ni ryzyko pojawienia si nowych,
nieznanych bdw.
63. Po prostu nie warto. To moe zabrzmie zbyt
ostro, ale taka bywa prawda. Bdy ktre
pojawiaj si rzadko albo w rzadko uywanych
funkcjach mona uzna za nieistotne. Bdy
ktre mona omija, gdzie istniej dostpne
uytkownikowi sposoby na uniknicie skutkw
bdu, niekiedy wiadomie si pozostawia.
Wszystko to sprowadza si do ryzykownej
decyzji handlowej.
W procesie podejmowania decyzji zwykle uczestnicz testerzy, kierownicy
projektu i programici. Kada z tych grup ma inny punkt widzenia na
znalezione bdy i rne pogldy na to, czy naley je skorygowa. W
rozdziale 18-ym, Raportowanie, mona si dowiedzie wicej na temat
raportw bdw i o tym, jak tester moe odgrywa istotniejsz rol w
procesie decyzyjnym.
Co bdzie, jeli podejmie si z decyzj?
Przypomnijmy sobie opisany w rozdziale 1-ym bd procesora Pentium.

Testerzy Intela znaleli bd przed wypuszczeniem procesora na rynek,
ale zesp odpowiedzialny za produkt zadecydowa, e taki may,
nieistotny bd nie musi by poprawiony. Harmonogram by napity i
zdecydowano, by zdy na najbliszy termin, a bd naprawi w
kolejnych wersjach procesora. Niestety, klienci odkryli istnienie bdu, a
reszta jak si to mwi jest histori.
Trudno powiedzie kiedy bd jest bdem
Jeli w oprogramowaniu jest bd, ale nikt go nigdy nie odkryje ani
programici, ani testerzy, ani jeden klient czy to jest bd?
Jeli zgromadzi grup testerw i zada im to pytanie, sprowokuje si
oywion dyskusj. Bdzie kilka rnych opinii i kady bdzie zawzicie
broni swego zdania. Problem w tym, e jednoznaczna odpowied nie
istnieje, lecz zaley od tego, jakie s cele i wymagania danego zespou
projektowego.
Przypomnijmy sobie definicj bdu podan w rozdziale 1-ym:
1.Oprogramowanie nie wykonuje czego, co wedle specyfikacji powinno
wykonywa.
specyfikacji nie powinno robi.
powinna.
5. Oprogramowanie jest trudne do zrozumienia,
trudne do uytkowania, powolne albo zdaniem
testera bdzie w oczach uytkownika po
prostu nieprawidowe.
Ta definicja rozstrzyga dylemat niewidocznego bdu, wymagajc by
skutki bdu byy obserwowalne. Nie daje si napisa raportu bdu o
czym, co nie daje si dostrzec, dlatego nie nona mwi o istnieniu bdu,
jeli nie daje si go zauway.
Mozna te spojrze na to z innej strony. Zdarza si, e dwie osoby maj
dramatycznie rne opinie na temat jakoci tego samego produktu. Jedna
okrela produkt jako rojcy si od bdw, za druga uwaa, e produkt jest
doskonay. W jaki sposb obie osoby mog mie racj? Moe tak si sta
wwczas, gdy jedna z nich uywaa programu w sposb, ktry powodowa
duo bdw. Druga za nie.
W tej ksice mianem bdu bedzie si okrela tylko obserwowalne

bdy. Bdy, ktrych jeszcze nie znaleziono, to po prostu nieodkryte
bdy.
Jeli to niezbyt jasne, nie naley wpada w rozpacz. Warto podyskutowa z
innymi testerami, posucha ich zdania, sprawdzi co myl i stworzy
swoj wasn definicj. Warto pamita o starym pytaniu: Czy jeli drzewo
przewraca si w lesie, gdzie nikt jego upadku nie syszy, czy wydaje jaki
dwik?
Specyfikacje produktu nigdy nie s gotowe
Producenci oprogramowania maj kopot. Ta dziedzina rozwija si tak
szybko, e to, co rok wczeniej byo super-nowoci, w tym roku moe by
przestarzae. Jednoczenie oprogramowanine robi si coraz wiksze i
bardziej skomplikowane, przez co projekty trwaja coraz duej i duej. Te
dwie przeciwstawne tendencje powoduj, e w trakcie projektu specyfikacja
wymaga wielokrotnie si zmienia. Nie ma innego sposobu, eby nada
za szybkimi zmianami. Wyobramy sobie, e wytwarzany produkt oparty
jest na zamknitej, nienaruszalnej specyfikacji. W poowie projektu okazuje
si, e gwny konkurent wanie wypuszcza na rynek bardzo podobny
produkt, ale majcy kilka poytecznych funkcji, ktre w naszym produkcie
nie byy planowane. Czy w tej sytuacji naley kontynuowa wedug
niezmienionej specyfikacji i wypuci po roku produkt gorszy od
konkurencji? Czy te naley wzi si za ponowne planowanie, zmieni
specyfikacj i pracowa dalej nad zmienion wersj produktu? W
wikszoci wypadkw, mdry biznesmen wybierze drugie rozwizanie.
Bdc testerem trzeba liczy si z tym, e specyfikacje ulegn zmianie.
Zostan dodane funkcje ktrcyh nie planowao si testowa, inne funkcje
nawet te ju przetestowane mog zosta zmienione albo usunite w ogle.
Tak bdzie na pewno dlatego niniejsza ksika uczy, jak elastycznie
planowa i wykonywa testy.
Testerzy nie s najbardziej lubiani w zespole projektowym
Przypomnijmy sobie cel dziaania testera oprogramowania:
Celem testera oprogramowania jest znajdowanie bdw.
Praca testera polega wic na krytykowaniu wynikw pracy kolegw,
znajdowaniu w nich problemw, a w kocu ogaszaniu tego, co si znalazo.
Uch taka praca zwykle nie zapewnia sympatii i popularnoci.
Oto kilka rad, jak zachowa dobre ukady z kolegami w zespole:
64. Znajdowa bdy jak najwczeniej. Warto na

to postawi. Znajdujc bd trzy miesice a nie
jeden dzie przed planowanym wypuszczeniem
na rynek, narobi si znacznie mniej zamieszania
i bdzie si bardziej lubianym.
65. Powciga wybuchy entuzjazmu. Zgoda, to
wspaniaa praca i ogrania nas radosne
podniecenie, kiedy znajdujemy naprawd
okropny bd. Nie sprawi si jednak
programicie przyjemnoci, wpadajc do jego
pokoju z radosnym umiechem i oznajmiajc, e
wanie znalazo si w jego czy jej kodzie
najokropniejszy bd w caej swojej karierze.
66. Take dobre wieci warto rozgasza. Jeli
znalazo si fragment kodu zachwycajco
bezbdny, warto to take nagoni. Warto
czasem po prostu pogada o niczym z
programistami i konstruktorami. Przynoszc
zawsze tylko ze wiadomoci, ryzykujemy, e
inni zaczn nas unika.
Test oprogramowania to cisy zawd techniczny
Dawniej testowanie oprogramowania nie byo oczywistoci. Programy byy
mae i niezbyt skomplikowane, ilo uytkownikw komputerw
ograniczona. Kilku programistw w zespole mogo na zmian testowa
sobie nawzajem swj kod. Bdy zwykle nie byy grone. Znalezione bdy
poprawiao si atwo bez wielkich kosztw. Testerzy, jeli ju ich uywano,
byli czsto sabo wykwalifikowani i zatrudnieni w projekcie w ostatniej
chwili, eby postukali troch na olep w program i sprbowali co
znale. Czasy si zmieniy.
Wystarczy popatrze na ogoszenia o pracy, by znale liczne ogoszenia
poszukujce testerw oprogramowania1. Przemys oprogramowania dojrza
ju do tego stopnia, e zatrudnianie profesjonalnych testerw stao si w
wielu projektach obowizkowe. Budowanie wadliwego oprogramowania
kosztuje dzi zbyt wiele.
Nie wszystkie przedsibiorstwa osigny ju ten poziom dojrzaoci. Wielu
producentw gier komputerowych i innych niewielkich programw nadal
hoduje zasadom do swobodnego podejcia do procesu wytwrczego
zwykle poprzestajc na metodzie skokowej albo prb i bdw. Jednak coraz
wicej oprogramowania wytwarza si zdyscyplinowanymi metodami, gdzie
specjalici od testowania i testerzy s naturaln czci zespou
projektowego.
1
Realia amerykaskie. W Europie zachodniej takich ogosze jest mniej, w Polsce jeszcze mniej.
Kiedy ju s, wzgldnie rzadko poszukuje si specjalisty od testowania, czciej specjalisty od testu
i integracji lub owcy problemw. Niemniej, tendencja wzrostowa jest wyrania wszdzie.
Dla osb zajmujcych si testowaniem to dobra wiadomo. Testownie

moe ju by drog kariery specjalizacj wymagajca umiejtnoci i
dyscypliny, pozwalajc na wspinaczk po szczeblach kariery2.
Terminologia i definicje w testowaniu oprogramowania

Niniejszy rozdzia zamyka pierwsz cz ksiki list paru podstawowych
terminw i definicji. Terminologia dotyczy podstawowych poj w
dziedzinie wytwarzania i testowania oprogramowania. Wiele z nich jest
czsto uywa si bdnie, dlatego zostay tutaj poczone w pary, aby
uatwi ich prawidowe zrozumienie.
Precyzja a trafno
Tester powinien waciwie rozumie rnic midzy precyzj a trafnoci.
Wemy dla przykadu pod rozwag testowanie kalkulatora. Czy odpowiedzi
podane przez kalkulator powinny by precyzyjne (np. z du iloci miejsc
po przecinku), czy trafne (w pobliu prawidowej wartoi)? Czy te jedno i
drugie? Jeli harmonogram projektu wymusza podjcie ryzykownej decyzji,
czy wybra raczej trafno, czy precyzj?
Jeli testuje si gr, tak jak symulator lotu albo gry w pik non, czy
powinno si testowa raczej trafno, czy precyzj?
Rysunek 3.4 ilustruje graficznie rnic midzy tymi dwoma pojciami. W
strzelaniu do celu chodzi o to, by trafi w sam rodek tarczy. Strzay na
lewym grnym rysunku nie s ani precyzyjne, ani trafne (celne). S z dala
jeden od drugiego i z dala od rodka tarczy.
Tarcza na grze po prawej stronie pokazuje strzay umieszczone
precyzyjnie, ale nietrafnie (niecelnie). S blisko siebie, ale z dala od rodka
tarczy nawet nie trafiy w tarcz.
O ile czciej jednak na stanowiskach kierowniczych nadal spotyka si programistw lub

inynierw, ktrzy przekroczyli prg swojej niekompetencji, ni specjalistw od testowania, ktrych
umiejtno krytycznego mylenia i podejmowania decyzji w sytuacji ryzyka doczekaa si uznania
zarzdu firmy
Rysunek 3.4 Rozkad strzaw w tarczy ilustruje rni midzy precyzj a

trafnoci (celnoci)
Tarcza po lewej na dole jest przykadem celnoci, ale sabej precyzji. Strzay
s blisko rodka, wic do celne, ale z dala jeden od drugiego, wic niezbyt
precyzyjne.
Tarcza na dole po prawej stronie to poaczenie celnoci (trafnoci) i
dokadnoci (precyzji). Strzay s blisko siebie, w centrum tarczy.
Czy od programu naley wymaga precyzji, czy te trafnoci, zley od jego
funkcji. Kalkulator powinien by zapewne i trafny, i precyzyjny. Mona
jednak wymaga, by odpowiedzi kalkulatora byy precyzyjne tylko do
pitego miejsca po przecinku potem ju nie. O ile testerzy znaja to
ograniczenie, mog dopasowa do niego swoje testy.
Weryfikacja i walidacja
Nazwy weryfikacja i walidacja czsto stosowane s zamiennie, ale maj
naprawd odmienne znaczenia. Ta rnica jest wana w testowaniu
oprogramowania.
Weryfikacja to potwierdzenie e co oprogramowanie spenia wymogi
swojej specyfikacji. Walidacja to potwierdzenie, e oprogramowanie spenia
wymagania uytkownika. Jedno i drugie moe wydawa si bardzo
podobne, ale przykad z teleskopem Hubbleà pomoe zilustrowa rnic.
W kwietniu 1990 roku, teleskop Hubbleà zosta umieszczony na orbicie
okooziemskiej. Jest to teleskop zwierciadlany, czyli uywa wielkeigo,
wklsego lustra zamist soczewki. Zbudowanie teleskopu byo olbrzymim
przedsiwziciem, wymagajcym wielkiej precyzji i trafnoci. Testowanie
teleskopu byo bardzo trudne, bo skonstruowano go do uytku w przestrzeni
kosmicznej i na Ziemi nie dao si go nawet ustawi. Dlatego jedynym
sposobem testowania byy staranne pomiary i porwnanie ich wynikw ze
specyfikacjami. Po zakoczeniu tych testw ogoszono, e teleskop by
gotw do wysania na orbit.
Niestety, wkrtce po rozpoczciu dziaania teleskopu okazao si, e obrazy
ktre produkowa byy nieostre. Dochodzenie odkryo, e zwierciado byo
le wykonane. Wprawdzie wykonanie byo zgodne ze specyfikacj, ale
specyfikacja bya bdna. Testowanie potwierdzio, e wykonanie speniao
wymagania specyfikacji weryfikacja ale nie potwierdzio e spenia
wymogi pierwotnych wymaga walidacja.
W 1993 roku misja promu kosmicznego skorygowaa bdne zwierciado
instalujc soczewk korekcyjn, poprawiajc ostro.
Chocia opisany przykad nie dotyczy produkcji oprogramowania, pojcia

weryfikcaji i walidacji s w niej kluczowe. Nigdy nie mona zakada. e
specyfikacja na pewno jest poprawna. Jeli zweryfikowa specyfikacj i
dodatkowo podda walidacji kocowy produkt, uniknie si takich
problemw, jakie dotkny konstruktorw teleskopu Hubbleà.
Jako i niezawodno
Jako defniowana jest niekiedy jako stopie doskonaoci. Jeli
oprogramowanie jest wysokiej jakoci, zaspokoi potrzeby klienta. Klient
odniesie wraenie, e dany produkt zaspokaja jego potrzeby, w dodatku
lepiej ni produkty konkurencyjne.
Testerzy oprogramowania czsto popeniaj bd utosamiajc jako i
niezawodno. Maj poczucie, e testujc program a stanie si stabilny i
niezawodny, przyczyniaj si do stworzenia produktu wysokiej jakoci.
Niestety, nie zawsze jest to prawd. Niezawodno to tylko jeden z
aspektw jakoci1.
Wyobraenie uytkownika, czym jest jako, skada si z caego szeregu
cech: moliwo egzekwowania programu na starym modelu PC,
dostpno obsugi telefonicznej u dostawcy, a nawet kolor opakowania.
Niezawodno i to, co program robi z danymi s zwykle wane, ale nie
zawsze.
Aby upewni si, e program jest wysokiej jakoci i niezawodny, tester musi
przeprowadza weryfikacje i walidacj przez cay okres wytwarzania
produktu.
Test i zapewnienie jakoci (QA)
Ostatnia para definicji to testowanie i zapewnienie jakoci (czsto skracane
jako QA). Oba te tych okrelenia s czsto uywane wobec zespou
projektowego albo wobec procesu weryfikacji i walidacji oprogramowania.
W rozdziale 20-ym Zapewnienie jakoci oprogramowania ta dziedzina jest
opisana dokadniej; na razie porwnajmy dwie definicje:
67. Celem testu oprogramowania jest znajdowanie
bdw jak najwczeniej i zapewnienie, eby
zostay naprawione.
68. Celem zapewnienia jakoci jest stworzenie i
wdroenie standardw i metod w celu
udoskonalenia procesu wytwarzania i
zapobieenia powstawaniu bdw.
Uywa si te okrelenia atrybuty jakoci. Oprcz funkcjonalnoci i niezawodnoci do atrybutw

jakoci zalicza si wydajno, uyteczno, atwo testowania, konfigurowalno, atwo
konserwacji i wiele innych (przyp. tumacza).
Rzecz jasna, te dziedziny nakadaj si na siebie. Testerzy czsto wykonuj

niektre z zada specjalisty od zapewnienie jakoci, ktry z kolei czsto
wykonuje troch testowania. Obie te role s blisko ze sob zwizane. Wane
jest wiedzie co do kogo naley i zakomunikowa to reszcie zespou.
Zamieszanie i nieporozumienia w zespole dotyczce odpowiedzialnoci za
test spowodoway ju wiele kosztownych niepowodze.
Podsumowanie
Kiebasa, prawa i oprogramowanie ogldanie jak powstaj moe by
troch obrzydliwe. Miejmy nadziej, e wstpne rozdziay nikogo jednak nie
odstraszyy.
Wielu testerw trafia do projektw nie rozumiejc, co si dookoa nich
waciwie dzieje, jak podejmowane s decyzje, wedug jakich procedur
powinni dziaa. W takich warunkach nie da si dziaa skutecznie. Majc
do dyspozycji podane dotd informacje na temat testowania i procesu
wytwarzania, otrzymuje si ju na starcie przewag. Nawet jeli kto po raz
pierwszy zajmie si testowaniem, bdzie od razu rozumia swoj rol, a
przynajmniej wiedzia, jakie pytania zada, zeby zrozumie swoj funkcj w
obrazie caoci.
Odtd wszystkie zagadnienie dotyczce procesu wytwarzania bd odoone
na bok, a w nastpnym rozdziale czytelnik zapozna si z podstwaowymi
technikami testowania oprogramowania.
Pytania
Pytania s po to, aby lepiej zrozumie przeczytany materia. W Dodatku A
Odpowiedzi na pytania kontrolne, znajduj si rozwizania, ktre warto
przeczyta ale nie ciga!
1.Pamitajc, e programu nie da si przetestowa w caoci, co naley
wzi pod uwag podejmujc decyzj czy mona ju zaprzesta
testowania?
2.Uruchom Kalkulator w Windowsach. Napisz 5,000-5= (przecinek jest
istotny). Przyjrzyj si wynikowi. Czy jest to bd? Dlaczego?
3.Przy tecie gry, np. symulatora lotu albo symulatora ruchu miejskiego, co
naley przetestowa w pierwszym rzdzie trafno czy precyzj?
4.Czy mone istnie produkt informatyczny wysokiej jakoci, ale o niskiej
niezawodnoci? Jaki mona poda przykad?
5.Czemu programw nie da si przetestowa cakowicie?
6.Jeli testujc program w poniedziaek znajduje si bd co godzin, jak
czsto naley oczekiwa bdw we wtorek?
Cz II strona 1 (86)
Cz IIPodstawy testowania
Jeli szuka si tylko jednej rzeczy, to tylko t rzecz mona znale.
Stare powiedzenie poszukiwaczy zota
Najciekawsze, co mona usysze w nauce, co zwiastuje najwicej odkry, to

nie okrzyk Eureka!, lecz To dziwne
Isaac Asimov, autor ksiek naukowych i fantastyczno-naukowych
W TEJ CZCI
Badanie specyfikacji
Test z klapkami na oczach
Badanie kodu
Testowanie pod rentgenem
Wersja 9 padziernika 2001, Bogdan Bereza
Rozdzia 4
Cz II strona 2 (86)
Badanie specyfikacji
W TYM ROZDZIALE
Jak zacz
Oglny przegld specyfikacji
Techniki testowania specyfikacji
W tym rozdziale wreszcie zaczniemy uprawia prawdziwe testowanie ale
moe nie tak, jak niektrzy si spodziewaj. Nie bdzie si insatalowa ani
puszcza adnych programw, nie bdzie si wali w klawiatur z nadziej
na wywoanie awarii. W tym rozdziale nauczymy si testowania specyfikacji
tak, by mc znajdowa bdy zanim jeszcze wejd do programu.
Nie wszyscy testerzy maj kiedykolwiek przywilej testowania specyfikacji
produktu. Czasami przychodzi si do projektu w poowie drogi, kiedy
specyfikacja jest ju napisana i zaczto pisanie kodu. Nawet wtedy mona
jeszcze zastosowa opisane w tym rozdziale techniki do testowania
ostatecznej wersji specyfikacji.
Kto ma szczcie znale si w projekcie dostatecznie wczenie i mie
dostp do wstpnej wersji specyfikacji, bdzie mie okazj zastosowa wiele
opisanych w tym rozdziale technik. Znalezienie bdw w tak wczesnej
fazie projektu moe zaoszczdzi ogromn ilo czasu i pienidzy.
1. Co to s metody czarnej skrzynki i szklanej
skrzynki
2. Rnice midzy testowaniem dynamicznym i
statycznym
3. Jakie techniki s uyteczne do przegldu
specyfikacji produktu
4. Jakich typowych problemw warto szuka
przystpujc do szczegowej inspekcji
specyfikacji produktu
Od czego zacz
Przypomnijmy sobie cztery modele procesu wytwarzania opisane w
rozdziale 2-im: skokowy, prb i bdw, kaskadowy i spiralny. W kadym
modelu oprcz skokowego, zesp projektowy przygotowuje specyfikacj
produktu, zwan niekiedy specyfikacj wymaga, aby zdefiniowa co ma
by zrobione.
Cz II strona 3 (86)
Najczciej specyfikacja produktu to dokument, opisujcy przy pomocy

sw i ilustracji projektowany produkt1. Fragment specyfikacji Kalkulatora
w Windowsach mgby wyglda tak:
Pozycja menu Edytuj bdzie mie dwie funkcje: Skopiuj i Wklej.
Mona je wybiera jedn z trzech metod: wskazujc i klikajc mysz,
uywajc klawiszy dostpu (Alt-C dla funkcji Kopiuj, Alt-P dla funkcji
Wklej), lub posugujc si standardowym skrtem Windowsw Ctrl-C
dla kopiowania i Ctrl-V dla wklejania.
Funkcja Kopiuj skopiuje biec warto z okna tekstowego do
Schowka Windowsw. Funkcja Wklej wklei zawarto Schowka do
numerycznego okna tekstowego.
Rysunek 4.1 Stadardowy kalkulator Windowsw z rozwijanym menu Edytuj.

Jak wida, opis zaledwie dwch pozycji rozwijanego menu wymaga sporej
iloci sw. Szczegowa specyfikacja caej aplikacji moe mie wieleset
stron.
Moe wydawa si przesad sporzdzanie tak drobiazgowego opisu dla tak
prostego programu. Czemu nie pozwoli po prostu programicie zrobi
kalkulator po swojemu? Kopot w tym, e nie wiedziaoby si wtedy
dokadnie, co si w kocu otrzyma. Wyobraenia programisty jak kalkulator
ma wyglda, jakie ma mie funkcje i jak uytkownik bdzie si nim
posugiwa mog rni si gruntownie od oczekiwa zleceniodawcy.
Jedynym sposobem zagwarantowania, e produkt kocowy bdzie taki,
jakiego oczekuje uytkownik co pozwoli take porzdnie zaplanowa
tesotwanie jest opisanie produktu w specyfikacji wymaga.
Dodatkow zalet pisanej specyfikacji i podstaw tego rozdziau jest to,
e tester otrzymuje do dyspozycji dodatkowy przedmiot testowania. Testujc
specyfikacj mona czasem wykry bdy jeszcze zanim zostanie napisana
pierwsza linijka kodu.
Istniej te rozmaite metody opisu specyfikacji wymaga w formalnych jzykach przypominajcych

jzyk programowania wysokiego rzdu (przyp. tumacza).
Cz II strona 4 (86)
Metody czarnej skrzynki i metody szklanej skrzynki

Testerzy dziel techniki testowania na dwie due grupy, znane jako test
czarnej skrzynki i test szklanej skrzynki1. Rysunek 4.2 pokazuje rnice
midzy tymi dwoma podejciami. W testowaniu metodami czarnej skrzynki,
tester wie jedynie, co oprogramowanie ma zrobi nie zaglda do wntrza
skrzynki eby zobaczy jak to dziaa. Kiedy wprowadzi si pewne dane
wejciowe, otrzyma si pewne dane wyjciowe. Nie wiadomo czemu tak
jest, tyle tylko, e tak jest.
Wrmy do przykadu kalkulatora z rysunku 4.1 Jeli napisa 3.14159 i
nacisn klawisz sqrt (pierwiastek drugiego stopnia), otrzyma si wynik
1.7724531022341. Przy technikach czarnej skrzynki nie bierze si pod
uwag jak dziaa program aby wyliczy pierwiastek kwadratowy z pi po
prostu to wykona. Tester oprogramowania moe zweryfikowa otrzymany
wynik na innym, ju sprawdzonym kalkulatorze i skontrolowa, czy
Kalkulator Windows dziaa poprawnie.
Rysunek 4.2 Stosujc techniki czarnej skrzynki, tester nie zna szczegw
dziaania programu, ktry testuje.
Testujc technikami szklanej skrzynki, tester ma dostp do kodu programu i
analizuje go w poszukiwaniu wskazwek, ktre pomog w testowaniu. Na
podstawie tej analizy, tester moe okreli, jakie liczby mog z wikszym
prawdopodobiestwem spowodowa zy wynik i dostosowuje do tego swoje
testowanie.
Z metodami szkalnej skrzynki wie si ryzyko stronniczoci zbyt
dokadne poznanie kodu moe spowodowa, e dostosuje si nawet
podwiadomie - zadania testowe do kodu tak, by nie spowodoway awarii.
Testowanie statyczne i dynamiczne
Black-box i glass-box; w oryginale autor posuguje si terminem biaa skrzynka (white-box),

okreleniem rwnie popularnym, ale mylcym w porwnaniu z nazw szklana skrzynka (przyp.
tumacza).
Cz II strona 5 (86)
Kolejne dwa terminy opisujce sposb testowania oprogramowania to

testowanie statyczne i testowanie dynamiczne. Testowanie statyczne dotyczy
czego, co nie jest wykonywane np. kodu lub specyfikacji
weryfikowanych przy pomocy analizy lub inpspekcji. Testowanie
dynamiczne jest tym, co powszechnie uwaane jest za testowanie
wykonywaniem i uywaniem programu.
Najlepsz analogi dla tych okrele s czynnoci wykonywane przy
sprawdzaniu uywanego samochodu. Kopanie w opony, sprawdzanie
lakieru, zagldanie pod mask to statyczne techniki testowania. Wczenie
silnika, suchanie jego pracy i jazda prbna to dynamiczne techniki
testowania.
Test specyfikacji: statyczny test metod czarnej skrzynki
Testowanie specyfikacji jest statycznym testowaniem metod czarnej
skrzynki1. Specyfikacja jest dokumentem, nie programem do wykonywania,
wic uwaa si j za statyczn. Specyfikacja zostaa zbudowana w oparciu o
dane z wielu rnych rde: bada nad uytecznoci, bada preferencji
klientw, danych z marketingu. Nie trzeba dokadnie wiedzie, w jaki
sposb wszystkie dane zostay zgromadzone wystarczy, e zostay spisane
w postaci specyfikacji wymaga. Ten dokument mona wzi do rki,
dokona na nim testowania statycznymi metodami czarnej skrzynki, i
uwanie szuka w nim bdw.
Wczeniej widzielimy przykad specyfikacji produktu dla Kalkulatora
Windowsw. W tym przykadzie posuono si standardowym pisemnym
dokumentem z ilustracj, aby opisa dziaanie projektowanego
oprogramowania. To najpowszechniejsza metoda pisania specyfikacji, ale
istnieje wiele rnorodnych wariantw. Zesp projektowy moe wole
diagramy ni opisy sowne, albo moe posuy si samodokumentujcym
si jzykiem programowania, jak np. Ada2. Techniki opisane w tym
rozdziale mona stosowa niezalenie od formy dokumentacji. Trzeba je
bdzie dostosowa do formatu specyfikacji, ale istota rzeczy pozostanie bez
zmiany.
Zwykle podzia na techniki czarnej i szklanej skrzynki stosuje si wycznie wobec testowania
dynamicznego (przyp. tumacza).
2
Samodokumentujce si jzyki programowania to fikcja, niezdolna naprawd zastpi

dokumentacji systemu (przyp. tumacza).
Cz II strona 6 (86)
Co robic jeli projekt nie ma specyfikacji? Zesp moe si przecie

posugiwa modelem skokowym lub metod prb i bdw. Dla testera to
trudna sytuacja. Celem jest jak najwczeniejsze znalezienie bdw
najlepiej zanim jeszcze powstanie kod - ale jeli nie istnieje specyfikacja,
wydaje si to niemolie. Chocia jednak nie istnieje pisemna specyfikacja,
kto programista, kierownik projektu albo sprzedawca - wie, co si usiuje
zbudowa. Mona si nimi posuyc jak chodzc, mwic specyfikacj i
zastosowa do tej specyfikacji w gowie te same techniki testowania co
wobec specyfikacji spisanej na papierze1. Mona posun si nawet jeszcze
dalej, nagrywajc zgromadzon informacj i rozpowszechniajc j w celu
poddania inspekcji. Mona wtedy poinformow zesp projektowy: Oto na
czym zamierza oprze mj plan testw i wobec czego bd kierowa
raporty bdw. Bdziemy zaskoczeni, jak wiele szczegw zostanie po tej
deklaracji popiesznie uzupenionych.
Specyfikacj mona testowa statycznymi metodami czarnej skrzynki
niezalenie od formatu specyfikacji. Moe to by dokument pisany albo
graficzny, albo mieszany. Nawet niezapisan specyfikacj mona testow,
wypytujc ludzi projektujcych i piszcych oprogramowanie.
Oglny przegld specyfikacji

Nietwo jest zdefiniowa produkt informatyczny. Specyfikacja boryka si z
wieloma niewiadomymi, oparta jest na zmieniajcych si danych i usiuje
poczy je w dokument opisujcy nowy produkt. Ten proces nie jest cis
nauk i naraony jest na trudnoci.
Pierwszym krokiem testowania specyfikacji nie jest szukanie konkretnych
bdw. Pierwszym krokiem jest spojrze na specyfikacj z gry, z lotu
ptaka niejako. Sprawdza si, czy w dokumencie nie ma duych,
zasadniczych problemw i przeocze. Mona to okrela bardziej jako prac
badawcz ni jako testowanie, ale celem tego badania jest lepsze
zrozumienie, co oprogramowanie waciwie ma robi. Rozumiejc lepiej
ukryte za specyfikacj rozmaite jak i czemu, bdzie o wiele atwiej
dokona szczegowej analizy pniej.
Wejcie w skr klienta2
Otrzymawszy pierwszy raz do rki specyfikacj produktu, najlepiej jeli
tester sprbuje si wcieli w klienta/uytkownika. Naley zbada kim jest
klient. Rozmowy z pracownikami dziau marketingu i sprzedawcami mog
Tego typu metody s czci bardzo popularnego ostatnio podejcia zwanego testowaniem
eksploracyjnym (exploratory testing), ktrego najbardziej znanym propagatorem jest James Bach
(przyp. tumacza).
2
Chodzi tu wic o walidacj specyfikacji wymaga. Jest to testowanie, ktre jest czci dziedziny
zwanej czsto inynieri wymaga; autor nie posuguje si t nazw (przyp. tumacza).
Cz II strona 7 (86)
niejedno ujawni. Jeli ma si do czynienia z produktem do uytku

wewntrznego, mona znale uytkownikw i porozmawia z nimi.1
Jest wane, aby dobrze rozumie oczekiwania klienta. Pamitajmy definicj
jakoci, ktra okrela jako jako stopie spenienia potrzeb klienta. Tester
musi rozumie te potrzeby, aby mc przetestowa, czy oprogramowanie je
spenia. Nie oznacza to, e musi si by ekspertem w dziedzinie, gdzie
bdzie dziaa oprogramowanie: by specjalist od techniki nuklearnej
testujc progamy dla elektrowni atomowej albo zawodowym pilotem
testujc symulator lotw. Jednak pewna orientacja w dziedzienie dziaania
oprogramowania jest ogromnie przydatna.
Przede wszstkim jednak nie naley niczego robi pochopnych zaoe. Jeli
czyta si cz specyfikacji ktrej si nie rozumie, nie naley zakada e
jest poprawna. W kocu przecie trzeba bdzie na jej podstawie
skonstruowa swoje testy dynammiczne, wic jako trzeba j bdzie
zrozumie. Teraz jest na to najlepszy moment. Jeli przy okazji znajdzie si
bdy w specyfikacji, tym lepiej.
Zbadanie istniejce standardw i zbiorw regu
W czasach przed powstaniem Windowsw i Macinotsha, prawie kady
produkt informatyczny mia inny interfejs uytkownika. Posugiwano si
rnymi kolorami, strukturami menu, nieograniczon iloci sposobw
otwierania plikw, tysicami tajemniczych polece dla wykonania tego
samego zadania. Przejcie z jednego programu na drugi wymagao czsto
ponownego przeszkolenia uytkownika.
Na szczcie nastpia znaczna standaryzacja oprogramownaia i sprztu2.
Dokonano take wielu bada nad tym, jak ludzie uywaj komputerw.
Dziki temu wikszo obecnych produktw jest wzgldnie jednolitych jeli
chodzi o interfejs uytkownika i sposb posugiwania si nimi, i zostay
zaprojektowane zgodznie z zasadami enrgonomii. Mona si spiera, e
daleko im jeszcze do doskonaoci i e istniej jeszcze lepsze metody,
jednak wydajno poprawia si ogromnie dziki tej standaryzacji.
Rozdzia 11 Testowanie uytecznoci, zajmie si tymi zagadnieniami
dokladniej. Na razie wystarczy pamita, e testujc specyfikacj produktu
naley wiedzie, jakie standardy i zbiory zasad powinna spenia.
Ta czynno nazywa si czsto gromadzeniem wymaga. U autora tester wykonuje czynnoci, ktre
w zasadzie powinny by wykonane przrz zesp piszcy specyfikacj, nie przez testerw. Jednak w
rzeczywistoci w takiej czy innej formie przychodzi je wykonywa w ramach przygotowa do
testowania (przyp. tumacza).
2
Autor ma na myli gwnie interfejs uytkowanika i gwnie w wiecie Windowsw. Czy podobne
zjawiska obserwujemy w dziedzinie systemw wbudowanych i innych standardw, pozostaje
czytelnikowi oceni samemu (przyp. tumacza).
Cz II strona 8 (86)
Rnica midzy standardem a zbiorem zasad dotyczy gwnie stopnia.

Standard jest bardziej jednoznaczny ni zbir zasad i naley go cile
przestrzega. Zasady np. branowe czy wewntrzne w danym
przedsibiorstwie powinny ale nie musz koniecznie by dokadnie
przestrzegane.
Istnieje wiele przykadw standardw i zbiorw zasad, ktre naley bara
pod uwag. Ponisza lista nie jest ostateczna. Naley na wasn rk zbada,
co dotyczy specyfikacji, ktr si testuje.
5. Terminologia i konwencje danego
przedsibiorstwa. Jeli oprogramowanie jest
robione specjalnie dla jednej firmy, naley
przestrzega konwencji i stosowa nazewnictwo
uywane przez jej pracownikw.
6. Wymagania branowe. Brane medyczna,
farmaceutyczna, przemysowe i finansowe maj
bardzo dokadne standardy branowe, ktre
oprogramowanie musi spenia1.
7. Standardy pastwowe. Instytucje pastwowe,
zwaszcza wojskowe, maj zwykle wasne
standardy.
8. Graficzny interfejs uytkowanika (GUI).
Oprogramowanie pracujce pod systemem
Microsoft Windows lub Apple Macinotsh
powinno spenia dostpne, opublikowane
standardy dotyczce konstrukcji i sposobu
dzialania interfejsu.
9. Stadardzy sprztowe i sieciowe.
Oprogramowanie wsppracujce bezporenio
ze sprztem komputerowym musi spenia jego
standardy.
Tester nie powinien musie samemu definiowa, jakie standardy stosuj si
si do danego oprogramowania. To jest zadaniem kierownika projektu czy
te osoby, ktra pisze specyfikacj. Tester powinien jednak przeprowadzi
wasne badania, czy rzeczywicie stosowane s waciwe standardy i czy
aden nie zostal przeoczony2. Powinno si te zna te standardy i mc
przetestowa, czy samo oprogramowanie je spenia. Powinno si trakowan
obowizujce standardy jak cz specyfikacji, wobec ktrej wykonuje si
test.
Maj te zwykle szczegowe wymagania dotyczce metod kontroli jakoci i testu (np. przemys
lotniczy, produkcja sprztu medycznego, kolejnictwo) przyp. tumacza.
2
To ryzykowna zasada jeli stosowan j bezkrytycznie zesp testucy, obciony

odpowiedzialnoci za weryfikacj specyfikacji wymaga, moe ju nie mie czasu na planowanie,
organizacj i wykonanie waciwych testw oprogramowania (przyp. tumacza).
Cz II strona 9 (86)
Przegld i przetestownie innego podobnego oprogramowania

Jednym z najlepszych sposobw, eby zrozumie czym ma by dany
produkt, jest zapoznanie si z innymi, podobnymi programami. Moe to by
produkt konkurencji albo inny, podobny do tego ktry wytwarza dany
projekt. Prawdopodobnie kierownik projektu albo zesp zajmujcy si
konstruowaniem specyfikacji wymaga ju to zrobi, wic nie powinno by
trudno zidnetyfikowa i znale taki program. Nie bdzie on dokadn kopi
budowanego programu (przecie projekt robi co nowego), ale pozwoli by
moe zorientowa si w stosownycm podejciu i moliwych technikach
testowania. Mog si te ujawni problemy, ktrych dotd nie wzito pod
uwag.
Badajc podobne oprogramowanie, warto pamita o nastpujcych
rzeczach:
10. Wielko. Czy produkt ktry bdzie si
testowa jest wiekszy czy mniejszy i czy
wpynie to znaczco na sposoby testowania?
11. Zoono. Czy produkt ktry bdzie si
testowa jest bardziej czy mniej zoony i czy
wpynie to na testowanie?
12. atwo testowania. Czy bdzie si mie do
dyspozycji rodki, czas i wiedz konieczne do
przetestowania podobnego produktu?
13. Jako/niezawodno. Czy badany produkt ma
podobn jako i niezawodno do
projektowanego?
Nic nie jest w stanie zastpi bezporedniego dowiadczenia, wic jeli
tylko da si zdoby podobne oprogramowanie, warto powici mu sporo
czasu. Zdobdzie si w ten sposb dowiadczenie, przydatne przy dalszym,
szczegowym testowaniu specyfikacji.
Techniki szczegowego testowania specyfikacji

Uporawszy si z oglnym przegldem specyfikacji, rozumie si lepiej
produkt i wymagania, ktre wpywaj na jego konstrukcj. Ta wiedza ulatwi
testowanie specyfikacji na bardziej szczegowym poziomie. Pozostaa
cz rozdziau opisuje jak to zrobi1.
Kontrolna lista atrybutw specyfikacji
Uyte tutaj listy kontrolne zostaly zaadaptowane ze stron 294-295 oraz 303-308 ksiki Handbook
of Walkthroughs, Inspections and Techncal Reviews, 3-cie wydanie, 1990, 1982, D.P. Freedmana i
G.M. Weinberga. Uyte za zgod Dorset House of Publishing (www.dorsethouse.com). Prawa
autorskie zastrzeone (przyp. autora).
Cz II strona 10 (86)
Dobra, przemylana i staranna specyfikacja produktu, spenia osiem

wanych wymaga:
14. Kompletna. Czy czego brakuje? Czy jest
dokadna? Czy zawiera wszystko, czego
potrzeba?
15. Trafna. Czy proponowane rozwizanie jest
prawidowe? Czy cel jest waciwie
zdefiniowany? Czy s jakie bdy?
16. Dokadna, jednoznaczna, przejrzysta. Czy
opis jest cisy i nie jest mtny? Czy moliwa
jest jednoznaczna interpretacja? Czy jest atwy
do zrozumienia?
17. Spjna. Czy opisy cech i funkcji nie s
niezgodne i innymi albo sprzeczne
wewntrznie?
18. Istotna. Czy dany opis jest konieczny, czy
mona go opuci? Czy dana funkcja daje si
wyprowadzi z potrzeb klienta?
19. Wykonalna. Czy funkcj da si zrealizowa
przy pomocy dostpnego personelu, narzdzi i
rodkw w ramach dostpnego budetu i
harmonogramu?
20. Wolna od szczegw realizacji. Czy
specyfikacja poprzestaje na zdefiniowaniu
produktu i nie usiuje okreli konstrukcji,
architektury i kodu oprogramowania?
21. Dajca si przetestowa. Czy dan funkcj
bdzie mona przetestowa? Czy podana
informacja jest dostateczna, aby tester mg na
jej podstawie okreli poprawno jej dziaania?
Testujc specyfikacj, naley wzi pod uwag kade z powyszych
wymaga i zada sobie samemu pytanie, czy tekst i rysunki specyfikacji
speniaj je. Jeli nie, mamy do czynienia z bdem, na ktry naley co
zaradzi.
Kontrolna lista terminologii
Uzupenieniem listy wymaga z poprzedniego podrozdziau jest lista sw,

na ktre warto zwrci szczegln uwag w czasie czytania specyfikacji.
Sowa, ktrych brzmienie sugeruje, e mwi o czym nie do koca
przemylanym, czsto s sygnaem istnienia bdw specyfikacji,
podpadajcych pod omwion list wymaga. Naley ich szuka w czasie
czytania i starannie przeanalizowa ich kontekst. Specyfikacja albo zawiera
precyzyjniejsze wyjanienie funkcji, albo poprzestaje na niejednoznaczym
okreleniu wwczas mamy do czynienia z bdem specyfikacji, ktrego
szukalimy.
22. Zawsze, kady, wszystkie, aden, nigdy.
Natknwszy si na takie sowa, oznaczajce
jednoznaczn pewno, warto sprawdzi, czy
rzeczywicie opisane przez nie regua jest
jednoznaczna i pewna. Dobr metod takiego
sprawdzianu jest prba znalezienia przypadkw
szczeglnych, kiedy takie reguy by moe nie
obowizuj.
23. Niewtpliwie, dlatego, jasne, oczywiste,
niewtpliwe. Te sowa usiuj przekona
czytelnika, eby co zaakceptowa jako
oczywiste. Nie dajmy si zapa w t puapk.
24. Niektre, czasami, czsto, zwykle, normalnie,
najczsciej, wikszo, gwnie. Te sowa s
zbyt niejednoznaczne. Nie da si przetestowa
funkcji, ktra dziaa czasami.
25. Itd., i tak dalej, i temu podobne, takie jak.
Wyliczenia zakoczone takimi zwrotami nie
daj si przetestwoa. Wyliczenia musz by
kompletne albo wyjanione tak, eby nie byo
wtpliwoci w jaki sposb dany cig powstaje i
co powinno nastpi na licie w dalszej
kolejnoci.
26. Dobry, szybki, tani, wydajny, may, stabilny.
To s okrelenia nie dajce si wyrazi
liczbowo, wic nie dajce si przetestowa. Jeli
pojawiy si w specyfikacji, musz by
dodatkowo wyjanione, eby byo dokadnie
wiadomo co waciwie oznaczaj.
27. Opracowa, przetworzy, odrzuci, pomin,
wyeliminowa. Za tymi okreleniami moe kry
si skomplikowana funkcja, ktra powinna by
wyspecyfikowana bardziej szczegowo.
28. Jeli To (ale pominite W przeciwnym

razie)1. Warto poszukiwa zda zawierajcych
wyraenia Jeli To, ale pozbawione
zamykajcego W przeciwnym razie. Wtedy
trzeba postawi sobie pytanie, co ma si sta,
jeli w przeciwnym razie si speni.
Podsumowanie
Po przeczytaniu tego rozdziau mona doj do wniosku, e tesowanie
specyfikacji to proces bardzo subiektywny. Przegld oglny eliminuje
przeoczenia i braki, przegld szczegowy pozwala stwierdzi, czy
waciwie zdefiniowane zostay wszystkie szczegy. Jednak te techniki nie
stanowi dokadnego procesu, ktry mona realizowa krok po kroku z
dwch przyczyn:
29. Niniejsza ksika jest podrcznikiem dla
pocztkujcych, ktrego celem jest szybkie
podniesienie umiejtnoi zawodowych
testerw. Na to wanie pozwala
zaprezentowany materia cho nie opisuje
technik szczegowych, pozwala jednak na
cakiem solidne przetestowanie kadego rodzaju
pisemnej specyfikacji.
30. Specyfikacje maj bardzo rnorodn form.
Metody opisane w tym rozdziale pozwol
przestestowa specyfikacj niezalenie od tego,
czy znajduje si ona wycznie w czyjej gowie,
czy opisana jest w formie wykresw i
diagramw, czy zdaniami, ktre trzeba
przeanalizowa.
Dla osb zainteresowanych bardziej szczegowym opisem technik
dokonywania przegldw specyfikacji2, warto zapozna si z pracami
Michaela Fagana. Pracujc w IBM-ie, Fagan by pionierem szczegowego i
metodycznego podejcia zwanego inspekcjami oprogramowania. Te metody
s dzi stosowane przez wiele przedsibiorstw3, zwaszcza wytwarzajcych
oprogramowanie krytyczne dla bezpieczestwa, w celu dokonywania
przegldu specyfikacji i kodu rdowego. Wicej informacji na ten temat
mona znal na stronie www.mfagan.com.
Pytania
1
Np. w jzyku C bdzie to If then, ale bez kaluzuli else (przyp. tumacza).
Metodyka Fagana nadaje si do w ogle wszelkich inspekcji, nie tylko specyfikacji i nie tylko
pisemnej dokumentacji (przyp. tumacza).
3
Istnieje wiele nowoczeniejszych metodyk inspekcji opisy niektrych z nich mona znale z licie
literatury na kocu ksiki (przyp. tumacza).

1. Czy mona dokona testu specyfikacji metod
szklanej skrzynki?
2. Podaj kilka przykadw standardw albo regu
dla oprogramowania pod Winowsami albo dla
Macintosha.
3. Wyjanij, jaki bd znajduje si w powniszym
zdaniu ze specyfikacji wymaga: Wybranie
przez uytkownika opcji Upakuj dane
spowoduje e program zagci list danych do
najmniejeszej moliwej objtoci przy uyciu
metody macierzy Hoffmana.
4. Wyjanij, czemu testera powinno zaniepokoi
ponisze zdanie ze specyfikacji wymaga:
Oprogramowanie pozwoli na 100 milionw
jednoczesnych pocze, chocia zwykle nie
bdzie stosowanych wicej ni 1 milion
pocze.
Rozdzia 5
Test z klapkami na oczach
W TYM ROZDZIALE
Dynamiczne testowanie metodami czarnej skrzynki:
testowanie z zawizanymi oczami
Test pozytywny i test negatywny
Metoda klas rwnowanoci
Testowanie danych
Testowanie zmian stanw
Inne techniki czarnej skrzynki
OK, bierzmy si do roboty! W tym rozdziale zapoznamy si z tym, co
wikszo ludzi rozumie pod pojciem testowanie oprogramowania. Czas
splun w garci, zasi przed komputerem i zacz szuka bdw.
Dla pocztkujcego testera moe to by pierwszym zadaniem. W czasie
wywiadu z kandydatami na stanowisko testera, na pewno padnie pytanie, jak
zabra si za testowanie nowego programu albo nowej funkcji.
atwo jest ruszy na olep, zacz bbni w klawiatur i mie nadziej, e
uda si co rozwali. Takie podejcie moe zadziaa przez jaki czas. Jeli
program nie jest jeszcze gotowy, nietrudno mie szczcie i szybko znale
kilka bdw. Niestety, te atwe zdobycze szybko znikn i trzeba bdzie
podej do zadania w sposb bardziej ustrukturalizoany i celowy, eby nadal
znajdowa bdy i zosta testerem na wysokim poziomie.
W tym rozdziale opisane s najpowszechniejsze i najbardziej wydajne
techniki testowania oprogramowania. Nie ma znaczenia, jaki rodzaj
programu si testuje te same techniki bd skuteczne zarwno dla
wykonanego na zamwienie firmy pakietu do prowadzenia rachunkowsci,
jak i dla oprogramowania w automatyzacji przemysowej, jak i dla
przeznaczonej na masowy rynek gry komputerowej.
Nie trzeba by programist aby posugiwa si tymi technikami. Nawizuj
one wprawdzie do podstawowych poj programowania, ale nie trzeba
samemu pisa kodu, aby je stosowa. Dla niektrych z opisanych tu tecknik
podane s pewne szczegy dla wyjanienia, na czym polega ich
skuteczno, ale przykady kody rdowego s krtkie i napisane w
BASIC-u aby atwo zilustrowa o co chodzi. Ci czytelnicy, ktrzy s
programistami i chc pozna wicej technik dajcych si zastosowa w
testowaniu na niskim poziomie, znajd po przeczytaniu tego rozdziau
wicej tematw dla siebie w rozdziaach 6-ym Analiza kodu i 7-ym
Testowanie oprogramowania pod rentgenem.
W tym rozdziale omwione s nastpujce tematy:
31. Co to jest dynamiczne testowanie metodami

czarnej skrzynki?
32. Jak zmniejszyc ilo zada testowych przy
pomocy podziau na klasy rwnowanoci
33. Jak zidentyfikowa kopotliwe warunki
graniczne
34. Wartoci danych, ktre skutecznie wywouj
awarie
35. Jak testowa stany i zmiany stanw
oprogramowania
36. Jak posugiwa si powtarzaniem, stresem i
wysokim obcieniem aby lokalizowa bdy
37. Kilka miejsc gdzie bdy lubia si ukrywa
Dynamiczne testowanie metodami czarnej skrzynki:

testowanie z zawizanymi oczami
Testowanie oprogramowania kiedy nie ma si wgldu w szczegy kodu
programu nazywane jest dynamicznym testowaniem metodami czarnej
skrzynki. Dynamicznym, poniewa program jest wykonywany tester
pouguje si nim w podobny sposb jak zwyky uytkownik. Czarnej
skrzynki, bo testowania dokonuje si nie wiedzc dokadnie, jak program
dziaa jakby z zawizanymi oczami. Wprowadza si dane wejciowe,
otrzymuje dane wyjciowe i sprawdza wyniki. Inn czsto stosowana nazw
na dynamiczne testowanie metod czarnej skrzynki to testowanie
behawioralne bada si bowiem zachowanie programu, kiedy si nim
posugiwa.
Aby mc to robi skutecznie, trzaba orientowa si, co program waciwie
ma wykonywa ta informacja powinna znajdowa si w specyfikacji
wymaga albo w dokumentacji produktu. Nie musi si wiedzie, co si
dzieje wewntrz skrzynki wystarczy wiedzie, e dane wejciowe A
maj spowodowa dane wyjciowe B, za dane wejciowe C dane
wyjciowe D. Dobra specyfikacja produktu powinna zawiera te informacje.
Jak si ju wie co wchodzi, a co powinno wychodzi z programu, mona
przystpi do konstruowania zada testowych. Zadania testowe to lista
danych wejciowych, ktre si zastosuje i czynnoci, ktre si wykona w
czasie testowania1. Rysunek 5.1 przedstawia kilka przykadw zada
testowych, ktre mona uy przy testowaniu dodawania w Kalkulatorze
Windows.
Zwykle do definicji zdania testowego zalicza si te jako trzeci element oczekiwany wynik. W
przeciwnym razie interpretacj poprawnoci lub nie wynikw pozostawia si niejako uznaniu testra, co
jest postpowaniem ryzykownym (przyp. tumacza).
Zadania testowe dla dodawania dla Kalkulatora Windows

0+0
0+1
254+1
255+1
256+1
1022+1
1023+1
1024+1
powinno
powinno
powinno
powinno
powinno
powinno
powinno
powinno
da
da
da
da
da
da
da
da
0
1
255
256
257
1023
1024
1025
Rysunek 5.1 Zadania testowe pokazuj rne dane wejcioiwe i czynnoci w

trakcie testowania programu.
Wybr zada testowych to bezwzgldnie najwaniejsze zadanie testera.
Nieprawidowy dobr moe spowodowa, e przetestuje si za duo, za
mao, albo po prostu nie to co trzeba. Te czary polegaj na tym, by
mdrze wzi pod uwag stopie ryzyka i umiejtnie zredukowa
nieskoczon ilo moliwych zada testowych do iloci, ktr
rzeczywicie daje si uy.
Pozostaa cz tego rozdziau a take znaczna cz reszty ksiki
nauczy nas sposobw strategicznego dobierania dobrych zada testowych.
Rozdzia 17-y Jak pisa zadania testowe i rejestrowa ich wyniki opisuje
konkretne sposoby zapisywania i zarzdzania zadaniami testowymi.
Testowanie eksploracyjne kiedy brakuje specyfikacji
Testujc oprogramowanie wytwarzane w ramach profesjonalnego,
dojrzaego procesu wytwarzania, ma si do dyspozycji szczegow
specyfikacj. Testujc programy wytwarzane metod skokow albo prb i
bdw, zwykle nie ma si adnej specyfikacji. To marna sytuacja dla
testera, ale jest szansa na dziaajce rozwizanie, jeli posuy si tak
zwanym testowaniem eksploracyjnym.
Program traktuje si jak specyfikacj i metodycznie eksploruje
wszystkie jego funkcje jedna po drugiej. Zbiera si notatki na temat
dziaania programu, sprzdza map jego funkcji i stosuje niektre z
technik czarnej skrzynki opisanych w rozdziale 3-im Test
oprogramowania w rzeczywistoci. Program analizuje si tak jakby
rzeczywicie by specyfikacj, po czym stosuje si opisane w niniejszym
rozdziale techniki testowania dynamicznego metodami czarnej skrzynki.
Nie da si t metod przetestowa programu rwnie gruntownie jak

wtedy, kiedy specyfikacja jest dostpna nie uda si na przykad odnale
funkcji brakujcych. Niemniej, da si program systematycznie
przetestowa. Jeli uda si znale troche bdw, to ju w tej sytuacji
sukces.
Test pozytywny i test negatywny

Istniej dwa podstawowe podejcia do testowania programw: testowanie
pozytywne i testowanie negatywne. Testy pozytywne kontroluj jedynie, e
oprogramowanie funkcjonuje poprawnie na swego rodzaju minimalnym
poziomie. Nie testuje si granic zbyt daleko, nie szuka si sposobw
wywoania awarii za wszelk cen. Postpuje si delikatnie, w
rkawiczkach, stosujc tylko najprostsze i najbardziej oczywiste zadania
testowe.
Jeli jednak celem ma by znajdowanie bdw, po co w ogle robi testy
pozytywne? Czy nie chcemy za wszelk cen znajdowa bdw, stosujc
najbardziej demomniczne zadania testowe? Tak, ale nie od razu.
Wyobramy sobie analogi z testowaniem nowego modelu samochodu
(rysunek 5.2). Testujc pierwszy prototyp, ktry dopiero co opuci linie
montaow i nigdy jeszcze nie jedzi, nie bdzie si go od razu prowadzi
na peen gaz tak ostro, jak tylko si da. Kierowca testowy przypuszczalnie
szybko rozbiby prbny samochd. W nowym samochodzie peno bdw
ujawni si nawet przy powolnjej jedzie w normalnych warunkach. Moe
opony maja z rednic albo hamulce s niesprawne, albo silnik zbyt
szybko wchodzi na wysokie obroty. Naley znale te usterki i naprawi je,
zanim przycinie si gaz do koca na torze prbnym1.
Autor stosuje jak wynika z podanego przykadu termin testowanie negatywne czciowo w tym
znaczeniu, ktre zwykle okrela si jako testowanie wydajnoci albo testowanie pod obcieniem. Za
testowanie negatywne to wedle powszechnej praktyki okrelenie testowania zadaniami, gdzie dane
wejciowe s niedozwolone, albo odwrotne do wymaga opisanych w specyfikacji (przyp. tumacza).
Rysunek 5.2 Naley najpierw posuy si testowaniem pozytywnym zanim

przejdzie si do testowania negatywnego.
Projektujc i wykonujc zadania testowe, zawsze najpierw naley
wykonywa testy pozytywne. Trzeba najpierw sprawdzi, czy program
dziaa w normalny sposb, zanim zacznie si testowa z grubej rury.
Moe to zdziwi, ale wielk ilo bdw znajduje si uywajc programu
w najnormalniejszy sposb.
Kiedy jest si ju przekonanym, e oprogramowanie dziaa zgodnie ze
specyfikacj w zwykych warunkach, czas zastosowa podstpne, ze,
przebiege zadania, ktre maj na celu zmusi nawet dobrze ukryte bdy do
ujawnienia si. Projektowanie i wykonywanie zada testowych, ktrych
gwnym celem jest zamanie programu nazywane jest testowaniem
negatywnym albo wymuszniem awarii. Jak zobaczymy w dalszej czci tego
rozdziau, testy negatywne nie zawsze musz wyglda gronie. Czsto
wygldaj jak testy pozytywne, ale s wybrane strategicznie w punktach,
gdzie czsto kryj si typowe saboci oprogramowania.
Komunikaty o awarii: test pozytywny czy test negatywny?
Czsto spotykan grup zada testowych s zadanie majce na celu
wymuszenie komunikatw o awariach programu. Znamy je dobrze jak
ten ktry si pojawia jeli poleci zapisanie pliku na dyskietce nie
woywszy dyskietki do stacji dyskw. Tego rodzaju zadania znajduj si
na samej granicy midzy testami pozytywnymi i negatywnymi.
Specyfikacja zapewne okrela, e pewna sytuacja powinna spowodowa
wywietlenie komunikatu o awarii. To jest typowe testowanie pozytywne.
Z drugiej strony, wymuszajc zaistnienie awaryjnej sytuacji, mamy do
czynienia z czym podobnym do testowania negatywnego. W gruncie
rzeczy, test komunikatw o awariach jest zapewne jednym i drugim
zarazem.
Nie warto trapi si cis definicj. Wane jest natomiast, aby wymusi
pojawienie si wszystkich komunikatw o awariach, ktre przewidziaa
specyfikacja wymaga, ale te wynale takie sytuacje awaryjne, ktrych
specyfikacja nie przewiduje. Prawdopodobnie znajdzie si bdy w obu
wypadkach.
Metoda klas rwnowanoci

Wybr zada testowych jest najwaniejszym zadaniem testera, a metoda
podziau na klasy rwnowanoci jest najbardziej podstawow technik
stosowan w tym celu. Podzia na klasy rwnowanoci jest procesem
metodycznego zmniejszenia olbrzymiego (czsto nieskoczonego) zbioru
moliwych zada testowych do zbioru znacznie mniejszego, ale nadal
dostatecznie skutecznego.
W przykadzie z testowaniem Kalkulatora Windowsw z rozdziau 3-ego,

nie dao si przetestowa wszystkich moliwych kombinacji dodawania
dwch liczb. Podzia na klasy rwnowanoci jest sposobem, eby wybra
wartoci istotne i odrzuci zbdne.
Na przykad, nawet nic nie wiedzc o podziale na klasy rwnowanoci, czy
mona przypuszcza, e przetestowawszy 1+1, 1+2, 1+3 i 1+4 warto jeszcze
testowa 1+5 i 1+6? Czy te daoby si bezpiecznie zaoy, e bd dziaa
poprawnie?
A co mona przypuszcza o 1+99999999999999999999999999999999
(najwiksza liczba jak daje si wprowadzic do kalkulatora)? Moe to
zadanie testowe jest troch inne od pozostaych, moe naley jakby do innej
klasy, do innej klasy rwnowanoci? Stanwszy przed koniecznoci
wyboru, czy wybraoby si raczej to zadanie, czy na przykad 1+13?
Patrzcie, ju zaczynamy myle jak zawodowi testerzy oprogramowania!
Klasa rwnowanoci to zbir zada testowych ktre testuj to samo albo
ujawniaj ten sam bd.
Jaka jest rnica midzy 1+99999999999999999999999999999999 a 1+13?
Jeli chodzi o 1+13, to wyglda ono na zwyke, proste dodawanie, takie
samo jak na przykad 1+5 albo 1+392. Natomiast
1+99999999999999999999999999999999 jest daleko, gdzie na skraju.
Jeli wzi najwiksza moliw liczb i dodac do niej 1, moe zdarzy si
co niedobrego moe odkryje si bd? Ten wypadek skrajny jest osobn
klas rwnowanoci1, inn ni klasa zwyczajnych liczb.
Identyfikujc klasy rwnowanoci, warto wzi pod uwag sposoby, jak
pogrupowa razem podobne dane wejciowe, podobne dane wyjciowe i
podobne dziaania programu. Te grupy mog by stosownymi klasami
rwnowanoci.
Przypatrzmy si kilku przykadom.
Czsto spotyka si nazw testowanie wartoci skrajnych na okrelenie testowania wartoci

granicznych dla klas rwnowanoci i traktuje obie metody jako odrbne, choc uzupeniajce si
wzajemnie.
38. Przy dodawaniu dwch liczb, wydawaa si

istnie wyrana rnica midzy
przetestowaniem 1+13 a
1+99999999999999999999999999999999.
Nazwijmy to intuicj, ale pierwsze wydaje si
zwykym dodawaniem, drugie wydaje si
ryzykowne. Ta intuicja jest trafna. Program musi
wykonywac dodawanie jednego do wartoci
maksymalnej w zupenie inny sposb ni
dodawanie dwch maych liczb. Te dwa
wypadki, poniewa program przypuszczalnie
dziaa dla nich zupenie inaczej, nale do
dwch rnych klas rwnowanoci.
Jeli zna si troch programowanie, przychodzi do gowy jeszcze klika
innych specjalnych liczb na ktrych program bdzie wykonywa
operacje w specjalny sposb. Jeli nie zna si programowania, uszy do
gry mona opanowa opisane techniki i stosowa je bez koniecznoci
rozumienia szczegw kodu.
39. Rysunek 5.3 przedstawia menu Edycji z
Kalkulatora z rozwinitymi poleceniami Kopiuj
i Wklej. Kad z tych funkcji mona wykonac na
pi rnych sposobw. Aby skopiowa, mona
klikn na pozycj menu, nacisn c albo C,
nacisn kombinacj Ctrl+c albo Ctrl+Shif+c.
Kade z tych polece skopiuje aktualn liczb
do Schowka wykona t sam procedur i
osignie ten sam wynik.
Rysunek 5.3 Rne sposoby przywoania funkcji kopiowania daj ten sam
wynik.
Jeli ma si przetestowa funkcj kopiowania, mona podzieli tych pi

rnych cieek na trzy grupy (klasy rwnowanoci): kliknicie na
polecenie z menu, napisanie c albo nacinicie Ctrl+c. Jeli wzrasta
nasze zaufanie do jakoci testowanego oprogramowania i weiemy, e jak
dotd funkcja kopiowania dziaaa dobrze niezalenie od sposobu, w jaki
si j przywoao, mona si zdecydowa na dalsze ograniczenie iloci
klas rwnowanoci, nawet do jednej tylko, np. Ctrl+c.
40. W trzecim przykadzie, przyjrzyjmy si
moliwym sposobom wprowadzenia nazwy
pliku do standardowego okna dialogowego
Zapisz jako (rysunek 5.4).
Rysunek 5.4 Pole do wprowadzenia nazwy pliku w oknie dialogowym

Zapisz jako ilustruje kilka rnych moliwoci podziau na klasy
rwnowanoci.
Nazwa pliku w Winodows moe zawiera dowolne znaki z wyjtkiem \ / :
* ? < > i | . Nazwy plikw mog skada si od jednego do 255 znakw.
Konstruujc zadania testowe dla nazw plikw, mona na przykad wybra
osobne klasy rwnowanoci dla dozwolonych i niedozwolonych znakw,
nazw o dozwolonej iloci znakw, nazw zbyt krtkich i nazw zbyt
dugich.
Pamitajmy, e celem podziau na klasy rwnowanoci jest zredukowanie
zbioru moliwych zada testowych do maego i dajcego si zastosowa w
praktyce, ale wci jeszcze dostatecznie dobrze testujcego
oprogramowanie. Podejmujc decyzj, e nie bdzie si testowa
wszystkiego, ponosi si ryzyko, trzeba wic dobrze si zastanowi, jak
wybra klasy rwnowanoci, eby poziom ryzyka mie pod kontrol.
Jeli posun si za daleko w redukcji iloci klas rwnowanoci po to,
aby zmniejszyc ilo zada testowych, ryzykuje si wyeliminowanie
testw ktre mogyby ujawnic bdy. Pocztkujcym testerom mona
zaleci, eby poddali wybrane przez siebie klasy rwnowanoci ocenie
kogo bardziej dowiadczonego.
Na zakoczenie wykadu o klasach rwnowanoci warto doda, e podzia

na klasy nie jest cisy, jest subiektywny. Nie jest nauk, lecz raczej sztuk.
Dwaj testerzy testujcy ten sam program mog zaproponowa dwa rne
zestawy klas rwnowanoci. Jest to do przyjcia pod warunkiem, e
wybrane klasy zostay poddane przegldowi i e zdaj si zapewnia
dostateczne pokrycie testowanego oprogramowania.
Testowanie danych
Njaprostszym sposobem wyobraenia sobie programu komputeroego jest
podzielic go na dwie czci: dane oraz program. Danymi staj si dane
wejciowe z klawiatury, kliknicia mysz, pliki z dysku, wydruki itd.
Program to przepyw sterowania, transakcje, logika i wyliczenia
numeryczne. Czsto dzieli si test oprogramowania na analogiczne dwie
czci.
Wykonujc testy na danych programu, kontroluje si informacje
wprowadzane przez uytkownika, uzyskiwane wyniki, a take porednie
wyniki ukryte w programie.
Kilka przykadw danych:
41. Wyrazy napisane przez uytkowanika w
programie do przetwarzania tekstu
42. Liczby wprowadzone w arkusz kalkulacyjny
43. Ilo pozostajcych jeszcze do dyspozycji
strzaw w grze komputerowej
44. Obraz wydrukowany przez oprogramowanie do
przetwarzania fotografii
45. Kopie zapasowe plikw na dyskietce
46. Dane przsyane za porednictwem modemu
przez linie telefoniczne
Ilo danych przetwarzanych nawet przez najprostszy program moe by
ogromna. Przypomnijmy sobie wszystkie moliwe kombinacje dodawania
na zwykym kalkulatorze. Wyobramy sobie teraz program do przetwarzania
tekstu, system naprowadzajcy pociskw rakietowych albo program do
przetwarzania danych na giedzie. Sztuczka (jeli mona tak to nbazwa) jak
uczyni to moliwym do przetestowania polega na tym, aby inteligentnie
zmniejszyc ilo klas rwnowanoci posikujc si kilkoma podstawowymi
zasadami: warunkw granicznych, warunkw granicznych dla podklas,
pustych zbiorw danych i niedozwolonych danych1.
1
Cay ten rozdzia naleaoby raczej zatytuowa Jak stosowa klasy rwnowanoci w praktyce.
Tytu Testowanie danych wprowadza w bd, poniewa kci si z powszechnie przyjtymi
definicjami testowania danych. Statyczne testowanie danych polega na poszukiwaniu w kodzie
rdowym bdw typu uycie zmiennej przed przydzieleniem jej wartoci, uycie zmiennej poza
zakresem jej definicji itp. Dynamiczne testowanie danych polega na oszacowaniu pokrycia testowego
np. wszystkich cieek od definicji do pierwszego uycia wszysktkich zmiennych programu. Te
Warunki graniczne
Najlepszym sposobem opisania testowania warunkw granicznych jest
rysunek 5.5. Jeli daje si bezpiecznie i pewnie przej brzegiem urwiska i
nie spa, to prawie na pewno daje si te i rodkiem pola. Jeli
oprogramowanie dziaa poprawnie dla wartoci skrajnych, to prawie na
pewno bdzie te dziaa dobrze w normalnych warunkach.
Warunki graniczne s szczeglnych wypadkiem, poniewa programownaie
jest ze swojej natury naraone na problemy zwizane z definicj warunkw
brzegowych2. Oprogramowanie jest binarne co jest albo prawd, albo nie.
Jeli jaka operacja moe by wykonywana na przedziale wartoci, to
istnieje ryzyko, e nawet jeli programista nie zrobi bdu dla wartoci ze
rodka przedziau, to popeni bd wanie na krawdzi. Wydruk nr 5.1
pokazuje, jak problem warunkw brzegowych atwo wciska si do
prociutkiego programu.
Wydruk 5.1 Prosty program w BASIC-u, demostrujcy bd warunkw
brzegowych.
1.
2.
3.
4.
5.
6.
7.
8.
Rem Stwrz 10-elementowy wektor cakowitoliczbowy

Rem Przydziel kademu elementowi wartoc 1
Dim data (10) As Integer
Dim i As Integer
For i=1 To 10
data(i)=-1
Next i
End
Rysunek 5.5 Granica w oprogramowaniu przypomina krawd urwiska.
metody s poza zakresem niniejszej ksiki (przyp. tumacza).

2
Sw brzegowe, graniczne i skrajne uywa si tutaj zupenie zamiennie (przyp. tumacza).
Ten fragment kodu ma stworzy 10-elementowy wektor i nada kademu

elementowi wektoru warto 1. Wydaje si to bardzo proste. Wektor na 10
liczb cakowitych i licznik (i) zostaj stworzone. Ptla For jest
wykonywana od 1 do 10, i kady element wektoru otrzymuje warto 1.
Gdzie problem z wartoci graniczn?
W programach w BASIC-u, kiedy stwarza si wektor o podanym zasigu
w tym wypadku, Dim data (10) as Integer pierwszy element
wektoru orzymuje numer 0, a nie 1. Podany program w rzeczywistoci
stwarza wektor majcy 11 elementw, od data(0) do data(10).
Program wykonuje ptl od 1 do 10 i nadaje tym elementom wektoru
warto 1, ale poniewa pierwszy element to data(0), nie otrzymuje on
adnej wartoci. Kiedy program skoczy przebieg, wartoci wektoru s
nastpujce:
data(0)=0
data(6)=-1
data(1)=-1
data(7)=-1
data(2)=-1
data(8)=-1
data(3)=-1
data(9)=-1
data(4)=-1
data(10)=-1
data(5)=-1
Zwrmy uwag, e warto elementu data(0) nie jest 1, lecz 0. Gdyby
programista pniej zapomnia o tym, albo inny programista nie zdawa
sobie sprawy, jak ten wektor zosta zainincjowany, mgby uy pierwszego
elementu wektoru, data(0), sdzc e ma on wartoc 1. Tego typu
problemy s bardzo powszechne i we wikszych, zoonych systemach
czsto powoduj przykre, trudne do zlokalizowania bdy1.
Rodzaje warunkw granicznych
Czas ju aby naprawd uruchomi szare komrki i zastanowi si, co
waciwie stanowi granic. Pocztkujcy testerzy nie zawsze zdaja sobie
spraw, jak wiele rnych granic moa wyznaczy na jednym zbiorze
danych. Czsto mamy do czynienia z kilkoma granicami rzucajcyjmi si w
oczy, ale jeli poszpera gbiej, znajdzie si liczne dalsze granice bardziej
ukryte, sabo zauwaalne i naraone na trudne do wykrycia bdy.
Ciekawe byoby zastanowi si, dlaczego w ogle wprowadzono do jzyka programowania tak
sprzeczn z intuicj, prowokujc do popeniania bdw, nienaturaln form deklarowania i
indeksowania wektorw. Podobne zjawiska s nagminne w wiecie informatyki. Wychowani na nich
programici i analitycy systemw przenosz tego typu mnaieryzmy na projektowane przez siebie
urzdzenia i programy uytkowe, ktre wobec tego cechuje czsto raco niski poziom uytecznoci,
niewygodny i niezgodny z intuicj interfejs uytkownika, obiekt licznych anegdot. Testerzy czsto
znajduj si w szczeglnej sytuacji, pozwalajcej im na identyfikowanie takich prooblemw bardzo
wczenie (przyp. tumacza).
Warunki graniczne to sytuacje powstajce na krawdziach planowanych

operacyjnych ogranicze oprogramowania.
Zetknwszy si z zagadnieniem w dziedzinie testowania oprogramowania,
ktre wymaga zidentyfikowania granic, naley wzi pod uwag
nastpujce typy danych:
numeryczne
szybko
znaki
pooenie
pozycja
wielko
ilo
Nastpnie trzeba uwzgldni nastpujce atrybuty powyszych typw:
pierwszy/ostatni
minimum/maksimum
pocztek/koniec
ponad/poniej
pusty/peny
najkrtszy/najduszy
najwolniejszy/najszybszy
najbliszy/najdalszy (w czasie)
najwikszy/najmniejszy
najwyszy/najniszy
nastpny/najdalszy (w kolejnoci)
Nie s to listy ostateczne. Zawieraj wikszo moliwych warunkw
brzegowych, ale kade oprogramowanie jest inne i mog w nim znajdowa
si zupenie inne typy danych ze swoistymi warunkami granicznymi.
Majc moliwoc wyboru wartoci, ktrej uyje si do przetestowania
danej klasy rwnowanoci, zaleca si uycie wartoci lecych na
granicy klasy (przedziau wartoci).
Testowanie w pobliu granic
Nauczylimy si jak dotd, e w celu ograniczenia iloci zada testowych,
naley podzieli zbiory danych, na ktrych dokonuje operacji testowane
oprogramowanie, na mniejsze zbiory zwane klasami rwnowanoci.
Poniewa bdy oprogramowania czsto wystpuj na granicach
przedziaw wartoci, wybierajc dane testowe nalece do klasy
rwnowanoci, warto wybiera wartoci lece na granicach w ten
sposb zwykle znajduje si wicej bdw.
Jednak samo testowanie wycznie na granicy przedziaw zwykle nie
wystarcza. Najlepiej jest testowa po obu stronach granicy1.
Szegowa analiza tych zagadnie naley to tak zwanego testowania domen (nie ma nic wsplnego z
domenami Internetowymi). Te zagadnienia opisane s obszernie w kilku pozycjach z listy referencji
(przyp. tumacza).
Najwicej bdw znajduje si, stworzywszy dwie klasy rwnowanoci

(wok kadej granicy). Do pierwszej z nich zaliczy si wartoci, ktre le
bezpiecznie we wntrzu przedziau, stanowicego klas rwnowanoci. Do
drugiej klasy zaliczy si wartoci niedozwolone, lece poza testow klas
wartoci co do ktrych oczekuje si, e mog wywoa jak awari.
Tesutujc warunki graniczne, naley zawsze przetestowa dozwolon
warto tu przy samej wartoci granicznej, warto graniczn oraz
warto niedozwolon pooon jak najbliej granicy.
Testowanie poza granicami jest z reguy atwo uzyska dodajc jeden albo
inn ma wielkoc, do grnej granicy, a odejmujc jeden albo inn ma
wielko, od dolnej granicy2. Na przykad:
47. Pierwszy-1 / ostatni+1
48. Start-1 / koniec+1
49. Mniej ni pusty / wicej ni peny
50. Jeszcze wolniejszy / jeszcze szybszy
51. Najwikszy+1 / najmniejszy-1
52. Minimum-1 / maksimum+1
53. Tu ponad / tu pod
54. Jeszcze krtszy / jeszcze duszy
55. Jeszcze wczeniej / jeszcze pniej
56. Najwyszy+1 / najniszy-1
Przypatrzmy si kilku przykadom, ktre uatwi zrozumienie, jak mysle na
temat moliwych granic i ich testw:
57. Jeli pole tekstowe dopuszcza wprowadzenie od
1 do 255 znakw, naley wprowadzi 1 i 255
znakw, jako wartoci z klasy wartoci
dozwolonych. Nastpnie naley wprowadzi 0 i
256 znakw jako wartoci z klasy wartoci
niedozwolonych.
58. Jeli program czyta i pisze dane na dyskietce,
naley sprbowa zapisa plik bardzo may,
najlepiej z jedn tylko pozycj, a nastpnie plik
bardzo duy dokadnie limit pojemnoci
dyskietki. Naley te sprbowa zapisa plik
pusty i plik wikszy ni pojemno dyskietki.
Dotyczy to oczywicie zmiennych cakowitych. Zmienne rzeczywiste (zmiennoprzecinkowe)

wymagaj bardziej precyzyjnych manewrw numerycznych (przyp. tumacza).
59. Jeli program pozwala na wydruk wielu stron na

jednej stronie, naley wydrukowa jedn stron i
maksymaln ilo stron, na ktr program
zezwala, a nastpnie sprbowa wydrukowa
zero stron i wiksz ilo ni maksymalna
dozwolona przez program.
60. Program ma pole do wprowadzania 5-cyfrowego
kodu pocztowego. Naley wtedy wyprbowa
00-000, najprostsze i najmniejsze, a take
warto najwiksz 99-999. Nastpnie naley
wyprbowa np. 00-00 i 100-000.
61. Testujc symulator lotw, naley sprbowa
lecie dokadnie na poziomie ziemi oraz na
maksymalnej dozwolonej dla samoloty
wysokoci. Naley te sprbowa lotu poniej
poziomu gruntu, poniej poziomu wody, a take
sprbowac wylecie w kosmos.
Poniewa nie da si przetestowa wszystkiego, przeprowadzenie podziau na
klasy rwnowanoci i uwzgldnienie warunkw brzegowych, tak jak w
powyszych przykadach, pozwoli storzy zadania testowe dla wartoci
krytycznych. Jest to najskuteczniejsza metoda zmniejszenia iloci testowania
do wykonania.
Jest niezmiernie wane, eby nauczy si wci poszukiwa warunkw
brzegowych w kadym oprogramowaniu, z ktrym ma si do czynienia.
Im wicej bdzie si szuka, tym wicej odkryje si warunkw
granicznych, a tym samym i znajdzie bdw.
Wewntrzne warunki graniczne
Normalne warunki graniczne wyej opisane jest bardzo atwo znale. S
opisane w specyfikacjach i rzucaj si w oczy, kiedy uywa si programu.
Niektre wewntrzne granice nie s widoczne dla uytkownika, ale
powinien je skontrolowa tester oprogramowania. Nazywa si je
wewntrznymi warunkami granicznymi albo warunkami granicznymi
podklas.
Nie musi si by programist ani umie czyta kodu rdowego, aby
identyfikowa te granice, ale potrzebna jest pewna oglna orientacja w
dziaaniu oprogramowania. Przykadami mog by potgi dwjki i tabela
ASCII. Testowany program moe mie jeszcze inne granice wewntrzne,
warto wic porozmawia z programistami, czy znaj jeszcze jakie inne
wewntrzne warunki graniczne, ktre wartoby przetestowa1.
Przykady opisane w ksice stosuj si w pierwszym rzdzie do interfejsu uytkownika dla

typowych aplikacji uytkowych. Analogiczne przykady mozna by znale take dla innych typw
oprogramowania, cznie z systemami wbudowanymi, dla interfejsu komunikacyjnego itd.
Potgi dwjki
Komputery i oprogramowanie oparte s na licznbach binarnych bitach
mogcych miec warto 0 lub 1, bajtach skadajcych si z omiu bitw,
sowach skadajcych si z czterech bajtw itd. Tablea 5.1 pokazuje czsto
uywane potgi dwjki i ich wartoci.
Tabela 5.1
Wybrane wartoci potg dwjki
Nazwa
Warto
Bit
0 lub 1
Powka bajtu
0-15
Bajt
0-255
Sowo
0-65 535 albo 0-4 294 967 295
Kilo
1024
Mega
1 048 576
Giga
1 073 741 824
Tera
1 099 511 627 776
Przedziay pokazane w tabeli 5.1 s list wartoci, ktre warto uwzgldni

przy testowaniu warotci granicznych. Zwykle nie znajduje si ich definicji
w specyfikacji produktu, czsto jednak s uywane wewntrznie przez
program.
Przykady potg dwjki
Potgi dwjki maj znaczenie przy testowaniu oprogramowania do
realizacji protokolw komunikacyjnych. Szeroko pasma, czyli zdolno
przesyowa nonika informacji, jest zawsze ograniczona. Zawsze jest
potrzeba, eby przesya informacj jeszcze szybciej. Z tego powodu
inynierownie usiuj upchn jak najwicej danych w kady meldunek
czy pakiet przesyowy.
Jednym ze sposobw zwikszenia przepustowoci czy jest zagszczenie
informacji.
Zamy, e w protokole komunikacyjnym jest 256 polece. Protok
mgby zezwala na wysyanie 15 najczstszych polece zakodowanych
w powce bajtu. Komendy z numerami 16 256 trzeba by wysya
zakodowane w cay bajt.
Uytkownik tego oprogramowania potrzebuje jedynie wiedzie, e moe

wysa 256 rnych polece i nie musi wiedzie, e oprogramowaniue
musi wykonywa specjalne wyliczenia na granicy pbajt/bajt.
Tworzc klasy rwnowanoci, naley uwzgldni warunki graniczne
wynikajce z potg dwjki. Jeli, na przykad, program przyjmuje dane o
wartoci od jednego do 1000, naley wczy do klasy wartosci
dozwolonych 1 i 1000, moe te 2 i 999. Aby pokry testami take granice
wynikajce z zasady potg dwjki, wcza si rwnie 14, 15 i 16 na granicy
p-bajtu i 254, 255 oraz 256 na granicy bajtu.
Tabela ASCII
Innym wartym uwzgldnienia warunkiem wewntrznej granicy jest tabela
znakw ASCII. Tabela 5.2. zawiera cz tabeli ASCII.
Tabela 5.2 Czciowa tabela znakw ASCII
Znak
Warto ASCII
Znak
Warto ASCII
warto zerowa
66
znak spacji
32
89
47
90
48
91
49
96
50
97
57
98
58
121
64
122

A
65
{
123
Zwrmy uwag, e tabela 5.2 nie jest cig list. Znaki od 0 do 9 maj
warotci ASCII od 48 do 57. Ukonik, /, wypada przed 0. Dwukropek,
:, wypada po 9. Due litery od A do Z maj warotci od 65 do 90.
Mae litery maj wartoci od 97 do 122. Wszystkie te wartoci mog
stanowi wewntrzne warunki graniczne.
Testujc oprogramowanie ktre przyjmuje tekstowe dane wejciowe albo
ktre dokonuje konwersji plikw tekstowych, warto przestudiowa tabel
ASCII i wzi pod uwag wynikajce z niej warunki graniczne przy
ustalaniu klas rwnowanoci. Na przykad testujc pole do wprowadzania
danych, ktre przyjmuje tylko znaki A Z i a z1, naley uwzgldni w
klasie wartoci niedozwolonych znaki bezporednio pod i bezporednio nad
A, Z, a i z: @, [, i {.
ASCII i Unicode
Cho kod ASCII jest nadal bardzo popularny jako metoda kodowania
znakw, stopniowo zastpuje go nowy standard zwany Unicode. Unicode
zosta stworzony przez konsorcjum Unicode w 1991 roku aby rozwiza
problemy zwizane z tym, e kod ASCII nie wystarcza na wszystkie znaki
istniejce we wszystkich pisanych jzykach.
Kod ASCII jest 8-bitowy i wystarcza wobec tego tylko na 256 rnych
znakw. Unicode uywa 16 bitw i wystarcza na 65536 znakw. Do dzi
wykorzystano okoo 39000 znakw, z czego ponad 21000 przypada na
znaki chiskie.
Warto domylna, warto pusta, spacja, warto zerowa, brak
danych
Innym rdem bdw jest sytuacja, kiedy program oczekuje danych
wejciowych, ale uytkownik nie wprowadza niczego, jedynie na przykad
naciska klawisz Enter. Ta sytuacja jest czsto przeoczona przy pisaniu
specyfikacji wymaga i zapomniana przez programistw, ale zdarza si
powszechnie podczas uytkowania programw.
Poprawnie dziaajce oprogramowanie jest w stanie poradzi sobie z t
sytuacj. Program moe posuy si wartoci domyln, czsto najnisz z
przedziau dozwolonych wartoci, albo wywietli zawiadomienie o awarii.
Okno dialogowe ustawie programu Paint w Windows (rysunek 5.6)
umieszcza wartoci domylne w polach Szeroko i Wysoko. Co si stanie,
jeli uytkownik usunie te wartoi, celowo lub przez przypadek?
1
Sprawa komplikuje si w wypadku jzykw uywajcych znakw spoza serii A B, na przykad

polskiego. Znaki legalne dla pola tekstowego bd wtedy znajdowa si rozsiane po wikszym
przedziale wartoci (przyp. tumacza).
Rysunek 5.6 Okno dialogowe ustawie programu Paint z wyzerowanymi

polami Szeroko i Wysoko.
Najlepiej byoby, aby program dostarczy jakie typowe wartoci domylne,
albo wywietli komunikat o bdzie. To wanie robi program Paint
(rysunek 5.7). Komunikat nie jest zbyt jasny, ale to odrbne zagadnienie.
Rysunek 5.7 Komunikat bdu wywietlony jeli nacisno si klawisz Enter z

wyzerowanymi polami Szeroko i Wysoko.
Zawsze naley storzy klas rwnowanoci dla wartoci domylnej,
pustej, znaku pustego, wartoci zerowej, zera albo braku danych.
Dla tych wartoci warto stworzy osobn klas, zamiast upycha je razem z
klas wartoci dozwolonych albo z klas wartoci niedozwolonych,
poniewa programy zwykle postpuj z nimi w specjalny sposb. Jest
prawdopodobne, e program wykonuje inn ciek kiedy wprowadzi si
warto domyln ni kiedy wprowadzi si niedozwolone wartoci - 0 albo
1. Jeli oczekuje si innego dziaania programu, dane te powinny mie
osobn klas rwnowanoci.
Dane nieprawidowe, bdne, mylne i mieci
Ostatnim rodzajem testowania danych jest uycie mieci, danych
bezuytecznych. Jest to przykad testu negatywnego. Kiedy ju sprawdzio
si, e program dziaa dla zada testowych pozytywnych, pora sign po
grubszy kaliber prawdziwe mieci.
Puryci mog si spiera, e nie jest to naprawd potrzebne, e skoro
przetestowao si wszystko, co opisalimy dotd, w tym dane niedozwolone,
to program bdzie dziaa poprawnie. W rzeczywistoci jednak moe si
przyda sprawdzenie, jak program poradzi sobie z zupelnie przypadkowymi
danymi.
Jeli wzi pod uwag, e wiele programw sprzedaje si dzi w setkach

milionw egzemplarzy, na pewno jaki procent uytkownikw posuy si
nimi nieprawidowo. Jeli w wyniku tego program ulegnie powanej awarii i
nastpi utrata danych, uytkownik nie bdzie obwinia siebie samego
bdzie wini oprogramowanie. Jeli program nie robi tego, czego od niego
oczekuj, to jest bd.
Tak wic moemy dobrze si zabawi podstawiajc programowi dane
nieprawidowe, bdne, mylne. Jeli program oczekuje liczb, podamy mu
litery. Jeli przyjmuje tylko liczby dodatnie, podamy mu ujemne. Jeli
dziaanie programu zaley od daty, sprawdzimy czy bdzie dziaal w roku
3000-ym. Bdziemy udawa, e mamy grube paluchy, naciskajc po kilka
klawiszy jednoczenie.
Nie ma innych zasad dla tego typu testowania po prostu chodzi o to, by
prbowac zama program. Trzeba by pomysowym, zoliwym i dobrze si
przy tym bawi.
Testowanie zmian stanw

Jak dotd testowalimy jedynie dane liczby, sowa, dane wejciowe i dane
wyjciowe. Teraz zaczniemy sprawdza, jak program przechodzi przez
rne swoje stany. Stan programu to jego aktualny stan lub tryb dziaania.
Spjrzmy na rysunki 5.8 i 5.9.
Rysunek 5.8 Program Paint w Windowsach w trybie rysowania owkiem.
Rysunek 5.7 Program Paint w Windowsach w trybie malowania

rozpryskiwaczem.
Rysunek 5.8 pokazuje program Paint w Windowsach w trybie rysowania

owkiem. Jest to stan pocztkowy po starcie programu. Zwrmy uwag,
e wybrawszy jako narzdzie owek, kursor przybiera ksztat owka, a na
ekranie rysuje si cienka linia. Rysunek 5.9 pokazuje ten sam program w
trybie malowania rozpryskiwaczem. W tym stanie podane s rozmiary
rozpryskiwacza, kursor wyglda jak puszka farby z rozpryskiwaczem, a linia
wyglda jak spryskana farb.
Spjrzmy bliej na rozmaite opcje, jakie oferuje program Paint wszystkie
narzdzia, pozycje menu, kolory itd. Kiedy wybiera si jedn z tych opcji i
program zmienia wygld, rodzaje dostpnych komend, dziaanie to znaczy
e zmieni si jego stan. Program wykonuje kod: zmienia wartoc kilku
bitw, przydziela warto kilku zmiennym, aduje jakie dane i zmienia
stan.
Tester musi przetestowa wszystkie stany programu i przejcia midzy
nimi.
Test przepywu przej midzy stanami programu
W rozdziale 3-im pokazano przykad, e testujc Kalkulator ma si do
czynienia z nieskoczon iloci kombinacji danych wejciowych dla
programu. Jednoczenie nauczylimy si w kolejnych rozdziaach, e aby
testowanie stao si moliwe, trzeba zmniejszyc ilo zada testowych
tworzc klasy rwnowanoci dla najwaniejszych grup wartoci.
Testowanie stanw i przej midzy nimi sprawia ten sam kopot. Zwykle da
si odwiedzi wszytkie stany (w kocu, gdyby si nie dao, mona by je po
prostu usun z programu). Kopot w tym, e z wyjtkiem rzeczywicie
najprostszych programw, zwykle nie da si przeby wszystkich moliwych
cieek do wszystkich stanw. Zoono oprogramowania, zwaszcza z
powodu bogactwa intefejsw uytkownika we wspczesnych aplikacjach,
stwarza tak wiele rnych wyborw i opcji, e ilo dostpnych cieek
ronie wykadniczo.
Ten problem przypomina dobrze znany problem komiwojaera: majc
okrelony zbir miast i odlegoci midzy nimi, znale najkrtsz z drg,
ktra przejdzie przez wszystkie miasta i wrci do punktu wyjcia. Gdyby
miast byo tylko pi, po dokonaniu oblicze mona stwierdzi, e
moliwych tras przez nie jest 120. Przejechanie wszystkich i zmierzenie ich
dugoci nie jest wic niewykonalne. Ale, jeli zadanie dotyczy setek lub
tysicy miast albo, w naszym przykadzie, setek albo tysicy stanw
programu problem staje si bardzo trudny do rozwizania.
Rozwizeniem (dla testowania, nie dla komiwojaera) jest zastosowanie
techniki podziau na klasy rwnowanoci stanw i przej midzy nimi.
Stwarza si w ten sposb ryzyko, bo nie przetestuje si wszystkiego, ale
mona je zredukowa dokonujc inteligentnych wyborw.
Stworzenie mapy przej stanw

Pierwszym krokiem bdzie stworzenie wanej mapy przej stanw
programu. Czasami taka mapa jest dostpna jako cz specyfikacji
produktu. Jeli tak jest, trzeba j przetestowa metodami statycznymi, jak to
opisano w rozdziale 4-ym Testowanie Specyfikacji. Jeli mapa przej
stanw nie istnieje, trzeba j bdzie zbudowa.
Istniej rne techniki zapisywania diagramw przej stanw programu.
Rysunek 5.10 pokazuje dwa przykady. Na jednym rysuje si prostokty i
strzaki, a drugim kka i strzaki1. Technika jest niewana, o ile wszyscy
czonkowie zespou umiej si ni posuy.
Rysunek 5.10 Diagramy przejc stanw mona rysowac na rne sposoby.

Diagramy przej stanw atwo staja si bardzo due. Czsto widzi si
cae ciany oklejone wydrukami diagramw. Istniej programy rysujce
takie diagramy warto si nimi posuy.
Mapa przej stanw powinna zawiera nastpujce elementy:
62. Kady unikalny stan w ktrym program
moe si znale. Prosta zasada brzmi jeli
trudno si zdecydowa, czy ma si do czynienia
z jednym czy dwoma odrbnymi stanami, to
zapewne s to dwa odrbne stany. Zawsze
mona pniej atwo poczy dwa stany z
powrotem w jeden, jeli to zaoenie okae si
niesuszne.
63. Dane wejciowe ktre powoduj przejcie z
jednego stanu do drugiego. Moe to by
nacinicie klawisza, dane z czujnika, dzwonek
telefonu itd. Stanu nie mona opuci bez
powodu. Ten powd wanie usiuje si tutaj
zidentyfikowa.
Oczywicie, rnica jest mniej ni kosmetyczna, w obu tych rnych technikach opisuje si stany i
ich przejcia w formie grafu. Rzeczywicie odmienn (i znacznie wygodniejsz) technik jest
natomiast opis w formie tabeli, gdzie rzdzy oznaczaj stany wyjciowe, kolumny stymulacj lub
dane wejciowe, a pola na przeciciu rzdw i kolumn stany docelowe (przyp. tumacza).
64. Wyprodukowane dane wyjciowe albo inna

zmiana warunkw przy przejciu ze stanu do
stanu. Moe to by na przykad wywietlenie
menu albo zestawu przyciskw, ustawienie flagi,
pojawienie si wydruku, wykonanie obliczenia
itd; wszystko, co dzieje si w trakcie przejcia z
jednego stanu w drugi.
Testujc przejcia stanw, zwykle robi si to w formie testowania metod
czarnej skrzynki, wobec czego nie musi si zna np. zmiennych w kodzie
programu, ktre ustawiane s w trakcie przej midzy stanami. Map
stanw programu nalepiej sprzdzic z punktu widzenia uytkownika.
Zmniejszenie iloci stanw i ich przej, ktre si bdzie testowa
Sporzdzenie mapy stanw dla duego produktu informatycznego to wielkie
przedsiwzicie. Jeli testuje si tylko cz produktu, np.podsystem,
wykonanie mapy stanw staje si atwiejsze. Kiedy mapa jest gotowa,
mona obejrze opis wszystkich stanw i przej midzy nimi i to jest
grony widok!
Gdyby mie do dyspozycji nieskoczon ilo czasu, mona by
przetestowa wszystkie cieki porwadzce przez diagram stanw nie
tylko przejcia midzy dwoma ssiednimi stanami, ale wszelkie moliwe
kombinacje przej od pocztku do koca, z rn iloci powtrze,
ptalmi itp. Podobdnie jak w problemie komiwojaera, nie da si
przetestowa wszystkich.
Jak podzia na klasy rwnowanoci stosuje si wobec danych, tak samo
mona ograniczy ilo zada testowych dla testw przej stanw. Jest na
to pi sposobw:
65. Odwiedzi kady stan przynajmniej jeden raz.
Niewane jak, wane aby si tam dosta.
66. Przetestowa przejcia ze stanu do stanu, ktre
wydaj si najczciej odwiedzane. To brzmi i
jest bardzo subiektywne, ale mona podeprze
si wiedz zdobyt, gdy przeprowadzao si
statyczn analiz metod czarnej skrzynki
(rozdzia 3) na specyfikacji produktu. Niektre
scenariusze zastosowa okazuj si by
wykonywane czciej ni inne i one musz
dziaa dobrze!
67. Przetestowa najrzadziej uywane cieki
midzy parami stanw by moe zostay one
przeoczone przez konstruktorw i programistw.
Tester bdzie jednym z pierwszych, ktry je
wyprbuje.
68. Przetestowa kady ze stanw awaryjnych oraz

powroty z nich. Wiele stanw awaryjnych
trudno jest wywoa. Niejednokrotnie
programici pisz kod dla obsugi rnych
awarii, ale nie s go w stanie przecie
przetestowa, std wiele bdw. Czsto
procedury obsugi bdw s niepoprawne,
komunikaty o bdach mylce, albo program nie
wraca do stanu normalnego we waciwy
sposb.
69. Przetestowa losowe zmiany stanw. Jeli ma
si do dyspozycji mape stanw programu,
mona w ni rzuca strzakami i potem testowa
przejcia od strzaki do strzaki. W rozdziale 14ym Automatyczne testowanie i narzdzia do
testowania znjaduj si informacje o tym, jak
zautomatyzowa losowe testowanie przej
stanw.
Co szczeglnie naley przetestowa
Kiedy si ju zidentyfikuje stany i przejcia midzy stanami, ktre chce si
przetestowa, mona przystpi do zdefiniowania zada testowych.
Testowanie stanw i przej midzy stanami oznacza sprawdzenie
wszystkich zmiennych okrelajcych stan: informacji, wartoci, funkcji itd.
wicych si z danym stanem lub zmieniajcych si przy przejciu od stanu
do stanu. Rysunek 5.11 pokazuje przykadowo program Paint w stanie
pocztkowym.
Rysunek 5.11 Pierwszy ekran programu Paint w stanie pocztkowym.

Oto lista wartoci zmiennych ktre charkteryzuj stan pocztkowy programu
Paint:
70. Okno wyglda tak, jak na rysunku 5.11.
71. Wymiary okna s takie jak podczas
poprzedniego uycia.
72. Obszar obrazu jest pusty.
73. Wywietlone jest menu do wyboru narzdzi,

koloru i pasek pokazujcy status.
74. Owek jest wybranym narzdziem.
75. Domylne kolory to czarny pierwszy plan i biae
to.
76. Tytu dokumentu jest bez tytuu.
Program Paint ma wiele, wiele innych zmiennych okrelajcych stan, ktre
mona by wzi pod uwag, ale podane przykady powinny wyjasni, na
czym polega zdefiniowanie stanu programu. Warto pamita, e tak samo
postpuje si identyfikujc stan programu niezalenie od tego, czy opis
stanu okrelaj zmienne tak widoczne jak okno lub okno dialogowe, czy
niewidoczne jak w wypadku stanw programu komunikacyjnego albo
aplikacji finansowej.
Dobrze jest przedyskutowa swoje przypuszczenia dotyczce stanw i
przej midzy nimi z autorami specyfikacji i z programistami. Mona od
nich uzyskac wgld w to, co dzieje si wewntrz programu.
Flaga sygnalizuje brudny dokument
Zmienne okrelajce stan mog by niewidoczne lub widoczne. Typowy
przykad to flaga sygnalizujca brudny dokument.
Kiedy dokument zostaje zaadowany do programu, takiego jak program
do przetwarzania tekstu albo program do malowania, wewntrzna
zmienna okrelajca stan, zwana flag brudnego dokumentu jest
wyzerowana i dokument jest w stanie czystym. Program pozostaje w
tym stanie dopty, dopki nie zostan dokonane jakie zmiany w
dokumencie. Dokument mona czyta i przewija warto zmiennej
pozostaje niezmieniona. Jak tylko jednak co zostanie napisane albo
dokument zostanie zmieniony w jakikolwiek inny sposb, program zmieni
swj stan na stan brudny.
Jeli chce si zamkn lub wyj z dokumentu w stanie czystym, odbdzie
si to bez przeszkd. Jeli dokument jest brudny, uytkownik otrzyma
komunikat z pytaniem, czy dokument naley zapisa przed wyjciem z
aplikacji.
Niektre programy s tak wyrafinowane, e jeli dokona si jakiej
zmiany, ktr potem si odwoa i dokument powrci do stanu
wyjciowego, to program powrci te do stanu czystego. Wyjcie z
programu jest wtedy moliwe bez pytania, czy chce si zapisa dokument.
Negatywne testowanie stanw
Wszystko co dotd zostao przeduskutowane dotyczyo testowania

pozytywnego. Przeglda si specyfikacj, szkicuje stany programu,
wyprbowuje liczne dozwolone warianty i upewnia si, e stany i przejcia
midzy stanami dziaaj. Drug stron medalu, tak samo jak przy testowaniu
danych, jest sprawdzenie czy program dziaa te wwczas, kiedy podda go
negatywnym zadaniom testowym. Przykady takich sytuacji to warunki
wycigu, powtrzenia, stres i obcienie.
Wycig i bdna synchronizacja w czasie
Wikszo wspczesnych systemw operacyjnych, zarwno dla
komputerw osobistych jak i dla sprztu specjalnego, jest zdolna do
wielozadaniowoci. Wielozadaniowo oznacza e system operacyjny jest
skonstruowany tak, by mc wykonywa wiele rnych procesw
rwnolegle. Te procesy to mog by odrbne programy uytkowe, jak
arkusz kalkulacyjny lub poczta komputerowa. Mog te by czciami tego
samego programu, jak na przykad wydruk w tle, gdy jednoczenie mona
wpisywa nowe sowa do programu przetwarzajcgo tekst.
Skonstruowanie wielozadaniowego systemu operacyjnego nie jest trywialne,
tak samo jak nie jest atwo zaprojektowa program uytkowy
wykorzystujcy wielozadaniowo. W systemie prawdziwie
wielozadaniowym niczego nie mona uwaa za pewnik. Program musi
sobie mc poradzi z przerwaniem nadchodzcym w kadym momencie,
by wykonywanym jednoczenie z nieznanymi, innymi programami, oraz
posugiwa si wsplnie z innymi programami dostpem do zasobw takich
jak pami, dysk, komunikacja i inne zasoby sprztowe.
Wszystko to prowadzi niekiedy do sytuacji zwanej wycigiem. Polega to na
tym, e kilka procesw jednoczenie ciga si do linii mety, jak jest np.
zawadnicie zasobem albo zapisanie wartoci w pamici, i w konsekwencji
dziaanie programu zaley od przypadkowej wygranej jednego z
procesw. Mwic oglnie, chodzi tu o z synchronizacj w czasie. Moe
si te zdarzy, e jeden proces przerwie wykonywanie drugiego procesu w
momencie, ktry nie by przewidziany.
Trudno jest zaplanowac testowanie nakierowane na wykrycie sytuacji
wycigu1, ale dobrym pocztkiem jest przyjrze si diagramowi zmian
stanw. Jakie zewntrzne czynniki mog przerwa kady stan? Co stanie
si, jeli potrzebne dane nie bd gotowe na czas albo bd zmieniane
przez jeden proces w momencie, kiedy drugi proces je czyta? Co bdzie,
jeli dane prowadzce do dwch rnych przej z aktualnego stanu
nadejd jednoczenie?
Autor uywa tutaj okrelenia wycig (race condition) na oznaczenie wszelkich bdw specyficznych
dla systemw czasu rzeczywistego. Jest to do pewne uoglnienie (w rzeczywsitoci wycig jest tylko
jednym z wielu typw takich bdw), ale bez znaczenia o tyle, e ksika i tak nie opisuje adnych
technik testowania specjalnych dla systemw czasu rzeczywistego.
Oto kilka przykadw sytuacji, ktre mog doprowadzi do zaistnienia

wycigu:
77. Zapisywanie tego samego dokumentu
jednoczenie przez dwa rne programy
78. Korzystanie przez rne programy ze wsplnej
drukarki, portu komunikacyjnego albo innego
urzdzenia peryferyjnego
79. Naciskanie klawiszy albo klikanie mysz w
czasie gdy aplikacja aduje si lub wanie
zmienia stan
80. Jednoczesne zamykanie lub otwieranie dwch
instancji tego samego programu
81. Jednoczesne zapisywanie w bazie danych przez
dwa rne programy
Moe to wszystko wydaje si zbdnie zawiymi testami, ale tak nie jest.
Oprogramowanie musi by dostatecznie odporne na bdy, eby poradzic
sobie z takimi sytuacjami. Wiele lat temu podobne sytuacje moe byy
niezwyke, ale dzi uytkownicy oczekuj, e programy czasu rzeczywistego
bd dziaa poprawnie.
Powtarzanie, obcienie i przecianie
Innymi rodzajami negatywnych testw stanw s powtarzanie, przecianie
i obcienie1. Maj one na celu wychwycenie bdw przy zmianie stanw,
pojawiajcych si w szczeglnych warunkach, ktrych programista nie
wzi pod uwag.
Testowanie powtarzalne polega na powtarzaniu tej samej operacji w kko
na okrgo. Moe to by co tak prostego jak wielokrotne otwieranie i
zamykanie programu. Mona te raz po raz zapisywa i z powrotem
adowa dane z pliku, albo w ogle powtarza wielkokrotnie jakiekolwiek
zadanie. Moe uda si trafi na bd ju po kilku powtrkach a moe
trzeba bdzie tysicy prb, eby problem si ujawni.
Pewne zamieszanie terminologiczne. Testy na obciaenie i przecienie zaliczaj si do testw

wydajnoci (jak szybko, duo itd. program pracuje), podczas gdy testowanie stanw jest metodyk
stosowan do wybierania zada testowych gwnie do testowania funkcjonalnego (czy program
wykonuje waciwe funkcje). Jedno z drugim niewiele ma wsplnego. Opisane w tym podrozdziale
testy wydajnoci znalazy si w rozdziale o testowaniu stanw raczej przez przypadek.
Gwnym celem testowania powtarzalnego jest poszukiwanie przeciekw

pamici1. Czsto spotykany bd pojawia si, kiedy fragment pamici
zostanie przydzielony programowi, ale nie zostanie potem uwolniony (lub
nie do koca), kiedy wykorzystujca t pami operacja zostanie ju
zakoczona. W kocu, po jakim czasie program zuyje ca dostpn
pami. Kady kto posugiwa si programem, ktry pocztkowo dziaa
dobrze, ale stopniowo zaczyna dziaa coraz wolniej i wolniej, albo po
jakim czasie zaczyna funkcjonowa niekonsekwentnie, zetkn si
przypuszczalnie wanie z problemem przecieku pamici. Testowanie
powtarzalne ma na celu znajdowanie i usunicie tego typu bdw.
Test przeciajcy polega na tym, e program zmusza si do dziaania w
niekorzystnych warunkach za mao pamici, za wolny mikroprocesor,
powolne modemy itd. Naley zorientowa si, od jakich zewntrznych
zasobw program jest uzaleniony. Testowanie przeciajce polega na
ograniczeniu tych zasobw do najzupeniejszego minimum. Staramy si po
prostu wygodzi program, zmuszajc go do pracy przy niedostatecznych
zasobach. Czy to nie przypomina testowania warunkw brzegowych? Jak
najbardziej.
Testowanie obciajce2 jest odwrotnoci testowania przeciajcego. W
czasie testowania przeciajcego staramy si wygodzi program; w
czasie testowania obciajcego adujemy w program tyle danych, ile tylko
si da. Przykladowo, kaemy programowi uywa najwikszych moliwych
plikw danych. Jeli program uywa urzdze peryferyjnych, jak drukarki
albo porty komunikacyjne, podcza si tyle ile si tylko da. Testujc serwer
internetowy majcy obsugiwa tysice jednoczesnych sesji, naley
wyprbowa wanie tysice jednoczesnych sesji. Naley przycisn
program, obsiy go ile si tylko da.
Nie zapominajmy, e take czas jest zmienn ktr mona wykorzysta do
testowania obciajcego. Wane jest, eby przetestowa dziaanie
programu przez dugi czas. Niektre typy programw powinny mc
funkcjonowa latami bez koniecznoci ponownego wczenia.
Oczywicie w praktyce mona poczy w jeden cig testowanie
powtarzalne, przeciajce i obciajce.
Ten rodzaj testowania, ktry autor nazywa testowaniem powtarzalnym, okrelany jest czsto jako
analiza dynamiczna. Jej celem jest znalezienie nie tylko przeciekw pamici, ale wszelkich bdw
typu niedozwolone skutki uboczne dziaania programu, ktrych symptomy ujawniaj si czsto
najwyraniej dopiero po upywie duszego czasu (przyp. tumacza).
2
Testowanie przeciajce definiuje si czsto jako testowanie dziaania programu w warunkach

obcienia wikszego ni maksymalne dozwolone (np. test centrali telefonicznej w sytuacji, gdy
wszyscy abonenci jednoczenie podnios sluchawki). Oczywicie, tego rodzaju wygodzenie
programu, jakie opisuje autor, jest skutecznym sposobem symulacji przecienia (cilej, wynikego z
przecienia braku zasobw) bez potrzeby kopotliwego generowania prawdziwego obcienia, ale nie
jest celem samym w sobie (przyp. tumacza).
Przy testowaniu powtarzalnym, przeciajcym i obciajcym trzeba

pamita o dwch sprawach:
82. Programici i kierownicy zespow mog nie
popiera usiowa zamania programu w taki
sposb. Bd si skary, e prawdziwi
uytkownicy nigdy nie bd obcia programu
a do tego stopnia. Krtka odpowied brzmi:
owszem, bd. Zadaniem testera jest upewni
si, czy program dziaa rwnie w takich
warunkach i zgosi bdy, jei nie dziaa1.
Rozdzia 18-y Raportowanie wynikw
wyjasnia, jak najlepiej zgasza i opisywa
znalezione bdy tak, eby zostay potraktowane
powanie i naprawione.
83. Zamykanie i otwieranie programu milion razy
jest przypuszczalnie niewykonalne, jeli robi to
rcznie. Podobnie, nieatwo bdzie znale i
zorganizowa grup kilku tysicy osb, eby
jednoczenie podczyy si do testowanej
aplikacji internetowej. Rozdzia 14 opisuje
automatyzacj testowania i zawiera wiele
informacji, jak mona przeprowadza testy
osigw bez koniecznoci angaowania osb do
rcznego wykonania tej pracy.
Inne techniki czarnej skrzynki

Pozostae typy technik czarnej skrzynki to nie s waciwie odrbne metody,
lecz raczej odmiany ju opisanych technik testowania danych i testowania
stanw2. Jeli dokonao si starannej identyfikacji klas rwnowanoci na
danych programu, sporzdzio szczegow map stanw programu i
sporzdzio na ich podstawie zadania testowe, znalazo si przypuszczalnie
wikszo bdw, jakie moe znale uytkownik.
Pozostay nam techniki dla znajdowania zbkanych bdw, ktre
zupenie jakby byy prawdziwymi, ywymi pluskwami wydaj si
porusza, kierowane wasnym, niezalenym umysem. Zajdowanie ich moe
wydawa si zadaniem nie stosujcym si do zasad zdrowego rozsdku, ale
chcc znale i usun kady, najlepiej ukryty bd, trzeba bdzie wykaza
si twrcz fantazj.
1
W zasadzie, tego rodzaju spr midzy testerami a programistami nie powinien mie miejsca: te
sprawy powinny by jednoznacznie rozstrzygnite przez specyfikacj wymaga. W praktyce,
specyfikacje bywaj notorycznie niedokadne zwaszcza jeli chodzi o okrelenie wymaga
dotyczcych osigw i wwczas intuicja tesera jak to opisuje autor moe czciowo zastpi
brakujcy opis wymaga (przyp. tumacza).
2
Istnieje wiele innych interesujcych technik czarnej skrzynki (m.in. bardzo skuteczne do
wychwytywania pewnych typw bdw testowanie syntaktyczne) ktrych ksika dla pocztkujcych
z koniecznoci nie opisuje (przyp. tumacza).
Zachowa si jak gupi uytkownik

Terminem politycznie poprawnym powinno by raczej niedowiadczony
uytkownik albo nowy uytkownik, ale w rzeczywistoci chodzi przecie o to
samo. Wystarczy posadzi przed komputerem osob, ktra programu
zupenie nie zna, a zobaczymy wkrtce jak usiuje zrobi rzeczy, ktre nam
do gowy nie przyszy w najmielszych marzeniach. Bdzie wprowadza do
programu dane, jakie nam nawet nie przyszy do gowy. Zmieni zdanie w
poowie wykonywania zadania, wycofa si i zrobi co innego. Przesurfuje
przez stron internetow, klikajc na przyciski, na ktre klika nie naley3.
Znajdzie bdy, ktre testerzy przeoczyli zupenie.
To moe by dla testera szalenie frustrujce, obserwowa kogo zupenie
pozbawionego dowiadczenia w testowaniu, kto w cigu piciu minut jest w
stanie spowodowa awari programu, ktry wczeniej testowao si
tygodniami. Jak on to robi? Po prostu nie stosuje si do adnych zasad i nie
robi adnych zaoe.
Warto wobec tego, konstruujc zadania testowe albo badajc program po raz
pierwszy, sprbowa wej w skr gupiego uytkownika. Sprbowa
odrzuci wszelkie zaoenia i przypuszczenia o tym, jak program powinien
dziaa. Mona sprbowa sprowadzi koleg, ktry nie jest w projekcie i
razem z nim wymyla szalone pomysy. Niczego nie przyjmowa za
pewnik. Tego typu zadania testowe dodane do specyfikacji bd stanowiy
cakiem pokan jej cz.
Szuka bdw tam, gdzie si je ju raz znalazo
S dwa powody, dla ktrcyh warto szuka bdw tam, gdzie si je ju
wczeniej znalazo.
Wygoda uytkowania i intuicyjno interfejsu, na ktrym nowy uytkownik zrobi to wszystko, zdaje
si pozostawia wiele do yczenia jak w rzeczywistoci rzecz ma si z wieloma programami (przyp.
tumacza).
84. Jak dowiedzielimy si w rozdziale 3-im, im

wicej bdw si znajduje, tym wicej bdw
tam si jeszcze ukrywa. Jeli znajduje si na
przykad duo bdw na grnych granicach
przedziaw w rnych funkcjach
oprogramowania, to warto powici wicej
uwagi testowaniu grnych granic przedziaw.
Oczywicie, to by si zrobio i tak, ale warto
dorzuci kilka dodatkowych zada testowych,
wiedzc, e mog okaza si skuteczne.
85. Wielu programistw naprawia tylko bd
opisany w raporcie bdu ani wicej, ani
mniej. Jeli si napisao, e wystartowanie,
zatrzymanie i ponowne wystartowanie programu
255 razy powoduje awari, to programista
przypuszczalnie to wanie naprawi. Moe
istnia tam gdzie przeciek pamici, ktry
programista znalaz i usun. Kiedy dostanie si
naprawiony program do ponownego
przetestowania, na pewno warto zrobic
dokadnie to samo 256 razy i wicej. Moe
gdzie ukrywa si jeszcze kolejny przeciek
pamici?
Posucha wasnego dowiadczenia, intuicji i przeczu
Nie ma lepszego sposobu eby sta si lepszym testerem ni zbiera
dowiadczenie. Nie ma lepszej metody nauczenia si ni testujc, i nie ma
skuteczniejszej lekcji ni pierwszy telefon od klienta, co znalaz bd w
programie, ktry wanie skonczyo si testowa.
Nie mona nauczy dowiadczenia i intuicji, trzeba je zdobywa samemu.
Mona zastosowa opisane dotd techniki i przegapi powane bdy, taka
jest natura tej pracy. Zdobywajc dowiadczenie zawodowe, uczymy si
rnych rodzajw i rnych wielkoci produktw, zbieramy rozmaite
wskazwki, ktre pokieruj nas w stron trudnych do znalezienia bdw. Po
jakim czasie jest si w stanie zasi do testowania nowego kawaka
oprogramowania i szybko znajdowa bdy, ktrych inni by nie zauwayli.
Warto zapisywa, co dziaa, a co nie, prbowa rnych sposobw. Jeli co
wyglda podejrzanie, zawsze warto si temu przypatrze dokadniej. Warto
posucha wasnych przeczu, dopki nie oka si faszywe.
Dowiadczenie to nazwa, jak ludzie nadaj swoim pomykom.
Oscar Wilde
Podsumowanie
To by dugi rozdzia. Dynamiczne testowanie metodami czarnej skrzynki

jest obszern dziedzin. Dla nowych testerw, to mg by najwaniejszy
rozdzia z caej ksiki. Prawdobodobnie w czasie wywiadu u pracodawcy
albo w pierwszym dniu pracy otrzyma si polecenie, eby przetestwoa
program. Stosujc techniki z tego rozdziau, bdzie mona od razu
znajdowa bdy.
Nie naley jednak przypuszcza, e to ju wszystko, co testowanie
oprogramowania ma do zaoferowania. Gdyby tak byo, mona by przesta
czyta i zlekceway pozostae rozdziay ksiki. Testowanie dynamiczne
metodami czarnej skrzynki to dopiero pocztek. Test oprogramowania
wymaga wicej wiedzy, a my dopieromy zaczli j zdobywa.
Dwa kolejne rozdziay wprowadzaj do testowania w sytuacji, kiedy ma si
dostp do kodu i mona zobaczyc, jak program dziaa i co robi na
najniszym poziomie. Poznane techniki czarnej skrzynki nadal s przydatne,
ale mona je uzupeni nowymi technikami, ktre pozwol sta si jeszcze
skuteczniejszymi testerami oprogramowania.
Pytania
1.Prawda czy fasz: czy da si wykonywa dynamiczne testowanie
metodami czarnej skrzynki bez specyfikacji produktu albo specyfikacji
wymaga?
2.Kiedy testuje si zdolno programu do robienia wydrukw, jakie oglne,
negatywne zadania testowe s waciwe?
3.Wystartuj Notatnik Windows i wybierz funkcj Drukuj z menu Plik.
Pojawia si wtedy okno dialogowe pokazane na rysunku 5.12. Jakie
warunki brzegowe istniej dla funkcji Zakres w dolnym, lewym rogu
okna?
Rysunek 5.12 Okno dialogowe funkcji Drukuj z funkcj wyboru zakresu.

4. Mamy pole do wprowadzania 10-cyfrowego
kodu pocztowego, jak na rysunku 5.13. Jakie
klasy rwnowanoci mona zastosowa do jego
testowania?
Rysunek 5.13 Przykadowe pole do wprowadzania 5-cyfrowego kodu

pocztowego.
5. Prawda czy fasz: przejcie wszystkich stanw
programu gwarantuje rwnie, e przeszo si
wszystkie przejcia midzy nimi.
6. Istnieje wiele sposobw rysowania diagramw
przejcia stanw, ale kady z nich pokazuje trzy
rzeczy. Jakie?
7. Podaj niektre z wartoci zmiennych w stanie
pocztkowym Kalkulatora Windowsw.
8. Co robi si z programem, chcc odkry bdy w
synchronizacji w czasie (wycig)?
9. Prawda czy fasz: jednoczesne wykonywanie
testowania na obcienie i na przecienie jest
niedopuszczalne.
Rozdzia 6
Analiza kodu
W TYM ROZDZIALE
Statyczne testowanie metodami szklanej skrzynki: badanie
projektu konstrukcji i kodu
Formalne przegldy
Standardy i reguy programowania
Lista kontrolna do przegldw kodu
Testowanie oprogramowania nie ogranicza si do tego, by traktowa
specyfikacje lub program jak czarn skrzynk, jak to opisne zostalo w
rozdziale 4-ym Badanie specyfikacji oraz w rozdziale 5-ym Test z
klapkami na oczach. Znajc troch programowanie, nawet niewiele, mona
testowa bezporednio projekt konstrukcji systemu oraz kod rdowy.
W wielu branach te metoda weryfikacji jest o wiele mniej powszechna ni
testowanie metodami czarnej skrzynki. Tam, gdzie wytwarza si
oprogramowanie dla zastosowa wojskowych, finansowcyh, kontroli
procesw przemysowych oraz dla zastosowa medycznych albo jeli ma
si szczcie pracowa w organizacji stosujcej zdyscyplinowane metody
wytwarzania - weryfikacja produktu na poziomie projektu oraz kodu jest
powszechna.
Ten rozdzia jest wprowadzeniem do podstaw weryfikacji projektu
konstrukcji i kodu rdowego. Nie jest to zwykle zadanie dla
pocztkujcego testera, ale przypuszczalnie majc pewne umiejtnoci w
programowaniu tester zetknie si z t dziedzin1.
Najwaniejsze punkty w tym rozdziale to:
86. Zalety statycznego testu metodami szklanej
skrzynki
87. Rne rodzaje statycznych przegldw metod
szklanej skrzynki
88. Standardy i reguy kodowania
89. Oglne metody inspekcji kodu w poszukiwaniu
bdw
Statyczne testowanie metodami szklanej skrzynki: badanie

projektu konstrukcji i kodu
Autor wychodzi z zaoenia, e typowy tester nie jest wyksztaconym programist. Oczywicie, nie
musi tak by (przyp. tumacza).
Przypomnijmy sobie definicje testowania statycznego i testowania

metodami szklanej skrzynki z rozdziau 4-ego. Testowanie statyczne odnosie
si do testowania czego co nie jest dziaajcym kodem do badania i
inspekcji. Testowanie metodami szklanej skrzynki (albo biaej skrzynki)
oznacza, e ma si dostp do wntrza konstrukcji, do kodu programu.
Tak wic statyczne testowanie metodami szklanej skrzynki jest procesem
starannego i metodycznego przegldu projektu konstrukcji, architektury lub
kodu rdowego w celu znalezienia bdw bez uruchamiania programu.
Czasami uywa si te nazwy analiza strukturalna.
Motywy stosowania statycznego testu metodami szklanej skrzynki s dwa:
znajdowa bdy jak najwczeniej oraz znajdowa bdy ktre byoby trudno
zidentyfikowa i zlokalizowa przy pomocy dynamicznego testowania
metodami czarnej skrzynki. Im bardziej osoby dokonujce przegldw s
niezalene od zespou wytwarzajcego kod, tym lepiej, zwaszcza jeli
znalizy dokonuje si na niskim poziomie i wczenie w cyklu wytwarzania.
Dodatkowym zyskiem z przeprowadzania statycznego testu metodami
szklanej skrzynki jest to, e w jego trakcie zesp testerw czsto znajduje
wiele pomysw, ktre daje si potem zastosowa do testowania
dynamicznego. Nawet nie wnikajc w zawie szczegy kodu, uczestnictwo
w przegldach pozwala zidentyfikowa obszary programu ktre s zawie i
gdzie czsto pojawiaj si bdy.
Zespoy projektowe rnie dziel si odpowiedzialnoci za statyczne
testowanie metodami szklanej skrzynki. W niektrych zespoach
odpowiedzialno za zorganizowanie przegldw spoczywa na
programistach, ktrzy zapraszaj na nie testerw w roli niezalenych
obserwatorw. W innych zespoach odpowiedzialno spoczywa na
testerach, ktrzy zapraszaj programistw na przegldy. Kade z tych
podej moe dziaa dobrze. Zesp projektowy ma prawo wybra to, co
mu najlepiej odpowiada.
Statyczny test metodami szklanej skrzynki ma jedn wad nie zawsze si
go przeprowadza. Wiele zespow ulego przesdom, e ta technika jest zbyt
czasochonna, zbyt kosztowna i niezbyt produktywna. Wszystko to jest
nieprawd w porwnaniu z kosztami testowania, znajdowania niektrych i
pomijania wielu bdw na samym kocu projektw. Kopot w tym, e
gwne zadanie programisty wiele osb rozumie jako pisanie linijek kodu i
kade zadanie, ktre zmniejsza tak rozumian efektywno wydaje si
spowalnia cay proces powstawania oprogramowania.
Na szczcie, czasy si zmieniaj. Coraz wicej przedsibiorstw zdaje sobie

spraw z zyskw pyncych z wczesnego testowania i zatrudnia oraz szkoli
swoich programistw i testerw, aby wykonywali testowanie metodami
szklanej skrzynki. Nie jest to cisa matematyka (o ile kto nie testuje
implementacji algorytmw matematycznych), ale eby zacz j stosowa
przydaje si znajomo kilku podstawowych technik. Jeli kogo interesuje
pjcie jeszcze dalej, moliwoci s olbrzymie.
Formalne przegldy
Przegld formalny to proces, ktry steruje statycznym testowaniem
metodami szklanej skrzynki. Przegld formalny moe mie rozmaite formy
poczwszy od prostego spotkania midzy dwoma programistami a po
szczegow, rygorystyczn inspekcj kodu1.
Cztery elementy wyrniaj przegldy formalne:
90. Identyfikacja problemw. Celem przegldw
jest znalezienie bdw nie tylko tego, co jest
zrealizowane niepoprawnie, ale rwnie tego,
czego brakuje. Krytyk kieruje si na kod
(przedmiot przegldu), a nie na osob autora.
Uczestnicy nie powinni traktowa krytyki
osobicie. Poczucie wielkoci, emocje i
wraliwe uczucia trzeba zostawi za drzwiami.
91. Postpowanie wedle zasad. Naley postpowa
wedle przyjtego zestawu zasad. Te zasady
mog np. okrela iloc kodu ktry podlega
przegldowi (zwykle kilkaset linii), ile czasu
naley powici (kilka godzin), na co naley
zwrci uwag itd. Wane jest, aby uczestnicy
znali swoje role i czego si od nich oczekuje.
Dziki temu przegldy przebiegaj sprawniej.
92. Przygotowanie. Oczekuje si, e kady
uczestnik bdzie przygotowany do przegldu.
Zalenie od rodzaju przegldu, uczestnicy mog
mie rne role i musz je zna, aby mc je w
czasie przegldu realizowa. Wikszo
problemw znalezionych w procesie przegldu
Czytelniku, wybacz, ale oto znowu nomenklatura autora rni si od powszechnie przyjtej. Ot
zwykle inspekcje i przegldy formalne to synomimy, okrelajce przegldy dokonywane szczegowo,
rygorystycznie, wedug opisanego procesu, natomiast caa reszta to po prostu przegldy, albo
przegldy nieformalne. Nie ma to wikszego znaczenia, ale dobrze orientowa si w tym
nomenklaturowym chaosie, eby rozumie o czym jest mowa.
Warto te pamita, e nie istnieje powszechnie przyjta klasyfikacja rnych typw przegldw i
podane przez autora definicje przegldu koleeskiego, rcznego sprawdzianu i inspekcji rni si w
znajduje si w czasie przygotowa, a nie
podczas samego przegldu2.
93. Pisanie raportu. Grupa dokonujca przegldu

musi stworzy pisemny raport podsumowujcy
wyniki przegldu. Raport musi by dostpny dla
caego zespou projektowego. Jest istotne aby
wszyscy poznali wyniki przygldu: ile
znaleziono bdw, gdzie itp.
Najwaniejsze dla formalnych przegldw jest to, e odbywaj si wedug
ustalonego procesu. Przypadkowe zebra si razem i przelecie si przez
troch kodu nie wystarcza, a nawet moe okaza si przeciwksuteczne.
Jeli proces odbywa si baaganiarsko, wiele bdw pozostanie
nieznalezionych, a uczestnicy bd mieli poczucie zmarnowango czasu.
Waciwie realizowane, przegldy mog by wymienit metod wczesnego
znajdowania bdw. Wyobramy je sobie jako pierwsze siatki na motyle
(rysuek 6.1), ktre chwytaj najwiksze pluskwy na samym pocztku
procesu wytwarzania. Oczywiciem mniejsze pluskwy przedostan si, ale
zostan schwytane w kolejnych fazach testowania, stosujcych siatki o coraz
mniejszych oczkach.
Rysunek 6.1 Formalne przegldy s jak pierwsze w serii siatek do apania

bdw pluskiew.
Oprcz znajdowania problemw i bdw, formalne przegldy przynosz
szereg porednich korzyci.
szczegach od definicji innych autorw, czy te od nazewnictwa stosowanego w przedsibiorstwach

(przyp. tumacza).
2
Wywd byby janiejszy, gdyby sowo przegld stosowa tylko do caego procesu, za zebranie na
ktrym spisuje si znalezione bdy nazywa zebraniem przegldowym, a nie mylco rwnie
przegldem (przyp. tumacza)..
94. Komunikacja. Przekazuje si sobie informacje,

ktrych nie ma w oficjalnych raportach. Na
przykad, testerzy zajmujcy si testowaniem
metodami czarnej skrzynki mog uzyska cenny
wgld w obszary moliwych kopotw.
Pocztkujcy programici mog nauczy si
nowych technik od dowiadczonych
programistw. Kierownictwo moe uzyska
lepsze wyczucie, jak projekt posuwa si do
przodu.
95. Jako. Kod napisany przez programist
kontroluje si szczegowo, linijka po linijce,
funkcja za funkcj co czsto powoduje, e
programici staj si staranniejsi. To nie znaczy
e w przeciwnym razie byliby niechlujni po
prostu wiedzc, e kod bdzie szczegowo
skontrolowany przez kolegw, odruchowo
podejmuje si dodatkowy wyciek eby unika
bdw.
96. Powstanie ducha zespou. Dobrze
zorganizowane i poprowadzone, przegldy
mog sta si forum, gdzie testerzy i
programici ucz si lepiej nawzajem rozumie
swoj prac i potrzeby, i szanowa nawzajem
swoje umiejtnoci.
97. Rozwizania. Moe uda si znale
rozwizania dla trudnych problemw, cho nie
wszystkie typy przegldw pozwalaj na ich
dyskutowanie w czasie zebrania przegldowego.
Moe by lepiej, eby taka dyskusja odbywaa
si poza zebraniem.
Te porednie korzyci zdarzaj si, ale nie mona na nie liczy z pewnoci.
Zdarza si, e z rnych powodw czonkowie zespou pracuj w
izolacji od siebie. Formalne przegldy to wietny sposb, eby zebra ich
razem w jednym pokoju, dyskutujcych wsplny problem.
Kontrole koleeskie
Najatwiej zebra razem czonw zespou i zleci im wykonanie pierwszego
wsplnego przegldu w postaci przegldu koleeskiego, ktry jest
najprostsz form przegldu. Te metoda jest w istocie rozmow w stylu
poka mi jak to zrobie, to ja ci poka jak ja to zrobiem.
Przegldy koleeskie czsto odbywaj si tylko z udziaem programisty

autora kodu oraz jednego czy dwch testerw albo programistw w roli
inspektorw. Ta niewielka grupa po prostu wsplnie przeglda kod i
poszukuje problemw i opuszcze. Aby mie pewno e przegld bdzie
wydajny (i nie zamieni si w przerw na kaw), wszystkie cztery elementy
formalnego przegldu powinny by zastosowane: szukanie problemw,
postpowanie wedug zasad, przygotowanie do przegldu i napisanie
raportu. Poniewa przegldy koleeskie s nieformalne, czsto omija si
niektre z tych elementw. Jednak samo zebranie si razem aby
przedyskutowac kod niejednokrotnie wystarcza, eby znale bdy1.
Rczny sprawdzian
Rczne sprawdziany s krokiem wzwy pod wzgldem poziomu formalizmu
w porwnaniu z przegldami koleeskimi. Rczny sprwadzian polega na
tym, e programista, ktry napisa kod, prezentuje kod programu na
piechot niewielkiej grupie programistw i testerw. Insepktorzy powinni
zawczasu otrzyma kopie kodu, tak eby mogli go skontrolowa i zapisa
komentarze i pytania, ktre chc zada w trakcie przegldu. Wane, by cho
jeden z inspektorw by dowiadczonym programist.
Prezentator czyta kod linijka po linijce lub funkcja po funkcji i wyjania, co
i dlaczego kod wykonuje. Inspektorzy suchaj i pytaj o wszystko, co budzi
wtpliwoci. Poniewa w rcznym sprawdzianie z reguy uczestniczy wicej
osb ni w kontroli koleeskiej, jest bardzo wane by wszyscy byli do
zebrania przygotowani i by przestrzega regu. Wane jest te, by po
ukoczonym sprawdzianie zosta napisany raport, streszczajcy jakie bdy
zidentyfikowano i jak planuje si je skorygowa.
Inspekcje
Inspekcje s najbardziej formalnym rodzajem przegldw. Maj precyzyjn
struktur i wymagaj, eby wszyscy uczestnicy byli odpowiednio
wyszkoleni. Inspekcje tym rnia si od przegldw koleeskich i rcznych
sprawdzianw, e osoba ktra przedstawia kod, zwana prezentatorem, nie
jest autorem kodu. Ta sytuacja wymaga, by kto inny oprcz autora rozumia
przedstawiany materia w szczegach.
Istnieje modna ostatnio metoda wytwarzania kodu, zwana programowaniem

ekstremalnym (extreme programming, xP), polegajca na tym, e programici pracuj w parach: jeden
pisze kod, drugi dokonuje na bieco koleeskiej inspekcji powstajcego kodu; po jakim czasie
zamieniaj si rolami (przyp. tumacza).
Pozostali uczestnicy inspekcji nazywani s inspektorami1. Kady otrzymuje

odrbne zadanie zanalizowania kodu z innego punktu widzenia, np.
uytkownika, testera, albo osoby zajmujcej si konserwacj
oprogramowania. To pozwala uwzgldni w czasie inspekcji rne aspekty
produktu i czsto pozwala zidentyfikowa rne rodzaje bdw. Jeden z
inspektorw otrzymuje nawet zadanie inspekcji kodu od tyu to znaczy od
koca do pocztku aby upewni si czy materia zosta zrealizowany
jednolicie i w peni.
Dwaj inspektorzy otrzymuja rwnie rol przewodniczcego i sekretarza,
ktrzy odpowiadaj za przestrzeganie regu i pynny przebieg caego
procesu.
Po zebraniu przegldowym inspektorzy mog zebra si ponownie, aby
przedyskutowa znalezione problemy i wsplnie z przewodniczcym
przygotowa pisemny raport idnetyfikujcy konieczne zmiany dla
naprawienia bdw. Programista nastpnie przeprowadza te zmiany, a
przewodniczcy sprawdza, czy zostay zrobione waciwie. Zalenie od
zakresu i wielkoci zmian oraz od stopnia krytycznoci oprogramowania,
moe zosta zarzdzona kolejna inspekcja dla znalezienia pozostaych
bdw.
Stwierdzono, e inspekcje s bardzo skuteczne w znajdowaniu bdw,
zwaszcza w dokumentacji projektu konstrukcji i w kodzie. Popularno
inspekcji wzrasta, gdy coraz wicej przedsibiortstw i zespow
projektowych odkrywa ich zalety.
Standardy i reguy programowania

W trakcie formalnych przegldw inspektorzy poszukuj problemw i
opuszcze w kodzie programu. Istnieje wiele typowych bdw, przy
ktrych program po prostu nie bdzie dziaa poprawnie. Najlepjej znajduje
si je poprzez starann analiz kodu dowiadczeni programici i testerzy
zwykle umiej to robi.
Istnieje te typ problemw, gdzie kod wprawdzie dziaaby poprawnie, ale
nie jest napisany zgodnie ze standardem lub norm. Mona to porwna ze
zdaniem, ktre wprawdzie da si zrozumie i przekazuje informacj, ale nie
spenia zasad gramatyki i skadni jzyka polskiego. Standardy to s ustalone,
zapisane, wymagane zestawy regu co wolno, a czego nie wolno. Reguy
to s sugerowane, praktyczne wskazwki, rekomendacje, zlecane sposoby.
Stanardy nie dozwalaj wyjtkw. Reguy nie s rwnie obowizujce.
W jzyku angielskim inspektorzy w procesie przegldu nazywani s tu reviewers, a inspektorzy

uczestniczcy w inspekcji inspectors. Po polsku podobne rozrnienie byoby jzykowo bardzo
niezrczne, dlatego zachowano jednakow nazw dla obu (przyp. tumacza).
Moe to brzmie dziwnie, e fragment oprogramowania moe dziaa, moe

by nawet przetestowany i bardzo stabilny, a mimo to niepoprawny,
poniewa nie spenia innych kryteriw. Istniej trzy gwne powody, dla
ktrych przestrzega si standardw i regu:
98. Niezawodno. Udowodniono, e kod napisany
zgodnie ze standardem lub zestawem regu jest
bardziej niezawodny i ma mniej bdw ni kod
nie przestrzegajcy standardw.
99. Czytelno/atwo konserwacji. Kod
speniajcy standardy i reguy jest atwiej
przeczyta, zrozumie i konserwowa.
100.Przenono. Kod musi by niekiedy
przeniesiony na inny sprzt albo skompilowany
innym kompilatorem. Jeli jest zgodny ze
standardem, bdzie przypuszczalnie atwiej
moe nawet zupenie bezbolenie przenie
kod na inna platform.
Wymagania projektu mog niekiedy domaga si bezwzgldnego
przestrzegania zasad midzynarodowego albo krajowego standardu, albo
tylko zaleca przestrzeganie wewntrznch zasad zespou projektowego. Co
jest wane, to stosowa jaki zestaw regu i weryfikowa jego przestrzeganie
w trakcie formalnych przegldw.
Przykady standardw i regu programowania
Rysunek 6.2 pokazuje przykad standardu programowania, ktry okrela
zasady stosowania instrukcji goto, while i if-else w jzyku C.
Niewaciwe uywanie tych instrukcji czsto prowadzi do bdw w kodzie,
i wikszoc standardw programowania podaje zasady posugiwania si
nimi.
TEMAT: 3.05 Ograniczenia zastsowania struktur kontrolnych

STANDARD
Nie naley uywa instrukcji go to (jak rnie etykiet).
Ptla while powinna by stosowana zamiast ptli do-while, z wyjtkiem
miejsc gdzie logika problemu jednoznacznie wymaga aby wntrze ptli
zostao wykonane chocia raz niezalenie od wartoci warunku
kontrolnego ptli.
Tam gdzie pojedyncze if-else moe zastpi continue, naley uywa ifelse.
UZASADNIENIE
Instrukcja go to jest zabroniona, poniewa stwierdzono empirycznie
korelacj jej uycia z wystpowaniem bdw i trudnym do zrozumienia
kodem, oraz z powodu abstrakcyjnego, e algorytmy powinny by wyraone
w postaci struktur uatwiajcych skontrolowanie zgodnoci programu ze
struktur realizowanego procesu.
Uycia do-while odradza si z tego powodu, e ptla powinna by
kodowana tak, eby moga byc atwo ominita, to znaczy kontrola
warunku ptli powinna by dokonywana przed wejciem do wntrza ptli.
Rysunek 6.2 Przykad standardw kodowania wyjaniajcy jak naley

uywa kilku struktur kontrolnych jzyka (Dostosowane z Zasady
programowania w C++, Thomas Plum i Dan Saks, 1991, Plum Hall).
Pokazany tutaj standard skada si z czterech gwnych czci:
101.Tytu opisuje czego standard dotyczy.
102.Standard (albo regua) opisuje tre
standardu/reguy wyjaniajc szczegowo co
jest, a co nie jest dozwolone.
103.Uzasadnienie wyjania motywacj standardu
tak aby programista mg zrozumie czemu
nakazyana praktyka jest korzystna.
104.Przykad pokazuje proste fragmenty kodu
stosujcego si do standardu. Nie zawsze jest to
konieczne.
Rysunek 6.3 jest opisem reguy stosowania funkcji jzyka C w jzyku C++.
Zwrmy uwag na rnice w sformuowaniach. Tutaj zaczyna si od
naley stara si unika. Reguy nie s tak surowe jak standardy i
pozwalaj na pewn elastyczno w razie potrzeby.

TEMAT: 7.02
C_problemy Problemowe dziedziny z C
REGUA
Naley stara si unika aspektw jzyka C niezgodnych w
programowaniem w C++
1. Nie uywa setimp i longimp jeli istniej obiekty z destruktorami,
ktre mogyby powsta midzy wykonaniem setimp a wykonaniem
longimp.
2. Nie stosowa makro offsetof z wyjtkiem kiedy stosuje si do
czonkw tej samej struktury prostej.
3. Nie miesza I/O w stylu C (uywajcego stdio.h) z I/O w stylu C++
(uywajcego iostream.h lub stream.h) w tym samym pliku.
4. Unika stosowania funkcji jzyka C takich jak memcpy albo memcap
dla kopiowania albo porwnywania obiektw innych typw ni wektor
znakw lub prosta struktura.
5. Unika makro NULL z jzyka C; uywa w zamian 0.
UZASADNIENIE
Kady z tych aspektw dotyczy obszaru tradycyjnych zastosowa z jzyka
C, ktre stwarzaj pewne problemy w C++.
Rysunek 6.3 Przykad regu kodowania pokazuje jak stosowa pewne

aspekty C w C++ (Dostosowane z Zasady programowania w C++, Thomas
Plum i Dan Saks, 1991, Plum Hall).
To kwestia stylu
Istniej standardy, istniej reguy, a wreszcie jest te styl. Z punktu
widzenia jakoci i testu oprogramowania, styl jest bez znaczenia.
Kady programista, tak samo jak kady pisarz albo malarz, ma swj
wany niepowtarzalny styl. Nawet kiedy przestrzegane s reguy, a uycie
konstrukcji jest z nimi zgodne, zwykle nadal jest atwo powiedzie, kto
jest autorem danego oprogramowania.
Czynnikiem wyrniajcym jest styl. W programowaniu moe to by na
przykad dugo komentarzy albo nazewnictwo zmiennych, albo jakiej
formy s wcicia w kodzie ptli. To jest specyficzny wygld kodu.
Niektre zespoy, w zapale stwarzania standardw i regu, zaczynaj
czasem krytykowa styl kodu. Tester oprogramowania powinien trzyma
si z dala od takich dyskusji. Kiedy wykonuje si przegldy fragmentw
oprogramowania, naley ograniczy uwagi do tego co jest bdne, czego
brakuje albo co nie jest zgodne z pisanymi standardami czy reguami.
Naley sobie samemu zada pytanie - czy ma si naprawd do czynienia z
bdem czy te z rnic opinii, z kwesti stylu. W drugim wypadku nie
moe by mowy o bdzie.
Skd wzi standardy?
Jeli projekt musi stosowa si do istniejcych standardw, albo jeli tylko
chce si porwna kod ze standardami, do dyspozycji ma si kilka rde.
Narodowe i midzynarodowe standardy w dziedzinie jzykw

programowania i technologii informatycznych mona znale:
105.American National Standard Institute (ANSI),
www.ansi.org
106.International Engineering Consortium (IEC),
www.iec.org
107.International Organisation for Standardisation
(ISO), www.iso.ch
108.National Committee for Information
Technology Standards (NCITS), www.ncits.org
Mona te znale dokumentacj regu programowania i opisy najlepszych
praktyk w nastpujcych organizacjach:
109.Association for Computing Machinery (ACM),
www.acm.org
110.Institute of Electrical and Electronics Engineers,
Inc (IEEE), www.ieee.org
Czsto mona te uzyska informacj od producenta oprogramowania.
Wielu producentw publikuje standardy do wasnego oprogramowania i
mona je kupowa za niewielk opat.
Lista kontrolna do przegldw kodu

Pozostaa cz tego rozdziau zajmuje si problemami, ktrych naley
szuka dokonujc formalnego przegldu kodu. Te listy kontrolne1 stosuje si
oprcz porwnywania kodu ze standardami oraz oprcz kontroli czy kod
spenia wymagania konstrukcyjne.
Aby rzeczywicie rozumie i stosowa opisane poniej punkty kontrolne,
naley mie pewne dowiadczenie z programowaniem. Jeli nie ma si
dosy dowiadczenia, warto przeczyta ksik dla pocztkujcych, na
przykad Jak nauczy si samemu programowania w 24 godziny z
wydawnictwa Sams Publishing2 zanim podejmie si prby szczegowej
analizy kodu programu.
Bdy w referencjach zmiennych
Zaczone tu listy kontrolne zostay zaadaptowane z Software Testing in the Real World: Improving
the Process, strony 198-201. 1999 by Edward Kit. Uyte za zezwoleniem Pearson Education
Limited, Lodyn. Wszelkie prawa zastrzeone (przyp. autora).
2
Obawiam si, e taka wiedza moe okaza si dramatycznie niewystarczajca (przyp. tumacza).
Bdy w referowaniu zmiennych czsto spowodowane s uyciem zmiennej,

staej, wektoru, cigu znakw albo rekordu ktre nie zostay
zainicjalizowane w sposb pasujcy do trybu czy sposobu uycia i
referowania.
111.Czy istnieje referencja do niezainicjalizowanej
zmiennej? Szukanie opuszcze jest tu rwnie
wane jak szukanie bdw.
112.Czy indeks wskazyjcy pozycj w wektorze
znakw albo w cigu znakw zawsze jest w
zakresie zgodnym z rozmiarami wektora?
113.Czy istniej jakie moliwe bdy o jeden w
indeksowych referencjach do wektorw?
Przypomnijmy sobie listing 5.1 z rozdziau 5ego.
114.Czy uywa si zmiennych tam gdzie staa
byaby odpowiedniejsza, na przykad do kontroli
granic wektora?
115.Czy zmiennej jest kiedykolwiek przydzielona
warto innego typu ni zmienna? Na przykad,
czy kod przydziela warto
zmiennoprzecinkow zmiennej
cakowitoliczbowej?
116.Czy pami, do ktrej referuj wskaniki,
zostaa przydzielona?
117.Kiedy wsplna struktura danych jest uywana w
kilku funkcjach, czy definicja struktury jest
wszdzie taka sama?
Bdy w deklarowaniu zmiennych
Bdy w deklaracjach s spowodowane przez niewaciwe deklarowanie
zmiennych lub staych.
118.Czy wszystkie zmienne maj zadeklarowan
waciw dugo, typ i rodzaj pamici? Na
przykad, czy zmienna nie powinna by raczej
zadeklaraowana jako cig znakw ni jako
wektor znakw?
119.Czy zmienne inicjalizowane w momencie
deklaracji s inicjalizowane poprawnie i
wartocia zgodn ze swoim typem?
120.Czy istniej zmienne z podobnymi nazwami?
Nie jest to koniecznie bdem, ale by moe
symptomem, e pomieszay si zmienne o
podobnych nazwach z rnych miejsc w
programie.
121.Czy istniej zadeklarowane zmienne, ktrych

si potem nie uywa albo uyte s tylko jeden
raz?
122.Czy wszystkie zmienne zadeklarowane s w
swoich moduach? Jeli nie, czy jest zrozumiae
e zmienna jest wsplna z najbliszym moduem
wyszego rzdu?
Bdy obliczeniowe
Bdy obliczeniowe to po prostu bdna matematyka. Wynik obliczenia jest
faszywy.
123.Czy gdzie w obliczeniach uywa si
zmiennych rnych typw, jak np. dodawanie
liczby cakowitej do zmiennoprzecinkowej?
124.Czy gdzie w obliczeniach uywa si
zmiennych tego samego typu ale rnej dugoci
na przykad dodanie bajtu do sowa?
125.Czy zasady konwersji kompilatora wobec
zmiennych rnych typw lub dugoci s
wzite pod uwag w kodzie realizujcym
obliczenia?
126.Czy zmienna ktrej przydzielony zostanie
wynik obliczenia jest mniejsza ni wynik
wyraenia po prawej stronie?
127.Czy moliwy jest niedomiar lub przepenienie
w trakcie oblicze?
128.Czy moe gdzie wystpi dzielenie przez zero?
129.Czy w wypadku dziaa cakowitoliczbowych
kod uwzgldnia moliwo utraty dokadnoci,
np. przy dzieleniu?
130.Czy warto zmiennej moe przekroczy
warto rozsdn? Na przykad, czy wynik
obliczania prawdopodobiestwa moe by
mniejszy ni zero lub wiekszy ni 100%?
131.W wyraeniach zawierajcych wiele
operatorw, czy zasady kolejnoci obliczania
oraz zasady priorytetu operatorw s
uwzgldnione? Czy potrzebne s nawiasy dla
wyjanienia?
Bdy w porwnaniach
Mniejsze ni, wiksze ni, rwne, nierwne, fasz, prawda. Porwnania i
decyzje s zwykle bardzo naraone na bdy warunkw brzegowych.
132.Czy porwnanie jest poprawne? To si wydaje

trywialne, ale prawie zawsze jest jakas
wtpliwo czy porwnanie ma by np.
mniejszy ni czy te mniejszy ni lub
rwny.
133.Czy dokonuje si porwna midzy
wartociami zmiennoprzecinkowymi? Jeli tak,
czy mog wystpi jakie kopoty z
dokadnoci? Czy na przykad 1.00000001 jest
dostatecznie blisko 1.00000002, eby
porwnanie wykazao rwno?
134.Czy wyraenie booleowskie wyraa waciwie
to co powinno? Czy obliczenia na zmiennych
booleowskich s poprawnie zbudowane? Czy
kolejno oszacowania jest wzita pod uwag?
135.Czy argumenty wyraenia booleowskiego s
booleowskie? Czy na przykad zmienna
cakowitoliczbowa zawierajca liczb cakowit
nie jest uywana w booleowskich obliczeniach?
Bdy przepywu sterowania
Bdy przepywu sterowania s skutkiem nieprzewidzianego innego ni
zamierzone dziaania ptli i innych konstrukcji jzyka. Spowodowane s
zwykle bezporednio lub porednio przez bdy w obliczeniach albo w
porwnaniach.
136.Jeli jzyk zawiera takie konstrukcje jak
beginend oraz dowhile, czy zakocznia
s jawne i czy waciwie zamykaj konstrukcje?
137.Czy program, modu, subrutyna albo ptla
kiedykolwiek zakocz dziaania? Jeli nie, czy
to jest w porzdku?
138.Czy istniej ryzyko przedwczesnego wyjcia z
ptli?
139.Czy istnieje moliwo, e kod we wntrzu
ptli nie zostanie wykonany ani razu i czy jest to
do przyjcia?
140.Jeli program zawiera wielokrotne
rozgazienie, takie jak instrukcja switch
case, czy warto zmiennej indeksowej moe
przekroczy wartoci indeksw moliwych
rozgazie? Jeli tak, czy istnieje odpowiednia
porcedura postpowania w tym wypadku?
141.Czy istniej bdy o jeden, ktre mog
spowodowa niezaplanowane wykonanie
wntrza ptli?
Bdy w parametrach procedur

Bdy w parametrach procedur bior si z niewaciwego przekazywania
danych do podprocedur.
142.Czy typ i wielko parametrw otrzymanych
przez procedur zgodne s z wysanymi przez
kod przywoujcy porcedur? Czy ich kolejno
jest poprawna?
143.Czy jeli procedura ma wiele punktw wejcia
(brr), to istniej odniesienia do parametrw
nie zdefiniowanych dla danego punktu wejcia?
144.Czy jeli zmienne posya si do procedury jako
parametry, czy ich warto moe zosta
przypadkowo zmieniona przez procedur?
145.Czy procedura zmienia warto parametru,
ktry ma by tylko wartoci wejciow?
146.Czy skala dla poszczeglnych parametrw jest
taka sama w rutynie wywoujcej i wywoanej
np. europejskie i amerykaskie miary?
147.Jeli wystpuj zmienne globalne, czy maj one
takie same definicje we wszystkich procedurach,
ktre z nich korzystaj?
Bdy danych wejciowych i wyjciowych
Ta klasa bdw odnosi si do wszelkich dziaa zwizanych z czytaniem z
pliku, przyjmowaniem danych z klawiatury albo z myszy, pisanie na
urzdzeniu wyjcia, np. na drukarce albo na ekranie. Podane poniej punkty
s bardzo oglnikowe i uproszczone. Naley je uzupeni, eby zastosowa
do rnych typw oprogramowania i urzdze, ktre si testuje.
148.Czy oprogramowanie dokadnie spenia
wymagania formatu danych pisanych albo
czytanych przez urzdzenie zewntrzne?
149.Jeli plik albo urzdzenie peryferyjne nie jest
gotowe, czy program radzi sobie waciwie z t
sytuacj?
150.Czy oprogramowanie radzi sobie gdy
zewntrzne urzdzenie jest odczone, nie
odpowiada, albo jest przepenione w trakcie
czytania lub pisania?
151.Czy wszelkie moliwe bdy s obsugiwane
przez oprogramowanie w przewidywalny
sposb?
152.Czy wszystkie komunikaty bdw zostay

sprawdzone i s trafne, maj odpowiedni tre,
s poprawne gramatycznie i ortograficznie?
Inne kontrole
Ponisza lista zawiera pozycje, ktre nie pasoway do pozostaych kategorii.
Nie jest ona w adnym razie kompletna, ale powinna by dobrym
pocztkiem dla sporzdzenia listy peniejszej, stosownej dla konkretnego
projektu.
153.Czy oprogramowanie bdzie dziaa poprawnie
z wszystkimi wymaganymi jzykami? Czy jest
w stanie posugiwa si rozszerzonym kodem
ASCII? Czy uywa Unicode zamiast ASCII?
154.Jeli oprogramowanie ma by przenone na
inne kompilatory i mikroprocesory, czy zostalo
to wzite pod uwag? Przenono, jeli
wymagana, staje si czsto duym problemem
jeli si jej nie planowao i nie testowao pod jej
ktem.
155.Czy uwzgldnione zostay wymagania
kompatybilnoci tak eby oprogramowanie
dziaao poprawnie z rn iloci dostpnej
pamici, rnymi rodzajami sprztu takiego jak
karty dwikowe i graficzne, i z rnymi
urzdzeniami peryferyjnymi, jak drukarki i
modemy?
156.Czy kompilacja programw powoduje rne
komunikaty ostrzegawcze albo
informacyjne? Zwykle oznacza to e w kodzie
kryje si co wzbudzajcego wtpliwoci.
Puryci twierdziliby, e adne komunikaty
ostrzegawcze nie s dopuszczalne.
Podsumowanie
Badanie kodu statyczne testowanie metodami szklanej skrzynki okazao

si wielokrotnie skutecznym sposobem wczesnego znajdowania bdw. Ta
metoda wymaga sporo przygotowa, aby moga by produktywna, ale wiele
bada pokazuje, e spdzony tym czas dobrze si opaca. eby za uczyni
ten rachunek jeszcze atrakcyjniejszym, dostpne s dzis programy
pozwalajce zautomatyzowa du cz pracy. Istniej programy
sprawdzajce zgodno kodu rdowego z wieloma istniejcymi
standardami i z wasnymi reguami, ktre mona dostosowywa do potrzeb
klienta. Rwnie kompilatory s dzisiaj na tyle udoskonalone, e
uruchomiwszy peny arsena ich moliwoi kontrolnych, mona
automatycznie zidentyfikowac wikszo problemw znajdujcych si na
omwionej na poprzednich stronach licie. Te narzdzia nie likwiduj
potrzeby przegldw i inspekcji kodu, tylko uatwiaj je znacznie i daj
testerom czas, aby mc szuka bdw jeszcze gbiej.
Jeli w zespole projektowym nie testuje si obecnie na tym poziomie, a
testerzy maj nieco dowiadczenia w programowaniu, mona zaproponowa
rozwaenie takiej moliwoci. Programici i kierownictwo mog si
pocztkowo obawia tego przedsiwzicia, nie bardzo wierzc, by zyski
rzeczywicie byy a tak due w kocu trudno jest udowodni, e na
przykad znalezienie bdu podczas inspekcji zaoszczdzio projektowi pi
dni, ktre trzeba by byo spdzic wiele miesicy pniej podczas testowania
metodami czarnej skrzynki. Niemniej, statyczne testowanie metodami
szklanej skrzynki nabiera coraz wicej impetu, i w niektrych branach nikt
nie odway si dzi dostarcza niezawodnego oprogramowania, nie
poddawszy go statycznemu testowaniu.
Pytania
1.Wymie kilka korzyci wynikajcych ze stosowania statycznego
testowania metodami szklanej skrzynki.
2.Prawda czy fasz: statyczne testowanie metodami szklanej skrzynki
pozwala znale zarwno brakujce elementy jak i problemy.
3.Jakie s kluczowe elementy formalnych przegldw?
4.Oprcz poziomu formalizmu, jaka jest zasadnicza rnica midzy
inspekcjami a innymi rodzajami przegldw?
5.Jeli programista zosta poinformowany, e wolno mu uywa nazw
zmiennych nie duszych ni osiem znakw i wszystkie musz zaczyna
si du liter, czy mamy do czynienia ze standardem czy z regu?
6.Czy list kontroln do przegldw kodu opisan w tym rozdziale
powinno si przyj jako standard waszego zespou do weryfikacji kodu?
Rozdzia 7
Testowanie pod rentgenem
W TYM ROZDZIALE
Dynamiczne testowanie metodami szklanej skrzynki
Dynamiczne testowanie a lokalizowanie i usuwanie bdw
Test komponentw
Pokrycie danych
Pokrycie kodu
Jak dotd w czci II-iej poznalimy trzy spord czterech podstawowych
technik testowania: statyczne testowanie metodami czarnej skrzynki
(testowanie specyfikacji), dynamiczne testowanie metodami czarnej
skrzynki (testowanie oprogramowania) i statyczne testowanie metodami
szklanej skrzynki (badanie i analiza kodu rdowego). W tym rozdziale
zapoznamy si z czwart podstawow technik dynamicznym testowaniem
metodami szklanej skrzynki. Testujc oprogramowanie, bdziemy zaglda
do wntrza skrzynki jakby przy pomocy rentgena.
Oprcz rentgenowskich okularw, trzeba te bdzie wystpi pod flag
programisty o ile ma si do tego kompetencje. Jeli komu brak
znajomoci programowania, nie trzeba si zraa. Podane w rozdziale
przykady nie s zanadto skomplikowane i przyoywszy si, kady jest w
stanie je ledzi. Zrozumiawszy cho w czci t grup technik testowych,
mona sta si o wiele skuteczniejszym testerm.
Jeli ma si pewne dowiadczenie w programowaniu, ten rozdzia otwiera
bardzo szerokie moliwoci. Wikszo firm produkujcych
oprogramowanie zatrudnia testerw wanie do testowanie na niskim
poziomie. Poszukiwane s osoby majce umiejtnoci zarwno w
programowaniu jak i w testowaniu, co jest rzadkim i czsto poszukiwanym
poczeniem.
157.Czym jest dynamiczne testowanie metodami
szklanej skrzynki
158.Rnica midzy dynamicznym testowaniem
metodami szklanej skrzynki a usuwaniem
bdw z programu
159.Co to jest testowanie jednostkowe i testowanie
integracyjne
160.Jak testowa funkcje na niskim poziomie
161.Rodzaje danych ktre trzeba testowa na niskim
poziomie
162.Jak zmusza program do wymaganego sposobu

dziaania
163.Jakimi rnymi metodami mona zmierzy
staranno testowania
Dynamiczne testowanie metodami szklanej skrzynki

Znamy ju na pewno bardzo dobrze pojcia statyczny, dynamiczny, metody
szklanej skrzynki i metody czarnej skrzynki, tak e wiedzc, e ten rozdzia
zajmie si testowaniem dynamicznym metodami szklanej skrzynki,
powinnimy si atwo domyle jego treci. Skoro jest dynamiczne, to
znaczy e program musi by uruchamiany, a skoro jest metodami szklanej
skrzynki, to znaczy e zaglda si do rodka pudeka, analizuje kod i
obserwuje jak jest wykonywany. Testuje si jakby z rentgenem na oczach.
Dynamiczne testowanie metodami szklanej skrzynki posikuje si
informacj zdobyt przez obserwowanie chodzcego kodu. Ta informacja
jest wykorzystywana aby zadecydowa co testowa, czego nie testowa, i w
jaki sposb podej do testowania. Inn powszechnie stosowan nazw na
dynamiczne testowanie metodami szklanej skrzynki jest testowanie
strukturalne, poniewa widzi si przy nim i wykorzystuje struktur kodu do
konstruowania i do wykonywania zada testowych.
Jakie poytki mog wynika ze znajomoci tego, co dzieje si wewntrz
pudeka, jak dziaa oprogramowanie? Spjrzmy na rysunek 7.1. Pokazane
s na nim dwa pudeka, realizujce podstawowe operacje arytmetyczne:
dodawanie, odejmowanie, mnoenie i dzielenie.
Rysunek 7.1 Wybraoby si inne zadania testowe wiedzc, e pudeku jest

komputer i inne, jeli w pudeku siedziaby czowiek z papierem i owkiem.
Jeli nie wie si, jak dziaa pudeko, wybraoby si dynamiczne techniki
czarnej skrzynki, ktre zostay opisane w rozdziale 5-ym, Testowanie z
klapkami na oczach. Gdyby jednak zajrze do pudeek i zobaczy, e jedno
z nich zawiera komputer, a w drugim ukrywa si czowiek z owkiem i
papierem, wybraoby si przypuszczalnie dla nich zupenie odmienne
zestawy testw. Oczywicie, to bardzo uproszczony przykad, ale dobrze
ilustruje jak znajomo sposobu dziaania programu wpywa na sposb
testowania.
Dynamiczne testowanie metodami szklanej skrzynki oznacza wicej niz
tylko ogldanie pracy kodu, moe rwnie oznacza bezporednie
testowanie i kontrol oprogramowania. Dynamiczne testowanie metodami
szklanej skrzynki obejmuje cztery obszary:
164.Bezporednie testowanie na niskim poziomie
funkcji, procedur, rutyn i bibliotek. W
Windowsach nazywane one s zwykle
interfejsem programistycznym (API).
165.Testowanie oprogramowania na najwyszym
poziomie, jako gotowy program, z tym e
zadania testowe oparte s rnie na tym, co si
wie o sposobach jego dziaania.
166.Uzyskanie dostpu do do zmiennych w kodzie i
do informacji o jego stanie uatwi sprzwdzenie,
czy testy s waciwie skonstruowane. Rwnie
daje to moliwoc zmuszenia programu do
innego dziaania , ni daoby si osign
testujc tylko technikami czarnej skrzynki.
167.Pomiary, jaka cz kodu i specyfikacji zostaa
rzeczywicie przetesowana i uzupenienie
zestawu zada testowych o nowe, jeli nie idao
si osign podanego pokrycia kodu.
Kady z tych czterech obszarw bdzie przedyskutowany w pozostaej
czci rozdziau. Warto to wzi pod uwag czytajc dalej i zastanowi si,
na ile te techniki przydayby si do testowania programw.
Dynamiczne testowanie a lokalizowanie i usuwanie bdw

Nie naley miesza dynamicznego testowania metodami szklanej skrzynki z
lokalizacj i usuwaniem bdw. Kto zajmowa si programowaniem, na
pewno spdzi wiele godzin lokalizujc i usuwajc bdy w napisanym przez
siebie kodzie. Obie czynnoci wydaja si podobne, poniewa obie zajmuj
si bdami w oprogramowaniu i obie grzebi si w kodzie, ale ich cele s
zupenie odmienne (rysunek 7.2).
Testowanie
Dynamiczne
testowanie
metodami biaej
skrzynki
Programowanie
Identyfikacja
bdu
Lokalizacja i
usuwanie bdu
Rysunek 7.2 Dynamiczne testowanie metodami szklanej skrzynki oraz

lokalizowanie i usuwanie bdw maj rne cele, ale zazbiaj si.
Celem testowania jest znajdowanie bdw. Celem lokalizacji i usuwania
bdw jest ich likwidacja. Te rejony zazbiaj si tam, gdzie staramy si
bd wyizolowac i zidentyfikowa jego przyczyn. Dowiemy si na ten
temat wicej w rozdziale 18-ym Raportowanie wynikw, ale na razie
przyjmijmy uproszczone wytumaczenie. Tester oprogramowania ma za
zadanie zawzic problem do naprostszego moliwego testu, ktry wywouje
symptom poszukiwanego bdu. Testujc metodami szklanej skrzynki,
moemy czsto nawet zidentyfikowa podejrzany fragment kodu.
Programista zajmujcy si lokalizowaniem i usuwaniem bdu przejmuje
paeczk w tym wanie miejscu, ustala dokadnie przyczyn bdu i usiuje
j usun.
Wane jest umie rozdzieli w praktyce prac testera i programisty.
Programici pisz kod, testerzy szukaj i znajduj bdy i czasem pisz
nieco kodu do automatyzacji testw; programici poprawiaj bdy. Bez
wyranego podziau, pewne zadania mog zosta przez obie strony
pominite, albo przeciwnie jaka praca zostanie wykonana dwa razy.
Testujc na niskim poziomie w pobliu kodu, uywa si wielu tych samych
narzdzi co programici. Jeli program jest kompilowany, tester rwnie go
kompiluje, ewentualnie z innymi ustawieniami dla umoliwienia
atwiejszego wykrywania bdw. Tester uywa te prawdopodobnie tego
samego programu ledzcego aby wykonywa program pojedynczymi
krokami, obserwowac warto zmiennych, ustawia punkty zatrzymania itd.
Czsto te pisze si wasne programy, np. aby mc przetestowa pojedyncze
moduy.
Testowanie kawakw
Przypomnijmy sobie z rozdziau 2-iego Proces wytwarzania

oprogramowania rne modele wytwarzania oprogramowania. Model
skokowy by najprostszy, ale te najbardziej chaotyczny. Wszystko czy si
ze sob na raz, zaciska kciuki i mona mie nadzij, e powstanie z tego
gotowy produkt. atwo si domyle, e testowanie przy tym trybie pracy
jest bardzo trudne. Co najwyej mona przystpi do testowania
dynamicznego metodami czarnej skrzynki, biorc program w jednym duym
kawaku i prbujc, co te daoby si znale.
Nauczylimy si ju e taka metoda jest bardzo kosztowna, poniewa bdy
znajduje si bardzo pno w procesie wytwrczym. Z punktu widzenia testu,
istniej dwie gwne przyczyny tych wysokich kosztw:
168.Trudno a czasem wrcz niemoliwe jest
zorientowa si, co jest przyczyn awarii.
Oprogramowanie jest jak zepsuty czarodziejski
stolik cho wypowiedziao si zaklcie
stoliczku nakryj si, adne potrawy si nie
pojawiy. Nie sposb zgadn, jaki drobiazg
szwankuje i powoduje, e cao nie dziaa.
169.Jedne bdy mog zasania inne bdy. Zadanie
testowe wywouje awari, programista spokojnie
znajduje i usuwa bd, ale kiedy wykonuje si
zadanie testowe ponownie, znw nastpuje
awaria. Tak wiele rnych bdw naoyo si
jedne na drugie, e bardzo czasochonne robi si
dotarcie do pierwszej przyczyny.
Test komponentw i test integracyjny
eby wybrn z tego caego baaganu, najlepiej do niego po prostu nie
dopuci. Jeli kod powstaje i jest testowany po kawaku, a potem
stopniowo skada si go w wiksze caoci, ni bdzie tylu niespodzianek,
kiedy w kocu poczy si cay produkt (rysunek 7.3).
Program gwny
Modu Modu
Rysunek 7.3 Poszczeglne fragmenty kodu buduje si i testuje pojedynczo,

potem integruje ze sob i testuje ponownie.
Testowanie na najniszym poziomie nazywane jest testowaniem

jednostkowym&testowaniem komponentw albo testowaniem moduu1.
Moduy s testowane, bdy w nich znajdowane i usuwane, po czym
nastpuje integracja i test integracyjny grup moduw. Proces przyrostowego
testowania przebiega stopniowo, czc ze sob coraz wicej i wicej
moduw, a wreszcie cay produkt a przynajmniej jego wiksza cz
zostaje przetestowana w caoci w ramach testowania systemu.
Kiedy stosuje si t strategi testowania, identyfikacja i lokalizacja bdw
staj si o wiele atwiejsze. Problem znaleziony na poziomie moduu z
reguy musi znajdowa si w tym samym module. Jeli nastpuje awaria
podczas czenia przedtem przetestowanych z osobna moduw, to jej
rdem jest przypuszczalnie interakcja midzy moduami. Zdarzaj si
wyjtki od tej zasady, ale oglnie rzecz biorc, testowanie i lokalizacja
bdw przebiega wtedy znacznie sprawniej ni kiedy testuje si wszystko
na raz.
Istniej dwie gwne metody integracji przyrostowej: oddolny i odgrny. W
testowaniu oddolnym (rysunek 7.4) testerzy pisz wasne procedury, zwane
sterownikami, ktre przywouj testowany modu. Podcza si moduy
dokadnie w ten sam sposb jak w penym programie. Sterowniki wysyaj
dane testowe do testowanych moduw, odczytuj wyniki i weryfikuj, czy
s poprawne. W ten sposb daje si zwykle przetestwoa oprogramowanie
bardzo szczegowo, przy uyciu bardzo rnorodnych danych testowych,
nawet takich ktre trudno byoby zastosowa podczas testowania
kompletnego systemu.
Rzeczywiste oprogramowanie
Oprogramowanie sterownika
Temperatura
Dane testowe
Wyniki
Wyniki
Modu konwersji z oF na oC
Modu konwersji z oF na oC
Konfiguracja w wiecie
rzeczywistym
Konfiguracja sterownika
testowego
Rysunek 7.4 Sterownik testowy moe zastpi cz oprogramowania i

przetestowa bardzo dokadnie modu niszego rzdu.
Spotyka si te okrelenia test komponentu oraz test podstawowy.
Integracja odgrna brzmi troch jak skokowa w mniejszej skali. W kocu

jeli gotowy jest gwny program, musi by za pno bra si za testowanie
moduw? Nie cakiem jest to prawd. Spjrzmy na rysunek 7.5. W tym
wypadku, modu interfejsu na niskim poziomie zbiera dane o temperaturze z
elektronicznego termometru. Modu wywietlacza umieszczony jest tu
ponad interfejsem, skd czyta dane i wywietla je na ekranie dla
uytkownika. Aby przetestowa grny modu wywietlacza na gotowym
systemie, trzeba by posugiwa si palnikami, woda, lodem i zamraark,
eby spowodowa zmiany temperatury czujnika, przekazywane do moduu
wywietlajcego.
Zamiast jednak testowa modu wywietlacza usiujc sterowa temperatur
termometru, mona napisa fragment kodu, zwany namiastk, ktry dziaa
tak jak interfejs, podajc temperatury - zapisane np. na pliku - wprost do
moduu wywietlajcego. Modu wywietlajcy odczytuje przekazywane
dane tak samo, jakby je czyta wprost z interfejsu prawdziwego termometru.
Nie jest w stanie dostrzec adnej rnicy. Uywajc namiastek, mona w
tym wypadku szybko przetestowa modu wywietlacza przy uyciu
wielkiej iloci danych testowych i dokona walidacji tego moduu.
Modu wywietlacza
temperatury
Testowany modu wywietlacza

temperatury
Modu interfejsu termometru
Namiastka skonstruowana przez

testera
Konfiguracja w wiecie
rzeczywistym
Plik z danymi testowymi

Konfiguracja sterownika
testowego
Rysunek 7.5 Namiastka testowa przesya dane do gry, do testowanego

moduu.
Przykad testu moduu
Funkcj dostpn w wielu jzykach programowania jest konwersja cigu
znakw ASCII w warto cakowitoliczbow.
Ta funkcja przyjmuje cig cyfr, znaki - lub + oraz moliwe dodatkowe
znaki jak spacja oraz litery, i przeksztaca je w warto liczbow. Na
przykad, cig znakw 12345 zostaje przeksztacony w liczb dwanacie
tysicy trzysta czterdzieci pi. Tej funkcji uywa si czsto do
przetwarzania danych z okna dialogowego na przykad czyj wiek albo
inne dane.
W jzyku C ta funkcja nazywa si atoi(), co jest skrtem nazwy ASCII

na liczb cakowit1. Rysunek 7.6 pokazuje specyfikacj tej funkcji. Kto nie
jest programist, nich si nie denerwuje. Oprcz pierwszej linijki,
okrelajcej jak funkcj si przywouje, specyfikacja jest napisana w
zwykej polszczynie i mona jej uywa do opisu tej samej funkcji dla
dowolnego jzyka programowania.
Co powinien zrobi tester, ktremu przypado zadanie wykonania
dynamicznego testowania metodami szklanej skrzynki tego moduu?
int atoi (const char *string)
Funkcja z ASCII na liczb cakowit przekada cig znakw na liczb cakowit.
Warto powrotna
Funkcja zwraca warto cakowitoliczbow, powsta przez potraktowanie cigu znakw
na wejciu jako zapisu liczby. Warto powrotna wynosi 0 jeli dane z wejcia nie dadz
si przksztaci na liczb cakowit. Warto powrotna jest niezdefiniowana w wypadku
przepenienia.
Parametr wejciowy
cig znakw
Cig znakw ktry ma by przeksztacony.
Uwagi
Cig znakw na wejciu jest sekwencj znakw, ktr mona zinterpretowa jako warto
liczbow. Funkcja przestaje czyta cig znakw po natrafieniu na pierwszy znak, ktrego
nie daje si zinterpretowa jako czci skadowej liczby. Ten znak moe by znakiem
zerowym (`\0`) zakaczajcym cig znakw.
Cig znakw dla tej funkcji ma posta:
[pusty znak] [znak plus/minus] cyfry

Pusty znak moe by spacj i/albo znakiem tabulacji, ktre s pomijane; znak
plus/minus to albo plus (+), albo minus (-); cyfry to to jeden lub wicej cyfr
dziesitnych. Funkcja nie rozpoznaje punktu dziesitnego, potg ani adnych
innych, niewymienionych powyej znakw.
Rysunek 7.6 Specyfikacja funkcji atoi() w jzyku C.

Wydaje si od razu, e ten modu wyglda jak modu na najniszym
poziomie, taki ktry jest przywoywany przez inne moduy, ale sam niczego
nie przywouje. Mona to ewentualnie potwierdzi, czytajc kod moduu.
Jeli tak jest, to logiczn metod bdzie napisanie sterownika testowego, aby
mc sprawdza ten modu niezalenie od reszty programu.
Po angielsku ASCII to Integer
Sterownik testowy wysyaby skonstruowane przez testera cigi znakw do

funkcji atoi(), odbiera wynik i porwnywa go z oczekiwanym
rezultatem. Najprawdopodobniej, sterownik testowy zostaby napisany w
tym samym jzyku, co testowana funkcja w tym wypadku, w jzyku C
ale daje si te pisa sterowniki w innych jzykach, byle miay one interfejs
do jzyka, w ktrym napisany jest testowany modu.
Sterownik testowy moe przybiera rne ksztaty. Moe to by proste okno
dialogowe, jak na rysunku 7.7, ktrego uywa si do wprowadzania cigw
znakw i do obserwacji wynikw. Mgby to by osobny program, czytajcy
cigi znakw i oczekiwane wyniki z pliku. Okno dialogowe, sterowane
przez uytkownika, jest interakcyjne i bardzo elastyczne mona je
udostpni rnie testerowi stosujcemu techniki czarnej skrzynki. Z drugiej
strony, osobny program moe dziaa o wiele szybciej, czytajc dane
testowe i zapisujc wyniki bezporednio na pliku.
Rysunek 7.7 Sterownik testowy w postaci okna dialogowego moe by

zastosowany, aby posya zadania testowe testowanemu moduowi.
Nastpnie naleaoby zanalizowa specyfikacj i zadecydowa, jakie
zadania testowe typu czarnej skrzynki warto wyprbowa, a w kocu
zastosowa podzia na klasy rwnowanoci aby zmniejszy ich ilo
(przypomnijmy sobie rozdzia 5-y). Tabela 7.1 pokazuje przykady zada
testowych wraz z cigami znakw stosowanych jako dane wejciowe oraz
oczekiwanymi wynikami wyjciowymi. Tabela ta nie ma by wyczerpujca.
Tabela 7.1 Przykadowe zadania do testowania przeksztacenia cigu ASCII
w liczb cakowit.
Cig znakw (na wejciu)
Warto na wyjciu
-1
-1
+1
-0
+0
1.2
2-3
abc
a123

i tak dalej
Wreszcie naleaoby rwnie rzuci okiem na kod rdowy, zobaczy z jaki

sposb zrobiono implementacj funkcji i wykorzystac t
szkalnoskrzynkow wiedz na temat moduu, aby doda lub usun zdania
testowe.
Wane, aby zadanie testowe typu czarnoskrzynkowego, oparte na
specyfikacji, konstruowa zanim zacznie si stosowac metody szklanej
skrzynki. W ten sposb testuje si w pierwszy rzdzie to, co modu
powinien wykonywa. Jeli natomiast zacz od zada testowych
sporzdzonych wedug metod szklanej skrzynki, to jest poprzez analiz
kodu, atwo zatraci bezstronno i konstruowa zadania testowe na
podstawie tego, jak modu rzeczywicie dziaa. Jednak programista mg
przecie nie zrozumie specyfikacji i wtedy zadania testowe
skonstruowane przez testera bd tak samo bdne. Owszem, mog by
dokadne, znakomicie testujce modu, ale nie bd trafne, poniewa nie
bd testowa waciwego dziaania.
Dodawanie i odrzucanie zada testowych przy uyciu wiedzy na temat kodu
jest w istocie szczeglnym zastosowaniem metody podziau na klasy
rwnowanoci przy zastosowaniu informacji wewntrznych. Pierwotne
zadania testowe mogy zakada, e zadania takie jak a123 i z123 s
istotnie rne. Analiza kodu mogaby jednak ujawni, e zamiast posugiwa
si tabel ASCII, programista ograniczyl si do poszukiwania znakw
pustych, znakw + i - oraz cyfr. Majc t informacj, jedno z
powyszych zada testowych mona spokojnie odrzuci, poniewa oba
znajduj si w tej samej klasie rwnowanoci.
Inna sytuacja dokadniejsza analiza kodu mogaby na przykad ujawni, e
identyfikowanie znakw + i - wyglda troch podejrzanie moe po
prostu trudno jest je zrozumie. W tej sytuacji, warto dla upewnienia si
doda kilka zada testowych ze znakami + i - rozrzuconymi w rnych
miejscach.
Pokrycie danych
Powyszy przykad testowania funkcji atoi() metodami szklanej skrzynki
by znacznie uproszczony i pomija wiele szczegw na temat wpywu
analizy kodu na dobr zada testowych. W rzeczywistoci analiza kodu jest
czym wicje ni rdem dobrych poysw, co testowa, a czego nie warto.
Naley tak samo jak to si robi w testowaniu metodami czarnej skrzynki
podzieli kod na dane i stany (albo przepyw sterowania). Stosujc ten punkt
widzenia, o wiele atwiej odnie uzyskan informacj na temat kodu do
wczeniej skonstruowanych zada testowych metodami czarnej skrzynki.
Wemy najpierw pod uwag dane. Do danych zaliczaj si wszystkie
zmienne, stae, wektory, inne struktury danych, dane wejciowe z klawiatury
i z myszy, dane wejciowe i wyjciowe z plikw i z ekranu, wjecie/wyjcie
z innych urzdze jak modemy, sieci i tak dalej.
Przepyw danych
Badanie pokrycia przepywu danych polega na przeledzeniu caej drogi
przez fragment programu jednego kawaka danych. Na poziomie
testowania jednostkowego oznacza to przepyw danych przez pojedynczy
modu. Mona take przeledzi drog danych przez kilka zintegrowanych
moduw albo nawet przez cae oprogramowanie aczkolwoiek byoby to
bardzo czasochonne.
Testujc funkcj na tak niskim poziomie, uywa si programu ledzcego i
obserwuje wartoci zmiennych w czasie wykonywania programu (rysunek
7.8). Stosujc testowanie czarnej skrzynki, zna si tylko warto zmiennej
na pocztku i na kocu. Stosujc dynamiczne testowanie szklanej skrzynki,
mona te sprawdza wartoci porednie podczas wykonywania programu.
Biorc pod owag poczynione obserwacje, mona zmodyfikowa zadania
testowe tak, aby wymusi przyjcie przez zmienne interesujcych czy
ryzykownych wartoci porednich.
Rysunek 7.8 Program ledzcy i obserwacja zmiennych umoliwia ledzenie

wartoci zmiennych w czasie wykonywania programu.
Wewntrzne wartoci graniczne
Wewntrzne wartoci graniczne omawiane ju byy w rozdziale 5-ym w
odniesieniu do wbudowanych tabel ASCII i do wartoci potgi dwjki. To s
przypuszczalnie najczciej spotykane wewntrzne wartoci graniczne
powodujce bdy, ale kady fragment kodu bdzie te mia swoje wasne,
specjalne wewntrzne wartoci graniczne. Oto kilka przykadw:
170.Modu sucy do wyliczania podatkw moe
przy progu podatkowym zmieni sposb
naliczania z tabeli wartoci na uycie
arytmetycznego wyraenia do oblicze.
171.System operacyjny moe zacz przenosi dane
do pamici tymczasowej na dysku kiedy
zaczyna brakowa pamici RAM. Warto tej
granicy nie musi by nawet ustalona z gry,
moe si zmienia zalenie od tego, ile miejsca
pozostao na dysku.
172.Dla uzyskania wikszej dokadnoci, zoony

algorytm numeryczny moe zmienia uwan
formu oblicze zalenie od wielkoci liczby.
Przy testowaniu metodami szkalnej skrzynki naley uwanie bada kod w
poszukiwaniu wewntrznych wartoci granicznych, aby mc dorobi dla
nich dodatkowe zadania testowe. Warto spyta programist, ktry napisa
kod, czy potrafi zidentyfikowa takie miejsca, i zwrci baczn uwag na
wewntrzne tabele danych, ktre s szczeglnie podatne na problemy
wewntrznych wartoci granicznych.
Wzory i rwnania
Bardzo czsto wzory i rwnania ukryte s gboko w kodzie i ich obecno
ani skutki nie s oczywiste, kiedy si patrzy z zewntrz. Program finansowy
do obliczania procentu zoonego na pewno bdzie gdzie zawiera
nastpujcy wzr:
A = P (1 + r/n)nt
gdzie
P = suma wyjciowa
r = roczna stopa procentowa
n = ilo razy, kiedy w cigu roku nalicza si procent
t = ilo lat
A = suma po upywie czasu t
Dobry tester posugujcy si metodami czarnej skrzynki wybraby, naley
mie nadziej, zadanie testowe gdzie n=0, ale tester stosujcy metody
szklanej skrzynki, zobaczywszy ten wzr w kodzie, na pewno zastosuje n=0,
poniewa spowoduje si w ten sposb awari wzoru i bd dzielenia przez
zero.
C si jednak stanie, jeli warto n jest wynikiem innych oblicze? Moe
program ustala warto n na podstawie danych wprowadzanych przez
uytkownika, albo algorytm wyprbowuje rne warotci n w celu
znalezienia takiej, dla ktrej wynik bdzie najniszy. Naley zada sobie
pytanie, czy istnieje moliwo, e n kiedykoliwek otrzyma warto zero i
odkry, jakie dane trzeba wprowadzic do programu aby to uzyska.
Naley przeszukiwa kod w poszukiwaniu wzorw i rwna, bada
uywane w nich zmienne i konstruowa zadania testowe oparte na
dodatkowych klasach rwnowanoci, jako dodatek do klas
rwnowaoci dla danych wejciowych i wyjciowych programu.
Wymuszanie awarii
Ostatnim rodzajem omawianych w tym rozdziale testw opartych na danych
jest wymuszanie awarii. Jeli uywa si programu ledzcego, mona nie
tylko obserwowa waroci zmiennych, ale rwnie je modyfikowa.
W omawianym przykadzie obliczania procentu zoonego, jeli nie znajduje
si sposobu nadania zmiennej n wartoci zerowej, mona nada jej waro
zero przy pomocy programu ledzcego. Program albo sobie z tym
poradzi albo nie.
Warto pamita, e przy pomocy programu ledzcego mona stworzy
sytuacj, ktra nigdy nie moe zaistnie przy normalnym uytkowaniu
programu. Jeli program kontroluje e waro n jest wiksza od zera na
pocztku funkcji, a zmiennej n pniej do niczego co moe zmieni jej
warto ju si nie uywa, to nadanie jej wartoci zerowej i
spowodowanie w ten sposb awarii programu jest niedozwolonym
zadaniem testowym.
Wymuszanie awarii moe by skuteczn metod, o ile stosowa j ostronie
i z namysem, sprawdzajc razem z programistami, e wybrane zadania
testowe s dozwolone. Mona w ten sposb wykonywac zadania testowe, w
przeciwnym razie trudne lub niemoliwe do osignicia.
Wymuszanie komunikatw o bdach
Wymuszanie awarii jest wietn technik, aby wywoa pojawienie si
wszelkich moliwych komunikatw o bdach, ukrytych w programie.
Wiele programw stosuje wewntrzne kody dla oznaczenia kadego
komunikatu o awarii. Kiedy wewntrzna flaga sygnalizujca bd jest
ustawiona, procedura obsugi bdu odczytuje zmienn zawierajc ten
kod i wywietla odpowiedni komunikat.
Wiele bdw trudno jest zaaranowa jak na przykad podczenie
2049 drukarek. Jeli jednak chce si tylko skontrolowa, e poprawny jest
sam komunikat o bdzie, (ortografia, sownictwo, format itd),
wymuszanie bdw moe by bardzo skutecznym sposobem, eby je
wszystkie zobaczy. Trzeba tylko pamita, e w ten sposb testuje si
kod wywietlajcy komunikat o bdzie, a nie kod wykrywajcy bd.
Pokrycie kodu
Tak jak z testowaniem metodami czarnej skrzynki, testowanie danych to

dopiero poowa bitwy. Dla osigniecia wyczerpujcego pokrycia naley
rwnie przetestowa stany programu i przepyw kontroli midzy nimi.
Trzeba sprawdzi wejcia i wyjcia kadego moduu, wykona kad linijke
kodu, i przeledzi kad ciek przez program1. Badanie oprogramowania
na tym poziomie nosi nazw analizy pokrycia kodu.
Analiza pokrycia kodu jest dynamiczn technik szklanej skrzynki,
poniewa wymaga penego dostpu do kodu, aby mc obserwowa te
fragmenty programu, przez ktre si przechodzi podczas wykonywania
zada testowych.
Najprostsz form analizy pokrycia kodu jest zastosowanie programu
ledzcego, by obserwowa ktre linie kodu si przechodzi podczas jego
wykonywania pojedynczymi krokami. Rysunek 7.9 pokazuje przykad
programu ledzcego dla Visual Basic w dziaaniu.
Rysunek 7.9 Program ledzcy umoliwia przyjcie programu pojedynczymi

krokami aby skontrolowa, ktre linie kodu i ktre moduy przechodzi si
podczas wykonywania zada testowych.
Dla bardzo maych programw albo pojedynczych moduw ten sposb
moe by cakiem zadowalajcy. Jednak aby mc przeprowadzi analiz
pokrycia kodu dla wikszoci programw, trzeba si posugiwa specjalnym
narzdziem, zwanym jako analizator pokrycia kodu. Rysunek 7.10 pokazuje
przykad takiego narzdzia.
Analizator pokrycia kodu podcza si do testowanego programu i jest
egzekwowany w tle, kiedy wykonuje si zadania testowe. Kiedy
wykonywanie przechodzi przez funkcj, linijk kodu albo punkt decyzyjny,
analizator zapisuje informacj o tym. Po zakoczonym wykonywaniu mona
uzyska dane statystyczne, ktre identyfikuj fragmenty kodu, przez ktre
si przeszo i te, przez ktre si nie przeszo podczas testowania. Majc te
dane wie si nastpujce rzeczy:
To nieprecyzyjne sformuowania i niewykonalne wymagania - wszystkich cieek przez program

przetestowa si z reguy nie da (przyp. tumacza).
173.Ktre czci kodu nie zostay pokryte przez

zastosowane testy. Jeli kod znajduje si w
odrbnym module, ktrego si nigdy nie
przeszo, wiadamo e trzeba si zabra za
tworzenie dodatkowych zada testowych, aby
przetestowa dziaanie tego moduu.
Rysunek 7.10 Analizator pokrycia kodu dostarcza szczegowych danych o

skutecznoci zastosowanych zada testowych (rysunek jest wasnoci i
zosta wydrukowany za zezwolenienm Bullseye Testing Technology.)
174.Ktre zadania testowe s zbdne. Jeli
wykonanie serii zada testowych nie zwiksza
stopnia pokrycia kodu, to przypuszczalnie
nale wszystkie one do tej samej klasy
rwnowanoci.
175.Jakie nowe zadania testowe trzeba
skonstruowa aby osign lepsze pokrycie.
Naley zanalizowa fragmenty kodu gdzie
pokrycie jest sabe, zrozumie jego dziaanie i
sporzdzi nowe zadania testowe, ktre
wykorzystaj ten kod.
Osiga si take wyczucie jakoci testowanego oprogramowania. Jeli
pokrycie kodu wynosi 90% i nie znajduje si wielu bdw,
oprogramowanie jest zapewne w dobrym stanie. Jeli, przeciwnie, testy
osigny ledwo 50% pokrycia kodu i nadal znajduje si bdy, trzeba
spodziewa si jeszcze wiele pracy.
Pokrycie linii kodu
Najprostsz form pokrycia kodu jest tak zwane pokrycie instrukcji albo
pokrycie linii kodu. Monitorowanie pokrycia instrukcji w trakcie testowania
oznacza zwykle, e celem jest wykonanie cho raz kadej instrukcji w
programie. Dla krtkiego programu, jak ten na wydruku 7.1, 100% pokrycia
instrukcji oznacza wykonanie linii od 1-ej do 4-ej.
Wydruk 7.1 Bardzo atwo jest przetestowa kad lini tego prostego
programu
PRINT Czoem, wiecie
PRINT Dzisiejsza data: ; Date$

PRINT Jest godzina: ; Time$
END
Nietrudno ulec zudzeniu, e 100% pokrycia instrukcji oznacza, e program
zosta przetestowany cakowicie. Celem i sygnaem do zaprzestania testw
byoby osigniecie 100% pokrycia. Niestety, to tylko zudzenie.
Przetestowanie kadej instrukcji programu nie oznacza, e przetestowao si
rwnie wszystkie moliwe cieki przez program.
Pokrycie rozgazie programu
Testowanie w celu pokrycia jak najwikszej iloci moliwych cieek przez
program nazywane jest testowaniem cieek. Najprostsz form testowania
cieek jest testowanie rozgazie. Spjrzmy na program pokazany na
wydruku 7.2.
Wydruk 7.2 Instrukcja IF stwarza rozgazienie w kodzie
PRINT Czoem wiecie
IF Date$ = 2000-01-01 THEN
PRINT Dosiego Roku!
ENDIF
END
Jeli ma si na celu osign 100% pokrycia instrukcji, wystarczy jedno
zadanie testowe, gdzie zmienna Date$ ma warto 1 stycznia 2000.
Program wykona wwczas nastpujc ciek:
Linie 1, 2, 3, 4, 5, 6, 7
Analizator pokrycia kodu okreliby, e przetestowana zostaa kada
instrukcja i e osignito 100% pokrycia. No to jestemy gotowi z
testowaniem, prawda? Nieprawda! Przetestowana zostaa kada instrukcja,
ale nie kade rozgazienie.
Instynkt podpowiada, e naleaoby jeszcze wykona zadanie testowe z dat
inn ni 1-y stycznia 2000. Wwczas program wykona inn ciek:
Linie 1, 2, 5, 6, 7
Wikszo analizatorw pokrycia podaje osobno wyniki pokrycia instrukcji
i pokrycia rozgazie, co pozwala sobie wytworzy o wiele lepsze pojcie o
skutecznoci testowania.
Pokrycie warunkw logicznych

Kiedy juz mylelimy, e wszystko gotowe, pojawia si nowa trudnoc w
testowaniu cieek. Wydruk 7.3 jest odmian wydruku 7.2. Dodany zosta
nowy warunek do instrukcji IF w drugiej linii, kontrolujcy zarwno czas
jak i dat. Testowanie warunkw logicznych uwzgldnia zoone warunki
logiczne w instrukcji warunkowej.
Wydruk 7.3 Zoony warunek w instrukcji IF powoduje, e pojawia si
wicej rnych cieek przez kod
PRINT Czoem wiecie
IF Date$ = 2000-01-01 AND Time$ = 00:00:00 THEN
PRINT Dosiego Roku!
ENDIF
END
Aby uzyska pene pokrycie warunkw logicznych w tym przykadowym
programie, potrzebne s cztery grupy danych testowych, jak pokazano w
tabeli 7.2. Te dane gwarantuj pokrycie wszelkich moliwoci w instrukcji
IF.
Tabela 7.2 Zadania testowe potrzebne dla osignicia penego pokycia
warunku IF ze zoonym warunkiem logicznym
Date$
Time$
Wykonanie linii
0000-01-01
11:11:11
1,2,5,6,7
0000-01-01
00:00:00
1,2,5,6,7
2000-01-01
11:11:11
1,2,5,6,7

2000-01-01
00:00:00
1,2,3,4,5,6,7
Jeli interesuje nas tylko pokrycie rozgazie, trzy pierwsze grupy danych
nie bd interesujce i mozna je poczy w jedn klas rwnowanoci i w
jedno zadanie testowe. Kiedy jednak stosuje si miar pokrycia warunkw
logicznych, wszystkie cztery zadania s istotne, poniewa reprezentuj
cztery rne warunki logiczne.
Analizatory pokrycia kodu mog zwykle zosta skonfigurowane tak, by
pokazyway rwnie pokrycie warunkw przy raportowaniu wynikw.
Kiedy si osiga pokrycie warunkw logicznych, osiga si zarazem
pokrycie rozgazie i pokrycie instrukcji.
Nawet jeli przetestuje si kad instrukcj, kade rozgazienie i kady
warunek logiczny (co jest moliwe tylko dla najmniejszych programw),
nadal jeszcze nie przetestowao si wszystkiego. Zwrmy np. uwag, e
wszysktkie bdy danych, opisane na pocztku tego rozdziau, nadal s
moliwe. Przepyw kontroli i przepyw danych cznie stwarzaj
dziaajce oprogramowanie.
Podsumowanie
W tym rozdziale dowiedzielimy si, jak dostp do kodu rdowego w
czasie wykonywania programu otwiera cay nowy rozdzia testowania
oprogramowania. Dynamiczne testowanie metodami szklanej skrzynki
upraszcza prac testera, dajc mu wgld w ukryt informacj, co warto jest
przetestowa. Poznawszy szczegy kodu, mona eliminowa zbdzne
zadania testowe i dodawa nowe zadania w miejscach, ktrych istnienia
nawet si z pocztku nie podejrzewao. I jedno, i drugie poprawi wydajnoc
testowania.
W rozdziaach 4 7 ponalimy podstawowe zasady testu oprogramowania:
176.Statyczne testowanie metodami czarnej
skrzynki, polegajce na badaniu specyfikacji i
wyszukiwaniu problemw zanim jeszcze
zostan wpisane w kod programu.
177.Dynamiczne testowanie metodami czarnej
skrzynki, polegajce na testowaniu
oprogramowania bez znajomoci wewntrznych
mechanizmw jego dziaania.
178.Stayczne testowanie metodami szklanej
skrzynki, polegajce na badaniu szczegw
kodu rdowego w postaci formalnych
przegldw i inspekcji.
179.Dynamiczne testowanie metodami szklanej
skrzynki, gdzie obserwuje si dziaanie
wewntrznych mechanizw programu i
dopasowuje zadania testowe do otrzymanej t
drog informacji.
W pewnym sensie, te cztery rozdziay obejmuj wszystko, co najwaniejsze

w testowaniu oprogramowania. Oczywicie, przeczyta w ksice a umie
zastosowa w praktyce to zupenie co innego. Trzeba wiele zaangaowania i
cikiej pracy, eby zosta dobrym testerem. eby umie zastosowa te
podstawowe techniki w praktyce, wiedzie ktra pasuje najlepiej w jakiej
sytuacji, trzeba wiele praktyki i dowiadczenia.
W czci 3-ej Zastosowanie umiejtnoci w praktyce poznamy rne
dziedziny testowania i zastosowanie umiejtnoci z czernej skrzynki i ze
szklanej skrzynki do rozmaitych rzeczywistych scenariuszy.
Pytania
1.W jaki sposb znajomo wewntrznych mechanizmw dziaania
programu wpywa na to, jak i co naley przetestowa?
2.Czy jest rnica midzy dynamicznym testowaniem metodami szklanej
skrzynki, a lokalizowaniem i usuwaniem bdw?
3.Jakie s dwa gwne powody, dla ktrych testowanie jest niemal
niewykonalne w modelu skokowym wytwarzania oprogramowania? Jak
mona im zaradzi?
4.Prawda czy fasz: jeli projektowi brakuje czasu, mona przeskoczy
testowanie moduw (jednostkowe) i przystpi od razu do tesowania
integracyjnego.
5.Jaka jest rnica midzy namiastk testow a sterownikiem testowym?
6.Prawda czy fasz: zawsze naley najpierw skonstruowa zadania testowe
metodami czarnej skrzynki.
7.Ktra jest najlepsza spord trzech opisanych w tym rozdziale metod
pomiaru pokrycia? Dlaczego?
8.Jaka jest najpowaniejsza trudno testowania metodami szklanej
skrzynki, zarwno statycznego jak i dynamicznego?
Strona 1 (99)
Cz III
praktyce
Zastosowanie umiejtnoci w
Na urodziny dostaem nawilasz i osuszacz Wstawiem je do jednego

pokoju i zostawiem, eby si ze sob rozprawiy.
Steven Wright, komik
Odkrycie polega na tym, e patrzy si na to samo co inni i myli co innego.
Albert Szent-Gyorgyi, laureat nagrody Nobla w medycynie i fizjologii w
1937 roku
W TEJ CZCI
Testowanie konfiguracji
Testowanie kompatybilnoci
Testowanie rnych wersji jzykowych
Testowanie atwoci korzystania
Testowanie dokumentacji
Testowanie witryn WWW
Strona 2 (99)
Rozdzia 8
W TYM ROZDZIALE
Przegld testowania konfiguracji
Jak podej do zadania
Jak zdoby potrzebny sprzt
Jak zidentyfikowa standardy sprztu
Testowanie konfiguracji innych typw sprztu
ycie mogoby by takie proste. Sprzt komputerowy mgby by tylko
jednego rodzaju. Wszelkie oprogramowanie mogoby by wytwarzane przez
tylko jedn firm. Nie byoby wtedy tych wszystkich mylcych przyciskw
do wyboru opcji do klikania i pl wyboru do wybierania. Wszystkie
interfejsy pasowayby od pocztku doskonale dla kadego. Jakie nudne1.
W rzeczywistym wiecie, w majcych po kilka tysicy metrw
kwadratowych powierzchni supermarketach komputerowych, stoj do
wyboru komputery, drukarki, monitory, karty komunikacyjne, modemy,
skanery, kamery cyfrowe, urzdzenia peryferyjne i setki innych
komputerowcyh gadetw wszystkie dajce si podczy do komuotera
domowego!
Dla pocztkujcego testera, jednym z pierwszych zada moe by
testowanie konfiguracji: sprawdzenie, e oprogramowanie dziaa z jak
najwiksz iloci rnych kombinacji sprztu. Rwnie testujc inne
rodzaje systemw ni najpopularniejsze pecety i Macintoshe, zagadnienie
konfiguracji trzeba wzi pod uwag. Umiejtnoci opisane w tym rozdziale
z atwoci mona dostosowa do takiej sytuacji.
Pierwsza cz rozdziau opisuje oglne zasady testowania konfiguracji
komputerw osobistych, a potem przechodzi si do szczegw na temat
testowania drukarek, kart wideo i kart dwikowych. Chocia przykady
dotycz komputerw osobistych, opisane metody mona atwo przenie na
prawie kade rodzaje testowania konfiguracji. Kadego dnia powstaj nowe
typy urzdze i zadaniem testerw jest wymyli sposoby ich testowania.
1. Czemu testowanie konfiguracji jest konieczne
2. Czemu testowanie konfiguracji bywa ogromnie
pracochonne
3. Podstawowe sposoby testowania konfiguracji
Czytelnikom polskim nalecym do troszeczk starszego ni najmodsze pokolenia przypominaj si

moe czasy bardzo zblione do tego ideau. Wcale jednak nie byo tak nudno
Strona 3 (99)
4. Jak wej w posiadanie potrzebnego sprztu
5. Jak postpowa testujc inne rodzaje
oprogramowania ni dla komputerw osobistych
Przegld testowania konfiguracji

Bdc z nastpn wizyt w sklepie komputerowym, warto przyjrze si
pudekom i poczyta opisy wymaga systemowych. Znajdzie si wrd nich
takie jak PC z procesorem 486/66 MHz, Super VGA, 256-kolorowy ekran,
16-bitowa karta dwikowa, port MIDI dla gier itd. Testowanie konfiguracji
to proces kontrolowania, czy testowane oprogramowanie dziaa z tymi
wszystkimi rozmaitymi rodzajami sprztu. Warto rozway rne moliwe
konfiguracje standardowego komputera osobistego, jaki stoi w wielu
domach i w prawie kadym biurze:
6. Komputer. S dziesitki znanych producentw:
Compaq, Dell, Gateway, Hewlett-Packard, IBM
i wielu innych. Kady producent konstruuje i
produkuje komputery osobiste albo z
komponentw wasnej konstrukcji, albo z czci
kupionych od innych producentw. Wasne
komputery osobiste produkuje te wielu mniej
znanych, maych producentw; robi je nawet
hobbyci-amatorzy.
7. Komponenty. Wikszo komputerw
osobistych ma moduow budow. Skadaj si
z kart gwnych, kart dodatkowych i rozmaitych
urzdze takich jak stacje dyskw, stacje CDROM, wideo, dwik, modem, karty siciowe
(rysunek 8.1). Istniej karty telewizyjne i
wyspecjalizowane karty do nagrywania wideo,
do automatyzacji urzdze domowych itd.
Istniej nawet karty wejcia i wyjcia, ktre s w
stanie zamieni komputer osobisty w jednostk
zdoln pokierowa niewielk fabryk.
Urzdzenia wewntrzne s wytwarzane przez
setki rnych producentw.
stacja dyskietek
stacja dysku twardego
urzdzenie dopasowujce I/O
stacja CD-ROM
adapter wywietlacza
zasilacz
magistrala
jednostka systemowa
karta gwna.
Rysunek 8.1 Liczne wewntrzne komponenty skadaj si na konfiguracj

PC.
Strona 4 (99)
8. Urzdzenia peryferyjne. Rysunek 8.2 pokazuje
drukarki, skanery, mysz, klawiatur, monitory,
aparaty fotograficzne, kamery, joysticki i inne
urzdzenia, ktre podcza si do komputera i
ktre dziaaj poza nim.
skaner
drukarka
joystick (manipulator)
jednostka gwna
kamera cyfrowa
mysz
Rysunek 8.2 Komputer osobisty mona podczy do rozmaitych urzdze

peryferyjnych.
9. Interfejsy. Komponenty i urzdzenia
peryferyjne podcza si do do komputera przez
rne rodzaje zczy (rysunek 8.3). Interfejsy
mog by wewntrzne albo zewntrzne. Ich
nazwy: ISA, PCI, USB, PS/2, RS/232, Firewire.
Istnieje tak wiele rnych moliwoci, e
producenci niekiedy produkuj to samo
urzdzenie pod rnymi nazwami. Na przykad
ten sam model myszy mona czsto kupi w
trzech rnych konfiguracjach!
10. Opcje i pami. Wiele komponentw i urzdze
peryferyjnych mona kupi z rnymi opcjami
sprztu i wielkociami pamici. Drukark mona
uaktualni, eby obsugiwaa wicej wzorw
liter albo uywaa wicej pamici, eby
drukowanie szo szybciej. Karty graficzne
majce wicej pamici potrafi obsugiwa
dodatkowe kolory i grafik o wikszej
rozdzielczoci.
11. Programy obsugi. Wszystkie komponenty i
urzdzenia peryferyjne komunikuj si z
systemem operacyjnym i z aplikacjami za
pomoc procedur na niskim poziomie, zwanych
programami obsugi. Czsto dostarczone s one
przez producenta sprztu i instaluje si je w
trakcie procesu ustawiania sprztu. Chocia w
sensi technicznym programy obsugi s
oczywicie oprogramowaniem, z punktu
widzenia testu zalicza si je do konfiguracji
sprztu.
Strona 5 (99)
Rysunek 8.3 Ty komputera osobistego zawiera liczne zcza do przyczania

urzdze peryferyjnych.
Tester przygotowujcy si do rozpoczcia testowania konfiguracyjnego
jakiego programu, powinien rozway jaka konfiguracja bdzie najbardziej
typowa dla tego programu. Gra komputerowa z mnstwem efektw
graficznych bdzie wymagaa zwrcenia uwagi na wideo i dwiki. program
do robienia kolorowych widokwek bdzie szczeglnie uzaleniony od
drukarek. program faksowy lub telekomunikacyjny naley przetestowa z
rnymi typami modemw i konfiguracji sici.
Czemu waciwie miaoby to wszystko by konieczne? Istniej przecie
standardy, ktre dotycz w jednakowym stopniu komputera osobistego
kupowanego w supermerkecie i specjalnego komputera w szpitalu. Mona
chyba oczekiwac, e jeli sprzt zosta skonstruowany zgodnie ze
standardami, to oprogramowanie powinno po prostu na nim dziaa bez
adnych kopotw. W wiecie idealnym pewnie by tak byo, ale niestety - w
rzeczywistoci standardy nie zawsze s przestrzegane. Niektre standardy s
do lune nazwijmy je zbiorami dobrowolnych regu. Producenci kart i
urzdze peryferyjnych dziaaj w sytuacji ostrej konkurencji i czsto
naginaj zasady, aby wcisnc w swj produkt jeszcze jedn now funkcj
albo jeszcze odrobin wysz wydajno. Czsto programy obsugi do
nowych urzdze wrzuca si do pudeka niemal w momencie, gdy dostawy
sprztu zaczynaj opuszcza bramy fabryki. W wyniku tego nie ra si
zdarza, e oprogramowanie nie dziaa z niektrymi konfiguracjami sprztu.
Lokalizacja bdw konfiguracji
Bdy konfiguracji mog by naprawd bolesne. Pamitamy przecie
jeszcze bd Krla Lwa opisany w rozdziale 1-ym? To by typowy
problem konfiguracji. Dwik programu nie dziaa na kilku zaledwie, ale
bardzo popularnych konfiguracjach sprztu. Ktokolwiek gra w gr
komputerow albo posugiwa si aplikacja graficzn, kiedy kolory nagle
oszalay, albo kawaki okna odupyway si kiedy si je cignlo,
przypuszczalnie zetkn si z bdem programu obsugi karty graficznej.
Ktokolwiek powici dugie godziny (albo dni!) usiujc zmusi stary
program do dziaania z now drukark, te mia zapewne do czynienia z
bdem konfiguracji.
Strona 6 (99)
Pewnym sposobem stwierdzenia, czy ma si do czynienia z bdem
konfiguracji czy po prostu ze zwykym bdem, jest powtrzenie
dokadnie tego samego dziaania, krok po kroku, na innym komputerze z
zupenie odmienn konfiguracj. Jeli awaria nie nastpuje, prawie na
pewno mamy do czynienia z bdem konfiguracji. Jeli awaria wystpuje
na wicej ni jednej konfiguracji, to zapewne jest to zwyczajny bd.
Przypumy e testujc program na jakiej szczeglnej konfiguracji
natrafiamy na problem. Kto tera powinien naprawi bd zesp
wytwarzajcy oprogramowanie czy te producent sprztu? Moe tu chodzi
o miliony dolarw.
Przede wszystkim trzeba zlokalizowa problem. Zwykle wie si to z
dynamicznym testowaniem metodami szklanej skrzynki i wysikiem
znajdowania i naprawiania bdu. Problem konfiguracyjny moe wystpi z
wielu rnych powodw, z ktrych kady wymaga starannego przebadania
kodu dziaajcego w rnych konfiguracjach:
12. Oprogramowanie moe mie bd wystpujcy
w wielu rnych konfiguracjach. Na przykad,
program do produkcji kartek z yczeniami moe
dziaa z drukarkami laserowymi, ale nie z
atramentowymi.
13. Oprogramowanie moe mie bd pojawiajcy
si tylko w jednej, szczeglnej konfiguracji na
przykad nie dziaa na modelu OkeeDoKee
BR549 super drukarki atramentowej.
14. Urzdzenie albo jego program obsugi zawiera
ukryty bd, ktry powoduje awari tylko
jednego programu. Moe ten program jest
jedynym, ktry uywa jakich ustawie karty
wideo? Taki program w poczeniu z wadliwym
modelem karty powoduje awari.
15. Urzdzenie albo jego program obsugi zawiera
bd, ktry wprawdzie widoczny jest z wieloma
programami, ale szczeglnie rzuca si w oczy z
jednym z nich. Przykadem moe by program
obsugi drukarki, ktry jako warto domyln
zawsze wybiera jako robocz wydruku, wic
aplikacja musi go do kadego wydruku
przestawia na tryb druku wysokiej jakoci.
W dwch pierwszych przykadach zesp projektu wytwarzajcego
oprogramowanie jest oczywicie odpowiedzialny za naprawienie bdu.
Strona 7 (99)
W obu nastpnych przykadach sytuacja nie jest ju oczywista. Powiedzmy
e bd jest bdem drukarki i e ten model jest najpopularniejszy na wiecie
ma dziesi milionw uytkownikw. Niewtpliwie, program musi dziaa
z t wanie drukark. Chocia program nie zawiera adnego bdu, ale
przypuszczalnie napraw w postaci jakiego obejcia tego bdu i tak
wykona zesp wytwarzajcy aplikacj.
Niezalenie od rda problemu, odpowiedzialno i tak spada na
producenta aplikacji. Klienci nie bd chcieli sucha tumacze, e to
wadliwy sprzt jest przyczyn bdu, bd po prostu chcieli, eby aplikacja
dziaaa na ich konfiguracji.
O kartach dwikowych
W 1997 roku Microsoft wypuci na rynek lalk AntiMates Barney wra z
oprogramowaniem na CD, majce uczy dzieci programowania.
Oprogramowanie kontaktowao si z lalk za pomoc dwukierunkowego
cza radiowego, umieszczonego w lalce i w komputerze osobistym.
Radio w komputerze byo podczone do rzadko uywanego interfejsu
kart dwikowych, zwanego zczem MIDI. Tego interfejsu uywa si do
podczania sprztu muzycznego. Microsoft wyszed z zaoenia, e to
cze jest dobrym wyborem, gdy wikszo posiadaczy komputerw
osobistych nia ma tego rodzaju sprztu muzycznego. Karta miaaby wic
to zcze wolne, dostpne do podczenia radia do komunikacji z lalk.
Podczas testowania konfiguracyjnego odkryto typow ilo bdw. Jedne
byy problemami karty dwikowej, inne bdami w oprogramowaniu
ActiMates. Jednak jednego bdu nie udao si nigdy zlokalizowa.
Wygldao na to, e od czasu do czasu, losowo, komputer osobisty nagle
si zawiesza i wymaga ponownego wystartowania. Problem wystpowa
tylko z jednym typem karty dwikowej najpopularniejszej na rynku
(oczywiocie).
Kiedy w harmonogramie pozostao jeszcze tylko kilka tygodni, podjto
wzmoone wysiki eby rozwiza problem. Po intensywnym testowaniu
konfiguracyjnyem i poszukiwaniu bdu, udao si znale jego przyczyn
winna bya karta. Wygldao na to, e zlcze MIDI tej karty zawsze
miao ten bd, tylko e uywano je na tyle rzadko, e bd nigdy nie
zosta odkryty. Oprogramowanie ActiMates ujawnio go po ra pierwszy.
Strona 8 (99)
Zrobi si wielki baagan, peno zaprzeczania i wzajemnego wytykania si
palcami, i wiele pracy pno w nocy. W kocu producent kart
dwikowych przyzna, e problem istnia i obieca znale obejcie bdu
w nowych wersjach programu obsugi. Microsoft zainstalowa
poprawiony program obsugi na CD-ROM sprzedawanym z lalk
ActiMate i dokona pewnych zmian w programie tak, eby bd rzadziej
powodowa awarie. Mimo tych wszystkich wysikw, te wanie problemy
z kompatybilnoci karty dwikowej byy najczstszym powodem
pniejszych telefonw do serwisu.
Dobr wielkoci zadania
Testowanie konfiguracyjne moe by wielkim przedsiwziciem.
Wyobramy sobie testowanie nowej gry, ktra ma by wykonywana na
Microsoft Windows. Gra ma mnstwo grafiki, duo efektw dwikowych,
pozwala wielu graczom zmierzy si ze sob przy pomocy pocze
telefonicznych oraz wykonywa wydruk szczegw gry dla celw
planowania strategii.
Testowanie konfiguracji naley zaplanowa co najmniej z rnymi kartami
graficznymi, dwikowymi, modemami i drukarkami. Asystent funkcji
Windows Dodaj nowy sprzt (rysunek 8.4) umoliwia wybranie sprztu w
kadej z tych kategorii i jeszcz 25-ciu innych.
Rysunek 8.4 Okno dialogowe asystenta Dodaj Nowy Sprzt umoliwia

dodawanie nowych urzdze do aktualnej konfiguracji PC.
W kadej kategorii sprztu znajduje si lista rnych producentw i modeli
(rysunek 8.5). Pamitajmy, e to s tylko rodzaje sprztu, dla ktrch
programy obsugi s wbudowane bezporednio w system Windows. Wielu
innych producentw sprztu dostarcza wra ze sprztem wasne dyski z
potrzebnym oprogramowaniem.
Strona 9 (99)
Rysunek 8.5 Kady rodzaj sprztu ma wielu rnych producentw i wiele

modeli.
Chcc przeprowadzi peny, obejmujcy wszelkie moliwoci test
konfiguracji, kontrolujcy wszelkie rodzaje i modele sprztu, ma si
olbrzymi robot.
Istnieje w przyblieniu 336 rnych kart graficznych, 210 kart
dwikowych, 1500 modemw i 1200 drukarek. Ilo kombinacji testowych
wynosi wic 336 x 210 x 1500 x 1200, co daje iloczyn rzdu miliardw
zbyt wiele by mc powanie o tym myle !
Jeli ograniczy testowanie tak, by wykluczy wszelkie kombinacje, tylko
testowa kady rodzaj karty osobno, powicajc okoo 30 minut na kad
konfiguracj, byoby si gotowym po upywie okoo roku. Pamitajmy,
wyliczenie dotyczny tylko jednego wykonania testw przez wszelkie
kombinacje, a przecie czsto uwzgldniwszy dostawy z naprawami
bdw trzeba wykona dwa lub trzy wykonania testw, dopki produkt
nie bdzie ostatecznie wypuszczony na rynek.
Rozwizaniem tego baaganu jest czego (naley mie nadziej) czytelnik
ju si domyla podzia na klasy rwnowanoci. Trzeba znale sposb,
jak ograniczy olbrzymi zbir wszelkich moliwych konfiguracji tak, aby
pozostay tylko najwaniejsze. Oczywicie nie testujc wszystkiego trzeba
bdzie podj pewne ryzyko, ale przecie wanie na tym polega test
oprogramowania.
Jak podej do zadania

Proces podejmowania decyzji, ktre urzdzenia naley przetestowa i w jaki
sposb jest w zasadzie nieskomplikowanym zastosowaniem podziau na
klasy rwnowanoci. Najwaniejsze kluczowe dla powodzenia projektu
jest znalezienie waciwej informacji przed podjciem decyzji. Jeli brak
nam dowiadczenia z rodzajem sprztu, jaki testowany program
wykorzystuje, trzeba si nauczy samemu ile si da oraz poprosi innych,
dowiadczonych testerw i programistw o pomoc. Trzeba zadawa wiele
pyta i upewni si, czy propozycje zostay zaakceptowane.
Strona 10 (99)
Nastpne podrozdziay opisuj oglny proces planowania testowania
konfiguracji.
Zdefiniowanie potrzebnych rodzajw sprztu
Czy aplikacja robi wydruki? Jeli tak, trzeba bdzie przetestowa drukarki.
Jeli ma efekty dwikowe, trzeba bdzie testowa karty dwikowe. Jeli
jest to program graficzny albo fotograficzny, pewnie przydadz si skanery i
cyfrowe aparaty fotograficzne. Warto uwanie pozna funkcje programu,
aby upewni si, czy niczego wanego si nie pomino w trakcie
planowania. Trzeba przez chwil zastanowi si, czego ten program bdzie
potrzebowa do dziaania.
Interakcyjna rejestracja
Przykadem funkcji, ktr atwo przeoczy przy planowaniu, jaki sprzt
naley przetestowa, jest rejestracja interakcyjna. Wiele programw
umoliwia dzisiaj uytkownikom dokonanie rejestracji podczas instalacji
przez modem. Uytkownik wpisuje swoje nazwisko, adres i inne dane,
klika na przycisk, a modem dzwoni do komputera i producenta, ktry
przesya potrzebn informacj i dokonuje rejestracji. Nawet jeli program
nie uywa takiego poczenia do adnej innej pracy oprcz interakcyjnej
rejestracji, trzeba zastanowi si, czy modemy maj by czci
testowania konfiguracyjnego.
Zadecydowa jakie s dostpne marki, modele i programy obsugi
urzdze
Ten kto wytwarza ostry program graficzny, nie bdzie chyba chcia testowa
jego wydrukw na czarno-biaej drukarce mozaikowej z roku 1987-ego
(pamitacie je jeszcze?). List sprztu do testowania konfiguracji warto
skompilowa wsplnie ze sprzedawcami i z osobami zajmujcymi si
marketingiem. Jeli nie mog lub nie chc pomc, warto zapa kilka
aktualnych i starszych numerw tydnika PC i zorientowa si, jakie
rodzaje sprztu s dostpne i co byo i jest popularne. Tego typu
czasopisma czsto publikuj rnego rodzaju listy i porwnania drukarek,
kart dwikowych i graficznych.
Warto si zorientowa, ktre z tych urzdze s klonami i dlatego
naecymi do tej samej klasy rwnowanoci co orygina. Zdarza si, e
producent drukarek sprzedaje swoje drukarki innej firmie, ktra nastpnie
umieszcza na nich swoj etykietk. Z punktu widzenia testowania
konfiguracji, mamy do czynienia z t sam drukark.
Strona 11 (99)
Trzeba te wzi pod uwag, ktre programy obsugi wykorzysta podczas
testowania. Do wyboru ma si zwykle program obsugi bdcy czci
systemu operacyjnego, program dostarczany razem z urzdzeniem oraz
najnowsz wersj programu obsugi dostpn na Internecie, na stronie
producenta urzdzenia lub systemu operacyjnego. Zwykle s to trzy rne
programy. Trzeba sobie samemu zada pytanie, co klienci maj lub bd
mie.
Zdefiniowanie moliwych cech, trybw pracy i opcji
Kolorowe drukarki potrafi drukowa czarno-biao albo w kolorze, w
rnych trybach jakoci, mog te mie ustawienia dla drukowania
fotografii albo tekstu. Karty graficzne, jak pokazano na rysunku 8.6, mog
uuwa rnych ustawie kolorw i rnej rozdzielczoci.
Rysunek 8.6 Rne odmiany kolorw i inne waciwoci ekranu to przykady

moliwych konfiguracji karty graficznej.
Kade urzdzenie ma rozmaite opcje. Testowany program nie musi
wykorzystywa wszystkich opcji urzdzenia. Dobrym przykadem s gry
komputerowe. Wiele z nich wymaga pewnej minimalnej iloci kolorw i
pewnej minimalnej rozdzielczoci, bez ktrych nie bd dziaa.
Zmniejszenie liczby konfiguracji do dajcej si opanowa iloci
Przy zaoeniu, e nie ma si do dyspozycji czasu ani budetu by
przetestowa wszystko, musi si zredukowa tysice moliwych
konfiguracji do najwaniejszych tych ktre si rzeczywicie przetestuje.
Sposobem moe by wprowadzenie wszelkich informacje na temat
konfiguracji do arkusza kalkulacyjnego, gdzie kolumy oznaczaj
producenta, model, wersj programu obsugi i warto opcji. Rysunek 8.7
pokazuje przykad tabeli, ktra opisuje rne konfiguracje drukarek. Zespl
testowy lub jego szef moe zapozna si arkuszem i zdecydowac, jakie
konfiuguracje chce si testowa.
Laser
XXX
LDYI2000
1.0
Czarnobiay
Opcje
Opcje
Wersja programu obsugi
Model
Producent
Wiek (w latach)
Typ (laser/atramentowa)
Popularno (1=najwiksza,
10=najmniejsza)
Strona 12 (99)
Roboczy
Wysokiej
jakoci
Atramento
wy
XXX
IJDIY2000
1.0a
Kolor
Roboczy
Czarnobiay
Wysokiej
jakoci
Roboczy
Wysokiej
jakoci
Atramento
wy
XXX
IJDIY2000
2.0
Kolor
Arytstyczny
Czarnobiay
Fotografia
Roboczy
Wysokiej
jakoci
10
Laser
YYY
LJ100
1.5
Czarnobiay
100 dpi
200 dpi
300 dpi
Strona 13 (99)
2
Atramento
wy
YYY
EasyPront
1.0
Auto
600 dpi
Strona 14 (99)
Rysunek 8.7 Warto wprowadzi dane na temat konfiguracji do arkusza
kalkulacyjnego.
Warto zwrci uwag, e tabela na rysunku 8.7 ma take kolumny na
informacje o popularnoci urzdzenia, jego typie i wieku. Konstruujc klasy
rwnowanoci, mona np. podj decyzj, e bdzie si testowao tyko
najpopularniejsze rodzaje drukarek, albo tyko te modele, ktre maj mniej
ni pi lat. Na podstawie informacji o typie w tym przykadzie, laserowa
albo atramentowA mona zadecydowa, e przetestuje si 75% drukarek
laserowych i 25% - atramentowych.
Niestety, proces decyzyjny, gdzie dzieli si moliwe konfuguracje na
mniejsze klasy rwnowanoci, zaley od wyboru dokonanego przez
zesp projektowy. Nie istnieje jedna, wycznie poprawna regua. Kady
projekt wytwarzania oprogramowania jest inny i nieatwo bdzie dobra
kryteria klasyfikacji. Wystarczy upewni si, e kady w zespole, a
zwaszcza kierownik projektu, zawiadomieni s o tym, co si testuje i w
jaki sposb wybrane zostay testowe zmienne, ktrych warto
zadecydowaa o podziale.
Zidentyfikowanie tych szczeglnych cech oprogramowania,
ktrych dziaanie zaley od konfiguracji sprztu
Najwaniejsze sowo w tytule to szczeglne. Nie chodzi o to, by kompletnie
przetestowa ca aplikacj na kadej moliwej konfiguracji. Wystarczy
przetestowa tylko te cechy, ktrych dziaanie zaley od sprztu.
Na przykad, testujc program do przetwarzania tekstu taki jak WordPad
(zob. rysunek 8.8), nie trzeba bdzie np. testowa zapisywania i adowania
plikw w kadej z konfiguracji. Zapisywanie i adowanie plikw nie ma nic
wsplnego z drukowaniem. Dobre dane testowe skadayby si z
dokumentu, zawierajcego rozmaite (wybrane oczywicie przy pomocy
podziau na klasy rwnowanoci) czcionki, wielkoci, kolory, ilustracje w
tekcie i tak dalej. Ten dokument drukowaoby si na wszystkich
konfiguracjach drukarek.
Rysunek 8.8 Do przetestowania konfiguracji drukarek mona uywa

dokumentu zawierajcego rne czcionki i style.
Strona 15 (99)
Wybranie funkcji zalenych od konfiguracji i sprztu moe by trudniejsze
ni si wydaje na pierwszy rzut oka. Naley zaczc od techniki czarnej
skrzynki i przetestowa oczywiste pod tym wzgldem funkcje. Potem warto
porozmawia z innymi osobami z zespou, zwaszcza z programistami, aby
uzyska obra szklanoskrzynkowy. Nie ra zdziwimy si, odkrywajc jak
na pozr odlege funkcje w jakim stopniu mog zalee od konfiguracji
sprztu.
Skonstruowanie zada testowych do uycia na kadej konfiguracji
Jak pisa zadania testowe bdzie tematem rozdziau 17-ego, Pisanie i
ledzenie zada testowych. Ju tera jednak warto zda sobie spraw, e
trzeba bdzie zanotowa wszystkie kroki potrzebne do przetestowania
kadej z konfiguracji. Moe to by tak proste jak ponisza lista:
1. Wybra i ustawi kolejn konfiguracj z listy
2. Wystartowa oprogramowanie
3. Zaadowa plik configtest.doc.
4. Potwierdzi, e wylwietlony plik jest
prawidowy
5. Wydrukowa dokument
6. Potwierdzic, e nie ma adnych komunikatw o
bdach i e wydrukowany dokument zgodny
jest ze standardem
7. Wszelkie rozbienoci notowa jako bdy
W rzeczywistoci, te instrukcje byyby znacznie bardziej skomplikowane,
zawierajce wicej szczgw na temat tego, co dokadnie naley zrobi. W
kocu przecie autor tej specyfikacji nie chciaby osobicie wykonywa tych
testw w przyszoci.
Wykonanie testw na kadej konfiguracji
Trzeba wykona zadania testowe i starannie zarejestrowa wyniki i napisa
na ich podstawie raport (zob. rozdzia 18-y, Raportowanie tego, co si
znalazo) dla zespou, a w razie koniecznoci take dla producenta. Jak
ju napisano wczeniej, czsto zidentyfikowanie rda problemu z
konfiguracj jest trudne i czasochonne. Trzeba wsppracowa z
programistami i testerami stosujcymi metody szklanej skrzynki aby znal
przyczyny awarii i zdecydowa, czy spowodowa j bd oprogramowania,
czy bd sprztu.
Strona 16 (99)
Jeli przyczyn awarii jest bd sprztu, naley poszuka w portalu
internetowym producenta sposobu raportowania bdw sprztu. Piszc
raport, warto przedstawi si jako tester oprogramowania i poda nazw
swego pracodawcy. Wiele firm ma osobny personel, ktry udziela pomocy
firmom piszcym oprogramowanie uywajce ich sprztu. Dla uatwienia
lokalizacji przyczyny bdu, producent sprztu moe prosi o przesanie
kopii oprogramowania, zada testowych i szczegw na temat okolicznoci
zaistnienia awarii.
Ponowne wykonywanie zada testowych a do skutku
Czsto test konfiguracji cignie si przez cay czas trwania projektu.
Pocztkowo prbuje si kilka konfiguracji, potem peny zestaw, potem znw
tylko wybrane konfiguracje dla zweryfikowania zrobionych poprawek. W
kocu nadchodzi moment, kiedy nie ma ju wicej znanych bdw, a
pozostae bdy wystpuj w rzadkich i mao prawdopodobnych
konfiguracjach. W tym momencie s podstawy, aby uzna testowanie
konfiguracji za zakoczone.
Jak zdoby potrzebny sprzt

Nie mwilimy jeszcze dotd jak wej w posiadanie caego tego sprztu.
Nawet dokonujc pracochonnej i ryzykownej redukcji zestawu klas
rwnowanoci do niezbdnego minimum, nadal potrzebuje si dziesitek
rnych zestaww sprztu. Kupi wszystko w sklepie jest kosztownym
rozwizaniem, zwaszcza jeli niektre elementy sprztu uyje si tylko raz.
Oto kilka sposobw, aby rozwiza ten kopot:
16. Kupuje si tylko t konfiguracj, ktrej si
bdzie uywao najczciej. Doskona metod
jest, aby kady tester w zespole posugiwa si
innym sprztem. To moe doprowadzi dziay
zaopetrzeniowy i administratorw systemu do
szau (dla nich jest najlepiej, aby kady
przcownik posugiwa si identyczn
konfiguracj), ale to bardzo skuteczny sposb,
aby zawsze mc testowa na rnych
konfiguracjach. Nawet w maym zespole, mie
do dyspozycji trzy cztery rne konfiguracje
jest bardzo cenne.
Strona 17 (99)
17. Warto skontaktowa si z producentami i
sprbowa poyczy czy wrcz dosta sprzt.
Jeli wytumaczy, e testuje si nowe
oprogramowanie i chce si upewnic, czy dziaa
na ich sprzcie, wielu producentw moe si
zgodzi. Oni s rwnie zainteresowani
wynikami, wic mona im obieca przekazanie
wynikw testw, a jak si da rwnie kopi
gotowego oprogramowania. Warto stworzy
dobre relacje, zwaszcza jeli znalazo si bd i
potrzenbujemy u producenta kogo, komu
mona przekaza informacj o bdzie.
18. Mona wysa poczt komputerow do
wszystkich w swojej firmie, z pytaniem jakiego
sprztu uywaj w pracy, a nawet w domu, i czy
pozwoliliby wykona na nim kilka testw.
Wykonujc w ten sposb testowanie
konfiguracji, trzeba bdzie si najedzi, ale ile
to taniej ni kupowanie wszystkiego samemu.
Testowanie konfiguracji magnetowidu
Animowane lalki Microsoftu ActiMates miay intefejs nie tylko do PC,
ale rwnie do magnetowidu. Specjalne pudeko doczone do
magnetowidu odczytywao komendy i wysysao je do lalki drog
radiow. Zesp testujcy mia do dyspozycji wiele konfiguracji PC, ale
adnego magnetowidu.
Znaleziono dwa sposoby rozwizania problemu:
Poproszono ponad 300 pracownikw, aby przynieli do pracy swoje
magnetowidy. Kierownik ogosi drobne nagrody dla zachcenia
uczestnikw.
Zapacono kierownikowi w lokalnym sklepie z elektronik , aby
pozosta w pracy po godzinach. W tym czasie testerzy wycigali z
pki kady magnetowid, podczali sprzt i wykonywali test. Kady
poyczony magnetowid zost dodatkwo odkurzony i oczyszczony, a
kierownikowi ktry si na to zgodzi zafundowano dobry obiad.
Kiedy wszystko byo ju gotowe, przetestwoano ponad 150
magnetowidw, ktre stanowiy dobr
klas rwnowanoci dla
magnetowidw posiadanych przez ludzi.
Strona 18 (99)
19. Kto dysponuje wasnym budetem, moe
sprbowa wynaj do testowania zajmujce si
zawodowo testowaniem kompatybilnoci i
konfiguracjji laboratorium1. Te firmy zajmuj si
wycznie testowaniem konfiguracji i maj do
dyspozycji wszelki znany ludzkoci sprzt PC.
No, moe nie a tyle, ale prawie.
Taka firma czsto jest w stanie pomc dokona wyboru waciwego
sprztu, na ktrym przeprowadzi si testowanie. Nastpnie ma si do
dyspozycji dwie opcje: albo samemu wykonuje si testowanie na sprzcie
firmy, albo mona te zakupi pen usug. Klient dostarcza
oprogramowanie, instrukcje testowanie oraz oczekiwane wyniki. Od tego
miejsca prac przejmuje firma, wykonuje testy i sporzdza raporty, ktre
zadania testowe przeszy, a ktre nie. Bywa to kosztowne, ale na pewno
mniej kosztowne ni kupowanie caego sprztu albo brak testowania i
klienci znajdujcy bdy.
Jak zidentyfikowa standardy sprztu

Kto chciaby powici nieco czasu analizie metodami czarnej skrzynki to
znaczy przejrze specyfikacje, uywane przez firmy wytwarzajce sprzt
komputerowy moe szuka w kilku miejscach. Znajc nieco lepiej
specyfikacj sprztu bdziemy mogli dokona bardziej wiadomego wyboru
najwaciwszych klas rwnowanoci.
Dla sprztu Applea trzeba zajrze na stron
http//:developer.apple.com/hardware. Znajdzie si tam doczenia na
temat wytwarzania i testowania sprztu i programw obsugi dla
komputerw Apple. Inne doczenie Applea,
http://developer.apple.com/testing, zawiera wiadomoci na temat testowania,
a take doczenia do laboratoriw zajmujcych si testowaniem
konfiguracji.
Dla komputerw osobistych, najlepsze doczenie to
http://www.pcdesignguide.org/. T witryne sponsoruj wsplnie Intel i
Microsoft. Znale tam mona wiadomoci i doczenia do standardw
stosowanych do wytwarzania sprztu i urzdze peryferyjnych dla PC.
Standardy podlegaj corocznej rewizji i otrzymuj nazwy PC99, PC2000 i
tak dalej.
Micorsoft publikuje zestawienia standardw dla oprogramowania i sprztu
ubiegajcego si o znak firmowy Windows. Ta informacja znajduje si na
http://msdn.micorsoft.com/certification oraz na
http://www.microsoft.com/hwtest.
Testowanie konfiguracji innych typw sprztu

1
Moliwo na razie niedostpna na rynku polskim (przyp. tumacza).
Strona 19 (99)
C wic pocz, jeli testuje si oprogramowanie na innych komputerach
ni PC i Mac? Czy cay ten rozdzia by marnowaniem czasu? W adnym
razie. Wszystko, czegomy si tutaj nauczyli, daje si zastosowa take do
testowania wasnych systemw firmowych. Niewane, o jaki chodzi sprzt i
oprogramowanie, do czego podczone. Jeli co podczone jest do
czegokolwiek innego, testowanie konfiguracji staje si potrzebne.
Testujc oprogramowanie dla systemu wbudowanego, sieci, urzdzenia
medycznego czy systemu telefonicznego, naley sobie zada te same
pytania, co dla komputera osobistego:
20. Jaki zewntrzny sprzt bdzie pracowa z tym
oprogramowaniem?
21. Jakie s dostpne modele i wersje tego sprztu?
22. Jakie funkcje i opcje obsuguje dany sprzt?
Naley najpierw stworzy klasy rwnowanoci przy pomocy wiadomoci
uzyskanych od osb pracujcych na danym sprzcie, kierownikw
projektw albo sprzedwacw. Nastpnie wytwarza si zadania testowe,
gromadzi potrzebny sprzt i wykonuje testy. Testopwanie konfiguracji
stosuje si do tych samych zasad, ktrych nauczylimy si ju wczeniej.
Podsumowanie
Ten rozdzia nauczy nas myle na temat testowania konfiguracji. To
zadanie czsto otrzymuj do wykonania pocztkujcy testerzy, poniewa
nietrudno je zdefiniowa, jest dobrym wprowadzniem do podstawowych
danych o firmie i do zastosowania podziau na klasy rwnowanoci w
praktyce. Ponadto to zadanie pozwoli na kontakt z wieloma innymi osobami
z projektu, a kierownictwo bez trudu samo zweryfikuej jego wyniki. Ma te
wad jest przygnebiajco rozlege.
Jeli otrzymao si za zadanie test komnfiguracji w projekcie, naley wzi
geboki oddech, ponownie przeczyta ten rozdzia, uwanie zaplanowa
prac i wykaza wiele cierpliwoci. Kiedy wszystko bdzie ju gotowe, szef
przyjdzie z kolejnym wyzwaniem: testowaniem kompatybilnoci, tematem
kolejnego rozdziau.
Pytania
Pytania maj na celu uatwienie zrozumienia. W aneksie A Odpowiedzi na
pytania znajduj si prawidowe rozwizania ale nie naley ciga!
1.Jaka jest rnica midzy komponentem a urzdzeniem peryferyjnym?
2. Jak odrzni, czy bd jest oglnym problemem,
czy te wycznie bdem konfiuracji?
3. Jak mona zagwarentowa, e program nigdy
nie bdzie mia bdw konfiguracji?
Strona 20 (99)
4. Prawda czy fasz: klonowana karta dzwikowa
nie musi by poddana testowaniu konfiguracji.
5. Oprcz wieku oraz popularnoci, jakie inne
kryteria mona zastosowa jako podstaw
podziau na klasy rwnowanoci?
6. Czy dopuszczalne jest wypuszczenie programu
majcego bdy konfiguracji?
Strona 21 (99)
Rozdzia 9
Testowanie kompatybilnoci
W TYM ROZDZIALE
Przegld testowania kompatybilnoci
Rne platformy i wersje aplikacji
Standardy i normy
Kompatybilno wsplnych danych
W rozdziale smym poznalimy testowanie konfiguracji sprztu i to, w jaki
sposb mona upewni si, e oprogramowanie dziaa poprawnie ze
sprztem, dla ktrego zostao zaprojektowane. Obecny rozdzia zajmuje si
pokrewnym obszarem testowania interakcji sprawdzaniem, czy
oprogramowanie wsppracuje poprawnie z innymi programami.
Testowanie czy program wspgra z innymi programami zyskao na
znaczeniu, odkd konsumenci domagaj si moliwoci posugiwania si
jednym zestawem danych przez programy rnych rodzajw od rnych
dostawcw, a take jednoczesnego posugiwania si kilkoma programami.
Dawniej kady program dziaa jako oddzielna aplikacja. Wykonywao si
go w znanym, zrozumiaym i yczliwym otoczeniu, z dala od wszelkich
zagraajcych oddziaywa. Dzisiaj program prawdopodobnie importuje i
eksportuje dane z rnych innych programw, jest wykonywany na rnych
systemach operacyjnych i na rnych przegldarkach i musi wsppracowa
z innymi programami wykonywanymi jednoczenie na tym samym
komputerze. Zadaniem testowania kompatybilnoci oprogramowania jest
sprawdzenie, czy to wszystko dziaa tak, jak oczekuj uytkownicy.
Najwaniejsze punkty tego rozdziau to:
23. Co to znaczy, e oprogramowanie jest
kompatybilne
24. Jak kompatybilno definiowana jest przez
standardy
25. Co to s platformy i jakie maj znaczenie dla
kompatybilnoci
26. Czemu mono przesyania danych midzy
rnymi aplikacjami jest kluczem do
kompatybilnoci
Przegld testowania kompatybilnoci
Strona 22 (99)
Testowanie kompatybilnoci oprogramowania oznacza kontrol, czy badany
program wsppracuje poprawnie z innymi programami i czy przepyw
danych odbywa si prawidowo. Takie wspdziaanie zwykle ma miejsce
midzy programami wykonywanymi na tym samym komputerze, albo nawet
na rnych komputerach, poczonych przez Internet i odleglych od siebie o
tysice kilometrw. Wspdziaanie moe by te zupenie proste jak
zapisanie danych na dyskietce i przeniesienie jej w rku do innego
komputera w tym samym pokoju.
Oto rne przykady kompatybilnoci oprogramowania:
27. Wycicie tekstu ze strony internetowej i
wklejenie go do dokumentu otwartego w
programie do przetwarzania tekstu
28. Zapisanie danych finansowych z jednego
arkusza kalkulacyjnego i zaadowanie ich do
zupenie innego arkusza kalkulacyjnego
29. Program do przetwarzania fotografii dziaajcy
poprawnie na rnych wersjach tego samego
systemu operacyjnego
30. Zaadowanie nazwisk i adresw z
elektronicznego kalendarza do programu do
przetwarzania danych i wydrukowanie z niego
serii imiennych zaprosze i adresw na koperty
31. Uaktualnienie programu obsugi bazy danych i
niezmieniony dostp do danych ze starej bazy
danych
Kompatybilno oznacza co innego dla rnych programw, zalenie od
poziomu kompatybilnoci opisanego w specyfikacji wymaga i od tego,
jakie s wymagania systemu, na ktrym program bdzie wykonywany.
Zagadnienie kompatybilnoci nie istnieje dla oprogramowania urzdzenia
medycznego, majcego wasny system operacyjny, zapisujcego dane na
wasnych typach pamici i niepodczonego do adnego innego urzdzenia.
Natomiast ktra z kolei wersja programu do przetwarzania tekstu (zob.
rysunek 9.1), czytajcego i piszcego rne pliki z innych programw
przetwarzajcych tekst, pozwalajcego na korzystanie za porednictwem
Internetu przez wielu uytkownikw jednoczenie, umoliwiajcego
wczanie wbudowanej grafiki lub arkuszy kalkulacyjnych z rnego
rodzaju aplikacji - uwikadna jest w wielk ilo zagadnie kompatybilnoci.
Strona 23 (99)
Program do
przetwarzania tekstu z
firmy U, dziaajcy na
systemie operacyjnym W
Import/eksport
za
porednictwem
sieci
Import/eksport
plikw
Zapis/adowanie
plikw
Program do przetwarzania
tekstu z firmy C,
dziaajcy na systemie
operacyjnym L
Wycinanie,
kopiowanie,
wklejanie
Kopia zapasowa
Arkusz kalkulacyjny z
firmy L, dziaajcy na
systemie operacyjnym N
Rysunek 9.1 Kopmatybilno wica razem kilka rnych typw aplikacji

szybko staje si bardzo skomplikowana.
Wykonujc testowanie kompatybilnoci nowego oprogramowania, trzeba
bdzie sobie umie odpowiedzie na klika pyta:
32. Z jakimi innymi platformami (systemy
operacyjne, przegldarki internetowe i inne
elementy rodowiska) system zosta
zaprojektowany jako kompatybilny? Jeli
testowane oprogramowanie samo jest platform,
jakie inne programy maj na nim by
wykonywane?
33. Jakie standardy albo reguy kompatybilnoci
musz by przestrzegane?
34. Jakie rodzaje danych testowane
oprogramowanie bdzie uywa do
komunikowania si i posugiwania wsplnymi
danymi z innymi programami?
Odpowiedzi na te pytania uzyskuje si przy pomocy zwykego testowania
statycznego zarwno metodami czarnej jak i szklanej skrzynki. Analizuje
si starannie specyfikacj produktu i wszelk dodatkow dokumentacj.
Warto te wzi pod uwag rozmowy z programistami i analiz kodu, aby
odkry wszelkie poczenia od i do testowanego oprogramowania. W
pozostaej czci tego rozdziau przyjrzymy si tym zagadnieniom bliej.
Rne platformy i wersje aplikacji
Strona 24 (99)
Wybr platformy dla aplikacji oraz programw z ktrymi ma by
kompatybilna jest w gruncie rzeczy zadaniem dla marketingu. Kto dobrze
znajcy klientw powinien podj decyzj, czy oprogramowanie jest
przeznaczone dla okrelonego systemu operacyjnego, przegldarki
internetowej czy dla innej platformy. Ta sama osoba powinna podj
decyzj, z jakimi wersjami dany produkt ma by kompatybilny. Na
przykad, czsto widuje si takie opisy na opakowaniach albo na pierwszym
wywietlanym przez program ekranie:
Dziaa najlepiej z Netscape 4.0
Wymaga Windows 95 albo wyej
Do uytku z jdrem Linuxa 2.2.16
Te informacje nale do specyfikacji i informuj zespoy wytwarzajcy i
testujcy o tym, jakie s wymagania dotyczce kompatybilnoci. Kada
platforma narzuca szczeglne wymagania i z punktu widzenia kierownictwa
projektu wane jest, by ta lista bya jak najkrtsza, ale nadal wystarczajca z
punktu widzenia potrzeb klientw.
Kompatybilno wprzd i wstecz
Dwa powszechnie stosowane terminy to kompatybilno wstecz (z
poprzednimi wersjami) oraz kompatybilno wprzd (z nastpnymi
wersjami). Program kompatybilny wstecz dziaa z poprzednimi wersjami.
Program kompatybilny wprzd dziaa z przyszymi wersjami.
Najprostsz ilustracj kompatybilnoci wstecz i wprzd s pliki typu .txt,
czyli tekstowe. Rysunek 9.2 pokazuje, jak plik tekstowy zrobiony przy
pomocy Notpad 98 w systemie Windows 98 jest kompatybilny wstecz a do
MS-DOS 1.0. Jest rwnie kopmatybilny wprzd do Windows 2000 i
prawdopodobnie pozostaniem takim rwnie w kolejnych wersjach.
Strona 25 (99)
Editexe na MSDOS 1.0
NotePad 98 na
Windows 98
WordPad na
Windows 2000
NotePad na
Windows 3.1
??? na OS ???
NotePad na
Windows 95
Kompatybilno
wstecz
Kompatybilno
wprzd
Rysunek 9.2 Kompatybilno wstecz i wprzd okrelaj, ktre wersje bd

dziaa z programem lub plikami aktualnego programu.
Nie jest konieczne, by kade oprogramowanie i wszelkie pliki byy
kompatybilne wstecz i wprzd. Jest to decyzja do podjcia dla projektu.
Tester musi jednak wiedzie, jak wiele pracy wymaga bdzie
przetestowanie kompatybilnoci wstecz i wprzd dla danego programu.
Skutki testowania rnych wersji
Testowanie, e rozmaite platformy i oprogramowania dziaaja razem
prawidowo moe by duym przedsiwziciem. Wemy pod uwag test
kompatybilnoci dla nowej wersji popularnego systemu operacyjnego.
Programici naprawili wiele bdw, podnieli osigi i dodali do kodu wiele
nowych funkcji. Mog istnie dziesitki albo nawet setki tysicy programw
dla aktualnej wersji systemu operacyjnego. Celem projektu jest zachowanie
100-procentowej kompatybilnoci ze wszystkimi. Spjrzmy na rysunek 9.3.
Jest to wielka praca, ale zarazem kolejny przykad, jak podzia na klasy
rwnowanoci moe pomc zredukowa ilo pracy.
Strona 26 (99)
Programy do
przetwarzania
tekstu
Arkusze
kalkulacyjne
Bazy danych
Programy do
malowania i
pisania
Gry
Nowa platforma komputerowa 2004
Programy
edukacyjne
Rysunek 9.3 Testujc kompatybilno nowej platformy, musi si

skontrolowa, e wszystkie istniejce aplikacje dziaj na niej prawidowo.
Zaczynajc testowanie kompatybilnoci, trzeba dokona podziau
wszelkich moliwych kombinacji oprogramowania na klasy
rwnowanoci, bdce najmniejszymi, skutecznymi zbiorami
weryfikujcymi poprawn interakcj testowanego programu z
programami nalecymi do danej klasy.
Krtko mwic, skoro nie da si przetestowa tysicy rnych programw
na nowej wersji systemu operacyjnego, trzeba zdecydowa, ktre s
najwaniejsze. Kryteria kwalifikacji mog by nastpujce:
35. Popularno. Trzeba uy statysktyki sprzeday
i wybra 100 do 1000 najwaniejszych
programw.
36. Wiek. Na przykad wybierze si tylko programy
i wersje nie starsze ni trzyletnie.
37. Typ. Dzieli si programy na typy takie jak
malowanie, pisanie, ksigowo, bazy danych,
komunikacja itd. Z kadej kategorii wybiera si
program do przetestowania.
38. Wytwrca. Innym kryterium jest wybr
programw na podstawie firmy, ktra je
wyprodukowaa.
Tak samo jak w testowaniu konfiguracji sprztu, nie istnieje jedyna
poprawna podrcznikowa odpowied. Zesp projektowy powinien podj
decyzj, co jest najwaniejsze i przy pomocy tego kryterium dokona
podziau na klasy rwnowanoci.
Poprzedni przykad przedstawi testowanie kompatybilnoci nowego
systemu operacyjnegop. Te same kwestie odnosz si do testowania nowej
aplikacji (rysunek 9.4). Trzeba podj decyzje, na jakich wersjach platformy
i z jakimi innymi programami trzeba przetestwowa aplikacj.
Strona 27 (99)
Aplikacja #3
Aplikacja #2
Aplikacja #1
Platforma 1.0
Apllikacja #4
Nowa aplikacja
Platforma 2.0
Aplikacja #5
Platforma 2.1
Rysunek 9.4 Testowanie kompatybilnoci nowej aplikacji moe wymaga

testowania na wielu platformach i z wieloma innymi aplikacjami.
Standardy i normy
Dotd w tym rozdziale uczylimy si, jak wybra programy, ktre bdzie si
testowa pod wzgldem kompatybilnoci z wasnym oprogramowaniem.
Teraz przyjrzymy si, jak przystpi do waciwego testowania. Pierwszym
krokiem bdzie zbadanie standardw i innych norm, ktre stosuj si do
testowanego oprogramowania lub platformy.
Te wymagania mona w zasadzie podzieli na dwa rodzaje: wysokiego i
niskiego poziomu. Standardy dotyczce wysokiego poziomu to te, ktre
okrelaj ogln zgodno programu z obowizujcymi normami: wygld
jego interfejsu uytkownika, rodzaj funkcji itp. Standardy niskiego poziomu
to szczegy takie jak format plikw albo protokoy komunikacyjne. Oba
typy s istotne i musz by przetestowane, aby zapewni kompatybilno.
Standardy i normy wysokiego poziomu
Na jakim systemie operacyjnym oprogramowanie ma dziaa na
Windowsach, Macintoshu czy Linuxie? Czy to jest aplikacja Internetowa?
Jeli tak, na jakich przegldarkach ma dziaa? Kada z tych platform ma
swj wasny zestaw standardw i norm, ktre musz by przestrzegane, jeli
chce si mc twierdzi, e oprogramowanie jest kompatybilne z platform.
Przykadem moe by znak Cerytfikowany dla Microsoft
Windows (rysunek 9.5). Aby otrzyma ten znak, oprogramowanie musi
zaliczy testy kompatybilnoci przeprowadzone przez niezalene
laboratorium testujce. Celem jest sprawdzenie, e dane oprogramowanie
funkcjonuje stabilnie i niezawodnie na tym systemie operacyjnym.
Strona 28 (99)
Rysunek 9.5 Znak Cerytfikowany dla Microsoft Windows oznacza, e

oprogramowanie spenia wszystkie kryteria zdefiniowane przez zbir norm.
Kilka przykadw wymaga dla otrzymania tego znaku:
39. Oprogramowanie funkcjonuje z mysz majc
wicej ni trzy przyciski
40. Oprogramowanie mona zainstalowa na
stacjach dyskw innych ni C: i D:
41. Oprogramowanie dziaa z dugimi nazwami
plikw
42. Oprogramowanie nie czyta, nie pisze ani w
aden inny sposb nie uywa starych plikw
systemowcyh win.ini, system.ini, autoexec.bat
ani config.sys.
Te wymagania mog si wydawa proste i oczywiste, ale to tylko cztery
pozycje z dokumentu obejmujcego 77 stron. Zajmuje sporo czasu upewni
si, czy oprogramowanie spenia wszelkie wymagania dla otrzymania znaku,
ale spenienie ich jest gwarancj, e oprogramowanie jest o wiele bardziej
kompatybilne.
Szczegy na temat znaku Windows mona znale na
http://msdn.microsoft.com/certification/. Szczegy na temat uzyskania
prawa uytkowania znaku dla Apple Macintoshà znajduj si w
http://developer.apple.com/mkt/maclogo.html.
Standardy i normy niskiego poziomu
Standardy niskiego poziomu s w pewnym sensi waniejsze ni standardy
wysokiego poziomu. Mona na przykad stworzy program dziaajcy na
platformie Windows, ale nie majcy wygldu i sposobu dziaania innych
programw w Windowsach. Taki program nie otrzyma znaku
Certyfikowany dla Microsoft Wiondows. Uytkowanicy mog nie by
zachwyceni rznicami w pornaniu z innymi aplikacjami, ale produkt daby
si uywa.
Strona 29 (99)
Jeli jednak produkt jest programem graficznym, ktry zapisuje pliki na
dysku jako pliki .pict (standardowy format Macintosha dla grafiki), ale nie
spenia wymaga standardu dla plikw .pict, jego uytkownicy nie bda w
stanie oglda grafiki w adnym innym programie. Taki program nie jest
kompatybilny ze standardem i przypuszczalnie bdzie mia krtki ywot.
Podobnie, protokoy komunikacyjne, skadnia jzykw programowania i
inne metody uywane przez programy aby dzieli si informacj, musz
stosowa si do powszechnie dostpnych standardw i norm.
Standardy niskiego poziomu czsto traktuje si jako oczywiste, ale z punktu
widzenia testrw musz by zdefiniowane. Standardy kompatybilnoci na
niskim poziomie naley traktowa jak przeduenie specyfikacji wymaga.
Jeli wedug specyfikacji oprogramowanie bdzie zapisywa i adowa
pliki graficzne w formatach .bmp, .jpg i .gif, to trzeba bdzie znale
standardy tych formatw i skonstruowa testy, ktre potwierdz, e
oprogramowanie istotnie spenia te wymagania.
Kompatybilno wsplnych danych

Wsplne uywanie danych przez rozmaite aplikacje jest tym, co naprawd
daje oprogramownaiu si. Dobrze napisany program, spenijcy
opublikowane standardy i pozwalajcy uytkownikom atwo przenosi dane
do i z innych programw, jest wspaniaym, kompatybilym produktem.
Najpowszechniejsza metod przenoszenia danych z jednego programu do
drugiego jest zapisywanie i adowanie plikw. Jak zostao powiedziane w
poprzednim akapicie, przestrzeganie standardw niskiego poziomu wobec
dyskw i formatw plikw jest tym, co umoliwia taki podzia. Inne metody
rwnie s traktowane jako oczywiste, ale te musz by przetestowane pod
wzgldem kompatybilnoci. Oto kilka przykadw:
43. Zapis pliku i adowanie pliku to najbardziej
znany sposb wsplnego korzystania z danych.
Dane zapisuje si na dyskietce (albo innym
rodzaju pamici sieciowej, magnetycznej czy
optycznej), a nastpnie przenosi na inny
komputer z innym oprogramowaniem. Format
danych na pliku musi by zgodny ze
standardem, aby funkcjonowy na obu
komputerach.
44. Eksport i import plikw to sposb stosowany
przez wiele programw, aby zachowa
kompatybilno ze starszymi wersjami samych
sibie i z innymi programami. Rysunek 9.6
pokazuje okno dialogowe Otworzy Plik w
programie Word Microsoftu i kilka spord 23
rnych formatw plikw, ktre mona
importowa do tego programu.
Strona 30 (99)
Rysunek 9.6 Word Microsoftu moe importowa 23 rone formaty plikw.

Aby przetestowa funkcje importowania, naleaoby stworzy
dokumenty we wszystkich kompatybilnych formatach
przypuszczalnie przy uyciu oryginalnego programu, ktry zapisuje
dane w tym formacie. Te dokumenty musz mie prbki wybrame
przy pomocy podziau na klasy rownowanoci tekstu i
formatowania, aby mc sprawdzi, czy importowanme dane s
poprawnie porzeoone na nowy format.
45. Wycinanie, kopiowanie i wklejanie s nabardziej
znanymi sposobami wsplnego korzystania z
danych przez rne programy bez potrzeby
zapisywania danych na dysku. W tym wypadku,
transfer danych dokonuje si w pamici przez
poredniczcy program zwany Schowkiem.
Rysunek 9.7 pokazuje, jak taki transfer si
odbywa.
Rysunek 9.7 Schowek Systemowy suy do tymczasowego przechowywania

rnych typw danych, ktre kopiuje si z jednego programu do drugiego.
Schowek jest zaprojektowany tak, by mc przechowywa kilka
rnych rodzajw danych. Czst spotykane w Windowsach typy
danych to teksty, grafika i dwik. Te typy danych te mog
wystpowa w rnych formatach na przykad tekst moe by
zwykym tekstem ASCII, HTML, albo tekstem wzbogaconym. Grafika
moe by w formie map bitowych, metaplikw albo plikw .tif.
Gdy uytkownik wykonuje wycinanie albo kopiowanie, wybrane dane
umieszczane s w Schowku. Kiedy wykonuje si wklejanie, dane s
kopiowane ze schowka do programu docelowego.
Strona 31 (99)
Testujc kompatybilno programu, trzeba si rwnie upewni, czy
jego dane s prawidowo kopiowane poprzez Schowek do innych
programw. Tej funkcji uzywa si tak czsto, e atwo zapomnie, e
kryje si za ni wiele kodu potrzebnego, by wszystko to dziaao i byo
kompatybilne z wieloma rnymi programami.
46. DDE (wymawia si didi-i) i OLE (wymawia
si o-lej) to metody, ktrych Windows uywa w
celu przekazywania danych midzy dwiema
aplikacjami. DDE oznacza Dynamiczna
Wymian Danych (Dynamic Data Exchange), a
OLE czenie i Wbudowywanie Obiektw
(Object Linking and Embedding). Na innych
platformach znajduj si podobne metody.
W tej ksice nie musimy wchodzi w szczegy tych technik, ale gwn
rnic midzy nimi a uyciem Schowka jest to, e przy pomocy DDE i
OLE dane przepywaj z jednego programu do drugiego w czasie
rzeczywistym. Wycinanie i kopiowanie to operacja rczna. Przy uyciu
DDE i OLE, transfer dokonywany jest automatycznie.
Przykadem zastosowania moe by pisemny raport wykonany w
programie do przetwarzania tekstu, zawierajcy wykres wykonany przez
arkusz kalkulacyjny. Gdyby autor dokumentu skopiowa i wklei wykres
do raportu, byby on statycznym zrzutem migawkowym danych. Jeli
jednak wczy wykres do raportu jako obiekt, zmieni si on
automatycznie jeli zmieni si liczby, ktre ilustruje.
To wszystko jest pomysowe, to prawda, ale rownie stanowi wyzwanie
dla testera, jak upewni si, e czenie i wbudowywanie obiektw
funkcjonuje poprawnie.
Podsumowanie
Ten rozdzia by wstpem do testowania kompatybilnoci. Tak naprawde
mona by na ten temat napisa osobn ksik, i jeden rozdzia nie jest w
stanie odda caoci tematyki. Kada platforma i kada aplikacja jest
szczeglna, a zagadnienie kompatybilnoci na jednym systemie moe by
zupenie odmienne ni na innym systemie.
Pocztkujcy tester oprogramowania moe czsto otrzyma zadanie
przetestowania kompatybilnoci programu. Moe si to wyda dziwne,
zwaywszy zoono i wielko zadania, ale te zwykle pojedynczy tester
otrzymuje tylko fragment caej pracy do wykonania. Jeli projekt wytwarza
now wersj systemu operacyjnego, pojedynczy tester moe na przykad
otrzyma zadanie testowania kompatybilnoci tylko programw do
przetwarzania tekstu albo graficznych. Jeli projekt wytwarza jak
aplikacj, tester moe otrzyma zadanie przetestowania jej kompatybilnoci
na kilku rnych platformach.
Strona 32 (99)
Z kadym z tych zada mona sobie poradzi, jeli przystpi do nich
pamitajc o trzech rzeczach:
47. Naley podzieli zbir wszystkich moliwych
typw oprogramowania na dajc si
zastosowa w praktyce ilo klas
rwnowaznoci. Oczywicie, kierownik projektu
powinien zaakceptowa dokonan selekcj i
zdawa sobie sprawe z ryzyka zwizanego z
tym, e nie testuje si wszystkiego.
48. Naley zbada standady i normy, zarwno na
wysokim jak i na niskim poziomie, i
potrakotowa je jako przeduenie specyfikacji
wymaga.
49. Trzeba przetestowa rone drogi, jakimi dane
przepywaj midzy testowanymi programami.
Taka funkcjonujca wymiana danych stanowi o
kompatybilnoci programw.
Pytania
1.Prawda czy fasz: kade oprogramowanie musi by w jakim stopniu
poddane testownaiu kompatybilnoci.
2.Prawda czy fasz: Kompatybilno jest cech produktu, ktra moe by
speniona w rnym stopniu
3.Jak naley podejc do zadania przetestowania kompatybilnoci
wszystkich formatw plikw dla danego produktu?
4.W jaki sposb testuje si kompatybilno wprzd (z kolejnymi,
nastpnymi wersjami programu)?
Strona 33 (99)
Rozdzia 10
Testowanie rnych wersji jzykowych
W TYM ROZDZIALE
Aby sowa i rysunki miay sens
Kwestie tumaczenia
Kwestie ulokalnienia
Zagadnienia konfiguracji i kompatybilnoci
Jak wiele trzeba testowa?
Si tu eres fluente en mas de un idioma y competente en provando programas
de computadora, tu tienes una habilidad muy decenda en el mercado.
Wenn Si eine zuverlig Software Prferin sind, und flieend eine
fremdsprache, ausser English, sprechen knnen, dann knnen Si gut
verdienen.
Przetumaczone z grubsza z hiszpskiego i niemiekiego, powysze zdania
znacz: Ten kto jest dowiadczonym testerem oprogramowania i zna dobrze
inny jzyk oprcz angielskiego, moe si spodziewa wysokich zarobkw1.
Wiele programw wypuszcza si dzisiaj na cay wiat, nie tylko na rynek
jednego kraju albo tylko w jednym jzyku. Micorsoft dostarcza Windows
98 z obsug dla 73 rnych jzykw, od Afrikaans przez wgierski do
wietnamskiego. Wikszo innych firm produkujcych oprogramowanie
postpuje podobnie, zdajc sobie spraw, e angielskojzyczny rynek
amerykaski to ledwo poowa potencjalnych klientw. Projektowanie i
testowanie oprogramowania pod ktem sprzeday na caym wiecie przynosi
konkretne zyski.
W tym rozdziale poznamy wymagania wobec testowania programw
pisanych dla wileu krajw i jzykw. Na pierwszy rzut oka wydaje si to
nieskomplikowane, ale rzeczywisto jest inna i dowiemy si, dlaczego.
Gwne punkty tego rodziau to:
50. Czemu samo tumaczenie nie wystarcza
51. Jak zmiana jzyka wpywa na sowa i na cay
tekst
52. Czemu pika nona i telefon s wane
53. Zagadnienia konfiguracji i kompatybilnoci
To zdanie, jak i cay rozdzia, napisany jest z wyranie amerykaskiej perspektywy. W niczym nie
zmienia to jego aktualnoci, cho oczywiie polscy producenci oprogramowania rzadziej ni
amerykascy wytwarzaj programy przenaczone do uytku wielojzycznego (przyp. tumacza).
Strona 34 (99)
54. Jak wiele pracy wymaga testowanie pod ktem
innego jzyka
Aby sowa i rysunki miay sens

Kady pewnie kiedy czyta instrukcj obsugi zabawki albo urzdzenia, le
dosownie przetumaczon z innego jzyka. Prze trzpie numer pi
przez zielon kratk i dokr nie luno adn nakrtke. Jasne?
To jest przykad zego tumaczenia, i tak wanie oprogramowanie moe
wyglda, kiedy nie do wysiku woyo si w przygotowanie wersji
innych ni oryginalna. atwo jest przetumaczy tekst sowo po sowie, ale
zachowanie znaczenia wymaga wicej pracy i uwagi.
Dobry tumacz potrafi to wanie osign. Kto mwi pynnie w obu
jzykach, potrafi sporzdzi tumaczenie rwnie poprawne i zrozumiae jak
orygina. Niestety, w przemyle informatycznym samo dobre tumaczenie
nie zawsze wystarcza.
Wemy jako przykad jzyk hiszpaski. To chyba prosta sprawa
przetumaczy tekst angielski na hiszpaski, prawda? Dobrze, ale ktry
hiszpaski? Hiszpaski z Hiszpanii? A co z hiszpaskim z Kostaryki, z Peru,
z Dominikany? Wszdzie tam mwi si po hiszpasku, ale s to odmiany na
tyle rne, e program napisany pod ktem jednego moe by le przyjty
przez inne. Nawet angielski ma podobne kopoty. Istniej nie tylko angielski
amerykaski, ale kanadyjski, australijski i brytyjski. W oczach
amerykaskiego uytkownika sowa colour albo neighbour wygldaj
dziwacznie1.
Trzeba wzi pod uwag, oprcz samego jzyka, rwnie tak zwan
specyfik regionaln: kraj albo region, z ktrego pochodzi uytkownik.
Proces ten naywa si ulokalnieniem: dostosowywanie oprogramowania do
lokalnej specyfiki, dialektu, obyczajw i kultury. Testowanie tak
przetworzonego oprogramowania nazywa si testowaniem ulokalnienia.
Kwestie tumaczenia
Chocia tumaczenie jest tyko czci caego procesu ulokalniania, jest
szczeglnie wane z punktu widzenia testowania. Najprostszym problemem
jest jak mona przetestowa co posugujcego si innym jzykiem? C,
ktry z testerw musi w tym celu mie choia redni znajomo tego
jzyka aby mc przemieszcza si w programie, czyta i rozumie
wywietlane przez program teksty infromacyjne i pisa komnedy niezbdne
do uruchomienia programu. Moe jest wobec tego czas najwyszy, aby
zapisa si na kurs jzyka soweskiego, o ktrym si od dawna marzyo?
Brytyjska i amerykaska ortografia rni si w tym miejscu: brytyjskiemu colour i neighbour

odpowiada amerykaskie color i neighbor (przyp. tumacza).
Strona 35 (99)
Wane by cho jedna osoba w zespole testujcym znaa cho troch jzyk,
ktry si testuje1. Oczywicie, jeli program bdzie mg obsugiwa 32
rne jzyki, moe to by trudno osign. Rozwizaniem jest
przekazanie tego zadania firmie specjalizujcej si w testowaniu
ulokalnienia. Liczne takie firmy na caym wiecie s w stanie podj si
testowania niemal we wszystkicj jzykach. Aby znale wicej
wiadomoci na ten temat, wystarczy przeszukiwa zwrotu localization
testing2 na Internecie.
Nie musi si wymaga, aby kady w zespole zna jzyk, na ktry dokonuje
si ulokalniania. Przypuszcalnie wystarczy jedna tylko osoba. Wiele rzeczy
mona sprawdzi nie znajc znaczenia sw. Na pewno pomocna jest pewna
znajomo, ale daje si sporo przetestowa nie mwic pynnie w danym
jzyku.
Rozszerzanie tekstu
Najprostszym przykadem kopotu z tumaczeniami jest tak zwane
rozszerzanie tekstu. Chocia jzyk angielski moe si czasem wydawa
rozwleky, okazuje si, e tumaczc angielski na inne jzyki zwykle
potrzeba wicej liter dla wyraenia tej samej rzeczy. Rysunek 10.1 pokazuje
jak wielko przycisku ronie, aby zmieci si na nim tekst dwch czsto
spotykanych okrele komputerowych. Dobrym oszacowaniem jest
spodziewa si do 100-procentowego wzrostu wielkoci poszczeglnych
sw na przykad na przycisku. Mona si spodziewa 50-procentowego
wzrostu rozmiarw zda i krtkich akapitw typowych zwrotw, jakie
znajduj si w oknach dialogowych i w komunikatach o awariach.
Rysunek 10.1 Sowa Minimize (minimalizuj) i Maximize (maksymalizuj)

mog mie rn wielko w rnych jzykach, co moe zmusi do
przekonstruowania interfejsu uytkownika, aby stworzy dla nich miejsce.
Najlepiej, oczywicie, aby wszyscy znali ten jzyk doskonale. Istotne dla krajw, ktre wicej
oprogramowania importuj ni eksportuj (przyp. tumacza).
2
W wersji brytyjskiej bdzie to localisation, nie localization (przyp. tumacza).
Strona 36 (99)
Z powodu zjawiska rozszerzenia, naley szczeglnie staranie przetestowa
te czci programu, ktre mog ulec zmianie z powodu rozszerzonego
tekstu. Warto zwrci uwag na tekst, gdzie sowa nie s przenoszone
poprawnie do nastpnej linijki, skracane lub nieprawidowo dzielone. Moe
si to zdarzy gdziekolwiek w kadym punkcie ekranu, w oknach, na
przyciskach itp. Szuka si te sytuacji, gdzie tekst wprawdzie znalaz
miejsce do rozszerzenia si, ale przy okazji usun z ekranu co innego.
Moe si te zdarzy, e duszy tekst spowoduje powan awari programu
albo nawet awari caego systemu. Programista mg by przydzieli do
wewntrznej pamici na komunikaty angielskie, ale nie na dusze,
przetumaczone cigi znakw. Wersja angielska bdzie dziaa poprawnie,
ale niemieka ulegnie awarii, kiedy pojawi si jaki komunikat. Tester
stosujcy metody szklanej skrzynki moe znale ten bd nie znajc ani
sowa po niemieku.
ASCII, DBCS i Unicode
W rozdziale 5-ym Testowanie oprogramowania z klapkami na oczach
krtko zosta omwiony zbir znakw ASCII. ASCII zawiera tylko 256
znakw zbyt mao, aby zmieci wszelkie moliwe znaki we wszystkich
jzykach. Kiedy zaczto wytwarza oprogramowanie w wielu rnych
jzykach, pojawia si potrzeba nowych rozwiza, aby omin to
ograniczenie. Metoda popularna w czasach MS DOS-u, ale wci jeszcze
stosowana, nazywana bya technik stron kodowych. Strona kodowa to jakby
zastpcza tabela ASCII, z rnymi kodami dla rnych jzykw. Program
wykonywany w Quebecù na francuskim PC mg zaadowa i uywa
stron zawierajc francuskie znaki. Rosyjski uywa innej strony kodowej
dla znakw cyrylicy i tak dalej.
Takie rozwizanie dziaa, cho do niezdarnie, dla jzykw majcych mniej
ni 256 znakw. Jednak japoski, chiski i inne jzyki majce tysice
znakw stwarzaj nowe kopoty. System zwany DBCS (Double-Byte
Character Set zbir znakw dwubajtowych) stosowany jest przez niektre
programy. Uycie dwch zamiast jednego bajtu umoliwia zdefiniowanie do
65356 rnych znakw.
Strony kodowe i DBCS czsto wystarczaj, ale jest z nimi kilka problemw.
Najwaniejszy to kwestia kompatybilnoci. Jeli zaadowa hebrajski
dokument na niemieki komputer z angielskim programem do przetwarzania
tekstu, wynika z tego groch z kapust. Jeli nie ma si waciwych stron
kodowych ani przekadu z jednych na drugie, znakw nie daje si odtworzy
poprawnie.
Wyjciem z tego caego baaganu jest standard Unicode.
Unicode przypisuje jedn, niepowtarzaln liczb kademu znakowi,
niezalenie od plaformy,
niezalenie od programu,
Strona 37 (99)
niezalenie od jzyka.
Co to jest Unicode?
z witryny Konsorcjum Unicode
www.unicode.org
Unicode jest midzynarodowym standardem, popieranym przez wiksze
firmy produkujce oprogramowanie, przez producentw sprztu i przez inne
organizacje zajmujce si standaryzacj, dziki czemu stale si
rozpowszechnia. Stosuje go wikszo popularnych aplikacji. Rysunek 10.2
pokazuje jeden z wielu dostpnych zestaww znakw. Jeli oczekuje si, e
program choby w przyszoci bdzie ulokalniony, projekt powiniem
natychmiast rozsta si ze starym, dobrym ASCII i przestawi na Unicode
- i w ten sposb oszczdzi sobie czasu, pracy i awarii.
Rysunek 10.2 Okno dialogowe w programie Windows Word 2000 pokazuje

wykorzystanie standardu Unicode.
Gorce klawisze i skrty
Po angielsku, nazwa brzmi Search. Po polsku, Szukaj. Po francusku,
Rchercher. Jeli gorcy klawisz wybierajcy funkcj Szukaj w wersji
angielskiej jest Alt-S, to w wersji francuskiej naleaoby go zmieni na Alt
+R.
W ulokalnionych wersjach oprogramowania trzeba przetestowa czy
wszystkie gorce klawisze i skrty dziaaj prawidowo i czy nie s zbyt
trudne na przykad wymagaj nacinicia trzeciego klawisza. I trzeba
pamita, by sprawdzi, czy angielskie gorce klawisze zostay poprawnie
wyczone.
Rozszerzone znaki
Czsto spotykanym problemem w ulokalnionych i nie tylko wersjach
oprogramowania, jest uycie rozszerzonych znakw. W odniesiniu do
staroytnej tabeli ASCII, rozszerzone znaki to te, ktre s poza zwykymi
literami angielskigo alfabetu A-Z i a-z, na przkad w Jos albo w el Nio.
Jeli program jest napisany prawidowo i posuguje si Unicodem albo jeli
poprawnie zarzdza stronami kodowymi lub DBCS, nie powinno by
kopotu, ale tester nigdy niczego nie powiniem zakada, wic warto
sprawdzi.
Strona 38 (99)
Bdw naey przede wszystkim szuka wszdzie tam, gdzie program
przyjmuje znaki albo produkuje dane wyjciowe. W tych miejscach trzeba
uy rozszerzonych znakw i sprawdzi, czy funkcjonuj rwnie dobrze jak
zwyke znaki. Okna dialogowe, dialogi do wlogowania si i wszelkie inne
pola tekstowe powinny by sprawdzone. Czy da si wysya i przyjmowa
rozszerzone znaki przez modem? Czy mona je stosowa w nazwach plikw
lub mie je w plikach? czy zostan poprawnie wydrukowane? Co si stanie
jeli je wycina, kopiowa i wkleja midzy testowanym programem i
innymi aplikacjami?
Najprostszy sposb, eby nie zapomnie o przetestowaniu rozszerzonych
znakw, to doada je do uywanej klasy rwnowanoci zawierajcej
wszystkie uywane przy testowaniu, zwyke znaki. Oprcz tych czsto
powodujcych awarie znakw na kracach tabeli ASCII, warto dorzuci
, , , ,
Obliczenia na znakach
Dodatkowy kopot z rozszerzonymi znakami powstaje wtedy, kiedy
oprogramowanie uywa znakw do oblicze. Dwa przykady to sortowanie
teksw i przeksztacanie na mae lub na due litery.
Czy nasze oprogramowanie potrafi wytwarza posortowane listy wyrazw?
Na przykad w licie dajcych si wybiera pozycji takich jak nazwy plikw
lub adresy Internetowe? Jeli tak, to jak naleaoby posortowa nastpujc
list sw?
Kopiren
Reiste
rmlich
Arg
Reiskorn
rsum
Reiaus
kopien
reiten
Reisschnaps
reien
resume
Testujc oprogramowanie przeznaczone do sprzedzy na rynki azjatyckie,

trzeba sobie zdawa spraw, e kierunek sortowania opiera si na kolejnoci
ruchw pdzla. Niniejsza lista miaoby przypuszczalnie zupenie inna
kolejno, gdyby bya napisana po chisku. Naley sprawdzi, jakie reguy
sortowania obowizuj w jzyku, ktry si testuje, i skonstruowa testy
specjalnie nastawione na kontrol porzdku sortowania.
Strona 39 (99)
Drugi rejon, gdzie zaamuj si obliczenia dokonywane na rozszerzonych
znakach, to przeksztacanie na mae i na due litery. Problem bierze si std,
e sztuczk, ktrej wielu programistw uczy si jeszcze w szkole, to
dodanie lub odjcie wartoci 32 do wartoci ASCII danego znaku, by
przeksztaci go w ma lub du liter. Dodajc np. 32 do wartoci ASCII A
otrzymuje si warto ASCII a. Niestety, ta regua nie dziaa dla
rozszerzonych znakw. Stosujc t technik wobec rozszerzonego zbioru
znakw Apple Macintosha, przeksztalcioby si np. (ASCII 132) w
(ASCII 164), zamiast w (ASCII 150) nie to o co chodzio.
Sortowanie i przeksztacanie znakw w due i mae to tylko jeden z wielu
przykadw. Warto przyjrze si uwanie oprogramowniu, ktrym si
posugujemy, aby zidentyfikow inne sytuacje, gdzie obliczenia
wykonywane byy wprost na sowach albo na literach. Moe programy
kontrolujce pisowni?
Czytanie z lewa na prawo i z prawa na lewo
Trudnym orzechem do zgryzienia jest to, e wiele jzykw, np. hebrajski i
arabski, czytaj od prawej do lewej, nie za od lewej do prawej. Oznacza to,
e cay interfejs uytkownika trzeba przerobi w jego lustrzane odbicie.
Na szczcie, wikszo systemw operacyjnych zawiera wspomaganie dla
tych jzykw. Bez tego, byoby to zadanie niemal niewykonalne. Tak czy
owak, nie jest to ju samo proste tumaczenie. Wkorzystanie funkcji
systemowych do wykonania tego przeksztacenia wymaga sporej iloci
programownaia. Z punktu widzenia testowania, bezpieczniej bdzie
potraktowa to jako zupenie nowy produkt, nie tylko jako ulokalnianie.
Teksty w grafice
Kolejne problemy pojawiaj si, kiedy teksty uywane s w grafice. Na
rysunku 10.3 znajduje si kilka przykadw.
Rysunek 10.3 Word 2000 zawiera przykady trudnego do przytumaczenia

tekstu w formie map bitowych.
Strona 40 (99)
Ikony na rysunku 10.3 s standardowe dla wybrania Tustego druku,
Kursywy, Podkrele oraz Koloru czcionki. Poniewa te ikony zawieraj
litery B, I, U i A, nie znacz nic dla kogo z Japonii, kto nie zna
angielskiego. Mona domyli si znaczenia na podstawie wygldu B jest
troch grubsze, I pochylone, U podskrelone, ale oprogramowanie nie
powinno by zagadk.
Skutkiem tego, ulokalnienie oprogramowania czsto oznacza, e trzeba
wymieni wszystkie ikony. Kidy ikon jest duo, ulokalnienie moe si sta
zbyt kosztowne. Naley szuka tych bdw wczenie w procesi
wytwarzania i nie pozwoli, by przelizgny si a do koca.
Tekst naley przechowywa z dala od kodu
Ostatnim z zagadnie zwizanych z problemtyk tumacze to kwestia
szklanoskrzynkowa trzymanie tekstw w innym mijescu ni kod.
Oznacza to, e wszelkie cigi znakw, komunikaty o bdach, dosownie
wszytko co powinno by tumaczone, naley przechowywa w osobnych
plikach niezalenych od kodu rdowego. Nie powinno si nigdy znale
linijki kodu jak ta:
Print Hello World
Wikszo osob zajmujcych si lokalizacj nie jest programistami i nie
potrzebuje. Zmuszanie ich do modyfikowania w ramach tumaczenia
kodu rdowego jest ryzykowne i mao wydajne. To, co powinno zosta
przez nich zmienione, to zwyky plik tekstowy, zwany plikiem zasobw,
zawierajcy wszystkie komunikaty wywietlane przez oprogramownanie.
Kiedy oprogramowanie dziaa, wskazuje teksty z pliku, nie wiedzc ani nie
dbajc o ich tre. Komunikat po angielsku czy po holendersku zostana tak
samo wywietlone.
Tak wic jest wanym zadaniem testerw wykonujcych testy metodami
szklanej skrzynki, by przeszukali kod rdowy, eby znale ukryte
wbudowane cigi znakw, ktrych zapomniano umieci na pliku zasobw.
Mogoby to spowodowa spore zamieszanie, gdyby wany komunikat a
hiszpaskim programie pojawi si nagle po angielsku.
Innym objawem tego problemu s teksty komunikatw dynamicznie
generowane przez kod. Na przykad, kawaki tekstu mog by poczone w
duszy komunikat. Kod mgby na przykad mie trzy cigi znakw:
1.Nacisne klawisz
2.zmienna typu cig znakw zawierajca nazw wlanie nacisnitego
klawisza,
3. w ostatniej chwili!.
Strona 41 (99)
czone potem w cao, aby stworzy komunikat. Jeli zmienny cig
znakw bdzie mia warto zatrzyma reaktor atomowy, komunikat
bdzie brzmia:
Nacisne klawisz zatrzyma reaktor atomowy w ostatniej chwili!
Trudno polega na tym, e nie wszystkie jzyki maj t sam kolejno
wyrazw w zdaniu. Chocia ten tekst zoy si adnie w cao po polsku,
byby bez sensu gdyby go dosownie przetumaczy na chiski albo nawet
niemieki. Nie wolno pozwoli na cigi znakw w kodzie i nie wolno, by
program automatycznie czy cigi znakw w dusze komunikaty.
Kwestie ulokalnienia
Jak ju zostao powiedziane, trodnoci tumaczenia to dopiero poowa
kopotu. Teksty daj si zwykle atwo przetumaczy, nawet uwzgldniajc
rne znaki i dugoci cigw znakw. Dodatkowe trudnoci pojawiaj si,
kiedy chce si cae oprogramowanie dostosowa do zagranicznego rynku.
Przypomnienie poj z rozdziau 3-ego: precyzja, trafno, niezawodno
i jako.
Oprogramowanie dobrze porzetumaczone i dobrze przetestowane bdzie
precyzyjne i niezawodne, ale zapewne nietrafne i nie majce wysokiej
jakoci. Moe wyglda i dziaa wietnie, da si atwo odczytywa i nigdy
nie ulega awarii, ale dla uytkownika z innego krgu kulturowego moe po
prostu wydawa si jakie nie na miejscu. Dopiero dokonanie ulokalnienia
produktu pozwoli na osignicie penego dostosowania.
Zawarto
Co mona by pomyle o nowej encyklopedii wydanej na amerykaski
rynek, gdyby miaa zawarto pokazan na rysunku 10.4?
Pika nona
Nasza krlowa
Budka
telefoniczna
Jedzimy zawsze
po lewej stronie
Rysunek 10.4 Te przykady wygldayby dziwnie w encyklopedii na rynek

amerykaski.
W Stanach Zjednoczonych, pika nona to nie to samo co futbol!1 Nie jedzi
si po lewej stronie. To, co nie obowizuje w jednym kraju, obowizuje w
drugim! Testujc produkt podlegajcy ulokalnieniu, trzeba starannie
przejrze jego zawarto, aby upewni si, e pasuje do obszaru
kulturowego, gdzie ma by stosowany.
Football to w USA futbol amerykaski, a soccer to nasza europejska pika nona (przyp. tumacza).
Strona 42 (99)
Dotyczy to rwnie wszystkich innych oprcz kodu skadnikw
produktu informatycznego (zob. rozdzia 2-i Proces wytwarzania
oprogramowania). Ponisza lista zawiera rne elementy produktu, ktre
naley dokadnie zbada opd ktem ulokalnienia. To nie jest lista
wyczerpujca skadniki zale od rodzaju produktu. Warto pomyle, jakie
jeszcze inne skadniki mog sprawia kopoty, jeli wysa je do innego
kraju.
Przykady dokumentacji
Ikony
Obrazki
Dwiki
Wideo
Pliki pomocnicze
Mapy z kontrowersyjnymi granicami

marketingowe
Opakowanie
Materiay
Poczenia internetowe
Za dugi nos
W 1993 roku Microsoft wypuci dwa produkty dla dzieci, zwane
Pomysowy Pisarz i Wspaniay Artysta1. W tych programach wystpowaa
posta imieniem McZee, majca dzieciom pomaga w posugiwaniu si
nimi. Wiele trudu woono w zaprojektowanie McZee, w wybr jego
wygldu, koloru, manieryzmw, osobowoci i tak dalej. Wyszed z tego
do dziwnie wygldajcy facet z wystajcymi zbami, ciemnopurpurow
skr i duym nosem.
Kiedy sporo pracy woono ju w animacj postaci McZee, telefon
zadzwoni w jednym z zagranicznych biur Microsoftu. Otrzymano tam
wanie wstpn wersj programu i po analizie uznano, e bya nie do
przyjcia. Powd: McZee mia za dugi nos. W tamtejszej kulturze, ludzie
z dugimi nosami byli rzadkoci i susznie czy nie dugi nos kojarzy
si z mnostwem negatywnych stereotypw. Stwierdzono, e produkt nie
bdzie si w tej postaci sprzedawa.
Storzenie dwch rnych postaci McZee, kadej na inny rynek, byoby
zbyt kosztowne, wic wyrzucono ca prac dotd woon, a McZee
rozbi sobie nos o pierwsz powan przeszkod.
Wypywa std nauka, e to tre oprogramowania czy bdzie ni tekst,
grafika, dwiki czy co innego ma kluczowe znaczenie dla ulokalniania.
Pod tym wanie ktem naley analizowa zawarto programu, a tester o
ile nie ma dowiadczenia z lokalnym krgiem kulturowym musi mie do
dyspozycji eksperta, ktry si na niej dobrze zna.
Formaty danych
Creative Writer i Fine Artist (przyp. tumacza).
Strona 43 (99)
Rne kraje stosuja rne formaty zapisywania jednostek waluty, czasu i
innych wymiarw. Tak jak i z zawartoci, nie chodzi tu o samo
tumaczenie, lecz o ulokalnienie. Amerykaski program do skadu
komputerowego, posugujcy si calami, nie wystarczy tylko prztumaczy
na centymetry. Trzeba dokona zmian w programie we wzorach oblicze,
siatce wsprzdnych i tak dalej.
Tabela 10.1 Formaty danych dla rnych krajw
Jednostka
Moliwe wartoci
Miary
Metryczne lub angielskie
Liczby
Przecinek lub kropka dziesita; sposoby

umieszczania znaku ujemnego; uycie znaku # na
oznaczenie liczby
Waluta
Rne symbole i gdzie je si umieszcza
Data
Klejno dnia, miesica, roku; znaki oddzielajce;

zera na pocztku; dugi i krtki format daty
Godzina
12-godzinny lub 24-godzinny, znaki oddzielajce
Kalendarz
Rne kalendarze i dni pocztkowe (miesica,

tygodnia itp)
Adresowanie
Kolejno pozycji; uycie kodu pocztowego
Numery telefonw
Nawiasy, mylniki lub inne znaki oddzielajce

czci numeru od siebie
Formaty papieru
Rne formaty papieru i kopert
Na szczcie, wikszo systemw operacyjnych przeznaczonych do uytku

w ronych krajach zawiera gotowe formaty tych rodzajw danych
dostosowane do rnych krajw. Rysunek 10.5 pokazuje przykad z
Windows 98. Korzystanie z tego wbudowanego wspomnagania uatwia
programistom ulokalnianie programw, ale nie zastpuje mylenia.
Sposb wywietlania daty nie wpywa na to, jaki format ma data
wewntrz w programie. Na przykad, data moe mie krtki format ddmm-rr. Nie oznacza to, e wewntrzna reprezentacja daty jest tylko
dwucyfrowa (i zawiea w sobie bd roku dwutysicznego). W tym
wypadku ustawienie oznacza jedynie, e 2 cyfry s wywietlane. System
operacyjny posuguje si czterema cyframi dziesitnymi do wykonywania
oblicze, o czym warto dodatkowo pamita przy testowaniu.
Strona 44 (99)
Rysunek 10.5 W Windows 98, opcje Ustawie Lokalnych pozwalaj

uytkownikom wybra sposb wywietlania liczb, waluty, godzin i dat.
Testujc oprogramowanie dostosowane do danego kraju, trzeba dobrze zna
jednostki miar, ktrych si w nim uywa. Aby waciwie przetestowa
oprogramowanie, trzeba bdzie skonstruowa nowe klasy rwnowanoci,
dostosowane do nowego rodzaju danych.
Zagadnienia konfiguracji i kompatybilnoci

Kwiestie testowania konfiguracji i kompatybilnoci, omwione w
rozdziaach 8-ym i 9-ym, stosuj si w peni do testowania ulokalnionych
wersji oprogramowania. Problemy, ktre pojawiaj si, gdy
oprogramowanie wspdziaa z rnym sprztem i z innymi programami,
mog nasili si w nowych kombinacjach. Testowanie tego nie bdzie
koniecznie trudniejsze, moe tylko troch bardziej pracochonne.
Dodatkowym kopotem moe by dostp do zagranicznych weresji sprztu i
programw, z ktrymi testowanie trzeba przeprowadzi.
Midzynarodowe konfiguracje platform
Windows 98 obsugije 73 rne jzyki i 66 rnych ukadw klawiatury.
Realizuje si to poprzez dialog Waciwoci Klawiatury w Panelu
Sterujcym. Rozwijana lista jzykw zaczyna si od Afrikaans, a konczy na
ukraiskim i zawiera dziewi rnych wersji angielskigo: amerykask,
australijsk, brytyjsk, kanadyjsk, karaibsk, irlandzk, z Jamajki,
nowozelandzk i poudniowoafrykask. Jest tam te pi rych
dialektw niemieckich i dwadzicia hiszpaskich.
Strona 45 (99)
Rysunek 10.6 Windows 98 obsuguje uycie ronych ukadw klawiatury i

ronych jzykw poprzez okno dialogowe Waciwoci Klawiatury.
Rysunek 10.7 pokazuje przykady trzech rnych ukadw klawiatury
przeznaczonych dla rnych krajw. Zauwamy, e kada klawiatura ma
klawisze ze znakami danego jzyka, ale rwnie znaki angielskie. Jest to
ddo powszechne, gdy angielski jest powszechnie znany w wielu krajach,
a taki ukad pozwala na uywanie zarwno oprogramowania lokalnego jak i
angielskigo.
Klawiatury to sprzt najbardziej zaleny od jzyka, ale zaleznie od tego, co
si testuje, inne elementy sprztu te mog by zalene. Na przykad
drukarki musz poprawnie drukowa wszystkie znaki, ktre
oprogramowanie im wysya, i umie sformatowa dane wyjciowe do
rnych formatw papieru w rnych krajach. Jeli oprogramowanie uywa
modemu, mog pojawi si zagadnienia zwizane z jakoci linii
telefonicznych lub z rnicami w protokoach telekomunikacyjnych. Kade
urzdzenie peryfyeryjne pracujce z testowanym oprogramowaniem trzeba
wzi pod uwag, planujc ewentualne zalenoci od jzyka i kraju
zastosowania.
Konstruujc klasy rwnowanoci, trzeba pamita, eby wzi pod
uwag rne kombinacj oprogramowania i sprztu, ktre wchodz w
skad platformy. Dotyczy to zarwno sprztu, programw obsugi i
systemu operacyjnego. Posugiwanie si francusk drukark na
Macintoshu, z brytyjskim systemem operacyjnym i niemieck wersj
jzykow testowanego programu moe by jak najbardzij dozwolon
konfiguracj!
Strona 46 (99)
Rysunek 10.7 Arabska, francuska i rosyjska klawiatura zawiera znaki

specyficzne dla danego jzyka. Za zezwoleniem Fingertip Software, Inc.
(www.fingertip.com).
Kompatybilno danych
Tak samo jak testowanie konfiguracji, rwnie testowanie kompatybilnoci
nabiera nowego sensu, kiedy wzi pod uwag potrzeby ulokalniania.
Rysunek 10.8 pokazuje, jak bardzo zoone moe zrobi si przeniesienie
danych z jednej aplikacji do innej. Na przykad, nimiecka aplikacja stosujca
metryczne jednostki miary i rozszerzony zbir znakw, moe przenie dane
do innej, francuskiej aplikacji zapisujc i nastpnie dujc z dysku, albo
posugujc si funkcjami wytnij-wklej. Aplikacja francuska moe z kolei
wyeksportowa dane, ktre jaka angielska aplikacja moe importowa.
Program angielski, posugujcy si brytyjskimi jednostkami miary i nierozszerzonym zestawem znakw, moe to wszystko z powrotem przenie
do niemieckiego programu.
Rysunek 10.8 Testowanie kompatybilnoci danych rnych ulokalnionych

wersji programu moe by mocno skomplikowane.
Strona 47 (99)
W czasie tego przesyania danych w kko, przy przekadaniu jednostek
miar i rozszerzonych znakw, jest wiele miejsc, gdzie mog ukrywa si
bdy. Niektre z nich mogy powsta w wyniku bdnych decyzji
konstrukcyjnych. Na przykad, co ma si sta z danymi przenoszonymi z
jednego do drugiego programu, jeli musi zosta przy tym zmieniony
format? Czy naley zmian przeprowadzi automatycznie, czy powinno si
zapyta uytkownika? Czy naley wywietli komunikat o bdzie, czy te
tylko przenie dane i zmieni jednostki miary?
Zanim mona zacz testowa kompatybilno ulokalnionego
oprogramowania, trzeba mie odpowiedzi na powysze pytania. Kiedy ju
ma si te odpowiedzi, testuje si tak samo jak dawniej tyle tylko e w
klasach rwnowanoci bdzie wicej elementw.
Jak wiele trzeba testowa?

Wan decyzj, jak trzeba podj przed przystpieniem do testowania
wersji lokalnych programu, jest ile trzeba bdzie testowa? Jeli testowanie
oryginalnej wersji amerykaskiej zajo sze miesicy, czy testowanie
ulokalnionej wersji francuskiej te powinno zaj sze miesicy? Czy moe
jeszcze duej, skoro pojawiy si nowe zagadnienia dotyczce konfiguracji i
kompatybilnoci?1
T nieatw decyzj mona uproci do dwch podstawowych pyta:
55. Czy od pocztku planowano dokonanie
ulokalnienia oprogramowania?
56. Czy w celu dokonania ulokalnienia trzeba byo
dokonywa zmian w kodzie programu?
Jeli dostosowanie programu do rnych wersji lokalnych i jzykowych
byo planowane od pocztku, ryzyko pojawienia si wielu bdw i potrzeba
rozbudowanego testowania s znacznie mniejsze. Jeli jednak program by
napisany z pocztku specjalnie po angielsku pod ktem rynku
amerykaskiego, a decyzj o dostosowaniu do innego jzyka podjto
dopiero poniej, bdzie chyba najlepiej potraktowa to oprogramowanie jak
zupenie now wersj wymagajc penego testowania.
Drugie pytanie dotyvczy tego, jakich zmian trzeba byo dokona w caym
produkcie. Jeeli ulokalnianie polega tylko na zmianach w zawartoci
grafiki i tekstw to testowanie mona ograniczy do powierzchownej
walidacji. Jeli jednak z powodu zej architektury systemu albo innych
problemw kod musia take ulec zmianie, testowanie musi to wzi pod
uwage i skontrolowa zarwno tre jak i dziaanie funkcji.
To samo pytanie pojawia si przy kadym testowaniu konfiguracji, a jeszcze oglniej przy kadym
testowaniu regresywnym, niezalenie od jego przyczyn (przyp. tumacza).
Strona 48 (99)
Decyzja, jaka jest wymagana ilo testowania ulokalnienia, jest decyzj
ryzykown jak zreszt cae testowanie. Nabierajc dowiadczenia w
testowaniu, uczymy si, co bra pod uwag w procesie podejmowania
decyzji.
Meteod niekiedy stosowan przez zespoy testujce, jest testowanie na
ile produkt majcy w przyszoci podega ulokalnieniu nadaje si do
ulokalnienia. Testuje si ju pierwsz wersj produktu, zakadajc e
ulokalnienia zostanie wykonane poniej. Testerzy stosujcy metody
szklanej skrzynki badaj kod w poszukiwaniu cigw znakw,
waciwego przetwarzania jednostek miar, rozszerzonych znakw i innych
zagadnie widocznych na poziomie kodu rdowego. Czasem nawet robi
si wasn, lipn ulokalnion wersj. Testerzy stosujcy metody czarnej
skrzynki starannie badaj specyfikacje i sam produkt pod ktem takich
problemw jak teksty w grafice albo kwestie konfiguracji. Mona tre
uy lipnej wersji w celu przetestowania kompatybilnoci.
W ten sposb, zanim prawdziwe ulokalnienie zostanie dokonane, kopoty
ktre pojawiyby si pniej zostay ju wczeniej usunite, dziki czemu
uloklanienie przebiega pniej atwiej i taniej.
Podsumowanie
Ha n egy rtermett s kpzett softver ismer, s folykonyan egy nyelvet a
Angolon kvul, n egy nagyon piackpes szakkpzett szemly.
To jest znane ju zdanie cytowane na pocztku tego rozdziau, tym razem
napisane po wgiersku. Jeli nie umie si go przeczyta, nie ma
zmartwienia. Dowiedzielimy si przecie, e znajomo jzyka to tylko
jedna z wielu umijtnoci potrzebnych, by testowa produkt poddany
ulokalnieniu. Znaczn cz pracy wykonuje si kontrolujc, na ile produkt
nadaje si do ulokalnienia oraz testujc sprawy niezalene od jzyka.
Znajc inne jzyki oprcz angielskiego, i czytajc t ksik a do koca,
eby nauczy si jak najwicej na temat testowania oprogramowania, bdzie
si miao jak to przeczytalimy przed chwil po wgiersku zesp
bardzo dobrze si sprzedajcych umiejtnoci.
Wicej wiadoamoci na teamt programowania ulokalnienia i testowania dla
Windowsw mona znale w www.microsoft.com/globaldev. Dla
Macintosha, wiadomoci mona znale w ksice Guide to Macintosh
Software Localization, opublikowanej przez Addison-Wesley.
Pytania
1.Jaka jest rnica midzy tumaczeniem a ulokalnieniem?
Strona 49 (99)
2.Czy musi si zna jzyk, aby mc testowa produkt poddany
ulokalnieniu?
3.Co to jest rozszerzanie tekstu i jakie bedy powoduje?
4.Podaj kilka dziedzin, w ktrych rozszerzony zbr znakw moe
spowodowa kopoty.
5.Dlaczego tekstowe cigi znakw naley trzyma poza kodem?
6.Wymie kilka rodzajw formatw danych, ktre mog si rni w
rnych ulokalnionych wersjach programu.
Strona 50 (99)
Rozdzia 11
Test atwoci korzystania
W TYM ROZDZIALE
Testowanie interfejsu uytkownika
Na czym polega dobry interfejs uytkownika?
Testowanie pod ktem inwalidw: testowanie dostpnoci
Programy pisze si po to, eby kto ich uywa. To przecie oczywiste ale
zapomina si o tym w popiechu projektowania, wytwarzania i testowania
skomplikowanego produktu. Tyle czasu i energii powica si technicznej
stronie kodowania, e zesp projektowy zapomina o najwaniejszej racji
bytu oprogramowania e kto bdzie je w kocu uywa. Niewane, czy
oprogramowanie jest wbudowane w kuchenk mikrofalow, central
telefoniczn czy jest czci Intenetowej aplikacji do handlu akcjami. W
kocu bity i bajty wydobywaja si na powierzchni, gdzie ywy czowiek
bdzie si nimi posugiwa. Trafno, funkcjonalno i skuteczno
wsppracy czowieka z programem okrelaj cznie uyteczno programu.
Moe obio si komu o uszy pojcie ergonomii, nauki o projektowaniu i
wzornictwie rzeczy do codziennego uytku tak, eby byy atwe w uyciu i
funkcjonalne. Celem ergonomii jest osignicie uytecznoci.
Nie, nie uda si przekaza treci czteroletnich studiw w dziedzinie
ergonomii na pitnastu mniej wicej stronach tego rozdziau i nie potrzeba.
Przypomnijmy sobie z rozdziau 1-ego, czym jest bd: oprogramowanie
ktre trudno jest zrozumie, trudno si nim posugiwa, ktre jest powolne,
albo ktre w oczach uytkownika kocowego po prostu nie jest
odpowiednie. To nasz list elazny uprawniajcy do do testowania
uytecznoci.
Tester jest zwykle pierwszym uytkownikiem programu naley mie
nadziej, e jeszcze w trakcie projektu wytwrczego, kiedy jest mono
dokonywania napraw. Tester zapoznaje si ze specyfikacjami i identyfikuje,
kim bdzie kocowy uytkownik1. Jeli tester ma trudnoci z posugiwaniem
si programem, mona si spodziewa, e bdzie je mia te uytkownik.
Istnieje tak wiele rnych rodzajw oprogramowania, e nie sposb
szczegowo wyoy zagadnien uytecznoci dla kadego z nich.
Uyteczno programu kierujcego automatycznym blokowaniem dziaania
reaktora atomowego jest czym innym, ni uyteczno systemu poczty
gosowej. W tym rozdziale zapoznamy si z podstawowymi zasadami przy
czym punkt cikoci wywodw znajdzie si na typowym oprogramownaiu
dla komputera osobistego. Te same zasady mona pniej zastosowa do
kadego rodzaju oprogramowania.
1
Miejmy nadziej, e zostao to zrobione ju w trakcie konstruowania specyfikacji wymaga, a nie

dopiero przez testerw (przyp. tumacza).
Strona 51 (99)
Gwne punkty tego rozdziau:
57. Co wchodzi w skad testowania uytecznoci
58. Na co zwraca uwag testujc interfejs
uytkownika
59. Specjalne cechy uytecznoci potrzebne osobom
niepenosprawnym.

rodki, za pomoc ktrych uytkownik komunikuje si z programem nosz
nazw Interfejsu Uytkownika, albo UI (ang. User Interface). Kade
oprogramowanie ma jaki interfejs uytkownika. Puryci mog si spiera,
e to nieprawda, e programy takie jak te, ktre w samochodzie kontroluj
skad mieszanki paliwowej nie maj interfejsu uytkownika. Rzeczywicie,
nie maj konwencjonalnego interfejsu, ale dodatkowa sia, z jak musi si
naciska na peda gazu, i wyranie syszalne trzaski w rurze wydechowej s
rodzajem interfejsu uytkownika
Interfejsy programw, do jakich jestemy przyzwyczajeni, zmieniy si wra
z upywem czasu. Pierwsze komputery miay elektryczne przeczniki i
arwki. Papierwowa tama, karty dziurkowane i dalekopisy spotykao si
najczciej w latach 60-ych i 70-ych. Nastpnie pojawiy si monitory i
proste edytory liniowe. Obecnie uywa si komputerw z graficznym
interfejsem uytkownika (GUI).
Chocia wymienione interfejsy bardzo rniy si od siebie, w sensie
technicznym zapewniay to samo: sposoby eby wprowadzi do komputera
dane wejciowe i otrzyma z powrotem dane wyjciowe.
Na czym polega dobry interfejs uytkownika?

Wiele firm komputerowych powica znaczne rodki na badanie jak
najlepiej zaprojektowa interfejs uytkownika dla swego programu. Takie
badania wykonuje si w laboratoriach uytecznoci, w ktrych pracuj
specjalici od ergonomii. Laboratoria wyposaone s w jednostronne lustra i
kamery wideo do zapisywania, jak dokadnie ludzie posuguja si
oprogramowaniem. Wszystko co osoby badane robi ktre klawisze
naciskaj, jak posuguj si mysz, jakie popeniaj bdy i co ich zbija z
tropu analizuje si, aby mc zaproponowa poprawki w UI.
Mona zada sobie pytanie, co tester moe waciwie zdziaa z tym
szczegowym i niemal naukowym opisem. Zanim oprogramowanie
zostanie napisze, powinno ju mie doskonae UI. Ale skoro tak, czemu na
tak wielu magnetowidach byska godzina 12:00?
Strona 52 (99)
Po pierwsze, mao ktry zesp projektuje swoje interfejsy w a tak
naukowy sposb1. Wikszo interfejsw po prostu konstruowana jest w
chwli natchnieniea przez programist, ktre moe dobrze umie wietnie
kodowa, ale nie jest zwykle ekspertem od ergonomii. Csto powica si
projektowanie interfejsu na rzecz popiechu czy pokonywania trudnoci
technicznych. Jedn z przyczyn moe by jak dowiedzielimy si w
rozdziale 10-ym e oprogramowanie nie zostao starannie ulokalnione. W
kadym razie, tester musi wzi na sibie odpowiedzialno za testowanie
uytecznoci produktu, ktrego czci jest interfejs uytkownika2.
Tester moe sdzi, e brakuje mu kompetencji do testowania interfejsu
uytkownika, ale to nieprawda. Nie oczekuje si, e tester ma interfejs
zaprojektowa. Wystarczy, by wszed w skr uytkownika i znalaz
problemy z interfejsem.
Ze wzgldu na subiektywny charakter bdw interfejsu, czste s
nieporozumienia midzy testerami i konstruktorami interfejsu
uytkownika. Twrca interfejsu czsto traktuje go jak dzieo sztuki i tester
mwicy, e co jest nie w porzdku obraa artyst. Uyteczno to
draliwy teren. W rozdziale 18-ym Raportowanie tego, co si znalazo,
opisane s sposoby, jak przkaza to, co ma si do powiedzenia na temat
bdu tak, by nikogo nie urazi.
Oto lista sidmiu cech, ktre powinien spenia dobry iterfejs uytkownika.
Nieistotne czy chodzi o interfejs cyfrowego zegarka na rk czy interfejs
systemu operacyjnego Macintosha, te zasady obowizuj w rwnym
stopniu.
60. Zgodny ze standardami i regulami
61. Intuicyjny
62. Spjny
63. Elastyczny
64. Wygodny
65. Poprawny
66. Uyteczny
W tekst wkrada si tutaj przewijajace si przez reszt wywodw utosamianie interakcji z

interfejsem. Jest to czsto spotykane nieporozumienie. Nawet elegancko wykonany i zgodny z
zasadami ergonomii interfejs uytkownika nie zapewni wysokiej uytecznoci programowi, ktry nie
ma przemylanego projektu caoci interakcji z uytkownikiem. Ciekawe dane na ten temat mona
znale na www.cooper.com (przyp. tumacza).
2
Trudno w peni zgodzi si z tym pogldem tester majcy kompensowa braki w formuowaniu
specyfikacji wymaga, w fazie konstrukcji to niewykonalne zadanie (przyp. tumacza).
Strona 53 (99)
Czytajc ksiki na temat wzornictwa interfejsu, mona zetkn si rwnie
z innymi cechami dodawanymi do tej listy. Wikszo jedna daje si
sprowadzi do lub wywie z powyszych siedmiu cech. Na przykad, nie
zostao tu wymienione atwy do nauczenia si, ale jeli co jest intuicyjne
i spjne, zapewne bdzie te atwe do nauczenia si. Tester, ktre
skoncentruje si na zadaniu, by interfejs uytkownika spenia powysz
list cech, przyczyni si do powstania naprawd dobrego interfejsu. Kada z
cech omwiona jest szczegowo poniej.
Zgodny ze standardami i reguami
Najwaniejsz cech dobrego interfejsu uytkownika jest to, by spenia
wymagania istniejcych standardw i regu albo mia bardzo dobre
powody tam, gdzie ich nie spenia. Dla oprogramowania pracujcego na
istniejcych platformach, takich jak Macinstosh czy Windows, standardy s
ustalone. Standardy Apple zdefiniowane s w ksice Macintosh Human
Interface Guidelines, opublikowanej przez Addison-Wesley, a standardy
Microsoftu w ksice Micorsoft Windows User Experience, wydanej przez
Micorsoft Press.
Obie ksiki wyjaniaj w najdrobniejszych szczegach, jak
oprogramowanie pracujce na tych platformach powinno wyglda i dziaa
z punktu widzenia kocowego uytkownika. Wszystko jest okrelone
kiedy uywa pole wyboru zamiast przycisku opcji (kiedy obydwa stany
wynikajce z wyboru s jednoznacznie przeciwstawne), kiedy naley
stosowa komunikaty informacyjne, ostrzeenia oraz komunikaty o
krytycznej awarii, pokazane na rysunku 11.1.
Rysunek 11.1 W Widnowsach stosuje si trzy rne poziomy komunikatw.

Standardy interfejsku uytkownika dla Windows okrelaj, kiedy naley
uywa ktrego rodzaju.
Testujc oprogramowanie majce pracowa na okrelonej platformie,
naley traktowa standardy i reguy dla tej platformy jako dodatek do
wasnej specyfikacji produktu. Na ich podstawie mona sporzdzi
zadania testowe tak samo, jak na podstawie wasnej specyfikacji
produktu.
Strona 54 (99)
Te standardy zostay sformuowane miejmy nadziej przez specjalistw
w dziedzinie uyteczno produktw. S podsumowaniem zgromadzonych
dowiadcze na temat tego, jak projektowa systemy o wysokiej
uytecznoci, atwe w obsudze dla uytkownikw. Jeli oprogramowanie
cile przestrzega tych zasad, wikszo innych cech dobrego interfejsu
uytkownika osignie si samo przez si. Nie wszystko jednak zadziaa,
kiedy albo zesp projektowy uleg pokusi radosnej twrczoci, albo reguy
nie do koca pasoway do specyfiki danego oprogramowania. Wwczas
naley zagadnieniom uytecznoci powici szczegln uwag.
Moe si te zdarzy, e dana platforma nie ma wasnego standardu1, a
moe wanie testowane oprogramowanie samo stanowi tak platform. W
tej sytuacji zesp projektowy sam bdzie ustala standardy uytecznoci dla
oprogramowania. Nie mogc posugiwa si gotowymi standardami, trzeba
tym uwaniej stosowa si do pozostaych (szeciu) cech wymaganych dla
dobrego interfejsu.
Intuicyjny
W 1975 roku firma MITS (Micro Instrumentation Telemetry System)
wypucia jeden z pierwszych komputerw osobistych. Jego interfejs
uytkownika (rysunek 11.2) sada si wycznie z przecznikow i wiateek
niezbyt intuicyjnych w uyciu.
Rysunek 11.2 Altair 8800 firmy MITS i jego niezbyt intuicyjny interfejs
uytkownika (fotografia zamieszczona za zgod Amerykaskiego Muzeum
Komputerw, www.computer-museum.org).
Alatir by zaprojektowany dla informatykw-hobbystw, ludzi skonnych do
wielkiej wyrozumiaoci wobec niedostatkw interfejsu. Obecnie
uytkownicy wymagaj o wiele wicej. Wszyscy staruszkowie, dzieci i
doktorzy nauk cisych uywaj komputerw na co dzie. Komputery
majce najbardziej intuicyjny interfejs to te, z ktrych istnienia nawet nie
zdajemy sobie sprawy.
1
Typowe dla systemw wbudowanych i innych posugujcych si niestandardow platfom i sprztem

(przyp. tumacza).
Strona 55 (99)
Testujc interfejs uytkownika, intuicyjno mona oceni usiujc
odpowiedzie na nastpujce pytania:
67. Czy interfejs uytkownika jest elegencki, nie
przeszkadza, nie sprawia kopotw? Interfejs nie
moe utrudnia zrobienia tego, co si chce.
Potrzebne funkcje oraz oczekiwana informacja
powinny by oczywiste i znajdowa si tam,
gdzie si ich oczekuje.
68. Czy interfejs jest dobrze zorganizowany i
rozplanowany? Czy atwo jest przemieszcza si
z jednej funkcji do drugiej? Czy jest zawsze
jasne, jaki jest kolejny krok? Czy w kadym
momencie mona wycofa si z rozpocztej
czynnoci? Czy wprowadzane dane s
potwierdzane? Czy menu i okna nie s
zbudowane na zbyt wielu poziomach?
69. Czy jest nadmiar funkcjonalnoci? Czy program
jako cao albo jaka jego cz usiuje robi
zbyt wiele? Czy zbyt wiele moliwoci utrudnia
i nadmiernie komplikuje prac? Czy jest si
przecionym nadmiarem informacji?
70. Czy gdy wszystko inne zawiodo, system
pomocy rzeczywicie jest pomocny?
Spjny
Spjno wewntrzna programu i jego spjno z innymi programami maj
kluczowe znaczenie. Uytkownicy wyrabiaj sobie nawyki i oczekuj, e
kiedy jaka funkcja dziaa w pewien sposb w jednym programie, bdzie te
dziaa tak samo w innym programie. Rysunek 11.3 pokazuje przykad
dwch aplikacji Windows, ktre powinny by zrobione zgodnie ze
standardem, ale nie s spjne. W Notatniku, funkcj Szukaj znajduje si
przez menu Poszukiwanie albo za pomoc naciniecia klawisza F3. W
bardzo podobnym programie WordPad, dostp do tej funckji odbywa si
przez menu Edytuj albo za pomoc klawiszy Ctrl-F.
Rysunek 11.3 Notatnik i WordPad w Windows s niespjne pod wzgldem

sposobu przywoywania funkcji Szukaj.
Strona 56 (99)
Tego rodzaju niespjnoci frustruj uytkownikw, kiedy przenosz si z
jednego do drugiego programu. Jeszcze gorzej, jeli niespjno pojawia si
wewntrz jednego programu. Jeli istnieje standard dla tego rodzaju
oprogramowania na danej platformie, naley si nim posugiwa. Jeli
standardu nie ma, trzeba zwrci szczegln uwag na to, by podobne
czynnoci byy wykonywane podobnie. Dokonujc przegldu nowego
produktu warto zwrci uwag na nastpujce elementy:
71. Skrty i wybory z menu. W systemie poczty
gosowej, zero, a nie inne numery, czy prawie
zawsze z operatorem. W Windows, naciniciue
F1 zawsze przywouje pomoc.
72. Terminologia i nazewnictwo. Czy jednolite
nazwy uywane s w caym oprogramowaniu?
Czy spjne jest nazewnictwo funkcji? Na
przykad, czy Szukaj zawsze nazywa si Szukaj,
czy te czasem naywa si Znajdowanie?
73. Publiczno. Czy oprogramowanie przez cay
czas zwraca si do tego samego rodzaju
publicznoci? Program z kolorowym
interfejsem, sucy do robienia mieszynych
pocztwek, mie powinien ogasza
komunikatw o bdach skomplikowanym
technologicznym bekotem.
74. Pooenie i odpowiedniki przyciskw na
klawiaturze. Czy ktokolwiek zauway, e
przyciski OK i Anuluj w oknie dialogowym
zawsze umieszcza si tak, e OK jest zawsze na
grze albo na lewo, za Anuluj na dole albo na
prawo? Z tego samego powodu, jako
odpowiednikw na klawiaturze uywa si
zwykle Esc jako anuluj i Enter jako OK.
Spjno jest wana1.
Elastyczny
Uytkownicy lubi mie mono wyboru bez przesady, ale do by mogli
wybiera co chc zrobi i w jaki sposb. Kalkulator w Windows (rysunek
11.4) ma dwa tryby: standardowy i naukowy. Uytkownicy sami wybieraj,
ktrego chc uywa.
Niedostateczne wyczucie amerykaskiego poczucia humoru nie pozwala stwierdzi, czy to

autentyczna pomyka, czy zamierzony sarkazm autora (przyp. tumacza).
Strona 57 (99)
Rysunek 11.4 Kalkulator w Windows jest elastyczny, bo moe dziaa w

dwch rnych trybach.
Oczywicie, elestyczno powoduje rosnc zoono. W powyszym
przykadzie z Kalkulatorem testowanie byoby znacznie prostsze, gdyby
program mg dziaa tylko w jednym trybie. Skutki elastycznoci
odczuwane s najbardziej dotkliwie w zakresie tego, co opisuje rozdzia 5-y
Testowanie z klapkami na oczach na teamt testowania przejc stanw.
75. Skoki midzy stanami. Elastyczne
oprogramowanie ma wicej opcji i wicej
sposobw osignicia tego samego wyniku.
Skutkiem tego s dodatkowe cieki midzy
rnymi stanami. Diagram przej stanw staje
si znacznie bardziej zoony. Wicej czasu
zajmie wybr, ktre cieki trzeba bdzie
przetestowa.
76. Omijanie stanw. Ta moliwo jest najbardziej
widoczna, kiedy oprogramowanie ma tryb
duej mocy, gdzie dowiadczony uytkownik
moe imin kilka kolejnych etapw i
przeskoczy na skrty wprost do celu. System
poczty gosowej, pozwalajcy bezporednio
wprowadzi numer wewntrzny rozmwcy jest
tego przykadem. Testujc oprogramowanie
majce takie moliwoci naley sprawdzi, czy
wszystkie zmienne otrzymay waciwe wartoci
mimo omijania stanw porednich.
Strona 58 (99)
77. Dane wejcia i wyjcia. Uytkownicy chc mc
posugiwa si rnymi sposobami
wprowadzania danych do programu i oglda je
w rnych formach. Na przykad aby
wprowadzi tekst do WordPad, mona go
napisa, wklei, zaadowa z plikw o rnych
formatach, wklei jako objekt albo przycignc
przy pomocy myszy z innego programu. Arkusz
kalkulacyjny Microsoft Excel pozwala na
ogldanie danych w formie 14 rnych
standardowych i 20 robionych na zamwienie
wykresw. Mao kto nawet wie, e jest a tyle
ronych moliwoci. Przetestowanie wszelkich
moliwych sposobw wprowadzania danych do
programu oraz ogldania wynikw moe bardzo
szybko powikszy niezbdzny w tym celu
wysiek poza dozwolon granic i zmusi nas do
bezwzgldnoci przy tworzeniu klas
rwnowanoci.
Wygodny
Oprogramowanie musi uywa si wygodnie. Nie powinno przeszkadza
uytkownikowi w wykonaniu pracy. Wygoda oprogramowania to bardzo
nieprecyzyjna zmienna. Naukowcy powicali cae kariery usiujc znale
formu, jak uczyni oprogramowanie wygodnym. To pojcie jest trudno
skwantyfikowa, ale warto poszukiwa nastpujcych wskanikw:
78. Stosowno. Oprogramowanie musi wyglda
stosownie do tego co i dla kogo robi. Aplikacja
fiansowa raczej nie powinna przesadza z
krzykliwymi kolorami i efektami dwikowymi.
Z drugiej strony, kosmiczna gra komputerowa
wymaga naginania regu. Oglnie mwic,
oprogramowanie nie moe by zbyt spartaskie,
ale nie moe by te przsadnie ozdobne.
79. Obsuga bdw. Program musi ostrzega
uytkownikw przed przystpieniem do
krytycznych dziaa i da moliwo
odtworzenia danych ewentualnie straconych w
wyniku awarii.
Strona 59 (99)
80. Wydajno. Szybko nie jest zawsze najlepsza.
Niejeden program migocze komunikatami o
awarii tak szybko, e czowiek nie nada ich
przeczyta. Z kolei do powolnych operacji, trzba
przynajmiej da uytkownikowi zmieniajc si
informacj o tym, ile czasu operacja bdzie
jeszcze trwaa, e aktywno trwa i program si
nie zawiesi. Pasek statusu, jak na rysunku 11.5,
to popularny sposb przekazywania tych
informacji.
Rysunek 11.5 Pasek stanu pokazuje, ile pracy ju ukoczono i ile jeszcze
pozostao.
Poprawny
Kwestia wygody jest, trzeba przyzna, niejednoznaczna i mona j rnie
interpretowa. Z poprawnoci nie ma takich kopotw. Testujc
poprawno, testuje si, czy interfejs uytkowanika wykonuje to, co
powinien. Rysunek 11.6 jest przykadem niepoprawango interfejsu.
Rysunek 11.6 Ten program ma zupenie bezuyteczny przycisk Przerwij.

Rysunek przedstawaia okno z komunikatem popularnego programu do
skanowania pod Windowsami. Okno to pojawia si, kiedy skanowanie si
rozpoczo i ma umoliwi przerwanie skanowania w trakcie. Niestety, nie
dziaa. Kursor ma ksztat klepsydry, co oznacza (wedug standardw
Windows), e oprogramowanie jest zajte i nie przyjmuje adnych danych z
wejcia. Po co wic umieszcza tam przycisk Przerwij? Mona wielokrotnie
klika w ten przycisk podczas caego skanowania, ktre trwa do kilku minut,
i nic si nie zmienia. Skanowanie posuwa si dalej bez przerwy a do koca.
Strona 60 (99)
Tego rodzaju brak poprawnoci rzuca si w oczy i zostanie przypuszczalnie
wykryty podczas zwykego testowania zgodnoci ze specyfikacj produktu.
Warto jednak zwrci szczegln uwag na jeszcze kilka zagadnie:
81. Bdy w materiaach do marketingu. Czy
brakuje jakich funkcji, czy pojwawiy si moe
funkcje o innym dziaaniu ni opisane w
materiaach reklamowych? Nie porwnuje si
tutaj oprogramownaia ze specyfikacj, lecz z
informacjami reklamowymi. Zwykle si rni.
82. Jzyk i pisownia. Programici wiedz tylko, jak
si pisze sowa-klucze jzyka programownia i
czsto konstruuj bardzo ciekawe komunikaty.
Poniszy przykad znajuje si na popularnej
witrynie Internetowej do dzi, naley mie
nadziej, zosta ju usunity.
Jeli jest jaka rozbieno z
ponisz informacj, prosimy
bezzwocznie si z nami
skontaktowa, by zapeni
punktualn dostaw
zamwionych arytkuw.
83. Bdne noniki. Przez noniki rozumie si tutaj
wspierajce program ikony, rysunki, dwiki i
fragmenty wideo wchodzce w skad interfejsu.
Ikony powiny mie sta wielko i zestaw
kolorw. Dwiki powinny by wszystkie
zapisywane w tym samym formacie i z t sam
czstotliwoci dokonywa pomiaru prbek.
Poprawne ustawienia powinny by wywiatlane.
84. WYSIWYG1 (dostaje si to, co si widzi).
Trzeba si upewni, e podawana przez interfejs
informacja jest prawdziwa. Kiedy si kliknie
przycisk Zapisz, czy zapisany dokument jest
dokadnie taki, jak widoczny na ekranie? Kiedy
zaadowa go z powrotem, czy jest identyczny
jak orygina?
Uyteczny
Wan cecha dobrego interfejsu jest uyteczno. Nie chodzi o to, czy cae
oprogramowanie jest uyteczne, tylko czy dana cecha lub funkcja jest
uyteczna. Funkcje niepotrzebne niewane w jakiego rodzaju programie
s ze dla uytkowanika, a dla testera oznaczaj niepotrzebn, dodatkow
prac.
WYSIWYG What You See Is What You Get (przyp. tumacza).
Strona 61 (99)
Waro sobie zada pytanie, czy dana funkcja do czego si przydaje czy w
trakcie przgldu specyfikacji, czy w czasie planowania, czy w czasi
wykonywania testw. Czy pomaga uytkownikom? Jeli funkcja wydaje si
zbdna, warto zbada, czemu znalaza si w programie. Mog istnie
nieznane testrowi powody, albo funkcja rzeczywicie jest zupenie zbdna.
Testowanie pod ktem inwalidw: testowanie dostpnoci

Wan czci testowania uytecznoci jest testowanie dostpnoci, czyli
testowania pod ktem inwalidw. Badania przprowadzone w latach
1994-1995 przez amerykaski urzd statystyczny (U.S. Census Bureau)
ujawniy, e 54 miliony mieszkacw USA miao w jaki sposb
ograniczon sprawno. Tabela 11.1 pokazuje rozkad niesprawnoci w
ronych grupach wiekowych.
Tabela 11.1 Ludzie niepenosprawni
Strona 62 (99)
Wiek
Procent osb niepenosprawnych
0-21
10%
22-44
14,9%
45-54
24,5%
55-64
36,3%
65-79
47,3%
Strona 63 (99)
80+
71,5%
Starzenie si spoeczestwa i wchodzenie oprogramowania w coraz to nowe

dziedziny ycia powoduje, e testowanie dostpnoci staje si coraz
waniejsze.
Istniej rne rodzaje inwalidztwa, ale kilka powoduje, e korzystanie z
komputerw staje si szczeglnie utrudnione.
85. Wady wzroku. Daltonizm, silna krtko- i
dalekowzroczno, widzenie tunelowe, widzenie
mgliste, katarakty to przykady wad wzroku.
Ludzie, ktrzy cierpi na jedn albo kilka z nich,
maj szczeglne trudnoci z uywaniem
oprogramowania. Wyobramy sobie, jak trudno
jest zobaczy, gdzie mieci si w danej chwili
kursor myszki, albo jak trudno odczyta mae
znaki graficzne albo tekst na ekranie. Co bdzie,
jeli uytkownik jest w ogle niewidomy?
86. Wady suchu. Mona by czciowo lub
cakiem guchym, mie trudnoci ze syszeniem
pewnych czstotliwoci albo z usyszeniem
dwiku w haasie. Moe to utrudnia albo
uniemoliwi syszenie gosw albo dwikw
towarzyszcych animacjom, pomocy
dwikowej albo ostrzee systemowych.
87. Ograniczenia ruchowe. Choroba albo wypadek
moe pozbawi osob czciwo lub cakowicie
kontroli nad doni lub ramieniem. Dla
niektrych ludzi prawidowe posugiwanie si
klawiatur lub myszka jest trudne lub
niemoliwe. Na przykad mog mie trudnoci z
naciniciem naraz wicej ni jednego klawisza,
albo z naciskaniem klawisza tylko jeden raz.
Niemoliwe moe by poruszanie mysz.
88. Ograniczenia poznawcze i jzykowe.
Zaburzenia pisania, mowy i pamici utrudniaj
uywanie skomplikowanego interfejsu
uytkownika. Naley wzi pod uwage
omwione wczeniej zagadnienia i rozway ich
moliwy wpyw na osoby z tego rodzaju
trudnociami.
Takie jest prawo
Na szczcie, wytwarzanie oprogramowania z ktrego mog korzysta take
osoby niepenosprawne nie jest tylko dobrym pomyslem, regu czy nawet
standardem jest (w USA) prawem. W Stanach Zjednoczonych, trzy
przepisy odnosz si do tego zagadnienia:
Strona 64 (99)
89. Prawo dotyczce osb niepenosprawnych
wymaga, by w przedsibiorstwach
zatrudniajcych wicej ni pitnastu
pracownikw byy zainstalowane niezbdne
udogodnienie. To prawo zastosowano ostatnio
wobec komercyjnych witryn na Internecie,
wymagajc by stay si bardziej dostpne.
90. Paragraf 508 prawa rehabilitacyjnego jest
podobny do przepisu zacytowango powyej i
dotyczy wszelkich organizacji oraz instytucji
otrzymujcych dotacje od rzdu federalnego.
91. Paragraf 255 prawa telekomuniacyjnego
wymaga, eby oprogramowanie
i sprzt
stosowany do przenoszenia informacji przez
Internet, sie albo przez linie telefoniczne, by
dostosowany do osb niepenosprawnych. Jeli
ten wymg nie jest speniony, to sprzt lub
oprogramowanie musi by kompatybilne (zob.
rozdzia 8-y Testowanie konfiguracji i
rozdzia 9-y Testowanie kompatybilnoci) z
istniejcymi w formie sprztu lub
oprogramowania
pomocami
dla
niepenosprawnych.
Funkcje dostpnoci oprogramowania
Oprogramowanie mona udostpni niepenosprawnym na dwa sposoby.
Najprociej wykorzysta pomoc wbudowan w system operacyjny. Zarwno
Windows, Macintosh, Java i IBM OS/2 maj pewne funkcje uatwiajce
realizacj dostpnoci. Wystarczy, by program spenia wymagania
systemowe dotyczce sposobu posugiwania si klawiatur, mysz, kart
dwikow i monitorem, aby spenia podstawowe wymagania dostpnoci.
Rysunek 11.7 pokazuje przykad panelu kontrolnego ustawie dostpnoci w
Windows 98.
Rysunek 11.7 Z tego panelu kontrolnego ustawia si funkcje dostpnoci w

Windows.
Strona 65 (99)
Jeli testowane oprogramowanie stosowane jest na innej platformie ni
wymienione (albo samo stanowi platform), musi mie wasne funkcje
dostpnoci wyspecyfikowane, zaprogramowane i przetestowane. Jest to
oczywicie trudniejsze ni posuenie si gotowymi funkcjami obsugi
dostpnoci, ale test dostpnoci wymagany jest w oby wypadkach, nawet
jeli oprogramowanie wykorzystuje wspomaganie wbudowane w system
operacyjny.
Testujc uyteczno produktu, trzeba pamita o skonstruowaniu zada
testowych take pod ktem dostpnoci. To zapewni nam czyste sumienie.
Kada z wymienionych platform ma wasn specyfik, ale wszystkie oferuj
wsparcie dla funkcji uatwiajcych posugiwanie si oprogramowaniem
przez osoby niepenosprawne. W Windowsach znajduj si nastpujce
moliwoci:
92. Lepkie Klawisze pozwalaj, by klawisze Shift,
Ctrl i Alt pozostaway aktywne a do nacinicia
nastpnego klawisza.
93. Filtrowanie Klawiszy anuluje skutki
przypadkowego wielokrotnego nacinicia tego
samego klawisza
94. Przeczniki Klawiszy generuj sygna
dwikowy po naciniciu klawiszy CapsLock,
ScrollLock i NumLock.
95. Stranik Dwiku generuje ostrzeenie graficzne
przy kadym uyciu sygnau dwikowego
przez system.
96. Pokaz Dwikw poleca oprogramowaniu
wywietlenie teksu lub grafiki przy kadym
generowanym przez nie dwiku. Wywietlany
tekst lub grafika musz by osobno
zaprogramowane.
97. Wysoki Kontrast ustawia monitor (kolory i
czcionki) tak, by uatwi prac osobom z
wadami wzroku. Przykad znajduje si na
rysunku 11.8.
Rysunek 11.8 Pulpit Windows mona przestawi na wysoki kontrast, co

uatwia prac osobom z wadami wzroku.
Strona 66 (99)
98. Mysz Klawiszowa umoliwia nawigacj przy
pomocy klawiszy klawiatury zamiast myszy.
99. Seryjne Klawisze ustawiaj port komunikacyjny
tak, by odczytywa przycinicia klawiszy z
pomocniczego urzdzenia. Chocia z punktu
widzenia systemu operacyjnego takie urzdzenia
powinny funkcjonowa tak samo jak
standardowa klawiatura, nie zaszkodzi ich
doczy do klasy rwnowanoci przy
testowaniu konfiguracji.
Wicej danych na temat funkcji dostpnoci wbudowanych w najwaniejsze
systemy operacyjne mona znale w nastpujcych witrynach
internetowych:
100.http://www.microsoft.com/enable
101.http:/www.apple.com/education/k
12/disability
102.http://www-3.ibm.com/able
103.http://www.sun.com/tech/access
Podsumowanie
Oprogramowanie moe by trudno zrozumie, nieatwo uywa, moe by
te zbyt wolne albo w opinii testera po prostu bdne.
Tester jest pierwsz osob, ktra posuguje si produktem w sposb zbliony
do uytkownika, pierwsz osob ktra widzi cao zoon w ostateczny
ksztat. Jeli cao sprawia trudnoci testerowi, klient bdzie mia te same
kopoty.
Nade wszystko nie wolno pozwoli, by subiektywno i brak cisych regu
stany na przeszkodzie testowaniu uytecznoci. Nawet specjalici od
projektowanie interfejsu uytkownika przynajmniej niektrzy zgodz si
z tym. Testujc interfejs uytkownika nowego produktu, mona posugiwa
si list z tego rozdziau, zawierajc cechy dobrego interfejsu. Jeli
testowany interfejs nie spenia tych kryteriw, mamy do czynienia z bdem.
Pytania
1.Pawda czy fasz: kady rodzaj oprogramowania ma interfejs uytkownika
i dlatego musi by przetestowany pod ktem uytecznoci.
2.Czy konstrukcja interfejsu uytkowanika jest nauk czy sztuk?
3.Jeli nie istniej jednoznaczne kryteria poprawnoci interfejsu
uytkownika, w jaki sposb mona go testowa?
Strona 67 (99)
4.Wymie znane ci przykady le zaprojektowanego albo niespjnego
interfejsu uytkkowanika.
5.Jakie cztery rodzaje inwalidztwa wpywaj na dostpno
oprogramowania?
6.Na co naley przede wszystkim zwrci uwag przy testowaniu
oprogramowania pod ktem dostpnoci dla niepenosprawnych?
Strona 68 (99)
Rozdzia 12
Testowanie dokumentacji
W TYM RODZIALE
Rodzaje dokumentacji oprogramowania
Znaczenie testowania dokumentacji
Pod jakim ktem testowa dokumentacj
Rzeczywisto testowania dokumentacji
W rozdziale 2-im Proces wytwarzania oprogramowania zostao
powiedziane, e w skad produktu informatycznego wchodzi oprcz
oprogramowania wielel innych skadnikw. Ich znaczna cz to
dukumentacja.
W dawnych dobrych czasach, dokumentacja skadaa si co najwyej z pliku
czytaj.to na dyskietce razem z oprogramowaniem, albo z jednostronicowej
instrukcji woonej do pudeka z programem. Dzisiaj jest tego znacznie,
znacznie wicej czsto dokumentacja wymaga wicej pracy i wysiku ni
samo oprogramowanie.
Tester oprogramowania nie musi wbrew nazwie ogranicza si do
testowania tylko oprogramowania. Odpowiedzialno testera powinna
dotyczy wszystkiego, co wchodzi w skad produktu informatycznego, a
wic rwnie kontroli poprawnoci dokumentacji.
W tym rozdziale zapoznamy si z metodami testowania dokumentacji i z
tym, jak wczy je w cao procesu testowania. Najwaniejsze punkty
rozdziau to:
104.Rne rodzaje dokumentacji
105.Znaczenie testowania dokumentacji
106.Pod jakim ktem testowa dokumentacj
Rodzaje dokumentacji oprogramowania

Gdyby dokumentacja oprogramowania skadaa si tylko i wycznie z pliku
czytaj.to, nie byoby wielkich kopotw z testowaniem. Wystarczyoby
sprawdzi, czy plik zawiera wszystkie potrzebne dane, czy dane s
poprawne technicznie i na dodatek monaby wykona kontrol pisowni i
przeciwwirusow dyskietki. Ale czasy dokumentcji skadajcej si tylko z
pliku czytaj.to dawno miny.
Dzisiaj dokumentacja oprogramowania stanowi zwykle znaczn cz
produktu. Czasem mona wrcz mie wraenie, e produkt to sama
dokumentacja z dodan odrobin oprogramowania.
Strona 69 (99)
Oto lista pozycji ktre naley zaliczy do dokumentacji. Nie kady rodzaj
oprogramowania bdzie mia wszystkie pozycje z listy, ale i takie mog si
trafi.
107.Tekst i grafika na opakowaniu. Wchodzi w to
pudeko, etykiety, obwoluta, plastikowe koperty
i tak dalej. Ta dokumentacja czsto zawiera
fragmenty interfejsu oprogramowania, listy
funkcji, wymagania systemowe, dane na temat
praw autorskich.
108.Materiay reklamowe i marketingowe. To s te
papierki ktre kady zwykle szybko wyrzuca,
ale s to mimo wszystko istotne narzdzia
wpierajce sprzeda dodatkowego
oprogramowania, umw serwisowych itd. Ta
informacja musi by poprawna, aby klienci
traktowali j powanie.
109.Gwarancja/rejestracja. Ma to zwykle form
formularza, ktry klient wypenia i wysyla do
producenta aby zarejestrowa oprogramowanie.
Bywa rwnie czci oprogramowania, ktr
klient wypenia wprost przy komputerze albo
nawet potwierdza interakcyjnie.
110.EULA. Wymawia si to jula i oznacza End
User License Agreement (Umowa Licencyjna
dla Uytkowanika Kocowego). Jest to
dokument o mocy prawnej, w ktrym klient
zobowizuje si midzy innymi nie
kopiowa oprogramowania ani nie pocigna
producenta do odpowiedzialnoci karnej za
szkody spowodowane przez ewentualne awarie
oprogramowania. EULA drukuje si niekiedy na
kopercie zwierajcej nonik programu
dyskietk albo CD. Moe te pojawi si na
ekranie w trakcie procesu instalacji. Przykad
EULA znajduje si na rysunku 12.1.
Rysunek 12.1 EULA jest czci dokumentacji oprogramowania i

wyjania prawne warunki posugiwania si programem.
Strona 70 (99)
111.Etykiety i nalepki. Mog znajdowa si na
noniku informacji (dyskietka, CD), na pudeku,
na drukach. Mog to by te nalepki z numerem
seryjnym, albo nalepki ktrych rozdarcie
oznacza przyjcie warunkw licencji. Na
rysunku 12.2 znajduje si przykad etykiety na
dyskietk i informacja, ktr musi si
skontrolowa.
112.Instrukcje instalacji i ustawie programu.
Czasem ta informacja znajduje si na noniku
programu, ale bywa te doczona jako osobny
arkusz, lub dla skompliwanego
oprogramowania jako cay podrcznik.
113.Podrcznik uytkownika. Uyteczno i
elastyczno interakcyjnych podrcznikw
spowodowaa, e podrczniki drukowane
spotyka si dzi o wiele rzadziej ni niegdy.
Wikszo programw zawiera obecnie
niewielki drukowany podrcznik zawierajcy
podstawowe wiadomoci, a wszelkie informacje
szczegowe znajduj si w podrczniku
interakcyjnym. Podrczniki interakcyjne
rozprowadza si albo razem z
oprogramowaniem na tym samym noniku
informacji, albo przez Internet, albo za pomoc
obu metod.
114.Pomoc interakcyjna. Pomoc interakcyjna czsto
stanowi jedno z podrcznikiem interakcyjnym,
a czasem wrcz go zastpuje. Pomoc intercyjna
ma zwykle indeks i daje si przeszukiwa, co
wybitnie uatwia znajdowanie potrzebnej
infomacji. Wiele systemw pomocy
interakcyjnej pozwala nawet dokonywa
poszukiwa przy pomocy pyta fomuowanych
w jzyku naturalnym. Uytkownik moe na
przykad napisa Poka mi jak skopiowa tekst
z jedneg programu do drugiego i otrzyma
waciw odpowied.
Strona 71 (99)
Nazwa
programu
Jzyki
Dane na temat
dyskietki
Rodzaje platform dla

oprogramowania
Instrukcje instalacyjne znajduj

si w Dokumentacji Jak
zacz
Numer identyfikacyjny
programu
Instrukcje dla
instalacji
Prawa
autorskie
Wersja
programu
Rysunek 12.2 Na etykiecie dyskietki znajduje si duo informacji, ktra musi

zosta skontrolowana przez testera.
115.Seminaria, programy asystujce, kursy
interakcyjne. W tych narzdzich czsto znajduje
si zarwno kod programu jak i pisemna
dokumentacja. Czsto stanowi mieszank treci
tekstowych oraz oprogramowania, zintegrowan
z systemem pomocy interakcyjnej. Uytkownik
moe zada pytanie, a program prowadzi go
przez wsztkie kroki potrzebne do wykonania
zadania. Pomocnik Microsoftu, zwany czasem
jako facet-spinacz (rysunek 12.3) jest
przykadem takiego systemu.
116.Prbki, przykady, wzory. Przykadem moe
by program do przetwarzania tekstu,
zawierajcy formularze albo prbki
dokumentw, ktre uytkowanik moe wypeni
i szybko uzyska w ten sposb dokumentcj o
profesjonalnym ukadzie. Kompilatory mog
zawiera fragmenty kodu ilustrujce, jak
posugiwa si danym aspektem jzyka.
117.Komunikaty o bdach. Kilkakrotnie byy ju w
tej ksice omawiane jako przykad tematu
czsto zaniedbywanego. Zaliczy mona je
rwnie do dokumentacji.
Strona 72 (99)
Rysunek 12.3 Pomocnik Micorsoftu jest przykadem bardzo rozbudowanego

systemu pomocy i nauczania.
Znaczenie testowania dokumentacji

Dla uytkownikw wszystkie elementy produktu nie bdce
oprogramowaniem s po prostu czci produktu informatycznego. Dla
uytkownika jest nieistotne czy dany element zosta skonstruowany przez
programist, autora tekstw czy te przez grafika. Dla uytkownika istotna
jest jako caego produktu.
Jeli uytkownik zostanie wprowadzony w bd przez mylne instrukcje
instalacyjne albo przez nieprawidowe komunikaty o bdach, bdzie to
dla niego rwnoznaczne z bdami oprogramowania ktre powinny
zosta znalezione przez testerw.
Dobra dokumentacja na trzy sposoby wpywa na ogln jako produktu:
118.Poprawia uyteczno. Pamitamy jeszcze z
rozdziau 11-ego Testowanie uytecznoci
wszystkie zagadnienia dotyczce uytecznoci
produktu? Uyteczno zaley w znacznym
stopniu od jakoci dokumentacji.
119.Podnosi niezawodno. Niezawodno zaley
od tego, jak stabilne i spjne jest
oprogramowanie. Czy program wykonuje to,
czego oczekuje uytkownik, w dodatku we
waciwym czasi? Jeli uytkownik zapozna
si z dokumentcj, posuy programem i
uzyska nieoczekowane wyniki, mamy do
czynienia z nisk niezawodnoici. Jak dowiemy
si w dalszej czci tego rozdziau, testowanie
oprogramowania przez dokumentacje i
dokumentacji przez oprogramowanie jest
dobrym sposobem, by znale bdy w jednym i
w drugim.
Strona 73 (99)
120.Obnia koszty serwisu. Dowiedzielimy si w
rozdziale 2-im, e bdy znalezione przez
uytkownika mog kosztowa 10 do 100 razy
wicej w porwnaniu z bdami znalezionymi i
skorygowanymi wczeniej w procesie
wytwarzania produktu. Jedn z przyczyn jest to,
e klienci nie mogcy spobie poradzi z
programem zwracaj si do dostwacy o pomoc,
ktrej udzielenie jest kosztowne. Dobra
dokumentacja moe w znacznym stopniu
przyczyni si do ograniczenia tych kosztw
uatwiajc prac uytkownikw.
Dla testera oprogramowania dokumentacja zasuguje na t sam uwag i
wysiek co kod programu. Stanowi one jedn cao dla uytkownika.
Pod jakim ktem testowa dokumentacj

Testowanie dokumentcji odbywa si na dwch poziomach. Jeli ona nie jest
kodem, jak na przykad drukowany podrcznik uytkownika lub tekst na
opakowaniu, testowanie jest statycznym procesem, jak opisany w
rozdziaach 4-ym i 6-ym. Mona je wwczas traktowa jak rodzaj redakcji
technicznej lub korekty. Kiedy dokumentacja i kod s ze soba cile
poczone, jak na przykad w wypadku interakcyjnego podrcznika
posugujcego si hiperpoczeniami albo w wypadku pomocnego asystentaspinacza, testowanie staje si dynamiczne i stosujemy w nim techniki, ktre
poznalimy w rozdziaach 5-ym i 7-ym. Mamy wtedy do czynienia z
testowaniem oprogramowania.
Dokumentacj najlepiej testowa tak samo, jak bdzie si ni posugiwa
uytkowanik, niezalenie od tego, na ile jest statycznym tekstem, a na ile
kodem. Naley j starannie przeczyta, wykona kady z opisanych
krokw, sprawdzi kady rysunek i wyprbowa kady opisany przykad.
W ten sposb znajdzie si bdy zarwno w programie, jak i w
dokumentacji.
Tabela 12.1 zawiera prost list kontroln do zastosowania przy
konstruowaniu zada testowych do dokumentacji.
Tabela 12.1
Lista kontrolna do testowania dokumentacji
Strona 74 (99)
Co sprawdzi
Co uwzgldni
Zagadnienia oglne
Czytelnicy
Czy dokumentacja zwraca si do waciwych

czytelnikw, nie do zbyt pocztkujcych, nie do zbyt
zaawansowanych?
Terminologia
Czy terminologia jest stosowna dla czytelnikw? Czy

nazwy uywane s konsekwentnie? Jeli uywa si
skrtw, czy s one powszechnie zrozumiae lub
zdefiniowane z tekcie? Naley upewni si, czy nie
stosuje si omykowo wewntrznej terminologii
stosowanej w firmie. Czy dostpny jest poprawny
indeks i referencje do terminologii?
Tre i zawarto
Czy dokumentcja nie zawiera zbdnych tematw?

Czy adnych zagadnie nie brakuje? Warto zwrci
uwag na opisy funkcji, ktre by moe zostay
usunite z produktu, o czym jednak nie
poinformowano autora dokumentacji technicznej. Czy
materia jest opisany dostatecznie szczegowo?
Poprawno
Same fakty
Czy informacja jest poprawna technicznie? Warto

szuka bdw wynikajcych z posugiwania si przez
autorw przestarza specyfikacj lub naginania
prawdy przez dzia marketingu. Spawdza si take
spis treci, indeks i referencje do numerw
rozdziaw. Sprawdza si adresy hiperpocze. Czy
prawidowo podany jest numer telefonu do obsugi
technicznej? Najprociej zadzwoni.
Krok po kroku
Cay tekst naley czyta powoli i starannie,

postpowa dokadnie wedug podanych instrukcji.
Niczego nie przyjmuje si za oczywiste. Brakujcego
opisu nie maley si prbowa domyla klienci nie
bd wiedzie, czego brakuje. Uzyskane wyniki
naley porwna z podanymi w dokumentacji.
Rysunki i
fragmenty ekranu
Sprawdza si poprawno i dokadno rysunkw.

Czy ilustracja zawiera waciw tre? Naley
sprawdzi, czy fragmenty ekranu nie pochodz z
poprzedniej wersji produktu. Czy podpisy pod
rysunkami s poprawne?
Prbki i
przykady
Kad prbk naley zaadowa i uy tak samo, jak

zrobi to uytkowanik. Jeli to jest kod, naley go
skopiowa i wyprbowa. Nic bardziej aosnego ni
nie dziaajce prbki kodu a mimo to spotykamy si
z nimi bardzo czsto!
Strona 75 (99)
Pisownia i
gramatyka
W doskonaym wiecie tego typu bdy nigdy nie

docieralyby do testerw. Programy do kontroli
pisowni i gramatyki s powszechnie dostpne i naley
je stosowa. Mogo si jednak zdarzy, e
zapomniano skontrolowa fragment tekstu lub e
specjalistyczny, techniczny termin unikn kontroli.
Rysunki i ilustracje zawierajce fragmenty ekranu
byy przypuszczalnie sprawdzane tylko rcznie, wic
obowizje wobec nich zasada ograniczonego
zaufania.
Strona 76 (99)
W kocu, jeli mamy do czynienia z dokumntacj napdzan programem,
naley j przetestowa tak samo, jak ca reszt oprogramowania. Sprawdza
si, czy indeks jest kompletny, czy szukanie daje poprawne wyniki, czy
hiperpoczenia i miejsca aktywne prowadz pod waciwe adresy. Warto
posuy si technik podziau na klasy rwnowanoci by zadecydowa, co
si kontroluje.
Rzeczywisto testowania dokumentacji

Na koniec rozdziau trzeba zapozna si z realiami, ktre powoduj, e
wytwarzanie i testowanie dokumentacji rni si jednak od wytwarzania
oprogramowania. Rozdzia 3-ci nosi tytu Testowanie oprogramowania w
rzeczywistoci. Ponisze zagadnienia monaby nazwa realiami testowania
dokumentacji.
121.Dokumentacja czsto otrzymuje najmniej
uwagi, rodkw i osb. Wydaje si istnie
specyficzna mentalno, e w produkcie
informatycznym przede wszystkim liczy si
oprogramowanie, caa reszta jest drugorzdna.
W rzeczywistoci klienci kupuj cay produkt
informatyczny i inne rzeczy s rwnie wane jak
bajty i bity. Ponoszc odpowiedzialno za
testowanie jakiej funkcji w oprogramowaniu,
naley dopatrzy, by w skad testowania wszed
rwnie test dokumentacji. Naley powici
mu tyle samo uwagi co oprogramowaniu i jego
bdom.
122.Zdarza si, e osoby piszce dokumentacj nie
s specjalistami w dziedzinie oprogramowania
lub jego zakresu programu. Tak samo jak tester
nie musi by ekspertem od rachunkowoci by
mc testowa arkusz kalkulacyjny, tak samo
autor dokumentacji nie musi zna doskonale
funkcji programu by mc pisa dokumentacj.
Nie mona wic zakada, e autor zdoa
wyoby prawd ze le napisanych specyfikacji i
ze skomplikowanych, niejasno
udokumentowanych funkcji produktu. Warto
blisko wsppracowa z autorami dokumentacji,
by upewni si, e maj dostp do potrzebnej
informacji i e znaja konstrukcje produktu1.
Testerzy mog te poinformowc autorw
dokumentacji, jakie funkcje programu s
szczeglnie trudne do zrozumienia lub do
zastosowania, tak by mogli lepiej wyjani je w
dokumentacji.
1
W takim razie testerzy powini mie pensje prezesw zarzdw spek, skoro maja kompensowa
niedbalstwo i niekompetencj wszystkich innych osb w firmie i w projekcie (przyp. tumacza).
Strona 77 (99)
123.Produkcja dokumetacji drukowanej zajmuje
tygodnie albo nawet miesice, podczas gdy
oprogramowanie mona opublikowa niemal
natychmiast na Internecie albo na CD. Z
powodu tej rnicy, dokumentacj czsto trzeba
sfinalizowa i zamrozi zanim oprogramowanie
zostanie wykoczone. Jeli program zmieni si,
albo odkryte zostan bdy w tym krytycznym
dla dokumentacji okresie, nie da si ju
unaczeni dokumentacji. Dlatego wymyono
pliki czytaj.to. Za ich pomoc mona
poinformowa klientw o zmianach
wprowadzonych w ostatniej chwili. Jedyn rad
jest mie i stosowa dobry model wytwarzania
oprogramowania, powstrzymywa
wypuszczenie papierowej dokumentacji jak
tylko dugo mona i publikowa jak najwiksz
cz dokumentacji razem z progamem, na
noniku programu lub na Internecie.
Podsumowanie
Miejmy nadziej, e ten rozdzia zdoa przekona czytelnikw, e produkt
informatyczny skada si nie tylko z pisanego przez programistw kodu.
Dokumentcja oprogramowania we wszystkich postaciach sporzdzana
przez autorw, ilustratorw, autorw indeksacji i tak dalej, moe by
bardziej pracochonna przy wytwarzaniau i testowaniu ni samo
oprogramowanie.
Z punktu widzenia uytkowanika wszystkio to s skadniki tego samego
produktu. Bd w pomocy interakcyjnej, ktra nie jest w stanie wyjani
znacznenia jakiego podstawowego okrelenia, nieprawidowa instrukcja
instalacji czy bd literowy to takie same bdy jak kady inny bd w
oprogramowaniu. Testujc porzdnie dokumentacj, znajduje si bdy
zanim znajd je uytkownicy.
W nastpnym rozdziale zapoznamy si z testowaniem czego, co niemal w
caoci jest sam dokumentacj tekst, grafika i hiperpoczenia wraz z
ukryt pod nimi platform. Techniki, ktre poznalimy dotd, da si
znakomicie zastosowa do testowania witryn WWW.
Pytania
Strona 78 (99)
1.Uruchom program Paint w Windows (zobacz rysunek 12.4) i poszukaj
przykadw dokumnetacji ktr naleaoby przetestowa. Co mona
znale?
Rysunek 12.4 Jakie przykady dokumentacji mona znale w programie

Paint w Windows?
2. Indeks pomocy w programie Paint w Windows
zawiera ponad 200 hase poczwszy od doda
wasne kolory1, skoczywszy na zmiana
wielkoci obrazu. Czy naley sprawdzi, czy
kade z hase indeksu porwadzi do waciwego
rozdziau? Jak naleaoby postpi w przypadku
10000 hase w indeksie?
3. Prawda czy fasz: testowanie komunikatw o
bdach jest czci testowania dokumentacji.
4. Jakie s trzy podstawowe powody, dla ktrych
ktrych test dokumentacji przyczynia si do
poprawy oglnej jakoci produktu
informatycznego?
Po angielsku adding custom colors jest na litere a (przy tumacza).
Strona 79 (99)
Rozdzia 13
Testowanie witryn WWW
W TYM ROZDZIALE
Podstawowe wiadomoci na temat stron WWW
Testowanie metodami czarnej skrzynki
Testowanie metodami szarej skrzynki
Testowanie metodami szklanej skrzynki
Testowanie konfiguracji i kompatybilnoci
Testowanie uytecznoci
Wprowadzanie automatyzacji
Poznane w poprzednich rozdziaach techniki testowe byy oglne. Zostay
zilustrowane przykadami zastosowania wobec maych programw takich
jak Notatnik Word, Kalkulator albo prosty program graficzny Paint. W tym
rozdziale zajmiemy si testowaniem szczeglnego typu oprogramowania stron WWW. Jest to temat na czasie, przypuszczalnie niele znany, i dobry,
praktyczny przykad zastosowania poznanych wczeniej technik.
W tym rozdziale dowiemy si, e testowanie Internetu obejmuje wiele
rnych dziedzin, w tym testowanie konfiguracji, kompatybilnoci,
uytecznoci, dokumentacji oraz - jeli mamy do czynienia z witryn o
zasigu wiatowym - testowanie ulokalnienia. Oczywicie, stosuje si - jak
zwykle - testowanie czarnej skrzynki, szklanej skrzynki, statyczne i
dynamiczne.
Niniejszy rozdzia nie jest wyczerpujcym przewodnikiem po testowaniu
Internetu (to wymagaoby osobnej ksiki)1 , ale znajduje si w nim
nieskomplikowane, praktyczne przykady testowania czego rzeczywistego.
Ponadto - jeli czyja pierwsza praca bdzie wanie szukaniem bdw w
witrynie Internetowej - uatwi znacznie start.
124.Jakie glwne czci strony WWW wymagaj
testowania?
125.Testowanie Internetu metodami czarnej i
szklanej skrzynki
126.Testowanie konfiguracji i kompatybilnoci
127.Czemu testowanie uytecznoci jest szczeglnie
istotne dla stron WWW
1
Rozdzia powicony jest testowaniu stron i witryn (gwnie statycznych), natomiast testowanie
Internetu - czy aplikacji internetowych - obejmuje rwnie m.in. testowanie skryptw w Jawie,
testowanie serwerw WWW, komunikacji, serwera aplikacji i bazy danych wspierajcych dan
witryn, i wiele innych elementw (przyp. tumacza).
Strona 80 (99)
128.Jak przy pomocy narzdzi mona uatwi
testowanie witryn.
Podstawowe wiadomoci na temat stron WWW

Mwic najprociej, strony WWW to s dokumenty skadajce si z tekstu,
rysunkw, dwikw, wideofilmw i hiperpocze - podobnie jak
popularne w poowie lat 90-ych multimedialne kompakty. Tak samo mona
tutaj przemieszcza si midzy stronami klikajc bdce hiperpoczeniami
fragmenty tekstu lub rysunki, szuka sw i zwrotw i przeglda znalezion
informacj.
Jendak Internet doda do koncepcji mulitmedialnego dokumentu dwie
rewolucjonizujce t technik moliwoci:
129.W przeciwiestwie do danych zgromadzonych
wycznie na dysku CD, strony WWW nie s
ograniczone tylko do jednego komputera.
Uytkownicy mog czy si i przeszukiwa
Internet na caym wiecie.
130.Tworzenie stron nie jest domen programistw
posugujcych si kosztownymi narzdziami.
Przecitna osoba moe zwykle rwnie atwo
stworzy stron WWW, co napisa dokument w
programie do przetwarzania tekstu.
Jak danie komu do rki pdzla nie robi z nikogo automatycznie artystymalarza, tak umiejtno tworzenia stronic WWW nie robi z nikogo
specjalisty od wydawnictw multimedialnych. Poczywszy to z eksplozj
nowych technik tworzenia zupenie nowych funkcji na internetowych
witrynach, mamy wymarzon okazj dla testerw oprogramowania.
Rysunek 13.1 przedstawia pewna popularn witryn WWW, ktra
przedstawia wiele moliwych funkcji stron WWW. Oto ich niepena lista:
131.Teskty w rnych wielkociach, rodzajach
czcionek i kolorach (OK, nie da si zobaczy
kolorw na czarno-biaym rysuku)
132.Grafika i fotografie
133.Hiperpocznia tekstu i grafiki
134.Rne reklamy
135.Okna do selekcji
136.Pola, w ktre uytkownik moe wpisywa dane
Strona 81 (99)
Rysunek 13.1 Typowa strona WWW ma wiele dajcych si przetestowa

funkcji.
Spor cz funkcjonalnoci trudno jest zauway, ale ona wanie czyni
strony WWW znacznie bardziej skomplikowanymi:
137.Ukad strony dajcy si przystosowa do
potrzeb klienta
138.Dostosowujca si do potrzeb klienta
zawarto, pozwalajca uytkownikom dokona
wyboru, jakie wiadomoci i jak infomracj
pragn oglda
139.Listy rozwijane do dokonywania wyboru
140.Dynamicznie zmieniajce si zadania testowe
141.Dynamiczny ukad strony i dodatkowa
informacja zalena od rozdzielczoci ekranu
142.Kompatybilno z rnymi przgldarkami,
wersjami przegldarek, systemami operacyjnymi
i sprztem
143.Ukryte formatowanie, znaczniki i inne rodzaje
niewidocznej informacji, podnoszce wygod
korzystania ze strony
Oczywicie, pominwszy portale do bezpiecznego handlu internetowego,
witryna na rysunku to jedna z bardziej zoonych i obfitych treciowo witryn
na Internecie. Dla osoby o mentalnoci testera - jakimi zapewne s
czytelnicy tej ksiki - widok tej strony powinien pobudzi apetyt na jej
przetestowanie i znajdowanie bdw. W pozostaej czci rozdziau
znajduj si wskazwki, gdzie najlepiej tych bdw szuka.
Testowanie metodami czarnej skrzynki
Strona 82 (99)
W rozdziaach od 4-ego do 7-ego, daleko na pocztku ksiki, omawiane
byy podstawy testowania. W tych ogromnie istotnych rozdziaach opisane
zostay gwne techniki testowania: czarnej skrzynki, szklanej skrzynki,
statyczne i dynamiczne - stanowice podstawowy arsena kadego testera.
Na stronach WWW mona doskonale zaczc wiczy swe nowonabyte
umiejtnoci. Nie trzeba kupowa adnych nowych programw ani
specjalnych narzdzi - wystarzy rzuci si na jak stron, ulubion albo
zupenie nieznan - i mona zaczyna testowanie.
Najprociej zaczc od tego, e stron WWW - albo nawet ca witryn potraktuje si jak czarn skrzynk. Nie wiemy nic o tym, jak ma dziaa, nie
mamy specyfikacji - jest tylko witryna przed nami. Czego zacz szuka?
Na rysunku 13.2 pokazany jest obraz ekranu witryny Macintosha,
www.apple.com. Jest to do prosta i typowa witryna. Ma wszystkie
podstawowe elementy - tekst, grafik, hiperpoczenia do innych stron na tej
samej witrynie oraz hiperpoczenia do innych witryn. Kilka stron witryny
ma pola do wypenienia, gdzie uytkownik moe wprowadzi informacj, a
kilka innych zawiera sekwencje wideo. Jedna interesujca, rzadziej
spotykana cecha tej witryny to jej lokalizacja - w 27 rnych miejscach, od
Azji a po Wielk Brytani.
Majc dostp do Internetu, warto teraz powici troch czasu na
eksploracj witryny Apple. Jak przystpi do jej testowania? Jakie
zastosowa klasy rwnowanoci? Czego nie warto testowa?
Rysunek 13.2 Co trzeba przetestowa w prostej witrynie jak ta na rysunku?

Po krtkiej eksploracji, do jakich dochodzi si wnioskw? Przypuszczalnie
kady zda sobie spraw, e to bdzie spore zadanie. Na mapie witryny
(www.apple.com/find/sitemap.html) pokazane s poczenia do ponad 60ciu rnych pod-witryn, z ktrych kada sada si z kilku stron WWW.
Testujc witryn WWW, naley zaczc od skonstruowania tabeli stanw
(rozdzia 5-y, Testowanie z klapkami na oczach), gdzie kad stron
potraktuje si jak odrbny stan, a hiperpoczenia - jak przejcia midzy
stanami. Gotowa mapa stanw pozwoli zda sobie spraw z rozmiarw
przedsiwzicia.
Strona 83 (99)
Na szczcie wikszo stron jest do prosta, skadaj si tylko z tekstu,
grafiki, pocze, a gdzieniegdzie z formularzy do wypenienia. Nie jest
trudno je przetestowa. Dalej dowiemy si, czego szuka.
Tekst
Stron WWW naley traktowa tak jak dokumentacj i testowa tak, jak
opisane zostao w rozdziale 12-ym, Testowanie dokumentacji. Trzeba
sprzwdzi, dla kogo strona jest przeznaczona, jaki jest poziom tej grupy,
terminologi, zawarto, tematyk, dokadno - zwaszcza informacj ktra
si starzeje - oraz zawsze, zawsze pisowni.
Nie naley zakada, e programy do kontroli pisowni s doskonae,
zwaszcza zastosowane do zawartoci stron WWW. Program sprawdzi
tylko zwyky tekst, ale nie zawarto tekstow grafiki, rozwijanych
ramek, formularzy itp. Po dokonaniu kontroli pisowni, na stronie nadal
mog znajdowa si bdy.
Dane na temat adresu poczty komputerowej, numeru telefonu, adresu naley
sprawdzi. Sprawdza si rwnie poprawno - w tym dat - informacji o
prawach autorskich.
Trzeba skontrolowa czy kada strona ma waciwy tytu. Ten tekst pojawia
si w pasku tytuowym przegldarki (grny lewy rg na rysunku 13.2) i
wchodzi w skad list ulubionych stron albo zakadek.
Tekstem, ktry atwo przeoczy podczas kontroli, jest tekst ALT, czyli tekst
zastpczy. Rysunek 13.3 przedstawia przykad tekstu ALT. Kiedy
uytkownik ustawia kursor nad elementem graficznym, ukazuje si
wyskakujcy napis, wyjaniajcy jego znaczenie. Tekst ALT
wykorzystywany jest te przez przegldarki nie wywietlajce grafiki.
Niewidomi uytkownicy mog dziki tekstom ALT korzysta ze stron
obficie wykorzystujcych grafik - gosowy czytnik przekazuje teksty ALT
przez gonik komputera.
Ewentualne problemy z ukadem strony mona skontrolowa zmniejszajc
albo powikszajc stron. W ten sposb wychodz na jaw bdy wynike z
tego, e projektant lub programista zaoyli sta wysoko lub szeroko
strony. Ujawni si te bdy ukadu polegajce na wkodowaniu na stae
zmiany wiersza, ktra wyglda doskonale przy pewnym ukadzie strony, ale
nie przy innych.
Hiperpoczenia
Poczenia mog by przyczone do tekstu lub do elementw graficznych.
Naley skontrolowa kade poczenie, czy prowadzi do waciwego celu i
czy otwiera si we waciwym oknie. Nawet nie majc do dyspozycji
specyfikacji strony, mona skontrolowa poprawno wykonanego skoku.
Strona 84 (99)
Hiperpoczenia sprawdza si rownie pod ktem tego, na ile s widoczne.
Poczenie tekstowe s zwykle podkrelone, a kursor ma zmieni ksztat ze
strzaki na do, kiedy znajduje si nad poczeniem - zarwno tekstowym
jak i graficznym.
Jeli poczenie otwiera list poczty komputerowej, naley go wypeni,
wysa i sprawdzi czy otrzymao si stosown odpowied.
Rysunek 13.3 Tekst ALT jest tekstowym opisem elementw graficznych na

stronie WWW.
Szukamy osieroconych stron, istniejcych wprawdzie w danej witrynie, ale
nie dajcych si osign przez adne poczenie, poniewa zapomniano je
podczy. By moe uda si uzyska list istniejcych stron od projektanta
witryny i porwna j nastpnie z wasn tabel stanw. Jeszcze lepiej,
mona wykorzysta list faktycznie istniejcych stron z serwera WWW i
dokona analizy pokrycia kodu, eby sprawdzi czy przetestowao si
wszystkie strony, e adnej nie brakuje i e nie istniej adne dodatkowe
strony.
Grafika
Wiele moliwych bdw zwizanych z grafik omwione zostanie w czci
powiconej testowaniu uytecznoci, ale pewne najbardziej oczywiste
rzeczy mona sprawdzi przy pomocy prostego podejcia
czarnoskrzynkowego. Na przykad, czy wszystkie elementy graficzne s
adowane i wywietalne poprawnie? Jeli plik graficzny nie istnieje albo ma
bdn nazw, nie uda si go zaadowa i przegldarka wywietli komunikat
bdu tam, gdzie powinien by pojawi si element graficzny.
Jaka jest wydajno adowania strony? Jeli strona ma zbyt wiele grafiki, co
wymaga przesania i wywietlenoia wielkiej iloci danych, wtedy tempo
adowania strony jest zbyt niskie. A co si stanie, jeli strona bdzie
adowana przez powolne poczenie przez modem na lini telefonicznej o
niskiej jakoci?
Strona 85 (99)
Rysunek 13.4 Kiedy nie daje si zaadowa elementu graficzngo, na jego

miejscu przegldarka wywietla okno z komunikatem o bdzie.
Formularze
Formularze to s okna tekstowe i inne typy pl sucych do wprowadzania i
wybierania informacji na stronie WWW. Rysunek 13.5 przedstawia prosty
przykad wzity z witryny Apple. Jest to formularz do zapisywania si,
przeznaczony dla programistw dla platformy Macintosha. S tam pola eby
wprowadzi imi, drugie imi, nazwisko i adres poczty komputerowej.
Mamy na tej stornie oczywisty bd - miejmy nadziej, e bdzie
naprawiony zanim czytelnicy zd zapozna si z tym rozdziaem.
Rysunek 13.5 Formularze na stronie WWW powinny by umieszczone we

waciwym miejscu. Warto zwrci uwag na bd ma tej stronie.
Formularze testuje si dokadnie tak samo, jak pola w zwykym programie czas ponownie przypomniec sobie rozdzia 5-y. Czy pola maj waciwe
rozmiary? Czy przyjmuj wszelkie poprawne dane i czy odrzucaj
niepoprawne? Czy uzyskuje si stosowne potwierdzenie po naciniciu
Enter? Czy pola opcjonalne rzeczywicie s opcjonalne, a wymagane
rzeczywicie wymagane? Co si stanie jeli wprowadzi
9999999999999999999999999999?
Obiekty i inne elementy zoone
Strona 86 (99)
Wityrna moe mieci takie funkcje jak licznik odwiedzin, rozwijane ramki
tekstowe, zmienne ogoszenia, albo wewntrzne przeszukiwarki systemu
(nie myli z przeszukiwarkami oglnosieciowymi, przeszukujcymi ca
WWW). Planujc testowanie witryny WWW, trzeba zidentyfikowa funkcje
wystpujce na kadej stronie. Kad z nich traktuje si jak funkcj
zwykego programu i testuje osobno poznanymi technikami testowymi. Czy
ma rne stany? Jak przetwarzane s dane? Czy da si zidentyfikowa
przedziay i wartoci graniczne? Jakie mona znale zadania testowe i na
jakie podzieli je klasy rwnowanoci?
Testowanie metodami szarej skrzynki

Poznalimy ju testowanie metodami czarnej i szklanej skrzynki, ale jest
trzecia metoda - mieszniana obu poprzewdnich - std jej nazwa. Stosujc
testowanie szarej skrzynki, stoi si na granicy obu pozostayh metod. Nadal
testuje si oprogramowanie jak czarn skrzynk, ale uzupelnia si t prac
zerkajc (ale nie zagldajc otwarcie, jak w metodach szklanej skrzynki) na
to, jak oprogramowanie dziaa w rodku.
Stronice WWW nadaj si bardzo dobrze do testowania szarej skrzynki.
Wikszo stron WWW zbudowanych jest z HTML (Hypertext Markup
Language, Hipertekstowy Jzyk Znacznikw). Listing 13.1 pokazuje rzdy
kodu HTML definiujce stron pokazan na rysunku 13.6.
Listing 13.1 Prbka HTML pokazujcy kod rdowy strony WWW
Strona 87 (99)
Rysunek 13.6 Cz tej strony WWW tworzy kod HTML z Listingu 13.1.
Kto z czytelnikw nie umie stworzy wasnej witryny WWW, moe
chcie poczyta troch na ten temat. Ksika dla pocztkujcych, taka jak
Sam uczy w 24 godziny jak samemu stworzy ston WWW pozwoli
nauczy si podstaw i uatwi zrozumienie jak zastosowa metody szarej
skrzynki .
HTML i strony WWW moa testowa jako szar szkrzynk, poniewa
HTML nie jest jzykiem programowania - jest jzykiem znacznikw. W
epoce wczesnych programw do przetwarzania tekstu, nie dao si po prostu
wybra fragmentu teksu i zamieni jego format na tusty druk albo na
kursyw. Trzeba byo uywa znacznikew, zwanych te czasem
znacznikami pl. Aby na przykad napisa zdanie
To jest tekst tustym drukiem.
pisze si co takiego
[begin bold]To jest tekst tustym drukiem.[end bold]
Tak samo dziaa HTML. Aby napisa to samo w HTML, pisze si
<b>To jest tekst tustym drukiem</b>
Strona 88 (99)
HTML ma obecnie setki rnych znacznikw i opcji, co wida na Listingu 13.1.
Niemniej, w grucie rzeczy HTML nie jest niczym innym jak podrasowanym,
starowieckim jzykiem znacznikw. Rnica midzy HTML a programem polega
na tym, e HTML nie jest wykonywane, tylko okrela jak tekst i grafika s
wywietlane na ekranie.
Aby zobaczy w przegldarce Internet Explorer, jak wyglda kod HTML

dla danej strony, klika si prawym klawiszem myszy gdzie na stronie (nie
na elemencie graficznym) i wybiera Kod rdowy (View Source) z menu.
Inne przegldarki dziaaj torch inaczej, ale wikszo daje moliwo
obejrzenia kodu HTML, z ktrego zbudowana jest ogldana w danej
chwili strona.
Poniewa tak atwo dotrze do kodu rdowego HTML, mona to
wykorzysta w trakcie testowania. Dla testera stosujcego metody czarnej
skrzynki jest to doskonaa okazja, by zaczc przesuwa si w stron metod
szklanej skrzynki.
Najlepiej zacz od tego, by nauczy si samemu budowa proste strony
WWW. Nauczywszy si znaczenia podstawowych znacznikw, mona
zacz bada jak zrobione s rne strony WWW dostpne na Intenecie.
Poznawszy HTML, jest si w stanie patrze na strony WWW w nowy
sposb i sta si bardziej skutecznym testerm.
Testowanie metodami szklanej skrzynki

Na rysunku 13.1 widzielimy przykad strony WWW majcej statyczn
zawarto w formie tekstu i grafiki. Tego typu strony zwykle tworzy si przy
pomocy prostego kodu HTML. Strony HTML mog te mie elementy
zmienne, dynamicznie dostosowaywane do potrzeb. Trzeba cay czas
pamita, e HTML nie jest jzykiem programowania, tylko systemem
znacznikw dla tekstu i grafiki. Aby stworzy elementy zmienne, trzeba
uzupeni HTML przy pomocy kodu, ktry moe by wykonywany i
wybiera rne cieki zalenie od warunkw decyzji.
Strona 89 (99)
Najczciej spotykane jzyki programowania1 stosowane do tego to
DHTML, Java, JavaScript, ActiveX, VBScript, Perl, CGI, ASP i XML. Jak
powiedziano w rozdziale 6-ym Badanie kodu i w 7-ym Test
oprogramowania z rentgenem na oczach, nie trzeba koniecznie by
specjalist w dziedzinie danego jzyka programowania, aby zastosowa
testowanie metod szklanej skrzynki - wystarczy zna go na tyle, by mc go
czyta i rozumie, oraz konstruowa zadania testowe na podstawie
znajomoci kodu.
W tym rozdziale nie ma miejsca, aby wda si we wszelkie szczegy
testowania witryn metodami szklanej skrzynki. Niektre funkcje daj si
najlepiej przetestowa przy pomocy metod szklanej skrzynki. Oczywicie,
mona by je te przetestowa metodami czarnej skrzynki, ale zoono
bywa tak dua, e aby na pewno zdoa znale najwaniejsze bdy,
powinno si mie pewn znajomo struktury witryny i programowania:
144.Tre dynamiczna. Tre dynamiczna to
grafika i tekst, ktre zmieniaj si zalenie od
warunkw - na przykad od pory dnia,
preferencji uytkowanika albo tego, co zrobi
uytkownik. Programowanie zmian treci moe
by zrobione w prostym jzyku jak JavaScript i
wbudowane wprost w kod HTML. Nazywa si
to programowaniem po stronie klienta.
Sprawdzajc skrypt i kod HTML, posugujemy
si metodami szarej skrzynki. Jednak ze
wzgldu na wydajno, zwykle programy
umieszca si serwerze WWW; nazywa si to
programowaniem po stronie serwera. Aby mc
zbada kod, musiaoby si mie dostp do
serwera.
Nie wszystkie wymienione tu programy s dosownie "jzykami programowania", ale nie ma to

znaczenia w tym kontekcie (przyp. tumacza).
Strona 90 (99)
145.Strony WWW sterowane przez baz danych.
Wiele stron WWW stosowanych w handlu
internetowym, ktre pokazuj katalogi towarw,
jest sterowanych przez bazy danych. HTML
stwarza prosty ukad strony, za ilustracje, opisy
tekstowe, cenniki itd. ciga si z bazy danych
na serwer WWW i nastpnie wkleja na
odpowiednia stron HTML.
146.Strony WWW stwarzane przez program.
Wiele stron WWW z dynamiczn treci jest
tworzonych przez programy - to znaczy kod
HTML, niekiedy nawet kod skryptowy wytwarza program. Projektant strony WWW
wprowadza odpowiednie dane do bazy danych,
przeciga i upuszcza elementy do programu
robicego skad strony, naciska guzik i po chwili
program dostarcza gotowy kod HTML do
wywietlenia danej strony. Brzmi to gronie, ale
naprawde nie rni si niczym od np.
kompilatora produkujcego kod maszyny1.
Testujc tak stron, naley sprawdzi czy
wygenerowany kod jest zgodny z
oczekiwaniami projektanta.
147.Wydajno i adowanie. Popularne witryny
WWW dostaj miliony trafie dziennie. Kade
trafienie powoduje konieczno zaadowania
strony WWW z serwera WWW do przegldarki
na komputerze klienta2. Aby przetestowa
wydajno i zachowanie systemu pod
obcieniem, naley znale sposb
zasymulowania milionw pocze i adowa3.
A nawet jeszcze "zwyczajniej": dokument - razem z ilustracjami, tabelami itp. - napisany np. w
powszechnie znanym programie Word mona zleci programowi zapisa w formacie HTML i strona
WWW jest gotowa. Innym przykadem takiego programu jest Composer, bdcy czci populanej
przegldarki Netscape Navigator (przyp. tumacza).
2
Zwykle o wiele wicej niz zaadowanie jednej strony. W systemach do handlu Internetowego kade
odwiedziny mog spowodowa adowanie wielu rnych stron, uruchomi poszukiwanie w bazie
danych i inne transakcje (przyp. tumacza).
3
Istnieje wiele programw, ktre to umoliwiaj (wicej na ten temat w rozdziale o automatyzacji), a
nawet firmy, wykonujce na zlecenia tego rodzaju testowanie (przyp. tumacza).
Strona 91 (99)
148.Bezpieczestwo. Zagadnienia bezpieczestwa
witryn WWW czsto trafiaj na pierwsze strony
gazet, gdy hakerzy na rne sposoby usiuj
dosta si do wewntrznych danych witryny.
Witryny zawierajce dane finansowe, medyczne
i inne wymagajce ochrony s szczeglnie
naraone i wymagaj drobiazgowej znajomoci
techniki pracy serwera WWW, aby mc je
przetestowa pod ktem bezpieczestwa.
Mitologia testowania bezpieczestwa
Na pierwsze strony gaet czsto trafiaj historie o hakerach, ktrzy wamali
si do superbezpiecznych witryn i uzyskali poufne informacje. Artykuy
prasowe podkrelaj, e hakerzy zrobili to przy pomocy programu
skadajcego si z trzech linijek kodu albo przez niezamknite tylne
wejcie. Nie dajmy si oszuka - hakerzy musieli pracowa dugo i
ciko, aby znale moliwo wejcia. Oczywicie, wynikiem tej pracy
mg by program majcy zaledwie trzy linijki, ale e=mc2 ma ledwo pi
znakw, a Einsteinowi zajo wiele lat, by to sformuowa. Bdc testerm,
trzeba by przygotowanym na to, e poszukiwanie niezabezpieczonych
drg dostpu do witryny jest czasochonne i trudniejsze ni si na pierwzy
rzut oka wydaje.
Testowanie konfiguracji i kompatybilnoci

Czas powrci do testowania stron WWW. Przypomnijmy sobie najpierw z
rozdziaw 8-ego i 9-ego, co to jest testowanie konfiguracji i
kompatybilnoci. Testowanie konfiguracji polega na sprawdzaniu, jak
oprogramowanie dziaa na rnych rodzajach platform programowych i
sprztowych i na ich rozmaitych konfiguracjach. Testowanie
kompatybilnoci to sprawdzian dziaania oprogramowania razem z innymi
programami. Strony WWW daj szerokie pole do zastosowania obu tych
typw testowania.
Zamy, e mamy do przetestowania witryn WWW. Zastanwmy si,
jakie aspekty konfiguracji sprztu i oprogramowania mog wpyn na
dziaanie lub wygld witryny. Oto lista propozycji:
149.Platforma sprztowa. Czy to jest Macintosh,
PC, wbudowana w telewizor przegldarka,
telefon czy zegarek na rk? Kade urzdzenie
na swj wasny system operacyjny, ukad
ekranu, oprogramowanie komunikacyjne itd.
Kady z tych aspektw wpywa na wygld stron
WWW na ekranie.
Strona 92 (99)
150.Rodzaj i wersja przegldarki. Istnieje wiele
rnych typw przegldarek - a kada ma wiele
wersji. Niktre dziaaj tylko na jednej
platformie sprztowej, inne na wielu. Przykady:
Netscape navigator 3.04 i 4.05, Internet Explorer
3.02, 4.01 i 5.0, Mosaic 3.0, Opera, Emacs.
Kada przegldarka i kada wersja ma nieco inny zestaw moliwoci.
Strona WWW moe wyglda wietnie w jednej przegldarce, a nie da
si wywietli w ogle w innej. Projektanci witryn maj do wyboru dwie
drogi: albo zaprojektowa witryn uywajc najmniejszego wsplnego
mianownika, tak eby wygldaa bardzo podobnnie na wszystkich
przgldarkach, albo napisa kod wykorzystujcy wszelkie ciekewe
moliwoci jednej z nich. Jakie ma to znaczenie dla testowania?
151.Wtyczki programowe. Wiele przegldarek
stosuje wtyczki programowe albo inne
rozszerzenia, aby uzyska dodatkowe
moliwoci, na przykad aby mc odgrywa
muzyke lub wywietla wideo.
152.Opcje przegldarki. Wiele przegladarek ma
wiele ronych ustawie. Na rysunku 13.7
znajduje si przykad. Mona wybra opcje
dotyczce bezpieczestwa, wybra sposb
dziaania tekstu ALT, uaktywni wybrane
wtyczki programowe itd. Kada opcja moe
wpyn na to, jak bdzie si zachowywa i
wyglda przegdana witryna - co stwarza nowe
moliwe scenariusze do przetestownania.
Rysunek 13.7 Przykad ilustrujcy moliwoci rnorakiego

skonfiguraowania przegldarki Internet Explorer.
Strona 93 (99)
153.Rozdzielczo ekranu i wielko skali kolorw.
Na wielu platformach mona wybra rne
rozdzielczoci ekranu i kolory. Na przykad na
PC pod Windows mona wybra rozmiary
ekranu 640x480, 800x600, 1024x768,
1280x1024 i jeszcze wiksze. Strona WWW
moe prezentowa si dobrze tylko przy pewnej
rozdzielczoci, a nie przy innej. Tekst i grafika
mog mie inaczej zawinite wiersze, by
obcite albo nie pojawia si wcale.
Dostpna skala kolorw te moe wpyn na wygld witryny. Ilo
kolorw moe by bardzo rna - od 15 do 224. Czy testowana witryna
daje si oglda tylko w 16-u kolorach?
154.Wielko tekstu. Uytkownik moe zmienia
wielko tekstu uywanego przez przegldark.
Czy strona da si oglda, kiedy wybrana
czcionka jest szczelnie maa lub szczeglnie
wielka? Co si stanie, jeli oglada j na maym
ekranie z niska rozdzielczoci i du czcionk?
155.Szybko modemu. Nie da si przeceni
znaczenia wydajnoci. Kiedy, w przyszoci,
kady bdzie mie poczenie do Internetu
wysokiej szybkoci, dostarczajce nowe dane
tak szybko, jak tylko zdoa si je przeczyta.
Zanim to nastpi, trzeba sprawdza, jak witryna
funkcjonuje dla rnych szybkoci modemw.
Wziwszy pod uwag wszystkie powysze moliwoci, przetestowanie
nawet najprostszej stroniczki WWW staje si olbrzymim przedsiwziciem.
Nie wystarczy, by wygldaa dobrze na PC projektanta. Musimy mie
pewno, e bdzie poprawnie dziaa i wyglda dla wszystkich, do kogo
chcemy dpotrze. W tym celu trzeba uwzldni, jakie uytkownicy mog
mie konfiguracje. Majc t wiedz, mona wybra klasy rwnowanoci
dla konfiguracji najwaniejszych do przetestowania.
Testowanie uytecznoci
Uyteczno i witryny WWW zdaj si niekiedy wyklucza. Kady spotka
si z witrynami na ktrych nawigacja jest trudna, ktre s nieaktualne,
powolne albo po prostu brzydkie. Nic dziwnego, e te witryny zapewne
nigdy nie przeszy przez rce testera oprogramowania. Programista albo kto
inny z niedostateczn znajomoci zasad projektowania i wzornictwa (albo
ze zbyt wielk wiedz na temat wzornictwa) skonstruowa strony i
zaadowa, nie dbajc o to czy s uyteczne.
Strona 94 (99)
Jak powiedziane zostao w rozdziale 11-ym, testowanie uytecznoci
nieatwo jest zdefiniowa. Co nie podoba si jednemu, podoba si drugiemu
- niektrzy uwaaj e jele na rykowisku1 to wielka sztuka. Na szczecie,
przestrzegajc kilku prostych zasad - i testujc ich uycie - mona uczyni
witryny WWW uyteczniejszymi.
Jakob Nielsen, www.useit.com, znany ekspert w zakresie wzornictwa i
uytecznoci witryn WWW, dokona wielu bada w tej dziedzinie. Ponisze
punkty przystosowane s z jego ksiki Dziesi gwnych bdw
projektowania witryn WWW2:
156.Nieuzasadnione uycie najostrzejszych
technologii. Witryna nie ma usiowa
przycign uwagi uytkownikw
ostentacyjnym stosowaniem najnowszych
dostpnych technologii. Bdzie to aktrakcyjne
dla kilku technologicznych fanatykw, ale dla
wikszoci uytkownikw najwaniejsza jest
zawarto strony i dobra jako oferowanego
wsparcia i serwisu. Uycie najnowszych
technologii zanim jeszcze si rozpowszechniy
jest pewn recept na zniechcenie
uytkownikw. Jeli ich system ulegnie awarii
podczas odwiedzin takiej witryny, niewielu
bdzie prbowao powrci. Wyjwszy firmy
sprzedajce internetowe produkty lub serwis,
lepiej jest zaczeka a zastosowana technologia
bdzie ju dostatecznie rozpowszechniona. W
czasach, kiedy skad komputerowy by
nowoci, niektrzy potrafili zastosowa i
dwadziecia rnych typw czcionek w swoim
dokumnecie. Unikajmy podobnych puapek przy
projektowaniu stron WWW.
157.Rozwijany tekst, ruchome ramki,
nieustannie poruszjce si animacje. Nie
wolno dopuci elementw strony bdcych w
cigym ruchu. Poruszajce si obiekty
przycigaja zawsze ludzkie tak zwane widzenie
peryferyjne. Strona WWW nie powinna
naladowa neonowej tablicy ogoszeniowej w
nieustannym ataku na zmys wzroku - dajmy
uytkownikom chwil spokoju, eby mogli
przeczyta znajdujcy si na stronie tekst!
W oryginale "Elvis on velvet" - tyz piknie! (przyp. tumacza).
W oryginale: Top Ten Mistakes in Web Design (przyp. tumacza).
Strona 95 (99)
158.Dugie, przewijane strony. Uytkownicy
zwykle nie lubi przewijania poza infromacj
widoczn na ekranie po pierwszym otwarciu
strony. Kluczowe informacje i opcje do
nawigacji powinny by dostpne w grnej czci
strony. Ostatnie badania wskazuj, e dzisiejsi
uytkownicy s bardziej skonni przewija
strony ni w pocztkowym okresie Internetu, ale
nadal warto minimalizowa przewijanie.
159.Niestandardowe kolory pocze.
Hiperpoczenia do stron, ktrych uytkownik
nie odwiedzi powinny byc niebieskie, za do
stron wczeniej odwiedzonych purpurowe lub
czerwone. Nie powinno si niczego z tymi
kolorami wydziwia - spjno jest konieczna,
eby uytkownicy nauczyli si znaczenia tych
kolorw. Odrnianie pocze ju wczeniej
wykorzystanych od jeszcze niewykorzystanych
jest jedn z nielicznych pomocy nawigacyjnych
dostpnych we wszystkich niemal typach
przegldarek.
160.Przestarzaa informacja. Zesp projektowy
powinien mie do dyspozycji ogrodnika
WWW - kogo zajmujcego si usuwaniem
chwastw i przesadzaneim kwiatw kiedy
ksztat strony si zmienia. Niestety, wiele
zespow woli wytwarza nowe strony ni
zajmowa si pielgnacj starych. W
rzeczywistoci, pielgnacja jest tanim sposobem
na poprawienie zawartoci witryny. Wikszo
starych stron zachowuje sw warto i podcza
si je do nowych stron. Oczywicie,
zdezaktualizowane strony najlepiej usun z
serwera jak najszybciej.
161.Zbyt dugi czas adowania. Szacuje si, e
okoo 0,1 sekundy to maksyamalny czas reakcji,
przy ktrym uytkownicy maj wraenia, e
system reaguje bezzwocznie. Jedna sekunda to
grna granica czasu, do ktrej bieg myli
pozostaje nienaruszony. Dziesi sekund to
najduszy moliwy czas zatrzymania
zainteresowania uytkownika. Uytkownicy
Internetu tylekro byli naraeni na dugie czasy
adowania, e przypuszczalnie maj nieco
wiksz odporno, tak e by moe wolno
przeduy ten limit czasu do 15 sekund przez
kika stron. Niemniej nie naley si tym
zadowala - poprzeczk naley umieci o wiele
niej.
Strona 96 (99)
162.Brak wsparcia dla nawigacji. Nie wolno
zakada, e uytkownicy znaj witryn tak
samo dobrze, jak jej autorzy. Zawsze bdzie im
trudno znale waciw informacj, wic trzeba
im pomc, dajc silne, wyrane oparcie w
strukturze i orientacji w pooeniu.
Projektowanie witryny naley zacz od
zrozumienia struktury informacji. T sam
orientacj trzeba jako przekaza
uytkownikom. Najlepiej sporzdzi map
witryny, na ktrej uytkownicy moga ledzi
gdzie s i dokd mog pj. Witryna powinna
take dysponowa dobr przeszukiwark, gdy
sama pomoc w nawigacji zwykle nie wystarcza.
163.Osierocone strony. Kada strona powinna byc
oznaczona, do jakiej witryny naley, bo
uytkownicy moga przecie wejc na ni
wprost, pomijajc stron domow. W tego
wanie podou, kada strona witryny powinna
mie poczenie powrotne, prowadzce do
strony domowej oraz wyjanienie, gdzie w
strukturze witryny w danej chwili si
znajdujemy.
164.Zoone adresy witryn WWW (URL-e). W
zasadzie "maszynowy" adres URL nie powinien
w ogle pojawia si w interfejsie uytkownika,
ale kada przegldarka go wywietla, a praktyka
i badania dowodz, e uytkownicy czsto przy
jego pomocy usiuj domysli si struktury
witryny. Przyczyn tego stanu rzeczy jest brak
wspomagania dla nawigacji i orientacji we
wsplczesnych przegldarkach. Tak wic naley
to bra pod uwag i uywa w URL-ach
czytelnych dla ludzi nazw, tak by
odzwierciedlay natur zawartoci danej strony.
Uytkownicy czsto pisz rwnie adresy URL, tak wic naley stara si
minimalizowa ryzyko pomyek uywc krtkich nazw, tylko maych liter
i adnych znakw specjalnych - wiele osb nie wie, jak przy pomocy
klawiatury napisa znak ~.
Strona 97 (99)
165.Uywanie ram. Ramy to technika HTML
umoliwiajca wywietlanie stron WWW
wewntrz storn WWW, ska nazwa rama - jak
rama obrazu. Podzielenie strony na ramy myli
uytkownikw, gdy sprzeniewierza si
intuicyjnemu modelowi strony wikszoci
uytkownikw. Znienacka nie mona oznaczy
biecej strony zakadk i powrci do niej
(zakadka wskazuje na inn cz systemu ram),
adresy URL przestaj dziaa, a wydruki staj
si utrudnione. Co gorsza, znika te
przewidywalno dziaa - kto wie, co si stanie,
kiedy kliknie si na poczenie?
Testujc witryn, warto wykorzysta przysugujce testerom prawo
skadania rwnie donosw na bdy uytecznoci. Warto poczyta na temat
podstawowych zasad projektowania interfejsu i dowiedzie si, na czym
polega uyteczno. Dobrym rdem informacji jest wydana przez
Microsoft praca pod tytuem "Poprawa uytecznoci i atrakcyjnoci witryn
WWW" (Improving Web Site Usability and Appeal). Jej adres na WWW jest
msdn.microsoft.com/workshop/management/planning/improvin
gsiteusa.asp. W tym dokumencie znajduje si obszerna lista
dowiadcze, jakie Microsfot zdoby w trakcie opracowywania swojej

wasnej witryny MSN. Niech nikogo nie zniechci data - 1997 - tego
dokumentu. Dobre wzory si nie starzej.
Wprowadzanie automatyzacji
Ostatnia cz tego rozdziau wprowadza w pewnym sensie do nastpnego
rozdziau ksiki, rozdziau 14-ego "Testowanie automatyczne i narzdzia
do testowania".
Czytajc ten rozdzia mona byo si czasem zastanawia, w jaki sposb jest
w ogle moliwe zdy przetestowa du i skomplikowan witryn
WWW. Zwyke klikanie wszystkich pocze w celu sprawdzenia, czy s
poprawne moe zajc mnstwo czasu. Jeli doda do tego testowanie
podstawowych funkcji, test konfiguracji i kompatybilnoci oraz wymylenie
sposobw na przetestowanie osigw i obcienia poprzez symulowanie
tysicy czy nawet milionw uytkownikw, ma si naprawde sporo pracy.
Strona 98 (99)
Na szczcie nie trzeba tego wszystkiego robi rcznie. Dostpne s
narzdzia do testowania, zarwno darmowe jak i do kupienia, ktre moga
znacznie uatwi prac. Darmowe narzdzia mona znale pod
www.netmechanic.com lub pod websitegarage.netscape.com. W obu
tych witrynach znajduj si atwe w uyciu narzdzia do automatycznej
analizy witryny i testowania pod ktem niekompatybilnoci z
przegldarkami, kopotw z wydajnoci, pknitych hiperpocze,
zgodnoci ze standardem HTML i bdw pisowni. Mog nawet
powiadomi, ktre grafiki witryny sa zbyt due i mog spowodowa zbyt
powolne adowanie. Te narzdzia potrafi zaoszczdzi wiele godzin
mozolnej, rcznej pracy. Warto im si przyjrze eby zorientowa si, o
czym bdzie mowa w rozdziale 14-ym.
Podsumowanie
Ten rozdzia zamyka cz III- "Zastosowanie umiejtnoci w praktyce".
Zapoznalimy si w niej z tematyk bardzo obszern: poczwszy od
ustawie karty wideo, poprzez wgierskie ulokalnienie programu, a do
brzydkich witryn WWW. Te tematy to jedynie fragment caego wiata
oprogramowania. Ta rnorodno powoduje, e testowanie
oprogramowania jest nieskoczonym wyzwaniem. Kadego dnia wytwarza
si nowe, fascynujce programy, technologia robi kolejny krok naprzd i
pojawiaj si do rozwizania nowe interesujce problemy w dziedzinie
testowania. Testowanie witryn WWW jest dzisiaj stosownym tematem do tej
czci ksiki, ale kto wie, co bdzie nim w przyszoci.
Mijemy nadzieje, e po przeczytaniu rozdziaow w czci III-ej zdajemy
sobie spraw, e nawet przetestowanie maej witryny czy niewielkiego
programu bywa zadaniem przekraczajcym moliwoci jednego testera czy
nawet zespou testerw. Przetestowanie napisanego przez jednego
programist, liczcego kilkaset rzdw programu moe wymaga dziesitek
albo nawet setek testerw, aby mogli oni dokadnie przetestowc wszelkie
moliwe platformy, konfiguracje, jzyki i typy uytkownikw. Ilo
kombinacji i permutacji jest bezkresna i nawet przy zastosowaniu podziau
na klasy rwnowanoci ilo pracy moe przekracza nasze moliwoci.
W nastpnych dwch rozdziaach dowiemy si, jak - przy pomocy zarwno
ludzkich si jak i narzdzi - zredukowa to zadanie do rozsdniejszych
wymiarw.
Pytania
1.Jakie podstawowe elementy strony WWW mona atwo przetestowa
technikami czarnej skrzynki?
2.Co to jest testowanie metodami "szarej skrzynki"?
Strona 99 (99)
3.Dlaczego moliwe jest zastosowanie metod szarej skrzynki do testowania
witryn WWW?
4.Dlaczego program do wyszukiwania bdw pisowni nie gwarantuje
poprawnej pisowni na stronie WWW?
5.Wymie par wanych zagadnie, ktre trzeba wzi pod uwag przy
testowaniu konfiguracji i kompatybilnoci witryn WWW.
6.Ktre z opisanych przez Jakoba Nielsena 10 gwnych bdw witryn
WWW spowodowayby bdy kompatybilnoci i konfiguracji?
Strona 1 (34)
Cz IV
Czym wesprze testowanie
Gdyby caa armia map stukaa w maszyny do pisania, mogaby napisa

wszystkie ksiki z Muzeum Brytyjskiego.
-
Sir Arthur Eddington, brytyjski astronom i fizyk
W TEJ CZCI
Testowanie automatyczne i narzdzia do testowania
Polowanie na bdy i testowanie beta
Strona 2 (34)
Rozdzia 14 Testowanie automatyczne i narzdzia do

testowania
W TYM ROZDZIALE
Poytki z automatyzacji i narzdzi
Narzdzia do testowania
Automatyzacja testu oprogramowania
Testowanie na chybi-trafi: mapy i goryle
Uycie narzdzi i automatyzacja testowania w rzeczywistoci
Testowanie oprogramowania to cika praca. Kto podczas lektury tej ksiki
zajty by take testowaniem, wie e samo wykonywanie testw to cika,
fizyczna praca, ktra zajmuje wiele czasu i kosztuje wiele wysiku.
Oczywicie, mona by woy jeszcze wicej wysiku w zmniejszenie iloci
klas rwnowanoci, dziki czemu ilo zada testowych do wykonania te
byaby mniejsza, ale w ten sposb zwikszyoby si rwnie poziom ryzyka,
zmniejszywszy pokrycie testowe i dokonujc wyboru, e pewne - moe
istotne - funkcje nie zostan przetestowane. Trzeba testowa wicej, ale nie
ma na to czasu. Co pocz?
Rozwizaniem jest zastosowanie metody znanej ju od dawna z wielu
innych dziedzin i przede wszystkim z przemysu wytwrczego - wynale i
zastosowa narzdzia, ktre uczyni prac atwiejsz i skuteczniejsz. O tym
wanie traktuje ten rozdzia.
Najwaniejsze punkty rozdziau:
1. Czemu uycie narzdzi do testowania i
automatyzacja s konieczne
2. Przykady prostych narzdzi
3. W jaki sposb zastosowanie narzdzi przeradza
si w automatyzacj
4. W jaki sposb karmi i dba o mapy
5. Czemu automatyzacja testowania nie jest
lekarstwem na wszystko
Poytki z automatyzacji i z narzdzi
Strona 3 (34)
Przypomnijmy sobie, co wiemy o wytwarzaniu oprogramowania. W
wikszoci modeli wytwarzania oprogramowania, ptla kodowanie testowanie - poprawki powtarza si wielokrotnie przed ostatecznym
wypuszczeniem oprogramowania. Oznacza to, e kady test moe trzeba
bdzie wykona nie jeden raz, ale dziesitki razy. Sprawdza si, czy bdy
znalezione w czasie wykonywania poprzedniej serii testw rzeczywicie
zostay naprawione i e nie pojawiy si adne nowe bdy. Ten proces
ponownego wykonywania tych samych zada testowych nazywany jest
testowaniem regresywnym1.
May projekt produkcji oprogramowania, majcy kilka tysicy zada
testowych do wykonania, moe nie mie nawet czasu aby wykona je
wszystkie cho jeden raz. Wielokrotne ich wykonywanie jest wobec tego
niemoliwe, pomijajc ju to, e byoby okropnie monotonne. Narzdzia do
testowania i do automatyzacji rozwizuj ten problem stwarzajc lepsze
metody ni rczne wykonywanie testw.
Oto najwaniejsze zalety narzdzi i automatyzacji:
6. Szybko. Wyobramy sobie, ile czasu zajoby
rczne wykonanie paru tysicy zada testowych
dla Kalkulatora Windowsw. Tester moe w
najlepszym razie wykonywa jedno zadanie na,
powiedzmy, pi sekund. Automatyzacja moe
skrci ten czas 10, 100 a nawet 1000 razy.
7. Skuteczno. Bdc zajtym wykonywaniem
testw, nie robi si w tym czasie nic innego.
Majc do dyspozycji narzdzie, ktre skraca
czas potrzebny na wykonanie testowania,
otrzymuje si wicej czasu do dyspozycji na
planowanie i projektowanie zada testowych.
8. Trafno i precyzja. Zrobiwszy to samo
kilkaset razy, czowiek nie jest w stanie duej
zachowa tej samej koncentracji i ryzyko
popenienia bdu wzrasta. Narzdzie wykonuje
testy i kontroluje wyniki rwnie dobrze za
kadym razem.
9. Nieustpliwo. Narzdzia do testowania nigdy
si nie mcz i nigdy nie rezygnuj. Dziaaj jak
ten krlik na bateryjki z reklamy telewizyjnej:
chodz w kko i w kko i
Warto jest odrnia zadania testowe wykonywane ponownie po to, by sprawdzi, e wykryty
wczeniej bd rzeczywicie zosta naprawiony od tych, ktre wykonuje si ponownie po to, by
sprawdzi, czy funkcje dziaajce uprzednio dziaaj nadal. Niektre standardy stosuj okrelenie
testowanie ponowne (re-testing) na pierwszy rodzaj, za testowanie regresywne (regression testing)
wycznie na drugi rodzaj (przyp. tumacza).
Strona 4 (34)
Wszystko to brzmi piknie - mona kaza narzdziom wykona za nas ca
prac, uruchomi je i spokojnie czeka na wyniki. Niestety, nie jest a tak
dobrze. Domw nie da si budowa automatycznie, chocia ciele maj do
dyspozycji piy motorowe i pistolety do wbijania gwodzi. Narzdzia
uatwiaj prac i umoliwiaj osignicie lepszej jakoci. Tak samo dziaaj
narzdzia do testowania.
Narzdzia do testowania nie zastpi testerw - tylko pomog testerom
lepiej wykonywa swoj prac.
Warto wzi pod uwag, e nie zawsze uycie narzdzi do testowania jest
wciwym rozwizaniem. Czasem nic nie zastpi testowania rcznego1. Na
razie zapoznamy si z moliwociami i sposobem dziaania narzdzi,
zastanawiajc si przy tym, jak mona by je zastosowa do stojcych przed
nami zada testowych. Na kocu rozdziau dowiemy si, jakie s
ograniczenia i jak zachowa ostrono, zanim podejmie si prby uycia
narzdzi w rzeczywistych projektach.
Tester oprogramowania spotyka si z wieloma rnymi rodzajami narzdzi.
Co bdzie przydatne w praktyce zaley od typu testowanego
oprogramowania i od tego, czy wykonuje si testowanie metodami czarnej
czy szklanej skrzynki.
Pikno narzdzi do testowania polega na tym, e nie zawsze trzeba by
specjalist od tego, jak one dziaaj ani co dokadnie robi, by mc nimi
skutecznie si posugiwa. Wyobramy sobie, e testuje si oprogramowanie
siei, ktre umoliwia komputerowi jednoczesny kontakt z milionem innych
komputerw. Byoby trudno lub wrcz niemoliwe przeprowadzi test
miliona rzeczywistych pocze. Majc do dyspozycj narzdzie pozwalajce
symulowa takie poczenia - na przykad dzwonic na rne numery
telefoniczne od jednego do miliona - daoby si wykona taki test bez
potrzeby stosowania rzeczywistych scenariuszy. Nie musi si rozumie, w
jaki sposb takie narzdzie dziaa - wystarczy e dziaa. Oto testowanie
czarnej skrzynki.
Z drugiej strony, mona posuy si narzdziami do monitorowania i do
modyfikowania protokou komunikacyjnego - midzy tym milionem
komputerw - na niskim poziomie. Aby skutecznie posugiwa si takim
narzdziem, trzeba umie stosowa metody szklanej skrzynki i rozumie
dziaanie protokou na niskim poziomie.
Jest popularne przysowie - "automatyczny chaos to szybszy chaos" - bardzo stosowne w odniesieniu
do automatyzacji testw oprogramowania (przyp. tumacza).
Strona 5 (34)
W tym przykadzie spotykamy si z istotnym rozrnieniem dwch
rodzajw narzdzi: nieintruzyjnych oraz intruzyjnych1. Jeli narzdzie
uywane jest tylko do tego, by by monitorowa i bada stan programu nie
modyfikujc go w adnen sposb, uwaa si je za nieintruzyjne. Jei
jednak narzdzie modyfikuje kod programu albo zmienia w jaki sposb
jego rodowsiko, nazywa si je intruzyjnym. Mona wyrni rozmaite
stopnie itruzyjnoci. Testerzy zwykle usiuj posugiwa si narzdziami
jak najmniej intruzyjnymi aby zmniejszy moliwo wpywu narzdzia
na uzyskiwane wyniki testw2.
Na kilku najbliszych stronach zostan opisane najwaniejsze rodzaje
narzdzi do testowania i sposoby och zastosowania. Niektre z opisanych
narzdzi s zwykle czci rodowiska wikszoci jzykw programowania,
inne s sprzedawane osobno. Moe si jednak zdarzy, e wytwarzany
sprzt lub oprogramowania jest na tyle specyficzne, e potrzebne s
specjalne narzdzia na zamwienie - albo wykonane samemu - dostosowane
do tych potrzeb. Rwnie te narzdzia daj si zwykle zaliczy do jednej z
opisanych dalej kategorii.
Analizatory i monitory
Analizatory albo monitory to narzdzia pozwalajce obserwowa szczegy
dziaania programu, ktrych nie da si zobaczy goym okiem. W rozdziale
7-ym Testowanie oprogramowania pod rentgenem poznalimy analizatory
pokrycia testowego, pozwalajce na identyfikacj wykonanych linii kodu,
funkcji oraz cieek, przez ktre program przeszed podczas wykonywania
zada testowych. Analizator pokrycia testowego jest jednym z przykadw
analizatora. Wikszo analiazatorw pokrycia jest intruzyjnych poniewa
musz by wkompilowane albo wczone w program, eby mie dostp do
dostarczanej informacji.
W oryginale non-invasive (nieintruzyjne) oraz invasive (intruzyjne). Czciej spotykane okrelenia to

non-intrusive oraz odpowiednio intrusive (przyp. tumacza).
2
Nie cakiem tak jest. Uycie narzdzi zwiksza skuteczno i szybko testw, ale kosztem
zastosowania intruzyjnych narzdzi, ktre powoduj, e rodowisko testowania rni si od
operacyjnego. Celem jest osignicie waciwej rnowagi midzy tymi dwoma przeciwstawnymi
tendencjami oraz w miar prezycyjne oszacowanie wpywu intruzyjnoci na wyniki testw (przyp.
tumacza).
Strona 6 (34)
Rysunek 14.1 pokazuje inny rodzaj analizatora - analizator komunikacyjny
(okrelany te czsto angielskim sowem sniffer, obwchiwacz). To
narzdzie umoliwia obserwacj danych przesyanych przez sie albo inne
cze komunikacyjne. Takie narzdzie po prostu podcza si do linii
komunikacyjnej, wychwytuje przesyane pakiety danych i wywietla je na
innym komputerze. Testujc taki system, wprowadzioby si dane inicjujce
zadanie testowe na komputerze nr 1, skontrolowao komunikacj na
komputerze nr 3 i sprawdzio poprawnoc wyniku na komputerze nr 2. Tym
samym systemem posuylibymy si w czasie poszukiowania rda bdu
po odkryciu awarii. Badajc przesyane dane, mona by stwierdzi, czy
rdem problemu jest generowanie danych (komputer nr 1), czy te ich
interpretacja (komputer nr 2). Ten rodzaj systemu jest nieintruzyjny
wzgldem oprogramowania.
Komputer nr 1
Testowane oprgramowanie
Komputer nr 2
Testowane oprgramowanie
cze komunikacyjne
Podczenie
analizatora
Komputer nr 3
Analizator - narzdzie testowe
Rysunek 14.1 Analizator komunikacji umoliwia obserwowanie danych

przesyanych midzy dwoma systemami.
Programy ledzce dostpne razem z wikszoci kompilatorw te taktuje
si jako analizatory, poniewa umoliwiaj testerom posugujcym si
metodami szklanej skrzynki na dostp do wartoci zmiennych i ledzenie
stanw programu. Kade narzdzie umoliwiajce wgld w dane programu,
do ktrych zwyky uytkownik nie ma dostpu, mona zaklasyfikowa jako
analizator.
Sterowniki
Strona 7 (34)
Sterowniki to narzdzia stosowane do sterowania i kontrolowania
testowanego oprogramowania. Najprostszym przykadem sterownika jest
plik wsadowy (batch file), bdcy prost list sekwencyjnie wykonywanych
programw lub komend. W czasach MS-DOS bya to popularna wrd
testerw metoda wykonywania programw testowych. Konstruowao si
plik wsadowy zawierajcy nazwy programw testujcych, puszczao si plik
i szo do domu. Wpczesne systemy operacyjne i jzyki programowania
maja bardziej wyrafinowane metody wykonywania programw testowych.
Na przylkad, w miejsce starego pliku wsadowego MS-DOS mona
zastosowa skomplikowany skrypt w Perlu, za Widows Task Scheduler
(program szeregujcy, rysunek 14.2) mona zastosowa do puszczania
rnych programw testowych o okrelonych porach dnia.
Rysunek 14.3 pokazuje inny rodzaj sterownika. Zamy e testopwane
oprogramowanie wymaga wprowadzania wielkich iloci danych testowych.
Przy pomocy nieco zmodyfikowanego sprztu i paru narzdzi
programowych, mozna zastpi klawiatur i mysz testowanego systemu
przy pomocy dodatkowego komuptera, dziaajcego jak strownik. Na tym
komputerze mona napisa proste programy, automatycznie generujce
uderzenia klawiszy i ruchy myszy, ktre program przekazuje testowanemu
oprogramowaniu.
Rysunek 14.2 Program szeregujcy umoliwia wyznaczenie kolejnoci

wykonywania programw lub plikw komend.
Strona 8 (34)
Normalna konfiguracja
Kabel klawiatury
Kabel myszy
Sterownik testow
Rysunek 14.3 Komputer moe dziaac jako sterownik zastpujcy klawiatur

i mysz w testowanym systemie.
Mona zada sobie pytanie, po co zawraca sobie gow tak
skomplikowaym ustawieniem? czemu po prostu nie uruchomi na
pierwszym systemie programu, ktry wysyalaby uderzenia klawiszy do
testowanego oprogramowania? S tutaj dwa moliwe problemy:
10. System operacyjny moe nie by
wielozadaniowy, co uniemoliwia jednoczesne
wykonywanie obu programw.
11. Wysyajac uderzenia klawiszy i ruchy myszy z
osobnego komputera, stawarzamy system
wzgldnie nieintuzyjny. Kiedy za sterownik jest
wykonywany na tym samym komputerze co
testowaney program, jest to intruzyjne, co
mona uzna za niedozwolony sposb
testowania.
Szukajc sposobu sterowania testowanuym oprogramowaniem, trzeba wzi
pod uwag wszelkie techniki zewntrznego sterowania programem, a potem
zacz szuka sposobu, jak istniejc kontrol zastpic czym, co bdzie
automatycznie wprowadza dane wejciowe.
Namiastki
Namiastki, tak jak sterowniki, zostay ju wspomniana w rozdziale 7-ym,
powiconym technikom szkalnej skrzynki. Namiastki s dokadn
odwrotnoci sterownikw w tym sensie, e e niczym nie kieruj, tylko
przyjmuj i odpowiadaj na dane, wysyane przerz testowane
oprogramowania. Rysunek 14.4 ilustruje t sytuacj.
Strona 9 (34)
Normalna konfiguracja
Konfiguracja
namiastkowa
Rysunek 14.4 Komputer moe dziaa jako namiastka, zastpujc drukark i

umoliwiajc skuteczniejsz analiz danych wyjciowych z testw.
Testujc oprogramowanie, ktre wysya dane na drukark, mona je
przetestowa rzeczywicie drukujc dane na drukarce i kontrolujc wydruk
na papierze. Bdzie to dziaa, ale do wolno, nieefektywnie i bdzie si
naraonym na dowolno. Czy da si zauway, e brakuje jednego piksela
albo minimaln rnic w kolorze? Gdyby zamiast tego zastpi drukark
innym komputerem z programem (namiastk) czytajc i intrepretujc dane
wysyane do drukarki, daoby si skontrolowa wyniki znacznie szybciej i
precyzyjniej.
Namiastki czsto uywa si, gdy programowanie musi komunikowa si z
zewntrznym sprztem. W czasie wytwarzania oprogramowania czsto
sprzt jeszcze nie istnieje albo jest trudno go zdoby. Uycie namiastki
pozwala rozpocz test oprogramowania zanim jeszcze powsta sprzt, a
ponadto czyni testowanie skuteczniejszym.
Czasem uywa si terminu emulator na okrelenie urzdzenia, ktre
zastpuje inne urzdzenie. Na przykad PC zastpujcy drukark w ten
sposb, e interpretuje kody wysyane przez program do drukarki i
odpowiada programowi tak jakby to robia drukarka, jest wanie
emulatorem. Rnica midzy emulatorem a namiastk jest taka, e
namiastka umoliwia take dostp i analiz wysyanych do niej danych.1
Narzdzia do testowania przeciajcgo i na obcienie
Te narzdzia - jak sama nazwa wskazuje - su do obciania i przeciania
testowanego oprogramowania. Na przykad testowany program do
przetwarzania tekstu dziaa poprawnie kiedy jest jedyn dziaajc na
systemie w danej chwili aplikacj, z dostpem do caej pamici i przestrzeni
na dysku. Ale kiedy tych zasobw zacznie brakowa w systemie, zwiksza
si szansa awarii. eby to spowodowa, mona oczywicie skopiowa na
dysk wiele plikw, eby go zapeni, albo uruchomi wiele programw
jednoczenie, eby wypeniy pami komputera, ale takie metody s mao
skuteczne i nieprecyzyjne. Narzdzie specjalnie zaprojektowane do takiego
testowania znacznie je uatwia.
Rnica midzy emulatorem, symulatorem i namiastk to zawsze atrakcyjny temat do dsykusji w

czasie przerw na kaw. Sowo namiastka (ang. stub) zwykle - inaczej ni w tej ksice - uywane jest
na oznaczenie kodu (rutyny), ktra zstpuje kod jeszcze nie gotowy z trakcie integracji odgrnej.
Strona 10 (34)
Rysunek 14.5 przedstawia program Microsoft Stress, wchodzcy w skad
rodowiska pracy dla programistw, tej samej firmy. Inne systemy
operacyjne te maj podobne narzdzia. Program przeciajcy pozwala
ustawia ilo pamici wewntrznej, powierzchni dysku, plikw i innych
zasobw dostpnych dla testowango programu.
Rysunek 14.5 Program Microsoft Stress umoliwia ustawianie iloci

zasobw dostpnych dla testowanego oprogramowania.
Ustawienie wartoci zasobw na poziom zerwoy lub bardzo niski wymusi na
oprogramowaniu wykonywanie innych ni zwykle cieek, obsugujcych
sytuacje tego rodzaju ogranicze. Oprogramowanie powinno w tej sytuacji
dziaa bez awarii i bez utraty danych. Moe pracowa wolniej, wywietla
komunikaty o braku zasobw itp, ale powinno dziaa poprawnie i
degradacja funkcjonalnoci powinna nastpowa w sposb kontrolowany.
Narzdzia obciajce s podobne do narzdzi przeciajcych w tym
sensie, e su do stwarzania sytuacji trudno osigalnych w inny sposb.
Na przykad dostpne s w handlu programy do obciania serwerw
WWW symulujce wybran ilo jednoczesnych sesji i trafie. Specyfikacja
wymaga moe da, by serwer by w stanie obsuy 10000
jednoczesnych uytkownikw i 1 milion trafie dziennie bez widocznego
wzrostu czasu odpowiedzi. Majc do dyspozycji narzdzie do obciania,
wystarczy wstuka dany poziom obcienia, przeprowadzi testy i
skontrolowa wyniki.
Generatory zaburze i szumu
Strona 11 (34)
Kolejn klas narzdzi stanowi generatory zaburze i generatory szumu1.
Podobne s w dziaaniu do narzdzi obciajcych, ale funkcjonuj bardziej
losowo. Na przykad narzdzie przeciajce moe mie tryb dziaania
losowo zmieniajcy ilo dostpnych zasobw. Testowany program moe
dziaa dobrze zarwno wtedy, kiedy dostpne jest duo pamici jak i wtedy,
kiedy pamici jest mao, ale zawodzi, jeli ilo dostpnej pamici
nieustannie si zmienia. Ten rodzaj bdu mgby zosta odkryty przez
program przeciajcy dziaajcy w trybie losowym.
Podobnie, dokonawszy maej zmiany w ustawieniu analizatora z rysunku
14.1 tworzy si konfiguracj tak jak na rysunku 14.6. W tym ustawieniu
analizator zastpiony jest przez system (sprzt plus oprogramowanie) ktry
umoliwia nie tylko analiz danych przepywajcych czem, ale take ich
modyfikowanie. Takie ustawienie moe suyc do symulowania wszelkiego
rodzaju bdw w komunikacji polegajcych na gubieniu danych, szumie,
wadliwych poczeniach itp.
Komputer nr 1
Testowane oprogramowanie
Komputer nr 2
Testowane oprogramowanie
cze komunikacyjne
Rysunek 14.6 Generator zaburze podczepiony do cza komunikacyjnego

moe suy do testowania, jak oprogramowanie radzi sobie z bdami
wynikajcymi z szumu na czu.
Przy podejmowaniu decyzji jak mona zastosowa generatory zaburze i
szumu, bierze si pod uwag jakie zewntrzne warunki wpywaj na
testowane oprogramowanie, a nastpnie projektuje sposoby manipulacji
tymi wpywami tak, eby sprawdzi jak oprogramowanie sobie z nimi radzi.
Narzdzia analityczne
Klasyfikowanie narzdzi do testowania to zadanie, ktre - jak kad klasyfikacj - mona

przeprowadzi na wiele sposobw. W praktyce istnieje olbrzymia ilo rnych kombinacji funkcji
narzdzi. Wiele dostpnych na rynku narzdzi czy w sobie szereg zintegrowanych funkcji, a
producenci czsto lansuj specjalne nazwy dla tego typu agregatw. Dlatego dla uatwienia orientacji
najlepsze byoby klasyfikowanie funkcji narzdzi, nie za samych narzdzi. Autor niestety wybra
wariant przeciwny i w tym podrozdziale opisuje wrcz sposb zastosowania narzdzi jako osobny
"typ" narzdzia. Warto pamita, e na dobr spraw nie istnieje adna powszechnie przyjta
terminologia w tej dziedzinie (przyp. tumacza).
Strona 12 (34)
Do tej kategorii zaliczy si ca reszt narzdzi1. Wielu testerw uatwia
sobie prac stosujc powszechnie stosowane aplikacje. Nie zawsze s one
tak wymylne jak opisane dotd, ale dobrze su i oszczdzaj wiele pracy i
czasu.
12. Programy do przetwarzania tekstu
13. Arkusze kalkulacyjne
14. Bazy danych
15. Programy do porwnywania ze soba plikw
16. Programy do przechwytywania i porwnywania
zawartoci ekranu
17. Programy ledzce
18. Kalkulatory binarne i heksadecymalne
19. Stopery
20. Magnetowid i kamera wideo
Oczywicie, zoono i charakter istniejcych programw zmienia si
nieustannie. Kad sytuacj trzeba zanalizowa oddzielnie, aby mc wybra
pasujce do niej narzdzia i najlepszy sposb ich zastosowania.
Automatyzacja testu oprogramowania

Chocia narzdzia do automatyzacji testowania to po prostu jeszcze jedna
kategoria narzdzi do testowania, jednak zasuguj one na specjalne
potraktowanie. Narzdzia omwione dotd s bardzo skuteczne, ale nadal
wymagaj bezporedniej, rcznej obsugi i obserwowania wynikw. A gdyby
tak dao si te narzdzia poczy, uruchomi i posugiwa si nimi bez
koniecznoci ludzkiej interwencji? Mogyby wykonywa testy, szuka
bdw, analizowa i logowa wyniki. To jest wanie automatyzacja
testowania.
W kilku nastpnych czciach tego rozdziau opisane s rne rodzaje
automatyzacji, od najprostszej do najbardziej zoonej.
Nagrywanie i odtwarzanie
Rzeczywicie, autor wrzuci tutaj do jednego worka midzy innymi narzdzia uywane do
zarzdzania testami (bazy danych, arkusze kalkulacyjne), do porwnywania wynikw testw z
oczekiwanymi poprawnymi wynikami (komparatory) oraz rozmaite narzdzia do wyliczania
oczekiwanych poprawnych wynikw (tzw. wyrocznie, ang. oracle).
Strona 13 (34)
Njabrdziej podstawow form automatyzacji testowania jest nagrywanie
wszelkich czynnoci wykonywanych przy pomocy myszy i klawiatury w
czasie pierwszego, rcznego testowania, a nastpnie odtwarzanie tego
nagrania, kiedy potrzeba wykona te same testy ponownie. Jeii testowanye
oprogramowanie dziaa na systemie Windows lub na Micintoshu,
nagrywanie i odgrywanie bdzie bardzo proste. Na Macintoshu uywa si
QuicKeys; na Windows mona posuy si otwartym programem Macro
Magic1. Wiele tego typu narzdzi jest dostpnych, niektre typu shareware
(otwarte, darmowe).
Tego typu programy s rodzajem sterownikw2. Jak juz byo opisane,
sterowniki s to narzdzia stosowane do kontrolowania i kierowania
testowanym oprogramowaniem. To wanie robi program
nagrywajcy/odgrywajcy: nagrane dziaania s odgrywane, powtarzajc to,
co zostao wczeniej zrobione w celu przetestowania oprogramowania.
Rysunek 14.7 pokazuje ekran asystenta ustawie Macro3, porwadzcego
uytkownika krok po proku przez wszystkie czynnoci potrzebne do
skonfigurowania i nagrywania testowych sekwencji.
Rysunek 14.7 Aystent ustavie Macro umoliwia skonfigurowanie w jaki

sposb nagrane makro jest wywoywane i odtwarzane (ilustracja za zgod
Iolo Technologies, www.iolo.com).
Asystent ustawie Macro pozwala na ustawienie nastpujcych opcji:
Istniej dziesitki, jeli nie setki tego typu programw (zwanych narzdziami
nagrywania/odgrywania, ang. capture/playback albo capture/replay) - przyp. tumacza.
2
Mona t definicj przyj wobec zastosowania narzdzia w trakcie odtwarzania, natomiast w trakcie
nagrywania dziaaj raczej jak analizator czy program ledzcy z moliwoci nagrywania
zaobserwowanych zjawisk (przyp. tumacza).
3
Macro - to nazwa programu nagrywania/odtwarzania Microsoftu. Ta mylca nazwa bierze si std, e

nagranie zapisywane jest w postaci programu "makropolece", czyli po prostu programu w specjalnie
do takich zastosowa dopasowanym jzyku (przyp. tumacza).
Strona 14 (34)
21. Nazwa. Nadanie makroprogramowi nazwy
pozwala na jego pniejsz identyfikacj. Setki
makroprogramw mog by potrzebne nawet do
przetestowania maego programu.
22. Powtrzenia. Testowanie powtrzeniami jest
wietnym sposobem znajdowania bdw.
Mona ustawic ile razy makroprogram zostanie
wykonany.
23. Wyzwalacze. Mona ustawi, co spowoduje
wykonanie makroprogramu. Moe to by gorcy
klawisz (np. Ctrl+Shift+T), komenda (np.
wykonaj makro 1), kliknicie na skrt,
pojawienie si jakiego okna (np. zawsze gdy
wystartuje Kalkulator), albo jeli system przez
jaki czas nie zanotowa adnej aktywnoci
uytkownika.
24. Co ma by przechwytywane. Mona wybra,
czy przechwytywane (i nagruwane) ma by
tylko naciskanie klawiszy klawiatury, czy
rwnie czynnoci wykonywane mysz.
25. Szybko odtwarzania. Makroprogram moe
by odgrywany od 20% do 500% szybkoci
oryginalnego nagrania. Jest to istotne jeli
szybko dziaania testowanego programu jest
zmienna. Co si stanie, jeli program bdzie
wykonywany w zmienionych okolicznociach
nieco wolniej i przyciks, na ktry makroprogram
mia wanie klikn, jeszcze nie pojawi si na
ekranie?
26. Pozycja odtwarzania. Ta opcja okrela, czy
ruchy i kliknicia myszy maj by bezwzgldne
czy w stosunku do wybranego okna na ekranie.
Testujc aplikacj ktrej pooenie na ekranie
moe si zmieni, naley wybra opcj
aktywnoci myszy w sotsunku do okna tej
aplikacji, w przeciwnym razie odtwarzany
program moe klika w zupenie inne elementy
aplikacji (lub poza ni), ni w czasie
nagrywania.
Teraz warto powiczy torch nagrywanie i odtwarzanie makroprogramw.
Wystarczy w tym celu znale i zaadowa jaki program do
nagrywania/odtwarzania i wyprbowa go na prostej aplikacji, np. na
Kalkulatorze albo na Notatniku. wiczc, starajmy si myle jak testerzy!
Strona 15 (34)
Okae si, e chocia nagrane makroprogramy mog wykona za testera
pewne testy automatycznie, co uatwia i przypiesza testowanie, metoda nie
jest jednak doskonaa. Najwikszy problem to brak weryfikacji.
Makroprogramy nie potrafi skontrolowa, czy uzyskane wyniki s
poprawne1. Makroprogram potrafi wpisa do Kalkulatorz 100-99, ale nie
potrafi skontrolowa czy wynik jest 1 - nadal musi si to robi samemu. To
oczywicie kopot, ale wielu testerw ceni sobie nawet samo pozbycie si
uciliwego pisania i poruszania mysz. O wiele prociej jest tylko
obserwowa wykonywany makroprogram i sprawdza, czy wyniki s
zgodne z oczekiwanymi2.
Szybko odwarzania to kolejna trudno z zastosowaniem
makroprogramw. Nawet ustawiajc szykbo odtwarzania nie zawsze uda
si zachowa synchronizacj makroprogramu i testowanego programu. Na
przykad strona WWW moe raz zaadowa si w sekund, a innym razem
w 10 sekund. Mona spowolni makroprogramy dopasowujc je do
najgorszego wariantu, ale bd wtedy wykonywane powoli nawet jeli
oprogramowanie dziaa szybko. Jei ktrego dnia dana strona adowaaby
si wyjtkowo powoli - cae 15 sekund - wtedy makroprogram i tak by si
pogubi i klika niewaciwe elementy w nieodpowiednim czasie.
Trzeba zachowa ostronoc nagrywajc ruchy i klikanie mysz.
Programy nie zawsze pojawij si w tym samy miejscu na ekranie.
Ustawienie pozycji odtwarzania wzgldem okna programu zamiast caego
ekranu oe rozwiza t trudno, ale nawet wwczas niewielka chocby
ziana GUI moe uniewani cae wczeniejsze nagranie.
Mimo tych ogranicze, nagrywanie i odtwarzanie makroprogramw jest
popularn metoda automatyzacji prostszych zada testowych. Jest to
rwnie dobry sposb rozpoczcia nauki automatyzacji testowania.
Programowane makroprogramy
Programowanie to krok w gr w porwnaniu z prostymi nagrywanymi
makroprogramami. Programy testowe tworzy si nie nagywajc rczne
testowanie, lecz programujc. Prosty program mgby wyglda tak jak
przykad na listingu 14.1. Ten rodzaj programu mona - uywajc Asystenta
Macro - zbudowa wybierajc poszczeglne instrukcje z automatycznej listy
- nie trzeba nawet ich pisa samemu.
Listing 14.1 Prosty makroprogram do wykonywania testu na Kalkulatorze
Windows.
1: Test Kalkulatora nr 2
Natomiast doskonale potrafi to zrobi dostpne na rynku programy do nagrywania/odtwarzania.
Bardzo niebezpieczne rozwizanie - taka poowiczna automatyzacja moe upi czujno testerw i
spowodowa przepuszczenie wikszej iloci bdw ni przy testowaniu w caoci rcznym.
Strona 16 (34)
5: <<PROMPT:Wynik powoinien by 23>>
Linijka 1-a jest komentarzem. Linijka 2-a wywouje program calc.exe,

Kalkulator w Windows. Linijka 3-a czeka do 5 sekund na wystartowanie
kalkulatora. Progra zatrzymuje si dopki na ekranie nie pojawi si okno ze
sowem Kalkulator na swoim pasku tytuowym. Linijka 4-a wpisuje
123-100=. Linijka 5-a wywietla infomracj, e wynik ma by 23. Linijka 6a zamuka Kalkulator i zakacza test.
Zwrmy uwag jak przewag maj tego rodzaju programy nad
nagrywanyi. Nadal nie da si dokona weryfikacji poprawnoci wynikw,
mona jednak wprowadzi przerwy i kaza testerowi potwierdzi
poprawno (lub nie) wyniku (rysunek 14.8).
Rysunek 14.8 Proste programy testowe nie s w stanie zweryfikowa

wynikw testw, ale mog zada od testera potwierdzenia (rysunak za
zgod Iolo Technologies, www.iolo.com).
Moliwe jest rwnie - zamiast stosowania oglnego spowolnienia
odtwarzania - zastosowa synchronizacj polegajc na oczekiwaniu na
spenienie zdefiniowanego warunku przez dalszy wykonywaniem programu.
W podanym przykadzie z Kalkulatorem, program czeka na wystartowanie
Kalkulatora - o wiele bardziej niezawodna metoda.
Jak na razie wszystko jest dobrze, posunliy si krok do przodu w stron
automatyzacji testowania. Ma si do dyspozycji prosty jzyk
programowania zawierajcy gotowe akrokomendy do sterowania
testowanym programem i metod prostego dialogu z testerem. Dla wielu
zada jest to najzupeniej wystarczajce i niejedno mona w ten sposb
zautomatyzowa.
Strona 17 (34)
Brakuje jednak nadal dwch istotnych elementw, bez ktrych niemoliwe
jest wykonywanie bardziej skomplikowanych testw. Po pierwsze, takie
programy s wycznie sekwencyjne - nie da si zaprogramowa rozwidle
w przebiegu programu. Zmienne i instrukcje decyzyjne dostpne w
oglnych jzykach programowania nie s dostpne. I nadal nie ma si
monoci autoatycznego zweryfikowania wynikw. Aby te moliwoci
uzysk, trzeba sastosowa bardziej zaawansowane narzdzie do
automatycznego testowania.
W peni programowalne automatyczne narzdzia do testowania
Gdyby tak mie do dyspozycji peny jzyk programowania, poazony z
makrokomendami uatwiajcymi sterowanie testowanym oprogramowaniem
i z moliwocia dokonywania weryfikacji wynikw? Miaoby si wtedy
najdoskonalsze narzdzie do znajdowania bdw! Rysunek 14.9 pokazuje
przykad takiego narzdzia.
Rysunek 14.9 Visual Test zosta skonstruowany przez Microsoft, obecnie za

sprzedawany jest przez Rational Software, jest przykadem narzdzia ktre
zawiera rodowisko do programowania, makrokomendy i moliwoci
weryfikowania wynikw zoone w jednen zintegrowany pakiet.
Automatyczne narzdzia do testowania, takie jak Visual Test, daj
moliwoc tworzenia bardzo skutecznych testw. Wiele z nich ma jzyk
programowania oparty na jzyku BASIC, dziki czemu nawet nieprogramici mog pisa kod do testowania.
Gdyby chcie wyprbowa pisanie cigu znakw Hello World! 10000 razy,
trzeba by napisa nastpujce linie kodu:
FOR i=1 TO 10000
PLAY Hello World!
NEXT I
Chcc za spowodowa przesunicie kursora yszy z grnego lewego rogu
ekranu 640x480 i wykona podwjne kliknicie, monaby to zrobi tak:
Strona 18 (34)
PLAY {MOVETO 0,0}
PLAY {OVETO 640, 480}
play {DBLCLICK}
Ten jzyk daje telepsze mozliwoci ni klikanie w okrelony punkt ekranu
albo wysyanie pojedynczych nacini klawisza. Na przykad, aby kl;ikn
na przycisk OK, ona posuy si komned
wButtonClick (OK)
Nie trzeba wiedzie gdzie na ekranie znajduje si przycisk OK. Program
testujcy poszukaby go, znalaz i klikn - tak samo jak uytkownik. Istniej
komendy tego saego rodzaju do obsugi menu, pl wyboru i tak dalej. Takie
komendy zapewniaja wielk elastyczno w pisaniu programw testowych i
zarazem czyni je atwiejszyimi do zrozumienia i bardziej niezawodnymi.
Najwaniejsza cecha takich automatycznych narzdzi to moliwo
dokonywania weryfikacji, sprawdzania czy testowany program poda
prawidowy wynik lub wykona prawidow czynno. Mona to robic na
kilka sposobw:
27. Przechwycenie treci ekranu. Wykonujc testy
po raz pierwszy, mona przechwyci i zapisa
poprawne fragenty ekranu. W czasie
odtwarzania testw, automatyczny program
porwnywaby zapisane fragmenty z aktualnym
fragmentem ekranu. Znajdujc rnic,
automatyczny program mgby zasygnalizowa
prawdopodobny bd.
28. Wartoci kontrolne. Zamiast przechwytywa
fragmenty ekranu, mona sprawdza warto
poszczeglnych kontrolek w oknie testowanego
oprogramowania. Testujc Kalkulator, program
mgny odczyta warto w polu
wywietlajcym wynik i porwna j z
wartocia oczekiwan. Daje si te
skontrolowa, czy przycisk by przycinity, a
pole wyboru - wybrane. Autoatyczne narzdzie
pozwala dokona tego przy pomocy programu.
29. Pliki i inne dane na wyjciu. Podobnie, jeli
testowany program zapisuje dane na pliku - na
przykad program do przetwarzania tekstu program testowy mgby otowrzyc ten plik i
porna ze znanym o poprawnej zawartoi. T
sam technik monaby zastosowa wobec
danych przesyanych przez modem albo przez
sie. Program testowy mgby odczytac te dane
i porwna z oczekiwanyi.
Strona 19 (34)
Weryfikacja bya ostatni powan przeszkod na drodze to automatycznego
testowania oprogramowania. Pokonawszy j, mona skonstruowa program
wykonujcy niemal kade zadanie testowe1 - cakiem albo przynajmniej
czciowo automatycznie.
Wicej danych a temat znanych programw do automatyzacji testowania
mona midzy innymi znale na:
30. Mercury Interactive, www.merc-int.com
31. Rational Software Corporation,
www.rational.com
32. Segue Software, www.segue.com
Takie oprogramowanie jest przeznaczone gwnie dla zespow
programistw w przedsibirstwach i dla osoby prywatnej jest raczej
kosztowne. Mona jednak sprbowa dosta licencj - ograniczon w czasie
- dla wyprbowania, albo - bdc studente - znik studenck. Wiele firm
odnosi si do takich propozycji yczliwie w nadziei, e to dobry sposb
reklamy.
Testowanie na chybi-trafi: mapy i goryle

Poznane przez nas dotd narzdzia i techniki miay na celu uatwi prac
testerw i uczyni j efektywniejsz. Miay uawtwi wykonywanie zada
testowych, a w najlepjej zautomatyzowa je zupenie.
Ten sposb uycia automatycznych narzdzi przyczynia si do znajdowania
bdw. Narzdzia pracowicie wykonuj testowanie regresyjne, a testerzy
maj wicej czasu na planowanie pracy i na projektowanie nowych zada
testowych. Istnieje te inny rodzaj autoatycznego testowania, ktrego celem
jest symulowanie tego, co z programem mog zrobi uytkownicy. Ten
rodzaj tesowania nazywany jest niekiedy testujc map.
Okrelenie testujca mapa bierze si ze starego pomysu, e jeli posadzi
milion map piszcych na milionie maszyn do pisania przez milion lat, to
statystycznie jest prawdopodobne, e napisane zostanie przez nie jakie
wielkie dzieo literackie. Walc w klawiatur na chybi-trafi, mona
przypadkowo trafi na waciw kombinacj liter i mapa przez chwil
mogaby robic wraenie niezwykle zdolnej - tak jak ta na rysunku 14.10.
cilej, kade zadanie testowe wykonywane za porednictwem GUI (przyp. tumacza).
Strona 20 (34)
Rysunek 14.10 Mapy testujce bd testowa tak dugo, jak dugo maj
prod i od czasu do czasu - banana.
Kiedy oprogramowanie zostanie rozpowszechnione, bdzie miao tysice, a
moe nawet miliony uytkownikw walcych w nie - czasem bez adu i
skadu. Mimo najlepszych stara przy konstruowaniu i wyborze zada
testowych, niektre bdy przelizgn si przez sie zastawion przez
testrw i zostan znalezione przez uytkownikw. A gdyby tak uzupeni
zadania testowe przy pomocy symulacji tego, co mog zrobi uytkownicy?
Mona by w ten sposb znale niekiedy bdy, ktre w przeciwnym razie
by si nam wymkny. Do tego wanie suy mapa testujca.
Uycie testujcej mapy do symulowania tego, co uytkownicy by moe
bd robi z programem nie jest insynuoacj, e uytkownicy
komputerw s mapami.
Gupie mapy
Najprostszym rodzajem mapy testujcej jest gupia mapa. Gupia mapa
niczego nie wie o testowanym przez siebie programie; po prostu losowo
wybiera klawisze i kliknicia mysz. Listing 14.2 pokazuje przykad kodu w
VisualTest ktry losowo klika i pisze tekst 10000 razy.
Listing 14-2 Kilka linijek kodu wystarcza, aby stworzy gupi map.
1: RANDOMIZE TIER
2: FOR i=1 TO 10000
3: PLAY {CLICK +STR$(INT(RND*640)) +, +STR$(INT(RND*480)) +}
4: PLAY CHR$(RND*256)
5: NEXT i
Linijka 1-a inicjalizuje liczby losowe. Linijka 2-a otwiera ptl od 1 do

10000 razy. Linijka 3-a wybiera losowo punkt na ekranie midzy 0,0 a
640,480 (rozdzielczo VGA) i klika w niego. Linjka 4-a wybiera losowo
znak midzy 0 a 255 i pisze go.
Strona 21 (34)
Testowany program nie odrnia skutkw dziaania takiego programu od
pracy prawdziwego uytkownika - prcz tego e wykonanie jest o wiele
szybsze. Na do szybkim PC wykonanie caego programu zajmie ledwo
kilka sekund. atwo sobie wyobrazi, ile losowych czynnoci daoby si
uzyska, gdyby taki program pracowa przez ca noc!
Zwrmy uwag, e ta mapa nie dokonuje adnej weryfikacji. Ona tylko
klika i wpisuje znaki a do momentu, kiedy albo ptla si skoczy, albo
program czy system operacyjny ulegnie awarii.
Kto nie wierzy, e gupia mapa moe znale powany bd, niech
zastosuje taki program na swojej ulubionej grze komputerowej.
Najprawdopodobniej najpniej po paru godzinach nastpi awaria.
Moe wydawa si dziwne, e proste losowe klikanie i pisanie jest w stanie
znale bdy. Jednak tak jest - z nastpujcych powodw:
33. Majc do czasu i wykonujc dostatecznie
wielk ilo prb, losowe wprowadzanie danych
w kocu trafi na ten cig czynnoi, o ktym nie
nio si ani programistom, ani testerom. Moe
mapa wprowadzi jakie dane a nastpnie
natychiast je usunie, albo wpisze olbrzymi cig
znakw tam, gdzie program oczekuje krtkeigo.
Kto wie? Co si na pewno znajdzie.
34. Gupia mapa przez samo nieustanne
powtarzanie wprowadzania danych moe
ujawni bdy - takie jak np. przecieki pamici ktre wychodz na jaw dopiero po wielu
godzinach czy nawet dniach uytkowania. Kto
posugoiwa si programem, ktry stawa si
coraz mniej stabilny im duej si go uywao,
spotka si z problemem, ktry daoby si
odkry stosujc gupi map.
Pgupie maby
Gupie mapy mg by bardzo skuteczne. atwo je zaprogramowa i
mog znajdowa powane bdy powodujce zupen awari programu.
Jednak kilka dodatkowych funkcji mogoby uczyni je jeszcze
skuteczniejszymi. Dodanie tych funkcji podniesie odrobin poziom
inteligencji naszej mapy, czynic j pgupi.
Strona 22 (34)
Powiedzmy e mapa pracowaa przez kilka godzin, aplikujc tysice
losowych danych wejciowych, zanim program uleg awarii. Wiadmomo, e
znalazo si jaki problem, ale nie da si pokaza programicie, jak mona
ten problem odtworzy. Mona by powtrzy odkadnie t sam prac
mapy (z tymi samymi danymi losowymi, jeli to moliwe), ale oznaczaoby
to ponowne zmarnowanie kilku godzin. Rozwizaniem jest dodanie do
mapy logowania, tak e wszelkie wykonane czynnoci zostayby zapisane
na pliku. Kiedy mapa znajduje bd, wystarczy zajrze do pliku logowego
eby zobaczy, co poprzedzio awari.
Warto te zaprogramowa map tak, eby dziaaa tylko na testowanym
oporogramowaniu. Jeli mapa losowo klika po caym ekranie, w kocu trafi
na komend zakaczajc program. Poniewa mapa nie wie, czy program
dziaa, bdzie pracowaa dalej. Wyobramy sobie, co moe si sta, jeli
mapa bdzie klikaa i pisaa po caym ekranie komputera - oj! Na szczcie
wikszo dajcych si zaprogramowa narzdzi do automatycznego
testowania pozwala ustawi testy na wybran aplikacj i przerwa prac,
kiedy aplikacja przestaa dziaa.
Kolejn funkcj, ktra podniesie inteligencj mapy, jest rozpoznawanie
awarii programu. Uruchomiwszy map na ca noc straci si wiele cennych
godzin, jeli program ulegnie awarii, ledwo si zamknie za sob drzwi. Jeli
doda do mapy moliwo rozpoznawania awarii i ponowngo uruchomienia
programu w tej sytuacji, zwikszy si znacznie skuteczno jej dziaania.
Bystre mapy
Kolejnym krokiem na drabinie ewolucyjnej jest bystra mapa. Taka mapa
dziedziczy po swoich mniej inteligentnych braciach korzyci testowania
losowego, ale wspomaga je zrozumieniem trybu dziaania testowanej
aplikacji. Bystra mapa nie wali ju cakiem losowo w kalwiatur - ona
wali w ni celowo.
Naprawd bystra mapa wie:
35. gdzie jest
36. co tam mona zrobi
37. dokd mona stamtd pj
38. gdzie bya wczeniej
39. czy to co wida jest poprawne.
Brzmi to znajomo? Powinno. Bystra mapa zna map stanw programu tak map jak opisana w rozdziale 5-ym Testowanie oprogramowania z
klapkami na oczach. Jeli caa informacja na temat stanw testowanego
oprogramowania znana jest mapie, moe ona posugiwa si programem
podobnie jak uytkownik, tylko o wiele szybciej, po drodze weryfikujc
poprawno dziaa programu.
Strona 23 (34)
Bystra mapa testujca Kalkulator Windows (zob. rysunek 14.11) bdzie
wiedzie, jakie przyciski mona nacisn, jakie s dostpne wybory menu,
gdzie mona wpisywa liczby. Kliknwszy opcj O Kalkulatorze z menu
Pomoc, bdzie wiedzie, e jedynym sposobem wyjcia stamtd jest
kliknicie przycisku OK albo Zamknij. Nie bdzie wic losowo klika po
caym ekranie.
Rysunek 14.11 Bystra mapa wie, jak zamkn okno dialogowe O

Kalkulatorze.
Bystra mapa nie musi szuka tylko bdw powodujcych zupen awari
programu. Moe rwnie po drodze weryfikowa dane, kontrolowa wyniki
i szuka rnic midzy wynikami rzeczywistymi a oczekiwanymi. Majc
zaprogramowane zadania testowe, mona poleci mapie ich losowe
wykonywanie, szukanie bdw i logowanie wynikw. Odlotowo!
Rysunek 14.12 pokazuje bystr map imieniem Koko, ochrzczon tak na
pamitk goryla, ktrego nauczono posugiwania si jzykiem znakw. Aby
zaprogramowa Koko, wprowadza si w ni tablic stanw programu,
czynnoci dajce si wykona w kadym ze stanw oraz sposoby
odrniania poprawnych od niepoprawnych wynikw dziaania programu.
Rysunek 14.12 Bystra mapa Koko daje si zaprogramowa tak, e wie

gdzie jest i co moe zrobi.
Strona 24 (34)
Kiedy Koko dziaa, doprowadza testowany program do znanego stanu, a
nastpnie wybiera losowo kolejn czynno na podstawie rozkadu
prawdopodobiestwa rzeczywistego uycia1, wykonuje t czynno i
kontroluje jej wynik. Jeli czynno powoduje zmian stanu programu,
Koko wie o tym i posuguje si nowym zestawem moliwych wyborw
czynnoci, odpowiednim dla tego nowego stanu.
W taki sposb daje si symulowa rzeczywisty sposb uytkowania
testowanego oprogramowania, symulujc tysice godzin jego dziaania w
cigu kilku godzin. Bystre mapy to naprawd maszyny do znajdowania
bdw!
Uycie narzdzi i automatyzacja testowania w

rzeczywistoci
Zanim jednak, zafascynowani nowymi moliwociami, rzucimy si, eby
zacz stosowa automatyzacj w naszych testach, naley przeczyta ten
podrozdzia i wzi sobie jego tre do serca. Automatyzacja testowania nie
jest uniwersalnym lekiem na wszystko. Nastpujce trudnoci z
automatyzacj testowania trzeba wzi pod uwag:
40. Oprogramowanie zmienia si. Specyfikacje nie
s zamknite. Nowe funkcje dodaje si pod
koniec projektu. Nazwa produktu zmienia si w
ostatniej chwili. Co bdzie, jeli zaprogramuje
si tysice makroprogramw aby mc wykona
wszystkie testy na tydzie przed wypuszczenie
produktu i wtedy okae si, e oprogramowanie
zostao w ostatniej chwili zmodyfikowane tak,
e wywietla zaraz po starcie zupenie nowy
ekran? Wszystkie nagrane programy zawiod,
bo nie bd wiedzie nic o istnienieu tego
nowego ekranu. Dlatego automatyzacj naley
zaprojektowa tak, aby bya elastyczna i dawaa
si atwo i szybko dostosowa do takich zmian
w oprogramowaniu.
41. Nic nie jest w stanie w peni zastpi ludzkiego
oka i ludzkiej intuicji. Bystre mapy mona
uczyni bystrymi tylko do pewnej granicy.
Mog testowa tylko to, do czego zostay
zaprogramowane. Nigdy nie bd mogy
powiedzie Oj, to dziwne. Musze sprawdzi to
dokadniej. Przynajmniej jeszcze nie dzi.
Koko realizuje w ten sposb strategi zwan Statystcznym testowaniem (Statistical Usage-Based
Testing), ktra w tej ksice nie jest szczegowo opisana (przyp. tumacza).
Strona 25 (34)
42. Weryfikacja jest trudna. Testujc interfejs
uytkownika, najprostszym sposobem
weryfikacji wynikw jest przechytywanie, a
nastpnie porwnywanie caych ekranw. Ale
przechwycone ekrany s olbrzymimi plikami, a
poza tym wygld i ukad ekranw zwykle
nieustannie si zmienia w trakcie projektu.
Dlatego trzeba zaprogramowa narzdzia tak, by
weryfikoway tyko to co najwaniejsze i eby
zmiany interfejsu dao si atwo uwzgldnia.
43. Nie naley zda si wycznie na autoatyzacj.
Nigdy nie mona zakada, e poniewa
automatyczny program nie znajduje adnych
bdw, to nie a ju adnych bdw. One tam
na pewno s - to opisany wczeniej paradoks
pestycydw.
44. Powicajc zbyt wiele czasu automatyzacji,
mona nie mie ju czasu na samo testowanie.
Pisanie makroprogramw i programowanie
bystrej mapy to wietna zabawa, ale to nie
jest testowanie. Te narzdzia pomog w pracy,
ale trzeba zdy zastosowa je na
oprogramowaniu i wykona rzeczywiste
testowanie by mc znale bdy.
45. Piszc makroprogramy, budujc narzdzia albo
programujc map, wykonuje si prac
bdc wytwarzaniem oprogramowania. Naley
przy tym przestrzega tych samych zasad i
stosowa te same metody co we waciwym
projekcie. To, e si jest testerem, nie upowania
do lekcewaenia zasad metodyki.
46. Niektre narzdzia s intruzyjne i mog
spowodowa awari testowanego
oprogramowania. Kiedy znalazo si bd w
trakcie testw automatycznych, warto
sprbowa ponownie wywoa ten bd - tym
razem rcznie. Moe si czasem okaza, e bd
spowodowany by dziaaniem narzdzia do
testowania.
Podsumowanie
Narzdzia do testowania i automatyzacja testowania daja si zastosowa do
kadego typu oprograowania. Wikszo przykadw w tym rozdziale
dotyczya testw interfejsu uytkownika, ale te same sposoby mona
zastosowa do testowania kompilatorw albo serwerw WWW. Trzeba
przypatrzy si swoim testom pod ktem tego, jak uycie innych programw
moe je uatwi.
Strona 26 (34)
Czasem uywa si doni, czasem packi na muchy, a czasem (moe
niesusznie) - motka. Tester powinien wiedzie, kiedy i jakie narzdzia
warto zastosowa. Lonstruowanie i uywanie narzdzi i automatyzacja
testowania moe by swietn zabaw. Wglda bojowo, kiedy komputer
dzaiaa sam, kursor lata po caym ekranie, a znaki wprowadzane s do
testowanej aplikacji automatycznie. Jest wielk frajd lee w domu w oku
albo popijaja kaw wiedzc, e automatyczny program pracuje w ty czasie
za nas, znajdujc bdy.
Pytania
1. Wymie kilka korzyci stosowania narzdzi do
testowania i automatyzacji testowania.
2. Jakie s moliwe wady automatyzacji i jakie
moliwe trudnoci trzeba wzi pod uwag przy
podejmowaniu decyzji o zastosowaniu narzdzi
i o automatyzacji?
3. Jaka jest rnica midzy narzdziem a
automatyzacj?
4. Jakie s podobiestwa i rnice midzy
analizatorem a generatorem zaburze?
5. Prawda czy fasz: narzdzie intruzyjne jest
najlepsze, poniewa dziaa najbliej
testowanego oprogramowania.
6. Jaki jest jeden z najprostszych, ale skutecznych,
sposobw automatyzacji testowania?
7. Wymie kilka funcji, ktre warto doda do
rozwizania opisanego jako odpowied na
porzednie pytanie, aby uczyni automatyczne
testy jeszcze skuteczniejszymi.
8. Na czym polega wyszo bystrych map nad
gupimi mapami i nad nagranymi
automatycznie makroprogramami?
Strona 27 (34)
Rozdzia 15 Polowanie na bdy i testowanie beta

W TYM ROZDZIALE
Nie wszystko da si zauway
Jak podzieli si testowaniem
Testowanie beta
Jak zleci testowanie innej firmie
W rozdziale 14-ym Automatyzacja i narzdzia do testowania
dowiedzieliy si, jak technologia w postaci narzdzi pozwala uczyni
testowanie skuteczniejszym. Zastosowanie programw do testowania
programw jest wietn metod przypieszenia pracy i sposbem na
znajdowanie bdw, ktre trudno byoby znale inaczej.
Innym sposobem uczynienia pracy testera skuteczniejesz jest
wykorzystanie innych ludzi. Gdyby udao si znale wicej osb niekoniecznie zawodowych testerw - do testowania, mona by znajdowa
bdy przeoczone przez testerw w projekcie.
47. Czemu wane jest wykorzystanie wielu osb do
testowania
48. Jak znale ludzi
49. Co to jest testowanie beta i jak rol maj w nim
testerzy
50. Jak skutecznie zleci testowanie innej firmie
Nie wszystko da si zauway

Na rysunku 15.1 znajduj si dwa niemal identyczne obrazki,
przedstawiajce t sam scen. Teraz wyjmujemy timer do jajek,
nastawiamy go na minut i szukamy rnic midzy obrazkami. Zapisujemy
znalezione rnice i kolejno, w jakiej je znajdowalimy.
Strona 28 (34)
Rysunek 15.1 Ile rnic midzy obrazkami zdy si znale w cigu minuty.
Ilustracja za zgod www.cartoonworks.com.
Teraz dajmy to samo zadanie kilku kolegom i porwnajmy uzyskane listy.
Okazuje si, e kady ma troch inne wyniki. Ile rnic si znalazo, ktre i
w jakiej kolejnoci - bdzie rne dla rnych osb. Jeli teraz poczy te
listy i odrzuci duplikaty, otrzyma si peniejsz list rnic - ale nawet
wtedy nie ma pewnoci, czy znalezione zostay wszystkie.
Tak samo rzecz si ma z testowaniem oprogramowania. Pracuje si pod
presj harmonogramu, znajduje bdy w dostpnym nam czasie, ale jeli
pozwoli poszuka te komu innemu, znajdzie on przypuszczalnie jeszcze
inne bdy. Moe to zniechca. Mona sobie pomyle: jak mona byo mimo caej cikiej pracy - przeoczy taki oczywisty bd? Jest to jednak
cakiem normalne i jest na to kilka sposobw.
51. Wykorzystanie drugiej pary oczu zapobiega
paradoksowi pestycydw. Jak wida na
przykadzie eksperymentu z rysunkiem 15.1,
ludzie zauwaaj rne rzeczy. Bdy ktre z
jakiego powodu przeoczy jedna osoba, z
atwocia moe zuway kto inny.
52. Tak samo jak rni ludzie zauwaaj rne
rzeczy, rozmaicie te zabieraj si za wykonanie
tej samej pracy. Tester dokona starannej analizy
specyfikacji i wybra zadania testowe, ale
zawsze kto inny moe wzi pod uwag co, co
mu nie przyszo do gowy - nacisn inny
klawisz, kliknc mysz szybciej, uruchomi
funkcj w inny sposb. Mamy tu ponownie do
czynienia z paradoksem pestycydw.
53. Majc kogo do pomocy, atwiej upora si z
nud. Testowanie tego saego raz po razie,
uywanie cigle tych samych funkcji programu
szybko staje si monotonne. Nuda powoduje
rozproszenie uwagi i mona wtedy przeoczy
najbardziej oczywiste bdy.
54. Patrze jak kto inny zabiera si za rozwizanie
zadania jest wietnym sposobem nauczenia si
nowych technik testowania, ktre potem mona
doda do swego repertuaru sposobw.
atwo ulec pokusie i chcie zachowa wyczno oraz ca
odpowiedzialno za swj kawaek testowanego oprograowania, ale lepiej
tego unika. Pozwalajc innym sobie pomc, mna wiele zyska.
Jak podzieli si testowaniem
Strona 29 (34)
O ile nie pracuje si w bardzo maym projekcie, zapewne kilka osb bdzie
zajmowa si testowaniem. Jest wiele sposobw na to, by wicej ni jedna
osoba szukaa bdw w tej samej czci programu.
Testerzy mog - na kilka godzin albo na kilka dni - zaieni si swoimi
zadaniami. Ja wykonam twoje testy, a ty wykonaj moje. Obie strony
zyskaj dziki temu dodatkowe, niezalene spojrzenie na testowany produkt
lub jego cz. Kady moe si te nauczy nowych sposobw - i dzieki
temu wymyslic pniej nowe zadania testowe. Warto przynajniej znale
kogo, eby przyjrza si wybranym przez siebie klasom rwnowanoci i
zadaniom testowym. Na podstawie swego dowiadczenia kto inny moe
zaproponowa dodatkowe obszary do przetestowania.
Zabawnym sposobem podzielenia si prac przy testowaniu jest tuczenie
bdw. Polega to na tym, e na jaki czas - zwykle na kilka godzin zawiesza si zwyke zadania i wszyscy razem bior udzia w tuczeniu
bdw. Wybiera si jeden fragment czy aspekt oprogramowania i wszyscy
koncentruj si na nim. Wybra mona na przykad obszar, gdzie byo
szczeglnie wiele bdw, eby sprawdzi czy nic tam wicej si ju nie
kryje. Albo mona wybra fragment podejrzanie bezbdny - taki
zmasowany atak pozwoli ustali, czy bdy ukryy si przed zwykymi
testami, czy te ma si do czynienia z rzeczywicie dobrze napisanym
fragmentem kodu. Objekt tuczenia bdw mona wybiera na podstawie
rozmaitych kryteriw, ale wsplnym celem jest zawsze to, by wiele rnych
osb jednoczenie szukao bdw w na ty samym terenie.
Sprzyierzecem w polowaniu na bdy jest dzia wsparcia klientw - ludzie,
ktrzy maj kontakt z klientami potrzebujcyi pomocy albo instrukcji. Ci
ludzie s bardzo czuli na punkcie bdw i moga naprawd wiele pomc
przy testowaniu. Warto dowiedzie si, kto bdzie odpowiada za pomoc
klientom i poprosi te osoby o wzicie udziau w testowaniu. Bd potrafili
znale zdumiewajce bdy.
Bodaj najczciej dzia obsugi klienta spotyka si z problemami z zakresu
uytecznoci. Wiele pyta przychodzi od osb, ktre po prostu usiuj
zrozumie, jak posuy si oprogramowanie. Dlatego warto sprbowa
wczy osoby z dziau obsugi w testowanie jak najwczeniej, eby
wczenie mogli pomc znale i naprawi wanie bdy uytecznoci.
Testowanie beta
Opisane dotd metody podzielenia si testowaniem maj charakter
wewntrzny - to znaczy osoby, ktre nam pomagaj, nale do tego samego
zespou testujcego albo do tego samego projektu. Inn powszechnie
stosowan metod walidacji i weryfikacji oprogramowania przy pomocy
innych osb jest tak zwane testowanie beta.
Strona 30 (34)
Testowanie beta polega na tym, e oprogramowanie jest testowane przez
wybranych klientw (lub potencjalnych klientw) w rzeczywistym,
operacyjnym rodowisku. Testowanie beta zwykle stosuje si pod koniec
projektu i waciwie powinno by wycznie walidacj tego, e
oprogramowanie jest ju zupenie gotowe do dostarczenia klientom.
Cele testowania beta mog by rozmaite: poczwszy od tego, eby
spowodowa pojawienie si w fachowej prasie wczesnych artykuw na
temat tego oprogramowania, poprzez walidacj interfejsu uytkownika, a
po ostatni atak w poszukiwaniu bdw. Tester powinien umie
zakomunikowa osobom kierujcym testami beta, jaki jest - z jego punktu
widzenia - ich cel.
Nastpujce rzeczy warto wzi pod uwag planujc testowanie beta:
55. Kim s osoby wykonujce testowanie beta? Jest
to wane w kontekcie przyjtego celu
testowania. Na przykad producent moe by
zainteresowany znalezieniem pozostaych
jeszcze problemw z uytecznoci, ale
testerami beta okazuj si by dowiadczeni
programici, bardziej zainteresowani dziaaniem
na niskim poziomie, nie za uytecznoci. Jeli
tesowanie beta ma przynie spodziewane
korzyci, trzeba z gry okreli, kto powinien je
wykonywa.
56. Skd bdzie wiadomo, czy wykonawcy testw
beta rzeczywicie uywali rorgramu? Jeli 1000
osb miao program do dyspozycji przez
miesic i nie raportowao adnych problemw,
czy to znaczy e nie byo adnych bdw, czy
te e bdy znajdowano ale nikt nie potrudzi
si napisaniem raportu, czy te e raporty
zostay zagubione na poczcie? Czsto si zdarza,
e osoby majce wykona testowaniue beta
przystpuj do tego dopiero po pewnym czasie,
a ponadto wykonuj je tylko w ograniczonym
zakresie. Trzeba dopatrze, by mie nad ty
wszystkim kontrol.
57. Testowanie beta czsto jest dobrym sposobem
znajdowania bdw konfiguracji i
kompatybilnoci. Jak dowiedzieliy si w
rozdziaach 8-ym Testowanie konfiguracji i w
9-ym Testowanie kompatybilnoci, trudno jest
zidentyfikowa i przetestowa reprezentatywn
prb moliwych ukadw sprztu i programw.
Jeli uczestnicy testw beta zostali trafnie
wybrani z grupy potencjalnych klientw,
powinni znale wiele problemw dotyczcych
wanie konfiguracji i kompatybilnoci.
Strona 31 (34)
58. Testowanie beta moe te da interesujce
wyniki w zakresie testowania uytecznoci, jeli
waciwie wybrao si jego uczestnikw odpowiedni mieszanke osb o rnym
poziomie dowiadczenia. Widzc
oprogramowanie po raz pierwszy, bd mogli
bez trudu zauway wszelkie mylce czy trudne
do zastosowania funkcje.
59. Oprcz konfiguracji, kompatybilnoci i
uytecznoci, testowanie beta jest zdumiewajco
nieefektywne w znajdowaniu bdw.
Uczestnicy czsto nie maj do czasu na
uywanie programu, tak e znajduj tylko
najbardziej oczywiste, powierzchowne problemy
- przypuszczalnie i tak s ju one znane
wytwrcy. Poza tym, poniewa testowanie beta
zwykle odbywa si pod koniec cyklu
wytwarzania, nie ma zbyt wiele czasu na
naprawianie znajdowanych bdw.
Jednym z najwikszych zagroe w projekcie wytwarzania
oprogramowania jest prba potraktowania testowania beta jako namiastki
prawdziwcyh testw. Nie wolno tego robi! Jeli to miaoby zadziaa,
czemu nie zrobi tego samego rwnie z projektowaniem i implementacj
oprogramowania?
60. Program testowania beta zajmuje duo czasu.
Czsto pocztkujcy testerzy otrzymuj wanie
za zadanie pomaganie klintom w ich
problemach, odpowiadanie na ich pytania i
potwierdzanie znalezionych przez nich bdw.
Wykonujc takie zadanie, trzeba te
wsppracowa z reszt zespou testujcego, aby
zrozumie, dlaczego bdy nie zostay
znalezione wczesniej i zaplanowa poprawienie
zada testowych tak, eby ich nie mc ponownie
przeoczy w przyszoci. To wszystko atwo
wypenia cay czas pracy, tak e nie zostaje go
ju na testowanie samemu.
Planujc program testowania beta, naley zaplanowa go zawczasu,
najlepiej jeszcze w czasie ustalania harmonogramu projektu. Trzeba zadba
o to, by cele testowania beta pokryway si z potrzebami zespou testujcego
i wsppracowa cisle z kierownikiem tego programu tak, by gos testerw
by brany pod uwag.
Testowanie beta moe by dobry sposobem uzyskania niezalenych
wynikw testw, ale aby mg on by skuteczny, trzeba nim opowiednio
pokierowa - mona niemal powiedzie, e trzeba go odpowiednio
przetestowa.
Strona 32 (34)
Jak zleci testowanie innej firmie

Czsto spotykan praktyk w wielu firmach jest zlecenie wykonania czci
testowania przedsibiorstwom specjalizujcym si w rnych aspektach
testowania. Chocia moe to si wydawa bardziej skoplikowane i
niewygodne ni zlecenie wykonania tej samej pracy testerom we wasnym
zespole projektowym, jest to zwykle skuteczny sposb podzielenia si
odpowiedzialnoci za testowanie - jeli zrobi to z gow.
Zwykle dobrze jest zleci innnej firmie test konfiguracji i kompatybilnoci.
Ten rodzaj testw wymaga duego laboratorium z wieloma rozmaitymi
platformami sprztowymi i z rnymi rodzajami oprogramowania, wraz z
kilkuosobowym personelem zarzdzajcym tym wszystkim. Wikszo
maych firm nie moe sobie pozwoli na koszty utrzymania takich
laboratoriw. Jest sensownym wariantem przekaza takie zadanie firmom
specjalizujcym si w tego typu testowaniu.
Testowanie ulokalnienia te dobrze nadaje si, by zleci jego wykonanie
komu innemu. O ile zesp testerw nie jest naprawd wielki, trudno
oczekiwa by mie do dyspozycji pracownikw znajcych wszelkie jzyki,
w ktrych program ma dziaa. Moe si opaca mie w zespole kilku
testerw znajcych obce jzyki, aby zidentyfikowa podstawowe problemy,
ale najpewniej lepiej jest powierzy cao testw przedsibiorstwu
majcemu odpowiednie kompetencje. Takie firmy dysponuj zwykle
psrsonelem zarwno znajcym jzyki, jak i znajcym si na testowaniu.
Pocztkujcy tester zapewne nie bdzie musia podejmowa decyzji w
sprawie tego, jakie rodzaje testw mona powierzy innej firmie, ale moe
musie wsppracowa z tak firm, jeli testuje ona oprogramowanie, za
ktre jest si odpowiedzialnym. Wwczas powodzenie lub niepowodzenie
pracy firmy wykonujcej testy moe zalee od wsppracy z tym wanie
testerem. Oto lista spraw, ktre trzeba uwzgldni, aby wsppraca
przebiagaa jak najlepiej:
61. Jakie dokadnie zadania zostay powierzone tej
firmie? Kto je definiuje? Kto je weryfikuje i
zatwierdza?
62. Jaki jest harmonogram ich pracy? Kto go ustala?
Jakie bd skutki ewentualnych opnie?
63. Jakie dostawy ma otrzymywa firma
wykonujca testy? Przykady to specyfikacja,
kolejne dostawy nowych wersji i zadania
testowe.
64. Jakie maj by dostawy z firmy testujcej do
producenta oprogramowania? Co najmniej musi
to by lista znalezionych bdw.
Strona 33 (34)
65. Jakie bd sposoby porozumiewania si z firm?
Telefon, poczta komputerowa, Internet, wsplna
baza danych, codzienna wizyta? Osoby
wyznaczone jako odpowiedzialne za wspprac
i kontakt z obu stron.
66. Skd bdzie wiadomo czy testujca firma
wywizuje si ze swoich zobowiza? Skd
firma ma wiedzie czy spenia oczekiwania
zleceniodawcy?
To wszystko nie jest wprawdzie cis matematyk, ale czsto te banalne
sprawy s zapomniane w popiechu, aby jak najszybncie przekaza
testowanie wybranej firmie. Postawa, aby jak najszybciej pozby si
programu i zwali jego testowanie na kogo innego, to recepta na klsk.
Pod warunkiem jednak waciwego planowania caego przedsiwzicia,
przekazanie czci testw innej firmie moe by skutecznym sposobem na
wykonanie specjalistycznych testw, na ktrych wykonanie samemu nie ma
si odpowiednich rodkw.
Podsumowanie
Wnioski jakie naley wyniec z tego i z poprzedniego rozdziau s takie, e
wszelkie rodki s dobre, eby sta si lepszym testerem. W jednej sytuacji
trzeba posuy si technologi, w innej postara si o pomoc innych ludzi,
jeszcze inna wymaga brutalnej siy - testowania rcznego. Kada sytuacja
jest inna i przy kadej mona sie czego nowego nauczy. Trzeba
eksperymentowa, prbowa rnych podej, obserwowa jak robi inni - i
cay czas mie na uwadze skutecznoc testowania i prawdopodobiestwo
znajdowania bdw.
Ten rozdzia zamyka cz ksiki powicon sposobom wykonywania
testowania. To bya dobra zabawa. Poznalimy proces wytwarzania
oprogramowania, podstawowe techniki testowania, jak je stosowa, jak je
wspomaga. W czci V-ej "Praca z dokumentacj" zobaczymy, jak to
wszystko czego nauczylimy si dotd poczy w cao: jak zaplanowa i
zorganizowa testowanie, jak zapisywa i ledzi znajdowane bdy, i jak
mie pewno, e zostan odpowiednio naprawione.
Pytania
1.Opisz paradoks pestycydw i w jaki sposb zaangaowanie nowych osb
w testowanie moe mu zapobiec.
2.Jakie s moliwe korzyci programu testowania beta?
3.Z czym naley zachowa ostrono planujc testowanie beta?
Strona 34 (34)
4.Jeli pracuje si w maym przedsibiorstwie robicym oprogramowanie,
czy warto przekaza test konfiguracji innej fimie?
Strona 1 (84)
Cz V
Dokumentacja testowania
Nic si naprawd nie zdarzyo, jeli tego nie zanotowano.

-
Viginia Woolf, angielska pisarka, eseistka i krytk literacki
Przy pisaniu artykuw do czasopism naukowych wydaje si obowizywa

zasada, e zaciera si za sob lady, nadaje swojej pracy ksztat bardziej
gotowy ni to jest naprawd, przemilcza lepe uliczki i to, jak na pocztku
miao si zupenie myln teori. Nie a wic gdzie opublikowa - w powanej
formie - co si naprawd zrobio eby rzecz zacza dziaa.
- Richard Feynman, amerykaski fizyk
W TEJ CZCI
Planowanie testowania
Jak pisa zadania testowe i rejestrowa ich wyniki
Raportowanie wynikw
Pomiar sukcesu
Strona 2 (84)
Rozdzia 16 Planowanie testowania

W TYM ROZDZIALE
Cele planowania testw
Tematyka planowania
Ten rozdzia otwiera cz V- Dokumentacja testowania. Omwione
dotd tematy przedstawiay testowanie z lotu ptaka i nauczyy nas podstaw
znajdowania bdw - gdzie szuka, jak testowa, jak testowa skutecznie.
Rozdziay nalece do czci V-ej opisuj, jak wszystkie zwizane z
testowaniem czynnoci planuje si, organizuje i komunikuje zespoowi
projektowemu.
Pamitajmy jaki cel przywieca testerowi:
Celem testu oprogramowania jest znajdowanie bdw, znajdowanie
ich jak najwczeniej i dopilnowanie, eby zostay naprawione.
Porzdne udokumentowanie testowania przy pomocy dobrze
skonstruowanych planu testowania, zada testowych i raportw testw
przyczyni si do osignicia tego celu.
Niniejszy rozdzia powicony jest przede wszystkim planowi testowania,
najwaniejszemu z dokumentw potrzebnych w pracy testera. Nowy tester
przypuszczalnie nie bdzie musia napisa obszernego planu testowania - to
zadanie przypadnie w udziale kierownikowi zespou testowego albo
menederowi testw. Kady jednak bdzie w jakim stopniu uczestniczy w
wytwarzaniu planu, dlatego potrzebna jest orientacja na czym to zadanie
polega i co wchodzi w skad planu testowania. W ten sposb mona
zarwno przyczyni si do procesu planowania, jak i nauczy si lepszej
organizacji - dla siebie. Poza tym, ju wkrtce dzisiejszy pocztkujcy tester
stanie si dowiadczonym testerem i bdzie pisa plany testowania.
Gwne tematy tego rozdziau:
1. Cele planowania testowania
2. Dlaczego wanie jest planowanie, a nie plan
3. Co trzeba uwzgldni w planowaniu
4. Jaka rol w planie testowania odgrywaja
pocztkujcy testerzy
Cele planowania testw
Strona 3 (84)
Proces testowania nie moe funkcjonowa w prni. Testowanie byoby
bardzo trudne, gdyby programici pisali kod nie informujc, co program ma
wykonywa, jak dziaa, kiedy bdzie gotowy. Podobnie, jeli testerzy nie
bd informowa co planuj testowa, jakich potrzebuj zasobw i jaki maj
harmonogram, szanse sukcesu bd nike. Najwaniejszy nonikiem
informacji na teat tego, co testerzy zamierzaj robi, jest plan testownaia
oprogramowania.
Standard ANSI/IEEE 829/1983 powicony dokumentacji testu
oprogrmowania nastpujco definiuje cel planu testowania:
Okrelenie zakresu, metodyki, zasobw i harmonogramu testowania.
Zidentyfikowanie przedmiotw testowania, funkcji do przetestowania,
czynnoci ktre trzeba wykona, osb odpowiedzialnych za kad z
nich oraz ryzyka zwizanego z planem.
Zarwno ta definicja jak i caa reszta standardu zakada, e plan testowania
jest rodzajem pisemnego dokumentu. Nic w tym dziwnego, ale chocia ten
kawaek papieru (albo dokument elektroniczny) jest kocoweym rezultatem,
nie o niego jednak przede wszystkim chodzi.
Plan testowania jest ubocznym produktem szczegowego procesu
planowania, ktry zosta podjty w celu stworzenia tego dokumentu.
Istotny nie jest dokument, lecz proces planowania.
Tytu rozdziau brzmi Planowanie testowania, a nie Pisanie planu
testowania. To rozrnienie jest zamierzone. Zbyt czsto napisany plan
testowania koczy ywot jako cega - dokument ustawiony na pce,
ktrego nikt nie czyta. Jeli celem planowania nie jest dokument, lecz proces
jago konstruowania - nie pisanie planu lecz definieowanie zada - problem
cegy znika automatycznoie.
Nie oznacza to e kocowy dokument - plan testowania opisujcy wyniki
procesu planowania - jest zbdny. Wrcz przeciwnie, plan testowania jest
nadal potrzebny jako referncja i do archiwizowania. W niektrych
przemysach jest wrcz wymagany przez prawo. Wane jdynie, eby plan nie
by gwnym celem, lecz niejako ubocznym produktem procesu planowania.
Njwaniejszym celem planowania testowania jest zakomunikowanie - a
nie zapisanie - zamiarw, oczekiwa i sposobu rozumienia testu przez
zasp testowy1.
Bardzo to pikne deklaracje - zwaszcza jeli maj przeciwdziaa nadmiernej "biurokratyzacji"

projektw - niemniej warunkiem koniecznym cho niewystarczjcym do skutecznego
zakomunikowania - jest zapisanie wynikw planowania, zwaszcza jeli sie chce, eby komunikat
pozosta aktualny take po upyniciu pewnego czasu.
Strona 4 (84)
Jeli zesp projektowy spdzi dostateczn ilo czasu pracujc nad tematami
opisnymi w pozostaej czci rozdziau, wyjaniajc i informujc wszystkich o
swoich zamiarach, wwczas zostanie uczyniony duy krok w kierunku
realizacji powyszego celu.
Tematyka planowania
Wiele ksiek na temat testowania zawiera wzr albo przykad planu
testowania, ktry atwo mona zmodyfikowa, aby stworzy na jego
podstawie swj wasny plan. Wad tego podejcia jest to, e sprzyja zbytniej
koncentracji na dokumencie zamiast na procesie. Bywao e kierownicy
testw duych projektw brali elektroniczny wzorzec dokumentu, spdzali
kilka godzin wycinajc, kopiujc i wklejajc, po czym wychodzi im
niepowtarzalny plan dla ich projektu. Mogo si wydawa, e dokonali nie
byle czego, konstruujc w cigu paru godzin to, co innym zajo tygodnie
lub miesice. Tego rodzaju plan pozostawa z reguy z dala od
rzeczywistoci tak dalece, e czsto nikt w zespole nie orientowa si, co
waciwie robili testerzy i dlaczego.
Z tego powodu nie ma w tej ksice szablonu planu testowania. Zamiast
niego jest lista najwaniejszych tematw, ktre trzeba dokadnie
przedyskutowa, zrozumie i ustali w zespole projektowym - z udziaem
testerw. Nie wszystkie pozycje z listy bd adwkwatne do kadego
projektu, ale i tak atwiej bdzie j dopasowa do potrzeb projektu ni
szczegowy szablon dokumentu. Z natury rzeczy planowanie jest procesem
dynamicznym, tak e dozwolone jest ominicie tych pozycji listy, ktre
danego projektu nie dotycz.
W wyniku procesu planowania powstanie oczywicie jaki rodzaj
dokumentu. Jego ksztat moe byc z gry okrelony - jeli brana lub
przedsibiorstwo maj swj standard. Przykadem szablonu do zastosowania
jest Standard 829/1983 ANSI/IEEE dla Dokumentacji Testowania
Oprogramowania. W przeciwnym razie form dokumentu projekt moe
ustali sam - naley nastawi si na form najskuteczniejsz aby przekaza
innym istotn tre.
Oczekiwania
Tematy, ktre w pierwszym rzdzie trzeba bdzie zaplanowa, dotycz
podstawowych aspektw i oczekiwa zespou testowego. To s rzeczy na
tyle kluczowe, e powinien w ich sprawie by zawarty konsensus, ale czsto
zostaj przeoczone. By moe robi wraenie zbyt oczywistych i zakada
si, e wszyscy je rozumiej - ale dobry tester nigdy niczego nie powinien
zakada!
Strona 5 (84)
5. Jaki jest cel procesu planowania testu i planu
testowania? Tester zna powody planowania OK, czytelnik wkrtce je pozna - ale czy znaj
je rwnie programici, autorzy techniczni,
kierownictwo? Co waniejsze, czy zgadzaj si
na zaplanowany proces testowanoie?
6. Jaki produkt si testuje? Oczywicie, sdziy e
to jest Ginsumatic v8.0, ale czy na pewno?
Czy wersja 8.0 jest tylko niewielk zmian w
ramach pielgnacji, czy zupen zian
architektury systemu? Czy jest to pojedynczy
produkt czy te skaadajcy si z tysicy
komponentw. Czy wytwarzany jest w
przedsibiorstwie, czy te przez inn firm?
Aby testowanie zakoczo si
sukcesem, musi istnie pene
proozumienie czym jest prokt, jego
wielko i zakres. Opis produktu
na podstawie specyfikacji wyaga
to dobry pocztek. Potem mna
sobie sprawi niespodziank,
pokazujc opis kilku zonkom
zespu. Niejeden prograista
powidzial Co? Pisany przerze
mnie kod tego noie zrobi!.
7. Jakie s cele jakociowe i niezawodnociowe?
Ten temat z reguy powoduje najrozmaitsze
reakcje, ale jest istotne by wszyscy zgodzili si
na wybrane cele. Sprzedwca oczekuje, e
produkt bdzie dziaa jak najszybciej.
Programista powie, e chciaby mie najnowsz
technologi. Obsuga powie, e nie nie chce
zna adnych bdw powodujcych widoczn
awari. Nie wszyscy moga mie racj na raz. Jak
mierzy szykbo i fajnie? I jak powiedzie
kierownikowi produktu, e system bdzie ulega
czasem awarii? Zesp testujcy bdzie testowa
niezawodno i jako produktu, tak e trzeba
zna swj cel. Skd inaczej wiedzie, czy si do
niego ju doszo?
Strona 6 (84)
Wynikiem procesu planowania ma by jasna, zwiza i zaakcpetowana
przez wszystkich definicja celw jakoci i niezawodnoci produktu.
Musi by tak sformuowana, eby nie byo adnych dyskusji, czy
rzeczywicie s osignite - lub nie. Jeli sprzedawcy ycz sobie
szybkoci, kamy im zdefiniowa miar - na przykad milion transkacji
na sekund albo dwa razy szybciej ni konkurent XYZ wykonujcy
podobne zadanie. Jeli programici ycz sobie odlotowych technologi,
zdefiniujmy dokadnie o co chodzi i pamitajmy, e zbdna technologia
to bd! Jeli chodzi o bdy, nie da si zagwarantowa, e ich nie bdzie
- wiemy ju e to jest niemoliwe. Mona jednak sfromuowa cel
wyimerny, na przykad e automatyczna mapa bdzie testowa
program przez dwadziecia cztery godziny nie powodujc ani jednej
awarii, albo e wszystkie zadania testowe bd wykonane bez ani
jednego nowego bdu itd1. Bdmy konkretni. Kiedy zblia si data
wypuszczenia produktu, nie powinno ju by adnych nieporozumie w
sprawie kryteriw jakoci i niezawodnoci. Powinny ju byc znane
wszystkim.
Ludzie, miejsca i rzeczy
Planujc testowanie musimy zidentyfikowa osoby pracujce w projekcie,
ich funkcje i jak si z nimi skontaktowa. W maym projekcie moe si to
wydawa zbdne, ale nawet may projekt moe mie pracownikw
rozproszonych z dala jeden od drugiego. Zatrudnieni mog si take
zmienia, co utrudnia kontrol nad tym, kto jest za co odpowiedzialny. W
duy projekcie mog istnie setki pocze midzy osobami. Zespoy
testowe zwykle musz wsppracowa ze szczeglnie du iloci osb, i
dobra orientacja kto jest kto i jak si z kadym skontaktowa jest
szczeglnie wana. Plan testowania powinien wic zawiera nazwiska,
tytuy, adresy, telefony, adresy poczty elektronicznej i zakresy
odpowiedzialnoci wszystkich najwaniejszych osb w projekcie2.
Trzeba rwnie okreli, gdzie znajduje si dokumentcja (na ktrej pce
stoi plan testowania), skd mona zaadowa oprogramowanie, gdzie
znajduj si narzdzia do testowania3. Naley wzi pod uwag aliasy
(nazwy zastpcze) poczty elektronicznej, nazwy serwerw, adresy witryn
WWW.
Jest to - brutalnie skrtowe - streszcznie moliwych kryteriw uznania testowania za zakoczone. To

obszerna tematyka, wymagajca w zasadzie osobnego rozdziau (przyp. tumacza).
2
Po raz kolejny w tej ksice trudno si oprze wraenieu, e propozycje autora zmierzaj w stron
tego, by kompetentny i zapobiegliwy kierownik testowania kompensowa wszelkie braki niezbyt
sprawnego kierownika projektu (przyp. tumacza).
3
Czy to raczej nie wchodzi w zakres zarzdzania konfiguracj (przyp. tumacza)?
Strona 7 (84)
Jeli do przeprowadzenia testw potrzebny jest sprzt, gdzie si znajduje i
jak go dosta? Jeli zewntrzne laboratorium ma wykona testowanie
konfiguracji, gdzi si ono mieci i jaki ma haronogram?
Najlepiej streci t tematyk jako wskaniki do tego wszystkiego, o co
zapytaby nowozatrudniony tester. Moe to by dobrym zadaniem dla
pocztkujcego testera. Zajdujc odpowiedzi na swoje pytania, po prostu si
je zapisuje. To, co si znalazo, zapewne wicej osb te chciaoby wiedzie.
Definicje
Nieatwo skoni wszystkie osoby nalece do zespou projektowego do
tego, by pogodziy si w kwestii definicji celw jakoci i niezawodnoci.
Niestety, te pojcia to dopiero pierwsze z listy licznych poj, ktre projekt
wytwarzania oprogramowania musi zdefiniowa. Przypomnijmy sobie
definicj bdu z rozdziau 1-ego, Podstawy testowania oprograowania:
1. Oprogramowanie nie wykonuje czego, co
wedle specyfikacji powinno wykonywa.
specyfikacji powinno nie robi.
powinna.
Czy kady czonek zespou zna, rozumie i - co najwaniejsze - zgadza si z
t definicj? Czy kierownik projektu zna cele zespou testowego? Jeli nie,
sposb zakomunikowania tego powinien zosta opisany w planie
testowania.
To jeden z najpowaniejszych problemw w zespoach projektowych nieznajomo definicji podstawoych uywanych w projekcie poj.
Programici rozumiej jaki termin w jeden sposb, testerzy w drugi, a
kierownik w trzeci sposb. Wyobramy sobie zamieszanie wynikajce z
tego, e prograici i testerzy rozumiej inaczej pojcie tak podstawowe, jak
to czym jest bd.
Sownictwo i teminologia uywane przez zesp testowy powinno by
zdefiniowane w procesie planowanoia testowania. Trzeba zidentyfikowa
ewentualne rnice i uzgodni je, eby wszyscy mogli si ze sob rozuie.
Strona 8 (84)
Oto lista kilku czsto spotykanych terminw i ich bardzo oglnikowe
definicje. Lista nie jest pena, a definicje nie s niepodwaalne. Jedne i
drugie mog zalee od zakresu projektu, rodzaju modelu wytwarzania
stosowanego przez zesp, poziomu dowiadczenia i kompetencji czonkw
zespou. Podaje si je tutaj po to, aby zachci do zastanowienia si, jakie
terminy powinny by w projekcie zdefiniowane i jak jest wane, by kady
zna ich znaczenie.
8. Poczenie (wersja). Poczenie kodu i danych
w cao, ktr mona testowa. Plan testw
powinien okrela czstotliwoc pocze
(codziennie, raz na tydzie) i ich przewidywan
jako.
9. Informacja na temat wersji1. Dokument
doczany do kadej nowej wersji (poczenia),
okrelajcy co jest nowe, zmienione lub
naprawione.
10. Wersja alfa. Wczesna wersja przeznaczona do
czciowej dystrybucji dla nielicznych
wybranych klientw oraz dla celw
demonstracji. Nie ma by uywana w
rzeczywistych sytuacjach. Chcc uywa wersj
alfa, trzeba zna dokadnie jej zawartoc i
poziom jakoci.
11. Wersja beta. Oficjalna wersja przeznczona do
dystrybucji do potencjalnych klientw.
Pamitamy z rozdziau 15-ego Testowanie beta
i polowanie na bdy, e naley zdefiniowa
cele robienia wersji beta oprogramowania.
12. Zamroenie specyfikacji. Data w
harmonograie, po ktrej specyfikacja ma by
kompletna i przesta si zienia. Kto bra ju
udzia w paru projektach, moe podejrzewa, e
taka data wystpuje tylko w baniach, ale
zdecydowanie naley zaleca jej ustalenie - po
tej dacie specyfikacja wymaga moe ju tylko
ulega ograniczonym i cile kontrolowanym
zianom.
13. Zamroenie funkcji. Data w haronogramie, po
ktrej programici przestaj dodawa do kodu
nowe funkcje i koncentruj si wycznie na
naprawianiu bdw.
W ksice termin "Test release document". Inne czsto spotykane angielskie nazwy to "Release
information", "Build contents" i inne - prawie kada firma ma wasn nazw (przyp. tumacza).
Strona 9 (84)
14. Komitet bdw1. Grupa zoona z kierownika
testw, kierownika projektu oraz kierownika
produktu2, spotykajca si raz w tygodniu3 w
celu dokonania przegldu raportw bdw i
podjcia decyzji, ktre z nich i jak maj byc
naprawione. Komitet bdw jest gwnym
uytkownikiem celw jakoci i niezawodnoi,
zdefiniowanych w planie testowania.
Podzia ddpowiedzialnoci
Istnieje wiele zewntrznych okolicznoci, wywierajcych decydujcy wpyw
na proces testowania. Na prace zespou testowego wywieraj te wpyw inne
grupy: programici, kierownictwo, autorzy tekstw techniczncyh itd. Jei
nie zaplanuje si podziau odpowiedzialnoci, projekt - zwaszcza
testowanie - moe sta si komedi chaotycznego przerzucania sobie
pieczki nawzajem, przez co traci si kontrol i zapoina o wanych
zadaniach do wykonania.
Rodaje zada, ktre trzeba zdefiniowa, nie zawsze s proste i oczywiste,
typu testerzy testuj, programici programuj. Najprostszym sposobem
planowania i zakomunikownaia podziau zada i odpowiedzialnoci jest
tabela (zob. rysunek 16.1).
Rodzaje zada i czynnoci znajduj si w lewej kolumnie, a lista moliwych
wacicieli - w pierwszym rzdzie na grze tabeli. Znak x oznacza
waciciela zadania, a mylnik - wskazuje na rol wspluczestnika. Pusty
znak oznacza brak bezporedniego zwizku.
Dowiadczenie uatwia podjcie decyzji w sprawie listy ewentualnych
zada. Kilku starszych uczestnikw projektu moe dokona wstpnej
analizy, ale kady projekt ma nieco inn struktue, inne te ni gdzie indziej
zalenoci midzygrupowe. Mona zacz od wypytywania o minione
projekty i o to, co wtedy zostao zaponiane.
Co tesowa, czego nie testowa
Nie wszystko co wchodzi w skad produktu informatycznego zawsze si
tetsuje. Oprogramowanie moe zawiera komponenty wypuszczone i
przetestowane ju wczeniej. Wykorzystuje si te oprogranowanie
dostarczone przez inne firmy.
Tutaj "bug committee", inne czste nazwy to "change control board", "defect meeting", "trouble
report board", "emergency board" (przyp. tumacza).
2
I czsto wielu innych osb (przyp. tumacza).
Albo czciej, albo te ziej - zlenie od fazy projektu, potrzeb i od czstotliwoci znajdowania bw
(przyp. tumacza).
--x
---
x
x
x
-----
-----
-----
---
---
---
---
x
x
---
---
---
---
---
x
x
-----
---
---
-----
Obsuga produktu
Dzia sprzeday
Test
Programici
Autorzy techniczni
Zadanie
Opisanie wizji produktu
Stworzenie listy koponentw
Zawarcie kontraktw i
proozumie
Projektowanie produktu
Gwny plan projektu
Specyfikcja produktu
Inspekcja specyfikacji produktu
Wewntrzna architektura
produktu
Konstrukcja i kodowanie
Planowanie testowania
Inspekcja planu testowania
Test komponentw (moduw)
Test oglny
Stworzy list konfiguracji
Zdefiniowa pomiary dotyczce
osigw/wydajnoi
Wykona testy kontrolne
Testowanie zawartoci
Test kodu dostarczanego spoza
projektu
Zautomatyzowa proces
wytwarzania nowej wersji
Budowanie i duplikacja dysku
Kontrola jakoci
Lista beta
Kontrola nad programem beta
Przegld materiaw
drukowanych
Definicja wersji do demonstracji
Wykonanie wersji do
demonstracji
Przetestowanie do wersji do
demonstracji
Komitet bdw
Kierownictwo projektu
Strona 10 (84)
x
x
--x
---
x
x
x
--x
---
--x
x
x
---
---
---
---
---
x
x
---
---
---
---
Rysunek 16.1 Uycie tabeli do zaplanowania podziau odpowiedzialnoci
Strona 11 (84)
W procesie planowania trzeba zidentyfikowa kady komponent
oprogramowania i ustali, czy bdzie si go testowao. Jeli nie, musi istnie
tego przyczyna. Byoby klsk, gdyby fragment kodu przelizgn si przez
proces wytwrczy zupenie nieprzetestowany - z powodu nieporozumienia.
Fazy testowania
Aby zaplanowa rne fazy testowania, zesp testujcy musi wzi pod
uwag stosowany model wytwarzania i zadecydowa, jakie fazy, albo etapy
testowania musz byc wykonane w trakcie projektu. W modelu prb i
bdw bdzie przypuszczalnie tylko jedna faza - testowa dopki kto nie
zawoa do. W modelu kaskadowym i spiralnym wyodrbnia sie zwykle
kilka faz - od badania specyfikacji produktu a do testowania
akceptacyjnego. Tak, planowanie testowania te jest jedn z faz testowania.
Zidentyfikowawszy fazy testowania, zesp testowy powinien
zakomunikowa swoje rozstrzygnicia caemu zespoowi projektowemu.
Czsto dziki temu cay zesp zaczyna lepiej rozumie nie tylko test, ale
cay model wytwarzania.
Dwa bardzo wane pojcia zwizane z fazami testowania to s kryteria
wyjcia i kryteria wejcia. Zesp testerw nie moe po prostu przyj do
pracy w poniedziaek rano, rzucic okiem na kalendarz i stwierdzi, e oto
s w kolejnej fazie. Dla kadej fazy musz istnie jednoznacznie
zdefiniowane, obiektywne kryteria, pozwalajce stwierdzi, e jedna faza
si zakoczya, a nastpna zacza.
Na przykad mona zdefiniowa, e etap przegldu specyfikacji jest
zakoczony, gdy opublikowany zosta protok przegldu. Etap
testowania beta zaczyna si, gdy test akceptacyjny dla wersji beta
programu zosta zakoczony bez znalezienia adnych nowych bdw.
Bez sprecyzowanych kryteriw wejcia i wyjcia, testowanie rozpadnie
sie na mae, sabo ze sob powizane kawaki - podobnie jak w modelu
prb i bdw.
Strategia testowania
Okrelenie faz testowania jest jednym z zada w czasie formuowania
strategii testowania. Strategia testowania opisuje, jak bdzie wykonywane
testowanie zarwno w caoci jak i w kadej fazie z osobna1. Przypomnijmy
sobie, czegomy si dotd nauczyli o testowaniau oprogramowania. Majc
produkt do przetestowania, trzeba midzy innymi zadecydowa, czy
skoncentrowa si na zastosowaniu technik czarnej czy szklanej skrzynki.
Jeli zastosowa obie, kiedy i wobec ktrych komponentw
oprogramowania?
Czsto strategia testowania jest podstw procesu testowania, jest wic wsplna dla wielu rnych
proojektw (przyp. tumacza).
Strona 12 (84)
Moe by znakomitym pomysem, eby cz kodu przetestowa rcznie, a
cz - przy uyciu narzdzi i automatyzacji. Jeli bd uyte narzdzia, czy
trzeba je bdzie samemu skonstruowa, czy wystarczy zakupi? Jeli kupi,
to ktre? A moe byoby najefektywniej zleci testowanie
wyspecjalizowanej, niezalenej firmie i pozostawi w projekcie tylko
szcztkowy zesp testerw do kontrolowania przebiegu prac i do kontaktw
z t firm?
Podjcie decyzji odnonie strategii to zoone zadanie. Decyzj t powinni
podejmowa najbardziej dowiadczeni testerzy, poniewa moe ona
zaway na powodzeniu lub niepowodzeniu caej pracy. Istotne jest ponadto,
aby kady w zespole projektowym rozumia i zgadza si z przyjtym
rozwizaniem.
Wymagania dotyczce zasobw
Planowanie zasobw jest procesem definiowania swoich potrzeb. Trzeba
wzi pod uwag wszystko, co moe by potrzebne do testowania przez cay
okres projektu. Na przykad:
15. Personel. Ile osb, z jakim dowiadczeniem, z
jakimi specjalnociami? Czy powinni by
zatrudnieni w penym wymiarze godzin czy na
krtszy okres czasu?
16. Sprzt. Komputery, sprzt testowy, drukarki,
narzdzia.
17. Powierzchnia biurowa i laboratorium. Gdzie
bd si mieci? Jakie due, jak urzdzone?
18. Oprogramowanie. Programy do przetwarzania
tesktu, bazy danych, specjalne narzdzia. Ktre
mona kupi, ktre trzeba zrobi samemu?
19. Firmy specjalistyczne w zakresie testowania.
Czy bdziey si do nich odwoywa? Przy
pomocy jakich kryteriw zostanie dokonany
wybr midzy nimi? Ile kosztuj?
20. Rne dostawy: dyski, telefony, manuale,
podrczniki. Co jeszcze moe sie przyda pod
koniec projektu?
Szczegowe potrzeby zasobw zale w znacznym stopniu od
przedsibiorstwa, projektu i zespou, tak e kady plan testowania musi
przeprowadzi szczegow analiz potrzeb. Czsto pod koniec projektu
niemoliwe okazuje si uzyskanie tego, czego nie uwzgldnio si w
budecie od pocztku, tak e warto wykona t prace drobiazgowo.
Strona 13 (84)
Zadania dla testerw
Kiedy fazy testowania, strategia i potrzeby s ju okrelone, mona t
informacj wykorzysta - razem z danymi ze specyfikacji produktu - do
okrelenia zada dla poszczeglnych testerw. Omwiony wczeniej podzia
miedzygrupowy dotyczy odpowiedzialnoci za zadania na wyszym
poziomie oglnoci. Okrelanie szczegowych zada dotyczy
poszczeglnych testerw. Tabela 16.1 pokazuje przykad - znacznie
uproszczony - opisu zada testrw.
Tabela 16-1 Definicje zada testrw
Strona 14 (84)
Tester
Olek
Sara
Ludwik
Jola
Wanda
Zadanie
Formaty znakw: czcionki, rozmiary,
kolory, style
Ukad: punkty, akapity, tabulator,
zawijanie wierszy
Konfiguracja i kompatybilno
Interfejs uytkownika: uyteczno,
wygld, dostepno
Dokumentacja: pomoc interakcyjna
Strona 15 (84)
Roman
Przecienie i obcienie
Strona 16 (84)
Rzeczywiste opisy zada byyby o wiele bardziej szczegowe, okrelajc
dokadnie zadania poszczeglnych testerw tak, eby na tej podstawie mc
konstruowa zadania testowe1.
Harmonogram testw
Harmonogram testw zbiera razem wszystkie dotd zaprezentowane
zagadnienia i wprowadza je do harmonogramu projektu. Ta faza czsto
okazuje si krytyczna dla planowania testowania, poniewa funkcje, ktre
byo nietrudno zaprojektowa i kodowa, okazuj si niekiedy bardzo
czasochonne w testowaniu. Przykadem moe by progra, ktry nie
wykonuje niemal adnych wydrukw - prcz jednej, rzadko uywanej
funkcji. Nikt mg sobie nie zdawa sprawy z wpywu tej funckcji na
testownaie, ale moe ona oznacza tygodnie testowania konfiguracji.
Harmonogam testowania powienien umoliwi kierownictwu projektu
uzupenienie harmonogramu caego projektu. Zdarza si, e uwzgldnienie
wymaga harmonogramu testownaia moe wpyn na zmian specyfikacji
projektu, np. spowodowa usunicie szczeglnie czasochonnych w
testowaniu funkcji.
Planujc testowanie trzeba koniecznie uwzgldni fakt, e testownaie jest
bardzo nierwnomiernie rozmieszczone na osi czasowej typowych
projektw. Pewna ilo testowania pojawia si na pocztku projektu w
formie przegldw kodu i specyfikacji, konstruowania narzdzi itd., ale ilo
zada i ilo zaangaowanych w nie osb wzrasta z czasem, osigajc szczyt
tu przed zakoczeniem projektu. Rysunek 16.2 pokazuje typowy diagram
zasobw projektu testowania.
Skutkie tego spitrzenia jest wzrastajca zaleno testowania od tego, co
dzieje si w projekcie wczeniej. Jeli jaki skadnik produktu zostanie
dostarczony z dwutygodniowym opnieniem do fazy testowania, ktra
bya zaplanowana na trzy tygodnie, co si wtedy stanie? Czy
trzytygodniowe testowanie zmieci si w cudowny sposb w jeden tydzie,
czy te cay projekt zostanie opniony o dwa tygodnie? Ten problem znany
jest jako zjadanie harmonogramu.
Zasoby w projekcie XXX
Testerzy
Miesice
Jest to, powiedzmy, do szczeglna forma zarzdzania projektem. Tematyka jest wprawdzie poza
zakresem ksiki, ale istniej bardziej elastyczne formy zarzdzania (przyp. tumacza).
Strona 17 (84)
Rysunke 16.2 Ilo testerw w projekcie zwykle wzrasta w kolejnych fazach
procesu wytwrczego.
eby tego unikn, nie naley wstawia do harmonogramu z gry
ustalonych dat, kiedy poszczeglne zadania zacznie si i zakoczy. Tabela
16.2 jest przykadem harmonogramu, ktry na pewno doprowadzi do
znikania czasu przeznaczonego na testowania.
Tabela 16.2 Harmonogram testowania oparty na z gry ustalonych datach
Strona 18 (84)
Zadanie
Gotowy plan testowania
Gotowe wszystkie zadania testowe
Wykonanie testw po raz pierwszy
Wykonanie testw po raz drugi
Data
5 III 2001
1 VI 2001
15 VI 2001 - 1 VIII 2001
15 VIII 2001 - 1 X 2001
Strona 19 (84)
Wykonanie testw po raz trzeci
15 X 2001 - 15 XI 2001
Strona 20 (84)
Jeli zamiast staych dat uywa dat wzgldnych, opartych na kryteriach
wejcia i wyjcia zdefiniowanych dla poszczeglnych faz testowych,
wyraniej wida wtedy, e wikszo zada testowych zaley od
wczeniejszych dostaw. Wyraniej widzi si te ile czasu zajmuj
poszczeglne zadania. Przykad takiego planu znajduje si w tabeli 16.3.
Tabela 16.3 Harmonogram testowania oparty na z datach wzgldnych
Strona 21 (84)
Zadanie
Gotowe wszystkie zadania
testowe
Wykonanie testw po raz
pierwszy
Wykonanie testw po raz drugi
Data rozpoczcia
7 dni po zamkniciu
specyfikacji wyaga
Trwanie
4 tygodnie
Gotowy poczony kod
6 tygodni
Wersja beta
6 tygodni
12 tygodni
Strona 22 (84)
Wykonanie testw po raz trzeci Wersja do oficjalnego
wypuszczenia
4 tygodnie
Strona 23 (84)
Oprogramowanie do tworzenia harmonogramw uatwia zarzdzanie tego
typu zalenociami. Kierownik projektu, ponoszcy gwn
odpowiedzialno za haronogram, uywa przypuszczalnie takiego programu.
Zadania testowe
Wiemy ju co to s zadania testowe - nauczylimy si tego wczeniej. W
rozdziale 17-ym Jak pisa zadania testowe i rejestrowa ich wyniki
poznamy wicej szczegw na ten temat. W procesie planowania
testowania okrelona zostaje metodyka generowania i wyboru zada
testowych, sposoby icharchiwizacji oraz zastosowanie i pielgnacja.
Raporty bdw
W rozdziale 18-ym Raportowanie wynikw opisane zostan sposoby
opisywania i kontroli znalezionych bdw. Rozstaw moliwoci jest duy od gonego woania z pokoju do pokoju, poprzez stosowanie tych
samoprzylepnych kartek, a do posuenia si skomplikowan baz danych
na skadowanie i zarzdzanie raportami bdw. Cay ten proces trzeba
zaplanowac szczegowo, tak eby kady bd by pod kontrol od momentu
znalezienia a do momentu, gdy jest naprawiony i zweryfikowany - i eby
niegdy adnego si nie udao zgubi!
Pomiary i statystyka
Dokonywanie pomiarw, zbieranie i analiza danych to najlepszy sposb
kontrolowania przebiegu projektu i testowania. W szegach opisujemy je w
rozdziale 19-ym Pomiar sukcesu. Planujc testowanie trzeba szczegowo
zdefiniowa, jakie dane bdzie si gromadzi, jak podejmowa na ich
podstawie decyzje, kto bdzie odpowiedzialny za zbieranie danych.
Przykady poytecznych danych:
21. Ilo znajdowanych codzienie bdw w trakcie
trwania projektu
22. Lista bdw do naprawienia
23. Aktualnie otwarte raporty bdw ustawione
wedug wanoci
24. Ilo bdw znaleziona przez kadego testera
25. Ilo bdw znalezionych w kadej funkcji albo
czci programu
Ryzyko
W trakcie planowanie czsto wykonuje si prb zidentyfikowania
moliwych problemw albo zagroe w projekcie - tych, ktre maj
znaczenia z punktu widzenia testowania.
Strona 24 (84)
Zamy e 10 nowych testerw, ktrych cae dowiadczenie w zakresie
testowania sprowadza si do lektury tej ksiki, otrzymuje zlecenie
przetestowania oprogramowania nowej elektrowni atomowej. Byoby to
due ryzyko. Inny przykad - moe nikt nie zdaje sobie sprawy, e jakie
nowe oprogramowanie powinno si przetestowa z 1500 rnych modemw
i harmonogram projektu nie przewiduje na to czasu - te ryzyko.
Testerzy odpowiedzialni s za rozpoznawanie zagroe w trakcie
planowania i za powiadomienie o nich kierownika testowania albo
kierownika projektu. Rozpoznane zagroenia zostan wzite pod uwag w
planie testowania i uwzgldnione w harmonogramie. Niektre zagroenia
zrealizuj si, innym uda si zapobiec. Wane, by zda sobie z nich spraw
zawczasu, eby nie pojawiay si w postaci niemiej niespodzianki pod sam
koniec projektu.
Podsumowanie
Skonstruowanie planu testowania - nawet dla niewielkiego projektu - to
powane zadanie, do ktrego nie mona zabiea si nonszalancko.
Oczywicie, nie jest trudno wypeni puste rubryki w gotowym szablonie i
po paru godzinach mc zacz drukowa nowy plan testowania, ale nie w
tym rzecz. Planowanie testowania to zajcie, w ktrym powinni
uczestniczy wszyscy testerzy i inne osoby z caego zespou projektowego.
prozdne zrobienie tego moe zaj tygodnie, a nawet miesice. Jednak
uzyskanie ju na pocztku projektu dobrej orientacji w tym, co, dlaczego i
jak bdzie si testowa powoduje, e wszystko pniej funkcjonuje o wiele
sprawniej, ni gdy planowanie zrobi si na odczepne.
Pocztkujcy tester - jaki zapewne jest wielu czytelnikw tej ksiki przypuszczalnie nie otrzyma zadania skonstruowania planu testowania.
Warto jednak by przygotowanym na to, by mc dostarczy potrzebne dane
kierownikowi zespou testujcego lub menederowi testowania. Kady jest
odpowiedzialny za jaki fragment caoksztatu testowania i czstkowe
harmonogramy, lokalne zagroenia i indywidualne potrzeby cz si w
cao, zwan gwnym planem testowania.
Pytania
1.Po co jest plan testowania?
2.Dlaczego istotny jest proces planowania, a nie sam plan?
3.Dlaczego zdefiniowanie celw jakoci i niezawodnoci oprogramowania
jest wan czci planowania testowania?
4.Co to s kryteria wejcia i kryteria wyjcia?
5.Wymie kilka typowych rodzajw zasobw potrzebnych do testowania,
ktre bierze si pod uwag podczas planowania.
Strona 25 (84)
6.Prawda czy fasz: harmonogram powinien zawiera dokadne daty, tak
eby nie ulegao adnej wtpliwoci, kiedy dana faza testowania ma sie
zacz i kiedy skoczy.
Strona 26 (84)
Rozdzia 17 Jak pisa zadania testowe i rejestrowa

ich wyniki
W TYM ROZDZIALE
Cele planowania zada testowych
Przegld planowania zada testowych
Organizacja i zarzdzanie zadaniami testowymi
W rozdziale 16-ym Planowanie testowania poznalimy proces planowania
i konstruowania planu testowania dla projektu. Informacje znajdujce si w
tym planie s niezbdzne, ale na zbyt wysoki poziomie i zbyt abstrakcyjne,
aby bezporednio kierowa codzienn praca poszczeglnych testerw.
Nastpny poziom w planowaniu testowania - konstruowanie zada
testowych - wpywa wprost na to, co wykonuj testerzy. Pocztkujcy tester
zwykle tylko wykonuje zadania testowe skonstruowane i opisane przez
kogo innnego, ale wkrtce zaczyna si samemu pisa zadania testowe. W
tym rozdziale dowiemy si, jak skutecznie wytwarza i zarzdza zadaniami
testowymi tak, aby swoja prac testera wykonywa maksymalnie skutecznie.
Najwaniejsze punkty w tym rozdziale:
26. Znaczenie konstruowania i zarzdzania
zadaniami testowymi
27. Co to jest specyfikacja projektu testw
28. Co to jest specyfikacja zadania testowego
29. Jak pisze si procedur testow
30. Jak zorganizowa zadania testowe
Cele planowania zada testowych

W pocztkowych rozdziaach tej ksiki bya mowa o rnych modelach
wytwarzania oprogramowania i jak rne techniki testowe daj si
zastosowa, by w tych modelach mc realizowa skuteczne testowanie. W
modelach skokowym i prb i bdw, testerzy s na asce i nieasce projektu,
czsto musz domyla si, co maj testowa i czy znajdowane anomalie to
rzeczywicie bdy? Przy zastosowaniau bardziej sformalizowanych modeli
wytwarzania testowanie staje si nieco atwiejsze, poniewa ma si do
dyspozycji dokumentacj, tak jak specyfikacja wymaga i specyfikcaja
architektury. Tworzenie oprogramowania - projektowanie, architektura i
programowanie - staj si prawdziwym procesem, a nie tylko chaotyczn
gonitw, eby produkt jak najszybciej wepchn uytkownikowi. W takim
rodowisku testowanie staje sie o wiele bardziej skuteczne i przewidywalne.
Strona 27 (84)
Dobrze zorganizowany projekt jest korzystny dla wszystkich, nie tylko dla
testerw. Wiemy ju, e programista, ktry natychmiast zaczyna
produkowa kod na podstawie specyfikacji wyaga, nie sporzdziwszy
wprzdy planu konstrukcji i nie poddawszy jej przegldowi,
przypuszczlanie narobi wicej szkody ni korzyci. Podobnie, tester
konstruujcy zadania testowe na podstawie tylko planu testowania, zapewne
nie osignie zachwycajcych wynikw. Jeli testerzy oczekuj od innych
zdyscyplinowania, powinni sami wieci dobrym przykadem.
Satranne i metodyczne planowanie zada testowych jest krokiem we
waciwym kierunku. Jest ono istotne z czterech powodw:
31. Organizacja. Nawet w niewielki projekcie
mog istnie tysice zada testowych,
skonstruowanych przez kilku rnych testerw
w cigu kilku miesicy czy nawet lat. Waciwie
zaplanowana organizacja pozwoli innym
korzysta z nich wygodnie i skutecznie.
32. Powtarzalno. Jak ju wiemy, w trakcie
projektu niejednokrotnie trzeba te same zadania
testowe powtarza wicej ni raz, szukajc
nowych bdw i sprawdzajc, czy bdy
znalezione wczeniej zpostay dobrze
naprawione. Bez odpowiedzniego planowania,
nie daoby sie stwierdzi, ktre zadania
rzeczywicie zostay wykonane i w jaki sposb,
tak eby mc je powtrzy dokadnie tak sao.
33. Zarzdzanie. W trakcie projektu trzeba umie
odpowiedzie na kilka wanych pyta. Ile zada
testowych planowao si wykona? Ile zostao
wykonanych na ostatniej wersji programu? Ile
przeszo, a ile zawiodo? Ilu zada nie
wykonano? I tak dalej. Nie zaplanowawszy
odpowiedznio ukadu zada testowych, nie da
si na te pytania udzielic sensownych
odpowiedzi.
34. Dowd przeprowadzenia testw. Przy
wytwarzaniu systemw krytycznych ze wzgldu
na bezpieczestwo, czsto trzeba mc
udowodni, e naprawde wykonao si
wszystkie zaplanowane zadania testowe.
Niezgodne z prawem - i niebezpieczne - jest
wwczas wypuszczenie oporogramowania, na
ktrym nie wszystkie zaplanowane testy zostay
wykonane. Waciwie zaplanowane zadania
testowe i rejestracja ich wynikw pozwala
udowowdni, co si naprawd przetestowao.
Strona 28 (84)
Nie naley miesza planowania zada testowych z ich identyfikacj, o
ktrej nauczylimy si w czci II-iej Podstawy testowania. Tamte
rozdziay uczyy nas, jak testowa i jak wybiera zadania testowe,
podobnie jak programistw uczy si programowania w danym jzyku.
Planowanie zada testowych jest kolejnym krokiem, podobnym do tego,
kiedy prograista uczy si, jak projektowa architektur wyszego rzdu i
jak poprawnie udokumentowac swoj prac.
Testowanie ad hoc
Tak zwane testowanie ad hoc polega na ty, e oprogramowanie testuje si
bez planu - nie ma si adnych zada testowych ani nawet planu
testowania, tylko tester zasiada przed komputerem i zaczyna wali w
klawisze. Niektrzy maj do tego wrodzony talent i szybko zaczynaj
znajdowa bdy. Robi to zwykle wraenie i moe by cennym
uzupenieniem planowanych testw - na przykad w czasie zmasowanego
ataku na bdy - ale nie jest zorganizowane, nie daje sie powtrzy, nie
daje si nim zarzdza, a kiedy jest zakoczone, nie ma adnego dowodu,
e rzeczywicie zostao zrobione. Tak jak tester woli unika
oprogramowania, ktre powstao metodami ad hoc, tak klienci nie chc
mie do czynienia z oprogramowaniem, ktre w sposb ad hoc zostao
przetestowane.
Przegld planowania zada testowych

Jak wic waciwie planowanie zada testowych mieci si w wielkim
planie testowania? Rysunek 17.1 pokazuje zalenoci midzy rnymi
typami planw.
Plan Testowania
Specyfikacja Projektu
Testw
Specyfikacja Projektu
Testw
Specyfikacja Zada
Testowych
Plan
Testowania
Plan Testowania
Specyfikacja Procedur
Plan
Testowania
Testowych
Plan Testowania
Rosnca rola
procesu
tworzenia planu
Rosnca rola
pisemnego planu
Strona 29 (84)
Rysunek 17.1 Planowanie testowania na ronych poziomach jest ze soba
cile powizane. Rnica polega na tym, czy najwaniejszy jest sam plan,
czy te proces jego konstruowania.
Wiemy ju, e w przypadku planu testowania na poziomie projektu
waniejszy jest proces planowania ni sam pisany dokumnet. Nastpne trzy
poziomy: specyfikacja projektu testw, specyfikacja zada testowych i
specyfikacja procedur testowych, opisane s w dlaszych czciach tego
rozdziau.
Jak wida na rysunku 17.1, im niej schodzi w hierarchii tych dokumentw,
tym waniejszy staje si sam napisany dokumnet, a mniej wany proces jego
konstruowania. Te dokumenty bowiem - zwaszcza specyfikacja zada
testowych i specyfikacja procedur testowych - uywane s cay czas przez
testerw wykonujcych zadania testowe. Jak si dowiemy, na najniszym
poziomie specyfikacja staje si szczegow instrukcj jak - krok po kroku wykona zadanie testowe, przez co szczeglnej wagi nabieraja dobra
organizacja, przejrzysto i zwizo materiau, a mniej wane jest, jakimi
sposobami udao si to osign.
Tre tego rozdziau opiera si na Standardzie Dokumentacji Testu
Oprogramowania1 ANSI/IEEE Std 829-1983 (dostpny pod
http://standards.ieee.org). Wiele zespow testowych dostosowao swoj
dokumentacj testowania do niego - wiadomie lub nie - poniewa ten
standard stanowi logiczn i zdroworozsdkow zarazem medod planowania
testowania. Naley zdawa sobie spraw, e o ile nie jest si zobligowanym
do cisego przestrzegania tego standardu przez oficjaln polityk swego
przedsibiorstwa lub gazi przemysu, naley posugiwa si nim raczej
jako zbiorem dobrych rad ni jak szczegowym standardem. Zarwno jego
tre jak i proponowane w nim metody s dzi rwnie aktualne jak w 1983,
kiedy standard powsta. Jednak to, co niegdy najlepiej byo przedstawi w
formie pisanego dokumentu, dzi czsto lepiej i skuteczniej jest zrealizowa
w postaci arkusza kalkulacyjunego albo bazy danych. Przykady takich
sytuacji znajduj si w dalszej czci tego rozdziau.
Podsumuwujc, plan testowania dla zespou testujcego powinien
obejmowa pany zakres planu testowania wg ANSI/IEEE 829. Jeli
najlepsze s dla kogo papierowe wydruki (cho trudno w to uwierzy),
niche je stosuje. Jeli kto jest zdania, e najlepsza bdzie centralna baza
danych, a zesp dysponuje czasem i budetem, by j stworzy samemu albo
zakupi, nic nie stoi na przeszkodzie. Wane jest tylko, by zakoczywszy
prac, osign cztery gwne cele planowania zada testowych:
organizacj, powtarzalno, kontrol i dowodzenie poprawnoci.
Grupy zada testowych2
1
Standard for Software Test Documentation (przyp. tumacza).
Autor dzieli - zgodnie ze standardem - opis zada testowych na trzy poziomy: grupy zada testowych
(test design), zadania testowe (test cases) oraz procedury testowe (test procedures). W rzeczywistoci
Strona 30 (84)
Plan testowania pisze si na bardzo oglnym poziomie. Dzieli si w nim
oprogramowanie na poszczeglne funkcje i elementy dajce si
przetestowa, ale nie wyszczeglnia jak bdzie si je testowa. By moe
okreli si zastosowanie automatyzacji, testowania czarnej skrzynki lub
szkalnej skrzynki, ale plan nie wchodzi w szczegy, gdzie i jak te metody
zastosowa. Kolejny poziom szczegowoci, opisujcy sposb testowania
poszczeglnych funkcji i elementw, to specyfikacja grup zada testowych
(projekt konstrukcji zada testowych), ktrej powicony jest ten
podrozdzia.
ANSI/IEEE 829 stwierdza, e specyfikacja grup zada testowych opisuje
bardziej szczegowo metody [opisane w planie testowania] oraz
identyfikuje funkcje, ktre naley uwzgldni przy tworzeniu konstrukcji
testw1. Ponadto okrela si zadania i procedurey testowe, o ile s
wymagane, konieczne do osignicia celu testowania, oraz kryteria
zaliczenia/niezaliczenia.
Celem tej specyfikacji jest zorganizowanie i opisanie testowania, ktre musi
by wykonane na danej funkcji. Nie zawiera ona jednak szczegowych
zada testowych ani opisu poszczeglnych krokw koniecznych do
wykonania zadania testowego. Nastpujce elementy - zaadaptowane ze
standardu ANSI/IEEE 829 - powinny wchodzi w skad tej specyfikacji:
35. Identyfikatory. Unikalny identyfikator daje
moliwo referowania do specyfikacji. W
specyfikacji powinny znajdowa si referencje
do oglnego planu testowania i do wszelkich
innych wykorzystanych planw i specyfikacji.
36. Funkcje do przetestowania. Opis funkcji
oprogramowania, ktrej dotyczy ta specyfikacja,
na przykad funkcja dodawania Kalkulatora,
wybr i wywietlenie wielkoci czcionki w
WordPad, test konfiguracji karty wideo w
QuickTime.
czeciej spotyka si podzia dwupoziomowy: zadania testowe (co jest testowane) opisane w
specyfikacji testowania (test specification) oraz procedury testowe - zwane te czsto instrukcjami
testowymi - (jak wykona zadanie testowe). W wielu przedsibiorstwach nawet te dwa poziomy
zlewaj si w jeden ("co" i "jak" opisane wsplnie w jednym dokumencie). Dodatkowo komplikuje
spraw fakt, e dla wygody i szybkoci wykonywania zada testowych zwykle opaca si czy je w
dugie cigi, obejmujce wiele zada testowych (np. w ramach jednej procedury wpisa, usun i
dokona ponownej prby usunicia osoby z bazy danych - trzy rne zadania testowe). Przyp.
tumacza.
1
Co to jest "test" standard nie wyjania - to brak konsekwencji i spjnoci typowy dla wielu
midzynarodowych i branowych standardw (przyp. tumacza).
Strona 31 (84)
W tej czci wylicza si te
funkcje, ktre zostan
przetestowane jako efekt uboczny
podczas testowania gwnej
funkcji. Na przyklad: cho nie
wchodzi to w zakres niniejszego
planu, interfejs uytkownika okna
dialogowego otwierania plikw
zostanie przetestowany w trakcie
testowania funkcji adowania i
zapisywania.
Wymienia si te funkcje ktrych
si nie przetestuje, lecz o ktrych
mona by faszywie sdzic e bd
przetestowane przy okazji
testowania gwnej funkcji. Na
przykad: testowanie funkcji
dodawania Kalkulatora zostanie
wykonane automatycznie przy
pomocy programu wysyajcego
dane o nacinitych klawiszach
wprost do aplikacji, nie zostanie
wic wykonane adne porednie
testowanie interfejsu uytkownika.
opisane jest w innej grupie zada
testowych.
37. Metody. Oglny opis metody zastosowanej do
przetestowania danej funkcji. Opis metody czsto zawarty ju w planie testowania - zostaje
tutaj pogbiony, technika szczegowo
zdefiniowana, a sposb weryfikacji poprawnoci
wynikw okrelony.
Strona 32 (84)
Na przykad: Zostanie
sporzdzone narzdzie do
sekwencyjnego adowania i
zapisywania przygotowanych
wczeniej plikw rnych
rozmiarw. Ilo plikw z danymi,
ich rozmiary oraz rodzaj danych
zostan okrelone przy pomocy
technik czarnej skrzynki i
uzupenione przykadami
uzyskanymi metod szkalnej
skrzynki, przygotowanymi przez
programistw. Weryfikacja
wynikw testw bdzie wykonana
poprzez prownanie (na poziomie
pojedynczych bitw) zapisanego
pliku z oryginaem, przy uyciu
narzdzia do prownywania
plikw.
38. Identyfikacj zada testowych. Lista i zwize
definicje zada testowych uytych do
przetestowania danej funkcji. Naley okrei
uyte klasy rwnowanoci i poda referencje
do zada, ktre je testuj. Na przykad:
Sprawdzenie najwyszej moliwej
wartoci - Zadanie testowe nr 10
Sprawdzenie najniszej moliwej
wartoci - Zadanie testowe nr 11
Sprawdzenie kilku rnych potg
dwjki - Zadanie testowe nr 12
Nie naley w tym miejscu okrela
dokadnie stosowanych wartoci.
Dla celw inspekcji specyfikacji
pod ktem pokrycia testowego, o
wiele istotniejsze jest podanie klas
rwnowanoci ni konkretnych
wartoci uytych do ich
przetestowania.
Strona 33 (84)
39. Kryteria zaliczenia/niezaliczenia. Okrela si
dokadnie jakie s warunki pozytywnej i
negatywnej weryfikacji testowanej funkcji.
Niekiedy jest to proste - funkcj uznaje si za
dziaajc poprawnie, jeli wszystkie zadania
testowe zostan wykonane bez znalezienia
bdu. Czasem jest niejednoznaczne - np.
funkcj weryfikuje si negatywnie, jeli
niezaliczonych zostao poad 10% zada
testowych. Nie powinny jednak istnie adne
wtpliwoci co do samego sformuowania
kryterium.
Tak, awaria systemu to bd
Pracowaem kiedy w projekcie, gdzie test konfiguracyjny aplikacji
multimedialnej zosta przekazany wyspecjalizowanej firmie. Nie bya to
najlepsza firma, ale jedyna dostpna w tym momencie. eby mie
pewno e wszystko zostanie wykonane zgodnie z zasadami sztuki,
przekazano testujcej firmie specyfikacje grup zada testowych,
specyfikacje zada testowych i procedury testowe - w ten sposb nie
powinno byo by adnych wtpliwoci, co zostao, a co nie zostao
przetestowane.
Mino kilka tygodni i wszystko zdawao si przebiega gadko - zbyt
gadko - kiedy pewnego dnia zatalefonowa kierownik zespou
testujcego. Zoy raport na temat tego, co znaleziono w cigu tygodnia nie byo tego wiele - i tu przed odoeniem suchawki zapyta, czy ma
rwnie raportowa bdy nie uwzgldnione w dokumentacji. Okazao si,
e od pierwszego dnia jego testerzy od czasu do czasu spotykali si z tymi
duymi, biaymi komunikatami mwicymi co na temat bdu ochrony
pamici. Komunikaty te lekcewaono, ale po jakim czasie ekran
komputera stawa si jaskrawoniebieski z kolejnym niezrozumiaym
meldunkiem o bdzie, co ju wymagao ponownego wystartowania
maszyny. Poniewa taki bd nie by wymieniony jako kryterium
niepowodzenia zadania testowego, kierownik zespou nie by pewien, czy
byo to wane i postanowi si upewni1.
Zadania testowe
W rozdziaach od 4-ego do 7-ego opisane zostay podstway testowania
oprogramowania - analizowanie specyfikacji, kodu rdowego i caej
aplikacji po to, by mc wygenerowa minimaln ilo zada testowych,
ktre umoliwiaj skuteczne przetestowanie tego oprogramowania. Nie
omawiano jednak kwestii, jak najlepiej opisa i udokumentowa wybrane
zadania testowe. Kto zajmowa si ju testowaniem, zetkn si
przypuszczalnie z rozmaitytmi sposobami i formatami zapisu. Ta cz
ksiki pozwoli zpozna si bliej z rnymi moliwoiami.
1
Sarkazm autora jest troch nie na miejscu - to, e tester czy automatyczny program testujcy
zignoruje nieprzewidziane skutki uboczne zadania testowego, jest zjawiskiem czsto spotykanym.
Zapobieganiu mu suy zesp technik testowania zwany analiz dynamiczn (przyp. tumacza).
Strona 34 (84)
ANSI/IEEE 829 definiuje, e specyfikacja zada testowych dokumentuje
faktyczne wartoci uyte jako dane wejciowe wraz z oczekiwanymi
wartociami danych wyjciowych. Opis zadania testowego okrela take
ograniczenia dotyczce procedury testowej wynikajce z zastosowania tego
wanie zadania testowego.
Szczegy opisu zadania testowego powinny wic wyjania dokadnie,
jakie wartoci lub warunki wprowadzane s do testowanego
oprogramowania i jakiego naley spodziewa si wyniku1. Standard
ANSI/IEEE 829 wylicza take niektre inne wane pozycje, ktre powinny
si w tym opisie znale:
40. Identyfikatory. Jednoznaczny identyfikator, do
ktrego odnoniki znajduj si zarwno w
specyfikacji grup zada testowych, jak i w
specyfikacji procedur testowych.
41. Przedmiot testu. Opisana tu jest w szczegach
funkcja, modu, czy inny przedmiot testu. Ten
opis jest dokadniejszy ni w listach funkcji
znajdujcych si w specyfikacji grup zada
testowych. Gdy na przykd specyfikacja grupy
zada testowych okrelia testowan funkcj
jako dodawanie na Kalkulatorze, to
specyfikacja zadania testowego okreli na
przykad test grnej granicy w procedurze
obsugi przepenienia. Powinny si tutaj te
znale odnoniki do specyfikacji produktu lub
innych specyfikacji, na podstawie ktrej
stworzone zostao to zadanie testowe.
42. Specyfikacja danych wejciowych2. Okrela
si tu wszelkie dane wejciowe i inne warunki
zapocztkowujce wykonanie zadania
testowego. Jeli testuje si Kalkulator, te dane
mog by tak proste jak na przykad 1+1. Kiedy
testuje si oprogramowanie centrali do telefonii
komrkowej, ma si do czynienia z setkami i
tysicami warunkw wejciowych. Kiedy testuje
si aplikacj do obsugi plikw, danymi
wejciowymi mog byc np. nazwa pliku oraz
jego zawarto.
Autor bez wtpienia si tu bez wszelkiej potrzeby powtarza - tumacz prosi o wybaczenia, ale taki jest
czsto styl amaerykaskich ksiek
2
Autor zdaje si - przypuszczalnie dla uproszczenia - utosamia dane wejciowe z czynnociami

uruchamiajcymi zadanie testowe, za dane wyjciowe - z wynikiem zadania testowego. Tak jest
bardzo czsto, ale na pewno nie zawsze: na przykad wynikiem zadania testowego moe by zmiana
stanu programu, zmiana danych w rejestrze lub bazie danych, a nawet to, e adna dajca si
zaobserwowa zmiana nie nastpuje! (przyp. tumacza).
Strona 35 (84)
43. Specyfikacja danych wyjciowych. Jest to opis
oczekiwanyego wyniku wykonania zadania
testowego. Czy 1+1 dao wynik rwny 2? Czy
tysice danych wyjciowych otrzymao
prawidowe wartoci w aplikacji obsugi
centrali? Czy zawarto pliku zostaa
prawidowo zaadowana?
44. Definicja wymaga rodowiska. Wymagania
rodowiska to sprzt, oprogramowanie,
narzdzia do testowania, warunki, personel itd.
potrzebne do wykonannia zadania testowego.
45. Szczeglne wymagania proceduralne. Tutaj
opisuje si wszystkie odbiegajce od normy
wymagania, ktre musz by spenione, aby
mc wykona zadanie testowe. Testowanie
programu WordPad pewnie niczego takiego nie
wymaga, ale testowanie elektrowni atomowej przypuszczalnie tak.
46. Zalenoci pomidzy zadaniami testowymi. W
rozdziale 1-ym Podstawy Testowania
znajdowa si opis bdu, ktry spowodowa
katastrof ldownika NASA na Marsie. Jest to
doskonay przykad nieudokumentowanej
zalenoci midzy zadaniami testowymi. Jeli
jedno zadanie zaley od drugiego albo moe
podlega wpywom jeszcze innego zadania
testowego, t informacj naley tutaj umieci.
Czy ju wpadamy w panik? Jeli cile przestrzega opisanych tu zasad
dokumentowania zada testowych, to trzeba by byo pisa co najmniej
stron tekstu do kadego zadania testowego! Tysice zada testowych
wymagayby tysicy stron specyfikacji. Projekt byby opniony zanim
jeszcze skoczyoby si j pisa.
Oto jeszcze jeden powd, dla ktrego standard ANSI/IEEE 829 naley
traktowa jako wskazwk raczej ni przestrzega go w 100 procentach - o
ile si nie musi. Wielel projektw rzdowych i niektre gazie przemysu
musz dokumentowa zadania testowe a w tym stopniu, ale zwykle mona
sobie pozwoli na uproszczenia.
Uproszczenia i skrty nie maj oznacza, e odrzuca si lub pomija istotn
informacj, a jedynie e usiuje si znale bardziej skuteczne metody
przekazywania tej informacji. Na przykad, nie istnieje aden powd, eby
ogranicza si do specyfikowania zada testowych w formie opiosowej.
Rysunek 17.2 pokazuje przykad macierzy do testowania kompatybilnoci
drukarki.
Strona 36 (84)
Identyfikator
zadania
testowego
Producent
drukarki
Model
Tryb pracy
Opcje
Strona 37 (84)
Czarno-biay
Tekst
Superfoto
Kolorowy
Automatyczny
Roboczy
Wysoka
rozdzielczo
Tekstowy
rednia
rozdzielczo
Niska
rozdzielczo
Strona 38 (84)
Rysunek 17.2 Zadania testowe czsto mona opisa przy pomocy maacierzy
lub tabeli.
Kada linia macierzy jest zadaniem testowym majcym wasny
identyfikator. Pozostaa informacja - przedmiot testu, specyfikacja danych
wejciowych, specyfikacja danych wyjciowych, wymagania rodowiska,
specjalne wymagania i zalenoci - jest przypuszczalnie jednakowa dla
wszystkich wymienionych zada i moe by opisana dla nich wsplnie
gdzie indziej. Dokonujc przygldu specyfikacji mona najpierw
przeczyta i skontrolowa t wspln informacj, a nastpnie atwo
przejrze tabel pod ktem pokrycia testowego.
Inne moiwe sposoby opisywania zada testowych to listy albo nawet
diagramy graficzne takie jak diagram stanw programu albo diagram
przepywu danych. Chodzi o to, by przekaza komu innemu opis zadania
testowego i wybiera si najskuteczniejszy sposb. Warto by pomysowym i
twrczym, pamitajc jednak, e gwnym celem jest udokumentowanie
zada testowych.
Procedury testowe
Udokumentowawszy grupy zada testowych i zadania testowe, pozostaje
jeszcze opisanie procedur, wedug ktrych zadania testowe bd
wykonywane. ANSI/IEEE 829 stwierdza, e specyfikacja procedur
testowych identyfikuje wszystkie kroki niezbdne do sterowania systemem
i wykonania okrelonych zada testowych w celu urzeczywistnienia grupy
zada testowych.
Procedura tesotwa albo skrypt testowy definiuje kroki okrelajce w
szczegach jak wykona zadanie testowe. Oto znajdujca si w niej
informacja:
47. Identyfikator. Unikalny identyfikator, czcy
procedur z odpowiednim zadaniem testowym i
z grup zada testowych.
48. Cel. Cel procedury i odnoniki do zada
testowych, ktre realizuje.
49. Specjalne wymagania. Inne procedury,
specjalne umiejtnoci testerw, albo specjalny
sprzt potrzebny do wykonania procedury.
50. Kroki procedury. Szczegowy opis jak
wykonywa test:
Log. Opis w jaki sposb bdzie si nagrywa i zapisywa wyniki i
inne obserwacje.
Przygotowanie. Wyjanienie jak przygotowa test.
Start. Wyjania jakie kroki potrzeben s by zacz wykonywanie
testu.
Strona 39 (84)
Procedura. Opis krokw w trakcie wykonywania testu.
Pomiar. Wyjanienie, jak uzyska si wyniki zada - na przykad
przy pomocy stopera albo obserwacji wizualnej.
Zatrzymanie. Wyjanienie, jak czasowo zawiesi wykonywanie
testu.
Ponowny start. Wyjanienie dla testera w jaki sposb ponownioe
podj wykonywanie zadania w okrelonym miejscu, jeli
przyczyn zawieszenia bya awaria lub zawieszenie si caego
systemu.
Zakoczenie. Opisuje kroki jak w kontrolowany sposb
zakoczy test.
Odtworzenie warunkw. Wyjania jak doprowadzi rodowisko
do stanu poprzedzajcego wykonywanie testu.
Nieprzewidziane wypadki. Wyjania co robi, kiedy co dzieje si
niezgodnie z planem.
Nie wystarczy, by procedura testowa brzmiaa na przykad: Prosze
wykona nastpujce zadania testowe i napisa w raporcie co si stao
Byby to proste i atwe do napisania, ale nie mwioby testerowi nic o tym,
jak wykonywa samo testowanie. Taka instrukcja nie byaby powtarzalna i
nie byoby adnego sposobu udowodnienia, ktre kroki zostay w
rzeczywistoci wykonane. Uywajc szczegowej procedury wie si
dokadnie, co i jak bdzie testowane. Rysunek 17.3 pokazuje fragment
fikcyjnego przykadu procedury testowania dla Kalkulatora Windows.
Realistyczny poziom szczegowoci
Stare powiedzenie najlepszy jest zoty rodek stosuje si w zupenoci do
planowania zada testowych. Pamitajmy o czterech podstawowych celach:
organizacji, powtarzalnoci, kontroli i uzyskaniu dowodw. Tester
produkujcy zadania testowe dziaa z grubsza w kierunku osignicia tych
celw, ale ich poziom okrelaj wymagania branowe, przedsiborstwa,
projektu lub nawet zespou. Zwykle tester nie musi dokumentowa swoich
zada testowych na bardzo szczegowym poziomie, ale te wzgldnie
rzadko lduje si w baaganiarskim projekcie, gdzie w ogle niczego nie
trzeba dokumentowa. Zwykle praca testera znajduje si gdzie midzy tymi
dwiema wartociami brzegowymi.
Sztuk jest utrafi we waciwy poziom. Przypatrzmy si procedurze
pokazanej na rysunku 17.3, ktra wymaga, e na PC musi by zainstalowany
system Windows 98. Procedura wprawdzie stwierdza w czci wstpnej, e
potrzebne jest Windows 98, ale nie precyzuje jaka wersja. Co si stanie za
rok lub dwa, kiedy pojawi si kolejna wersja Windows 98? Czy procedur
trzeba bdzie zmieni, by uwzgldni t zmian? Aby unikn tego kopotu,
mona pomin numer wersji i uy okrelenia najnowsza, ale co pocz,
gdy nowa wersja pojawi si w trakcie cyklu produkcyjnego? Czy naley
wwczas zmieni uywan do testowania wersj w trakcie projektu?
Strona 40 (84)
Identyfikator: WinCalcProc98. 1872
Cel: procedura opisuje kroki, ktre naley wykona aby uruchomi
zadania testowe funkcji Dodawanie, od numeru WinCalc98.0051 do
WinCalc98.0185.
Specjalne wymagania: Nie jest potrzebny aden sprzt ani
oprogramowanie prcz tego, ktre okreone jest w opisie samych
zada testowych.
Kroki procedury:
Log: Tester posuy si aplikacj WordPad z szablonem
Testowanie do notowania przebiegu wykonania procedury.
Wszystkie pola zaznaczone jako obowizkowe musz by
wypenione. System do rejestracji i ledzenia bdw Mantis
suy do rejestracji wszelkich problemw, ktre zaistniej w
trakcie wykonywania procedury.
Ustawienie: Tester musi zainstalowa czyst kopi Windows
98 na swojej maszynie przed wykonaniem procedury. Przed
zainstalowaniem najnowszej wersji Windows 98 naley
posuy si aplikacjami WipeDisk i Clone. Wicej wiadomoci
na temakt posugiwania si tymi narzdziami mona znale w
dokumencie Zaczynajc od nowa.
Start:
Wystartowa Windows 98
Klikn przycisk Start
Wybra Programy
Wybra Akcesoria
Wybra Kalkulator.
Procedura: Dla kadego z podanych wyej zada testowych,
naley wprowadzi dane przy uyciu klawaitury (nie klawiszy
numerycznyych widocznych na ekranie) i prowna wynik z
oczekiwanym.
Pomiar:
Rysunek 17.3 Przykad (fikcyjny) procedury testowej pokazuje ilo
szczegw, ktre trzeba uwzgldni.
Strona 41 (84)
Inna kwestia to zalecenie procedury, aby zainstalowa czyst kopi
Windows 98. Co to oznacza? Procedura wymienia kilka narzdzi, WipeDisk
i Clone, ktrymi naley posuy si w trakcie czynnoci poprzedzajcych
test, i odsya testera do innego dokumentu po wyjanienia jak si nimi
posuy. Czy kroki procedury nie powinny by bardziej szczegowe i
wyjani, gdzie dokadnie znajduje si ten dokument i te narzdzia? Kto
kiedykolwiek instalowa system operacyjny, wie rwnie, e jest to
skomplikowany proces i e instalator musi odpowiedzie na wiele pyta i
wybra wiele moliwych opcji. Czy ta albo inna procedura testowa powinna
wchodzi w tego typu szczegy? Jeli nie, to skd bdzie mona wiedzie,
na jakiej dokadnie konfiguracji wykonano testy. Jeli tak, a proces instalacji
kiedy ulegnie zmianie, moe to oznacza konieczno poprawienia stetek
innych procedur testowych. Co za zamieszanie!
Niestety nie istnieje jedna, poprawna odpowied. Bardzo szczegowe
specyfikacje testw redukuj niejednoznaczno, powoduj e zadania
testowe s powtarzalne i pozwalaj dowiadczonym testerom wykonywa je
dokadnie zgodnie z opisem. Z drugiej strony, tak dokadny opis wymaga
czasu i wysiku, utrudnia zmiany oraz - z przyczyny tej caej masy
szczegw - hamuje testowanie, powodujc e wymaga ono wicej czasu.
Pisza zadania testowe najlepiej dostosowa si do standardw projektu, w
ktrym si pracuje. Testujc nowy sprzt medyczny, bdzie si
przypuszczalnie pisa o wiele bardziej szczegowe procedury ni przy
testowaniu nowych gier komputerowych. Jeli ma si za zadanie ustalenie
metodyki i rekomendacji sposobu opisywania grup zada testowych, zada
testowych i procedur testowych dla nowego projektu, najlepiej wzi pod
uwag formaty zdefiniowane przez ANSI/IEEE 829, wyprbowa kilka
przykadw i stwierdzi, co najlepiej pasuje do zespou i do wymaga
projektu.
Organizacja i zarzdzanie zadaniami testowymi

Piszc dokumentacj trzeba bra pod uwag, w jaki sposb informacja jest
zorganizowana i jak bdzie j mona znajdowa. Oto przykady pyta na
ktre tester - albo zesp tesowy - powinien umie odpowiedzie:
51. Ktre zadania testowe bd wykonane?
52. Ile zada planuje si wykona? Ile czasu to
zajmie?
53. Czy jest si w stanie wybra grupy zada
testowych dostosowane do testowania wybranej
funkcji albo czci systemu?
54. Czy bdzie si w stanie zanotowa, ktre
zadania zostay zaliczone, a ktre nie, podczas
ich wykonywania?
Strona 42 (84)
55. Spord zada ktre nie zostay zaliczone, ile
nie zostao zaliczonych rwnie podczas
wczeniejszych prb?
56. Jaki procent zada testowych zostao
zaliczonych poprzednim razem?
To s przykady wanych pyta, ktre czsto spotyka sie w trakcie typowego
projektu. W rozdziale 19-ym Pomiar sukcesu zajmiemy si zbieraniem
danych i statystki dokadniej, ale w tej chwili uznajmy po prostu e
potrzebny jest jaki proces pozwalajcy na kontrol zada testowych i
rejestracj ich wynikw. Istniej cztery opdstwaowe typy systemw:
57. W gowie. Nie powinno si tego nawet bra pod
uwag nawet w najprostszych projektach, chyba
e testuje si oprogramowanie do wasnego
prywatnego uytku i nie ma sie adnego powodu
dokadnego ledzenia przebiegu testowania.
58. Papier/dokumenty. W maych projektach
moliwe jest zarzdzanie zadaniami testowymi
wycznie na papierze. Suyy do tego
niejednokrotnie zupenie dobrze tabele i listy
kontrolne. Jest to oczywicie metoda saba z
punktu widzenia organizowania i poszukiwania
danych, ale ma jedn cech dodatni: lista
kontrolna na papierze zawiera zwykle sygnatur
albo podpis testera, co w razie potrzeby stanowi
doskonay dowd w sdzie, e testy faktycznie
zostay wykonane.
59. Arkusz kalkulacyjny. Popularn i bardzo
dobrze dziaajc metod organizowania zada
testowych jest umieszczenie ich w arkuszu
kalkulacyjnym. Na rysunku 17.4 znajduje si
przykad zastosowania tej metody. Dzieki temu,
e wszystkie dane na temat zada testowych
zgromadzone sa w jednym miejscu, arkusz
kalkulacyjny pozwala na skuteczn i szybka
ocen statusu testowania. atwo sie go uywa,
wzgldnie atwo konstruuje, a przede wszystkim
przy jego pomocy mona zupenie dobrze
organizowa i kontrolowa zadania testowe oraz
rejestrowa ich wyniki.
Strona 43 (84)
Rysunak 17.4 Do organizacji i zarzdzania zadaniami testowymi mona

uywa arkuszy kalkulacyjnych.
60. Baza danych. Najlepsza metod organizacji
zada testowych jest baza danych
skonstruowana specjalnie pod tym ktem. Wiele
dostpnych na rynku narzdzi jest
skonfigurowanych wanie pod w ten sposb.
Korzystajc z docze opisanych w rozdziale
21-ym Kariera dla testera, mona zapozna si
z wieloma takimi narzdziami i z
rekomnedacjami od innych testerw. Kto chce
zbudowa wasny system, moe z twoci
posuy si narzdziami takimi jak Claris
FileMaker Pro, Microsoft Acees, i wiel innych,
pozwalajcymi niemal bez programowania tylko przy uyciu myszki - w cigu kilku godzin
stworzy baz danych dopasowan do formatu
dokumentacji ANSI/IEEE 829. Posugujc si
wbudowanymi w baz danych metodami
wyszukiwania rnych kombinachji danych, jest
si w stanie bezzwocznie odpowiedzie na
prawie kade niemal moliwe pytanie dotyczce
zada testowych i przebiegu testowania.
Trzeba zdawa sobie spraw, e zada testowych mog by tysice i bez
sposobu kontrolowania ich mona bardzo atwo uton w morzu
dokumentacji. Trzeba znale metod na to, by jednym rzutem oka mc
uzyska odpowied na pytanie: Co bdziemy testowali jutro, ile zada
testowych trzeba bdzie wykona?
Podsumowanie
Pora ju na to, by ponownie przypomnie cztery podstawowe powody, dla
ktrych konieczne jest staranne planowanie zada testowych: organizacja,
powtarzalno, kontrola i dowody wykonania. Nigdy do powtarzania tych
zasad, bo dowiadczenia poucza, e czsto zaniedbuje si bardzo istotna
cz pracy testera: szczegowe dokumentowanie tego, co si zrobio.
Strona 44 (84)
Nikt nie chciaby prowadzi samochodu, ktry zosta zaprojektowany przez
zesp konstruktorski na odwrocie serwetki, ani mieszka koo elektrowni
atomowej, gdzie programy kontrolne testowa zesp posugujcy si
wycznie metodami ad hoc. Chce si, by inynierowie odpowiedzialni za
jako tych systemw posugiwali si dobrymi praktykami inynierskimi i
tak dokumentowali sw prac, by dao si stwierdzi, czy to co zbudowano
zgodne jest z pierwotnymi planami.
Pocztkujcy tester zwykle nie ma wpywu na to, jakie metody planowania i
dokumentacji stosuje projekt, ale moe si stara wykonywa swoj prac
jak najskuteczniej. Trzeba odrnia rzeczy konieczne od zbdznych, bada
jak mona by usprawni proces i nigdy nie i na atwizn. Na tym polega
rnica midzy profesjonalizmem a hakerstwem.
Ten rozdzia i rozdzia 16-y opisuje planowanie i dokumentacj tego, co
zamierza si przetestowa. Nastpne dwa rozdziay zajm si tym, jak
dokumentowa uzyskane wyniki testw i w jaki sposb powiedzie innym,
e znalazo si bd.
Pytania
1.Jakie s cztery powody, aby planowa zadania testowe?
2.Co to jest test metodami ad hoc?
3.Czemu suy specyfikacja grup zada testowych?
4.Co to jest specyfikacja zada testowych?
5.Jakich innych metod - oprcz tradycyjnej formy pisemmnego dokumentu
- mona uywa do opisu zada testowcyh?
6.Po co jest specyfikacja procedur testowych?
7.Jak szczegowa powinna by procedura testowa?
Strona 45 (84)
Rozdzia 18 Raportowanie wynikw

W TYM ROZDZIALE
Co zrobi, eby bdy byy naprawiane
Izolowanie i odtwarzanie bdw
Bd bdowi nierwny
Cykl yciowy bdu
Systemy ledzenia bdw
Patrzc na testowanie z oddalenia, dostrzec mona w najszerszym zarysie
trzy gwne zadania: planowanie testw, samo testowanie oraz temat tego
rozdziau - raportowanie wynikw.
Na pierwszy rzut oka moe si wydawa, e raportowanie odkrytych
problemw jest najatwiejsze z tych trzech zada. W porwnaniu z iloci
pracy konieczn do planowania i z umiejtnociami niezbdnymi, by
skutecznie znajdowa bdy, opowiedzenie innym e znalazo si bd
powinno przecie by prostsze i nmiej czasochonne. W rzeczywistoci, jest
to najwaniejsze - i czasami najtrudniejsze - z zda jakie stoj przed
testerem.
61. Czmu bdy nie zawsze zostaja naprawione
62. Co mona zrobi, by zwikszy szans
naprawienia bdw
63. Jakimi metodami izolowa i ponownie
wywoywa znalezione bdy
64. Jak przyebiega ycie bdu - od jego narodzin a
do mierci
65. Jak ledzi i kontrolowa bdy rcznie lub przy
pomocy bazy danych
May Kurczak ma kopot
May Kurczak by pewnego razu w lesie, kiedy na gowe spad mu od.
Tak go to przerazio, e cay zadra. Trzs si tak, e a zgubi poow
pir.
Pomocy, pomocy! Niebo si wali! Musze pobiec powiedzie krlowi! zawoa May Kurczak.
Strona 46 (84)
I kurczak pobieg w wielkim strachu opowiedzie krlowi. PO drodze
spotka Henny Penny.
Dokd idziesz, May Kurczaku? - spyta Henny Penny.
Och, pomocy! Niebo si wali! - odpowidzia May Kurczak.
Skd wiesz? - zapyta Henny Penny.
Widziaem to na wasne oczy, syszaem to na wasne uszy, a cz nieba
spada mi na gow! - odpowiedzia May Kurczak.
To straszne, po prostu straszne! Lepiej popieszmy si! - zawoa
Henny Penny. I obaj pobiegli jak najszybciej tylko umieli.
W tej popularnej dziecinnej bajeczce, May Kurczak wpada w szok, kiedy
staje si co nieoczekiwanego i ucieka w panice, woajc na cay wiat, co
mu si wydaje. Pomulmy, jak May Kurczak zachowaby si znalazszy
bd oprogramowania! Jak zareagowaby na to kierwonik projektu albo
programista? Jest wiele interesujcych podobiestw midzy t historyjk a
testowaniem oprogramowania - warto mie j w pamici czytajc ten
rozdzia.
Co zrobi, eby bdy byy naprawiane

Dawno temu w rozdziale 3-im Test oprogramowania w rzeczywistoci
dowiedzielimy si, e mimo wszelkich stara podczas planowania i
wykonywania testw, nie wszystkie znalezione bdy1 zostan naprawione.
Niektre zostan cakowicie odrzucone, inne mog by odroczone z
zamiarem naprawienia ich dopiero w kolejnej wersji oprogramowania. Z
pocztku taka moliwoc wydawaa si nieco zniechcajca czy wrcz
grona. Tearz, wiedzc ju o wiele wicej na temat testowania,
przypusczalnie atwiej nam zrozumie, czemu w rzeczywistoci nie
wszystkie bdy s naprawiane.
Oto wymienione w rozdziale 3-im powody, dla ktrych nie wszystkie bdy
zostaj naprawiane:
66. Brakuje czasu. W kadym porjekcie zawsze
jest zbyt wiele funkcji, zbyt mao zaogi i nie
doc czasu w harmonogramie. Jeli pracuje si
nad programem do deklaracji podatkowych, data
skadanie deklaracji si nie zmieni - program
musi by gotowy w terminie.
Tutaj przydaoby si rozrnienie midzy "awari" (dajcym si zaobserwowa nieprawidowym

dziaaniem programu) oraz "bdem" (przyczyn tej nieprawidowoci), by uczyni wywd
janiejszym. Autor jednak konskwentnie uywa tego samego sowa "bug" na okrelenie raz przyczyny
bdu, a raz - jego objaww.
Strona 47 (84)
67. To nie jest naprawd bd. Znane jest
powiedzonko To nie bd, to funkcja! Czste
s nieporozumienia, bdy w testownaniu lub
zmiany specyfikacji powodujce, e pozorne
bdy zostaj zaklasyfikowane jako podane
funkcje.
68. Za due ryzyko naprawy. Niestety, tak czsto
jest. Oprogramowanie jest delikatne, spltane,
czasem jak makaron nitki. Mona wtedy
naprawiajc jeden bd obudzi inne,
wczeniej ulryte bdy. Pod naciskiem wymaga
wypuszcznia programu miomo przykrtkiego
harmonogramu, jakiekolwiek zmiany mog by
zbyt ryzykowne. Lepiej moe by zostawi w
spokoju ju znany bd, ni ryzykowa
pojawienie si nowych, nieznanaych.
69. Po prostu nie warto. To moe brzmi brutalnie,
ale taka jest rzeczywisto. Bdy ktre
wystpuj niezbyt czsto albo w rzadko
uywanych funkcjach mona pomin. Bdy
dla ktrych istniej obejcia, czyli metody jak je
omija, czsto uznaje si za niewarte naprawy.
Rzecz sprowadza si do decyzji biznesowej w
oparciu o przewidywane ryzyko.
Do tej listy warto doda jeszcze jedn pozycj, ktra moe by dodatkwym
powodem pojawienia si tych wczeniejszych:
70. Bdy s nieskutecznie raportowane. Tester
nie sporzdzi dostatecznie silnej argumentacji,
dlaczego dany bd powinien zosta naprawiony.
Skutkiem tego bd zosta mylnie oceniony jako
nie-bd, uznano e nie jest dostatecznie wany
aby opnia produkt, zbyt ryzykowny do
naprawy, albo po prostu nie wart wysiku.
Tak jak to byo z Maym Kurczakiem, bieganie i krzyki, e niebo si wali
nie jest zwykle skuteczn metod komunikowania problemu - o ile
oczywicie niebo nie wali si naprawd. Wikszo znajdowanych bdw
nie bdzie a tak dramatycznych. Trzeba bdzie tylko zwile i treciwie
powiadomi o swoim znalezisku zesp zajmujcy si podejmowaniem
decyzji w tych sprawach, tak eby mia do dyspozycji potrzebn do decyzji
informacj.
Poniewa istnieje wiele rnych modeli wytwarzania oprogramowania i
rne typy dynamiki grupowej, nie da si z gry jednoznacznie opisa, jak
bdzie przebiega w danym zespole lub projekcie proces podejmowania
decyzji, czy bd ma by naprawiony, czy nie. Czsto decyzja naley
wycznie do kierownika projektu, czasem do programisty, czasem
podejmuje j specjalnie dobrany zesp.
Strona 48 (84)
Jadnak zawsze jedna lub kilka osb dokonuje przegldu bdu, ktrego
dotyczy zoony raport, i podejmuje decyzj co dalej. Ta decyzja jest
podejmowana przynajmniej czciowo w oparciu o informacj
dostarczon przez testera w raporcie bdu.
Nie trzeba by prawnikiem albo byym przewodniczcym grupy
dyskusyjnej, aby domyle si, jak naley przekonywa innych, by bd
zosta naprawiony. Wystarczy w znacznym stopniu zdrowy rozsdek i
podstawowe umiejtnoci komunikacyjne. W dalszej czci rozdziau
zapoznamy si z rnymi systemami zapisywania i ledzenia raportw o
bdach, ale na razie wemiemy pod uwag klika oglnych, podstawowych
zasad.
71. Raportowa bdy jak najszybciej. Mwilimy
ju o tym wczesniej, ale tych powtrze nigdy
nie jest zbyt wiele. Im wczeniej znajdzie si
bd, tym wicej czasu pozostaje w
harmonogramie na jego napraw. Wyobramy
sobie, e zawstydzajcy bd ortograficzny
zostaje znaleziony w tekcie pomocniczym na
kilka miesicy przed wypuszczeniem programu.
Jest wwczas bardzo prawdopodobne, e bd
zostanie naprawiony. Ten sam bd znaleziony
kilka godzin przed dostaw, zapewne
naprawiony nie bdzie. Rysunek 18.1 ilustruje
zaleno midzy czasem a napraw bdw na
wykresie.
Powany bd
Prawdopodobiestwo
naprawy
Mniejszy bad
Pocztek projektu
Rysunek 18.1 Im poniej bd zostanie znaleziony, tym mniejsze

prawdopodobiestwo, e zostanie naprawiony, zwaszcza jeli chodzi o miej
powane bdy.
Czas
Strona 49 (84)
Moe sie to wydawa dziwne - bd jest wci tym samym bdem
niezalenie od tego czy znale go dzisiaj, czy za trzy miesice. W
doskonaym wiecie nie miaoby znaczenia, kiedy bd zostaje
znaleziony, tylko co to jest za bd. Jednak w rzeczywistoci ryzyko
zwizane z naprawianiem bdu wzrasta wraz z upywem czasu i ten
fakt ma rosnce znaczenia w trakcie podejmownaia decyzji.
72. Opisywa bdy skutecznie. Wyobramy sobie,
e jest si programist i otrzymuje od testera
nastpujcy raport o bdzie: Kiedy tylko
wstukam mas przypadkowych znakw w okno
wlogowujce, oprogramowanie zaczyna
wyrabia dziwne rzeczy. W jaki sposb mona
choby zacz szuka przyczyny bdu nie
wiedzc co to za przypadkowe znaki, jak wielka
ilo wywouje ten efekt, i jakie dziwne rzeczy
si zdarzay?
Skuteczny opis bdu
Dobrze napisany raport o bdzie ma nastujce cechy:
Jest jak najkrtszy. Opisuje wycznie fakty i szczegy konieczne

do zademonstrowania i opisu bdu. Okrelenie masa przypadkowych
znakw nie jest jak najkrtsze. Naley poda dokadn sekwencj
krokw, ktre wywouj problem. Jeli bd wywouj rozmaite zbiory
czynnowci i danych wejciowych, podaje si kilka przykadw,
zwaszcza jeli zawieraj jak regularno czy inna wskazwk, ktra
mo uatwi programicie lokalizacj przyczyny bdu. Pisze si
zwile i na temat.
Jest pojedynczy. Raport bdu powinien opisywa tylko jeden bd.

To brzymi jak co oczywistego, ale czasami nieatwo jest odrni od
siebie kilka bdw o podobnych objawach i w popiechu wrzuca si
je wszystkie do jednego worka. Kopot, jaki zwykle wynika z
opisywania kilku rnych bdw w jednym raporcie jest taki, e
zwykle tylko pierwszy z tych bdw zostaje naprawiony - pozostale
s zapomniane lub zignorowane. Poza tym niemoliwe jest ledzenie
statusu kilku rnych bdw jeli opisuje je wsplny raport (wicej o
tym piszemy poniej).
Strona 50 (84)
atwo powiedzie, e bdy naley meldowa pojedynczo i nie czy
razem w jednym raporcie, ale w rzeczywistoci nie jest to zawsze takie
atwe. Przyjrzyjmy si nastpujcemu raportowi: Nastpujce pi sw
ma bdy literowe w pliku pomocy interakcyjnej To, oczywicie,
trzeba podzieli na pi osobnych raportw. Ale jak potraktowa Dialog
wlogowania nie przyjmuje hase ani tosamoci uytkownika
zawierajcych due litery? Czy to jeden, czy dwa rne bdy? Z punktu
widzenia uytkownika wyglda to jak dwa bdy, jeden dotyczcy hasa i
drugi dotyczcy tosamoci uytkownika. Jednak na poziomie kodu moe
to by tylko jeden bd, gdzie programista zapomnia uwzgldni due
litery.
Zalecenie: kiedy ma si wtpliwoci, lepiej rozdzieli bdy na dwa rne
raporty ni je czy. Tester poszukuje objaww, nie przyczyn bdu.
Wiele bdw moe mie wspln przyczyn, ale nie wie si tego dopki
bd nie zostanie naprawiony1. Lepiej popeni bd stwarzajc omykowo
dwa raporty tam, gdzie wystarczyby jeden, ni opni albo, co gorsza,
spowodowa e bd nie zostanie w ogle naprawiony z powodu
wrzucenia kilku bdw do jednego worka.
Jest oczywisty i oglny. Bd opisany nadmiernie szczegowo, przy

pomocy wielu zawiych krokw niezbdnych do wywoania jakiego
jednego specjalnego przypadku bdu nie skania naprawiania go w
tym samym stopniu co bd opisany w kilku prostych, atwych do
wykonania instrukcjach pokazujcych, na ile jest on oglny i atwo
dostrzegalny przez uytkownika.
Raczej dopki bd nie zostanie znaleziony, niekoniecznie "naprawiony". Po raz ktry z rzdu
wywody byyby o wiele jeniejsze, gdyby stosowa inne okrelenie na objawy bdu (np. "awaria") i na
jego przyczyny (np. "bd" lub "usterka"). Przyp. tumacza.
Strona 51 (84)
Raportowanie bdw znalezionych przez narzdzia do automatycznego
testowania jest przykadem takiej sytuacji. Automatyczny program mg
dziaa przez wiele godzin zanim bd zosta znaleziony. Kierownik
projektu podejmujcy decyzj dotyczc tego, co zrobi z bdem, moe
si zawaha, czy warto naprawia bd, kty wymaga wielogodzinnego
walenia w klawiatur, zanim si ujawni. Jeli jednak powici chwil
analizie wynikw testu, moe si okaza, e nie potrzeba wcale wielu
godzin - wystarczy kilka powszechnie stosowanych uderze w klawisze.
Ten proces nazywa si izolowaniem bdu. Automayczny program po
prostu przypadkiem trafi na t sekwencj klawiszy. Jeli chce si, aby
bd zosta potraktowany z uwag, na jak zasuguje, trzeba w raporcie
opisa tych wanie kilka magicznych uderze w klawisze, a nie tysice
wykonanych przez automatyczny program zanim dotar on do miejsca
pojawienia si bdu.
Daje si odtworzy. Aby raport bdu zosta potraktowany powanie,

opisany bd musi da si odtworzy - wykonanie okrelonego cigu
czynnoci spowoduje, e oprogramowanie osignie ten sam stan co
porzednio i bd pojawi si ponownie. Jedn z trudniejszych, ale
satysfakcjonujcych czynnoci w testowaniu s prby wyizolowania i
odtworzenia tych pozornie losowych zachowa oprogramowania niezrozumiaych zawiesze si, przypadkowego zniszczenia danych
przez program i tak dalej1. W dalszej czci rozdziau poznamy kilka
sposobw jak to osign. Kiedy wiadomo ju, jak odtworzy bd
przy pomocy jednoznacznej serii czynnoci, pora napisa raport
meldujcy o istnieniu tego bdu2.
73. Opisywa bdy nikogo nie oskarajc.
Nietrudno, by midzy programistami i testerami
powstay antagonizmy. Kto zapomnia,
dlaczego, niech przeczyta ponownie rozdzia 3ci. Programici i cay zesp wytwarzajcy
system moe traktowa raporty o bdach jako
raporty o caej ich pracy, dlatego raporty bdw
naley pisa stylem bezosobowym,
dyplomatycznie i powstrzymujc si od
wydawania osdw. Raport bdw mwicy
Kod twojego sterownika drukarki jest okropny,
po prostu nie dziaa. Nie wierz, e omielie
si przekaza go do testowania jest
niestosowny. Raporty bdw powinno si pisa
przeciwko bdom, a nie osobom3, i
ogranicza si do opisu samych faktw. Nie
naley si chwali, nie naley si wywysza,
nie naley oskara. Licz si takt i dyplomacja.
Szczeglnie trudne staje si to w odniesieniu do programw czasu rzeczywistego - tam potrzebne s

specjalne techniki szukania bdw, ktrcyh wystpienie moe zalee od skomplikowanego splotu
zmiennych czasowych (przyp. tumacza).
Strona 52 (84)
74. ledzi dalsze losy zoonego raportu. Jest
jedna rzecz gorsza ni nie znale bdu: znale
bd, napisa raport, a potem o nim zapomie
lub go zgubi1. Wiemy ju e testowaniae
oprogramowania to cika praca, nie pozwlmy
wic by jej owoce - znalezione przez nas bdy zostay zmarnowane. Od momentu znalezienia
bdu na testerze spoczywa odpowiedzialno,
by zameldowa o jego istnieniu i dopatrze, by
powicono mu konieczn uwag. Dobry tester
znajduje wiele bdw. Wielki tester znajduje
wiele bdw i ledzi ich dalsze losy a do
momentu, gdy zostan naprawione. Nauczymy
si wicej na ten temat w dalszej czci tego
rozdziau.
Te zasady - wczesne raportowanie bdw, skuteczne metody ich
opisywania, uywanie nieantagonizujcych sformuowa, ledzenie
dalszych losw raportw - s zgodne z zasadami zdrowego rozsdku.
Stosuj si do kadgo zadania wymagajcego midzyludzkiej komunikacji.
Czasami jednak w popiechu nietrudno o nich zapomnie. Jednak dla
testera, ktrey chce skutecznie meldowa znalezione bdy i spowodowa,
by zostay naprawione, stosowanie si do tych zasad jest konieczne.
Izolowanie i odtwarzanie bdw

Nauczylimy si wanie, e aby skutecznie zoy meldunek o znalezionym
bdzie, trzeba go opisa przekonywujco, oglnie i w sposb pozwalajcy
na jego odtworzenie. Wielokrotnie jest to nietrudne. Wyobramy sobie, e
mamy proste zadanie testowe dla programu graficznego, sprawdzajce czy
daje si stosowa wszystkie kolory. Jeli za kadym razem, kiedy wybiera
si kolor czerwony, program rysuje na zielono, jest to oczywisty, oglny i
odtwarzalny bd.
Autor spycha na testerw znaczn cz odpowiedzialnoci za znalezienie przyczyny, a nie tylko

objaww bdu. Oczywicie czsto nie jest to najlepsze rozwizania, a jego cen bywa zwykle utrata
kontroli nad harmonogramem testw i to, e w budet czasowy testowania wpisuje si czynnoci
nalece jednoznacznie do wytwarzania (przyp. tumacza).
3
Osoba bdca pozornie "autorem" danego bdu wcale nie zawsze rzeczywiscie ponosi za niego win:
znacznie czsciej "winny" jest nierealistyczny harmonogram, brak odpowiedniego dowiadczenia, brak
dobrych specyfikacji i wszelki inny baagan organizacyjny i procesowy, ni autentyczne niechlujstwo
programisty (przyp. tumacza).
1
Nie pierwszy to raz autor zdaje si byc zdania, e testerzy ponosz odpowiedzialno za braki
organizacyjne i za to, co bezwzgldnie powinno nalee do obowizkw kierownika projektu, o ile nie
przekae on tej odpowiedzialnoci innym (przyp. tumacza).
Strona 53 (84)
Co jednak pocz, kiedy taki bd pojawia si dopiero po wykonaniu kilku
innych zada testowych, ale nie wystpuje, jeli to samo zadanie testowe
wykona zaraz ponownym wystartowaniu maszyny? Co pocz, kiedy
pojawia si losowo albo tylko w czasie peni ksiyca? Trzeba bdzie wtedy
zabawi si w detektywa.
Izolowanie i odtwarzanie bdw wymaga umiejtnoci detektywistycznych
i prb ograniczenia okolicznoci, w ktrych problem wystpuje. Dobra
wiadomo to fakt, ze losowe bdy nie istniej - jeli odtworzy
dokadnie t sam sytuacj i zastosowa dokadnie te same dane wejciowe,
bd na pewno pojawi si ponownie. Kopot polega na tym, e odtworzenie
dokadnie tego samego stanu i zespou danych wejcia moe by bardzo
trudne i czasochonne. Kiedy odpowied ju si zna, wydaje si oczywista.
Zanim si j znajdzie, zadanie moe wydawa si beznadziejne.
Niektrzy testerzy zdaj si mie wrodzony talent do izolowania i
odtwarzania bdw. Potrafi oni odkry bd i potem szybko
zidentyfikowa dzialania i warunki, w ktrych wystpuje. Dla innych taka
umiejtno pojawia si dopiero wraz z rosncym dowiadczniem, kiedy
znaleli i zameldowali wiele rnych rodzajw bdw1. Kady, kto chce
by dobrym testerem, musi jednak t umiejtno opanowa, tak e warto
wykorzysta kad okazj, by prbowa swoich si w izolowaniu i
odtwarzaniu bdw.
Na pocztek kilka dobrych rad, ktre przydadz si, kiedy znajdzie si bd
wymagajcy bardzo wielu krokw w celu odtworzenia lub nie dajcy si na
pozr odtworzy w ogle. Komu si to przytrafi, niech sprbuje
wykorzysta na pocztek wskazwki z poniszej listy:
75. Niczego nie bra za pewnik. Zapisywa
wszystko co si robi - kady krok, kad
przerw - wszystko. Nietrudno omykowo
opuci lub doda jeden krok. Pomoc moe by
kolega obserwujcy, co robi si w czasie
testowania. Mona posuy si te programem
do nagrywania nacinitych klawiszy oraz
ruchw i klikni myszk. Jeli to konieczne,
mona nawet posuy si kamer wideo do
nagrania swoich czynnoci. Chodzi o to, by
kady krok sta si widoczny i by mona go byo
zanalizowa z innej perspektywy.
Generalnie, umiejtno szybkiego izolowanie przyczyn bdw wymaga dobrej znajomoci

szczegw aplikacji i jej konstrukcji, co powoduje, e skuteczniejsi pod tym wzgldem zawsze
powinni byc programici ni testerzy. Dlatego uparcie twierdz, e izolownie bdw to zadanie raczej
dla programisty ni dla testera! (przyp. tumacza).
Strona 54 (84)
76. Szukajmy sytuacji zalenych od zmiennych
czasowych. Czy bd pojawia si tylko o
okrelonej porze dnia? By moe zaley od tego,
jak szybko wprowadza si dane lub od tego, czy
dane zapisuje si na wolniejsz dyskietk
zamiast na szybszy dysk twardy. Czy sie bya
mocno obciona kiedy zaobserwowao si
bd? Warto wyprbowa to samo zadanie
testowe na szybszym i na wolniejszym sprzcie.
Myle o aspektach czasowych.
77. Bdy spowodowane takimi
szklanoskrzynkowymi okolicznociami jak
warunki brzegowe, przecienie systemu,
przecieki pamici, czy przepenienie zasobw
danych s zwykle trudne do wyizolowania.
Moe si zdarzy, e wykona si zadanie
testowe powodujce zniszczenie fragmentu
danych, ale odkryje si to dopiero znacznie
pniej, kiedy bdzie si z tych danych chciao
skorzysta. Bdy, ktre nie wystpuj po
ponownym wystartowaniu maszyny, tylko
dopiero po jakim czasie, zwykle zaliczaj si
do tej katoegorii. Kiedy tak si dzieje, warto
uwanie przyjrze si wykonywanym wczeniej
testom, moe posuy si dynamicznymi
technikami szklanej skrzynki, aby odkry
poprzednio przeoczone uboczne skutki
wykonywanych zada.
78. Bdy zalene od stanu aplikacji pojawiaj si
tylko wtedy, kiedy oprogramowanie znajduje si
w okrelonym stanie. Przykady takich bdw
to bdy, ktre wystpuj tylko wtedy, kiedy
program wykonywany jest po raz pierwszy albo
przeciwnie, tylko wtedy kiedy program
wykonywany jest kolejne razy. Moe jaki bd
pojawia si dopiero po wczeniejszym zapiszniu
danych lub po uprzednim naciniciu jakiego
klawisza. Takie bdy mog na pozr wyglda
jak zalene od zmiennych czasowych, ale wany
jest nie czas, lecz kolejno, w jakiej wykonuje
si zadania.
Strona 55 (84)
79. Warto uwzgldni zalenoci od zasobw,
wspdziaanie aplikacji z pamici, z sieci
oraz wsplne korzystanie z zasobw
sprztowych przez rne aplikacje. Czy bd
wystpuje tylko na obcionym systemie, ktry
jednoczenie obsuguje inne programy albo
komunikuje si z innymi systemami? Moe si
okaza, e przyczyn bdu s warunki wycigu
(kilka procesw lub programw rywalizujcych
o te same zasoby), przecieki pamici (pami
wykorzystywana i zwracana przez program nie
w caoci wraca do puli pamici pozostajcej do
dyspozycji systemu operacyjunego), albo jest to
bd zaleny od stanu systemu, pojawijcy si
tylko w poczeniu z okrelonymi zasobami.
80. Nie wolno zapomina o sprzcie. Inaczej ni
oprogramowanie, sprzt moe psu si wraz z
upywem czasu i dziaa w nieoczekiwany
sposb. Obluzowana karta, zapsuta ko pamici
albo przegrzany mikroprocesor mog
wywoywac awarie, ktre na pierwszy rzut oka
wygldaja jak skutki bdw oprogramowania,
ale nimi nie s. Warto sprbowa wywoa t
sama awari na innym sprzcie. To jest
szczeglnie istotne podczas wykonywania
testowania konfiguracji i kompatybilnoci.
Sprawdza si, czy ta sama awaria pojawia si
tylko na jednym rodzaju sprztu czy na wielu.
Jeli mimo wszelkich wysikw wci nie udaje si wyizolowa
znalezionego bdu i sporzdzi zwizej listy krokw niezbdnych dla jego
odtworzenia, trzeba mimo to zapisa informacj o nim po to, by nie zosta
zapomniany. Moe si zdarzy, e przy pomocy informacji zdobytej przez
testera programista bdzie w stanie bd zidentyfikowa. Poniewa
programista zna kod, wic opis symptomw, krokw zadania testowego i
przede wszystkim tych czynnoci, ktre tester wykonal usiujc
zidentyfkiowa przyczyn awarii, mog programicie podsun wskazwki,
gdzie bd moe si ukrywa. Oczywicie programista nie bdzie chcia ani
nie powinien nawet tego robi w odniesieniu do wszystkich znajdowanych
bdw1, ale niektre szczeglnie trudne wymagaj pracy zespoowej.
Bd bdowi nierwny
Dlaczeg by nie? C za fantastyczny i nienaturalny pomys podziau pracy, by zmusza testerw do

wykonywania zadania, w ktrym programista jest zdecydowanie lepszy, kosztem tego, co testerzy maj
robi i w czym s lepsi, to jest testowania?! (przyp. tumacza)
Strona 56 (84)
Kady zgodzi si pewnie, e bd niszczcy dane uytkownika jest
powaniejszy ni zwyky bd literowy. C jednak bdzie wtedy, kiedy
zniszczenie danych jest tak rzadkie, e by moe adnemu uytkownikowi
nigdy si nie przytrafi, podczas gdy bd lityerowy powoduje, e kady
uytkownik ma trudnoci z zainstalowaniem oprogramowania? Ktry bd
jest wtedy waniejszy i powinien by naprawiony przede wszystkim?
Decyzja staje si trudniejsza.
Gdyby projekt mia do dyspozycji nieskoczon ilo czasu, naprawionoby
oba bdy, ale tak sie nigdy nie zdarza. Jak dowiedzielimy si wczeniej, w
kadym projekcie informatycznym trzeba wywaa jedne bdy wobec
drugich i podejmowa ryzykowne decyzje. Ryzyko zawarte jest w decyzji,
ktre bdy naprawi przede wszystkim, a ktre mona pomin lub
zaplanowa do naprawy dopiero w pniejszej wersji programu.
Skadajc raporty o bdach, tester czsto ma moliwo podania propozycji,
co ma z nimi zosta zrobione. Tester klasyfikuje bdy i w zwizy sposb
opisuje ich znaczenie i skutki. Powszechnie stopsowan metod jest
przypisanie bdowi wagi oraz priorytetu. Szczegy tego procesu s rne
w rnych przedsibiorstwach, ale istota rzeczy pozostaje ta sama:
81. Waga oznacza jak powany jest bd i jakie s
jego skutki dla produktu i dla uytkownika.
82. Priorytet oznacza jak wane jest naprawienie
bdu i kiedy naley go naprawi.
Podana poniej lista czsto stosowanych kryteriw klasyfikacji wagi i
priorytetu powinna uatwi zrozumienie rnicy midzy nimi. Pamitajmy,
to s tylko przykady. Niektre firmy stosuja nawet dziesi rnych
poziomw, inne zadowalaj si trzema. Bez wzgldu na ilo poziomw, cel
jest ten sam.
Waga
1.Katastrofa systemu, utrata danych, zniszczenie danych
2.Bd w dziaaniu, nieprawidowy wynik, utrata funkcjonalnoci
3.Pomniejszy problem, bd literowy, forma interfejsu uytkownika, rzadki
wypadek
4.Propozycja
Priorytet
Strona 57 (84)
1.Natychmiastowa naprawa, uniemoliwia dalsze testowanie, bardzo
widoczny
2.Musi by naprawiony przed wypuszczeniem produktu
3.Powinien zosta naprawiony w miar moliwoci
4.Mona naprawi, ale mona te wypuci bez zmiany
Bd polegajcy na rzadko wystpujcym zniszczeniu danych mona
zaklasyfikowa jako Waga 1, Priorytet 3. Bd literowy w instrukcji
instalacji systemu, powodujcy e uytkownik zadzwoni po pomoc, mona
zaklasyfikowa jako Waga 3, Priorytet 2.
Co powiedzie o wersji programu, ktry pada natychmiast po
wystartowaniu? Przypuszczalnie Waga 1, Priorytet 1. Pogld, e przycisk
naley przesun odrobin na d strony mona chyba zaklasyfikowa jako
Waga 4, Priorytet 4.
Ta informacja jest kluczowa dla osoby lub zespou dokonujcego przegldu
raportu bdu1 i podejmujcego decyzje, jakie bdy naprawia i w jakiej
kolejnoci. Programista, ktremu przypisano 25 bdw do naprawy,
powinien przypuszczalnie zacz od bdw majcych priorytet 1, zamiast
najpierw odwali najatwiejsze. Podobnie, dwch kierownikw projektw jednego zajmujcego si gr komputerow, a drugiego - oprogramowaniem
monitora pracy serca - mogliby otrzyma podobn informacj i na jej
podstawie podj diametralnie odmienne decyzje. Jeden z nich zapewne
postawi na to, by aplikacja wygldaa jak najlepiej i dziaaa jak najszybciej,
za drugi przypuszczalnie wybierze w pierwszym rzdzie niezawodno.
Informacja o wadze i priorytecie bdw jest podstaw do decyzji. Kawaek
dalej w tym rozdziale zobaczymy, jak pola do wprowadzanie tej informacji
uywane s w rzeczywistym systemie do rejestracji i ledzenie bdw.
Priorytety bdw mog si zmienia w trakcie trwania projektu. Bd z
pocztku zarejestrowany jako Priorytet 2 moe zmienic si na Priorytet 4
kiedy czas ucieka i data wypuszczenia pierwszej wersji wisi nad gow.
Tester ktry znalaz bd powinien nieustannie kontrolowa status danego
bdu by upewni si czy jest to nadal zgodne z jego zdaniem i mc
dostarcza nowych danych na poparcie tego, by zosta naprawiony2.
Cykl yciowy bdu
I zwykle taki zesp o wiele bardziej od pojednycznego testera powoany jest do nadawania raportom
wagi i priorytetu - w takim zespola powinny znajdowa si osoby z marketingu, osoby zajmujce si
konstruowaiem wymaga itp (przyp. tumacza).
2
A kontrol polityki personalnej firmy oraz planowanej emisji nowych akcji nie powinien tester
czasem te si zaj? W kocu i do tego s wyznaczone osoby, ktre mog - jak w tym przykadzie
kierwonictwo projektu gdzie bez nieustannej kontroli i interwencji testerw system do ledzenie
raportw bdw nie dziaa - popenia bdy (sarkastyczny przypisek tumacza).
Strona 58 (84)
W entomologii (badajcej prawdziwe, ywe owady) okrelenie cykl yciowy
odnosi si do to rnych etapw ycia owada. Z lekcji biologii ze szkoy
redniej przypominamy sobie, e stadia wikszoci owadw to jajko, larwa,
poczwarka i dorosy owad. Dlatego wydaje si na miejscu, wziwszy pod
uwag e bdy oprogramowania nazywamy take pluskwami, e
podobny system stadiw yciowych zastosuje si, by wyrni
poszczeglne fazy ycia bdw. Fazy yciowe komputerowej pluskwy
nie s dokadnie takie same jak prawdziwego owada, ale koncepcja jest
analogiczna. Rysunek 18.2 pokazuje przykad najprostszego i optymalnego
cyklu yciowego bdu oprogramowania.
Bd znaleziony
Tester znajduje i rejestruje bd

Bd przydzielony programicie
Otwarty
Programista naprawia bd
Bd przydzielony testerowi
Rozwizany
Tester potwierdza e bd
zosta naprawiony
Tester zamyka bd
Zamknity
Rysunek 18.2 Diagram stanw pokazuje, e komputerowa pluskwa ma
cykl yciowy podobny do prawdziwego owada.
Na tym przykadzie wida, e kiedy bd zostaje po raz pierwszy znaleziony
przez testera, zostaje zarejestrowany i przypisany programicie do naprawy.
Ten stan nazywa si stanem otwartym. Kiedy programista poprawi ju kod,
przypisuje go na powrt testerowi i bd wchodzi w stan rozwizany. Tester
przeprowadza wtedy test regresywny aby potwierdzi, e bd rzeczywicie
zosta naprawiony i - jeli tak jest - zamyka bd. Bd wchodzi wtedy w
sw ostatni faz, w stan zamknity.
Czsto cykl yciowy bdu nie jest bardziej skomplikowany: bd zostaje
otwarty, rozwizany i zamknity1. W pewnych sytaucjach jednak cykl
yciowy nieco si komplikuje, jak wida na rysunku 18.3.
Zrczniej byoby mwi o rnych stanach raportu o bdzie, nie o stanach bdu, ale tak nietypow
terminologi stosuje autor (przyp. tumacza).
Strona 59 (84)
W tym wypadku cykl zaczyna si tak samo jak poprzednio od tego, e tester
otwiera bd i przypisuje go programicie, ale programista nie naprawia
bdu. Zdaniem programisty bd nie jest dostatecznie istotny by
umotywowa napraw, wic programista odwouje si do kierownika
projektu. Kierownik projektu zgadza si ze zdaniem programisty i
umieszcza bd w stanie rozwizany, nie bdzie naprawiony. Tester nie
zgadza si z t decyzj, znajduje bardziej oglny i jednoznaczny przykad
bdu, otwiera go ponownie i przypisuje kierownikowi porjektu. Kierownik
projektu w oparciu o now informacj przyznaje racj testerowi i ponownie
przypisuje bd programicie do naprawienia. Programista naprawia bd i
rozwizujc go, przypisuje go testerowi, ktry potwierdza zniknicie
symptomw i zamyka raport bedu.
Kierownik projektu akceptuje
konieczno naprawy
Bd znaleziony
Bd przypisany programicie
Tester znajduje i rejestruje bd

Otwarty
Bd przydzielony programicie
Programista naprawia bd
Otwarty
Bd przypisany testerowi
Programista ocenia bd jako
zbyt drobny by go naprawia
Bd przydzielony kierownikowi
projektu
Rozwizany
(naprawiony)
Tester potwierdza, e bd
jest naprawiony
Otwarty
Kierownik projektu ocenia
bd jako nie wymagajcy
naprawy
Rozwizany (nie
naprawiony)
Tester zamyka bd
Zamknity (jako
naprawiony)
Bd przypisany testerowi
Tester znajduje oglniejszy
przypadek awarii
Otwarty
Bd przypisany kierownikowi
projektu
Rysunek 18.3 Cykl yciowy bdu staje si niekiedy bardzo skomplikowany,

jeli proces naprawiania bdu nie przebiega tak gadko jak si oczekiwao.
Strona 60 (84)
Widzimy, e bd moe podlega wielu zmianom i powraca do poprzednich
stanw w czasie swego ycia, czasem skaczc do punktu startowego i
zaczynajc cykl yciowy od pocztku. Rysunek 18.4 dodaje do prostego
modelu z rysunku 18.2 moliwe decyzje, zatwierdzenia i powroty, ktre
zdarzaj si w wikszoci projektw. Oczywicie, kade przedsibiorstwo i
projekt moe mie wasny system, ale ten rysunek jest na tyle oglny e
powinien z grubsza pasowa do wikszoci ze spotykanych cykli yciowych
bdw.
Ten oglny cykl yciowy ma dwa dodatkowe stany i kilka dodatkowych linii
czcych. Stan przegldu ma miejsce wtedy, gdy kierownik projektu lub
komitet, czasem nazywany Komisj Kontroli Zmian (Change Control
Board, CCB), podejmuje decyzj czy bd naley naprawi. W niektrcyh
projektach wszystkie bdy przechodz przez t komisj zanim przypisane
zostaj programicie do naprawy. W innych projektach zdarza si to tylko
pod koniec projektu albo wcale. Zwrmy uwag, e od stanu przegldu jest
strzaka prowadzca bezporednio do stanu zamknitego. Korzysta si z
niej, kiedy przegld decyduje, e bdu nie trzeba naprawia - jest zbyt
drobny, nie jest w rzeczywistoci bdem, albo wynika z bdu testowania.
Dodany zosta stan odroczony. Przegld moe zadecydowa, e bd naley
naprawi kiedy w przyszoci, ale nie w obecnej wersji programu.
Bd znaleziony
Otwarty
Przegld
Rozwizany
Zamknity
Odroczony
Rysunek 18.4 Ten oglny diagram stanw cyklu yciowego bdu pasuje do
wikszoci zdarzajcych si naprawd sytuacji.
Strona 61 (84)
Dodatkowe poczenie od stanu rozwizanego do otwartego dotyczy
sytuacji, kiedy tester odkrywa, e bd nie zosta naprawiony. Bd otwiera
si ponownie i cykl yciowy zaczyna si od pocztku. Dwie przerywane
linie od stanu zamknitego i odroczonego z powrotem do stanu otwartego
wykorzystywane s rzadko, ale s na tyle wane, e trzeba o nich
wspomnie. Poniewa tester nigdy nie rezygnuje, moe si zdarzy, e bd
na pozr naprawiony, przetestowany i zamknity pojawia si ponownie.
Takie bdy nazywa si niekiedy regresjami. Zdarza si te, e bd
oproczony okazuje si potem na tyle powany, e wymaga jednak
natychmiastowej naprawy. Jeli ktra z tych sytuacji ma miejsce, bd
zostaje ponownie otwarty i cay proces zaczyna si od pocztku.
Wikszo zespow projektowych stosuje reguy dotyczce tego, kto ma
prawo zmieni stan bdu lub przypisa bd komu innemu. Na przykad,
by moe tylko kierownik projektu ma prawo podj decyzj o odroczeniu
bdu, lub tylko tester ma prawo zamkn bd. Wane jest, eby raz
zanotowawszy istnienie bdu, ledzi jego drog przez cykl yciowy, nie
zgubi go i dostarcza informacji koniecznej do tego, by bd zosta
naprawiony i zamknity.
Systemy ledzenia bdw

W tej chwili powionno ju by jasne, e proces raportowania bdw jest
skomplikowanym stworem, wymagajcym duo informacji, sporo
szczegw i wiele dyscypliny, aby dziaa. Wszystko czegomy si w tym
rozdziale nauczyli brzmi dobrze, ale aby mc zastosowa to w praktyce
potrzebny jest system, ktry umoliwia rejestrowanie znalezionych bdw i
ledzenie ich przez cay cykl yciowy. Takie s wnie zadania systemu
ledzenia bdw.
Pozostaa cz rozdziau powicona jest opisowi podstaw takiego systemu.
Podane bd przykady systemw opartych na papierowych notatkach i
systemw opartych o baz danych. System, ktry bdzie si stosowa w
rzeczywistoci zaley oczywicie od przedsibiorstwa lub od projektu, ale z
drugiej strony, podstawowe zasady s do podobne i spjne w caym
przemyle oprogramowania, tak wic ten opis powinien pozwoli poradzi
sobie z kadym systemem, krego przyjdzie nam uywa.
Standard: raport incydentu
Strona 62 (84)
Nasz dobry przyjaciel, Standard Dokumentacji dla Testu Oprogramowania
ANSI/IEEE 829 (mona go znale na standards.iee.org), definiuje
dokument zwany Raportem Incydentu Testowego (Test Incident Report),
ktrego zadaniem jest udokumentowa kade zdarzenie, ktre zachodzi w
trakcie testowania i wymaga dalszego badania. Mwic krtko,
zarejestrowa bd1.
Przegld standardu jest dobrym sposobem, by zebra wszystko czegomy si
dotd nauczyli o procesie raportowania i ledzenia bdw. Ponisza lista
zawiera - nieco zmodyfikowany pod wzgldem terminologii - zakres tego
stadardu.
83. Identyfikator. Okrela unikalny numer czy
nazw bdu, ktrej uywa si do poszukiwania
bdu lub w odnonikach do niego.
84. Streszczenie. Krtkie streszczenie istoty bdu.
Zawiera te referencje do wersji testowanego
oprogramowania, stosowanej procedury
testowej, numeru zadania testowego i
specyfikacji testu.
85. Opis wydarzenia. Jest to szczegowy opis
bdu, zawierajcy nastpujc informacj:
Data i godzina
Imi i nazwisko testera
Uyta konfiguracja oprogramowania i sprztu
Dane wejciowe
Kroki procedury testowej
Oczekiwane wyniki
Uzyskane wyniki
Usiowania odtworzenia bdu wraz z opisem, co wyprbowano
Inne informacje i obserwacje, ktre mog uatwi programicie
lokalizacj bdu.
86. Skutki. Waga, priorytet oraz oszacowanie
skutkw bdu dla planu testowania,
specyfikacji, procedur i zada testowych.
cilej, zarejestowa podejrzenie istnienia bdu. W najlepszym razie ma si do czynienia z oczywist

awari, ktrej dokadn przyczyn ujawni jednak dopiero dalsze poszukiwanie bdu. Czsto jednak
raport dotyczy jakiego "podejrzanego" wydarzenia, gdzie analizy wymaga, czy bya to w ogle
awaria, czy np. kopoty ze rodowiskiem testowym albo omyka testera!
Strona 63 (84)
Rczne raportowanie i ledzenie bdw
Standard 829 nie definiuje formatu raportu bdu, ale podaje przykad
prostego dokumentu. Rysunek 18.5 pokazuje, jak taki papierowy raport
bdu moe wyglda.
Strona 64 (84)
Nazwa projektu
Oprogramowanie:
Raport Bdu
Produkt:
Bd nr:
Wersja:
Tester:
Data:
Przypisany komu:
Waga: 1 2 3 4
Priorytet: 1 2 3 4
Odtwarzalno: TAK
NIE
Tytu:
Opis:
Decyzja: NAPRAWIONY - DUPLIKAT - NIEODTWARZALNY - NIE DA
SI NAPRAWI - ODROCZONY - NIE NAPRAWIA
Data rozwizania:
Rozwizany przez:
Wersja:
Komentarz na temat rozwizania:
Ponownie
przetestowany przez:
Przetestowana wersja:
Data testu:
Komentarz na temat testu:
Autor:
Programista:
Podpisy:
Tester:
Kierownik projektu:
Strona 65 (84)
Marketing:
Obsuga produktu:
Rysunek 18.5 Przykadowy formularz raportu bdu pokazujcy, jak

wszystkie potrzebne dane mona zmieci na pojedynczej stronie.
Zwrmy uwag, e ten jednostronicowy formularz ma mijesce na wszelk
informacj potrzebn, by zidentyfikowa i opisa bd. Zawiera te pola,
ktre wykorzystuje si, by mc ledzic bd w trakcie jego caego cyklu
yciowego. Kiedy formularz zostanie wypeniony przez testera, mona go
przypisa programicie do naprawy. Programista ma do dyspozycji pola,
gdzie moe wprowadza dane na temat naprawy, w tym propozycje decyzji
dotyczcych bdu. Sa te pola, gdzie tester - po naprawieniu bdu wprowadza informacj na temat wynikw ponowengo testu i moe zamkn
bd. Na dole formularza znajduje si miejsce na podpisy - wiele
przedsibiorstw stosuje zasad, e podpisem powiadcza si akceptacj tego,
jak bd zosta rozwizany1.
W bardzo maych projektach papierowe formularze mog by zupenie
wystarczajce. Jeszcze we wczesnych latach 90-ych zdarzay si wielkie,
krytyczne dla firmy projekty z tysicami zarejestrowanych bdw, ktre
stosoway papierowe formularze w celu raportowania i ledzenia bdw.
Resztki tych metod trwaj miejscami pewnie do dzi.
Kopot z papierowymi formularzami jest taki, e s one papierowe, a
kady kto kiedykolwiek usiowa co znale w jakimkolwiek systemie
opartym na papierowej dokumentacji wie dobrze, jakie to bywa
nieskuteczne. Wyobramy sobie tylko zawioci moliwych cykli cyiowych
raportu bdu (przykad mielimy na rysunku 18.3), a zwtpimy, czy
papierowy system jest w stanie za nimi nady. Co bdzie, jeli kto
zapragnie pozna status raportu numer 6329 albo zechce si dowiedzie, jak
wiele jest jeszcze otwartych raportw o priorytecie 1? Dziki Bogu za
arkusze kalkulacyjne i bazy danych.
Automatyczne raportowanie i ledzenie bdw
Tak samo jak z opisami zada i procedur testowych, ktrymi zajmowalimy
sie w rozdziale 17, nie ma powodu, by nie wspczeni standardu
ANSI/IEEE 829 i nie zaadaptowa go do pracy w nowoczesnych systemach.
W kocu informacja potrzebna do ledzenia bdw, taka jak dane na
formularzu z rysunku 18.5, to tylko tekst i liczby - idealne zastosowaneie dla
bazy danych. Rysunek 18.6 pokazuje taki automatyczny system do
reportowania i ledzenia bdw, jaki mona czsto dzi spotka w pracy
testera.
Bardzo anglosaskie podejcie - "podchody" majce na celu skoni np. kierownika testw, eby
wreszcie podpisa raport marnie naprawionego bdu i w ten sposb umoliwi wypuszczenie programu
bywaj tam przedmiotem wielu anekdot. Taki formalizm ma swoje zalety, ma te liczne wady (przyp.
tumacza).
Strona 66 (84)
Rysunek 18.6 pokazuje najwyszy poziom bazy danych zawierajcej 3263
bdy. Poszczglne bdy, ich identyfikatory, tytuy, status, priorytet, waga i
podjte decyzje pokazuje lista w grnej czci ekranu. Dalsza informacja na
temat wybranego bdu widoczna jest w dolnej czci ekranu. Od razu widzi
si, kto otworzy dany bd, kto go rozwiza i kto go zamkn. Mona te
przewija wszystkie szczegly wprowadzone do raportu w cigu cyklu
yciowego bdu.
Zwrmy uwag na pasek z przyciskami na grze ekranu, przy pomocy
ktrych mona stworzy (otworzy) nowy raport, jak rwnie edytowa,
rozwiza, zamkn lub reaktywowa (ponownie otworzy) ju istniejcy
raport. Na kolejnych stronach zobaczymy, jakie okna pojawiaj si po
wybraniu poszczeglnych opcji.
Lisiting bdw
Skrcona informacja
na temat cyklu
yciowego wybranego
bdu
Szczegowe dane na
temat bdu
Rysunek 18.6 Okno gwne typowej aplikacji bazodanowej do

raportowania bdw zawiera prbk moliwoci oferowanych przez taki
system (ilustracje przedstawiaj baz danych Mantis, za zgod Dave Balla
i HBS International, Inc.).
Rysunek 18.7 przedstawia okno dialogowe Nowy Bd, do ktrego
wprowadza si dane na temat nowego bdu do zarejestrowania w systemie.
Oglny opis bdu zawiera tytu, wag, priorytet, dane na temat wersji
oprogramowania itd. Jako komentarz wprowadza si opis tego, w jaki
sposb doszo do wykrycia bdu. Ta aplikacja zawiera ju gotowe
nagwki, suce jako pomoc do wypenienia potrzebnej informacji.
Wprowadzajc opis nowgo bdu, trzeba tylko wypeni wszystko po kolei cel testu, przygotowanie zadania, kroki potrzebne do wywoania bdu,
oczekiwane wyniki, otrzymane wyniki, konfiguracj sprztu i
oprogramowania, ktrej sie uywao kiedy wystpi bd.
Strona 67 (84)
Szczegowy opis
danych wejciowych i
krokw procedurey
testowej
Rysunek 18.7 Nowy bd zaczyna swj cykl yciowy w oknie dialogowym

Nowy Bd.
Kiedy bd zosta ju wprowadzony, a waciwie kiedykolwiek w trakcie
jego cyklu yciowego, moe okaza sie potrzebna nowa informacja
uzupeniajca opis, zmiany priorytetu lub wagi, i wszelkie inne drobne
zmiany danych dotyczcych bdu. Rysunak 18.8 przedstawia okno, ktre t
umoliwia.
Zwrmy uwag, e to okno dialogowe zawiera dodatkowe pola prcz pl
dostpnych ju przy wprowadzaniu nowgo bdu. W trakcie edycji opisu
bdu mona na przykad wprowadzi odnonik do innego bdu, jeli
wydaj si podobne lub w inny sposb spokrewnione. Programista moe
doda informacj na temat tego, na jakim etapie znajduje si praca nad
napraw bdu i ile czasu jeszcze na to potrzeba. Jest tam nawet pole
umoliwiajce zwieszenie bdu, jakby zamroenie bdu na obecnym
etapie jego cyklu yciowego.
Wan funkcja pokazan na rysunku 18.8 jest pole Komentarze. Za kadym
razem kiedy modyfikuje si opis bdu, kiedy si go otwiera, zmienia,
rozwizuje i zamyka, infomracja ta zostaje zarejestrowana w polu
Komnetarze. Na pierwszy rzut oka wida, jakie fazy bd przeszed ju w
swoim cyklu yciowym.
Dodatkowe pola
dostpne przay
modyfikacji
Informacja do
ledzenia zmian cyklu
yciowego
Rysunek 18.8 Okno Edycja pozwala dodawa nowe informacje do

istniejcego raportu bdu .
Strona 68 (84)
Rysunek 18.9 pokazuje okno stosowane wczas gdy kto, zwykle
programista lub kierownik projektu, rozwizuje bad. Rozwijana lista
zawiera rne moliwe rozwizania, poczwszy od Naprawiony, poprzez
Nie daje si naprawi a do Duplikat. Jeli bd zosta naprawiony,
wprowadza si numer wersji programu zawierajcej potrzebne zmiany, a
informacj na temat tego, co i jak zostao zmienione, wprowadza si do pola
przeznaczonego na komentarze. Bd zostaje nastpnie przypisany testerowi
do ponownego przetestowania i zamknicia.
Wiele baz danych dla raportw bdw zawiera nie tylko komnetarz
dotyczcy zmian, ale pene szczegy przeprowadzonych zmian: lini kodu,
nazw moduu, a nawet rodzaj bdu, jako e moe to by istotn informacj
dla testera stosujcego metody szkalnej skrzynki.
Kiedy bd zosta rozwizany, zwykle przypisuje si go ponownie testerowi,
aby go zamkn. Rysunek 18.10 pokazuje okno dialogowe Zamykanie.
Poniewa w bazie danych zapisano wszelkie zmiany w raporcie od momentu
jego otwarcia, widzi si wszystkie decyzje podjte po drodze i dokadny opis
sposobu naprawienia bdu. Moe si zdarzy, e bd zosta naprawiony
inaczej ni tester si spodziewa, moe inny, podobny bd zosta znaleziony
przez innego testera, albo programista doda komentarz, e dany sposb
naprawy jest ryzykowny. Wszelka informacja moe przyda si testerowi,
gdy bdzie testowa ponownie, aby si upewni, czy rzeczywicie bd
zosta naprawiony. Jeli bd nie zosta naprawiony, po prosu otwiera si go
ponownie i cykl yciowy zaczyna si od pocztku.
Rysunek 18.9 Okno dialogowe Rozwizanie uywane jest zwykle przez
programist, zapisujcego dane na temat sposobu naprawienia bldu.
Rysunek 18.10 Raport bdu gotowy do zamknicia zawiera do wgldu ca
swoj histori.
Kiedy raz si zacznie stosowa baz danych do ledzenia bdw, czowiek
dziwi si, jak mona to byo kiedykolwiek robi na papierze. Baza danych
do ledzenia raportw o bdach staje si gwnym orodkiem, uywanym
nie tylko przez testerw, do komunikowania statusu projektu, przypisywania
uczestnikom projektu zada do wykonania i - co najwaniejsze - upewnienia
si, e adne bdy nie zostan zapomniane czy pominite. Jest to stosowne
zamknicie tego wszystkiego, czego nauczylimy si w tym rozdziale na
temat raportowania znalezionych bdw.
Podsumowanie
Rozdzia zacz si od dziecinej historyjki o Kurczaku, ktry przestraszy si
ogromnie, gdy od spad mu na gow. Kurczak pomyla, e znalaz
powany problem - bd wagi 1, priorytetu 1 - i natychmiast zacz biega i
krzycze, e wali si cay wiat.
Strona 69 (84)
Testerowi tez moe si co takiego atwo przydarzy, gdy znajdzie w
programie co, co nie dziaa tak jak powinno. Nauczylimy si w tym
rozdziale, e powinien istnie formalny proces, wedle ktrego naley
pracowa aby porzdnie wyizolowa, zaklasyfikowa, zarejestrowa i
ledzi dlasze losy znalezionych bdw tak, by mie pewno, e zostan w
kocu rozwizane i - miejmy nadziej - naprawione.
May Kurczak nigdy nie czyta rozdziau 18-ego, wic nie przyszo mu do
gowy nic innego ni opowiada wszystkim spotkanym, co mu si zdarzyo.
Oczywicie, to nie by dobry pomys. wiat si nie wali. Gdyby Kurczak
cho na chwil zatrzyma si i sprbowa wyizolowa i odtworzy problem,
okazaoby si szybko, e to w ogle nie by adnen problem - e spadanie
odzi z drzewa byo zgodne z zamiarem konstruktora. Tymczasem panika i
naiwno w kocu zgubiy Kurczaka. Dla tych, co nie znaj tej historii:
Kurczak i jego przyjaciele w kocu spotkali godnego lisa, ktry zaprosi ich
do swej nory, aby posucha caej historii.
Wypywa z tego taki mora, e dobry tester musi nie tylko umie
zaplanowa swoje testy i znajdowa bdy, ale take umie metodycznie i
systematycznie raportowa ich istnienie. Przesadny, le opisany albo wrcz
nieprawdziwy bd nie jest w ogle bdem - i na pewno nie zostanie
naprawiony.
Pytania
1.Podaj kilka powodw, dla ktrych bd moe nie zosta naprawiony.
2.Jakie s podstawowe zasady pisania raportw o bdach tak, aby
zmaksymalizowa szans, e zostan naprawione?
3.Podaj kilka technik izolowania i odtwarzania bdu.
4.Wyobramy sobie, e testujc Kalkulator Windows otrzymujemy
nastpujce wyniki: 1+1=2, 2+2=5, 3+3=6, 4+4+9, 5+5=10 i 6+6=13.
Napisz stosowny tytu raportu i opis bdu.
5.Jak wag i priorytet nadaby bdowi literowemu w nazwie firmy na
pierwszym ekranie aplikacji?
6.Jakie s trzy podstawowe fazy cyklu yciowego bdu i dwa czsto
stosowane stany dodatkowe?
7.Podaj kilka powodw, dla ktrych system ledzenia bdw z uyciem
bazy danych jest znacznie bardziej uyteczny ni system oparty na
papierowych raportach.
Strona 70 (84)
Rozdzia 19 Pomiar sukcesu

W TYM ROZDZIALE
Wykorzystanie danych ze statystyki raportw bdw
Pomiary stosowane w testowaniu
Typowe pomiary stosowane w projekcie
W rozdziale 18-ym poznalimy podstawowe zasady rejestracji i ledzenia
bdw oraz jak posuy si specjaln baz danych w celu gromadzenia
raportw o bdach. Chocia najczciej pracuje si z t baz danych
podczas wprowadzania do niej lub modyfikowania ju zarejestrowanych
bdw, dodatkowym, porednim zyskiem z jej istnienia jest mono
wydobywania z niej interesujcych danych, ktre wskazuj na sukces (albo
niepowodzenie) testowania oraz na oglny postp w projekcie.
Korzystajc ze zgromadzonych w bazie danych informacji, mona
dokonywa poszukiwa, ktrych wyniki poka na przykad jakie typy
bdw rejestrowane sa najczciej, jak szybko rozwizuje si znalezione
bdy, jaki procent znalezionych dotd bdw zostao naprawionych itp.
Kierownik testowania lub kierownik projektu mog na podstawie takiej
statystyki zidentyfikowa trendy, ktre wska na przykad czy jaka cz
oprogramowania wydaje si potrzebowa jeszcze duo wicej testowania,
albo czy projekt wydaje si nada za harmonogramem. Dane s dostpne,
jedynie potrzeba sporzdzi na ich podstawie odpowiednie raporty, ktre
wydobd poszukiwane trendy na wiato dzienne.
W tym rozdziale zapoznamy si z typowymi formami pyta oraz raportw, z
ktrymi tester prawdopodobnie wczeniej lub pniej bdzie musia si
spotka, oraz sposoby ich zastosowania w projektach informatycznych.
87. Jak korzysta z pomiarw i danych
statystycznych
88. Czemu trzeba zachowa ostrono podczas
zbierania danych i konstruowania raportw na
ich podstawie
89. Jak formuowa proste pytania w bazach danych
i jak budowa z nich raporty
90. Czsto stosowane pomiary w projektach
Wykorzystanie danych ze statystyki raportw bdw

Zastanwmy si nad nastpujcymi pytaniami:
91. Jakie czci testowanego oprogramowania maj
najwicej bdw? Jakie najmniej?
Strona 71 (84)
92. Ile rozwizanych bdw jest obecnie
przypisanych Marcie?
93. Robert wkrtce wyjedzie na urlop. Czy zdy
przedtem naprawi wszystkie przypisane mu
bdy?
94. Ile bdw znaleziono w tym tygodniu? W tym
miesicu? W czasie caego projektu?
95. Na najblisze posiedzenie grupy sterujcej
projektu potrzebna jest lista wszystkich
otwartych bdw o priorytecie 1
96. Czy wydaje si, e jest szansa dotrzyma
zaplanowan dat wypuszczenia
oprogramowania?
Tego rodzaju pytania zadawane s nieustannie w trakcie trwania projektu
informatycznego. Nie jest to adna cisa matematyka, lecz proste pytania,
na ktre zarwno zesp testowy jak i cay zesp projektowy musi zna
odpowied.
Moe si to komu wydawa dziwnym, e baza danych suca do rejestracji
i ledzenia raportw bdw moe sta si takim podstawowym narzdziem
do pomiaru statusu projektu i do znajdowania odpowiedzi na tak zasadnicze
pytania. Kto jeszcze si tego nie nauczy, mgby oczekiwa, e t rol
powinien raczej spenia plan projektu, gwny harmonogram albo jaki
inny dokument pod kontrol kierownika projektu. Jednak w rzeczywistoci
te dokumenty odzwierciedlaj bardziej zamiary ni stan faktyczny, podczas
gdy baza danych oddaje to, co dzieje si w rzeczywistoci. Chcc wybra
dobr restauracj, mona to zrobi na podstawie yciorysu gwnego
kucharza lub historii waciciela restauracji. Jednak chcc miec pewno, e
wybr bdzie trafny, oprzemy si raczej na opinii aktualnego dziau w prasie
codziennej lub na danych z inspekcji sanitarnych restauracji. W ten sam
sposb dziaa baza danych projektu. Jej zawarto mwi nam co dziao si w
przeszoci, co dzieje si obecnie oraz pozwala nam analizowa dane by
dokona dobrze podbudowanej prby przewidywania przyszoci.
Pomiary okrelonych atrybutw projektu informatycznego okrela si
terminem pomiary oprogramowania. rednia ilo bdw znalezionych
dziennie przez testera jest takim pomiarem. Stosunek iloci bdw o
wadze 1 do iloci bdw o wadze 4 jest innym pomiarem.
Poniewa baza danych zawierajca raporty o bdach jest codziennie
uzupeniana nowymi bdami, datami planowanych napraw, nazwiskami
czonkw projektu, przypisywaniem bdw rnym osobom itd., jest ona
oczywistym miejscem, skd mona pobiera pomiary opisujce status
projektu - oraz status poszczeglnmych testerw i programistw.
Strona 72 (84)
Tutaj kryje si rwnie potencjalne niebezpieczestwo korzystania z bazy
danych dla uzyskiwania pomiarw. Ta sama baza danych, z ktrej kady
moe si dowiedzie, ile jeszcze pozostao do naprawienia bdw o
priorytecie 1-ym, pozwoli te kierownictwu dowiedzie si, ile bdw
zostao spowodowanych przez okrelonego programist. Szef testera moe
take sprawdzi, ile dany tester sporzdzi raportw bdw w porwnaniu z
innymi testerami. Czy to dobrze? By moe, pod warunkiem e zarwno
tester jak i programiosta s naprawd dobrzy. Co bdzie jednak, jeli jeden
tester bdzie testowa kod wyprodukowany przez naprawd dobrego
programist? Bdzie to oznacza mniej bdw do znalezienia i statystyka
iloci sporzdzonych przez danego testera raportw bdw bdzie si
prezetowa sabiutko w pornaniu z wynikami uzyskanymi przez jego
kolegw, testujcych kod naprawd nafaszerowany bdami.
Nie jest celem tego rozdziau wdawa si w rozwaania dotyczce
moralnych i interpersonalnych aspektw, ktre mog si pojawi wobec
sposobw zastosowania statystyki wygenerowanej z bazy danych. Generalna
zasada powinna by taka, e celem korzystania z danych ma by uzyskanie
pomiarw dotyczcych projektu, a nie osigni poszczeglnych osb.
Stosowanie pomiarw do ocen indywidualnych moe by wzite pod uwag
pod warunkiem, e pomiary s dostpne do wgldu tylko dla
upowanionych osb, s zrozumiae i jednoznaczne - czy wyniki ujawniaj
dobrego programist czy kiepskiego testera? Pracujc w projekcie
uywajcym bazy danych do rejestrowania i ledzenia bdw, naley - by
unikn poniejszych niespodzianek - z gry przedyskutowa ze swoim
szefem oraz z kierownikiem projektu, w jaki sposb dane te bd
wykorzystywane.
Pomijajc polityk, zastosowanie bazy danych jako rda pomiarw jest
nadzyczajnie skuteczn metod oceny stanu projektu i swojej wasnej pracy.
Wszelka potrzebna informacja ju tam jest, chodzi jedynie o to, by j
wydoby i zaprezentowa w odpowiedni sposb. W pozostaej czci tego
rozdziau bdzie mowa o tym, jak generowa i interpretowa pewne
powszechnie stosowane pomiary do oceny projektw informatycznych.
Oczywicie, projekty bywaj rozmaite, wic trzeba pamita, e rne bd
take adekwatne typy pomiarw. Kiedy si wanie zobaczyo najbardziej
dziwaczny diagram koowy pod socem, kto w teje chwili wymyli inny,
pozwalajcy na nowy, skuteczny sposb uzyskania wgldu w dane
dotyczce projektu.
Pomiary stosowane w testowaniu
Strona 73 (84)
Chyba najczciej - oprcz rejestrowania i modyfikowania raportw bdw
- uywan funkcj bazy danych do ledzenia bdw jest wykonywanie
pyta, aby uzyska listy bdw dobranych pod wybranym wzgldem.
Pamitajmy, e bazy danych mog zawiera tysice raportw bdw.
Manualne przeszukiwanie czy sortowanie tak wielkiej listy jest
niewykonalne. Urok rejestrowania bdw w bazie danych polega midzy
innymi na tym, e wykonywanie pyta staje si tak atwe. Rysunek 19.1
pokazuje typowe okno suce do budowania pyta, z przykadowym
pytaniem gotowym do wprowadzenia do aplikacji.
Rysunek 19.1 Wikszo baz danych sucych do rejestracji i ledzenia
bdw umoliwia budowanie pyta, ktre pozwalaj uzyskiwa
poszukiwan informacj (baza danych Mantis, za zgod Davea Balla z
HBS International, Inc.)
Ten program do budowania pyta, jak wikszoc innych, uywa
standardowych operatorw logicznych ORAZ i LUB oraz nawiasw do
konstruowania zoonych pyta. W pokazanym przykadzie tester poszukuje
listy bdw speniajcych nastpujce kryteria:
97. Nazwa produktu brzmi Mantis LUB Mantis Web
ORAZ
98. bd zosta otwarty albo przez IraCol LUB
przez JosNar ORAZ
99. obecny status bdu jest Zamknity.
Kliknicie w przycisk Zadaj Pytanie spowoduje szukanie w bazie danych
wszystkich bdw speniajcych podane kryteria. Wynikiem
przeszukiwania bdzie lista numerw i tytuw bdw speniajcych te
kryteria.
Rodzaje pyta, ktre mona zadawa zale od tego, jakie pola znajduj si
w bazie danych, jakie wartoci pola te mog przyjnowa, oraz od funkcji
aplikacji do obsugi bazy danych. Daje si w kadym razie zwykle uzyska
odpowied na niemal kade pytanie dotyczce testowania i jego relacji do
projektu. Oto przykadowa lista pyta, na ktre wikszo baz danych
udzieli odpowiedzi:
100.Jakie s idnetyfikatory rozwizanych bdw,
przypisanych w ostatniom czasie danemu
testerowi do zamknicia?
101.Ile raportw bdw przedoy dany tester w
trakcie trwania projektu? W ostatnim tygodniu?
Midzy 1 kwietnia a 31 lipca?
102.Ktre z wprowadzonych przez danego testera
raportw dotyczcych interfejsu uytkownika
zostay rozwizane jako nie do naprawy?
103.Ile bdw zarejestrowanych przez danego
testera miao wag 1, a ile wag 2?
Strona 74 (84)
104.Spord wprowadzonych przez danego testera
bdw, ile ju naprawiono, ile zostao
odroczonych, a ile byo duplikatami?
Odpowiedzi na postawione pytanie jest lista bdw, taka jak pokazana w
oknie na rysunku 19.2. Znajduj si w niej - w kolejnoci swoich numerw wszystkie bdy speniajce kryteria postawione w pytaniu. Bdy, ktrych
nie ma na licie, kryteriw nie speniaj.
Numrery
(identyfikatory)
bdw
Tytuy (skrcone opisy)

bdw speniajcych
kryteria
Lista bdw
speniajcych
kryteria pytania
Rysunek 19.2 Odpowied na postawione pytanie pojawia si w oknie

aplikacji bazodanowej jako lista bdw speniajcych kryteria pytania.
Moliwo stawiania pyta i przeszukiwania bazy danych jest wielk
pomoc w uzyskiwaniu informacji niezbdnej do oceny jakoci wykonanej
pracy oraz do planowania dalszych dziaa. Kolejny krok to przedstawienie
odpowiedzi na pytanie (lub pytania) w formie drukowanego raportu,
najlepiej w postaci graficznego diagramu. Rysunek 19.3 pokazuje jak moe
wyglda dialog funkcji stosowanej do konstruowania takich raportw.
Rysunek 19.3 Ta baza danych pozwala dokona wyboru, ktre pola kadego
rekordu maj zosta wyeksportowane na plik (tekstowy lub w formacie
aplikacji do obrbki teskstu).
Na rysunku 19.2 znajduje si lista znalezionych bdw. Dla kadego bdu
pokazany jest jego numer/identyfikator, tytu, status, priorytet, waga,
decyzja oraz nazwa produktu, ktrego bd dotyczy. Czasem potrzebuje si
dokadnie tej informacji, ale czasem przydaoby sie wicej lub mniej
szczegw. Definiujc, ktre pola maj zosta wyeksportowane na plik
przy pomocy funkcji pokazanej na rysunku 19.3, mona precyzyjnie
okreli, ktre dane znajd si w ostatecznym raporcie. Jeli potrzebna jest
lista bdw przypisaneych okrelonemu testerowi, wystarczy
wyeksportowa numery i tytuy bdw. Wybierajc si na zebranie majce
dyskutowa na temat otwartych bdw, sporzdzi si zapewne raport
zawierajcy numery bdw, ich tytuy, wagi, priorytety oraz nazwisko
osoby, ktrej s przypisane. Przykad takiej listy znajduje si w Tablicy 19.1.
Tabela 19.1 Lista otwartych bdw na zebranie Komitetu Bdw
Strona 75 (84)
Nr
Tytu bdu
Priorytet
Waga
Przypisany
komu
005
Liczby parzyste nie s

dodawane poprawnie
(nieparzyste poprawnie)
0 dzielone przez 0
powoduje awari
lepe doczenia do
usunitych tematw w
pliku pomocy calc.jlp
lepe doczenia do
nieznanych tematw w
pliku pomocy wcalc.hlp
WaltP
ElP
BobH
BobH
023
024
025
Strona 76 (84)
030
Bdne kolory w trybie

256 (poprawne w trybie
16)
MarthaH
Strona 77 (84)
Zamiast zapisywa wyniki przeszukiwania w pliku o formacie gotowym do
sporzdzenia wydruku, mona go zapisa w formie samego tekstu z polami
oddzielonymi znakiem tabulatora. Taki plik mona wczyta do innej bazy
danych, do arkusza kalkulacyjnego albo do aplikacji do sporzdzania
wykresw. Na przykad mona sofrmuowa nastpujce pytanie:
Produkt RWNA SI Calc-U-Lot ORAZ1
Wersja RWNA SI 2.0 ORAZ
Otwarty Przez RWNA SI Patryk
Takie pytanie stworzy list wszystkich bdw dla (fikcyjnego) produktu o
nazwie Calc-U-Lot, wersji 2.0, otwartych przez kogo o imieniu Patryk.
Jeli uzyskan list, zawierajc pole opisujce wag bdu, wyeksportowa
do np. arkusza kalkulacyjnego, mona sporzdzi wykres taki jak na
rysunku 19.4.
Calc-ULot, wer. 2.0
Bdy Patryka posortowane wedug wagi
Waga 1 Waga 2 Waga 3 Waga 4

Rysunek 19.4 Na podstawie informacji z bazy danych mona sporzdza
wykresy pokazujce szczegy na temat stanu testowania.
Ten wykres koowy nie zawiera tytuw ani opisw bdw, ani dat, ani
decyzji, ani nawet mumerw bdw. Widzimy wycznie przegld bdw
przypisanych Patrykowi w projekcie wytwarzania aplikacji Calc-U-Lot,
wersji 2.0 (istotne jeli tester lub programista uczestniczy jednoczenie we
wjcej ni jednym projekcie), podzielonych wedug wagi. Spord bdw
Patryka 45% ma wag 1, 32% wag 2, 16% wag 3 i 7% wag 4. Za tymi
liczbami kryje si wiele istotnych szczegw, ale w skrcie mona
powiedzia, e wikszo przypisanych Patrykowi bdw jest do
powanych.
Podobnie, rysunek 19.5 pokazuje przykad innego wykresu, sporzdzonego
na podstawie odpowiedzi na inne pytanie, ktry pokazuje jak bdy Patryka
podzieliy si wedle podjtych decyzji, co z nimi zrobi. Pytanie w celu
uzyskania listy bdw wygldaoby nastpujco:
Produkt RWNA SI Calc-U-Lot ORAZ
Wersja RWNA SI 2.0 ORAZ
Otwary Przez RWNA SI Patryk ORAZ
Status RWNA SI Rozwizany LUB Status RWNA SI
Zamknity
Pseudo-kod uyty w tych przykadach to jakby uproszczony SQL (przyp. tumacza).
Strona 78 (84)
Eksportujc list bdc odpowiedzi na powysze pytanie wraz z polem
Decyzja do aplikacji generujcej wykresy, mona wygenerowa diagram
taki jak na rysunku 19.5, pokazujcy, e wikszo bdw Patryka zostaje
naprawionych (dobry znak dla tstera), a tylko niewielki procent zostaje
rozwizanych jako nie dajce si odtworzy, duplikaty, odroczone albo - z
rnych powodw - jako nie-bdy (faszywe bdy).
Calc-ULot, wer. 2.0
Bdy Patryka posortowane wedug rozwizania
Ilo bdw
Naprawiony Nie odtw. Duplikat Nie-bd Odroczony

Rysunek 19.5 Rne pytania pozwalaj przedstawi dane na temat bdw z
rnych perspektyw. Na tym przykladzie widzimy, jak zostay rozwizane
bdy nalece do jednego testera.
Rozpoczwszy testowania, zaczyna si stosowa pewne pomiary po to, by
ledzi postpy pracy. Niektrzy chtnie stosuj pomiar iloci bdw
znalezioneych w cigu jednago dnia, inni posuguj si raczej
wspczynnikiem naprawialnoi, jak w powyszym przykadzie.
Wydobywajc informacj z bazy danych, daje sie sporzdzi wiele rnych
pomiarw. To prowadzi nas do nastpnego podrozdziau, gdzie bdzie mowa
o powszechnie stosowanych pomiarach na wyszym poziomie,
pokazujcych stan i postpy caego projektu.
Typowe pomiary stosowane w projekcie

Zabawimy si teraz w wielkiego szefa i zastanowimy si nad pytania, nad
ktrymi kierownicy gowi si kadego dnia nad porann kaw: czy projekt
robi postpy? czy oprogramowanie da si dostarczy zgodnie z
harmonogramem? jakie jest ryzyko opnienia? jaka jest nieazwodno
produktu?
Kierownictwo zawsze jest zainteresowane oglnymi danymi na temat
projektu - jaka jest oglna jako i niezawodno produktu oraz czy projekt
idzie zgodnie z harmonogramem. Baza danych z bdami jest doskonaym
rdem uzyskania takiej informacji.
Przypomnijmy sobie rozdzia 3-ci Testowanie w rzeczywistoci, gdzie
poznalimy zasad - im wicje bdw si znalazo, tym wicej bdw jest
jeszcze ukrytych. Ta zasada jest speniona niezalenie od tego, czy stosuje
si ja wobec maego fragmentu kodu, czy wobec oprogramowania
skadajcego si z tysicy moduw. Stosujc j, mona bez trrudu
wykonywa pomiary i sporzdza wykresy, pozwalajce wyrobi sobie
zdanie na temat stanu nie tylko testw, ale caego projektu.
Strona 79 (84)
Najprawdopodobniej nie tester, lecz kierwonik testw lub projektu bdzie
wykonywa te pomiary. Wane jest jednak, aby rwnie testerzy
orientowali si w ich znaczeniu, bo to pozwala zrozumie zwizek midzy
wasn prac a postpami zespou testujcego oraz caego projektu.
Rysunek 19.6 jest podstawowym diagramem koowym, pokazujcym jak
bdy znalezione w projekcie Calc-U-Lot, wersja 2.0, dziel si wedle
gwnych funkcji oraz typw dziaa programu.
Calc-U-Lot wer. 2.0 - Bdy w rnych czciach programu
Inne
Lokalizacja
Interfejs uytkowanika
Kompatybilno
Konfiguracja
Matematyka cakowitoliczbowa
Dokumentacja
Matematyka binarna
Matematyka zmiennoprzecinkowa
Rysunek 19.6 Diagram koowy na poziomie caego projektu pokazuje, jak

wiele bdw znaleziono w gwnych czciach wytwarzanego programu.
Zamy, e powyszy wykres wygenerowany zosta gdzie w poowie
procesu wytwarzania programu. Stosujc zasad bdy chodz stadami,
atwo przewidzie, ktre obszary oprogramowania zapewne zawieraj jescze
wiele bdw i prawdopodobnie bd wymagay dodatkowego testowania.
Trzy dziedziny - interfejs uytkowanika, matematyka cakowitoliczbowa
oraz matematyka zmiennoprzecinkowa - cznie odpowiadaja za 60%
znalezionych dotd bdw. Przy zaoeniu, e rne dziedziny testowane
byy rwnie starannie, istnieje rzeczywicie due prawdopodobieastwo, e
te trzy naprawd s pene bdw i zawieraj jeszcze wiele dalszych bdw
do znalezienia.
Formuujc takie wnioski, trzeba jednak powanie wzi pod uwag, czy
testowanie odbywao si jednakowo intensywnie w caym projekcie.
Mogo si przecie atwo zdarzy, e te trzy dziedziny przetestowano ju
do starannie, podczas gdy w pozostaych testy ledwo si rozpoczy!
Generujc pomiary na podstawie bazy danych bdw, trzeba zawsze
uwzgldni, czy wnioski formuuje si na pdstawie prawidowych
danych!
Strona 80 (84)
Dane przedstawione w powyszym przykadzie mwi kierwonictwu bardzo
wiele o stanie projektu, co wymownie ilustruje, jak istotn informacj moa
oddestylowa z prostych i atwo zrozumiaych faktw. Zespoy testujce
czsto uywaj tego typu wykresw, aby zrozumie skd bierze si
najwicej bdw i ktre rejony projektu wymagaj najwicej uwagi.
Wykres nie zawiera jednak danych dotyczcych czasu. Na przykad jest
moliwe, e tempo znajdowania nowych bdw (czyli przyrost cznej
iloci bdw) dla interfejsu uytkownika sabnie, natosmiast wzrasta dla
lokalizacji. Tego nie da si powiedzie na podstawie takiego wykresu. Z
tego powodu czsto uywa si innego typu wykresw, pokazujcych czna
sum znalezionych bdw przez duszy okres. Rysunek 19.7 jest
przykadem takiego wykresu.
Na tym wykresie, pocztkowe daty tygodni poczwszy od 7 czerwca a do 6
wrzenia znajduj si na osi X, za ilo znajdowanych kadego dnia bdw
na osi Y. Wida, e tempo znajdowania bdw byo niskie na pocztku
projektu, stopniowo wzrastao i w kocu ustabilizowao si na poziomie
okoo 15 bdw dziennie. Przyjmijmy, e planowana data wypuszczenia
produktu to 15 wrzenia. Czy mona si spodziewa dotrzymania tego
terminu, patrzc na wykres?
Wikszoc rozsdnie mylcych ludzi odpowie "nie". Wykres jednoznacznie
pokazuje stabiln frekwencj znajdowania bdw przez duszy czas, bez
adnych tendencji spadkowych. Oczywisie moe si zdarzy, e spadek
tempa znajdowania bdw dajcy si zaobserwowa w cigu ostatnich
trzech dni bdzie trwa nadal, ale brak na to dowodw. Dopki nie pojawi
sie wyrany trend, nie ma adnych powodw sdzi, e oprogramowanie
jest gotowe do wypuszczenia.
Wyrany trend pokazujcy dokonany postp dostrzega si natomiast na
rysunku 19.8. Pocztek wykresu jest taki sam dla obu projektw (rysunki
19.7 i 19.8), ale po osigniciu szczytowego poziomu w poowie lipca, ilo
znajdowanych bdw wyranie maleje, w kocu spadajc do okoo
jednego-dwch dziennie - wyrany wskanik, e bdw w oprogramowaniu
jest coraz mniej i dlatego staj si coraz trudniejsze do znalezienia.
Calc-U-Lot wer. 2.0 - Ilo bdw otwartych w rnych tygodniach
Ilo bdw
Bdy otwarte
kadego dnia
Data otwarcia
Strona 81 (84)
Rysunek 19.7 Wykres iloci bdw otwartych w rnych tygodniach
ujawnia wiele na temat projektu wytwarzania oprogramowania .
Calc-U-Lot wer. 2.0 - Ilo bdw otwartych w rnych tygodniach
oraz wykres cznej iloci otwartych bdw
Ilo bdw
Bdy otwarte
kadego dnia
Skumulowana
ilo bdw
Data otwarcia
Rysunek 19.8 Ten wykres dotyczy projektu, ktry ma szans zrealizowa

zaplanowan dat wypuszczenia produktu 15 wrzenia.
Wykres na rysunku 19.8 zawiera dodatkow lini skumulowanej iloci
bdw znalezionych od pocztku testowania. Wida jej systematyczne
wznoszenie si, a potem wypaszczenie, wiadczce o malejcej frekwencji
znajdowanych bdw. Projekt, ktry dotar ju do tego momentu, ma
zwykle znaczne szanse wypuszczenia produktu.
Interpretujc dane trzeba zachowa ostrono. Wemy pod uwag
wykres na rysunku 19.8. Wida na nim, e tempo znajdowania nowych
bdw wyranie maleje. Mona przyj, e dzieje si tak dzieki temu, e
produkt staje si stopniowo - wraz z usuwaniem wczeniej znalezionych
bdw - coraz stabilniejszy. Nie mona jednak wykluczy, e ten efekt
wie si np. z mniejsz iloci testerw w pracy z powodu epidemii
grypy! Kiedy testerzy nie testuj, znajduje si mao bdw i wykres
wyglda dokadnie tak samo, jak wczas gdy produkt staje si coraz
stabilniejszy.
Uyte w powyszych przykadach uproszczone wykresy maj na osi X
jedynie daty kalendarzowe. W odniesieniu do rzeczywistego projektu
naleaoby na tej osi uwzgldni nie tylko daty, ale rwnie harmonogram
projektu i gwne punkty kontrolne, takie jak planowane dostawy programu,
kolejne fazy testowania itp. Mogoby to na przykad wyjani, czemu
czstotliwo znajdowania bdw maleje w pewnym momencie (jedna faza
testowania zostaa zakoczona i testerzy czekaj na now dostaw), albo
czemu gwatownie wzrasta (rozpoczto testowanie duej iloci wczeniej
nietestowanego kodu). Wykres to tylko graficzne przedstawienie danych.
Aby sta si uyteczny, musi by wytumaczony i zrozumiay.
Strona 82 (84)
Wykres, ktry niezwykle skutecznie ilustruje stan projektu, pokazany jest na
rysunku 19.9. Jest on podobny do wykresu z rysunku 19.8, ale dodane
zostay na nim dwie dodatkowe krzywe: jedna pokazuje sum iloci
rozwizanych bdw, druga sum iloci zamknitych bdw. Cieniowanie
przestrzeni midzy krzywymi podkrela granice midzy nimi.
Calc-U-Lot wer. 2.0 - Ilo bdw otwartych, rozwizanych i
zamknitych
Ilo otwartych
bdw
Bdy otwarte
Bdy rozwizane
Bdy zamknite
Data otwarcia
Rysunek 19.9 Czy to jest najlepszy z moliwych wykres stanu testowania w

projekcie? Moe tak, moe nie. Na pewno bardzo dobrze ilustruje stan
projektu.
Grna krzywa jest ta sama, co na rysunku 19.8 i przedstawia ilo
wszystkich otwartych bdw. Tutaj nie ma adnej nowoci. Nastpna
krzywa reprezentuje rozwizane bdy - te, ktre zostay naprawione przez
programistw albo co do ktrych komitet podj decyzj, e nie bd
rozwizywane. Wraz z upywem czasu, ta krzywa - naley mie nadziej wznosi si do gry, podajc w lad za krzyw bdw otwartych. Odstp
midzy krzywymi (na wykresie obszar wypeniony czarnym kolorem)
bdzie istnia prawie zawsze, poniewa z reguy programici ani komitet nie
s w stanie rozwizywa bdw natychmiast, gdy si pojawi. Zwykle
bdy gromadz si i odstp ten pocztkowo si powiksza. W kocu
programici i inne osoby odpowiedzialne za rozwizywanie bdw
zaczynaj nadrabia zalegoci i obie linie schodz si - ilo bdw w jaki
sposb rozwizanych pokrywa si z iloci bdw otwartych.
Bd rozwizany to nie zawsze to samo, co bd naprawiony. Niektre
bdy zostan okrelone jako duplikaty, jako bdy, ktrych nie bdzie si
naprawia, jako faszywe bdy itd.
Strona 83 (84)
Trzecia krzywa pokazuje ilo bdw zamknitych. Pamitajmy, e bd
naprawiony kierowany jest z powrotem do testera, aby sprawdzi, czy bd
faktycznie jest naprawiony, czy naprawa nie spowodowaa innych bdw
itd. Jeli wszystko jest w porzdku, bd si zamyka. Krzywa ta znajduje si
poniej krzywej bdw rozwizanych z tego samego powodu, co krzywa
rozwizanych nie nada sa krzyw otwartych - testerzy nie zdaj
zamyka bdw natychmiast, kiedy zostan naprawione, poniewa ich czas
pochania przede wszystkim testowanie caej reszty oprogramowania. W
kocu jednak zalegoci zostaj nadrobione i krzywa bdw zamknitych
czy si z krzyw bdw rozwizanych, gdy obie spaszczaj si - kiedy
znajduje si coraz mniej nowych bdw.
O czym mwi nam ten wykres? Obszary czarny i szary informuj, ile pracy
pozostao jeszcze programistom i testerom. Poszerzajcy si pas czarny
ostrzega, e programici zostaj coraz dalej i dalej w tyle z rozwizywaniem
znalezionych bdw. Poszerzajcy si pas szary wskazuje, e testerzy coraz
bardziej nie nadaj z ponownym testowaniem bdw juz naprawionych.
Kiedy krzywe wypaszczaj si i zbliaj do siebie, kierownik projektu
zaczyna lepiej w nocy spa.
Ten wykres zwykle rysuje si w kolorach. Czerwony oznacza bdy
otwarte, ty - rozwizane, a zielony - zamknite. Jeden rzut oka
pokazuje, w jakim stanie znajduje si projekt. Duo czerwieni oznacza
duo pracy dla programistw. Duo tego oznacza peno pracy dla
testerw. Duo zieleni oznacza, e projekt zblia si do koca.
Poczenie krzywych iloci bdw otwartych, rozwizanych i zamknitych
na jednym wykresie pozwala zobaczy caociowy obraz stanu projektu i
zmniejsza ryzyko bdnej interpretacji danych. Wspomniano ju, e
spaszczenie krzywej iloci otwartych bdw mogo oznacza albo brak
bdw, albo brak testerw. Rnicy nie dao si dostrzec na podstawie
dostpnych danych. Jeszcze inna moliwo to e zesp testerw
postanowi przez kilka dni powici si gwnie testowaniu naprawionych
bdw i nie wykonywa duo nowych testw. Majc te informacje dostpne
jednoczenie na jednym wykresie mona atwiej zrozumie, co si stao.
Pamitajmy o tym usiujc odpowiedzie na jedno z pyta zmaykajcych
rozdzia.
Podsumowanie
Strona 84 (84)
Opisane w tym rozdziale rodzaje pomiarw nie s w adnym razie list
ostateczn. Sa to tylko przykady powszechnie stosowanych pomiarw
uywanych do ledzenia i okrelania statusu projektw informatycznych.
Kady zesp projektowy, kierownik projektu albo tester wybierze te
pomiary, ktre w jego odczuciu najlepiej informuj go o stanie projektu.
Niektrzy mog ledzi redni waro wagi znajdowanych bdw. Dla
innych bdzie waniejsze, jak szybko znajdowane bdy s rozwizywane.
Kto moe chcie wiedzie, ile bdw przecitnie znajduje w cigu jednego
dnia lub jaki jest stosunek iloci jego bdw znalezionych do
naprawionych. Calem dokonywania pomiarw i posugiwania si ich
wynikami jest wiedzie, jak dobrze nam wychodzi praca, czy wszystko
toczy si zgodnie z planem, a jeli nie - co mona zrobi by poprawi
sytuacj.
Rozdzia 20-y "Zapewnienie jakoci oprogramowania" zapozna nas z
kolejnym poziomem na drabinie ewolucyjnej, sigajcym poza testowanie
oprogramowania, gdzie pomiarw nie uywa si tylko dla celw jednego,
biecego projektu, ale rwnie aby oceni i ulepszy cao procesu
wytwrczego.
Pytania
1.Czemu - wykorzystujc dane pomiarowe z bazy danych ze znalezionymi
bdami - liczenie tylo i wycznie iloci bldw znalezionych jednego
dnia lub obliczenie redniej iloci bdw znajdowanych dziennie nie
daoby wystarczajcgo obrazu stanu projektu?
2.Uzupeniajc odpowied na pytanie 1-e, jakie inne dane pomiarowe
warto wzia pod uwag, aby trafnie i skutecznie mierzy jako wasnej,
osobistej jakoci pracy jako testera?
3.Jak wygldaoby pytanie postawione bazie danych (wolno uy
dowolnego formatu i skadni "pseudojzyka"), ktre miaoby wydoby z
niej wsztystkie rozwizane bdy, przypisane Terry'emu, w projekcie
Calc-U-Lot, wersja 3.0?
4.Jeli tempo znajdowania nowych bdw sabnie (jak na rysunku 19.8) i
wszyscy bardzo si ciesz, e projekt zblia si do celu, jakie mog by
powody (wymie kilka), e liczby kami, tj. e stan produktu/projektu
wcale nie jest dobry, mimo e bdw znajduje si coraz mniej?
Strona 1 (28)
VI Przyszo
Kiedy tylko zaczlimy programowa, okazao si - ku naszemyu zdumieniu e wcale nie byo tak atwo jak sdzilimy zrobi programy bezbdnie.
Przyszo nam wwczas odkry usuwanie bdw z programu,
odpluskwianie. Pamitam do dzi dokadnie t chwil, kiedy sobie
uiwadomiem, e znaczn cz ycia spdz szukajc bdw we wasnych
programach.
-
Maurice Wilkes, jeden z pionierw komuteryzacji
W TEJ CZCI
Zapewnienie jakoci oprogramowania
Kariera testera oprogramowania
Strona 2 (28)
Zapewnienie jakoci oprogramowania

W TYM ROZDZIAE
Jako jest za darmo
Test i zapewnienie jakoci w przedsibiorstwie
Zarzdzanie testowaniem a struktury organizacyjne
CMM (Model Poziomu Jakoci Procesu Wytwarzania)
ISO 9000
Tematyka tej ksiki jest zgodna z jej tytuem dotyczy przede wszystkim
testu oprogramowania. Nauczylimy si jak planowa testowanie, gdzie
szuka bdw, jak je znajdowa i jak raportowa. Kto jest w tej brany
pocztkujcy, przypuszczalnie z tymi wlanie czynnociami zetknie si
najpierw.
Warto jednak umie spojrze na t dziedzin z szerszej perspektywy, aby
zdawa sobie spraw, co jeszcze mona osiagn i jakie istniej moliwoci
dalszej kariery. Celem tego rozdziau jest przedstawi to, co znajduje si
poza testowaniem oprogramowania, nakreli moliwosci i wyzwania, i
zmotywowa miejmy nadziej czytelnikw do uczynienia z jakoci
swojego wasnego celu.
1. Jaki jest koszt wytwarzania oprogramowania o
wysokiej jakoci?
2. Jaka jest rnica midzy testowaniem a
zapewnieniem jakoci oprogramowania?
3. Rne formy, w jakich grupa odpowiedzialna za
test - lub szerzej za jako - moe uczestniczy
w pracach projektu
4. Jak stosowa CMM?
5. Standard ISO 9000
Jako jest za darmo
Strona 3 (28)
Jako za darmo? Niedmoliwe! Nie, to prawda. Philip Crosby1 napisal w
swojej ksice Jako za darmo: co zrobi by osign jako na pewno?
(Quality is Free: The Art of Making Quality Certain), e zbudowanie
produktu o wysokiej jakoci nie kosztuje wcale wicej (czsto mniej) ni
produktu o niskiej jakoci. Wziwszy pod uwag to, czegomy si dotd
nauczyli na temat iloci pracy niezbdnej do znajdowania i poprawiania
bdw, moe si to wydawa niemoliwe a jednak jest moliwe.
Przypomnijmy sobie wykres z rozdziau 1-ego (powtrzony poniej jako
rysunek 20.1), pokazujcy koszty znajdowania i naprawiania bdw w
rnych fazach ycia produktu. Im pniej znajduje si bdy, tym bardziej
kosztowna jest ich naprawa nie jest to w dodatku zaleno liniowa, lecz
wykadnicza.
Teraz podzielmy koszty jakoci na dwie grupy: koszty osignicia i koszty
nieosignicia potrzebnej jakoci. Koszty osigniecia jakoci to koszty
zwizane z planowaniem i wykonaniem wszystkich testw jeden raz, aby
zweryfikowa poprawno oprogramowania. Jeli znajduje si jednak bdy
i trzeba powici czas na ich wyizolowanie, raportowanie i testowanie
regresywne, wtedy koszt nieosignicia jakoci wzrasta. Te koszty, ktre
ponosi si przed oficjalnym wypuszczeniem produktu, klasyfikuje si jako
koszty awarii wewntrznych; znajduj si one gwnie po lewej stronie
rysunku 20.1
Koszty naprawy bdu
Specyfikacja Projekt Kodowanie Test Wdroenie

Faza, w ktrej znaleziono bd
Rysunek 20.1 Ten wykres uatwia zrozumienie, dlaczego jako jest za

darmo
Jesli bdy nie zostan znalezione i dostan si do produktu dostarczonego
do klientw, skutkiem bd kosztowne telefony do dziau obsugi,
ewentualnie naprawa, ponowne testy i wypuszczenie nowej wersji, a w
najgorszym razie koszty wycofania produktu lub procesw sdowych. Te
koszty zwane kosztami awarii zewntrznych s take kosztami
nieosigniecia jakoci i znajduj si po prawej stronie rysunku 20.1.
Philip Crosby, Joseph Juran i W. Edwards Deming s czsto okrelani jako ojcowie jakoci.
Napisali na temat zepewnienia jakoci wiele ksiek i wiele z opisanych przez nich metod jest dzi
powszechnie stosowanych na caym wiecie. Chocia ich prace nie dotycz szczeglnie
oprogramowania, odnosz si jednak w rwnym stopniu do rnych dziedzin. Miej lektury!
Strona 4 (28)
W swojej ksice Crosby demonstruje, e koszty osignicia jakoci plus
koszty awarii wewntrznych s mniejsze ni koszty awarii zewntrznych.
Niszczc wszelkie bdy jak najwczeniej, albo najlepiej nie majc w
ogle adnych bdw, uzyskujemy produkt taniej ni wtedy, kiedy awarie
zdarzaj si u klientw. Jednym sowem, jako nic nie kosztuje to czysto
zdroworozsdkowy wniosek.
Niestety, nie wszdzie w przemyle informatycznym zdoano zaakceptowa
t prost prawd. Niejednokrotnie projekt zaczyna si peen najlepszych
intencji, ale kiedy pojawiaj si pierwsze trudnoci i przestaje si nada za
harmonogramem, zasady i rozsdek wyrzucane s do kosza. Na szczcie
obserwuje si dzi rwnie tendencje odwrotne. Firmy zaczynaj zdawa
sobie spraw, e ich koszty jakoci s zbyt wysokie, ale nie musz. Klienci
zaczynaj si domaga oprogramowania dobrej jakoci, a konkurencja
zaczyna by w stanie je dostarczy. Uswiadamiamy sobie, e to co Crosby
napisa 20 lat temu z mysl o przedsibiorstwach produkcyjnych, dotyczy
jak najbardziej rwnie dzisiejszego przemyslu informatycznego.
Test i zapewnienie jakoci w przedsibiorstwie

W rnych przedsibiorstwach, a nawet w rnych projektach, zesp w
ktrego skad wchodz testerzy wystpuje pod rozmaitymi szyldami:
testowanie oprogramowania, zapewnienie jakoci oprogramowania, kontrola
jakoci, weryfikacja i walidacja oprogramowania, test i integracja
oprogramowania i wiele innych. Czsto te nazwy stosowane s zamiennie
lub jedn z nich wybiera si, bo brzmi bardziej oficjalnie, jak na przyklad
inynier zapewnienia jakoci (Quality Assurance Engineer) w porwnaniu
z testerem oprogramowania. Trzeba sobie jednak zdawa spraw, e te
nazwy w gruncie rzeczy rni si od siebie znacznie i nie s synonimami. Z
jednej strony ma si do czynienia z podejciem e to tylko nazwa, a to co
si naprawd liczy to tre wykonywanej pracy. Z drugiej strony, nazwa
zespou czy nazwa wykonywanej przez pracownika roli to jest to, co przede
wszyskim widz inni czonkowie zespou projektowego. Etykietka zespou
okrela oczekiwania innych: co dany zesp bdzie dostarcza1 i jakich
dostaw sam oczekuje. Kolejne czci tego rozdziau poswicone s
zdefiniowaniu czsto spotykanych nazw dla zespou odpowiedzialnego za
testowanie i maj na celu wyjanienie rnic miedzy nimi.
Testowanie oprogramowania (Software Testing)
Nigdy do tego powtarza, wic jeszcze raz:
Celem testowania oprogramowania jest znajdowanie bdw,
znajdowanie ich tak wczenie jak si tylko da oraz dopilnowanie, by
zostay naprawione.
Typowe nieporozumienia to np. oczekiwanie, ze zesp testowy odpowiada za wykonanie integracji

(to jest moliwe, ale wymaga o wiele wicej rodkw i innego typu umiejtnoci ni sam test) oraz e
zesp testowy odpowiada za system do raportowania bdw (przyp. tlumacza).
Strona 5 (28)
W tej ksice poznalimy wszelkie szczegy tej definicji w jaki sposb
osiagn te cele oraz ograniczenia i trudnoci w rzeczywistoci. Mona
okreli testowanie oprogramowania jako zadanie polegajce na oszacowaniu,
raportowaniu i ledzeniu. Zajduje si bdy, przekonywujco je opisuje,
informuje waciwe osoby oraz ledzi bdy, dopki nie zostan rozwizane.
Definicja pracy testera w tej ksice wykracza poza oszacowanie,
raportowanie i ledzenie, bowiem dodana jest do nich odpowiedzialno
za to, by bdy faktycznie zostay naprawione. Aczkolwiek wielu testerw
poprzestaoby na okresleniu raportowanie, ja osobicie jestem
przekonany, e bycie skutecznym testerem wymaga ponoszenia
specjalnej, osobistej odpowiedzialnoci za znajdowane bdy, ledzenia
ich przez cay cykl yciowy i nakanianie odpowiedzialnych osb do tego,
by bdy zostay naprawione. Najatwiej jest oczywicie po prostu
umieci raport bdu w bazie danych i mie nadziej, e kto go
dostrzee i co w jego sprawie zrobi, ale gdyby na tym poprzesta, kto
mgby spytac po co w ogle szuka bdw?
Pamitajmy o jednej bardzo wanej rzeczy: tester oprogramowania nie jest
odpowiedzialny za jako oprogramowania! Moe to brzmie dziwnie, ale
jest prawd. Nie tester stworzy przecie bdy w programie, plan testw
zosta zaaprobowany przez kierownika projektu i przez programistw, plan
zosta zrealizowany co do joty i mimo wszelkich wysikw, program nadal
mia bdy. To nie jest win testera!
Zastanwmy si nad tym. Lekarz nie jest w stanie spowodowa, by gorczka
spada, mierzc temperatur. Meteorolog nie powstrzyma huraganu mierzc
szybko wiatru. Tester nie potrafi naprawi produktu zej jakoci przy
pomocy samego znajdowania bdw. Testerzy po prostu melduj fakty.
Nawet jeli tester bardzo si stara, by znalezione bdy rzeczywicie zostay
naprawione, te wysiki nadal nie s w stanie przemieni zego produktu w
dobry. Jakoci nie da si wtestowa i kropka.
W niektrych przedsibiorstwach wierzy si, e jako mona stworzy
przy pomocy testowania. Zamiast poprawi metodyk wytwarzania
oprogramowania, sdzi si, e rozwizaniem jest dodanie wikszej iloci
testerw. Sdzi si, e wicej testerw, znajdujc wicej bdw, uczyni
produkty lepszymi. Ciekawe, e ci sami ludzie nigdy nie zaproponowaliby
uycia wikszej iloci ternmomwtrw, by obniy gorczk.
Kierownik zespou testujcego lub meneder testw jest odpowiedzialny za
to, by kady w zespole projektowym rozumia rol testera. Ta kwestia staje
si czsto koci niezgody gdy harmonogramu nie udaje si dotrzyma lub
gdy bdy przelizguj si przez kontrol, tak e najlepiej wyjani wszystko
z gry - w planie testowania projektu.
Zapewnienie jakoci (Quality Assurance, QA)
Strona 6 (28)
Inn nazw czsto nadawan grupie zajmujcej si poszukiwaniem bdw
jest Zapewnienie jakoci. W rozdziale 3-im zostaa podana nastpujca
definicja osoby penicej t funkcj:
Inynier zapewnienia jakoci bada i dokonuje pomiarw procesu
wytwarzania oprogramowania w celu znalezienia sposobw ulepszenia
go i zapobieenia powstawaniu bdw.
Teraz, kiedy wiemy ju wicej na teamt testowania, ta definicja chyba
wydaje si o wiele groniejsza ni kiedy przeczytalimy j po raz pierwszy.
Grupa zajmujca si zapewnieniem jakoci ma o wiele szerszy zakres
dziaania i odpowiedzialnoci ni grupa testujca - a przynajmniej tak
powinno by, zgodnie z definicj jej funkcji. Oprcz wykonywania czci
lub caoci testowania1, grupa ma za zadanie zapobiega powstawaniu
bdw i zapewnieniu waciwego (przypuszczalnie wysokiego) poziomu
jakoci i niezawodnoci oprogramowania. Ta grupa nie tylko testuje i
raportuje, lecz ma znacznie dalej idce zadania. Teraz wida dlaczego, jeli
budet i czas dostpny dla grupy pozwala tylko na wykonywanie
testownania, ryzykowne moe by przyjcie tego bardziej prestiowego
tytuu.
Mona sobie zada pytanie - skoro sam test nie jest w stanie zapewni
jakoci produktu, co grupa zapewnienia jakoci moe w tej sprawie uczyni
innego? Odpowied to pena kontrola nad projektem, wdraanie standardw
i metodologii, staranne ledzenie i monitorowanie oraz ocena jakoi
procesu wytwarzania, skadanie propozycji sposobw rozwizywania
znajdowanych problemw, wykonywanie czci testowania oraz
podejmowanie decyzji o gotowaoci produktu do wypuszczenia i dostawy. Z
pewn przesad mona okreli, e grupa zapewniania jakoci jest jakby
dodatkowym kierownikiem projektu, ktrego gwnym celem jest brak
bdw, podczas gdy waciwy kierownik projektu ma gwnie na celu
zrealizowanie projektu w ramch dostpnego budetu i harmonogramu.
Jak dowiemy si w dalszej czci rozdziau, przejcie od testowania do
zapewnienia jakoci jest zwykle stopniowym procesem, jakby osigania
kolejnych poziomw dojrzaoci. Nie jest to jeden krok - wczoraj byo si
testerem, a dzi jest si specjalist od zapewnienia jakoci.
Ile testowania powinna wykonywa grupa zapewniania jakoci zaley od poziomu jakoci procesu
wytwarzania. Dowiemy si wicej na temat poziomw jakoci procesu w dalszej czci rozdziau.
Strona 7 (28)
Niektre z umiejtnoci nabytych w trakcie lektury tej ksiki mona
okreli jako nalece do zapewniania jakoci, zalenie od tego, gdzie
przprowadzi granic midzy znajdowaniem a zapobieganiem bdom oraz
granic midzy wewntrzymi i zewntrznymi awariami. Skoro celem
zapewnienia jakoci jest zapobieganie bedom, to mona twierdzi, e
testowanie statyczne specyfikacji produktu, dokumetnacji oraz kodu
(rozdziay 4-y i 6-y) naley do zapewniania jakoci, gdy zapobiega
pojawieniu si bdw. Bdy w ten sposb znalezione i usunite nie bd
mogy by pniej znalezione przez testerw wykonujcych dynamiczne
testowanie gotowego produktu.
Total Quality Management
Kady sysza zapewne o metodach zwanych Total Quality Management
(Sumaryczne Zarzdzanie Jakoci) lub Total Quality Control
(Sumaryczna Kontrola Jakoci). Gwna myl tego podejcia zasadza si
na tym, e scentralizowane zarzdzanie jakoci - poprzez zesp
dopowiedzialny za zapewnienie jakoci - nie sprawdza si, gdy ludzie
wykonujcy faktyczn prac, jak pisanie kodu czy tworzenie elementw
graficznych, nie czuj si odpowiedzialni za jako i dlatego nie usiuj jej
osign. Aby osign produkty o wysokiej jakoci, kultura jakoci musi
by obecna w caej organizacji tak, by kady by wspodpowiedzialny za
jako.
Cho idea TQM/TCM ma istotne implikacje dla funkcji istniejcej grupy
zapewnienia jakoci, to nie elimiminuje ona oczywicie koniecznoci
testowania oprogramowania. Przeciwnie, rola testowania w rodownisku
realizujcym TQM jest jeszcze wyraniej okrelona. Mimo wszelkich
wysikw, oprogramowanie wytwarzane jest przez ludzi, a ludzie
popeniaj bdy. Naadal potrzebna jest grupa w caoci skoncentrowana
na poszukiwaniu bdw. Moe nie znajd wiele, ale to tylko dobrze!
Inne nazwy dla zespu odpowiedzialnego za test
Zalenie od miejsca pracy, mona spotka jeszcze inne nazwy na grup
zajmujc si poszukiwaniem i raportowaniem znalezionych bdw. Czsto
spotyka si okrelenie Kontrola Jakoci Oprogramowania (Software Quality
Control, SQC). Nazwa ta pochodzi z systemw produkcyjnych, gdzie
inspektorzy Kontroli Jakoci pobieraj prbki z linii produkcyjnej, testuj je
i - jeli znajd bdy - maj prawo zamkn lini produkcyjn lub nawet ca
fabryk. Niewiele zespow testujcych oprogramowanie ma tak wadz,
nawet jeli nazywaj siebie Kontrol Jakoci Oprogramowania.
Weryfikacja i walidacja oprogramowania to rwnie czsto spotykane
okrelenie organizacji testujcej oprogramowanie. To bardzo dobra nazwa.
Cho nieco przyduga, okrela dokadnie to za co grupa jest odpowiedzialna
i co robi. W rozdziale 3-im znajduj si definicje weryfikacji i walidacji.
Moga nawet istnie dwie grupy, jedna zajmujca si weryfikacj, a druga walidacj.
Strona 8 (28)
Test i integracja, test i budowa, zarzdzanie konfiguracj i test, test i
zarzdzanie laboratorium i inne podobne, zoone nazwy s z reguy
sygnaem istnienia problemw. Niejednokrotnie, dobrowolnie lub nie, grupa
testujca bierze na siebie role nie majce wiele zwizku z testowaniem. Na
przykad, czsto mona si zetkn z sytuacj, e zesp testujcy zajmuje
si zarzdzaniem konfiguracj lub integracj czy budowaniem produktu.
Wynikaj z tego dwojakie problemy:
6. Malej rodki dostpne do testowania produktu.
7. Celem grupy testujcej jest usiowanie
wywoywania awarii, a nie praca konstrukcyjna,
tak e odpowiedzialno za integracj stwarza
potencjalny konflikt interesw.
Najlepiej, eby programici albo osobny zesp byli odpowiedzialni za
integracj i budowanie systemu. Testowanie powinno mc sie
skoncentrowa na znajdowaniu bdw.
Zarzdzanie testowaniem a struktury organizacyjne

Oprcz nazwy i przyjtej oficjalnie roli, istnieje trzecie zagadnienie
wywierajce wielki wpyw na to, co robi zesp testujcy i jaka jest jego rola
w zespole projektowym. Chodzi o to, w jaki sposb zesp testowy
wczony jest w ogln struktur organizacyjn projektu. Istniej rne
struktury organizacyjne i kada z nich ma swoje plusy i minusy. O
niektrych twierdzi si, e s generalnie lepsze, ale to, co dziaa dobrze w
jednym miejscu, nie musi funkcjonowa rwnie dobrze gdzie indziej. Kto
pracuje przez duszy czas z testowaniem, zetknie si zapewne z wieloma z
tych struktur. Oto kilka przykadw.
Na rysunku 20.2 znajduje si struktura czsto stosowana przez mae (poniej
10-ciu osb) zespoy projektowe. W tej strukturze, zesp testowy
podporzdkowany jest kierownikowi produkcji, czyli osobie nadzorujcej
prac programistw. Wziwszy pod uwag to, co wiemy na temat
testowania, powinno teraz nam zamigota te wiato ostrzegawcze - jeli
osoby piszce kod i osoby szukajce w kodzie bdw podporzdkowane s
jednej i tej samej osobie, moe to spowodowa wiele problemw.
Kierownik produkcji
Testerzy
Programici
Rysunek 20.2 W strukturze organizacyjnej maego projektu zesp testowy

czsto podporzdkowany zostaje kierownikowi produktu.
Strona 9 (28)
Powstaje wtedy nieunikniony konflikt interesw. Celem kierownika
produkcji jest wytwarzanie oprogramowania. Testerzy meldujcy o
znalezionych bdach stwarzaj na pozr przeszkody w osigniociu tego
celu. Kiedy testerzy wykonuj dobrze swoja prac, praca programistw
zczyna wyglda gorzej. Jeli kierownik da do dyspozycji wicej rodkw
testerom, znajd oni zapewne wicej bdw, a im wicej bdw znajd,
tym bardziej utrudni rol kierownikowi produkcji dcemu do
wytworzenia gotowego oprogramowania.
Mimo tych minusw, struktura taka moe niele funkcjonowa pod
warunkiem, e kierownik ma due dowiadczenie i zdaje sobie spraw, e
jego rzeczywistym celem nie jest po prostu zbudowanie programu, lecz
zbudowanie programu o odpowiedniej jakoci. Taki kierownik bdzie
traktowa testerw i programistw jednakowo. Jest to rwnie bardzo dobra
struktura z punktu widzenia przepywu informacji. Jest w niej minimalna
ilo poziomw organizacyjnych, a testerzy i programici mog dobrze
razem wsppracowa.
Rysunek 20.3 pokazuje inn, czsto spotykan struktur, gdzie grupa
testowa i grupa programistw podporzdkowane s kierownikowi projektu.
W tym ukadzie grupa testowa me zwykle swego wasnego kierownika,
ktrego uwaga skoncentrowana jest wycznie na pracy zespou testujcego.
Taka niezaleno jest bardzo korzystna, kiedy podejmowane s kluczowe
decyzje dotyczce jakoci oprogramowannia. Gos zespou testujcego staje
si rwnie wany co zespou programistw i innych grup wsplpracujcych
oprzy wytwarzaniu produktu.
Minusem tej struktury jest jednak fakt, e kierownik projektu ma ostatnie
sowo przy podejmowaniu decyzji dotyczcych jakoci. W wielu branach i
dla wielu typw oprogramowania jest to rozwizanie w zupenoci
wystarczajce. Przy wytwarzaniu systemw krytycznych dla bezpieczestwa
lub innych systemw wysokiego ryzyka, opaca si niekiedy, by kontrola
jakoci bya reprezentowana na wyszym poziomie. Struktura takiej
organizacji przedstawiona jest na rysunku 20.4.
W takiej organizacji, zespoy odpowiedzialne za jako podporzdkowane s
bezporednio wyszemu kierownictwu firmy, na tym samym poziomie co
poszczeglne projekty. Zwykle dotyczy to caoci zapewnienia jakoci, a nie
tylko testowania. Niezaleno tej grupy od bezporedniego kierownictwa
projektw umoliwia jej ustalanie standardw i reg, pomiary wynikw i
przyjmowanie procesw stosowanych przez wiele projektw naraz.
Informacja na temat zej - a take dobrej - jakoci dociera wprost do
najwyszego poziomu organizacji.
Strona 10 (28)
Kierownik projektu
Kierownik produkcji
Kierownik testowania
Programici
Testerzy
Rysunek 20.3 W organizacji, gdzie zespl testowy podporzdkowany jest

wprost kierownikowi projektu, testerzy dysponuj pewn niezalenoci od
programistw.
Dyrekcja
Kierownicy
zapewnienia
jakoci/testowania
Kierownicy
produkcji
Kierownicy
projektw
Rysunek 20.4 Zesp zapewnienia jakoci albo zesp testujcy

podporzdkowany bezporednio wyszemu kierownictwu ma najwiksz
niezaleno, najwiksz wadz i najwiksz odpowiedzialno.
Oczywicie, wraz z rosnc wadz musi pojawi si wzrost
odpowiedzilanoci i powcigliwo. To, e zapewnienie jakoci jest
niezalene od projektw nie ma oznacza, e zacznie ono stawia nierealne i
niemoliwe do osignicia wymagania dotyczce jakoci, jeli takich
wymaga nie stawiaj klienci ani uytkownicy. Standard przyjty przez
przedsibiorstwo dla systemw bazodanowych moe by zbyt wymagajcy
w odniesieniu do gier komputerowych. Aby dziaa skutecznie, niezalena
organizacja zapewnienia jakoci musi umie wsppracowa z projektami i
umie poczy swj entuzjazm dla jakoci z praktycznymi wymaganiami
produkcji oprogramowania. Niezbdne s te wysiki, by utrzyma jak
najlepsze kontakty z zepoami programistw i innymi czonkami zespow
projektowych. Staje si to tym trudniejsze, im bardziej wyduaj si drogi
przepywu informacji.
Pamitajmy, e podane tu trzy struktury to tylko uproszczone przykady
wielu moliwych typw i e opisane plusy i minusy take mog by bardzo
rne. W procesie wytwarzania oporogramowania rzadko ma si do
czynienia z niezawodnymi receptami i to, co dziaa w jednym projekcie,
moe nie pasowac do innego, na pozr zupenie podobnego. Dostpne s
jednak pewne standardowe pomiary i metody sprawdzone w wielu
projektach, ktre licznym zespoom umoliwiy popraw jakoci.
Zapoznamy si nieco z nimi w dwch nastpnych podrozdziaach.
CMM (Model Poziomu Jakoci Procesu Wytwrczego)
Strona 11 (28)
Model Poziomu Jakoci Procesu Wytwrczego dla oprogramowania
(Capability Maturity Model, CMM lub CMM-SW)1 to standard stosowany
do okrelenia i pomiaru dojrzaoci procesu wytwrczego przedsibiorstwa
informatycznego i sucy do identyfikacji moliwych kierunkw poprawy
jakoci procesu. Model ten zosta skonstruowany wsplnie przez Software
Engineering Institute (SEI), Carnegie Mellon University oraz przedstawicieli
przemysu informatycznego, pod kierownictem Ministerstwa Obronu USA.
CMM ma oglny charakter i daje si zastosowa rwnie dobrze do kadego
przedsibiorstwa, niezalenie od jego wielkoci - od najwikszego koncernu
do jednoosobowej firmy doradczej. Wyrnia on pi poziomw (patrz
rysunek 20.5), ktre pozwalaj do atwo oszacowa dojrzao (jako)
procesu wytworczego przedsibiorstwa i okreli, jakie kroki naley podjc
w celu przejcia na wyszy poziom.
Poziomy jakoci procesu wg CMM
5. Staa poprawa jakoci procesu poprzez
ilociowe sprzenie zwrotne i stosowanie
nowych metod.
4. Proces kontrolowany. Szczegowe pomiary
oraz zrozumienie jakoci procesu i produktu.
3. Mylenie na poziomie organizacji.
Zorientowany zadaniowo i proaktywnie.
Udokumentowany i ustandaryzowany.
2. Mylenie na poziomie projektu. Reaktywny.
Podobne projekty mog powtrzy
wczeniejsze sukcesy.
1. Proces chaotyczny, ad hoc. Powodzenie
projektu zaley oc szczcia i od wybitnych
jednostek.
Optymalizujcy
Sterowany
Zdefiniowany
Powtarzalny
Wstpny
Rysunek 20.5 Model Poziomu Jakoci Procesu Wytwrczego stosuje si do

oceny dojrzaoci firmy w procesie wytwarzania oprogramowania.
Czytajc dalej, pamitajmy e spord wszystkich przedsibiorstw na
wiecie zajmujcych si wytwarzaniem oprogramowania, wikszo jest na
poziomie 1-ym, sporo znajduje si na poziomie 2-im, nieliczne - na 3-im,
garstka - na 4-ym, a zaledwie kilka - na 5-ym. Oto opisy 5-ciu poziomw
wyrniancyh przez CMM:
CMM, Capability Maturity Model oraz Carnegie Mellon s znakami firmowymi zarejestrowanymi w
Urzdzie Patenowym USA.
Strona 12 (28)
8. Poziom 1-y: Wstpny. Proces wytwarzania
oprogramowania na tym poziomie jest
przypadkowy i zwykle chaotyczny. Powodzenie
projektu zaley od szczcia i od
indywidulanych wysikw jednostek. Nie
stosuje si standardowych metod planowania,
monitorowania i sterowania procesem. Nie daje
si przewidzie czasu trwania i kosztw
projektu. Proces testowania jest rwnie
przypadkowy co reszta procesu wytwarzania.
9. Poziom 2-i: Powtarzalny. Najlepiej go okreli
jako mylenie na poziomie projektu.
Podstawowe elementy procesu zarzdzania
projektem stosuje si do ledzenia kosztw,
harmonogramu, funkcjonalnoci i jakoci
projektu. Stosuje si niekiedy dowiadczenia
zdobyte w poprzednich, analogicznych
projektach. Jest poczucie pewnej dyscypliny.
Stosuje si podstawowe metody testowe, jak
planowanie testowania i dokumentacj zada
testowych.
10. Poziom 3-i: Zdefiniowany. Pojawia sie
mylenie organizacyjne nie tylko na poziomie
projektu. Najwaniejsze czynnoci kierownicze i
inynierskie s unormowane i udokumentowane.
Normy te stosuje si w rnych projektach.
Norm i standardw nie zarzuca si pod
wpywem trudnoci czy popiechu.
Dokumentacja testowa i plany testowania
podlegaj inspekcjom, zamin testowanie si
rozpoczyna. Zesp testujcy jest niezaleny od
programistw. Wyniki testowania analizowane
s dla oszacowania tego, czy produkt jest juz
gotowy.
11. Poziom 4-y: Sterowany. Na tym poziomie
proces organizacyjny znajduje si pod kontrol
statystyczn. Jako produktu definiowana jest z
gry wg kryteriw ilociowych (np. "produkt nie
zostanie wypuszczony dopki czsto bdw
nie zejdzie poniej 0,5 bdu na 1000 linii
kodu"). Wytwarzanie produktu nie zostaje
zakoczone, dopki wymagane kryteria nie
zostan spenione. Szczegy dotyczce procesu
i jakoci produktu s gromadzone w trakcie
trwania projektu i dokonuje si korekt w celu
utrzymania projektu na kursie.
Strona 13 (28)
12. Poziom 5-y: Optymalizujcy. Poziom ten
nazywany jest optymalizujcym (nie
"optymalnym"), poniewa dokonuje si na nim
nieustannych poprawek i korekt poziomu 4-ego.
Prbuje si stosowa nowe technologie i
sposoby pracy, wyniki s mierzone. Stosuje si
zarwno zmiany przyrostowe jak i skokowe w
celu poprawienia jakoci. Kiedy kto mgby ju
pomysle, e zosta osignity najlepszy
moliwy stan, koo obraca si jeszcze raz i
podejmuje si kolejne wysiki w celu osignicia
jeszcze wyszego poziomu.
Czy opis ktrego z poziomw brzmi znajomo? Strach pomyle, e
wikszo oprogramowania wytwarzana jest na poziomie 1-ym, ale czsto
nie dziwi to nikogo, kiedy si uyje programu. Czy jednak odwaylibymy
si przej przez most, lecie samolotem albo wsi do windy zbudowanej
na poziomie 1-ym? Pewnie nie. Kiedy - miejmy nadziej - konsumenci
zaczn energiczniej domaga si wyszej jakoci oprogramownaia i firmy
stopniowo zaczn si wspina na wysze poziomy modelu CMM.
Trzeba zdawa sobie spraw, e naley do roli testra propagowa
osignicia przez przedsibiorstwo wyszego poziomu CMM. Taka
decyzja powinna byc podjta na poziomie kierownictwa przedsibiorstwa,
wdroona odgrnie. Zaczynajc now prac jako tester, warto wszake
oszcowa z grubsza, na jakim poziomie dojrzaoci znajduje si nowa
firma i zesp testowy, w ktrym przyjdzie nam pracowa. Majc te dane,
lub wiedzc do jakiego poziomu firma dy, atwiej bdzie mie samemu
realistyczne oczekiwania i trafniej zrozumie, czego przedsibiorstwo
moe oczekiwa od testera.
Wicej informacji na temat CMM mona znale w witrynie Software
Engineering INstitute, www.sei.cmu.edu/cmm.
ISO 9000
Midzynarodowa Organizacja Standaryzacyjna (International Organisation
for Standardisation, ISO) ma seri standardw 9000, ktre odnosz si
rnie do jakoci oprogramowania. ISO jest midzynarodow organizacj
ustalajc standardy dla wszystkiego, od rubek i bolcw poczwszy, a
skoczywszy - w swojej serii standardw 9000 - na zarzdzaniu jakoci i
zapewnianiu jakoci.
Prawie kady zetkn si w jakiej formie z ISO 9000, choby w reklamach
produktw czy usug przedsibiorstw. Czsto odnonik do ISO 9000
wystpuje w postaci maego logotypu obok nazwy firmy. Nie jest atwo
osignc certyfikat ISO 9000, wic fima ktre to osigna pragnie ten fakt
pokaza ewentualnym klientom, zwaszcza jeli jej konkurencja takego
certyfikatu nie ma.
Strona 14 (28)
ISO 9000 jest zbiorem standardw dotyczcych zarzdzania i zapewnienia
jakoci, ktre definiuj podstawowy zestaw dziaa, pozwalajcych firmie
dostarcza produkty zgodnie z wymaganiami jakoci jej klientw. Nie ma
znaczenia czy ma si do czynienia z wielomiliardow korporacj, czy te z
firm mieszczc si w garau, czy produktem jest oprogramowanie, sprzt
rybacki, czy dostawy pizzy do domu. Zasady dobrego zarzdzania odnosz
si do nich w tym samaym sotpniu.
ISO 9000 ma dwie wane zalety:
13. Dotyczy procesu wytwrczego, nie za
produktu. Obiektem jej zainteresowania jest
sposb, w jaki organizacja wykonuje sw prac,
a nie wyniki tej pracy. Nie usiuje zdefiniowa
poziomw jakoci dla produktw schodzcych z
tamy produkcyjnej lub dla oprogramowania na
pycie CD. Jak ju wiemy, pojcie jakoci jest
wzgldne i subiektywne. Celem
przedsibiorstwa powinno by osignicie
poziomu jakoci zgodnego z oczekiwaniami
klientw. W osigniciu tego celu pomoe
znaczco dobrej jakoci proces wytwrczy.
14. ISO 9000 wyznacza jedynie, jakie s
wymagania dotyczce procesu, a nie jak je
speni. Na przykad, standard okrela, e zesp
projektowy powinien zaplanowa i wykona
przegldy projektw produktu (patrz te
rozdziay 4-y i 6-y), ale nie okrela, w jaki
sposb speni to wymaganie. Wykonywanie
przegldw projektw konstrukcji jest podane
i powinno by wykonane przez odpowiedzialny
zesp projektowy (dlatego wchodzi w skad
ISO 9000), ale dokadnie w jaki sposb takie
przegldy bd realizowane pozostawia si do
decyzji zespou wykonujcego produkt. ISO
9000 okrela co trzeba wykona, ale nie - jak.
Przedsibiorstwo, ktre otrzymao certyfikat ISO 9000, osigno
okrelony poziom kontroli jakoci w swoim procesie wytwrczym. Nie
oznacza to jednak, e jego produkty take osigny okrelony poziom
jakoci - aczkolwiek jest prawdopodobne, e jego produkty bd lepszej
jakoci ni pochodzce z firmy, ktra ISO 9000 nie osigna.
Z tego powodu, gwnie w Unii Europejskiej, ale coraz czciej rwnie
w USA, klienci oczekuj, e ich dostawcy bd mieli certyfikat ISO 9000.
Z dwch dostawcw konkurujcych o ten sam kontrakt, ten z nich ktry
ma certyfikat ISO 9000 bdzie w korzystniejszej sytuacji.
Strona 15 (28)
Standardy z rodziny ISO 9000 stosujce si do oprogramowania to ISO
9001 oraz ISO 9000-3. ISO 9001 dotyczy przedsibiorstw ktre projektuj,
wytwarzaj, produkuj, instluj i zajmuj si obsug produktw. ISO
9000-3 dotyczy przedsibiorstw ktre wytwarzaj, dostarczaj, instaluj i
pielgnuj oprogramowanie.
Nie da si w tym rozdziale poda w szczegach wszystkich wymaga ISO
9000, ale ponisza lista powinna pozwoli si zorientowa, jakie rodzaje
kryteriw wchodz w skad standardu. Mijemy nadziej, e wiadomo
istnienia midzynarodowej inicjatywy majcej na celu pomc
przedsibiorstwom stworzy lepszy proces wytwarzania oprogramowania
przyczyni si te do poprawienia humoru czytelnikowi.
Oto niektre z kryteriw ISO 9000-3:
15. Naley sporzdzi szczegowe plany kontroli
jakoci, procedury zarzdzania konfiguracj,
weryfikacji i walidacji produktu (testowanie),
niezgodnoci (bdw) i dziaa korekcyjnych
(napraw).
16. Naley sporzdzic i otrzyma akceptacj planw
wytworzania oprogramowania, w skad ktrego
wejdzie definicja projektu, lista celw projektu,
harmonogram projektu, specyfikacja produktu,
opis organizacji projektu, analiza ryzyka i
zaoe oraz starategi kontrolowania ryzyka.
17. Specyfikacja produktu powinna by
sformuowana w sposb zrozumiay dla klienta i
uatwiajca przeprowadzenie walidacji w trakcie
testowania.
18. Naley zaplanowa, okreli, udokumentowa i
wykonywa przegldy projektw
oprogramowania.
19. Naley sporzdzi procedury kontrolne dla
zmian przeprowadzanych w konstrukcji
produktu w trakcie jego cyklu yciowego.
20. Naley sporzdzi i udokumentowa plan
testowania oprogramowania.
21. Naley sporzdzi metody pozwalajce na
kontrol, czy produkt spenia wymagania
klienta.
22. Naley przeprowadzi walidacj
oprogramowania i test akceptacyjny.
23. Naley zachowa wyniki przeprowadzonych
testw.
24. Naley kontrolowa w jaki sposb znalezione
bdy s badane i rozwizywane.
Strona 16 (28)
25. Naley mc udowodni gotowo projektu
przed jego dostarczeniem do klienta.
26. Naley mie procedury kontrolowania procesu
wypuszczania i dostawy produktu.
27. Naley zidentyfikowa i zdefiniowa, jakie
pomiary dotyczce jakoci bd wykonywane.
28. Naley stosowa metody staystyczne do
kontrolowania procesu wytwarzania
oprogramowania.
29. Naley stosowa metody statystyczne do
oszacowania jakoci produktu.
Wszystkie te wymagania wydaj sie do podstawowe i
zdroworozsdkowe. Mona zada sobie pytanie, jak przedsibiorstwo jest w
ogle w stanie stworzy oprogramowanie nie majc do dyspozycji procesu
speniajcego te kryteria. Zdumiewa, e jest to w ogle moliwe, ale
jednoczenie wyjania, dlaczego tyle dostpnych na rynku programw jest
penych bdw. Mona mie nadziej, e z czasem konkurencja i
wymagania klientw zmusz coraz wicej przedsibiorstw w przemyle
informatycznym do spenienia zasad ISO 9000.
Kto jest zainteresowany, by dowiedzie sie wicej na temat ISO 9000,
znajdzie materiay w nastpujcych witrynach WWW:
30. Midzynarodowa Organizacja Standaryzacyjna
(ISO), www.iso.ch
31. Amercian Society for Quality (ASQ),
www.asq.org
32. American National Standards Institute (ANSI),
www.ansi.org
Podsumowanie
Jedno z praw Murphy'ego gosi, e nigdy nie ma doc czasu, by wykona
co poprawnie, ale zawsze jest do czasu, by zrobi to od nowa - brzmi jak
firma na poziomie pierwszym CMM, prawda? Zapomijmy o Murphym i
pomylmy o Philipie Crosby. Mia ona racj goszc, e jako zaiste jest za
darmo. To tylko kwestia tego, by zesp projektowy pracowa wedug
procesu, bez nadmiernego popiechu, z sposb zdyscyplinowany i usiujc
wykonywa wszystko poprawnie ju od pocztku.
Strona 17 (28)
Oczywicie, mimo wszelkich wysikw, ludzie nadal bd si myli, a bdy
bd si pojawia. Celem zapewnienia jakoci jest, aby przyczyny bdw to
byy rzeczywicie pomyki, nie za skutki gbokich problemw procesu
wytwarzania. Test oprogramowania bdzie nadal niezbdny nawet w
najlepszej organizacji, ale jeli wszystko poszoby dobrze, praca testera
moe ogranicza si do czsto powtarzanego stwierdzenia "Nie, dzisiaj nie
znalazem adnych bdw, ale mijemy nazdziej, e znajd co jutro".
Ksika jest ju niemal zakoczona. Pozosta jescze jeden rozdzia, gdzie
nauczymy si, jak zdobywa dalsze dowiadczenie w testowaniu
oprogramowania i gdzie szuka dalszych informacji.
Pytania
1. Czemu istniej koszty testowania, zwizane z
kosztami osignicia jakoci?
2. Prawda czy fasz: zesp testowy jest
odpowiedzialny za jako.
3. Czemu nieatwo jest speni wszystkie
wymaganaia, ktre implikuje tytu inyniera
zapewnienia jakoci?
4. Czemu korzystne jest, by grupa odpowiedzialna
za test lub zapewnienie jakoci bya
podporzdkowana bezporednio kierownictwu
firmy?
5. Na jakim poziomie CMM bdzie firma, ktra
spenia warunki standardu 9000-3 dla
oprogramowania?
Strona 18 (28)
Kariera testera oprogramowania

W TYM ROZDZIAE
Praca testera
Jak znale prac jako tester?
Jak zdoby praktyczne dowiadczenie?
Wyksztacenie, szkolenia, certyfikaty
Doczenia internetowe
Organizacje
Dalsza lektura
Zaczynamy ostatni rozdzia testowania oprogramowania. No, moe raczej
ostatni rozdzia ksiki Testowanie oprogramowania, lecz bez wtpienia nie
pracy. Praca w tej brany dopiero si rozpoczyna.
Zaczlimy zapewne lektur tej ksiki nie wiedzc wiele na temat
testowania. Mielimy - jak wszyscy - nieco dowiadcze z drobnymi
irytacjami i niewielkimi awariami komputera w domu lub w pracy.
Czytalimy te troch na temat wikszych bdw oprogramowania i o
znanym bdzie roku 2000-ego, ktry jednak - po trwajcych do ostatniej
chwili przygotowaniach i testowaniu, nie mia tak gronych skutkw jak si
tego obawiano.
Przypuszczalnie teraz rozumiemy ju, dlaczego takie bdy si zdarzaj
mimo wysikw osb wytwarzajcych oprogramowanie. Poznalimy proces
planowania testowania, gdzie szuka bdw i jak raportowa znalezione.
Rozumiemy ju trudny proces decyzyjny, kiedy rozstrzyga si, ktre bdy
naprawi, a ktre mona odoy na potem. Widzielimy wykresy, ktre
idnetyfikoway produkt gotowy do wypuszczenia oraz inny, wymagajcy
jeszce wiele pracy.
Przede wszystkim jednak, rozumiemy ju e testowanie oprogramowania
jest trudn i skomplikowan prac. Aby si powioda, konieczne s
dyscyplina, szkolenia i dowiadczenie. Nie da si po prostu usi, wali w
klawisze i pokrzykiwa do programisty za ciank dziaow, kiedy dzieje si
co dziwnego. Oprogramowanie jest zbyt wane. Biznesy si waliy, kariery
zostay zrujnowane i ludzie ginli z powodu bdw w oprogramowaniu.
Zadaniem testera jest znalezienie tych bdw, profesjonalnie i skutecznie,
zanim wydostan si poza bram przedsibiorstwa.
W tym ostatnim rozdziale znajdziemy wskazwki, jak szuka dlaszych
wiadomoci w tej dziedzinie, jakie s moliwe dalsze drogi kariery oraz
jakie jest znaczenie jakoci oprogramowania. Najwaniejsze punkty to:
33. Drogi kariery dostpne dla testerw
oprogramowania
Strona 19 (28)
34. Gdzie szuka pracy jako tester
35. Jak zdoby wicej praktycznego dowiadczenia
w znajdowaniu bdw
36. Karta Praw uytkownika komputera
Praca testera
Jednym z powanych nieporozumie jest przekonanie, e testowanie
oprogramowania jest zajciem tylko dla pocztkujcych1. To bdne
przekonanie trwa uparcie poniewa opiera si na niewiadomoci, czym
naprawd jest testowanie oprogramowania - gwnie z powodu, e wiele
przedsibiorstw nadal produkuje oprogramowanie bez jakiegokolwiek
godnego swej nazwy procesu. Nie wszyscy wiedz jeszcze, e aby mc
wytwarza dobre oprogramowanie, potrzeba specjalistw w dziedzinie
testowania na wszystkich poziomach. Jednak waraz ze wzrostem popytu na
oprogramowanie naprawd niezawodne i wysokiej jakoci wzrasta
zrozumienie wartoci kariery testera.
Dzieki tej rosncej wiadomoci istnieje wiele interesujcych moliwoci.
Testerzy oprogramowania z kilkuletnim dowiadczeniem s bardzo
poszukiwani2. Testerzy umiejcy wykonywa testy metodami szklanej
skrzynki oraz budowa testy automatyczne s poszukiwani jeszcze bardziej.
Jeli za kto ma ju dowiadczenie z kilku projektw i potrafi pokierowa
zespoem innych testerw, jego pozycja na rynku jest ju bardzo mocna.
Naprawd, w tej chwili rynek pracy dla testerw jest rynkiem sprzedawcy.
Oto lista typowych stanowisk pracy w testowaniu oprogramowania oraz
opisy ich zawartoci. Pamitajmy, czego nauczylimy si w rozdziale 20-ym
"Zapewnianie jakoci oprogramowania", e nazewnictwo jest rnorodne i
moe wprowadza w bd, ale ostatecznie - bez wzgldu na nazw moliwe role w testowaniu oprogramowania sprowadzaj si do opisanych
niej kategorii.
37. Technik (software test technician). To naprawd
pozycja zwykle dla pocztkujcych. Jest si
odpowiedzialnym za konfigurowanie
oprogramowania i sprztu, za wykonywanie
prostych skryptw testowych albo
automatyzacji. Bby moe bdzie si te
pracowa z testami beta w celu izolowania i
odtwarzania znalezionych bdw. Czc pracy
Nietety, jake czsto to nieporozumienie potwierdza smutna rzeczywisto (przyp. tumacza).
Ponisze wywody dotycz gwnie amerykaskiego rynku pracy. W Europie s znaczne rnice
midzy krajami przodujcymi jeli chodzi o test (Wielka Brytania, Irlandia, Holandia, kraje
Skandynawskie, czciowo Niemcy), a krajami bardzo pod tym wzgldem "zacofanymi" (mwic
oglnikowo - basen Morza rdziemnego oraz Europa Centralna). Co oczywicie nie wyklucza
istnienia pojedynczych firm wybijajcych si ponad przecitno (przyp. tumacza).
Strona 20 (28)
moe by mudna i monotonna, ale jest to dobre
stanowisko wprowadzajce do pracy testera1.
38. Tester (software tester lub software test
engineer). Wiele przedsibiorstw wyrnia kilka
poziomw testerw zalenie od dowiadczenia i
umiejtnoci. Tester na najniszym poziomie
moe wykonywac zadania technika, stopniowo
awansujc i wykonujc coraz bardziej
skomplikowane testy. Idc dalej, zaczyna si
samemu pisa procedury i zadania testowe,
uczestniczy si te w przegldach projektw i
specyfikacji. Tester wykonuje testy oraz izoluje,
odtwarza i raportuje znalezione bdy. Kto umie
programowa, bdzie take czsto pisa
programy do automatycznego testowania oraz
wsppracowa blisko z programistami w czasie
wykonywania testowania metodami szkalnej
skrzynki.
39. Kierownik zespou testowego (software test
lead). Kierownik zespou odpowiada za test
znazcnej czci projektu, czasami za cay
niewielki projekt. Zwykle pisze plan testowania
dla swojego obszaru odpowiedzialnoci i
nadzoruje testowanie wykonywane przez
innych. Czsto kierownik zespou testujcego
bdzie zaangaowany w zbieranie pomiarw i
prezentowanie ich kierownictwu projektu.
Zwykle wykonuje te w pewnym zakresie
samemu obowizki testera.
40. Meneder testw (software test manager).
Kierownik testw nadzoruje testowanie w caym
projekcie lub w kilku projektach. Podlegaj mu
kierownicy zespow tesujcych. Wsppracuje
z kierownikiem projektu przy ustalaniu
harmonogramw, celw i priorytetw. Jest
odpowiedzialny za dostarczenie odpowiednich
rodkw - osb, sprztu, powierzchni do pracy
itd. - w podlegych mu projektach. Ustala
strategi testowania dla podlegych zespow.
Jak znale prac jako tester?

Gdzie wic szuka pracy z testowaniem oprogramowania? Odpowied
brzmi - w tych samych miejscach gdzie szuka pracy programista - we
Dla skomplikowanych systemw technicznych moe by to stanowisko wymagajce - przeciwnie ni

tu opisano - ogromnego dowiadczenia (przyp. tumacza).
Strona 21 (28)
wszelkich przedsibiorstwach zajmujcych si wytwarzaniem
oprogramowania2.
41. Internet. Szybkie przeszukanie przy uyciu
kilku szperaczy tu przed oddaniem tej ksiki
do druku zaowocowao znalezieniem ponad
1000 stanowisk zwizanych z testowaniem
oprogramowania. Wikszoc z nich byy to
stanowiska na najniszym poziomie. Znalazo
si kilka zaj dla testerw przy testowanmiu
programw muzycznych, telewizji interakcyjnej,
sieci, sprztu medycznego, witryn WWW - bra
i wybiera.
42. Gazety i czasopisma. W odpoweidnim dziale
ogosze gazet i czasopism lokalnych lub
oglnokrajowych. Rwnie czasopisma
komputerowe mog by rdem stosownych
ogosze.
43. Po prostu spyta. Jeli jest si
zainteresowanym pewn technik lub okrelon
aplikacj, czy moe bran, warto znale
stosowne przedsibiorstwa i zadzwoni do nich
lub wysa im swj list motywacyjny oraz
yciorys. Czsto s wolne stanowiska, ktre nie
zdyy pojawi si w formie ogoszenia.
Aktywni testerzy zapi je, zanim ktokolwiek
inny dowie si o ich istnioeniu.
44. Praktyki w firmie. Stundenci mog prbowa
znale sobie praktyki wakacyjne - lub dusze w przedsibiorstwach jako testerzy.
Niejednokrotnie takie praktyki okazuj si
doskonaym wprowadzeniem do pracy testera.
Jeli pracuje si dobrze i ma troch szczcia,
praktyka moe doprowadzi do oferty
normalnego zatrudnienia po ukoczeniu
studiw.
Co nie musi oznacza przedsibiorstw, dla ktrych wytwarzanie oprogramowania jest gn

dziaalnoci biznesow! Banki, firmy ubezpieczeniowe, administracja publiczna wszelkich szczebli,
firmy lotnicze, samochodowe, energetycze, firmy telekomunikacyjne, operatorzy telefoniczni lista
jest duga (przyp. tumacza).
Strona 22 (28)
45. Zastpstwa i prace zlecone. Czasem
przedsibiorstwa wynajmuj testerw na krtkie
kontrakty, kiedy nastpuje spitrzenie pracy
testowej w jakim projekcie. Takie zajcie moe
trwa kilka tygodni lub kilka miesicy, a w tym
czasie zdobywa si cenne dowiadczenie, uczc
si w trakcie pracy. Niektrzy bardzo ceni
sobie t form, poniewa umoliwia ona
wyprbowanie pracy w rnych
przedsibiorstwach i z rnymi typami
oprogramowania.
Jak zdoby praktyczne dowiadczenie?

Testowanie oprogramowania niczym nie rni si od innych dziedzin
komputerowych - mona o nim czyta dugo, ale trudno je tak naprawd
zrozumie, dopki si go nie wyprbuje w praktyce. Dlatego najlepiej
nauczy si testowania oporgramowania prbujc samemu, na wasnmym
komputerze i na wasnych programach.
Wybieramy program dobrze znany albo taki, ktrego nigdy wczeniej nie
uywalimy. Podrcznik i pliki pomocnicze traktujemy jako specyfikacj
produktu. Potem piszemy plan testowania, konstruujemy zadania testowe i
szukamy bdw. Znalezione bdy rejestrujemy przy pomocy arkusza
kalkulacyujnego lub programu do przetwarzania tekstu. Znalezione bdy
mona przesa do firmy, ktra wyprodukowaa program (prawie wszystkie
firmy komputerowe daj moliwo zgaszania bdw za pomoc swoich
witryn WWW). Bdziemy zdumieni tym, co znajdziemy, a firma moe
rwnie.
Majc pewne dowiadczenie z tego rodzaju testowaniem, mona zgosi si
do testw beta dla nowych produktw informatycznych. Jak dowiedzielimy
si w rozdziale 15-ym "Polowanie na bdy i testowanie beta", testerzy beta
otrzymuj kopie aplikacji zanim jest ona dostarczona klientom. Daje to
mono posugiwania si programem jeszcze nie cakiem ukoczonym,
znajdowania bdw, ktre przepucili testerzy w przedsibiorstwie oraz - na
podstawie tego, co si znajdzie - moe uda si wywrze wpyw na
konstrukcj aplikacji. Rne firmy maj rne systemy administrowania
testerami beta. Warto poszuka na witrynie WWW firmy sw "beta tester"
lub sprbowa zadzwoni i uzyska informacje telefonicznie.
Uywajc aplikacj w wersji beta na wasnym komputerze w domu warto
zachowa ostrono. Wersja beta nie jest gotowa i z reguy peno w niej
jest bdw. Niektre bdy mog spowodowa powane problemy z
pozostaymi aplikacjami na uywanym komputerze, czste awarie i nawet
utrat danych. Warto zrobi kopie zapasowe wszystkich wanych rzeczy
przed przystpieniem do testw beta.
Strona 23 (28)
Innym sposobem zdobycia dowiadczenia jest zgosi si do testw
uytecznoci (rozdzia 11, "Testowanie uytecznoci"). Wiele firm
produkujcych oprogramowanie dla komputerw osobistych ma wasne
laboratoria uytecznoci lub kontrakty z niezalenymi laboratoriami
uytecznoci. Kogo interesuje testowani interfejsu uytkownika, powinien
wykona kilka telefonw i zorientowa si w moliwociach uczestniczenia
- w roli osoby badanej - w testach uytecznoci. Czsto bdzie si musiao
wypeni ankiet przeznaczon do pomiaru dowiadcczenia osb badanych z
pewnymi typami oprogramowania. Projekty wchodzce w faz testowaia
uytecznoci potrzebuj rnych osb - od zupenie pocztkujcych a po
specjalistw. Jeli si pasuje do ktrej z tych rl, zostanie si wezwanym do
wyprbowania okrelonych funkcji nowego produktu. W czasie
wykonywania zleconych zada jest si obserwowanym przez osoby
administrujce testami - co si robi, jak si to robi, jak reaguje si na
dziaania programu. Mona zosta zaproszonym ponownie, kiedy firma
testuje uyteczno ponownie po przeprowadzneiu rnych zmian. Czsto
firma testujca oferuje jak form wynagrodzenia - zwykle w postaci
darmowego oprogramowania.
Wyksztacenie, szkolenia, certyfikaty

Rosnca wiadomo, e test oprogramowania jest odrbn i wan
dziedzin spowodowaa, e niektre uczelnie zaczy prowadzi zajcia z
tego przedmiotu1. Studiujc informatyk lub elektronik, warto sprbowa
uczestniczyc w tych zajciach. Nawet jeli ma si zamiar zosta programist
lub inynierem-elektronikiem, wiedza w zakresie testowania pozwoli
wykonywa lepiej rwnie te zawody.
Niektre uczelnie techniczne prowadz zajcia wieczorowe2 z testowania
oprogramowania i posugiwania si narzdziami do testowania. Niekiedy
uczelnie daj nawet dyplomy i certyfikaty z testowania oprogramowania.
Dobrym sposobem zdobycia wiedzy jest uczestniczenie w konferencjach
powiconych testowaniu oprogramowania. Jest ich wiele w cigu roku, w
USA i w innych krajach. Gromadz prelegentw z rnych dziedzin
testowania oprogramowania. Prezentowane materiay maj zarwno
chrakter dla pocztkujcych, jak i bardzo zaawansowany. Bardzo cenna na
konferencjach jest moliwo spotkania i rozmowy z innymi testerami,
wymiany dowiadcze, anegdot i rozwiza. Ponisza lista zawiera niektre
najpopularniejsze konferencje, ale na pewneo nie jest kompletna. Wczenie
lub pominicie konferencji nie jest adnego rodzaju rekomendacj3.
1
Zwykle w ramach zaj z inynierii oprogramowania (przyp. tumacza).
Dotyczy USA. Nie znam takiego wypadku w Polsce ani gdzie indziej w Europie - ale warto moe
poszuka (przyp. tumacza).
3
List konferencji europejskich oraz pewne uzupenienia do niniejszej listy znajdzie czytelnik w licie
literatury i innych rde. W Polsce konferencje KKIO (Krajowa Konferencja Inynierii
Oprogramowania), organizowane przez PTI (Polskie Towarzystwo Informatyczne, www.pti.pl)
zawiera zwykle kilka referatw na temat testowania. Na razie innych konferencj krajowych na ten
Strona 24 (28)
46. International Conference and Exposition on
Testing Computer Software (TCS),
sponsorowana przez U.S. Professional
Development Institute (www.uspdi.org).
47. International Quality Week, sponsorowana
przez Software Research, Inc.
(www.soft.com).
48. International Software Testing Conference
(ISTC), sponsorowana przez Quality Assurance
Institute (www.qaiusa.com).
49. Software Testing Analysis & Review (STAR),
sponsorowana przez Software Quality
Engineering (www.sqe.com).
50. International Conference on Software
Quality (ICSQ), organizowana przez sekcj
oprogramowania American Society for Quality
(www.asq-software.org).
51. International Conference on Software Testing
(ICSTEST), organizowana przez Software
Quality Systems (www.icstest.com).
Odbywa si w Niemczech.
52. The Second World Congress for Software
Quality (2WCSQ) (www.juse.or.jp/erenmei/2WCSQMAIN.htm).
Doczenia internetowe
Internet zawiera wielkie bogactwo materiaw na temat testowania
oprogramowania. Mona zawsze szamemu uy przeszukiwarki ze sowami
"software testing" albo "software test", ale poniej podajemy list
popularnych wityn internetowych powiconych testowaniu
oprogramowania i bdom oprogramowania - dobr na pocztek1:
53. BugNet (www.bugnet.com) publikuje bdy
znalezione w popularnych programach i sposoby
ich naprawiania.
54. Software Testing Hotlist
(www.io.com/~wazmo/qa) zawiera dziesitki
docze do witryn internetowych
powiconych testowaniu oprogramowania oraz
do artykuw na ten temat.
temat nie ma, ale warto by moe sprawdza ofert IIR (www.iir.com.pl) oraz firmy Software
Konferencje (www.software.com.pl/konferencje). Przyp. tumacza.
1
Niektre inne adresy znajdzie czytelnik w licie literatury i innych rde (przyp. tumacza).
Strona 25 (28)
55. Software Testing Online Resources
(www.mtsu.edu/~strom) ogasza si sama jako
" pierwszy przystanek na Internecie dla
naukowcw i profesjonalistw w dziedzinie
testowania oporgramowania".
56. QA Forums (www.qaforums.com) jest forum
dyskusyjnym na temat testowania
oprogramowania, automatycznego testowania,
zarzdzania testowaniem, narzdzi i na wiele
innych tematw.
57. Grupa dyskusyjna comp.software.testing i jej
FAQ1 na www.faqs.org/faqs/softwareeng/testing/faq zawiera liczne dyskusje testerw
i kierownikw testw na tematy narzdzi,
technik i projektw.
58. Grupa dyskusyjna comp.risks opisuje i analizuje
aktualne awarie oprogramowania.
59. Risk Digest (catless.ncl.ac.uk/Risks/) jest forum
dyskusyjnym na temat ryzyka zwizango z
systemami komputerowymi.
Organizacje
Istnieje sporo organizacji zajmujcych si oprogramowaniem, testowaniem
oprogramowania i zapewnieniem jakoci oporgramowania. Na ich
internetowych witrynach znajduj si szczgowe opisy zakresu
dziaalnoci2.
60. The American Society for Quality (ASQ) na
www.asq.org oraz jego oddzia zajmujcy si
oprogramowaniem (www.asq-software.org)
sponsoruj Krajowe Forum Jakoci (National
Quality Forum) corocznie w padzierniku
(krajowy miesic jakoci). Organizacje te
publikuj czasopisma powicone zagadnieniom
jakoci oraz administuj dwa zawodowe
certyfikaty: Certified Quality Engineer (CQE)
oraz Certified Software Quality Engineer
(CSQE).
FAQ = Frequently Asked Questions (czsto zadawane pytania) - przyp. tumacza.
List organizacji europejskich znajdzie czytelnik w licie literatury i innych rde (przyp. tumacza).
Strona 26 (28)
61. The Association of Computing Machinery
(ACM) na www.acm.org oraz jej specjalna
grupa zainteresowa zajmujca si inynierir
oprogramowania (SIGSOFT) na
www.acm.or/sigsoft maj ponad 80.000
czonkw. SIGSOFT publikuje dwumiesicznik,
zawierajcy midzy innymi popularny dzia
zatytuowany "Publiczne zagroenia", w ktrym
opisywane s szczegy najnowszych bdw
oprogramowania.
62. The Society for Software Quality (SSQ) na
www.ssq.org okrela swj cel jako "by
uznanym Stowarzyszeniem dla osob
zainteresowanych popieraniem jakoci jako
powszechnego celu dla oprogramowania."1
Dalsza lektura
Istnieje wiele ksiek na temat testowania i zapewnienia jakoci
oprogramowania. Niektre maj charakter techniczny, inne koncentruja si
na zagadnieniach procesu i zarzdzania testowaniem. eby znale jak
interesujc pozycj, trzeba uda si do dobrze zaopatrzonego sklepu zwyklego lub internetowego2 - i szuka ksiek nastpujcych autorw:
Boris Beizer, Rex Black, Bill Hetzel, Cem Kaner, Edward Kit, Glen Myers i
Willioam Perry3.
Osobom zianteresowanym bardziej oglnymi zagadnieniami jakoci mona
poleci ksiki Philipa Crosby, W. Edwardsa Deminga i Josepha Jurana.
Podsumowanie
Autor pomija zupenie stowarzyszenia europejskie (patrz poprzedni przypis), a przede wszystkim
sponsorowany przez British Computer Society system certyfikatw dla osb zajmujcych si
zawodowo testem (wicej informacji na ten temat mona znale na www.bcs.org.uk/iseb/st). Trwaj
obecnie prace nad rozszerzeniem tych certyfikatw na wszystkie kraje europejskie. Uczestnicz w nich
Wielka Brytania, Niemcy, Szwecja, Dania, Finlandia, Belgia i Holandia (przyp. tumacza).
2
adna ze znanych mi ksigarni w Polsce nie dysponuje angielskimi ksikami z tej dziedziny.
Rozwizaniem jest jak zwykle amazon.com lub amazon.co.uk (przyp. tumacza).
3
Porzdna lista literatury i zasobw internetowych zostaa doczona do niniejszego tumaczenia

(przyp. tumacza).
Strona 27 (28)
Chciaoby si zakoczy t ksik jak mantr podsumowujc to, co
tester pragnie osign za pomoc swojej pracy. Wielokrotnie w tej ksice
pojawiaj si jadnak zastrzeenia takie jak "w zalenoci od
przedsibiorstwa lub zespou projektowego", "zalenie od brany" itp. kiedy
mowa jest o procesie wytwarzania, technikach testowania i o poziomach
jakoci. Uycie takich zastrzee uniemoliwia sformuowanie wsplnych,
oglnych celw dla jakoci oprogramowania. Niestety te zastrzeenia s
konieczne, poniewa definicja jakoci oprogramowania zaley wanie od
rozmaitych czynnikw.
W 1998 roku dr Clare-Marie Karat, psycholog i konstruktor interfejsu
uytkownika w Centrum Naukowym IBM w Hawthorne, zaproponowaa
stworzenie karty praw uytkownika. Ta karta praw definiuje minimalny
poziom jakoci, zbir minimalnych oczekiwa, ktre powinny by spenione
przez kady rodzaj oprogramowania. Przemys informatyczny ma jeszcze
przed sob dalek drog by zrealizowa wszystkie postulaty karty, ale kady
tester moe przyczyni sie do urzeczywistnienia tej wizji.
Oto karta praw uytkownika komputera (za zgod Dr Karat)1:
1.Punkt widzenia. Uytkownik ma zawsze racj. Kiedy pojawiaj si
kopoty z uyciem systemu, to system jest problemem, nie za
uytkownik.
2.Instalacja. Uytkownik ma prawo do atwej instalacji i usunicia
oprogramowania i sprztu bez adnych niekorzystnych konsekwencji.
3.Zgodno. Uytkownik ma prawo do systemu ktry dziaa dokadnie tak
jak obiecano.
4.Informacja. Uytkownik ma prawo do atwo dostpnej informacji i
wskazwek (podrczniki, pomoc interakcyjna, komunikaty o awariach)
umoliwiajcej zrozumienie i zastosowanie systemu oraz bezproblemowe
wychodzenie z sytuacji awaryjnych.
5.Kontrola. Uytkownik ma prawo do kontroli nad systemem i
otrzymywania natychmiastowych reakcji od systemu.
6.Informacja zwrotna. Uytkownik ma prawo do tego, aby system
udziela jasnej, zrozumiaej i poprawnej informacji dotyczcej aktualnie
wykonywanego zadania i jego statusu.
7.Zalenoci. Uytkownik ma prawo by jasno poinformownaym o
wszystkich wymaganiach systemu, ktre musz by spenione w celu jego
skutecznego stosowania.
8.Zakres. Uytkownik ma prawo zna wszystkie ogranicznia moliwoci
systemu.
9.Wspomaganie. Uytkownik ma prawo do porozumiewania si z
dostawc technologii i otrzymywania przemylanych i pomocnych
odpowiedzi na wszelkie zadawane pytania.
Opublikowano za zgod IBM Corporation.
Strona 28 (28)
10.Uyteczno. Uytkownik, nie program ani sprzt, ma by panem.
Produkty powinny by naturalne i intuicyjne w uyciu.
Pytania
1.Szukajc na Internecie pracy zwizanej z testowaniem, jakich sw
naley szuka startujc przeszukiwark?
2.Wymie dwa sposoby, jak mona miec do czynienia z testowaniem
oprogramownaia przed jego wypuszczeniem na rynek.
3.Jakie s cele testera oprogramowania?
Strona 1 (25)
Aneks A
Odpowiedzi na pytania
Rozdzia 1
1. Czy w opisanym przykadzie powstania bdu
roku 2000-ego programista popeni jaki bd?
Nie - o ile specyfikacja produktu nie stwierdzaa, e produkt ma dziaa
rwnie po roku 2000-ym. Tester powinien szuka i znale ten bd.
Zesp powinien podj decyzj, czy naley go naprawi.
2. Prawda czy falsz: to wane, jakim sowem firma
albo zesp nazywa problem w programie.
Fasz. To nie jest wane, ale uywane okrelenie odzwierciedla charakter
zespou testowego i jego podejcie do znajdowania, raportowania i
naprawiania problemw.
3. Dlaczego sprawdzenie tylko tego, e program
dziaa tak jak powinien, nie jest wystarczajce?
Zwykle to tylko poowa zadania testowego. Uytkownicy nie zawsze
postpuj zgodnie z instrukcj i testerzy powinni sprawdzi, co si stanie
kiedy uytkownik postpi wbrew instrukcji. Poza tym, tester powinien
podchodzi do przedmiotu testowania z nastawieniem musz to
zama, inaczej trudniej bdzie mu znajdowa bdy.
4. O ile drosze jest naprawienie bdu
znalezionego ju po wypuszczeniu produktu ni
bdu znalezionego na samym pocztku
projektu?
Od 10-u do 100-u i nawet wicej!
5. Jakie cele maj testerzy?
Celem testowania jest znajdowanie bdw tak wczenie jak to tylko
moliwe i upewnienie si, e zostay naprawione.
6. Prawda czy fasz: dobry fachowiec w dziedzinie
testowania nieugicie dy do doskonaoci.
Fasz. Dobry tester powinien wiedzie, e doskonao jest nieosigalna i
umie rozpozna, kiedy produkt jest dostatecznie dobry.
7. Podaj kilka przyczyn, dla ktych najwikszym
rdem bdw programu jest zwykle
specyfikacja produktu.
Strona 2 (25)
Czsto specyfikacji nawet nie ma - pamitajmy, e czego nie da si
powiedzie, nie da si te zrobi. Poza tym czsto, nawet jeli
specyfikacja istnieje, jest niedokadna, wci si zmienia i nie jest znana
przez cay zesp projektowy.
Rozdzia 2
1.Wymie kilka czynnoci, ktre powinno si wykona zanim programici
zaczn pisa pierwsze linijki kodu programu.
Zesp projektowy musi rozumie wymagania klienta i opisa funkcje
produktu w specyfikacji wymaga. Naley sporzdzi dokadny
harmonogram tak, by zesp zawsze wiedzia, ile pracy ju wykonano i
ile jeszcze pozostao. Naley zaprojektowa architektur systemu i jego
konstrukcj, a testerzy powinni zacz planowa swoj prac.
2. Jakie s ze strony formalnej, zamknitej
specyfikacji wymaga?
Kiedy sytuacja rynkowa zmienia si np. z powodu wypuszczenia
produktu przez konkurencj lub zmieniajcych si potrzeb klienta,
brakuje elastycznoci by mc dostosowa do niej powstajce
oprogramowanie.
3. Jaka jest najlpesza cecha modelu skokowego
wytwarzania oprogramowania?
Jest prosty. Kropka.
4. Skd wiadomo przy uyciu metody prb i
bdw kiedy oprogramowanie jest gotowe do
wypuszczenia?
Brakuje w tej metodzie jednoznacznych kryteriw wyjciowych, dopki
kto - lub harmonogram - nie powie e pora ju zakoczy.
5. Czemu model kaskadowy moe by
niewygodny?
Tak samo jak ososiowi, trudno jest pyn pod prd. Kady krok jest
dyskretnym, oddzielnym procesem nastpujcym po swoim
poprzedniku. Jeli doszo si do koca i odkryo, e co powinno byo
by zrobione inaczej wczeniej, jest zbyt pno, by si cofn.
6. Dlaczego testerzy czsto wol model spiralny od
innych?
Jest si zaangaowanym w proces wytwrczy bardzo wczenie i ma si
mono wczesnego znajdowania bdw, co zaoszczdza
projektowiczas i pienidze.
Strona 3 (25)
Rozdzia 3
1.Pamitajc, e programu nie da si przetestowa w caoci, co naley
wzi pod uwag podejmujc decyzj czy mona ju zaprzesta
testowania?
Nie istnieje jedyna, poprawna odpowied, kiedy naley przesta
testowa. Kady projekt jest inny. Oto przykady informacji, ktr trzeba
wzi pod uwag przy podejmowaniu decyzji: czy nadal znajduje si
duo bdw? czy rodzaj i ilo wykonanych dotd testw jest
satysfakcjonujca? czy zgoszone bdy zostay ocenione i czy podjto
decyzje, ktre maj by naprawione, a ktre nie? Czy dokonano
walidacji produktu wobec wymaga uytkownikw?
2. Uruchom Kalkulator w Windowsach. Napisz
5,000-5= (przecinek jest istotny). Przyjrzyj
si wynikowi. Czy jest to bd? Dlaczego?
Otrzymana odpowed wynosi 0, a nie 4995, jak mona by si
spodziewa. Dzieje si tak dlatego, e przecinek zostaje automatycznie
zamieniony na znak dziesitny. To, co zostao obliczone to 5.000 - 5 = 0,
a nie 5000-5=4995. Aby zdecydowa, czy jest to bd, naley porwna
to dziaanie ze specyfikacj produktu. Moe jest tam napisane, e
przecinki bd zmieniane na punkt dziesitny. Naley rwnie dokona
walidacji tej cechy wobec wymaga uytkownikw. Trzeba stwierdzi,
czy wikszoc uytkownikw oczekuje takiego zachowania si progamu,
czy te jest ono mylce.
3. Przy tecie gry, np. symulatora lotu albo
symulatora ruchu miejskiego, co naley
przetestowa w pierwszym rzdzie trafno czy
precyzj?
Celem symulatora jest, aby grajcy znalaz si w szcztucznym
rodowisku, ktre naladuje rzeczywiste wydarzenia. Pilotowanie w
symulatorze lotu powinno dawa wraenia zblione do pilotowania w
rzeczywistoci. Posugiwanie si si symulatorem miasta powinno
odzwierciedla sprawy, ktre dziej si w rzeczywistym miecie.
Najwaniejsze jest wic to, jak trafnie symulator odddaje rzeczywisto.
Czy samolot zachowuje si jak Boeing 757, czy jak awionetka? Czy
ksztaty gmachw przypominaj mistop, ktre symulator ma
naladowa? Kiedy trafno jest osignita, mona pokusi si take o
dokadno. Tak wanie odbywa si rozwj komputerowych gier
symulacyjnych w cigu ostatnich lat.
4. Czy mone istnie produkt informatyczny
wysokiej jakoci, ale o niskiej niezawodnoci?
Jaki mona poda przykad?
Strona 4 (25)
Tak, ale zaley to od oczekiwa klienta wzgldem jakoci. Niektrzy
ludzie kupuj sportowe samochody, o ktrych uwaa si, e s wysokiej
jakoci ze wzgldu na przypieszenie, szybko, styl i wykoczenie.
Czsto te wanie samochody s notorycznie zawodne: czsto si psuj, a
ich naprawy s bardzo kosztowne. Dla wacicieli ta wysoka zawodno
nie wpywa na ocen przez nich jakoci.
5. Czemu programw nie da si przetestowa
cakowicie?
Kady program - prcz najmniejszych i najprostszych - ma zbyt wiele
moliwych wartoci danych wejciowych, zbyt wiele rodzajw danych
wyjciowych i zbyt wiele moliwych cieek przez program, by dao si
przetestowa je wszystkie. Ponadto specyfikacje oporgramowania czsto
s subiektywne i daj si rozmaicie interpretowa.
6. Jeli testujc program w poniedziaek znajduje
si bd co godzin, jak czsto naley oczekiwa
bdw we wtorek?
Bierze si tu pod uwag dwie zasady. Pierwsza - ilo bdw jeszcze
pozostajcych w systemie jest wprost proporcjonalna do iloci bdw
ju znalezionych - oznacza, e nie zdarzy si, by przyszedszy do pracy
we wtorek nieoczekiwanie i cudownie odkry, e program sta sie
doskonay. Paradoks pastycydw gosi, e wykonujc te same zadania
testowe raz za razem, w kocu przestanie si przy ich pomocy
znajdowa nowe bdy, dopki nie doda si nowych zada testowych.
Uwzgldniwszy dziaanie obu zasad, naley si spodziewa
niezmienionego lub nieznacznie zminiejszonego tempa znajdowania
nowych bdw.
Rozdzia 4
1.Czy mona dokona testu specyfikacji metod szklanej skrzynki?
Tak, o ile tester zaangaowany jest w sam proces tworzenia specyfikacji.
W tym celu tester mgby uczestniczy w zebraniach grup
uytkownikw, badaniach uytecznoci oraz zebraniach dziau
sprzeday, aby zdoby orientacj w przebiegu procesu planowania
funkcji produktu. Istnieje jednak ryzyko, e uczestnictwo w tych
zebraniach uatwi testerowi przyjcie pniej podwiadomie zaoenia,
e specyfikacje s poprawne.
2. Podaj kilka przykadw standardw albo regu
dla oprogramowania pod Winowsami albo dla
Macintosha.
Na Macintoshu usunite pliki trafiaj do Trash Can, a w Windowsach do Recycle Bin. Nacinicie F1 zawsze powoduje wywietlenie
Pomocy.
Strona 5 (25)
Menu Plik jest w Windowsach zawsze po lewej stronie paska
funkcyjnego .
Wybranie Pomoc, Na temat powoduje wywietlenie danych na temat
praw autorskich, licencji i wersji programu.
Ctrl+X powoduje wycicie, Crtl+C skopiowanie, a Ctrl+V wklejenie.
3. Wyjanij, jaki bd znajduje si w powniszym
zdaniu ze specyfikacji wymaga: Wybranie
przez uytkownika opcji Upakuj dane
spowoduje e program zagci list danych do
najmniejeszej moliwej objtoci przy uyciu
metody macierzy Hoffmana.
Uyte jest tutaj okrelenie najmniejszy moliwy. Nie da si go
przetestowa, poniewa nie jest ani dokadne, ani wyraone liczbowo.
Specyfikacja powinna dokadnie okreli, jaki poziom zagszczenia jest
wymagany.
Ponadto sformuowanie zawiera w sobie definicj sposobu rozwizania,
wyjania jakim algorytmem posuy si ta funkcja. Ta informacja nie
powinna znajdowa si w specyfikacji wymaga. Uytkownik nie jest
zainteresowany tym, w jaki sposb odbywa si zagszczenie, tylko tym
e w ogle si odbywa.
4. Wyjanij, czemu testera powinno zaniepokoi
ponisze zdanie ze specyfikacji wymaga:
Oprogramowanie pozwoli na 100 milionw
jednoczesnych pocze, chocia zwykle nie
bdzie stosowanych wicej ni 1 milion
pocze.
atwo testowania. Nie ma znaczenia, e typowe uycie wynosi 1
milion pocze - jeli specyfikacja okrela, e 100 milionw ma by
moliwe, trzeba bdzie przetestowa 100 milionw. Tester bdzie albo
musia znale sposb przetestowania tak wielkiej liczby pocze, albo
skoni autora specyfikacji do tego, by zmniejszy maksymaln liczb
pocze tak, by bya blisza iloci typowej.
Rozdzia 5
1.Prawda czy fasz: czy da si wykonywa dynamiczne testowanie
metodami czarnej skrzynki bez specyfikacji produktu albo specyfikacji
wymaga?
Strona 6 (25)
Prawda. Technika ta nazywa si testowaniem eksploracyjnym, co polega
w gruncie rzeczy na tym, e jako specyfikacj stosuje si sam program.
Nie jest to doskonaa metoda, ale w krytycznej sytuacji moe dziaa
cakiem niele. Najwikszym ryzykiem jest to, e nie odkryje si
brakujcych funkcji.
2. Kiedy testuje si zdolno programu do robienia
wydrukw, jakie oglne, negatywne zadania
testowe s waciwe?
Mona sprbowa dokona wydruku kiedy w drukarce nie ma papieru
albo kiedy papier si pognit. Mona te drukark wyczy, odczy
od rda prdu albo odczy kabel midzy komputerem i drukark.
Mona sprbowa wydruku przy niskim poziomie farby, lub nawet po
zupenym wyjciu kartusza z farb. eby znale wszystkie moliwoci,
mona poszuka w podrczniku drukarki wszelkich opisanych bdnych
sytuacji i usiowa je wszystkie stworzy lub zasymulowa.
3. Wystartuj Notatnik Windows i wybierz funkcj
Drukuj z menu Plik. Pojawia si wtedy okno
dialogowe pokazane na rysunku 5.12. Jakie
warunki brzegowe istniej dla funkcji Zakres w
dolnym, lewym rogu okna?
Kiedy wybierze si opcj Strony, pola Od i Do s aktywne.
Narzucajcymi si warunkami brzegowymi bd wartoci 0 i 99999,
najwiksza i najmniejsza warto, ktr daje si wprowadzi do tych pl.
Nie bdzie od rzeczy przetestowa rwnie wewntrzne warunki
brzegowe takie jak 254, 255, 256 oraz 1023, 1024 i 1025. Istnieje jeszcze
inna wewntrzna granica. Sprbujmy zleci wydrukowanie stron 1- 8 z
6-stronicowego dokumentu. Zwrmy uwag, e w tym wypadku
oprogramowanie musi zaprzesta drukowania na stronie 6-ej poniewa
brak jest danych, a nie dlatego, e otrzymao tak komend. Zastanwmy
si nad innymi moliwymi warunkami tego typu.
4.Mamy pole do wprowadzania 10-cyfrowego kodu pocztowego, jak na
rysunku 5.13. Jakie klasy rwnowanoci mona zastosowa do jego
testowania?
Poprawne 5-cyfrowe kody. Poprawny oznacza e skada si on z cyfr,
a nie e jest to autentyczny kod - chocia to mogaby by inna klasa
rwnowanoci.
Poprawne 9-cyfrowe (9 cyfr i mylnik) kody.
Krtkie 5-cyfrowe.
Krtkie 9-cyfrowe.
Strona 7 (25)
Dugie 5-cyfrowe. Na przykad 8 cyfr bez mylnika. Hmm, czy to nie
jest ta sama klasa co krtkie 9-cyfrowe?
Dugie 9-cyfrowe. Moe nie da si wpisa wicej ni 9 cyfr i
mylnika, ale naley sprbowa.
Mylnik z zym miejscu.
Wicej ni jeden mylnik.
Znaki nie bdce ani cyframi, ani mylnikiem.
5.Prawda czy fasz: przejcie wszystkich stanw programu gwarantuje
rwnie, e przeszo si wszystkie przejcia midzy nimi.
Fasz. Wyobramy sobie odwiedzenie 50 miast w caym kraju. Mona
zaplanowa tras tak, eby prowadzia przez kade miasto, ale
niemoliwe jest przejechanie wszystkich drg czcych te miasta, bo to
oznaczaoby przejechanie wszystkich drg w caym kraju.
6.Istnieje wiele sposobw rysowania diagramw przejcia stanw, ale
kady z nich pokazuje trzy rzeczy. Jakie?
Kady stan w ktrym moe znale si oprogramowanie.
Dane wejciowe lub warunki, powodujce przejcie z jednego stanu
do kolejnego.
Warunki, zmienne lub dane wyjciowe, ktre powstaj kiedy
wchodzi si lub wychodzi ze stanu.
7.Podaj niektre z wartoci zmiennych w stanie pocztkowym Kalkulatora
Windowsw.
Wstpnie wywietlona warto i wewntrzna zmienna zawierajca wynik
czstkowy ustawione s na zero. Rejestry pamici (przyciski MC, MR,
MS i M+) s wyzerowane. Schowek systemowy (tam, gdzie skaduje si
dane podczas wycianania, kopiowania i wklejania) jest niezmieniony.
Inn zmienn charakteryzujc stan pocztkowy jest lokalizacja
Kalkulatora na ekranie. Jeli uruchomi jednoczenie kilka kopii
Kalkulatora, atwo zauway, e s pooone na ekranie w rnych
miejscach (przynajmniej w Windows 95/98). Mona wykonac wiczenie
w testowaniu eksploracyjnym i sprbowa domyli si, co kieruje
pooeniem Kalkulatora na ekranie.
8.Co robi si z programem, chcc odkry bdy w synchronizacji w czasie
(wycig)?
Strona 8 (25)
Naley wykonywa wiele rzeczy na raz. Mog one mie ze sob co
wsplnego, jak na przykad jednoczesne pisanie z tej samej aplikacji na
dwch rnych drukarkach. Mog by rwnie niezalene, jak
naciskanie klawiszy w czasie wykonywania przez program oblicze. W
obu wypadkach chce si wywoa sytuacj, w ktrej oprogramowanie
ciga si samo ze sob w czasie wykonywania funkcji.
9.Prawda czy fasz: jednoczesne wykonywanie testowania na obcienie i
na przecienie jest niedopuszczalne.
Fasz. Nie ma testw poniej pasa. Celem pracy testera jest znajdowa
bdy.
Rozdzia 6
1.Wymie kilka korzyci wynikajcych ze stosowania statycznego
testowania metodami szklanej skrzynki.
Stayczne testowanie metodami szklanej skrzynki pozwala znajdowa
bdy we wczeniejszych fazach cyklu wytwarzania, dziki czemu ich
szukanie jest mniej czasochonne, a naprawy - mniej kosztowne.
Testerzy wykonujcy te testy nabieraj dowiadczenia w tym, jak
oprogramownaie dziaa, jakie ma sabsze obszery i ryzyka, a take mog
stworzy lepsz, robocz wspprac z programistami. O statusie prjektu
mona poinformowa wszystkich czonkw zespou uczestniczcych w
testowaniau.
2. Prawda czy fasz: statyczne testowanie
metodami szklanej skrzynki pozwala znale
zarwno brakujce elementy jak i problemy.
Prawda. Mona si o to spiera, ale zapewne brakujce elementy s
waniejsze ni inne problemy, a statyczne testowanie szklanej skrzynki
pozwala na ich wczesn identyfikacj. Kiedy kontroluje si kod wobec
standradw oraz starannie analizuje go w trakcie formalnych
przegldw, znalezienie brakujcych elementw jest bardzo
prawdopodobne.
3. Jakie s kluczowe elementy formalnych
przegldw?
Proces. cise stosowanie si do opisanego procesu jest tym, co rni
formalny przegld och dwch kumpli, ktrzy patrz sobie nawzajem na
kod.
4. Oprcz poziomu formalizmu, jaka jest
zasadnicza rnica midzy inspekcjami a innymi
rodzajami przegldw?
Strona 9 (25)
Gwna rnica: podczas inspekcji kto inny ni autor prezentuje objekt
podlegajcy inspekcji. Zmusza to jeszcze jedn osob do starannego
zrozumienia kodu lub dokumentacji, podlegajcych inspekcji. Jest to o
wiele bardziej skuteczne ni zwyczajne szukanie bdw.
5. Jeli programista zosta poinformowany, e
wolno mu uywa nazw zmiennych nie duszych
ni osiem znakw i wszystkie musz zaczyna si
du liter, czy mamy do czynienia ze
standardem czy z regu?
Byby to standard. Gdyby mu zezwolono na uywanie nie mniej ni
omiu znakw, ale zlecane byyby krtkie nazwy, byaby to regua.
6. Czy list kontroln do przegldw kodu opisan
w tym rozdziale powinno si przyj jako
standard waszego zespou do weryfikacji kodu?
Nie! Podano j tylko jako oglny przykad. Jest w niej kilka dobrych
zada testowych, ktre warto wzi pod uwag przy testowaniu kodu,
ale przed wybraniem standardu do wasnego uytku naleaoby zbada i
poczyta rwnie inne standardy.
Rozdzia 7
1.W jaki sposb znajomo wewntrznych mechanizmw dziaania
programu wpywa na to, jak i co naley przetestowa?
Testujc tylko metodami czarnej skrzynki, nie bdzie si wiedziao, czy
zadania testowe dostatecznie pokrywaj wszystkie czci
oprogramowania i czy niektre zadania nie s zbyteczne. Dowiadczony
tester moe zaprojektowa dosy skuteczny zestaw zada testowych
tylko metodami czarnej skrzynki, ale nie bdzie wiedzie na pewno jak
dobry jest ten zestaw bez niejakiego udziau metod szklanej skrzynki.
2. Czy jest rnica midzy dynamicznym
testowaniem metodami szklanej skrzynki, a
lokalizowaniem i usuwaniem bdw?
Oba te procesy zachodz na siebie, lecz celem testowania metodami
szklanej skrzynki jest znajdowanie bdw, za celem usuwania bdw
jest ich naprawa. Cz wsplna to izolowanie i lokalizacja poszukiwanie gdzie dokadnie i dlaczego bd si pojawia.
3. Jakie s dwa gwne powody, dla ktrych
testowanie jest niemal niewykonalne w modelu
skokowym wytwarzania oprogramowania? Jak
mona im zaradzi?
Strona 10 (25)
Kiedy oprogramowanie trafia w rce testera od razu w jednym, wielkim
kawaku, jest trudne lub wrcz niemoliwe stwierdzenie, dlaczego
nastpuje jaka awaria - jest to jak szukanie igy w stogu siana. Po
drugie, bdw jest zwykle tak wiele, e jedne mog przesania drugie.
apie si jeden bd i krzyczy mam cie!, by w chwil poniej odkry,
e program nadal zawodzi. Motodyczna integracja i testowanie moduw
pozwala znajdowa i naprawia bdy zanim dobrze si ukryj albo
spitrz jedne na drugich.
4. Prawda czy fasz: jeli projektowi brakuje
czasu, mona przeskoczy testowanie moduw
(jednostkowe) i przystpi od razu do tesowania
integracyjnego.
Fasz! O ile oczywicie produkt nie skada si z jednego tylko moduu.
5. Jaka jest rnica midzy namiastk testow a
sterownikiem testowym?
Namiastk testow stosuje sie przy integracji i testowaniu odgrnym.
Zastpuje ona nie istniejcy jeszcze modu niszego poziomu. Dla
wyszego poziomu namiastka wyglda i zachowuje si tak jak
prawdziwy modul niszego rzdu.
Sterownik jest odwrotnocia namiastki i stosuje si go przy integracji
oddolnej. Jest to kod testowy, ktry zastpuje oryginalny kod wyszego
rzdu aby skuteczniej wyprbowa moduy niszego rzdu.
6. Prawda czy fasz: zawsze naley najpierw
skonstruowa zadania testowe metodami
czarnej skrzynki.
Prawda. Najpierw projektuje si zadania testowe na podstawie
przypuszczalnego zachowania si programu. Nastpnie stosuje si
metody szklanej skrzynki aby sprawdzi i udoskonali te zadania
testowe.
7. Ktra jest najlepsza spord trzech opisanych w
tym rozdziale metod pomiaru pokrycia?
Dlaczego?
Pokrycie warunkw logicznych jest najlepsze, poniewa zawiera w sobie
pokrycie rozgazie i pokrycie instrukcji. Wiemy, e wszystkie warunki
zawierajce logik decyzyjn - takie jak instrukcje if - then, zostaj
zweryfikowane, jak rwnie biegnce od nich rozgazienia i wszystkie
linie kody rdowego.
Jaka jest najpowaniejsza trudno
testowania metodami szklanej
skrzynki, zarwno statycznego jak i
dynamicznego?
Strona 11 (25)
atwo sta si stronniczym. Spojrzy si na kod i powie Aha, widz,
tego nie trzeba testowa, kod napisany jest w tym miejscu poprawnie.
W rzeczywistoci, powtarzamy by moe ten sam bd, co programista i
eliminujemy niezbdne zadania testowe. Ostronie!
Rozdzia 8
1.Jaka jest rnica midzy komponentem a urzdzeniem peryferyjnym?
Mwic oglnie, komponent to sprzt w jakim sensie znajdujcy si
wewntrz PC. Urzdzenie peryferyjne za jest poza PC. Ta granica moe
jednak dla pewnych rodzajw sprztu by bardzo niewyrana.
2.Jak odrzni, czy bd jest oglnym problemem, czy te wycznie bdem
konfiuracji?
Naley powtrzy te same kroki, ktre spowodoway awari, na rnych
konfiguracjach. Jeli awaria nie wystpuje na wszystkich, mamy
zapewne do czynienia z bdem konfiguracji. Jeli awaria pojawia sie
niezalenioe od konfiguracji, mamy zapewne do czynienia z bdem
oglnym. Nie bdmy jednak pochopni. Moe si zdarzy bd
konfiguracji wystpujcy w caej klasie rwnowanoci. Na przykad
moe si zdarzy, e jaki bd pojawia si tylko na drukarkach
laserowych, ale nie na na atramentowych.
3.Jak mona zagwarantowa, e program nigdy nie bdzie mia bdw
konfiguracji?
To takie podstpne pytanie. Musiaoby sie wysya oprogramowanie i
sprzt razem jako jeden produkt, oprogramowanie dziaaoby tylko na
tym sprzcie, a sprzt musiaby byc dokadnie zapiecztowany, bez
adnego interfejsu do wiata zewntrznego.
4.Prawda czy fasz: klonowana karta dzwikowa nie musi by poddana
testowaniu konfiguracji.
To zaley. Klonowany sprzt ma zwykle identyczn konstrukcj jak
orygina, tylko inn nazw i inn obudow. Zwykle s funkcjonalnie w
100% idnetyczne, ale czasem programy obsugi mog si rni i mie
mniejszy lub wikszty zakres dostpnych funkcji.
5.Oprcz wieku oraz popularnoci, jakie inne kryteria mona zastosowa
jako podstaw podziau na klasy rwnowanoci?
Na przykad rejon albo kraj pochodzenia, gdy niekiedy sprzt - taki jak
odtwarzacze CD - dziaa tylko z z pytami kompaktowymi z tego samego
rejonu. Inna moliwo to rodzaj konsumenta albo brana. Niekiedy
sprzt jest charakterystyczny tylko dla jednej brany. Mog by jeszcze
inne kryteria, zelnie od rodzaju oprogramowania.
Strona 12 (25)
6. Czy dopuszczalne jest wypuszczenie programu
majcego bdy konfiguracji?
Tak. Nigdy nie da si naprawi wszystkich bdw. Jak zawsze w
testowaniu, decyzja zawiera w sobie element ryzyka. Zesp musi
zdecydowa, co jest si w stanie naprawi, a co nie. Pozostawienie
jakiego rzadkiego bdu, ktry ujawnia si tylko na rzadko spotykanym
sprzcie, nie bdzie trudne. Zwykle jednak decyzje tego typu nie bd
rwnie proste.
Rozdzia 9
1.Prawda czy fasz: kade oprogramowanie musi by w jakim stopniu
poddane testownaiu kompatybilnoci.
Fasz. Bywaj rzadko spotykane typy oprogramowania, ktre wystpuje
tylko w jednej wersji i z niczym nie ma adnej interakcji. Dla
pozostaych 99 procent programw testowanie kompatybilnoci bdzie
jednak koniecznoci.
2. Prawda czy fasz: Kompatybilno jest cech
produktu, ktra moe by speniona w rnym
stopniu.
Prawda. Poziom kompatybilnoci produktu zaley od potrzeb
uytkownikw. Jest zwykle zupenie dopuszczalne, by np. program do
przetwarzania tekstu nie by kompatybilny z formatem plikw programu
konkurencyjnego, lub eby nowy syystem opoeracyjny nie pozwala na
korzystanie z jakiego rodzaju programw rozrywkowych. Tester
powinien uatwic podejmowanie tego typu decyzji, dotarczajc dane na
temat tego, ile pracy wymagaby weryfikacja danego typu
kompatybilnoci.
3. Jak naley podej do zadania przetestowania
kompatybilnoci wszystkich formatw plikw
dla danego produktu?
Najpierw trzeba zbada, czy format plikw uywanych przez program
zgodny jest z jakim istniejcym standardem. Jeli tak, testuje si na
zgodno ze standardem. Naley te wyrni klasy rwnowanoci dla
moliwych programw, ktre bd pisay lub czytay pliki testowanego
programu. Przygotowuje si dokumenty testowe, zawierajce
reprezentatywne prbki typw danych, ktre testowany program bdzie
zapisywa i adowa. Musi si przetestowa przesyanie tych plikw
midzy testowanym programem oraz innymi programami.
4. W jaki sposb testuje si kompatybilno
wprzd (z kolejnymi, nastpnymi wersjami
programu)?
Strona 13 (25)
Testowanie kompatybilnoci wprzd nie jest atwe - nie da si przecie
przetestowa czego, co jeszcze nie istnieje! Rozwizaniem jest
testowanie wedug tak dokadnej specyfikacji, e moe ona stya si
standardem. Ten standard wwczas zapewni, e to co testujemy bdzie
kompatybilne wprzd.
Rozdzia 10
1.Jaka jest rnica midzy tumaczeniem a ulokalnieniem?
Tumaczenie dotyczy wycznie aspektw jzykowych - tumaczenia
sw. Ulokalnienie bierze pod uwag obyczaje, konwencje i kultur
regionu, dla ktrego dokonuje si ulokalnienia programu.
2. Czy musi si zna jzyk, aby mc testowa
produkt poddany ulokalnieniu?
Nie, ale kto w zespole testowym powinien posugiwa si pynnie tym
jzykiem. Mona testowa np. czci programu, ktre nie zale od
jzyka, ale znajomo jzyka pozwala pracowa skuteczniej.
3. Co to jest rozszerzanie tekstu i jakie bedy
powoduje?
Rozszerzenie tekstu wystpuje przy tumaczeniu z jednego jzyka na
inny. Dugo cigw znakw moe wwczas wzrosn nawet o 100
procent i wicej. Teksty w oknach dialogowych, przyciskach itd, ktre
dotd pasoway do ich wielkoci, przestaj pasowa. Cz tekstu moe
zosta odcita lub przesunita do nastpnej linii. Moe nawet zdarzy si
awaria programu spowodowana tym, e duszy tekst nie mieci si w
przeznaczonej dla niego pamici i niszczy inne dane.
4. Podaj kilka dziedzin, w ktrych rozszerzony zbr
znakw moe spowodowa kopoty.
Kolejnoc posortowanych w kolejnoci alfabetycznej sw i zwrotw,
konwersja z maych na due litery i odwrotnie, i inne oglne kwestie
dotyczce wywietlanych tesktw i wydrukw.
5. Dlaczego tekstowe cigi znakw naley trzyma
poza kodem?
Ulokalnianie jest o wiele atwiejsze, jeli osoba dokonujca przekadu
musi przerobi tylko plik tekstowy, a nie kod programu. Uatwia to
rwnie prac testow, poniewa wiadomo, e kod ulokalnionej wersji
jest identyczny z kodem wersji oryginalnej.
6. Wymie kilka rodzajw formatw danych, ktre
mog si rni w rnych ulokalnionych
wersjach programu.
Strona 14 (25)
Miary takie jak funty, cale i galony. Czas w formacie 24 i 12-godzinnym.
Oznaczenie waluty i wiele, wiele innych.
Rozdzia 11
1.Pawda czy fasz: kady rodzaj oprogramowania ma interfejs uytkownika
i dlatego musi by przetestowany pod ktem uytecznoci.
Prawda. W kocu nawet najgbiej wbudowane oprogramownaie ma
jak interakcj z uytkownikiem. Pamitajmy, e interfejs uytkownika
moe by tak prosty jak przecznik i arweczka lub tak
skomplikowany jak symulator lotw. Nawet jeli program jest tylko
jednym moduem kodu, ma interfejs - w postaci zmiennych i parametrw
- dostpny programicie.
2. Czy konstrukcja interfejsu uytkowanika jest
nauk czy sztuk?
Po trosze jedno i drugie. Wiele interfejsw uytkownika, ktre
przetestowano starannie w laboratoriach i poddano rygorystycznej
analizie, okazaa si kompletmym niewypaem na rynku.
3. Jeli nie istniej jednoznaczne kryteria
poprawnoci interfejsu uytkownika, w jaki
sposb mona go testowa?
Tester oprogramowania powinien sprawdzi, czy interfejs spenia siedem
wanych kryteriw: e jest zgodny ze stadardami, e jest intuicyjny,
spjny, elastyczny, wygodnmy, poprawny i uyteczny.
4. Wymie znane ci przykady le
zaprojektowanego albo niespjnego interfejsu
uytkkowanika.
Odpowied bdzie zaleaa od rodzaju produktu, ktry si wemie pod
uwag, ale zastanwmy si nad tym przykadem: czy da si nastawi
godzin na radio samochodowycm bez uycia podrcznika?
Niektre okna dialogowe Windows maj przycisk OK po lewej i
przycisk Anuluj po prawej, podczas gdy inne maj Anuluj po lewej i OK
po prawej. Kto si przyzwyczai do jednego ukadu i kliknie nie patrzc,
moe zmarnowa swoja wczeniejsz prac!
Czy nie zdarzyo si kademu niechccy rozczy rozmow
telefoniczn, nacisnwszy omykowo niewaciwy klawisz telefonu przy
prbie np. pocznie innej rozmowy?
5. Jakie cztery rodzaje inwalidztwa wpywaj na
dostpno oprogramowania?
Wzrokowe, suchowe, ruchowe i ograniczenia poznawcze.
Strona 15 (25)
6. Na co naley przede wszystkim zwrci uwag
przy testowaniu oprogramowania pod ktem
dostpnoci dla niepenosprawnych?
Na to, co dotyczy klawiatury, myszy, dwikw i wywietlania. Jeli
oprogramowanie zostao napisane na platform, ktra wspiera
dostpno dla niepenosprawnych, testowanie bdzie twiejsze ni
wwczas, gdy dostpno trzeba byo zaprogramowa w caoci w
aplikacji.
Rozdzia 12
1.Uruchom program Paint w Windows (zobacz rysunek 12.4) i poszukaj
przykadw dokumnetacji ktr naleaoby przetestowa. Co mona
znale?
Oto kilka przykadw: istnieje pomoc w formie maych okienek z
opisami, pojawiajcych si, kiedy kursor przesuwa si nad narzdziem.
Wybranie Na temat z menu Pomoc wywietla okno z informacj na
temat praw autorskich i licencji. Nacinicie F1 wsytartowuje
interakcyjny system pomocy, gdzie mona czyta podrcznik, wybiera z
indeksu albo szuka okrelonych sw. Jest rwnie jeszcze inna funkcja
pomocy - na przykad wybrawszy Edytuj kolory z menu Kolory, a
potem kliknwszy na ikon ? na pasku tytuowym, a w kocu
kliknwszy na jeden z kolorw, orzymuje si pomoc na temat wybierania
i tworzenia kolorw.
2.Indeks pomocy w programie Paint w Windows zawiera ponad 200 hase
poczwszy od doda wasne kolory1, skoczywszy na zmiana wielkoci
obrazu. Czy naley sprawdzi, czy kade z hase indeksu porwadzi do
waciwego rozdziau? Jak naleaoby postpi w przypadku 10000 hase
w indeksie?
Kade zadanie testowe jest problemem ryzykownej decyzji. Jeli ma si
czas, by skontrolowa wszystkie hasa, mona to zrobi. Jeli nie zdy
si przetestowa wszystkich, trzeba bdzie sporzdzi klasy
rwnowanoci, o ktrych si sdzi, e trzeba je przetestowa. Mona
oprze swoje decyzje na uzyskanej od programistw inforamcji o tym,
jak dziaa system indeksacji pomocy. Mona porozmawiac z autorem
tekstw i dowiedzie si, jak hasa zostay wygenerowane. Mona
wreszcie wyprbowa po jednym hale na kad liter, albo 2 hasa, albo
4 itd. Mona nawet zaczeka, a przeczyta si rozdzia 14-y
Automatyczne testowanie i narzdzia do testowania.
3.Prawda czy fasz: testowanie komunikatw o bdach jest czci
testowania dokumentacji.
Po angielsku adding custom colors jest na litere a (przy tumacza).
Strona 16 (25)
Prawda, ale komunikaty o bdach to co wicej ni dokumentacja.
Zawarto komunikatu trzeba przetestowa tak jak dokument, ale
wymuszenie pojawienia si komunikatu i kontrola, czy waciwy
komunikat zosta wywietlony, jest testowaniem kodu.
4. Jakie s trzy podstawowe powody, dla ktrych
ktrych test dokumentacji przyczynia si do
poprawy oglnej jakoci produktu
informatycznego?
Ulepszona uyteczno, wysza niezawodno i mniejsze koszty
serwisu.
Rozdzia 13
1.Jakie podstawowe elementy strony WWW mona atwo przetestowa
technikami czarnej skrzynki?
Statyczne elementy, podobne do multimedialnego oprogramowania na
dysku CD-ROM: tekst, grafik i doczneia.
2. Co to jest testowanie metodami szarej
skrzynki?
Testowanie metodami szarej skrzynki ma miejsce wtedy, kiedy zerka si
na kod i uywa uzyskan w ten sposb informacj, aby skuteczniej
testowa. Rni si to od testowania metodami szklanej skrzynki tym, e
zammiast skomplikowanego, wymagajcego kompilacji jzyka, takiego
jak C++, mamy do czynienia z prostym kodem skryptowym. Rwnie
nie bada si kodu a tak szczegowo, jak przy testowaniu metodami
szklanej skrzynki.
3. Dlaczego moliwe jest zastosowanie metod
szarej skrzynki do testowania witryn WWW?
Poniewa wikszo stron WWW zbudowana jest gwnie z
atwodostpnego kodu HTML, jzyka znacznikw, a nie z programu.
4. Dlaczego program do wyszukiwania bdw
pisowni nie gwarantuje poprawnej pisowni na
stronie WWW?
Program jest w stanie znale bdy tylko w zwyklym tekcie, a nie - w
graficznym tekcie albo w tekcie generowanym dynamicznie.
5. Wymie par wanych zagadnie, ktre trzeba
wzi pod uwag przy testowaniu konfiguracji i
kompatybilnoci witryn WWW.
Strona 17 (25)
Platforma sprztowa, system operacyjny, przegldarka WWW, wtyczki
programowe, opcje i ustawienia przegldarki, rozdzielczo wideo,
gbia kolorw, wielkoc tekstu i szybko modemu.
6.Ktre z opisanych przez Jakoba Nielsena 10 gwnych bdw witryn
WWW spowodowayby bdy kompatybilnoci i konfiguracji?
Niepowcigliwe posugiwanie si najnowsz technologi. Istniejcy
sprzt i oprogramowanie nie lubi, kiedy puszca na nich po raz
pierwszy najnowsze technologie. Nie byo wprawdzie o tym mowy
wprost w rozdziale, ale przypusczalnie dao si odpowied wywie z
podanych informacji.
Rozdzia 14
1.Wymie kilka korzyci stosowania narzdzi do testowania i automatyzacji
testowania.
Mog skrci czas, jaki zajmuje wykonywanie zada testowych. Mog
uczyni testerw skuteczniejszymi, dajc im wicej czasu na planowanie
testowania i wytwarzanie zada testowych. S bezbdne, precyzyjne i
niegdy sie nie mcz.
2.Jakie s moliwe wady automatyzacji i jakie moliwe trudnoci trzeba
wzi pod uwag przy podejmowaniu decyzji o zastosowaniu narzdzi i o
automatyzacji?
Poniewa oprogramowanie ulega zmianom, zmienia musz si take
narzdzia. Istnieje ryzyko wpadnicia w puapk, e najwicej czasu
trzeba w kocu powici na konstruowanie narzdzi i automatyzacji,
zaniedbujc samo testowanie. atwo te zaufa automatyzacji w zbyt
duym stopniu. Nie da si niczym zastpi testowania samemu.
3.Jaka jest rnica midzy narzdziem a automatyzacj?
Narzdzie testowe pomaga testowa, ulatwiajc wykonanie zadania,
ktre wczeniej trzeba byo wykonywa rcznie. Automatyzacja to
rwnie narzdzie, ktre potrafi dziaa bez ludzkiej interwencji.
Wyobramy sobie pi motorow i motek, ktre same buduj dom,
kiedy ciela pi.
4.Jakie s podobiestwa i rnice midzy analizatorem a generatorem
zaburze?
Oba te typy narzdzi umoliwiaj wgld w oprogramowanie w miejscach
normalnie niedostpnych dla uytkownika. Analizatory s nieintruzyjne i
pozwalaj tylko zobaczy to, co sie odbywa. Generator zaburze jest
intruzyjny - pozwala nie tylko obserwowa, ale take sterowa
przebiegiem wydarze. Mona przy jego pomocy wykonywa zadania
testowe, ktrych normalnie nie daoby si wykona metodami
dostpnymi zwykemu uytkownikowi.
Strona 18 (25)
5.Prawda czy fasz: narzdzie intruzyjne jest najlepsze, poniewa dziaa
najbliej testowanego oprogramowania.
Fasz. Intruzyjnoc lub nieintruzyjno nie czyni narzdzia dobrym lub
zym. Rodzaj testowanego oprogramowania i rodzaj zadania testowego,
ktre ma si wykona, okrelaj rodzaj narzdzia, ktre pasuje najlepiej.
6.Jaki jest jeden z najprostszych, ale skutecznych, sposobw automatyzacji
testowania?
Nagrywanie i odgrywanie czynnoci klawiatury i myszy jest
najprostszym typem automatyzacji, ktra skutecznie znajduje bdy.
7.Wymie kilka funcji, ktre warto doda do rozwizania opisanego jako
odpowied na porzednie pytanie, aby uczyni automatyczne testy jeszcze
skuteczniejszymi.
Proste programowanie czynnoci programu testujcego zamiast ich
nagrywania. Zdolno robienia przerw oraz oczekiwania na reakcj
programu na dane wejciowe. Niektre typy prostej weryfikacji,
pozwalajcej stwierdzi, czy wynik testu by poprawny, czy nie.
8. Na czym polega wyszo bystrych map nad
gupimi mapami i nad nagranymi
automatycznie makroprogramami?
Bystre mapy znaj tabel stanw oprogramowania, tak e wiedz,
gdzie si znajduj i co w tej sytuacji mona zrobi.
Rozdzia 15
1.Opisz paradoks pestycydw i w jaki sposb zaangaowanie nowych osb
w testowanie moe mu zapobiec.
Paradoks pestycydw (opisany w rozdziale 3-im Testowanie
oprogramowania w rzeczywistoci) jest to sytuacja, ktra moe
nastpi, kiedy testuje si oprogramowanie wci przy uyciu tych
samych zada testowych lub tych samych testerw. Wydaje si, jakby
oprogramowanie stopniowo wytwarzao sobie odporno na te testy,
poniewa nie znajduj one ju adnych nowych bdw. Jeli zmieni
zadania testowe lub zaangaowa nowych testerw, znw zacznie si
znajdowa nowe bdy. Oczywicie, bdy byy tam przez cay czas, a
nowe zadania testowe tylko zdoay je ujawni.
2. Jakie s moliwe korzyci programu testowania
beta?
Wielu nowych ludzi zaczyna posugiwa si programem. Jest to take
dobra metoda znajdowania bdw kompatybilnoci i konfiguracji.
Strona 19 (25)
3. Z czym naley zachowa ostrono planujc
testowanie beta?
Test beta nie zastpi zorganizowango, metodycznego, planowego
testowania - nie jest skuteczny do znajdowania wszystkich typw
bdw. Musi si wiedzie, kim s testerzy beta jeli chodzi o ich
dowiadczenie, sprzt i motywacj, aby mc mie realistyczne
oczekiwania, czego po nich mona si spodziewa.
4. Jeli pracuje si w maym przedsibiorstwie
robicym oprogramowanie, czy warto przekaza
test konfiguracji innej fimie?
Koszty biece i potrzebne inwestycje, aby zaopatrzy laboratorium do
testowania konfiguracji s bardzo wysokie i nieosigalne dla maej firmy
lub projektu.
Rozdzia 16
1.Po co jest plan testowania?
Parafrazujc definicj ANSI/IEEE, celem planu testowania jest
okrelenie zakresu, metodyki, rodkw i harmonogramu testowania oraz
zidentyfikowanie przedmiotw testowania, funkcji, ktee bdzie si
testowa, czynnoci do wykonania, osb za nie odpowiedzialnych oraz
ryzyka zwizanego z tym planem. Mwic krtko, aby opowiedzie
reszcie projektu i uzyska jego zgod na to, jak do cholery zesp
testowy waciwie zamierza wzi si za robot.
2. Dlaczego istotny jest proces planowania, a nie
sam plan?
Poniewa wszelkie zagadnienia i kwestie okrelone w planie testowania
wpywaja na reszt projektu, albo s pod wpywem reszty projektu.
Istotne jest, by wszyscy zrozumieli oraz zgodzili si na tre planu.
Sporzdzenie papierowego dokumentu w zaciszu swego pokoju i
umieszczenie go na pce tam, gdzie inni go nie znajd, jest nie tylko
marnowaniem czasu, ale wrcz zagroeniem dla projektu.
3. Dlaczego zdefiniowanie celw jakoci i
niezawodnoci oprogramowania jest wan
czci planowania testowania?
Poniewa jeli tego nie zrobi, kady bdzie mia inne pojcie na temat
tego, co si rozumie pod pojciem jakoci i niezawodnoci. Poniewa
bd rne, nie da si ich wszystkich osign na raz.
4. Co to s kryteria wejcia i kryteria wyjcia?
Strona 20 (25)
S to wymagania, ktre musz zostac spenione, by mc przej z jednej
fazy testowania do nastpnej. Nie wolno zakoczy jednej fazy, dopki
kryteria wyjcia nie zostay spenione. Nie wolno rozpocz nowej fazy,
dopki kryteria wejcia nie zostay spenione.
5. Wymie kilka typowych rodzajw zasobw
potrzebnych do testowania, ktre bierze si pod
uwag podczas planowania.
Ludzie, sprzt, biura i laboratoria, oprogramowanie, firmy wykonujce
testy na zlecenie i inne.
6. Prawda czy fasz: harmonogram powinien
zawiera dokadne daty, tak eby nie ulegao
adnej wtpliwoci, kiedy dana faza testowania
ma sie zacz i kiedy skoczy.
Fasz. Poniewa testowanie zaley w ogromnym stopniu od innych
aspektw projektu (na przykad nie da si zacz testowa czego, co
jescze nie zostao zakodowane), harmonogram testowania najkorzystniej
jest sformuowa wzgldem dat dostaw, a nie w czasie kalendarzowym.
Rozdzia 17
1.Jakie s cztery powody, aby planowa zadania testowe?
Organizacja, powtarzalno, moliwo ledzenia oraz dowd
wykonania testw.
2. Co to jest test metodami ad hoc?
Jest to testowanie bez planu. Jest atwe i przyjemne, ale nie jest
zorganizowane, nie jest powtarzalne, nie da si ledzi jego przebiegu
ani wynikw, a kiedy ju jest zakoczone, nie ma adnych dowodw na
to, e zostao wykonane.
3. Czemu suy specyfikacja grup zada
testowych?
Celem specyfikacji grupy zada testowych jest opisanie testw, ktre
maj by wykonane na jednej okrelonej funkcji. Specyfikacja ta
definiuje w oglnym zarysie t funkcj i planowany sposb jej
testowania. Identyfikuje zadania testowe (ale nie specyfikuje ich
szcegowo) oraz kryteria zaliczenia/niezaliczenia.
4. Co to jest specyfikacja zada testowych?
Ten dokument okrela rzeczywiste wartoci danych wejciowych oraz
oczekiwane wyniki zada testowych. Zawiera te listy szczeglnych
wymaga dotyczcych rodowiska i sposobu wykonywania testw oraz
zalenoci midzy zadaniami testowymi.
Strona 21 (25)
5. Jakich innych metod - oprcz tradycyjnej formy
pisemmnego dokumentu - mona uywa do
opisu zada testowcyh?
Table, macierze, listy, wykresy graficzne - cokolwiek najskuteczniej
prezentuje zadania do wykonania wobec autora, pozostaych testrw i
wobec reszty zespou projektowego.
6. Po co jest specyfikacja procedur testowych?\
Jej celem jest opisanie wszystkich krokw niezbdnych do wykonania
zada testowych, wcznie z tym jak przygotowa, uruchomi,
przeprowadzic oraz zamkn test. Zawiera te wyjasnienia, co robi w
razie niezalicznenia testu.
7. Jak szczegowa powinna by procedura
testowa?
Nie ma jednoznacznej odpowiedzi na to pytanie. Zaley to w duym
stopniu od tego, kto bdzie korzysta z procedury. Zbyt maa ilo
szczegw spowoduje, e procedura bdzie niejednoznaczna, a sposb
jej realizacji zaleny od intepretacji. Zbyt wiele szczegw moe
spowodowa, e wykonanie testw bdzie odbywa si nadzwyczaj
nieelastycznie i powoli. Stosowny poziom szczegoowoci zalee
powinien od brany, od przedsibiorstwa, od projektu i wreszcie od
specyfiki zespou testowego.
Rozdzia 18
1.Podaj kilka powodw, dla ktrych bd moe nie zosta naprawiony.
Nie ma ju czasu w harmonogramie, to nie by naprawd bd, jest to
zbyt ryzykowne, nie opaca si skrka za wypraw, raport bdu by
niewaciwie sporzdzony.
2. Jakie s podstawowe zasady pisania raportw o
bdach tak, aby zmaksymalizowa szans, e
zostan naprawione?
Naley je zapisa jak najszybciej. Bd naley opisa jak najlepiej,
starajc si by opis by jak najkrtszy, unikalny, oczywisty i oglny, oraz
pozwalajcy na powtrzenie bdu. Naley powstrzyma si od
wygaszania osdw i ocen w opisie bldu. Naley ledzi dalsze losy
raportu.
3. Podaj kilka technik izolowania i odtwarzania
bdu.
Strona 22 (25)
Notowa wszystko co si robi i starannie to analizowa. Posugiwa si
metodami szklanej skrzynki aby szukac sytuacji "wycigu", warunkw
brzegowych, przeciekw pamici i innych tego typu kopotw.
Sprawdza, czy awaria zaley od stanu, w jakim znajduje si
oprogramowanie, jak na przykad stan pocztkowy albo inny ni
pocztkowy. Bra pod uwag zaleno od zasobw, a nawet moliwo
bdw w sprzcie jako przyczyny awarii.
4. Wyobramy sobie, e testujc Kalkulator
Windows otrzymujemy nastpujce wyniki:
1+1=2, 2+2=5, 3+3=6, 4+4+9, 5+5=10 i
6+6=13. Napisz stosowny tytu raportu i opis
bdu.
Tytu: dodawanie dwch liczb parzystych daje wynik o jedno za duy.
Opis:
Zadanie testowe: proste dodawanie
Warunki startowe: uruchomi Wersj 1.0 Kalkulatora.
Kroki dla odtworzenia: dodajemy pary liczb parzystych takich jak 2+2,
4+4 i 10+10. Prbujemy te dodawa pary liczb nieparzystych takich jak
3+3, 5+5 i 13+13 oraz pary mieszane (liczba parzysta i nieparzysta),
takie jak 1+2, 5+6 i 12+13.
Oczekwiane wyniki: poprawna odpowied dla wszystkich par liczb
Rzeczywiste wyniki: dla par liczb parzystych, wynik jest za duy o
jedno, np. 2+2=5, 4+4=9, 10+10=21 i tak dalej.
Dodatkowa informacja: nie zostao to przetestowane wyczerpujco, ale
bd pojawi si w duej iloci przypadkw od 2+2 do 65536. Bd nie
wydaje si wystpowa dla par liczb nieparzystych i dla par miesznaych.
5. Jak wag i priorytet nadaby bdowi
literowemu w nazwie firmy na pierwszym
ekranie aplikacji?
Przypuszczalnie wag 3 (drobniejszy problem) oraz priorytet 2 (musi by
naprawiony przed wypuszczeniem).
6. Jakie s trzy podstawowe fazy cyklu yciowego
bdu i dwa czsto stosowane stany dodatkowe?
Otwary, Rozwizany i Zamknity to stany podstawowe. Do Analizy oraz
Odroczony to dwa moliwe dodatkowe stany.
Strona 23 (25)
7. Podaj kilka powodw, dla ktrych system
ledzenia bdw z uyciem bazy danych jest
znacznie bardziej uyteczny ni system oparty na
papierowych raportach.
Na pierwszy rzut oka daje si zobaczyc histori yciow bdu - nawet
jeli bya zoona. Aktulany stan bdu widzi si natychmiast. Bdw
nie daje si zgubi ani zaniedba rwnie atwo.
Rozdzia 19
1.Czemu - wykorzystujc dane pomiarowe z bazy danych ze znalezionymi
bdami - liczenie tylo i wycznie iloci bldw znalezionych jednego
dnia lub obliczenie redniej iloci bdw znajdowanych dziennie nie
daoby wystarczajcgo obrazu stanu projektu?
Ten pomiar nie daje kompletnego obrazu sytuacji. Moe wanie bya
testowana najbardziej zoona cz programu, a moe cz napisana
przez najbardziej dowiadczonego programist, czy te odwrotnie - przez
pocztkujcego programist. Testowany kod mg by testowany ju
wczeniej przy innej okazji lub zupenie nowy.
2.Uzupeniajc odpowied na pytanie 1-e, jakie inne dane pomiarowe
warto wzi pod uwag, aby trafnie i skutecznie mierzy jako wasnej,
osobistej jakoci pracy jako testera?
Sredni ilo bdw znajdowanych dziennie. aczn sum bdw
znalezionych od pocztku do obecnej chwili. Stosunek iloci bdw
naprawionych do wszystkich znalezionych. Stosunek iloci bdw o
wadze 1 (albo priorytecie 1) do iloci wszystkich znalezionych bdw.
redni czas od statu Rozwizany do stanu Zamknity.
3.Jak wygldaoby pytanie postawione bazie danych (wolno uy
dowolnego formatu i skadni pseudojzyka), ktre miaoby wydoby z
niej wsztystkie rozwizane bdy, przypisane Terryemu, w projekcie CalcU-Lot, wersja 3.0?
Produkt EQUALS Calc-U-Lot AND
Wersja EQUALS 3.0 AND
Status EQUALS Rozwizany AND
Przypisany EQUALS Terry
4.Jeli tempo znajdowania nowych bdw sabnie (jak na rysunku 19.8) i
wszyscy bardzo si ciesz, e projekt zblia si do celu, jakie mog by
powody (wymie kilka), e liczby kami, tj. e stan produktu/projektu
wcale nie jest dobry, mimo e bdw znajduje si coraz mniej?
Strona 24 (25)
Mogo si zdarzy, e program by przekazywany do testowania
stopniowo i nie cay zosta jeszcze prztestowany - moe wypaszczenie
dotyczy tylko pierwszej fazy. Testerzy mogli by zajci testowaniem
regresyjnym i zamykaniem bdw, a nie szukaniem nowych bdw.
Mg to by wyjtkowo ciepy i soneczny tydzie albo testerzy mogli
by na wakacjach.
Rozdzia 20
1.Czemu istniej koszty testowania, zwizane z kosztami osignicia
jakoci?
Poniewa - niezalenie od tego, jak doskonay jest proces wytwrczy testowanie trzeba wykona co najmniej jeden raz, aby mc dokona
weryfikacji produktu wzgldem jego specyfiakcji oraz walidacji
wzgldem wymaga uytkownikw. Jeli nie znalazo si adnych
bdw, to wspaniale, ale koszty planowania, konstruowania i
wykonywania testw wchodz w skad kosztw osignicia jakoci.
2. Prawda czy fasz: zesp testowy jest
odpowiedzialny za jako.
Falsz! Testowanie ma za zadanie poszukiwanie bldw. Nie testerzy
spowodowali, e w programie sa bdy. Testerzy nie s w stanie
zagwarantowa, e po zakoczeniu testw w programie na pewno nie ma
ju adnych bdw.
3. Czemu nieatwo jest speni wszystkie
wymaganaia, ktre implikuje tytu inyniera
zapewnienia jakoci?
Poniewa tytu implikuje odpowiedzialno za jako produktu. Kto jest
gotowy ponie t odpowiedzialno?
4. Czemu korzystne jest, by grupa odpowiedzialna
za test lub zapewnienie jakoci bya
podporzdkowana bezporednio kierownictwu
firmy?
Jei zesp testowy podporzdkowany jest kierownikowi produkcji lub
kierownikowi projektu, ma miejsce konflikt interesw midzy
znajdowaniem bdw a zbudowaniem oprogramowania oraz
dotrzymaniem harmonogramu.
5. Na jakim poziomie CMM bdzie firma, ktra
spenia warunki standardu 9000-3 dla
oprogramowania?
Strona 25 (25)
Bdzie ona zapewne na poziomie 3-im CMM, by moe ocierajc si o
niektre wymagania dla poziomu 4-ego. Nie jest na poziomie 2-im,
poniewa poziom 2-i dotyczy tylko projektu. Poziom 3-i dotyczy caej
organizacji czy przedsibiorstwa. Na poziomie 4-ym pojawia sie
staystyczna kontrola procesw.
Rozdzia 21
1.Szukajc na Internecie pracy zwizanej z testowaniem, jakich sw
naley szuka startujc przeszukiwark?
Nazwy roli i opisy funkcji testerw oprogramowania s rnorodne,
naley wic szuka okrele "test oprogramowania" (software test),
"testowanie oprogramowania" (software testing), "zapewnienie
jakoci" (quality assurance) oraz "QA".
2.Wymie dwa sposoby, jak mona miec do czynienia z testowaniem
oprogramownaia przed jego wypuszczeniem na rynek.
Testowanie beta i testowanie uytecznoci.
3.Jakie s cele testera oprogramowania?
Celem testera jest znajdowanie bdw, znajdowanie ich jak
najwczeniej oraz dopatrzenie, by zostay naprawione.
Strona 1 (9)
Literatura fachowa i inne rda

Oglne pozycje na temat testowania
Znajduj si tutaj pozycje oglne dotyczce testowania oprogramowania..
Pozycje oglne - ksiki
1. Ammerman, M., The Root Cause Analysis
Handbook-A Simplified Approach to
Identifying, Correcting, and Reporting
Workplace Errors, 1998
2. Beizer, B. Software Testing Techniques, 1990
3. Beizer, B. Black Box Testing: Techniques for
Functional Testing of Software and Systems,
1995
4. Beizer, B. Software System Testing and Quality
Assurance, 1996
5. Clapp, J., A. Software Quality Control, Error
Analysis and Testing, 1995
6. Gano, D. L. Apollo Root Cause Analysis - A
New Way Of Thinking, 1999
7. Gardiner, S. (editor) Testing Safety-Related
Software, 1999
8. Hetzel, B. The Complete Guide To Software
Testing, (1988), 1993
9. Hetzel, B. Making Software Measurement
Work, 1993
10. Hutcheson M., L. Software Testing Methods and
Metrics: The Most Important Test Methods,
1997
11. Jorgensen, P., C. Software Testing: A
Craftsman's Approach, 1995
12. Kan, S. Metrics and Models in Software Quality
Engineering, 1995
13. Kaner, C., Falk. J., Nguyen, H.Q. Testing
Computer Software, 1993
14. Kit, E. Software Testing in the Real World, 1995
15. Krawczyk H., Wiszniewski B. Analysis and
Testing of Distributed Software Applications,
1999
Strona 2 (9)
16. Lewis, R., O. Independent Verification and
Validation: A Life Cycle Engineering Process
for Quality Software, 1992
17. Lewis W. E., Software Testing and Continuous
Quality Improvement, 2000
18. Lindgaard, G. Usability Testing and System
Evaluation, 1993
19. Marick, B. The Craft of Software Testing, 1995
20. Marks, D., M. Testing Very Big Systems, 1992
21. McConnell, S., C., Rapid Development : Taming
Wild Software Schedules, 1996
22. McDermott, R. E., Beauregard, M. R., Mikulak,
R. J., The Basics of FMEA [Failure Mode and
Effect Analysis], 1996
23. Musa, J., D. Software Reliability Engineered
Testing, 1998
24. Myers, G. The Art of Software Testing, 1979
25. Patton, R. Software Testing, 2000
26. Perry, W. A Structured Approach to Systems
Testing, 1988
27. Perry, W., Rice, R. Surviving the Top Ten
Challenges of Software Testing, 1997
28. Perry, W. Effective Methods for Software
Testing, 2000
29. Pham, H. (editor) Software Reliability and
Testing, 1995
30. Pol, M., van Veenendaal, E. Structured Testing
of Information Systems, 1998
31. Qurik, W., J. (editor) Verification and Validation
of Real-Time Software, 1988(?)
32. Roper, M. Software Testing, 1994
33. Rubin, J. Handbook of Usability Testing, 1994
34. Schutz, W. The Testability of Distributed RealTime Systems, 1993
35. Wiegers, K. E. Software Requirements, 1999
36. Wiszniewski, B. Weryfikacja, walidacja i
testowanie [w:] Grski J. (red.) Inynieria
oprogramowania, 2000
Pozycje oglne - czasopisma
Strona 3 (9)
37. Professional Tester, www.professionaltester.com
38. Quality Techniques Newsletter (QTN) [byy
Testing Techniques Newsletter (TTN)],
archiwum, www.soft.com/News/TTN-Online
39. Software Testing and Quality Magazine (STQE),
www.stqemagazine.com
40. Software Testing, Verification and Reliability,
www.interscience.wiley.com
41. The Journal of Software Testing Professionals,
www.softdim.com
Pozycje oglne - organizacje
42. American Society for Quality, www.asq.org
43. BCS SIGIST, Great Britain,
www.bcs.org.uk/sigist/index.html
44. Belgian Software Test Association, Belgium
45. CSE, Ireland
46. Data Teknisk Forum, Denmark,
www.delta.dk/dtf
47. Erfagruppe, Norway,
www.dnd.no/software_testing/index.htm
48. ESI, Spain
49. GI (Test) SIG, Germany, www.fbe.hsbremen.de/spillner/gi.htm
50. IEEE Computer Society, www.computer.org
51. ISTI (International Software Testing Institute),
Great Britain, www.softtest.org
52. Polskie Towarzystwo Informatyczne, www.pti.pl
53. Quality Assurance Institute (private company),
www.qaiusa.com
54. SAST (Swedish Association for Software
Testing), www.sast.net/
55. SOFT-ED, Finland, www.soft-ed.net
56. SQE (Software Quality Engineering),
www.sqe.com
Strona 4 (9)
57. TestNet, Netherlands, www.testnet.org
Pozycje oglne - konferencje
58. EuroSTAR, www.testingconferences.com
59. ICSTEST, www.icstest.com
60. QualityWeek, www.soft.com/QualWeek
61. QualityWeek Europe, www.soft.com/QualWeek
62. STAREast, STARWest,
www.sqe.com/conferences
63. The European Software Testing Congress,
www.sqe-europe.com
Pozycje oglne - zasoby internetowe
64. Bereza-Jarociski, B. Is Software Testing
Scientific?,
http://www.bbj.com.pl/common/is_scientific.ht
m
65. Grupa dyskusyjna comp.software.testing
66. Huckle, Th. Collection of Software Bugs,
wwwzenger.informatik.tumuenchen.de/persons/huckle/bugse.html
67. NEC Research Index, researchindex.org
68. QA Forums, www.qaforums.com
69. Quality Techniques Newsletter (QTN)
[Formerly Testing Techniques Newsletter
(TTN)], archive, www.soft.com/News/TTNOnline
70. Software Testing Frequently Asked Questions
(uprzednio cz Marick's Corner),
www.rstcorp.com/marick
71. Software Testing Hotlist, Bret Pettichord,
www.io.com/~wazmo/qa/
72. Statistical Usage Testing, www.qlabs.com/port_sut.html
73. Sticky Minds, stickyminds.com/
74. STORM (Software Testing Online Resources),
www.mtsu.edu/~storm
75. Testing Foundations, Brian Marick,
www.testing.com
Strona 5 (9)
76. The Software Quality Page,
www.tiac.net/users/pustaver
Przegldy oraz inspekcje

Przegldy oraz inspekcje - ksiki
77. Fagan, M. E. Design and Code Inspections to
Reduce Defects in Program Development, 1976
78. Freedamn, D. P., Weinberg, G. M. Handbook of
Walkthroughs, Inspections and Technical
Reviews, 1990
79. Gilb, T., Graham, D. Software Inspection (1993)
Proces testowania i zarzdzanie testowaniem

Proces testowania i zarzdzanie testowaniem - ksiki
80. Black, R. Managing the Testing Process, 1999
81. Gilb, T. Principles of Software Engineering
Management, 1988
82. Koomen, T., Pol, M. Test Process Improvement,
1999
83. Paulk, M. C., Weber, Ch. V., Curtis, B., Chrissis,
M. B. The Capability Maturity Model (CMM):
Guidelines for Improving the Software Process,
1995
84. Watkins, J. Testing IT: An Off-The-Shelf
Software Testing Process, 2000
Proces testowania i zarzdzanie testowaniem zasoby
internetowe
85. Bereza-Jarociski, B. Decision Making and Risk
Management in Testing,
http://www.bbj.com.pl/common/decision_theory
/paper.htm
Testowanie oprogramowania obiektowego

Testowanie oprogramowania obiektowego - ksiki
86. Bashir I., Goel A., L. Testing Object-Oriented
Software: Life-Cycle Solutions, 2000
87. Binder, R., V. Testing Object-Oriented Systems:
Models, Patterns, and Tools, 1999
88. Kung, D., C. Testing Object-Oriented Software,
1998
Strona 6 (9)
89. Siegel, S., Muller R., J. Object Oriented
Software Testing: A Hierarchical Approach,
1996
90. Sykes, D., A., McGregor J., D. Practical Guide
to Testing Object-Oriented Software, 2001
Testowanie Internetu i systemw klient-serwer

Testowanie Internetu i systemw klient-serwer - ksiki
91. Marshall, S. Making E-Business Work: A Guide
to Software Testing in the Internet Age, 2000
92. Mosley, D., J., Client Server Software Testing
on the Desk Top and the Web, 1999
93. Nguen, H. Q. Testing Applications on the Web:
Test Planning for Internet-Based Systems, 2000
94. Splaine, S. The Web Testing Handbook, 2001
Automatyzacja testowania
Automatyzacja testowania - ksiki
95. Dustin, E., Rashka, J., Paul, J. Automated
Software Testing, 1999
96. Fewster, M., Graham, D. Software Test
Automation, 1999
97. Hayes, L. G. The Automated Testing Handbook,
1995
Automatyzacja testowania - referaty, artykuly i zasoby internetowe
98. Adelswrd Brck K., Rosenquist P. Automated
Testing of Software with Graphical User
Interfaces, 1998 (praca magisterska na
Uniwersytecie w Lund i w Telelogic AB)
99. Bach, J. Test Automation Snake Oil, 1997,
www.stlabs.com/snakeoil.htm
100.Bereza-Jarociski, B. Automated Testing in
Daily Build, raport dla Sveriges
Verkstadsindustrier, 2000
101.Bereza-Jarociski, B. Tools and Automation on
a Shoestring,
http://www.bbj.com.pl/common/white_paper_E
S_short.htm
102.Buwalda, H., Kok A., Schlatter, A. Testing
Using Action Words, 1998 (EuroSTAR 1998).
Strona 7 (9)
103.Delta Report on Automatic Test Tools in Danish
Electronic Industry
www.delta.dk/HyperNews/get/projekter/SWtest
proj.html
104.Gerrard, P. Testing GUI Applications, 1997
(EuroSTAR 1997, Edinburgh;
www.evolutif.co.uk/GUI/TestGui.html
105.Hedlund, H. Characterizing Test Tools for
Systems Containing Software, 1998 (master
thesis at KTH and Enea Data AB)
106.Imbus GmbH How to Automate Testing of GUI,
1998 www.imbus.de/html/GUI/AQUISfull_paper-1.3.html
107.Kaner, C. Improving the Maintainability of
Automated Test Suites, 1997 (Software QA 4)
108.Kaner C. Pitfalls and Strategies in Automated
Testing, 1997 (IEEE Computer, April 1997)
109.Kemerer, C. How the Learning Curve Affects
CASE Tool Adoption, 1992 (IEEE Software,
May 1992)
110.Marick, B. When Should a Test be Automated,
1998
(ftp://ftp.rstcorp.com/pub/papers/automate.pdf)
111.Marick, B. Maricks Corner, unaczeniane na
bieco www.rstcorp.com/marick
112.Nokia Telecommunications Institutionalization
of Best Practices for Test Automation and
Management, 1998 (ESSI Report no 21284)
113.Poston, R. M. Automating Specification-Based
Software Testing, 1996
Automatyzacja testowania - konferencje
114.Software Test Automation
www.sqe.com/testautomation
115.Daich et al, Software Test Technologies Report ,
1994 (schemat klasyfikacji narzdzi testowych,
techniki oceny narzdzi)
116.Graham D., Herzlich P., Morelli, C. The Cast
Report, Computer Aided Software Testing, 1999,
www.evolutif.co.uk/CastReport.html
117.IPL, www.iplbath.com (referat oraz informacja
na temat AdaTEST, Cantata, Cantata++)
Strona 8 (9)
118.LDRA Ltd, www.ldra.com (LDRA Testbed,
automatyczne generowanie rodowiska
testowego - namiastek i sterownikw - dla testu
komponentw)
119.Marick, B. Testing Tools Supplier List,
unaczeniane na bieco,
www.rstcorp.com/marick/faqs/tools.htm
120.Ovum, Software Testing Tools Evaluation, nowa
wersja co roku, www.ovum.com
121.Poston, R., Sexton, M. Evaluating and selecting
testing tools, 1992
122.Sticky Minds, stickyminds.com
123.Testwell,
http://www.testwell.sci.fi/homepage.html
(narzdzia testowania dla C, C++ i Ady)
124.Wilson, R., C. UNIX Test Tools and
Benchmarks. Methods and Tools to Design,
Develop and Execute Functional, Structural,
Reliability and Regression Tests, 1995
Standardy
125.British Standards Institution (BSI),
http://www.bsi.org.uk
126.BS 7925-1, Vocabulary of Terms in Software
Testing
127.BS 7925-2, Software Component Testing
128.IEEE SESC (Software Engineering Standards
Committee) Software Safety Planning Group
Action Plan,
www.computer.org/standards/sesc/Safety
129.IEEE Std 829-1998, Standard for Software Test
Documentation
130.IEEE Std 1008-1987, Standard for Software
Unit Testing
131.IEEE Std 1012-1998, Standard for Software
Verification and Validation
132.IEEE Standard 1209, Recommended Practice
for the Evaluation and Selection of CASE Tools,
1992
133.IEEE Standard 1348, Recommended Practice
for the Adoption of Computer-Aided Software
Engineering (CASE) Tools, 1995
Strona 9 (9)
134.RTCA/DO-178B Software Considerations in
Airborne Systems and Equipment Certification,
software.software.org/quagmire/descriptions/do178b.asp
135.TTCN (Tree and Tabular Combined Notation,
jzyk formalny dla specyfikacji zada
testowych), part of ISO 9646, www.iso.ch;
dobry opis w
www.telelogic.se/solution/language/ttcn.asp i
materia szkoleniowy w
www.webproforum.com/ttcn/index.html.
Inne
136.Information Systems Examination Board
(ISEB), www.bcs.org.uk/iseb
137.ISEB Examination Information,
www.bcs.org.uk/iseb/syll/st.htm#exam
138.ISEB List of Accredited Training Providers,
www.bcs.org.uk/iseb/st.htm
139.Software Testing Foundation Certificate
Syllabus, www.bcs.org.uk/iseb/syll/st2.htm

RonPatton TestowanieOprogramowania

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

RonPatton TestowanieOprogramowania

Uploaded by

Copyright:

Available Formats

Okadka, 8 I 2002

[okadka strona 1-a]

Testowanie Oprogramowania to ksika dla pocztkujcych i ambitnych

Ron Patton ma ponad 15 lat dowiadczenia w testowaniu oprogramowania i

ZASADY I ICH ZASTOSOWANIE

[okadka strona 2-a]

Co eksperci powiedzieli na temat "Testowania

"Podoba mi si podzia na rne rodzaje testowania, takie jak testowanie

Rick Craig jest popularnym prelegentem na wielu konferencjach i

"Test Oprogramowania Pattona jest przystpnym i nietrudnym wstpem do

Spis treci oryginau:

5. Test z klapkami na oczach (str.79)

Inne kontrole (str.124)

Ponowne wykonywanie zada testowych a do skutku (str.158)

11. Test atwoci korzystania (str.191)

Cele planowania testw (str.272)

Pocztek, strona 1 (7)

Tumaczenie: Bogdan Bereza

Pocztek, strona 2 (7)

Skrcony spis treci

Pocztek, strona 3 (7)

Pocztek, strona 4 (7)

Czytelnicy ksiki s dla nas najwaniejszymi krytykami i komentatorami.

Pocztek, strona 5 (7)

Wydaje si, jakby codziennie pojawiaa si jaka nowa historia o awarii

Kto powinien korzystac z tej ksiki?

Pocztek, strona 6 (7)

Ksika skierowana jest do trzech rnych grup czytelnikw:

Do czego suy ta ksika

Oprogramowanie potrzebne do tej ksiki

Pocztek, strona 7 (7)

Przedstawione w ksice metody s oglne i mona je stosowa do

Ron Patton Test oprogramowania

Kiedy zawiesza si program konkurencji, to jest awaria. Kiedy zawiesza si

Uwielbiam ostateczne terminy. Zwaszcza podoba mi si wist, jaki wydaj

Wersja 9 padziernika 2001, Bogdan Bereza-Jarociski

Ron Patton Test oprogramowania

Opisy niesawnych bdw oprogramowania

Wersja 9 padziernika 2001, Bogdan Bereza-Jarociski

Ron Patton Test oprogramowania

atwo dzisiaj traktowa programy komputerowe jak co oczywistego i nie

jesli otrzyma si wynik zero, komputer jest w porzdku. Jeli otrzyma si

Wersja 9 padziernika 2001, Bogdan Bereza-Jarociski

Ron Patton Test oprogramowania

30-ego padziernika 1994, dr Thomas R. Nicely odkry, e przyczyn

Wersja 9 padziernika 2001, Bogdan Bereza-Jarociski

Ron Patton Test oprogramowania

28-ego sierpnia roku 2000, wkrtce przed pierwszym wydaniem tej

Wersja 9 padziernika 2001, Bogdan Bereza-Jarociski

Ron Patton Test oprogramowania

Pocisk obrony przeciwrakietowej Patriot, 1991

Strategic Defense Initiative

Wersja 9 padziernika 2001, Bogdan Bereza-Jarociski

Ron Patton Test oprogramowania

Zapoznalimy si wanie z kilkoma przykadami tego, co si dzieje kiedy

Lista terminologii na kocu ksiki zawiera angielsko-polski i polsko-angielski sowniczek

Wersja 9 padziernika 2001, Bogdan Bereza-Jarociski

Ron Patton Test oprogramowania

Problem, pomyka i bd to chyba najczciej uywane3, oglne okrelenia.

Autor uywa okrelenia bug.

Wersja 9 padziernika 2001, Bogdan Bereza-Jarociski

Ron Patton Test oprogramowania

Dla potrzeb tej ksiki i wikszej czci przemysu produkujcego