Professional Documents
Culture Documents
RonPatton TestowanieOprogramowania
RonPatton TestowanieOprogramowania
Strona 1 (3)
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]
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
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.
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)
Podsumowanie (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)
Podsumowanie (str.76)
Pytania (str.77)
Podsumowanie (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)
Podsumowanie (str.260)
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)
Podsumowanie (str.266)
Pytania (str.267)
Cz V. Dokumentacja testowania (str.269)
16. Planowanie testowania (str.271)
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)
Podsumowanie (str.341)
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)
Podsumowanie (str.355)
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)
Podsumowanie (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
19 IX 2001
Testowanie Oprogramowania
Ron Patton
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
+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
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
19 IX 2001
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
Cz I
Cz I, strona 1 (44)
Obraz oglny
W TEJ CZCI
Test oprogramowania: to
Proces wytwarzania oprogramowania
Test oprogramowania w rzeczywistoci
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
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)
Cz I, strona 4 (44)
Cz I, strona 5 (44)
Cz I, strona 6 (44)
Co to jest bd?
Cz I, strona 7 (44)
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)
Autor ma na myli angielskie sowa problem, error oraz bug; trudno powiedzie, jaki jest rozkad
czstoci uywania analogicznych sw w jzyku polskim.
1
Cz I, strona 9 (44)
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)
Cz I, strona 11 (44)
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.
Cz I, strona 12 (44)
Cz I, strona 13 (44)
Cz I, strona 14 (44)
Cz I, strona 15 (44)
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
Cz I, strona 16 (44)
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
Cz I, strona 17 (44)
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).
Cz I, strona 18 (44)
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
Cz I, strona 19 (44)
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.
Cz I, strona 20 (44)
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.
Cz I, strona 21 (44)
Cz I, strona 22 (44)
Cz I, strona 23 (44)
Cz I, strona 24 (44)
Cz I, strona 25 (44)
Cz I, strona 26 (44)
Cz I, strona 27 (44)
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.
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).
Cz I, strona 28 (44)
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).
Cz I, strona 29 (44)
Podsumowanie
Cz I, strona 30 (44)
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
Cz I, strona 31 (44)
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
Cz I, strona 32 (44)
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).
Cz I, strona 33 (44)
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.
Cz I, strona 34 (44)
Cz I, strona 35 (44)
Cz I, strona 36 (44)
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
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).
Cz I, strona 37 (44)
Cz I, strona 38 (44)
Cz I, strona 39 (44)
Cz I, strona 40 (44)
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.
Cz I, strona 41 (44)
Cz I, strona 42 (44)
Cz I, strona 43 (44)
Cz I, strona 44 (44)
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
W TEJ CZCI
Badanie specyfikacji
Test z klapkami na oczach
Badanie kodu
Testowanie pod rentgenem
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.
Najwaniejsze punkty tego rozdziau:
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)
Cz II strona 4 (86)
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
Cz II strona 5 (86)
Zwykle podzia na techniki czarnej i szklanej skrzynki stosuje si wycznie wobec testowania
dynamicznego (przyp. tumacza).
2
Cz II strona 6 (86)
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)
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)
Maj te zwykle szczegowe wymagania dotyczce metod kontroli jakoci i testu (np. przemys
lotniczy, produkcja sprztu medycznego, kolejnictwo) przyp. tumacza.
2
Cz II strona 9 (86)
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)
Cz II strona 11 (86)
Cz II strona 12 (86)
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).
Cz II strona 13 (86)
Rozdzia 5
Cz II strona 14 (86)
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:
Cz II strona 15 (86)
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).
Cz II strona 16 (86)
powinno
powinno
powinno
powinno
powinno
powinno
powinno
powinno
da
da
da
da
da
da
da
da
0
1
255
256
257
1023
1024
1025
Cz II strona 17 (86)
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).
Cz II strona 18 (86)
Cz II strona 19 (86)
Cz II strona 20 (86)
Rysunek 5.3 Rne sposoby przywoania funkcji kopiowania daj ten sam
wynik.
Cz II strona 21 (86)
Cz II strona 22 (86)
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
Cz II strona 23 (86)
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.
Cz II strona 24 (86)
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).
Cz II strona 25 (86)
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).
Cz II strona 26 (86)
Cz II strona 27 (86)
Cz II strona 28 (86)
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
Nazwa
Warto
Bit
0 lub 1
Powka bajtu
0-15
Bajt
0-255
Sowo
Kilo
1024
Mega
1 048 576
Giga
Tera
Cz II strona 29 (86)
Cz II strona 30 (86)
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
65
Cz II strona 31 (86)
{
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
Cz II strona 32 (86)
Cz II strona 33 (86)
Cz II strona 34 (86)
Cz II strona 35 (86)
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).
Cz II strona 36 (86)
Cz II strona 37 (86)
Cz II strona 38 (86)
Cz II strona 39 (86)
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.
Cz II strona 40 (86)
Cz II strona 41 (86)
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
Cz II strona 42 (86)
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).
Cz II strona 43 (86)
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).
Cz II strona 44 (86)
Podsumowanie
Cz II strona 45 (86)
Pytania
Pytania maj na celu uatwienie zrozumienia. W aneksie A Odpowiedzi do
pyta znajduj si prawidowe rozwizania ale nie naley ciga!
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?
Cz II strona 46 (86)
Rozdzia 6
Cz II strona 47 (86)
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
Autor wychodzi z zaoenia, e typowy tester nie jest wyksztaconym programist. Oczywicie, nie
musi tak by (przyp. tumacza).
Cz II strona 48 (86)
Cz II strona 49 (86)
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
Cz II strona 50 (86)
znajduje si w czasie przygotowa, a nie
podczas samego przegldu2.
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)..
Cz II strona 51 (86)
Cz II strona 52 (86)
Cz II strona 53 (86)
Cz II strona 54 (86)
Cz II strona 55 (86)
Cz II strona 56 (86)
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++.
Cz II strona 57 (86)
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).
Cz II strona 58 (86)
Cz II strona 59 (86)
Cz II strona 60 (86)
Cz II strona 61 (86)
Cz II strona 62 (86)
Podsumowanie
Cz II strona 63 (86)
Pytania
Pytania maj na celu uatwienie zrozumienia. W aneksie A Odpowiedzi do
pyta znajduj si prawidowe rozwizania ale nie naley ciga!
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
Cz II strona 64 (86)
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.
Najwaniejsze punkty tego rozdziau:
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
Cz II strona 65 (86)
Cz II strona 66 (86)
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.
Cz II strona 67 (86)
Testowanie
Dynamiczne
testowanie
metodami biaej
skrzynki
Programowanie
Identyfikacja
bdu
Lokalizacja i
usuwanie bdu
Testowanie kawakw
Cz II strona 68 (86)
Cz II strona 69 (86)
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
Cz II strona 70 (86)
Konfiguracja w wiecie
rzeczywistym
Cz II strona 71 (86)
Cz II strona 72 (86)
Cz II strona 73 (86)
Warto na wyjciu
-1
-1
+1
-0
+0
1.2
2-3
abc
a123
Cz II strona 74 (86)
Cz II strona 75 (86)
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.
Cz II strona 76 (86)
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.
Cz II strona 77 (86)
Cz II strona 78 (86)
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
Cz II strona 79 (86)
Cz II strona 80 (86)
Cz II strona 81 (86)
Cz II strona 82 (86)
Cz II strona 83 (86)
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
Cz II strona 84 (86)
00:00:00
1,2,3,4,5,6,7
Cz II strona 85 (86)
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.
Cz II strona 86 (86)
Pytania
Pytania maj na celu uatwienie zrozumienia. W aneksie A Odpowiedzi do
pyta znajduj si prawidowe rozwizania ale nie naley ciga!
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
W TEJ CZCI
Testowanie konfiguracji
Testowanie kompatybilnoci
Testowanie rnych wersji jzykowych
Testowanie atwoci korzystania
Testowanie dokumentacji
Testowanie witryn WWW
Strona 2 (99)
Rozdzia 8
Testowanie konfiguracji
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.
Najwaniejsze punkty tego rozdziau:
1. Czemu testowanie konfiguracji jest konieczne
2. Czemu testowanie konfiguracji bywa ogromnie
pracochonne
3. Podstawowe sposoby testowania konfiguracji
Strona 3 (99)
4. Jak wej w posiadanie potrzebnego sprztu
5. Jak postpowa testujc inne rodzaje
oprogramowania ni dla komputerw osobistych
stacja CD-ROM
adapter wywietlacza
zasilacz
magistrala
jednostka systemowa
karta gwna.
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
Strona 5 (99)
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.
Strona 9 (99)
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.
Laser
XXX
LDYI2000
1.0
Czarnobiay
Opcje
Opcje
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.
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.
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.
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
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
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
Strona 26 (99)
Programy do
przetwarzania
tekstu
Arkusze
kalkulacyjne
Bazy danych
Programy do
malowania i
pisania
Gry
Programy
edukacyjne
Strona 27 (99)
Aplikacja #3
Aplikacja #2
Aplikacja #1
Platforma 1.0
Apllikacja #4
Nowa aplikacja
Platforma 2.0
Aplikacja #5
Platforma 2.1
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)
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.
Strona 30 (99)
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
Pytania maj na celu uatwienie zrozumienia. W aneksie A Odpowiedzi na
pytania znajduj si prawidowe rozwizania ale nie naley ciga!
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
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
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?
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.
Najlepiej, oczywicie, aby wszyscy znali ten jzyk doskonale. Istotne dla krajw, ktre wicej
oprogramowania importuj ni eksportuj (przyp. tumacza).
2
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`u 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.
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
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.
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
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
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
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
Liczby
Waluta
Data
Godzina
Kalendarz
Adresowanie
Numery telefonw
Formaty papieru
Strona 44 (99)
Strona 45 (99)
Strona 46 (99)
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.
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
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 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
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
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.
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
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.
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
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.
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.
Strona 57 (99)
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.
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.
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.
Strona 62 (99)
Wiek
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%
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.
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.
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
Pytania maj na celu uatwienie zrozumienia. W aneksie A Odpowiedzi na
pytania znajduj si prawidowe rozwizania ale nie naley ciga!
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
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.
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
Numer identyfikacyjny
programu
Instrukcje dla
instalacji
Prawa
autorskie
Wersja
programu
Strona 72 (99)
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.
Strona 74 (99)
Co sprawdzi
Co uwzgldni
Zagadnienia oglne
Czytelnicy
Terminologia
Tre i zawarto
Same fakty
Krok po kroku
Rysunki i
fragmenty ekranu
Prbki i
przykady
Strona 75 (99)
Pisownia i
gramatyka
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.
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
Pytania maj na celu uatwienie zrozumienia. W aneksie A Odpowiedzi na
pytania znajduj si prawidowe rozwizania ale nie naley ciga!
Strona 78 (99)
1.Uruchom program Paint w Windows (zobacz rysunek 12.4) i poszukaj
przykadw dokumnetacji ktr naleaoby przetestowa. Co mona
znale?
Strona 79 (99)
Rozdzia 13
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.
Najwaniejsze punkty w tym rozdziale to:
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.
Strona 81 (99)
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?
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.
Strona 85 (99)
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?
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.
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.
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.
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.
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!
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
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
Pytania maj na celu uatwienie zrozumienia. W aneksie A Odpowiedzi na
pytania znajduj si prawidowe rozwizania ale nie naley ciga!
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
W TEJ CZCI
Testowanie automatyczne i narzdzia do testowania
Polowanie na bdy i testowanie beta
Strona 2 (34)
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.
Narzdzia do testowania
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.
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
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.
Strona 8 (34)
Normalna konfiguracja
Kabel klawiatury
Kabel myszy
Sterownik testow
Strona 9 (34)
Normalna konfiguracja
Konfiguracja
namiastkowa
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.
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
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.
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.
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
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
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>>
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.
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.
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
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.
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!
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
Pytania maj na celu uatwienie zrozumienia. W aneksie A Odpowiedzi na
pytania znajduj si prawidowe rozwizania ale nie naley ciga!
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)
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.
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)
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
Pytania maj na celu uatwienie zrozumienia. W aneksie A Odpowiedzi na
pytania znajduj si prawidowe rozwizania ale nie naley ciga!
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
W TEJ CZCI
Planowanie testowania
Jak pisa zadania testowe i rejestrowa ich wyniki
Raportowanie wynikw
Pomiar sukcesu
Strona 2 (84)
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.
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.
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
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.
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.
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
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
Testowanie 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
---
---
---
---
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.
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
Gotowy plan testowania
Gotowe wszystkie zadania
testowe
Wykonanie testw po raz
pierwszy
Wykonanie testw po raz drugi
Data rozpoczcia
7 dni po zamkniciu
specyfikacji wyaga
Gotowy plan testowania
Trwanie
4 tygodnie
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
Pytania maj na celu uatwienie zrozumienia. W aneksie A Odpowiedzi na
pytania znajduj si prawidowe rozwizania ale nie naley ciga!
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)
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.
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
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.
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
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.
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)
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
Pytania maj na celu uatwienie zrozumienia. W aneksie A Odpowiedzi na
pytania znajduj si prawidowe rozwizania ale nie naley ciga!
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)
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.
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
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:
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.
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.
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.
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.
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
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.
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
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
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
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.
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.
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:
Autor:
Programista:
Podpisy:
Tester:
Kierownik projektu:
Strona 65 (84)
Marketing:
Obsuga produktu:
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
Strona 67 (84)
Szczegowy opis
danych wejciowych i
krokw procedurey
testowej
Informacja do
ledzenia zmian cyklu
yciowego
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
Pytania maj na celu uatwienie zrozumienia. W aneksie A Odpowiedzi na
pytania znajduj si prawidowe rozwizania ale nie naley ciga!
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)
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.
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
Lista bdw
speniajcych
kryteria pytania
Strona 75 (84)
Nr
Tytu bdu
Priorytet
Waga
Przypisany
komu
005
WaltP
ElP
BobH
BobH
023
024
025
Strona 76 (84)
030
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
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
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
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
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
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
Pytania maj na celu uatwienie zrozumienia. W aneksie A Odpowiedzi na
pytania znajduj si prawidowe rozwizania ale nie naley ciga!
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.
-
W TEJ CZCI
Zapewnienie jakoci oprogramowania
Kariera testera oprogramowania
Strona 2 (28)
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
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.
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.
Testerzy
Programici
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
Kierownicy
zapewnienia
jakoci/testowania
Kierownicy
produkcji
Kierownicy
projektw
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
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
Pytania maj na celu uatwienie zrozumienia. W aneksie A Odpowiedzi na
pytania znajduj si prawidowe rozwizania ale nie naley ciga!
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)
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
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.
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.
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.
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.
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).
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
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.
Strona 28 (28)
10.Uyteczno. Uytkownik, nie program ani sprzt, ma by panem.
Produkty powinny by naturalne i intuicyjne w uyciu.
Pytania
Pytania maj na celu uatwienie zrozumienia. W aneksie A Odpowiedzi na
pytania znajduj si prawidowe rozwizania ale nie naley ciga!
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.
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)
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
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
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
Narzdzia do testowania
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