Strona 1 z 11

O czym tester powinien pamita nawet po pnocy

Autor: Hans Schaefer Hans Schaefer, Software Test Consulting
hans.schaefer@ieee.org.
Hans Schaefer to jeden z najbardziej znanych na wiecie specjalistw w dziedzinie testowania
oprogramowania komputerowego oraz znakomity prelegent i wykadowca. Przewodniczcy
Norwegian Software Testing Qualifications Board.
http://home.c2i.net/schaefer/testing.html
Tumaczenie - na podstawie teksu Hansa Schaefera wykona Bogdan Bereza
(bogdan.bereza@victo.eu)
Tester moe po prostu wykonywa swoj prac, co niekiedy wystarcza. Moe take w ni woy
nieco wicej zaangaowania, czyli zrobi lepsz robot. W tym artykule prbuj wyjani, na czy
polega to nieco wicej zaangaowania.

Nie wystarcza testowanie w zwyky sposb.

Systematycznego testowania systemw i oprogramowania mona si nauczy tak samo, jak
kadej innej inynierskiej umiejtnoci. Dostpne s systemy certyfikacji wiedzy dla testerw
(ISTQB, ISEB, GTB), dostpne s ksiki (Myers 79, Beizer 95, Kaner 99, Copeland 2004) i normy
(terminologia ISTQB, BS 7925, IEEE 829, 1008, 1012). Ksiki i standardy dostpne s ju od
dawna, a wiele technik jest powszechnie uznawanych, co oznacza, e testowania mona si
uczy, a nastpnie wykonywa je w jaki usystematyzowany sposb.
Nie oznacza to wprawdzie, e opisane w tych materiaach, typowe metody testowe s
powszechnie stosowane (Schaefer 2004), ale przynajmniej istnieje moliwo wykonywania
testowania wg zasad opisanych w podrcznikach.
Tester, albo inynier testowy, wykonuje dwa podstawowe zadania: projektowanie przypadkw
testowych oraz ich wykonywanie poczone z rejestrowaniem i analizowaniem wynikw. Jeli
uzyskane wyniki s rne od spodziewanych, zgasza si niezgodno i nadzoruje jej
rozwizywanie. Ponadto nowoczesne metody, takie jak testowanie eksploracyjne (zob. witryna
Jamesa Bacha), zalecaj take stosowanie automatyzacji testw oraz zarzdzanie przez testerw
czasem swojej pracy.
Testowanie w zwyky sposb polega na tym, by opanowa kilka technik i nastpnie realizowa je,
wykonujc testy i raportujc ich wyniki. Zwykle stosowana formua zaleca, aby przetestowa
system i nie okrela adnych dodatkowych szczegw. W niektrych ksikach testowanie
definiuje si jako uzyskiwanie informacji o jakoci lub pomiar jakoci (Hetzel). Poniewa
testowanie jest jedn z ostatnich wykonywanych w projekcie czynnoci, znajduje si zwykle pod
siln presj czasow, co powoduje, e testerzy maj jawn bd ukryt motywacj do tego,
aby zrezygnowa z dokadnego i starannego wykonywania swej pracy. Na przykad, poniewa
znajdowanie bdw opnia zarwno samo testowanie, jak i dostaw czy odbir produktu,
pojawia si ukryty nacisk na to, by bdw nie znajdowa, a przynajmniej nie te powane.
Testowanie po prostu ma by zrobione. W takiej sytuacji praca przestaje by motywujca, nie

Strona 2 z 11
inwestuje si w ksztacenie, ludzie zaczynaj szuka innej pracy, a jako testowania nie
poprawia si.

Czy mona testowa lepiej?

Glenford Myers ju w 1979 roku zdefiniowa1 cel testowania odmiennie: celem testowania jest
znajdowanie bdw. Negatywne podejcie, prby zamania produktu pozwalaj na znajdowanie
liczniejszych i powaniejszych bdw, a nie tylko sprawdzanie, e oprogramowanie dziaa.
Ludzie zwykle robi to, co im si kae. Jeli poleci im znajdowanie jak najwikszej liczby bdw,
bd prbowa. Jeli natomiast kaza im szybko skoczy testowanie, przy okazji wprost lub
porednio komunikujc, e znajdowanie bdw opnia projekt, wwczas bd stara si nie
znajdowa bdw, albo wiele z nich przeocz.
Pierwsz zasad powinno wic by jasno okreli cel testowania, i upewni si, e jest on dla
wszystkich w peni zrozumiay. Omwimy o poniej.
wiat si zmienia, zwaszcza w dziedzinie wytwarzania oprogramowania, i trzeba to wzi pod
uwag przy kadym zajciu, nie tylko przy testowaniu. Pojawiaj si nowe techniki, metody i
narzdzia, nowe sposoby projektowania. Oprogramowanie staje si coraz bardziej
skomplikowane, a produkty programistyczne wci bardziej zalene jedne od drugich. Zmieniaj
si wymagania, na przykad coraz wikszy nacisk kadzie si na bezpieczestwo, uyteczno i
mono wykonania na wielu platformach. Wszystko to powoduje, e zmieniaj si warunki
wykonywania pracy testerw, ktrzy musz si wobec tego wci rozwija pod wzgldem
zawodowym. Ten temat take zostanie obszerniej omwiony poniej.
Problemem jest take nastawienie wielu ludzi. Niektrzy chtnie uznaj podawane oficjalnie
informacje lub obowizujce zasady. Inni s bardziej krytyczni badaj i zadaj pytania. Skoro
jednym z celw testowania jest znajdowanie problemw i wad, mona testowa skuteczniej, gdy
nie przyjmuje si rzeczy na wiar, sprawdza szczegy, poszukuje dodatkowych informacji i
samodzielnie myli.
Do zada testera naley zgaszanie bdw. Nie jest to atwe. Literatura na temat testowania
zwykle opisuje zasady zarzdzania zgoszeniami bdw, czyli cykl yciowy zgosze na ktry
skada si ich raportowanie, okrelanie wagi oraz rozwizywanie. To s jednak tylko podstawy
w rzeczywistoci zgaszanie bdw wymaga czego wicej. Mona je porwna do zadania, jakie
stoi przed sfrustrowanym uytkownikiem, szukajcym pomocy w dziale wsparcia dostawcy:
trzeba problem opisa w taki sposb, aby druga strona uznaa go za na tyle wany, aby mu
zaradzi. Oznacza to zgromadzenie dodatkowych informacji na temat bdu, a take umiejtno
sprzedania zgoszenia bdu osobie odpowiedzialnej.
Wreszcie, tester ma take pewne prawa. Nie powinnimy testowa wszystkiego, co tylko
zostanie nam zwalone na biurko. Jeli brak nam niezbdnych informacji, lub gdy przekazany do
testowania produkt roi si od bdw, testowanie go jest zwykym marnotrawstwem.
Powinnimy stosowa kryteria dopuszczenia do testowania jako swego rodzaju Kart Praw
Testera (Gilb 2005). Bdzie o tym take mowa poniej.

W ksice The Art of Software Testing; jej kolejne, poszerzone wydanie pod niezmienionym tytuem ukazao si w polskim tumaczeniu w 2005 roku (wyd. Helion).

Strona 3 z 11
Dotykamy tutaj zagadnie z zakresu filozofii testowania. Istniej jednak pewne najzupeniej
podstawowe reguy dotyczce testowania. Cho temat ten budzi wiele kontrowersji, pozwol
sobie przedstawi niektre z nich z mojej konferencyjnej prezentacji (Schaefer 2004).
Na tym sprawy si nie kocz. Testerzy powinni nieustannie poszukiwa nowych wyzwa.
Niniejszy artyku jest tylko pocztkiem.

Cel testowania
Istnieje wiele rnych celw testowania. Jeden z gwnych, cho by moe do nudny, to
pomiar jakoci testowanego produktu. Testowanie traktujemy wtedy jak najzwyklejsze
urzdzenie pomiarowe. Wykonywanie pomiarw nie jest szczeglnie zabawne, ale konieczne i
musi by zrobione starannie. Aby jednak mc mierzy skutecznie i sprawnie, tester powinien
uzyska odpowiedzi na kilka pyta. Po pierwsze, jakie waciwoci (atrybuty) jakoci s
najwaniejsze i jak dokadnie powinno si je mierzy?
Wedug innej definicji, celem testowania jest uzyskanie zaufania do produktu. Ale zaufanie
najlepiej si osiga, kiedy prbuje si bez powodzenia je podway. Przypomina to prac
naukow: kto przedstawia now teori, a inni specjalici usiuj j odrzuci. Po jaki czasie, jeli
teoria si obroni, zaczyna by zwolna uznawana. To podejcie jest zgodne z definicj Myersa:
znajdowanie bdw! Jest to podejcie pesymistyczne. Pesymista przypuszcza, e co nie dziaa i
usiuje znale potwierdzenie. Kada znaleziona wada czy usterka to sukces.
Ludzkim dziaaniem kieruje motywacja. Definicja testowania jako aktywnego poszukiwania wad
motywuje, a take pozwala znajdowa wicej bdw. S tego dwie przyczyny. Po pierwsze,
projektuje si bardziej destruktywne lub po prostu liczniejsze przypadki testowe. Po drugie,
uwaniej analizuje si uzyskane wyniki, wnikajc w szczegy pomijane przez sabiej
zmotywowanego testera. Moe to np. oznacza analizowanie wynikw niedostrzegalnych wprost
na monitorze, lecz ukrytych w gbi plikw, baz danych, buforw pamici lub w sieci.
Tester powinien usiowa znajdowa bdy! Wady mog by ukryte tam, gdzie nieatwo je
dostrzec, to znaczy niekoniecznie na ekranie monitora!
Na tym jednak sprawy si nie kocz. Wady s towarzyskimi stworzeniami: lubi wystpowa w
gromadzie. To tak jak z komarami: jeli zobaczy si i zabije jednego, czy sdzi si, e wicej ich ju
nie ma w okolicy? Dlatego wanie naley przyjrze si uwanie rejonom, gdzie znalazo si bdy.
Testerzy powinni domyla si, gdzie szuka bdw. Powinni zapozna si z rnymi
wskanikami jakoci, czyta raporty, w ktrych mona je odnale. Jako wskaniki mog suy
dane na temat wczeniej znakowanych bdw, braki w komunikacji w projekcie, zoono
programu, czste zmiany, nowe technologie, nowe narzdzia, nowe jzyki programowania,
zmiany w zespole, konflikty midzy uczestnikami projektu itd. Kopot w tym, e te wskaniki
czasem wskazuj w niewaciwym kierunku. Wady mogy zosta wykryte w obszarze nieomal
bezbdnym dlatego, e akurat na tam skupiy si przypadki testowe. Komunikacja w projekcie
moe wydawa si rozpaczliwa, jeli jego uczestnikw dzieli dua odlego. Zdarza si jednak, e
mimo tego ludzie sprawnie si ze sob porozumiewaj korzystajc z nieformalnych kanaw,
albo te interfejs midzy komponentami okaza si zaprojektowany nadzwyczaj dobrze, nieomal
idiotoodpornie. Z jednej strony wiele danych pokazuje na korelacje midzy wskanikami a
rozkadem bdw; z drugiej strony, zawsze zdarzaj si wyjtki. Na przykad, najbardziej zoone

Strona 4 z 11
komponenty konstruowane s przez najbardziej dowiadczone osoby. Czste zmiany na przykad
zwykle powoduj bdy albo wskazuj sabo zrozumiane i le zaprojektowane obszary, ale
zdarzaj si te zmiany dobrze przemylane i poddane wnikliwym inspekcjom.
W niektrych projektach zdarzaj si psy pogrzebane w centralnych miejscach, gdzie lepiej
niczego nie rusza. Takie obszary mog by sabo zrozumiane, le zdefiniowane i rojce si od
bdw. Poniewa kady wie, e lepiej ich nie rusza, nikt nie domaga si ich modyfikowania.
Nowe technologie take powoduj zagroenia, czciowo dlatego, e mog one wynika z
samych technologii, czciowo za dlatego, e ludzie nie s jeszcze z nimi oswojeni, nie znaj
kryjcych si w ich uytkowaniu trudnoci. To samo dotyczy testerw. Z drugiej strony, moe
wystpi efekt odwrotny: nowe technologie mog uwolni nas od wielu zagroe, po prostu je
uniemoliwiajc.
Na zakoczenie, przypatrzmy si czynnikowi ludzkiemu. To ludzie myl si i popeniaj bdy.
Badania wykazay, e dobrzy i li programici rni si od siebie zarwno produktywnoci
jak i czstotliwoci bdw. Bdy nie wynikaj tylko z programowania, trudniej jednak
precyzyjnie okreli odpowiedzialno za kopoty z projektowaniem i specyfikacjami. Jeden
czynnik ma niezmiennie negatywny wpyw na jako: fluktuacja kadr. Kiedy nowe osoby
przejmuj czyj prac, zwykle nie uzyskuj o niej penej wiedzy, gdy dowiadczenie oraz
intuicja z trudem tylko s przekazywane. Dotyczy to zwaszcza sytuacji, gdzie pewne obszary byy
znane tylko jednej osobie.
Podsumowujc: istnieje wiele wskanikw, na podstawie ktrych mona wnioskowa o bdach,
ale naley si nimi posugiwa ostronie.
Bdy wystpuj gromadnie: s towarzyskie!
Wiele rozmaitych bdw moe mie wspln przyczyn. Warto j zidentyfikowa, a pniej
szuka jej kolejnych skutkw!
Gdzie znao si bdy, tam warto szuka dalej!
Kolejna definicja testowania to pomiar ryzyka. Oznacza to, e testowanie jest najwyraniej
form zapobiegania zagroeniom, czci zarzdzania ryzykiem. W najgorszym razie, to testerzy
powinni zadawa pytania o zagroenia zwizane z produktem, zwaszcza jeli nie zadaje ich nikt
inny. Podstawowy sposb identyfikacji ryzyka to wzicie pod uwag profilu uytkowania i
skutkw ewentualnych awarii. Tester powinien spyta si o to, ktrzy uytkownicy jak czsto
bd wykonywali jakie czynnoci? Jakie bd rnice midzy uytkownikami? Czy ten rozkad
bdzie zmienia si w czasie?
Koniecznie musi si uwzgldni moliwe bdy wprowadzania danych i inne pomyki.
Uytkownicy miewaj niezdarne palce, a programy miewaj bdy! Naley wic zastosowa nie
tylko poprawne dane wejciowe, ale zapewne take bardzo wiele niepoprawnych.
Kolejny czynnik to moliwe koszty awarii. Moe by trudno je okreli. Na pocztku warto sobie
przynajmniej zada pytanie: co najgorszego moe si wydarzy w razie awarii funkcji,
funkcjonalnoci lub zadania uytkownika?
Testowanie jest form zapobiegania zagroeniom.
Od czego zaley ryzyko?

Strona 5 z 11
Jakie s skutki niepoprawnych danych wejciowych?
Podsumowujc: najlepiej, gdy tester jest pesymist (pesymista to optymista majcy ju
dowiadczenie). Jeli co nie dziaa, to znakomicie, gdy nikt nie bdzie musia dozna tej awarii
w przyszoci. Pozytywne skutki oka si dopiero na dusz met. Lepsze testowanie zmusza
take konstruktorw do lepsze pracy, informuje kierownictwo o istniejcych zagroeniach, a
ponadto obnia koszty naprawy bdw. Testerzy przynosz ze wieci, ale na tym polega ich
praca. Nikt nie lubi kontroli prdkoci na szosie, ale dziki nim szosy s bezpieczniejsze i wszyscy
z tego korzystamy.
Pesymista jest lepszym testerem!

Cige uczenie si
W niemal kadym zawodzie trzeba wci si uczy, ale dla testerw jest to zupenie niezbdne.
W wikszoci przypadkw testowanie wykonuje si w pewnym stopniu systematycznie, przy
pomocy jakiego podejcia czarnoskrzynkowego. Ponadto projektowanie testw moe
wykorzystywa pewne heurystyki. Ale podejcia czarnoskrzynkowe nie gwarantuj penego
pokrycia testowego. Zasady heurystyczne nigdy nie gwarantuj penego pokrycia, gdy zale od
osobistego dowiadczenia, wzgldnie od dowiadczenia uzyskanego za porednictwem innych
osb. Z kolei podejcie biaoskrzynkowe nie jest w stanie ujawni np. pominitych wymaga.
Wszystko to sprowadza si o kwestii: to, o czym tester nie wie, nie moe by przetestowane! A
wic tester powinien wiedzie jak najwicej - tylko jak?
Testerowi przydaje si dowiadczenie w programowaniu. Nawet po testach moduowych
przeprowadzonych przez programistw, w kodzie pozostaje wiele bdw a ponadto testy
moduowe rzadko kiedy s starannie przeprowadzane. Tester powinien orientowa si w
trudnociach, jakie stwarza dany jzyk programowania. Na przykad ptle i liczniki z reguy
sprawiaj kopoty, powodujc bdy o jedno. Jeli tester nie ma o tym pojcia, nie przetestuje
ptli z liczb iteracji zerow, maksymaln, wiksz o jeden od maksymalnej ani te z jedn
iteracj. Wwczas jedynie przypadek pozwoli na znalezienie bdu o jedno.
Testerowi przydaje si dowiadczenie w projektowaniu. Projektowanie dotyczy w znacznym
stopniu okrelania zakresu i komunikacji: ktry modu, w jakim zakresie, przy uyciu jakich
zalenoci, powinien wykonywa ktre zadanie? Gdzie znajduj si te moduy, jak si
komunikuj, jak rozwizuj konflikty? Jeli tester nie orientuje si w sprawach architektury i
zwizanych z ni problemw, nie bdzie mu atwo zaplanowa testy integracyjne.
Tester potrzebuje te wiedzy dziedzinowej. Testowanie systemowe polega na sprawdzaniu, czy
system realizuje waciwe rozwizanie, czy spenia wymagania dziedzinowe. Kto potrafi
przetestowa system sygnalizacji kolejowej? (eee na czym polega sygnalizacja kolejowa?)
Cho TROCH znajomoci dziedziny jest niezbdne, albo porozumiewanie si ze znajcymi j
innymi udziaowcami.
Niestety, to nadal nie wystarcza. Wana w testowaniu jest umiejtno uzyskiwania waciwych
informacji od waciwych ludzi. Warto nauczy si czego o technikach przeprowadzania
wywiadw. Posiadszy t umiejtno, uzyskuje si wiele nowych informacji! Systemy s zalene
od innych systemw w coraz bardziej zawiy sposb, pojawia si wiele nieoczekiwanych
interfejsw. Dla przykadu, kto moe integrowa TWJ serwis internetowy ze SWOIM portalem,

Strona 6 z 11
i jednoczenie z innymi portalami. Moe twj serwis dziaa pod jakim wzgldem inaczej ni
wszystkie inne, i dlatego nie jest ju atrakcyjny- lub jest o wiele atrakcyjniejszy, ni mona si
byo spodziewa. Co oznacza, e testowanie pod ktem obecnych udziaowcw systemu nie
zawsze wystarcza. Mog istnie najzupeniej nowe sposoby wykorzystania lub interfejsu do
twojego systemu, nowe nieprzewidziane podejcia do niego i naley przynajmniej sprbowa
cz z nich przewidzie!
Tester powinien stale usiowa znale nowe punkty widzenia testowanego systemu, nowe
sposoby podejcia i zastosowania. Wreszcie, chcemy, eby testerzy korzystali z najnowszych
metodyk i technologii. Trzeba si ich nauczy. Naley czyta ksiki powicone testowaniu,
wyszukiwa i poznawa narzdzia, czyta czasopisma, udziela si w grupach dyskusyjnych,
rozmawia z innymi profesjonalistami i bra udzia w konferencjach testowych!
Uczmy si wicej i o wszystkim!
Uczmy si programowania, architektur, nowych dziedzin, narzdzi wszystkiego!
Trzy rzeczy cign mj sprzt: psy, psy i psy. (Roald Amundsen).
Dla testera, te trzy rzeczy to: uczy si, uczy si i uczy si.

Krytyczne nastawienie
Nie wierzcie w byle co! Mj kolega powiedzia kiedy, e: wierzy to naley w niedziel w
kociele. Poza tym wszystko naley sprawdza.
Niestety atwiej bywa wierzy, nie wymaga to adnego wysiku. Pomylcie, co jest napisane w
gazecie. Czy to prawa? Gdzie bya bro masowego raenia? Czy naprawd za wszystko co ze
odpowiadaj ydzi? Czy rzeczywicie ogldanie telewizji jest niebezpieczne dla dzieci? Czy
naprawd pewien sok jest zdrowy? Odpowied: atwiej o to nie pyta. Jeli wszystko poddawa
w wtpliwo, niczego nie mona osign, wic w codziennym yciu przyzwyczailimy si nie
pyta, lecz wiele rzeczy przyjmowa na wiar. Wierzy, zakada i NIE ZADAWA PYTA!
Testerowi nie wolno niczego zakada to moe by nieprawd! Projektanci, autorzy
specyfikacji, programici dokonuj wielu zaoe. Czasem trudno nam zada pytanie, bo
obawiamy si wypa gupio. Ten, kto zna odpowied, moe przebywa daleko albo dostp do
niego moe by trudny. Moe nam nawet nie przyj do gowy, e moliwa jest inna interpretacja
od powszechnie przyjmowanej. Kto inny nie zna odpowiedzi, jeszcze kto odpowiada
sarkastycznie
Bdc pesymist, mona rwnie dobrze przyj zaoenie, e kade przypuszczenie jest bdne.
Niczego nie zakadaj! Pytaj!
S sposoby na to, aby nie musie czu si gupio pytajc. Trzeba nauczy si postpowa z
ludmi, przeprowadza wywiady, zdoby pewno siebie (jak si uczy zostao napisane
wczeniej). Mona spyta kogo innego, przeczyta, dokona przegldu, przespa spraw,
sprbowa znale inne wytumaczenie. Byle tylko niczego nie przyjmowa na wiar! Niczego nie
traktowa jako oczywistoci! A nade wszystko, nie wierzy, e system zapewne dziaa
poprawnie. Co najmniej jeden system informatyczny w banku nieprawidowo oblicza procent
w kocu nieatwo to skontrolowa By sobie system informacji geograficznej, ktry wybiera

Strona 7 z 11
tras dookoa wiata zamiast najkrtszej. S systemy linii lotniczych do rezerwacji miejsc, ktre
nie pokazuj wszystkich dostpnych pocze. Istnieje wiele wicej podobnych przykadw.
Jeli nikt nie zadaje waciwego pytania, moe wanie Ty mgby to zrobi! Pomyl o nowych
moliwociach, nieznanych problemach i o wszystkim, czego si nauczysz! Myl
niestandardowo!

Wady
Nikt nie kocha tego, co przynosi ze wieci. Testerzy zwykle przynosz ze wieci (czasem nie ma
zych wiadomoci, wszystko wydaj si dziaa poprawnie, ale to inna historia).
Ze wieci to bdy, albo zdarzenia czy kwestie, aby nazwa je jako neutralnie. Duo na ten
temat napisano w podrcznikach. Zdarzenia s raportowane, rejestrowane, zarzdzane,
usuwane, poddawane testom ponownym i testom regresji, i wszyscy dobrze o tym wiemy. Ale
pewne sprawy ksiki przemilczaj:
1 zdarzenie jest dla testera interesujce tylko wtedy, kiedy zostanie zaakceptowane jako wada i
naprawione;
2 zdarzaj si awarie, ktre wystpuj tylko wtedy, kiedy wykonuje si szereg przypadkw
testowych po kolei w okrelonej kolejnoci.
Pierwsza sprawa to umiejtno sprzeday i dyscyplina. Nikt nie ma ochoty wydawa pienidzy
na napraw bdw naprawia si je tylko wwczas, gdy s dostatecznie wane. Wobec tego
tester powinien zgosi bd w taki sposb, aby konstruktor zrozumia konieczno jego
naprawienia. Konsekwencje awarii musze wydawa si znaczne, jej prawdopodobiestwo
wysokie, z zdarzenie musi by atwo odtworzy. Tester nie moe wobec tego poprzesta na
zapisaniu zdarzenia w raporcie. Tester powinien pomyle w nastpujcy sposb: czy nie ma
czasem scenariuszy wydarze, w ktrych ta sama wada mogaby spowodowa jeszcze gorsz
awari? Moe dla niektrych udziaowcw sprawa jest powaniejsza, ni si wydaje? Czy sprawa
ogranicza si do zaobserwowanego symptomu, czy kryje si za ni co wicej? Raz jeszcze warto
myle niestandardowo. Czasem trzeba wymyli i wykona dodatkowe testy. Sporo ciekawego
materiau na ten temat mona znale u Cema Kanera.
Nie mona lekceway czynnika ludzkiego: dyplomacji, grzecznoci i tak dalej. Tester powinien
zadba o to, aby nikogo nie urazi osobicie swoim zgoszeniem bdu. Kto powiedzia, e
dyplomacja to umie kaza komu pj w diaby tak, by tamten z radoci wybra si w drog.
Kade zdarzenie albo bd naley zbada dokadniej!
Zgoszenie bdu musi podkrela zwizane z nim zagroenie!
Raportowanie bdw wymaga umiejtnoci skutecznej sprzeday!
Zgaszajc bdy nie wolno zapomina o dyplomacji!
Zdarzaj si jednak gorsze sytuacje: awarie, ktrych nie da si odtworzy. Raz problem si
pojawia, za drugim razem go nie ma. Takie wydarzenia nazywa si przejciowymi bdami. S z
nimi szczeglnie due kopoty, jeli pocigaj za sob awari caego systemu. Ponowne
uruchomienie systemu usuwa stare dane z pamici, co zaciera lady. Czsto przejciowe bdy
spowodowane s trwajcej przez duszy czas, stopniow degradacj pamici lub innych
zasobw, na przykad tzw. przeciekami pamici. Kiedy jaka funkcja programu nie zwraca zuytej

Strona 8 z 11
pamici, system moe mimo to dziaa tak dugo, a pami si nie wyczerpie. Jeszcze gorzej, gdy
zjawisko takie nie wystpuje kadorazowo, tylko w szczeglnych okolicznociach.
Take inne zasoby, nie tylko pami, mog ulec wyczerpaniu. Na przykad sonda Mars Explorer
przestaa dziaa po 18 dniach, gdy otwartych zostao zbyt wiele plikw na szczcie NASA
zdoaa zaadowa nowe oprogramowanie. Wiele wbudowanych systemw czasu rzeczywistego
uruchamia procesy ponownie co pewien czas, aby zapobiega zagroeniu stopniowej degradacji
zasobw. Niestety, WSZYSTKIE wsplne zasoby mog ulec awarii, dlatego naley sprawdza
wszystkie dane wyjciowe, nie tylko te atwe do zobaczenia na ekranie. Pliki, wskaniki do
pamici, bufory, bazy danych, meldunki, rejestry cokolwiek. Moe powsta sytuacja wycigu,
zalenie od precyzyjnego pooenia w czasie rwnolegych wtkw lub procesw. Nietrudno
spostrzec dane pojawiajce si na ekranie wszystko inne wymaga narzdzi lub dodatkowych
czynnoci ze strony testera, ktre to czynnoci mog okaza si zbyt czasochonne. Bdy
przejciowe wymagaj aby je ujawni caego szeregu przypadkw testowych, nie tylko
pojedynczej pary we-wy. Wreszcie bd moe tkwi gdzie w systemie operacyjnym, w
bibliotekach, w komponentach nie bdcych czci produktu.
Kiedy pojawi si przejciowy bd, warto mc ponownie wykona t sam co poprzednio
sekwencj przypadkw testowych, moe nawet z identycznymi ustawieniami czasowymi, i
wykona dodatkowe kontrole. James Bach (Bach 2005) proponuje szereg rad, jak bada takie
problemy:
Naley analizowa nawet przejciowe bdy!
Naley w trakcie testw rejestrowa wszystkie wykonywane czynnoci i obserwowane
zdarzenia!
Musi istnie moliwo powtrzenia wykonanych testw z uruchomianymi dodatkowymi
urzdzeniami rejestrujcymi i analizujcymi!

Tester ma take prawa

Bdc testerem masz swoje prawa.
Testowanie wykorzystywane jest czsto przez innych do czyszczenia Stajni Augiasza. Zamiast
porzdnie pracowa od pocztku, wbudowuje si bdy w system i zleca testerom ich
wyszukiwanie. To marnotrawstwo czasu i pracy. Koszt usunicia bdu znalezionego przez
testerw przekracza wielokrotnie koszt zapobieenia temu bdowi. Powoduje to take
opnienia dostaw. Zadaniem testerw nie powinno by sprztanie po innych, lecz wykonywanie
pomiarw jakoci i raportowanie poziomu ryzyka. Sprztanie jest po prostu prac nie dla nich.
Tester nie jest odkurzaczem!
Rozwizaniem tego absurdu jest stosowanie kryteriw wejcia, co wymusza na innych dostawy o
rozsdnym poziomie jakoci. Karta Praw Testera pojawia si w co najmniej dwch rdach.
W Extreme Programming Projects Lisa Crispin pisze o testerach: najwaniejsze trzy prawa
testerw s nastpujce.
* Prawo do wykonywania i zmiany swoich oszacowa ().
* Prawo do korzystania z niezbdnych do pracy narzdzi ().

Strona 9 z 11
* Prawo do tego, aby rwnie pozostali uczestnicy zespou projektowego, nie tylko testerzy,
poczuwali si do odpowiedzialnoci za jako.
Tom Gilb (Gilb 2003) stworzy nastpujc list praw testera (przytoczon tutaj za zgod autora).
Karta Praw Testera.
1. Testerzy maj prawo do wyrywkowych kontroli otrzymywanego produktu i odrzucania go, gdy
nie spenia kryteriw jakoci.
2. Testerzy maj prawo do jednoznacznych i zrozumiaych wymaga.
3. Testerzy maj prawo rozpoczyna testowanie jak najwczeniej w kolejnych fazach rozwoju
systemu.
4. Testerzy maj prawo do tego, aby specyfikacje testw traktowane byy na rwni z pozostaymi
technicznymi specyfikacjami.
5. Testerzy maj prawo do wspdecydowania o przyjtych kryteriach jakoci.
6. Testerzy maj prawo domaga si zasobw niezbdnych o wykonywania swej pracy.
7. Testerzy maj prawo do rwnomiernego obcienia prac i do prywatnego ycia.
8. Testerzy maj prawo okreli skutki braku czasu na wykonanie dostatecznych testw.
9. Testerzy maj prawo dokonywa przegldw specyfikacji, ktre dotycz ich pracy.
10. Testerzy maj prawo wykonywa testy produktw speniajcych kryteria jakoci i odrzuca
produkty zbyt wadliwe.
Ostatnie sformuowanie w tej licie jest szczeglnie wane: testerzy powinni odrzuca
produkty nie speniajce kryteriw jakoci!

Skrzynka z narzdziami dla testera do uytku nawet w rodku nocy

Jak tester powinien pracowa? O czym powinien zawsze pamita wykonujc swoj prac?
Pierwsza kwestia to testowanie wszystkiego. To o wiele za duo, tego si nie daje osign.
Tester powinien jednak orientowa si, co jest przetestowane, co nie jest, a co czciowo.
Nazywamy to pokryciem testowym.
W skrcie, istniej trzy podstawowe pojcia pokrycia, ktre mona zastosowa do modeli
dziaania systemw zapisanych w postaci grafw; na przykad do grafu przepywu sterowania
(schematu blokowego), grafu przepywu danych, grafu przej stanw, drzewa wywoa,
diagramu architektury systemu lub przypadku uycia.
Podstawowe pokrycie to pokrycie kadego klocka (wza grafu). Kolejny poziom to
przetestowanie kadego cza (krawdzi grafu). Osignicie obu tych poziomw naley traktowa
jako minimum zalecane przy testowaniu. Jeli ma si do dyspozycji wicej czasu, na kolejnym
poziomie mona testowa kombinacje, na przykad pary krawdzi.
Tester powinien umie okreli osignite pokrycie testowe!
Dalej, testerzy powinni postpowa zgodnie z profilem uytkowania systemu, co nie zawsze jest
atwe w testowaniu moduw i podsystemw. Jednak bdc testerem, naley przynajmniej
sprbowa mie cho czciowe rozeznanie, jak stosowany bdzie przedmiot aktualnych testw.
Jeli nie mamy na ten temat adnej wiedzy, naley rwnomiernie testowa rne tryby uycia
pod ktem wytrzymaoci aplikacji. W tej sytuacji interesujce s zwaszcza niepoprawne dane
wejciowe.

Strona 10 z 11

Jeli moliwe, testujmy godnie z profilem uycia!

Gdy to niemoliwe, testujmy odporno na bdne dane wejciowe.
Jedna z technik jest podstawowa dla testw czarnoskrzynkowych: podzia na klasy
rwnowanoci. Pozwala ona ograniczy wysiek testowy, uzupenia take inne techniki testowe.
Testerzy powinni j zna, ale uwiadamia sobie jej ograniczenia. Testy czarnoskrzynkowe gro
przeoczeniem istotnych aspektw dziaania systemu. Naley zdawa sobie spraw z poytkw
testowania kombinacji. Lee Copeland (Copeland 2004) opublikowa dobre wprowadzenie do tej
techniki.
Podzia na klasy rwnowanoci to dobra technika podstawowa!
Nie zapominajmy o testowaniu kombinacji!
Najgorszy scenariusz to konieczno przyznania si, e testu nie dao si wykona lub jego wynik
by niepoprawny. Duym problemem bywa te rodowisko testowe musi by wczenie
przygotowane i przetestowane. Opnienie si rodowiska testowego zabije kady projekt
testowy co inni bd nam wytyka palcami! Wreszcie, wykryta awaria nie musi by
spowodowana bdem testowanego obiektu, lecz testowych danych wejciowych lub analizy
danych wyjciowych. Bdmy samokrytyczni!
Trzeba sprawdza rodowisko testowe!
Trzeba sprawdzi dane testowe!
Na zakoczenie, kwestia automatyzacji testw. Oprogramowanie powinno by programowalne,
to znaczy atwe do zmiany. Ale zmiana oznacza ryzyko, co pociga za sob konieczno
testowania po kadej zmianie, wykonywania testw ponownych i testw regresji. Wykonywanie
testw przy pomocy robotw uatwia testy regresji. Jednak automatyzacja testw to co wicej:
istniej narzdzia, ktre na podstawie specyfikacji automatycznie generuj przypadki testowe. S
te narzdzia suce do automatycznego tworzenia rodowisk testowych, a take
wspomagajce zarzdzanie testowaniem i testaliami.
Automatyzujcie testowanie!
Pamitajcie, e testowanie to nie tylko wykorzystanie robotw testowych!

Wybrane referencje:
1. Bach 2005: James Bach. Notatki na temat przyczyn bdw przejciowych:
http://blackbox.cs.fit.edu/blog/james/
2. Beizer 95: Boris Beizer, Black Box Testing, John Wiley, 1995
3. Better Software Magazine, www.bettersoftware.com. www.stickyminds.com
Bardzo praktyczne!
4. BS7925: British Standard: www.testingstandards.co.uk/bs_7925-1.htm
5. Copeland 2004: Lee Copeland, A Practitioners Guide to Software Test Design,
Artech House, 2004.
6. Crispin: Lisa Crispin, Tip House, Testing Extreme Programming, AddisonWesley, 2002, take http://home.att.net/~lisa.crispin/XPTesterBOR.htm
7. Gilb 2003: "Testers Rights: What Test should demand from others, and why?".,
Prezentacja plenarna na EuroSTAR 2003
8. GTB: German Testing Board: www.german-testing-board.info German

Strona 11 z 11
Testing Board stworzy wczeniejsz wersj obecnego certyfikatu ISTQB.
9. IEEE Standards: zobacz www.ieee.org
10. ISEB: Information Systems Examinations Board of British Computer Society.
http://www.bcs.org/BCS/Products/Qualifications/ISEB/ prowadzi system certyfikacji dla
testerw od 1999.
11. ISTQB: www.istqb.org International Software Testing Qualifications Board.
12. ISTQB Glossary: www.istqb.org/fileadmin/media/glossary-current.pdf
13. Kaner 99: C. Kaner, J. Falk, H. Q. Nguyen, Testing Computer Software (3rd
ed.), John Wiley, 1999.
14. Kaner bugadvoc: Prezentacja na temat sposobw raportowania bdw.
http://www.kaner.com/pdfs/BugAdvocacy.pdf
15. Myers 79: Glenford Myers: The Art of Software Testing, John Wiley, 1979.
16. Schaefer 2004; Hans Schaefer, What Software People should have known about
Software Testing 10 years ago - What they definitely should know today. Why
they still don't know it and don't use it, EuroSTAR 2004

W jzyku polskim:
1. Glenford Myers "Sztuka testowania oprogramowania" (translated to Polish 2005
and pubished by Helion publ. house)
2. Ron Patton "Testowanie oprogramowania", tumaczenie polskie 2002, MIKOM.
3. Bogdan Wiszniewski i Bogdan Bereza-Jarociski "Praktyka i teoria testowania
programw", MIKOM 2006.