Certyfikowany tester
Plan poziomu podstawowego
International Sotware Testing Qualifications Board
Stowarzyszenie Jako
ś
ci Systemów Informatycznych
Wersja 1.0
© Stowarzyszenie Jako
ś
ci Systemów
Informatycznych
Strona 1 z 78
20 pa
ź
dziernika 2006
Certyfikowany tester
Plan poziomu podstawowego
Wersja 1.0
Stowarzyszenie Jako
ś
ci Systemów Informatycznych
International Software Testing Qualifications Board
Certyfikowany tester
Plan poziomu podstawowego
International Sotware Testing Qualifications Board
Stowarzyszenie Jako
ś
ci Systemów Informatycznych
Wersja 1.0
© Stowarzyszenie Jako
ś
ci Systemów
Informatycznych
Strona 2 z 78
20 pa
ź
dziernika 2006
Wszelkie prawa dla wersji angielskiej zastrze
ż
one dla © International Software Testing
Qualifications Board (dalej nazywane ISTQB).
Grupa Robocza ISTQB, plan Poziomu Podstawowego : Thomas Müller (przewodnicz
ą
cy),
Rex Black, Sigrid Eldh, Dorothy Graham, Klaus Olsen, Maaret Pyhäjärvi, Geoff Thompson
and Erik van Veendendal 2004-2005.
Prawa autorskie zastrze
ż
one © Stowarzyszenie Jako
ś
ci Systemów Informatycznych (SJSI).
Tłumaczenie z j
ę
zyka angielskiego oraz udział w przegl
ą
dach: Bogdan Bereza-Jaroci
ń
ski,
Wojciech Jaszcz, Helena Klitenik, Joanna Nowakowska, Jan Sabak, Anna Seredyn, Lucjan
Stapp, Piotr
Ś
l
ę
zak, Łukasz
ś
ebrowski.
Autorzy, tłumacze, ISTQB oraz SJSI okre
ś
laj
ą
nast
ę
puj
ą
ce warunki korzystania z Planu:
1) Osoby oraz firmy szkoleniowe maj
ą
prawo korzysta
ć
z planu jako podstawy do
materiałów szkoleniowych pod warunkiem podania
ź
ródła praw autorskich oraz
własno
ś
ci planu. Powoływanie si
ę
na niniejszy plan w materiałach reklamowych i
promocyjnych dozwolone jest dopiero po oficjalnym rozpocz
ę
ciu procedury ubiegania
si
ę
o akredytacj
ę
w ISTQB lub w Radzie Krajowej (National Board) uznawanej przez
ISTQB.
2) Osoby oraz firmy i zrzeszenia maj
ą
prawo korzysta
ć
z planu jako podstawy do
artykułów, ksi
ąż
ek oraz innych materiałów pod warunkiem podania
ź
ródła praw
autorskich oraz własno
ś
ci planu.
3) Ka
ż
da uznawana przez ISTQB Rada Krajowa mo
ż
e wykona
ć
tłumaczenie
niniejszego planu oraz udziela
ć
zezwolenia na korzystanie z cało
ś
ci lub cz
ęś
ci
tłumaczenia innym stronom.
Certyfikowany tester
Plan poziomu podstawowego
International Sotware Testing Qualifications Board
Stowarzyszenie Jako
ś
ci Systemów Informatycznych
Wersja 1.0
© Stowarzyszenie Jako
ś
ci Systemów
Informatycznych
Strona 3 z 78
20 pa
ź
dziernika 2006
Historia zmian
Wersja
Data
Uwagi
0.1
15.07.2005
Wzorzec dokumentu.
0.1.1
01.08.2005
Bogdan Bereza-Jaroci
ń
ski, cz
ęś
ciowo rozdział 6.
0.1.2
16.08.2005
Anna Seredyn: fragmenty rozdz. 1 (kosmetyczne zmiany BB).
Bogdan Bereza-Jaroci
ń
ski: dalsze tłumaczenie rozdziału 6-ego.
Helena Klitenik: zał
ą
cznik A (kosmetyczne zmiany BB).
0.1.3
30.09.2005
Dodany rozdział 3. (Helena Klitenik), rozdział 4. (Helena
Klitenik) oraz Wst
ę
p (Helena Klitenik).
0.2
02.01.2006
Do przegl
ą
du (Bogdan Bereza-Jaroci
ń
ski)
0.2.1
04.01.2006
Uzupełnienia: zał
ą
czniki B, C i D od Heleny Klitenik
0.9
06.02.2006
Wersja dostarczona do SJSI
0.91
10.02.2006
Wersja do ostatecznego przegl
ą
du.
0.92
17.02.2006
Scalona wersja po przegl
ą
dzie, który nie okazał si
ę
ostateczny
0.93
28.07.2006
Poprawki do wersji ostatecznego przegl
ą
du
0.94
11.09.2006
Wersja alfa
0.95
18.09.2006
Wersja beta. Dodanie indeksu.
1.0
20.10.2006
Dostarczona zarz
ą
dowi SJSI
Certyfikowany tester
Plan poziomu podstawowego
International Sotware Testing Qualifications Board
Stowarzyszenie Jako
ś
ci Systemów Informatycznych
Wersja 1.0
© Stowarzyszenie Jako
ś
ci Systemów
Informatycznych
Strona 4 z 78
20 pa
ź
dziernika 2006
Spis tre
ś
ci
Historia zmian.......................................................................................................................................................... 3
Spis tre
ś
ci ................................................................................................................................................................ 4
Podzi
ę
kowania ........................................................................................................................................................ 7
Wst
ę
p do planu........................................................................................................................................................ 8
1.
Podstawy testowania (K2), 155 minut........................................................................................................... 10
1.1.
Czemu testowanie jest niezb
ę
dne (K2), 20 minut ................................................................................................. 11
1.1.1.
Otoczenie systemów informatycznych (K1)..................................................................................................... 11
1.1.2.
Przyczyny defektów oprogramowania (K2) ..................................................................................................... 11
1.1.3.
Rola testowania w procesach tworzenia, utrzymania i u
ż
ytkowania oprogramowania (K2).............................. 11
1.1.4.
Testowanie i jako
ść
(K2)................................................................................................................................. 11
1.1.5.
Kiedy zako
ń
czy
ć
testowanie (K2).................................................................................................................... 12
1.2.
Co to jest testowanie (K2), 30 minut..................................................................................................................... 13
1.3.
Ogólne zasady testowania (K2), 35 minut ............................................................................................................ 14
1.4.
Prosty proces testowy (K1), 35 minut ................................................................................................................... 15
1.4.1.
Planowanie i nadzór nad testowaniem (K1) .................................................................................................... 15
1.4.2.
Analiza i projektowanie testów (K1)................................................................................................................. 16
1.4.3.
Implementacja i wykonanie testów (K1) .......................................................................................................... 16
1.4.4.
Ocena kryteriów zako
ń
czenia oraz raportowanie testów (K1) ......................................................................... 16
1.4.5.
Czynno
ś
ci na zako
ń
czenie testowania (K1) .................................................................................................... 17
1.5.
Psychologia testowania (K2), 35 minut................................................................................................................. 18
2.
Testowanie w cyklu
ż
ycia oprogramowania (K2), 135 minut......................................................................... 20
2.1.
Modele wytwarzania oprogramowania (K2), 20 minut .......................................................................................... 21
2.1.1.
Model V (K2)................................................................................................................................................... 21
2.1.2.
Iteracyjne modele wytwarzania (K2)................................................................................................................ 21
2.1.3.
Testowanie w cyklu
ż
ycia (K2) ........................................................................................................................ 21
2.2.
Poziomy testów (K2), 60 minut............................................................................................................................. 23
2.2.1.
Testowanie modułowe (K2)............................................................................................................................. 23
2.2.2.
Testowanie integracyjne (K2).......................................................................................................................... 23
2.2.3.
Testowanie systemowe (K2) ........................................................................................................................... 24
2.2.4.
Testowanie akceptacyjne (K2) ........................................................................................................................ 25
2.3.
Typy i cele testów (K2), 40 minut ......................................................................................................................... 26
2.3.1.
Testowanie funkcji (testowanie funkcjonalne) (K2).......................................................................................... 26
2.3.2.
Testowanie wła
ś
ciwo
ś
ci (testowanie niefunkcjonalne) (K2)............................................................................. 26
2.3.3.
Testowanie struktury/architektury systemu (testowanie strukturalne) (K2)....................................................... 27
2.3.4.
Testowanie zwi
ą
zane ze zmianami (testowanie potwierdzaj
ą
ce i regresywne) (K2) ........................................ 27
2.4.
Testowanie w fazie utrzymania (K2), 15 minut ..................................................................................................... 28
3.
Statyczne techniki testowania (K2), 60 minut ............................................................................................... 29
3.1.
Przegl
ą
dy i proces testowy(K2), 15 minut............................................................................................................. 30
3.2.
Proces przegl
ą
du (K2), 25 minut .......................................................................................................................... 31
3.2.1.
Fazy formalnego przegl
ą
du (K1) ..................................................................................................................... 31
3.2.2.
Role i odpowiedzialno
ś
ci (K1) ......................................................................................................................... 31
3.2.3.
Rodzaje przegl
ą
dów (K2)................................................................................................................................ 32
Certyfikowany tester
Plan poziomu podstawowego
International Sotware Testing Qualifications Board
Stowarzyszenie Jako
ś
ci Systemów Informatycznych
Wersja 1.0
© Stowarzyszenie Jako
ś
ci Systemów
Informatycznych
Strona 5 z 78
20 pa
ź
dziernika 2006
3.2.4.
Czynniki powodzenia przegl
ą
dów (K2)............................................................................................................ 33
3.3.
Analiza statyczna przy pomocy narz
ę
dzi (K2), 20minut ........................................................................................ 34
4.
Techniki projektowania testów (K3), 255 minut............................................................................................. 35
4.1.
Identyfikowanie warunków testowych i projektowanie przypadków testowych (K3), 15 minut ............................... 37
4.2.
Kategorie technik projektowania testów (K2), 15 minut......................................................................................... 38
4.3.
Techniki na podstawie specyfikacji lub czarnoskrzynkowe (K3), 120 minut .......................................................... 39
4.3.1.
Podział na klasy równowa
ż
no
ś
ci (K3) ............................................................................................................. 39
4.3.2.
Analiza warto
ś
ci brzegowych (K3) .................................................................................................................. 39
4.3.3.
Testowanie w oparciu o tablic
ę
decyzyjn
ą
(K3) ............................................................................................... 39
4.3.4.
Testowanie przej
ść
pomi
ę
dzy stanami (K3) .................................................................................................... 40
4.3.5.
Testowanie w oparciu o przypadki u
ż
ycia (K2)................................................................................................ 40
4.4.
Techniki na podstawie struktury lub białoskrzynkowe (K3), 60 minut.................................................................... 41
4.4.1.
Testowanie instrukcji i pokrycie (K3) ............................................................................................................... 41
4.4.2.
Testowanie decyzyjne i pokrycie (K3) ............................................................................................................. 41
4.4.3.
Inne techniki na podstawie struktury (K1)........................................................................................................ 41
4.5.
Techniki oparte na do
ś
wiadczeniu (K2), 30 minut ................................................................................................ 42
4.6.
Wybór technik testowych (K2), 15 minut.............................................................................................................. 43
5.
Zarz
ą
dzanie testowaniem (K3), 180 minut.................................................................................................... 44
5.1.
Organizacja testowania (K2), 30 minut ................................................................................................................. 46
5.1.1.
Organizacja i niezale
ż
no
ść
testowania (K2) .................................................................................................... 46
5.1.2.
Zadania kierownika testów i testera (K1)......................................................................................................... 46
5.2.
Planowanie testowania (K2), 50 minut ................................................................................................................. 48
5.2.1.
Planowanie testowania (K2)............................................................................................................................ 48
5.2.2.
Czynno
ś
ci wykonywane podczas planowania testów (K2) .............................................................................. 48
5.2.3.
Kryteria wyj
ś
cia (K2) ....................................................................................................................................... 48
5.2.4.
Oszacowanie wysiłku testowego (K2) ............................................................................................................. 49
5.2.5.
Sposoby podej
ś
cia do testowania (strategie testowe) (K2).............................................................................. 49
5.3.
Monitorowanie przebiegu i nadzór testowania (K2), 20 minut ............................................................................... 51
5.3.1.
Monitorowanie post
ę
pu testów (K1) ................................................................................................................ 51
5.3.2.
Raportowanie testów (K2)............................................................................................................................... 51
5.3.3.
Nadzór nad testowaniem (K2)......................................................................................................................... 51
5.4.
Zarz
ą
dzanie konfiguracj
ą
(K2), 10 minut .............................................................................................................. 53
5.5.
Ryzyko a testowanie (K2), 30 minut ..................................................................................................................... 54
5.5.1.
Ryzyko projektowe (K1, K2)............................................................................................................................ 54
5.5.2.
Ryzyko zwi
ą
zane z produktem (K2) ................................................................................................................ 54
5.6.
Zarz
ą
dzanie incydentami (K3), 40 minut .............................................................................................................. 56
6.
Testowanie wspierane narz
ę
dziami (K2), 80 minut ...................................................................................... 58
6.1.
Rodzaje narz
ę
dzi testowych (K2), 45 minut.......................................................................................................... 59
6.1.1.
Klasyfikacja narz
ę
dzi testowych...................................................................................................................... 59
6.1.2.
Zarz
ą
dzanie testowaniem wspierane narz
ę
dziami (K1)................................................................................... 59
6.1.3.
Testowanie statyczne wspierane narz
ę
dziami (K1)......................................................................................... 61
6.1.4.
Tworzenie specyfikacji testów wspierane narz
ę
dziami .................................................................................... 61
6.1.5.
Wykonywanie testów wspierane narz
ę
dziami ................................................................................................. 62
6.1.6.
Testowanie wydajno
ś
ci i monitorowanie wspierane narz
ę
dziami (K1) ............................................................. 63
Certyfikowany tester
Plan poziomu podstawowego
International Sotware Testing Qualifications Board
Stowarzyszenie Jako
ś
ci Systemów Informatycznych
Wersja 1.0
© Stowarzyszenie Jako
ś
ci Systemów
Informatycznych
Strona 6 z 78
20 pa
ź
dziernika 2006
6.1.7.
Narz
ę
dzia wspieraj
ą
ce testowanie w okre
ś
lonych dziedzinach ....................................................................... 63
6.1.8.
Wykorzystanie innych narz
ę
dzi (K1) ............................................................................................................... 64
6.2.
Skuteczne zastosowanie narz
ę
dzi: mo
ż
liwe korzy
ś
ci i zagro
ż
enia (K2), 20 minut ................................................ 65
6.2.1.
Mo
ż
liwe korzy
ś
ci i zagro
ż
enia wynikaj
ą
ce ze stosowania narz
ę
dzi wspieraj
ą
cych testowanie (dla wszystkich
rodzajów narz
ę
dzi) (K2)................................................................................................................................................... 65
6.2.2.
Zagadnienia specjalne dla niektórych rodzajów narz
ę
dzi (K1)......................................................................... 65
6.3.
Wdro
ż
enie narz
ę
dzia w organizacji (K1), 15 minut ............................................................................................... 67
7.
Referencje .................................................................................................................................................... 69
Zał
ą
cznik A – Pochodzenie planu.......................................................................................................................... 70
Zał
ą
cznik B – Cel nauki i poziomy wiedzy ............................................................................................................. 72
Zał
ą
cznik C – Zasady dotycz
ą
ce Planu poziomu podstawowego ISTQB / SJSI ................................................... 73
Zał
ą
cznik D – Informacja dla dostawców szkole
ń
.................................................................................................. 75
Indeks.................................................................................................................................................................... 76
Certyfikowany tester
Plan poziomu podstawowego
International Sotware Testing Qualifications Board
Stowarzyszenie Jako
ś
ci Systemów Informatycznych
Wersja 1.0
© Stowarzyszenie Jako
ś
ci Systemów
Informatycznych
Strona 7 z 78
20 pa
ź
dziernika 2006
Podzi
ę
kowania
Angielska wersja tego dokumentu została napisana przez Grup
ę
Robocz
ą
ISTQB w składzie:
Thomas Müller (przewodnicz
ą
cy), Rex Black, Sigrid Eldh, Dorothy Graham, Klaus Olsen,
Maaret Pyhäjärvi, Geoff Thompson oraz Erik van Veendendal. Grupa Robocza wyra
ż
a
podzi
ę
kowania przedstawicielom Rad Krajowych za udział w przegl
ą
dach planu.
Szczególne podzi
ę
kowania skierowane s
ą
do (Austria) Anastasios Kyriakopoulos, (Dania)
Klaus Olsen, Christie Rosenbeck-Larsen, (Niemcy) Matthias Daigl, Uwe Hehn, Tilo Linz,
Horst Pohlmann, Ina Schieferdecker, Sabine Uhde, Stephanie Ulrich, (Indie) Vipul Kocher,
(Izrael) Shmuel Knishinsky, Ester Zabar, (Szwecja) Anders Claesson, Mattias Nordin, Ingvar
Nordström, Stefan Ohlsson, Kenneth Osbjer, Ingela Skytte, Klaus Zeuge, (Szwajcaria) Armin
Born, Sandra Harries, Silvio Moser, Reto Müller, Joerg Pietzsch, (Wielka Brytania) Aran
Ebbett, Isabel Evans, Julie Gardiner, Andrew Goslin, Brian Hambling, James Lyndsay, Helen
Moore, Peter Morgan, Trevor Newton, Angelina Samaroo, Shane Saunders, Mike Smith,
Richard Taylor, Neil Thompson, Pete Williams, (USA) Dale Perry.
Tłumaczenie na j
ę
zyk polski zostało wykonane przez Grup
ę
Robocz
ą
SJSI w składzie:
Bogdan Bereza-Jaroci
ń
ski, Wojciech Jaszcz, Helena Klitenik, Joanna Nowakowska, Jan
Sabak, Anna Seredyn, Lucjan Stapp, Piotr
Ś
l
ę
zak, Łukasz
ś
ebrowski.
Certyfikowany tester
Plan poziomu podstawowego
International Sotware Testing Qualifications Board
Stowarzyszenie Jako
ś
ci Systemów Informatycznych
Wersja 1.0
© Stowarzyszenie Jako
ś
ci Systemów
Informatycznych
Strona 8 z 78
20 pa
ź
dziernika 2006
Wst
ę
p do planu
Cel dokumentu
Plan ten stanowi podstaw
ę
do Mi
ę
dzynarodowej Kwalifikacji w Testowaniu Oprogramowania
na poziomie podstawowym. ISTQB (The International Software Testing Qualifications Board)
zapewnia narodowym grupom egzaminacyjnym akredytacj
ę
dostawców szkole
ń
oraz
posiadanie pyta
ń
egzaminacyjnych w ich lokalnym j
ę
zyku. Dostawcy szkole
ń
przygotowuj
ą
materiał kursu i okre
ś
l
ą
odpowiednie metody nauczania do akredytacji, a plan pomaga
kandydatom w przygotowaniu si
ę
do egzaminu.
Informacj
ę
o historii i pochodzeniu planu mo
ż
na znale
źć
w Zał
ą
czniku A.
Podstawowy Poziom Certyfikowanego Testera w Testowaniu
Oprogramowania
Kwalifikacja na Poziomie Podstawowym kierowana jest do ka
ż
dego zaanga
ż
owanego w
testowanie oprogramowania. Zalicza si
ę
tu takie osoby jak testerzy, analitycy testów,
in
ż
ynierowie testów, konsultanci testów, mened
ż
erowie testów, testerzy akceptacji
u
ż
ytkownika i programi
ś
ci. Kwalifikacja na Poziomie Podstawowym odpowiednia jest równie
ż
dla ka
ż
dego, kto potrzebuje podstawowej wiedzy w dziedzinie testowania oprogramowania.
Dotyczy to kierowników projektu, kierowników jako
ś
ci, kierowników oprogramowania,
analityków biznesowych, dyrektorów IT i konsultantów zarz
ą
du. Posiadacze Certyfikatu
Podstawowego b
ę
d
ą
mieli mo
ż
liwo
ść
przej
ś
cia na wy
ż
szy poziom kwalifikacji w testowaniu
oprogramowania.
Cele uczenia si
ę
/poziom wiedzy
Dla ka
ż
dej sekcji planu podane s
ą
nast
ę
puj
ą
ce poziomy poznawcze:
K1: zapami
ę
taj, poznaj, wymie
ń
;
K2: zrozum, wyja
ś
nij, podaj przyczyny, porównaj, sklasyfikuj, stre
ść
;
K3: zastosuj.
Dalsze szczegóły i przykłady celów uczenia si
ę
podano w Zał
ą
czniku B.
Wszystkie poj
ę
cia wymienione w „Terminologii”, zaraz poni
ż
ej nagłówków rozdziałów,
powinny by
ć
zapami
ę
tane, nawet, je
ś
li nie wspomniano o tym wyra
ź
nie, w celach uczenia si
ę
.
Egzamin
Egzamin na Certyfikat Podstawowy b
ę
dzie oparty na niniejszym konspekcie. Odpowiedzi na
pytania egzaminacyjne mog
ą
wymaga
ć
skorzystania z materiału bazuj
ą
cego na wi
ę
cej ni
ż
jednym rozdziale niniejszego planu. W egzaminie uwzgl
ę
dnione s
ą
wszystkie rozdziały planu.
Format egzaminu to test wielokrotnego wyboru.
Egzaminy mo
ż
na zdawa
ć
podczas akredytowanego kursu szkoleniowego lub przyst
ę
powa
ć
do nich niezale
ż
nie (np. w centrum egzaminacyjnym).
Akredytacja
Dostawcy szkole
ń
, których materiał kursowy odpowiada planowi, mog
ą
by
ć
akredytowani
przez narodow
ą
organizacj
ę
uznawan
ą
przez ISTQB. Wytyczne odno
ś
nie akredytacji
powinno si
ę
uzyska
ć
od organizacji lub ciała, które dokonuje akredytacji. Kurs akredytowany
uznawany jest jako odpowiadaj
ą
cy temu planowi. Zezwala si
ę
, aby zdawa
ć
egzamin ISTQB
jako cz
ęść
kursu.
Certyfikowany tester
Plan poziomu podstawowego
International Sotware Testing Qualifications Board
Stowarzyszenie Jako
ś
ci Systemów Informatycznych
Wersja 1.0
© Stowarzyszenie Jako
ś
ci Systemów
Informatycznych
Strona 9 z 78
20 pa
ź
dziernika 2006
Dalsze wskazówki odno
ś
nie dostawców szkole
ń
podano w Zał
ą
czniku D.
Poziom uszczegółowienia
Poziom uszczegółowienia w konspekcie pozwala na spójne mi
ę
dzynarodowo nauczanie oraz
egzamin. Aby osi
ą
gn
ąć
ten cel plan zawiera:
•
Ogólne cele opisuj
ą
ce intencj
ę
poziomu podstawowego,
•
List
ę
informacji do nauczenia, wliczaj
ą
c w to opis i odniesienia do dodatkowych
ź
ródeł, je
ś
li s
ą
wymagane,
•
Cele uczenia si
ę
dla ka
ż
dej dziedziny wiedzy, opisuj
ą
ce poznawczy rezultat uczenia
si
ę
i zestaw poj
ę
ciowy do osi
ą
gni
ę
cia,
•
List
ę
poj
ęć
, które studenci musz
ą
zrozumie
ć
i umie
ć
wymieni
ć
,
•
Opis kluczowych koncepcji nauczania, wliczaj
ą
c w to
ź
ródła takie jak przyj
ę
ta
literatura lub standardy.
Tre
ść
planu nie jest opisem całego obszaru wiedzy z testowania oprogramowania;
odzwierciedla poziom szczegółowo
ś
ci dla kursów szkoleniowych z poziomu podstawowego.
Organizacja planu
Plan zawiera sze
ść
głównych rozdziałów. Nagłówek górnego poziomu pokazuje poziomy
wiedzy zawarte wewn
ą
trz rozdziału i okre
ś
la jego czas trwania. Na przykład:
2.Testowanie w cyklu
ż
ycia oprogramowania (K2), 135 minut
pokazuje,
ż
e rozdział 2 ma poziom wiedzy K1 (zakłada si
ę
zawieranie ni
ż
szych, gdy
pokazany jest wy
ż
szy poziom) i K2 (ale nie K3) i zaplanowano 135 minut na nauczenie
materiału w nim zawartego.
Wewn
ą
trz ka
ż
dego rozdziału jest wiele sekcji. Ka
ż
da sekcja ma równie
ż
cele uczenia si
ę
i
ilo
ść
wymaganego czasu. Podsekcje, dla których nie podano czasu, wliczaj
ą
si
ę
do czasu
dla sekcji.
Certyfikowany tester
Plan poziomu podstawowego
International Sotware Testing Qualifications Board
Stowarzyszenie Jako
ś
ci Systemów Informatycznych
Wersja 1.0
© Stowarzyszenie Jako
ś
ci Systemów
Informatycznych
Strona 10 z 78
20 pa
ź
dziernika 2006
1. Podstawy testowania (K2), 155 minut
Celem rozdziału „Podstawy testowania” jest nauczenie, w
poszczególnych paragrafach:
1.1 Dlaczego testowanie jest niezb
ę
dne (K2)
•
Przedstawiania, z przykładami, w jaki sposób bł
ą
d w oprogramowaniu mo
ż
e
wyrz
ą
dzi
ć
szkod
ę
osobie,
ś
rodowisku lub firmie. (K2)
•
Ró
ż
nic pomi
ę
dzy przyczyn
ą
bł
ę
du a jej efektem. (K2)
•
Uzasadnienia, opieraj
ą
c si
ę
na przykładach, dlaczego testowanie jest niezb
ę
dne. (K2)
•
Pokazania, dlaczego testowanie jest cz
ęś
ci
ą
zapewnienia jako
ś
ci i podania
przykładów, w jaki sposób testowanie pomaga osi
ą
gn
ąć
wy
ż
sz
ą
jako
ść
. (K2)
•
Definicji: pomyłka, defekt, awaria oraz synonimy bł
ą
d i pluskwa. (K1)
1.2 Co to jest testowanie (K2)
•
Podstawowych zada
ń
procesu testowania.(K1)
•
Opisu celów testowania w procesach tworzenia, utrzymania i u
ż
ytkowania
oprogramowania, jako metody znajdowania bł
ę
dów, dostarczenia informacji o jako
ś
ci
oraz zapobieganiu awariom oprogramowania. (K2)
1.3 Podstawowe zasady testowania (K2)
•
Podstawowych zasad testowania. (K2)
1.4 Podstawowy proces testowy (K1)
•
Podstawowych etapów testów od planowania do zako
ń
czenia testów i głównych
zada
ń
ka
ż
dego etapu testów. (K1)
1.5 Psychologia testowania (K2)
•
Wpływu czynników psychologicznych na sukces testów poprzez (K1):
o
Jasno zdefiniowane cele;
o
Równowag
ę
mi
ę
dzy testami programistów a testami niezale
ż
nymi;
o
Znaczenia asertywnej komunikacji i informacji o bł
ę
dach.
•
Ró
ż
nicy w podej
ś
ciu testera i programisty. (K2)
Certyfikowany tester
Plan poziomu podstawowego
International Sotware Testing Qualifications Board
Stowarzyszenie Jako
ś
ci Systemów Informatycznych
Wersja 1.0
© Stowarzyszenie Jako
ś
ci Systemów
Informatycznych
Strona 11 z 78
20 pa
ź
dziernika 2006
1.1. Czemu testowanie jest niezb
ę
dne (K2), 20 minut
Terminologia
Pluskwa, defekt, pomyłka, awaria, usterka, jako
ść
, ryzyko, oprogramowanie, testowanie.
1.1.1. Otoczenie systemów informatycznych (K1)
Systemy informatyczne odgrywaj
ą
coraz wi
ę
ksz
ą
rol
ę
w
ż
yciu, pocz
ą
wszy od rozwi
ą
za
ń
dla
biznesu (np. sektor bankowy) a
ż
do urz
ą
dze
ń
dla konsumenta (np. samochody). Wi
ę
kszo
ść
ludzi zetkn
ę
ła si
ę
z oprogramowaniem, które nie działało tak jak powinno. Oprogramowanie
takie mo
ż
e wywoła
ć
wiele problemów – strat
ę
pieni
ę
dzy, czasu i reputacji firmy, mo
ż
e nawet
spowodowa
ć
obra
ż
enia lub
ś
mier
ć
.
1.1.2. Przyczyny defektów oprogramowania (K2)
Człowiek popełnia bł
ą
d (pomyłk
ę
), której skutkiem jest defekt (usterka, pluskwa) w kodzie,
oprogramowaniu, systemie lub dokumencie. Je
ś
li kod z defektem zostanie wykonany,
system nie zrobi tego, co powinien (lub zrobi co
ś
, czego nie powinien robi
ć
), wywołuj
ą
c
awari
ę
. Defekty w oprogramowaniu, systemach lub dokumentach mog
ą
, lecz nie musz
ą
skutkowa
ć
awariami.
Defekty istniej
ą
, poniewa
ż
ludzie s
ą
omylni, działaj
ą
pod presj
ą
czasu, w sytuacji
skomplikowanego kodu, skomplikowanej infrastruktury, zmieniaj
ą
cych si
ę
technologii i wielu
interakcji wewn
ą
trz systemu.
Awarie mog
ą
by
ć
równie
ż
wywołane przez czynniki
ś
rodowiska: promieniowanie, magnetyzm,
pole elektryczne, ska
ż
enie. Wszystko to mo
ż
e powodowa
ć
awarie w oprogramowaniu
wbudowanym lub wpływa
ć
na działanie oprogramowania przez zmian
ę
warunków działania
sprz
ę
tu.
1.1.3. Rola testowania w procesach tworzenia, utrzymania i u
ż
ytkowania
oprogramowania (K2)
Rygorystyczne testowanie systemów i dokumentacji mo
ż
e zredukowa
ć
ryzyko wyst
ą
pienia
awarii w
ś
rodowisku produkcyjnym i przyczyni
ć
si
ę
do osi
ą
gni
ę
cia wysokiej jako
ś
ci systemu.
Konieczne jest, aby znalezione defekty były poprawione przed dopuszczeniem systemu do
działania w
ś
rodowisku produkcyjnym.
Testowanie oprogramowania mo
ż
e by
ć
równie
ż
wymagane przez zapisy kontraktowe,
wymogi prawne lub standardy przemysłowe.
1.1.4. Testowanie i jako
ść
(K2)
Przy pomocy testowania mo
ż
na zmierzy
ć
jako
ść
oprogramowania rozumian
ą
jako liczba
znalezionych bł
ę
dów, zarówno w stosunku do wymaga
ń
funkcjonalnych jak i
niefunkcjonalnych oraz cech systemu (niezawodno
ść
, u
ż
yteczno
ść
, efektywno
ść
i
utrzymywalno
ść
). Wi
ę
cej informacji o testach niefunkcjonalnych znajduje si
ę
w rozdziale 2.
Wi
ę
cej informacji o cechach oprogramowania mo
ż
na znale
źć
w normie Software
Engineering – Software Product Quality (ISO 9126).
Testowanie mo
ż
e podnosi
ć
zaufanie co do jako
ś
ci oprogramowania, je
ż
eli znaleziono mało
lub nie znaleziono bł
ę
dów. Prawidłowo zaprojektowany test, który przechodzi bez
znalezienia bł
ę
du redukuje poziom ryzyka w systemie. Je
ś
li testowanie znajduje bł
ę
dy i bł
ę
dy
Certyfikowany tester
Plan poziomu podstawowego
International Sotware Testing Qualifications Board
Stowarzyszenie Jako
ś
ci Systemów Informatycznych
Wersja 1.0
© Stowarzyszenie Jako
ś
ci Systemów
Informatycznych
Strona 12 z 78
20 pa
ź
dziernika 2006
te zostaj
ą
naprawione, jako
ść
systemu informatycznego wzrasta. Samo testowanie nie
podnosi jako
ś
ci oprogramowania i dokumentacji.
Z poprzednich projektów powinny by
ć
wyci
ą
gane wnioski. Proces wytwórczy mo
ż
na
doskonali
ć
poprzez zrozumienie przyczyn bł
ę
dów znalezionych w poprzednich projektach. W
konsekwencji powinno zapobiec ponownemu pojawieniu si
ę
podobnych defektów a tym
samym poprawi
ć
jako
ść
przyszłych systemów.
Testowanie powinno by
ć
zintegrowane z innymi metodami zapewniania jako
ś
ci (np. ze
standardami kodowania, szkoleniami i analiz
ą
bł
ę
dów).
1.1.5. Kiedy zako
ń
czy
ć
testowanie (K2)
Decyzja o tym, ile trzeba testowa
ć
, powinna bra
ć
pod uwag
ę
poziom ryzyka, wł
ą
czaj
ą
c w to
ryzyko techniczne, biznesowe i projektowe oraz ramy projektu takie jak czas i bud
ż
et. Temat
ryzyka jest omówiony w rozdziale 5.
Testowanie powinno dostarczy
ć
interesariuszom informacji wystarczaj
ą
cej do podj
ę
cia
decyzji o dopuszczeniu testowanego oprogramowania lub systemu do nast
ę
pnej fazy
produkcji, przekazaniu go klientowi itp.
Certyfikowany tester
Plan poziomu podstawowego
International Sotware Testing Qualifications Board
Stowarzyszenie Jako
ś
ci Systemów Informatycznych
Wersja 1.0
© Stowarzyszenie Jako
ś
ci Systemów
Informatycznych
Strona 13 z 78
20 pa
ź
dziernika 2006
1.2. Co to jest testowanie (K2), 30 minut
Terminologia
Kod, debagowanie, tworzenie (oprogramowania), wymaganie, przegl
ą
d, podstawa testów,
przypadek testowy, testowanie, cele testu.
Wprowadzenie
Zazwyczaj testowanie jest odbierane jako zaj
ę
cie polegaj
ą
ce na wykonywaniu testów, czyli
uruchamianiu oprogramowania. Jest to jedynie cz
ęść
, lecz nie cało
ść
, testowania.
Czynno
ś
ci zwi
ą
zane z testowaniem, takie jak planowanie, nadzorowanie, ustalanie
warunków testowych, projektowanie zada
ń
testowych, porównywanie wyników, ocena
kryteriów zako
ń
czenia, raporty dotycz
ą
ce procesu testowego i testowanej aplikacji,
zako
ń
czenie i zamykanie testów (po zako
ń
czeniu fazy testów), wyst
ę
puj
ą
zarówno przed jak
i po wykonaniu testów. Testowanie obejmuje równie
ż
przegl
ą
dy dokumentów (w tym kodu)
oraz analiz
ę
statyczn
ą
.
Zarówno testowanie statyczne jak i dynamiczne mo
ż
e by
ć
u
ż
yte do osi
ą
gni
ę
cia podobnych
celów. Oba podej
ś
cia dostarcz
ą
informacji koniecznych do poprawy testowanego
oprogramowania oraz procesu tworzenia i testowania oprogramowania.
Mo
ż
na wyró
ż
ni
ć
nast
ę
puj
ą
ce cele testów:
Znajdowanie defektów
Budowanie zaufania odno
ś
nie jako
ś
ci oraz dostarczanie informacji o jako
ś
ci
Zapobieganie awariom
Proces projektowania zada
ń
testowych wykonywany wcze
ś
nie w cyklu wytwórczym
(weryfikacja podstawy testów za pomoc
ą
projektowania testów) mo
ż
e zapobiec
wprowadzaniu defektów do kodu. Przegl
ą
dy dokumentów (np. dokumentu wymaga
ń
)
równie
ż
pomagaj
ą
zapobiega
ć
pojawianiu si
ę
defektów.
Ró
ż
ne punkty widzenia podczas testowania maj
ą
na uwadze ró
ż
ne cele. Przykładowo, w
testach prowadzonych przez programistów (np. testowanie modułowe, integracyjne i
systemowe) głównym celem mo
ż
e by
ć
spowodowanie tylu awarii ile jest to mo
ż
liwe, aby
defekty w oprogramowaniu zostały zidentyfikowane i poprawione. W testach akceptacyjnych
głównym celem mo
ż
e by
ć
potwierdzenie działania systemu zgodnie z oczekiwaniami, aby
upewni
ć
si
ę
, ze system spełnia wymagania u
ż
ytkowników. W niektórych przypadkach
głównym celem testu mo
ż
e by
ć
ocena jako
ś
ci oprogramowania (bez zamiaru naprawienia
defektów), aby dostarczy
ć
interesariuszom informacji na temat ryzyka zwi
ą
zanego z
wdro
ż
eniem systemu w okre
ś
lonym czasie. Testy piel
ę
gnacyjne cz
ę
sto zawieraj
ą
testy
sprawdzaj
ą
ce, czy nie wprowadzono
ż
adnych nowych bł
ę
dów podczas implementacji zmian.
Podczas testów produkcyjnych głównym celem mo
ż
e by
ć
ocena wybranych charakterystyk
takich jak niezawodno
ść
i dost
ę
pno
ść
.
Debagowanie i testowanie ró
ż
ni
ą
si
ę
od siebie. Testowanie mo
ż
e ujawni
ć
awarie
spowodowane defektami. Debagowanie jest czynno
ś
ci
ą
programistyczn
ą
wykonywan
ą
w
celu zidentyfikowania przyczyny defektu, poprawienia kodu i sprawdzenia czy defekt został
poprawnie naprawiony. Pó
ź
niejsze testowanie potwierdzaj
ą
ce wykonywane przez testera
zapewnia,
ż
e poprawka rzeczywi
ś
cie usun
ę
ła awari
ę
. Odpowiedzialno
ść
za ka
ż
d
ą
z tych
czynno
ś
ci jest inna: testerzy testuj
ą
, a programi
ś
ci debaguj
ą
.
Proces testowania i jego czynno
ś
ci s
ą
omówione w sekcji 1.4.
Certyfikowany tester
Plan poziomu podstawowego
International Sotware Testing Qualifications Board
Stowarzyszenie Jako
ś
ci Systemów Informatycznych
Wersja 1.0
© Stowarzyszenie Jako
ś
ci Systemów
Informatycznych
Strona 14 z 78
20 pa
ź
dziernika 2006
1.3. Ogólne zasady testowania (K2), 35 minut
Terminologia
Testowanie gruntowne
Zasady
Przez ponad 40 lat powstała pewna ilo
ść
zasad z zakresu testowania, które zawieraj
ą
ogólne
wytyczne cechuj
ą
ce ka
ż
de testowanie.
Zasada 1 – Testowanie ujawnia bł
ę
dy
Testowanie mo
ż
e pokaza
ć
,
ż
e istniej
ą
defekty, lecz testuj
ą
c nie jeste
ś
my w stanie dowie
ść
,
ż
e ich nie ma. Testowanie zmniejsza prawdopodobie
ń
stwo,
ż
e w oprogramowaniu
pozostan
ą
niezidentyfikowane defekty, ale nawet w przypadku, gdy
ż
adne defekty nie
zostan
ą
znalezione, nie jest to dowodem na poprawno
ść
oprogramowania.
Zasada 2 – Testowanie gruntowne jest niemo
ż
liwe
Przetestowanie wszystkiego (wszystkich kombinacji wej
ść
i warunków wst
ę
pnych) jest
mo
ż
liwe wył
ą
cznie w odniesieniu do bardzo trywialnych przypadków. Okre
ś
laj
ą
c zakres
testów, zamiast skupia
ć
si
ę
na testowaniu gruntownym, wykorzystujemy informacje o ryzyku
i priorytetach.
Zasada 3 – Wczesne testowanie
Czynno
ś
ci testowe powinny rozpoczyna
ć
si
ę
tak wcze
ś
nie, jak to mo
ż
liwe tylko w przypadku
danego oprogramowania lub cyklu wytwarzania oprogramowania. Powinny by
ć
one równie
ż
nastawione na osi
ą
ganie zdefiniowanych celów.
Zasada 4 – Kumulowanie si
ę
bł
ę
dów
Wi
ę
kszo
ść
defektów znalezionych podczas testowania przed wypuszczeniem
oprogramowania lub powoduj
ą
cych awarie produkcyjne znajduje si
ę
w małej liczbie modułów.
Zasada 5 – Paradoks pestycydów
Je
ż
eli te same testy s
ą
ci
ą
gle powtarzane, ten sam zestaw przypadków testowych nie
znajduje ju
ż
ż
adnych nowych bł
ę
dów.
ś
eby przezwyci
ęż
y
ć
paradoks pestycydów, przypadki
testowe musz
ą
by
ć
regularnie przegl
ą
dane i korygowane. W celu sprawdzenia innych cz
ęś
ci
oprogramowania lub systemu, aby potencjalnie znale
źć
wi
ę
cej bł
ę
dów, powinny by
ć
dopisywane nowe, inne testy.
Zasada 6 – Testowanie jest zale
ż
ne od kontekstu
Testowanie jest wykonywane w ró
ż
ny sposób w ró
ż
nych sytuacjach. Na przykład, systemy
krytyczne ze wzgl
ę
du na bezpiecze
ń
stwo s
ą
testowane inaczej ni
ż
systemy typu e-
commerce.
Zasada 7 – Mylne przekonanie o bezbł
ę
dno
ś
ci
Znalezienie i usuni
ę
cie bł
ę
dów nie pomaga, je
ż
eli system jest nie nadaj
ą
cy si
ę
do u
ż
ytku i
nie spełnia potrzeb oraz oczekiwa
ń
u
ż
ytkownika.
Certyfikowany tester
Plan poziomu podstawowego
International Sotware Testing Qualifications Board
Stowarzyszenie Jako
ś
ci Systemów Informatycznych
Wersja 1.0
© Stowarzyszenie Jako
ś
ci Systemów
Informatycznych
Strona 15 z 78
20 pa
ź
dziernika 2006
1.4. Prosty proces testowy (K1), 35 minut
Terminologia
Testowanie potwierdzaj
ą
ce, warunki wyj
ś
cia, incydent, testowanie regresywne, podstawa
testów, warunek testowy, pokrycie testowe, dane testowe, wykonanie testu, log testu, plan
testów, strategia testowania, raport ko
ń
cowy z testowania, testalia.
Wprowadzenie
Najbardziej widoczn
ą
cz
ęś
ci
ą
testowania jest wykonanie testów. Jednak,
ż
eby testy były
efektywne i skuteczne, plany testów powinny uwzgl
ę
dnia
ć
równie
ż
czas sp
ę
dzony na
planowaniu testów, projektowaniu przypadków testowych, przygotowaniu do wykonania
testów oraz ocenie statusu wykonania testów.
Podstawowy proces testowy składa si
ę
z nast
ę
puj
ą
cych głównych czynno
ś
ci:
•
Planowanie i nadzór;
•
Analiza i projektowanie;
•
Implementacja i wykonanie;
•
Ocena stopnia spełnienia warunków zako
ń
czenia i raportowanie;
•
Czynno
ś
ci zamykaj
ą
ce test.
Pomimo i
ż
czynno
ś
ci te s
ą
logicznie sekwencyjne, w procesie mog
ą
si
ę
zaz
ę
bia
ć
lub
wyst
ę
powa
ć
jednocze
ś
nie.
1.4.1. Planowanie i nadzór nad testowaniem (K1)
Planowanie testów weryfikuje misj
ę
testowania, definiuje cele testowania oraz sposób ich
osi
ą
gni
ę
cia.
Nadzór nad testami to powtarzaj
ą
ca si
ę
czynno
ść
porównywania rzeczywistego post
ę
pu
prac z planem i raportowanie wraz z informacj
ą
o odchyleniach od zało
ż
e
ń
. Nadzór nad
testami poci
ą
ga za sob
ą
czynno
ś
ci konieczne do wypełnienia misji i osi
ą
gni
ę
cia celów
projektu. Chc
ą
c nadzorowa
ć
testowanie, musimy je monitorowa
ć
w sposób ci
ą
gły. Podczas
planowania testów bierze si
ę
pod uwag
ę
informacje zwrotne z monitorowania i nadzoru.
Planowanie testów zawiera nast
ę
puj
ą
ce główne zadania:
•
Ocena zakresu i ryzyka oraz identyfikacja celów testowania.
•
Ocena metodyki testowania (techniki, testowane elementy, pokrycie, identyfikowanie i
integracja zespołów zaanga
ż
owanych w testowanie, testalia).
•
Ocena potrzebnych zasobów (np. ludzie,
ś
rodowisko testowe, komputery).
•
Wdro
ż
enie polityki testów i/lub strategii testowania.
•
Harmonogramowanie analizy testów i zada
ń
projektowych.
•
Harmonogramowanie implementacji, wykonania i oceny testów.
•
Okre
ś
lenie kryteriów zako
ń
czenia.
Nadzór nad testami ma nast
ę
puj
ą
ce główne zadania:
•
Mierzenie i analiza rezultatów;
•
Monitorowanie i dokumentowanie post
ę
pu prac, pokrycia testowego i kryteriów
zako
ń
czenia;
•
Rozpocz
ę
cie prac naprawczych;
Certyfikowany tester
Plan poziomu podstawowego
International Sotware Testing Qualifications Board
Stowarzyszenie Jako
ś
ci Systemów Informatycznych
Wersja 1.0
© Stowarzyszenie Jako
ś
ci Systemów
Informatycznych
Strona 16 z 78
20 pa
ź
dziernika 2006
•
Podejmowanie decyzji.
1.4.2. Analiza i projektowanie testów (K1)
Analiza i projektowanie testów to czynno
ś
ci, w ramach których ogólne cele testowania
zostaj
ą
przekształcone w namacalne warunki testowe i projekty testów.
Analiza i projektowanie testów zawiera nast
ę
puj
ą
ce główne zadania:
•
Przegl
ą
danie podstawy testów (takiej jak wymagania, architektura, projekt, interfejsy).
•
Identyfikacja warunków testowych lub wymaga
ń
testowych oraz potrzebnych danych
testowych na podstawie analizy przedmiotów testu, specyfikacji, zachowania i
struktury.
•
Projektowanie testów.
•
Ocena testowalno
ś
ci wymaga
ń
i systemu.
•
Projektowanie
ś
rodowiska testowego i identyfikacja całej potrzebnej infrastruktury
oraz narz
ę
dzi.
1.4.3. Implementacja i wykonanie testów (K1)
Implementacja i wykonanie testów to czynno
ś
ci, w ramach których warunki testowe s
ą
przekształcane w przypadki testowe i testalia, oraz tworzone jest
ś
rodowisko testowe.
Implementacja i wykonanie testów składaj
ą
si
ę
z nast
ę
puj
ą
cych czynno
ś
ci:
•
Wytwarzanie i okre
ś
lanie priorytetów przypadków testowych, tworzenie danych
testowych, pisanie procedur testowych oraz – opcjonalnie - przygotowywanie jarzma
testowego i pisanie automatycznych skryptów testowych.
•
Tworzenie scenariuszy testowych na podstawie przypadków testowych celem
efektywnego wykonania testu.
•
Weryfikacja poprawno
ś
ci utworzonego
ś
rodowiska testowego.
•
Wykonanie przypadków testowych r
ę
cznie lub przy pomocy narz
ę
dzi, w
zaplanowanej kolejno
ś
ci.
•
Logowanie wyniku wykonania testu i rejestrowanie jednostek i wersji testowanego
oprogramowania, narz
ę
dzi testowych oraz testaliów.
•
Porównywanie wyników rzeczywistych z oczekiwanymi.
•
Raportowanie rozbie
ż
no
ś
ci jako zdarze
ń
i analizowanie ich celem znalezienia
przyczyny wyst
ą
pienia (np. bł
ą
d w kodzie, w specyficznych danych testowych, w
dokumencie testowym, lub pomyłka w sposobie wykonania testu).
•
Powtarzanie czynno
ś
ci testowych jako rezultat akcji podj
ę
tych po stwierdzeniu
rozbie
ż
no
ś
ci. Na przykład: ponowne wykonanie testu, który poprzednio wykrył awari
ę
celem potwierdzenia usuni
ę
cia usterki (testowanie potwierdzaj
ą
ce); wykonanie
poprawionego testu i/lub wykonanie testów celem upewnienia si
ę
,
ż
e nowe defekty
nie zostały wprowadzone do niezmienionych obszarów oprogramowania lub,
ż
e
usuwanie usterek nie powoduje innych awarii (testowanie regresywne).
1.4.4. Ocena kryteriów zako
ń
czenia oraz raportowanie testów (K1)
Ocena stopnia spełnienia warunków zako
ń
czenia i raportowanie to czynno
ś
ci, w ramach
których wykonanie testu jest oceniane pod wzgl
ę
dem zdefiniowanych celów. Tego typu
czynno
ś
ci powinny by
ć
wykonywane dla ka
ż
dego poziomu testów.
Ocena stopnia spełnienia warunków zako
ń
czenia i raportowanie składa si
ę
z nast
ę
puj
ą
cych
głównych czynno
ś
ci:
•
Sprawdzenie dziennika testów w odniesieniu do warunków zako
ń
czenia okre
ś
lonych
podczas planowania testów.
Certyfikowany tester
Plan poziomu podstawowego
International Sotware Testing Qualifications Board
Stowarzyszenie Jako
ś
ci Systemów Informatycznych
Wersja 1.0
© Stowarzyszenie Jako
ś
ci Systemów
Informatycznych
Strona 17 z 78
20 pa
ź
dziernika 2006
•
Okre
ś
lenie, czy potrzebne jest wi
ę
cej testów lub czy nale
ż
y zmieni
ć
warunki
zako
ń
czenia.
•
Napisanie raportu ko
ń
cowego z testowania dla interesariuszy.
1.4.5. Czynno
ś
ci na zako
ń
czenie testowania (K1)
W ramach czynno
ś
ci zamykaj
ą
cych testowanie zbierane s
ą
dane z zako
ń
czonych czynno
ś
ci
testowych celem gromadzenia do
ś
wiadczenia, testaliów, faktów i liczb. Na przykład, kiedy
oprogramowanie zostaje przekazane klientowi, projekt testowy jest zako
ń
czony (lub
anulowany), krok milowy zostaje osi
ą
gni
ę
ty lub zamkni
ę
ta zostaje nowa wersja
oprogramowania po piel
ę
gnacji.
Do czynno
ś
ci zamykaj
ą
cych test zaliczamy:
•
Sprawdzenie, które zaplanowane dostawy zostały dostarczone
•
Zamkni
ę
cie raportów incydentów lub zgłoszenie zmian do tych, które pozostały
otwarte
•
Dokumentowanie akceptacji systemu.
•
Zako
ń
czenie i archiwizacja testaliów,
ś
rodowiska testowego i infrastruktury testowej
celem ponownego wykorzystania.
•
Przekazanie testaliów do zespołu serwisowego.
•
Analiza wniosków na potrzeby przyszłych projektów, oraz poprawy zdolno
ś
ci /
dojrzało
ś
ci testów.
Certyfikowany tester
Plan poziomu podstawowego
International Sotware Testing Qualifications Board
Stowarzyszenie Jako
ś
ci Systemów Informatycznych
Wersja 1.0
© Stowarzyszenie Jako
ś
ci Systemów
Informatycznych
Strona 18 z 78
20 pa
ź
dziernika 2006
1.5. Psychologia testowania (K2), 35 minut
Terminologia
Testowanie niezale
ż
ne
Wprowadzenie
Nastawienie podczas testowania i przegl
ą
dania jest inne ni
ż
podczas analizowania i
wytwarzania. Maj
ą
c odpowiednie nastawienie programi
ś
ci s
ą
w stanie testowa
ć
własny kod.
Rozdzielenie odpowiedzialno
ś
ci mi
ę
dzy twórcami kodu a testerami wykonywane jest zwykle,
w celu zwi
ę
kszenia nacisku na testy i dostarczanie dodatkowych korzy
ś
ci, takich jak
niezale
ż
ne spojrzenie wyszkolonego i profesjonalnego zespołu testowego. Testowanie
niezale
ż
ne mo
ż
e mie
ć
miejsce na ka
ż
dym poziomie testowania.
Pewien stopie
ń
niezale
ż
no
ś
ci (dzi
ę
ki któremu unika si
ę
autorskiego spojrzenia na testowany
produkt) pozwala zwykle na wi
ę
ksz
ą
skuteczno
ść
w znajdowaniu defektów i awarii.
Niezale
ż
no
ść
nie zast
ę
puje jednak znajomo
ś
ci programu; programi
ś
ci mog
ą
znale
źć
wiele
defektów we własnym kodzie. Zdefiniowano kilka poziomów niezale
ż
no
ś
ci:
•
Testy projektowane przez osob
ę
(osoby), które pisały testowany program (niski
poziom niezale
ż
no
ś
ci).
•
Testy projektowane przez inn
ą
osob
ę
(osoby) (np. z zespołu wytwórczego).
•
Testy projektowane przez osob
ę
(osoby) z innej grupy organizacyjnej (np. niezale
ż
ny
zespół testowy).
•
Testy projektowane przez osob
ę
(osoby) z innej organizacji lub z innego
przedsi
ę
biorstwa (np. outsourcing lub certyfikacja wykonywana przez jednostk
ę
zewn
ę
trzn
ą
).
Ludzie oraz projekty kieruj
ą
si
ę
okre
ś
lonymi celami. Ludzie maj
ą
skłonno
ść
do
dopasowywania planów do celów okre
ś
lonych przez kierownictwo lub innych interesariuszy,
na przykład, do znajdowania defektów, b
ą
d
ź
potwierdzania,
ż
e oprogramowanie działa. St
ą
d
wa
ż
ne jest dokładne i jasne okre
ś
lenie celów testowania.
Identyfikacja awarii podczas testowania mo
ż
e by
ć
postrzegana jako krytyka skierowana pod
adresem produktu lub jego autora. Powoduje to,
ż
e testowanie jest cz
ę
sto postrzegane jako
czynno
ść
destrukcyjna, nawet, je
ż
eli jest ona bardzo konstruktywna w
ś
wietle zarz
ą
dzania
ryzykiem projektu. Szukanie awarii w systemie wymaga ciekawo
ś
ci, profesjonalnego
pesymizmu, krytycznego spojrzenia, przywi
ą
zywania wagi do szczegółów, dobrej
komunikacji z programistami i do
ś
wiadczenia, na którym mo
ż
na oprze
ć
zgadywanie bł
ę
dów.
Je
ż
eli bł
ę
dy, defekty lub awarie s
ą
komunikowane w konstruktywny sposób, mo
ż
na unikn
ąć
spi
ęć
pomi
ę
dzy testerami, analitykami, projektantami i programistami. Odnosi si
ę
to zarówno
do przegl
ą
dania, jak równie
ż
do testowania.
Tester i kierownik testów potrzebuj
ą
dobrych zdolno
ś
ci interpersonalnych, aby móc
informowa
ć
o faktycznym stanie defektów, post
ę
pu prac oraz o ryzyku w konstruktywny
sposób. Dla autorów oprogramowania lub dokumentu, informacja o bł
ę
dzie mo
ż
e okaza
ć
si
ę
pomocna w doskonaleniu umiej
ę
tno
ś
ci. Znalezione podczas testowania i usuni
ę
te defekty
pozwol
ą
zaoszcz
ę
dzi
ć
czas i
ś
rodki w przyszło
ś
ci, i zmniejsz
ą
ryzyko projektu.
Problemy komunikacyjne mog
ą
wyst
ą
pi
ć
zwłaszcza wtedy, gdy testerzy s
ą
postrzegani jako
osoby przekazuj
ą
ce informacje wył
ą
cznie o awariach. Istnieje kilka sposobów by poprawi
ć
komunikacj
ę
i relacje pomi
ę
dzy testerami i innymi pracownikami:
•
Raczej współpracowa
ć
ni
ż
walczy
ć
– przypomina
ć
wszystkim o wspólnym celu, jakim
jest lepsza jako
ść
produktów.
Certyfikowany tester
Plan poziomu podstawowego
International Sotware Testing Qualifications Board
Stowarzyszenie Jako
ś
ci Systemów Informatycznych
Wersja 1.0
© Stowarzyszenie Jako
ś
ci Systemów
Informatycznych
Strona 19 z 78
20 pa
ź
dziernika 2006
•
Informowa
ć
o nieprawidłowo
ś
ciach produktu w neutralny sposób, zorientowany na
fakty, bez krytykowania osoby, która stworzyła produkt, na przykład, pisa
ć
obiektywne, faktyczne i rzeczowe raporty zdarze
ń
i nieprawidłowo
ś
ci znalezionych
podczas przegl
ą
dów.
•
Spróbowa
ć
zrozumie
ć
, co czuje inna osoba i dlaczego reaguje w sposób, w jaki
reaguje.
•
Upewni
ć
si
ę
,
ż
e inna osoba zrozumiała to, co zostało powiedziane.
Referencje:
1.1.5 Black, 2001, Kaner, 2002
1.2 Beizer, 1990, Black, 2001, Myers, 1979
1.3 Beizer, 1990, Hetzel, 1998, Myers, 1979
1.4 Hetzel, 1998
1.4.5 Black, 2001, Craig, 2002
1.5 Black, 2001, Hetzel, 1998
Certyfikowany tester
Plan poziomu podstawowego
International Sotware Testing Qualifications Board
Stowarzyszenie Jako
ś
ci Systemów Informatycznych
Wersja 1.0
© Stowarzyszenie Jako
ś
ci Systemów
Informatycznych
Strona 20 z 78
20 pa
ź
dziernika 2006
2. Testowanie w cyklu
ż
ycia oprogramowania (K2), 135
minut
Celem rozdziału „Testowanie w cyklu
ż
ycia oprogramowania” jest
nauczenie, w poszczególnych paragrafach:
2.1 Modele wytwarzania oprogramowania (K2)
•
Powi
ą
za
ń
mi
ę
dzy wytwarzaniem, testowaniem i budowanymi produktami w cyklu
wytwarzania oprogramowania; poda
ć
przykłady uwzgl
ę
dniaj
ą
ce wła
ś
ciwo
ś
ci produktu,
projektu oraz ich kontekst. (K2)
•
Konieczno
ś
ci dostosowywania modeli wytwarzania oprogramowania do wła
ś
ciwo
ś
ci
projektu i produktu. (K1)
•
Przyczyn testowania na ró
ż
nych poziomach, oraz charakterystyk dobrego testowania
niezale
ż
nie od modelu cyklu
ż
ycia oprogramowania.
2.2 Poziomy testów (K2)
•
Porównywania ró
ż
nych poziomów testów: głównych zało
ż
e
ń
testów, typowych
przedmiotów celów testów (np. funkcjonalne lub strukturalne), kto wykonuje testy,
rodzaje znajdowanych defektów i awarii. (K2)
2.3 Typy testów: cele testowania (K2)
•
Czterech typów testów - funkcjonalne, niefunkcjonalne, strukturalne i wynikaj
ą
ce ze
zmian. (K2)
•
O testowaniu funkcjonalnym i strukturalnym wyst
ę
puj
ą
cym na ka
ż
dym poziomie
testów. (K1)
•
Rozpoznawania i opisywania testów niefunkcjonalnych bazuj
ą
cych na wymaganiach
niefunkcjonalnych. (K2)
•
Rozpoznawania i opisywania typów testów bazuj
ą
cych na strukturze lub architekturze
systemu. (K2)
•
Przeznaczenia testowania potwierdzaj
ą
cego i testowania regresywnego. (K2)
2.4 Testowanie w fazie utrzymania (K2)
•
Testowania w fazie utrzymania (testowanie istniej
ą
cego systemu) i testowania nowej
aplikacji, na zasadzie porównania, z uwzgl
ę
dnieniem celów, powodów i zakresu
testów. (K2)
•
Przyczyn testowania w fazie utrzymania (modyfikacja, migracja lub wycofanie
systemu). (K1)
•
Roli testów regresywnych i analizy wpływu w utrzymaniu oprogramowania. (K2)
Certyfikowany tester
Plan poziomu podstawowego
International Sotware Testing Qualifications Board
Stowarzyszenie Jako
ś
ci Systemów Informatycznych
Wersja 1.0
© Stowarzyszenie Jako
ś
ci Systemów
Informatycznych
Strona 21 z 78
20 pa
ź
dziernika 2006
2.1. Modele wytwarzania oprogramowania (K2), 20 minut
Terminologia
Oprogramowanie z półki, przyrostowy model wytwarzania, poziom testów, walidacja,
weryfikacja, model „V”.
Wprowadzenie
Testowanie nie ma sensu w oderwaniu od czynno
ś
ci procesu wytwarzania oprogramowania,
z którym jest powi
ą
zane. Ró
ż
ne modele wytwarzania oprogramowania wymagaj
ą
odmiennej
metodologii testowania.
2.1.1. Model V (K2)
Pomimo,
ż
e istniej
ą
rozmaite warianty modelu „V”, powszechnie wykorzystywane podej
ś
cie
stosuje cztery poziomy testów, odpowiadaj
ą
ce czterem poziomom wytwarzania
oprogramowania.
W opracowaniu tym wykorzystywane s
ą
nast
ę
puj
ą
ce cztery poziomy:
•
Testowanie modułowe (jednostkowe);
•
Testowanie integracyjne;
•
Testowanie systemowe;
•
Testowanie akceptacyjne.
W rzeczywisto
ś
ci model „V” mo
ż
e mie
ć
inne definicje poziomów wytwarzania i testowania
oprogramowania, zale
ż
nie od projektu lub rodzaju produktu. Przykładowo, po testowaniu
modułowym mo
ż
e wyst
ę
powa
ć
testowanie integracyjne modułów, lub po testowaniu
systemowym testowanie integracyjne systemów.
Powstaj
ą
ce w procesie wytwarzania oprogramowania produkty (scenariusze biznesowe lub
przypadki u
ż
ycia, specyfikacje wymaga
ń
, dokumentacja projektowa oraz kod
ź
ródłowy)
stanowi
ą
cz
ę
sto podstaw
ę
testów na jednym lub kilku poziomach testów. Produkty te
definiowane s
ą
m.in. w modelu CMMI (Capability Maturity Model Integration) oraz w normie
IEEE/IEC 12207 (Software Life Cycle Process). W trakcie powstawania poszczególnych
produktów procesu mo
ż
e by
ć
wykonywana ich weryfikacja i walidacja (oraz wczesne
projektowanie testów).
2.1.2. Iteracyjne modele wytwarzania (K2)
Wytwarzanie w modelu iteracyjnym polega na kilkukrotnym – w formie kilku przej
ść
mniejszych procesów – okre
ś
laniu wymaga
ń
, projektowaniu, programowaniu i testowaniu
systemu. Przykładami modeli iteracyjnych s
ą
: prototypowanie, szybkie wytwarzanie
oprogramowania (Rapid Application Development, RAD), Rational Unified Process (RUP)
oraz metodyki zwinne (agile development). W trakcie trwania iteracji tworzony przyrost
systemu mo
ż
e by
ć
testowany na kilku poziomach. Kolejne przyrosty systemu, dodawane do
cz
ęś
ci wytworzonych wcze
ś
niej, stopniowo tworz
ą
system, który równie
ż
powinien by
ć
poddany testowaniu. W ka
ż
dej kolejnej iteracji coraz wa
ż
niejsze staj
ą
si
ę
testy regresywne.
W ka
ż
dej iteracji mo
ż
na wykonywa
ć
zarówno weryfikacj
ę
jak i walidacj
ę
.
2.1.3. Testowanie w cyklu
ż
ycia (K2)
Ka
ż
dy cykl
ż
ycia systemu posiada kilka cech charakterystycznych dobrego testowania:
Dla ka
ż
dej czynno
ś
ci wytwarzania systemu istnieje odpowiadaj
ą
ca jej czynno
ść
testowa.
Ka
ż
dy poziom testów ma specyficzne dla siebie cele.
Certyfikowany tester
Plan poziomu podstawowego
International Sotware Testing Qualifications Board
Stowarzyszenie Jako
ś
ci Systemów Informatycznych
Wersja 1.0
© Stowarzyszenie Jako
ś
ci Systemów
Informatycznych
Strona 22 z 78
20 pa
ź
dziernika 2006
Analiza i projektowanie testów dla danego poziomu powinny rozpoczyna
ć
si
ę
ju
ż
podczas
odpowiadaj
ą
cej im fazy wytwarzania.
Testerzy powinni uczestniczy
ć
w przegl
ą
dach wczesnych wersji dokumentacji tworzonej
podczas wytwarzania.
Poziomy testów mo
ż
na ł
ą
czy
ć
ze sob
ą
lub organizowa
ć
na ró
ż
ne sposoby zale
ż
nie od
specyfiki projektu lub architektury systemu. Na przykład podczas integracji w system
gotowego oprogramowania z półki zamawiaj
ą
cy mo
ż
e przeprowadza
ć
testowanie
integracyjne na poziomie systemu (np. testy integracji z infrastruktur
ą
i pozostałymi
systemami albo testy odbiorcze i wdro
ż
eniowe) oraz testowanie akceptacyjne (testy
funkcjonalne i/lub niefunkcjonalne, testy u
ż
ytkowników ko
ń
cowych i/lub testy zdolno
ś
ci
operacyjnej).
Certyfikowany tester
Plan poziomu podstawowego
International Sotware Testing Qualifications Board
Stowarzyszenie Jako
ś
ci Systemów Informatycznych
Wersja 1.0
© Stowarzyszenie Jako
ś
ci Systemów
Informatycznych
Strona 23 z 78
20 pa
ź
dziernika 2006
2.2. Poziomy testów (K2), 60 minut
Terminologia
Testowanie alfa, testowanie beta, testowanie modułowe (zwane te
ż
testowaniem
jednostkowym, modułowym lub programu), testy akceptacyjne zgodno
ś
ci z umow
ą
,
sterowniki, testy w
ś
rodowisku produkcyjnym, wymagania funkcjonalne, integracja,
testowanie integracyjne, wymagania niefunkcjonalne, operacyjne testy akceptacyjne, testy
akceptacyjne zgodno
ś
ci legislacyjnej, testowanie odporno
ś
ci, za
ś
lepki, testowanie
systemowe, wytwarzanie sterowane testowaniem (test-driven development),
ś
rodowisko
testowe, testowanie akceptacyjne przez u
ż
ytkownika.
Wprowadzenie
Dla ka
ż
dego poziomu testów mo
ż
na okre
ś
li
ć
nast
ę
puj
ą
ce parametry: ogólne cele, produkty
procesu wytwarzania, z których wywodz
ą
si
ę
przypadki testowe (podstawa testów),
przedmiot testowania (co b
ę
dzie testowane), znajdowane typowe defekty i awarie,
wymagania dotycz
ą
ce jarzma testowego oraz wsparcia narz
ę
dziowego, metodologii
testowania oraz odpowiedzialno
ś
ci.
2.2.1. Testowanie modułowe (K2)
Celem testów modułowych jest poszukiwanie bł
ę
dów oraz weryfikowanie daj
ą
cych si
ę
przetestowa
ć
elementów oprogramowania, np. modułów, programów, obiektów, klas itd.
Testy modułowe wykonuje si
ę
zwykle osobno dla ka
ż
dego testowanego obiektu, cho
ć
zale
ż
y
to od rodzaju systemu oraz przyj
ę
tego cyklu wytwarzania oprogramowania. W tej sytuacji
niezb
ę
dne mo
ż
e by
ć
posługiwanie si
ę
sterownikami testowymi, symulatorami oraz
za
ś
lepkami.
Celem testów modułowych mo
ż
e by
ć
zarówno weryfikacja funkcjonalno
ś
ci modułu jak i jego
wła
ś
ciwo
ś
ci niefunkcjonalnych, na przykład wykorzystania zasobów (czy nie powoduje
wycieków pami
ę
ci itp.). Ponadto wykonywane mog
ą
by
ć
testy odporno
ś
ci modułu oraz
testowanie strukturalne w celu osi
ą
gni
ę
cia pokrycia rozgał
ę
zie
ń
. Przypadki testowe
projektuje si
ę
na podstawie specyfikacji modułów, specyfikacji projektu oprogramowania lub
modelu danych.
Testowanie modułowe zwykle wykonuje si
ę
maj
ą
c dost
ę
p do kodu
ź
ródłowego,
ś
rodowiska
deweloperskiego, oprogramowania wspomagaj
ą
cego testy jednostkowe lub debagera.
Uczestniczy w nim zazwyczaj programista b
ę
d
ą
cy twórc
ą
testowanego modułu, natomiast
defekty s
ą
naprawiane natychmiast po znalezieniu, bez formalnego zgłaszania incydentów.
Jedna z metodologii organizacji testów modułowych polega na przygotowaniu
automatycznych przypadków testowych zanim jeszcze przyst
ą
pi si
ę
do kodowania.
Metodologia ta nazywana jest „najpierw przygotuj testy” lub „wytwarzanie sterowane
testowaniem”. Sposób ten jest wysoce iteracyjny i polega na cyklicznym budowaniu
automatycznych przypadków testowych, a nast
ę
pnie konstruowaniu i integracji niewielkich
fragmentów kodu oraz wykonywaniu testów modułowych a
ż
do spełnienia ustalonych
kryteriów.
2.2.2. Testowanie integracyjne (K2)
Podczas testowania integracyjnego testuje si
ę
interfejsy mi
ę
dzy modułami, interakcj
ę
z
innymi cz
ęś
ciami systemu (system operacyjny, system plików, sprz
ę
t) oraz interfejsy do
innych systemów.
Certyfikowany tester
Plan poziomu podstawowego
International Sotware Testing Qualifications Board
Stowarzyszenie Jako
ś
ci Systemów Informatycznych
Wersja 1.0
© Stowarzyszenie Jako
ś
ci Systemów
Informatycznych
Strona 24 z 78
20 pa
ź
dziernika 2006
Testy integracyjne mog
ą
by
ć
wykonywane na kilku poziomach, a ich przedmiotem mog
ą
by
ć
cz
ęś
ci rozmaitej wielko
ś
ci. Przykładowo, testy integracyjne modułów sprawdzaj
ą
interakcje
mi
ę
dzy modułami oprogramowania, wykonuje si
ę
je po zako
ń
czeniu testów modułowych.
Natomiast testy integracyjne systemów sprawdzaj
ą
interakcj
ę
mi
ę
dzy ró
ż
nymi systemami i
mog
ą
by
ć
wykonywane po zako
ń
czeniu testowania systemowego. W tej sytuacji organizacja
wytwarzaj
ą
ca oprogramowanie zarz
ą
dza tylko jedn
ą
cz
ęś
ci
ą
interfejsu, co powoduje
trudno
ś
ci w przypadku zmian. Procesy biznesowe, zaimplementowane jako przepływy, mog
ą
anga
ż
owa
ć
wiele systemów. Du
ż
e znaczenie mog
ą
odgrywa
ć
zagadnienia zgodno
ś
ci
mi
ę
dzy rozmaitymi platformami.
Im wi
ę
kszy jest zakres integracji, tym trudniejsze mo
ż
e by
ć
okre
ś
lenie, który moduł lub
system jest przyczyn
ą
danej awarii, co powoduje zwi
ę
kszone ryzyko.
Systematyczne strategie integracji mog
ą
opiera
ć
si
ę
na architekturze systemu (np. scalanie
wst
ę
puj
ą
ce lub zst
ę
puj
ą
ce), funkcjach systemu, kolejno
ś
ci przetwarzania transakcji, oraz
innych wła
ś
ciwo
ś
ciach systemu lub modułu. Aby ograniczy
ć
ryzyko spowodowane zbyt
pó
ź
nym ujawnianiem bł
ę
dów, zaleca si
ę
raczej integracj
ę
przyrostow
ą
ni
ż
skokow
ą
(„big
bang”).
W ramach testów integracyjnych wykonuje si
ę
tak
ż
e niekiedy testowanie wła
ś
ciwo
ś
ci
niefunkcjonalnych, np. wydajno
ś
ci.
Niezale
ż
nie od poziomu integracji, testowanie powinno dotyczy
ć
wył
ą
cznie samej integracji.
Przykładowo, integruj
ą
c ze sob
ą
moduły A i B, powinno si
ę
testowa
ć
komunikacj
ę
mi
ę
dzy
tymi modułami, a nie ich funkcjonalno
ść
. Stosuje si
ę
podej
ś
cie zarówno strukturalne jak i
funkcjonalne.
Najlepiej byłoby, aby testerzy rozumieli architektur
ę
systemu oraz mieli wpływ na planowanie
integracji. Planowanie testów integracyjnych przed przyst
ą
pieniem do wytwarzania systemu i
jego modułów pozwala na przyj
ę
cie takiej kolejno
ś
ci wytwarzania, która umo
ż
liwia
najsprawniejsze testowanie.
2.2.3. Testowanie systemowe (K2)
Testowanie systemowe dotyczy działania całego systemu lub produktu, zgodnie z zakresem
projektu lub programu.
Dla testowania systemowego
ś
rodowisko powinno odwzorowywa
ć
w miar
ę
mo
ż
liwo
ś
ci jak
najwierniej
ś
rodowisko produkcyjne, tak, aby zminimalizowa
ć
ryzyko,
ż
e nie zostan
ą
znalezione bł
ę
dy zale
ż
ne od jego specyfiki.
Przypadki testowe wykorzystywane w testowaniu systemowym mo
ż
na projektowa
ć
na
podstawie oceny ryzyka, specyfikacji wymaga
ń
, procesu biznesowego, przypadków u
ż
ycia
lub innych opisów działania systemu (na wysokim poziomie), jak równie
ż
interakcji systemu z
systemem operacyjnym i jego zasobami.
Testowanie systemowe powinno dotyczy
ć
zarówno wymaga
ń
funkcjonalnych jak i
niefunkcjonalnych. Wymagania opisuje si
ę
w formie tekstowej lub w formie modeli.
Potrzebna jest tak
ż
e umiej
ę
tno
ść
radzenia sobie z niepełnymi lub nieudokumentowanymi
wymaganiami. Testowanie funkcjonalne nale
ż
y rozpocz
ąć
od projektowania przypadków
testowych przy pomocy najstosowniejszej dla danego systemu techniki czarnoskrzynkowej
(w oparciu o specyfikacj
ę
). Przykładowo, tablica decyzyjna mo
ż
e posłu
ż
y
ć
do
systematycznego opisu zale
ż
no
ś
ci czynników opisanych w regułach biznesowych. Mo
ż
na
te
ż
zastosowa
ć
techniki testowania strukturalnego (białoskrzynkowe), aby oceni
ć
staranno
ść
testowania w odniesieniu do pokrycia wybranych elementów, np. struktury menu lub
nawigacji mi
ę
dzy stronami WWW (zob. rozdz. 4.)
Testowanie systemowe wykonywane jest cz
ę
sto przez niezale
ż
ny zespół testowy.
Certyfikowany tester
Plan poziomu podstawowego
International Sotware Testing Qualifications Board
Stowarzyszenie Jako
ś
ci Systemów Informatycznych
Wersja 1.0
© Stowarzyszenie Jako
ś
ci Systemów
Informatycznych
Strona 25 z 78
20 pa
ź
dziernika 2006
2.2.4. Testowanie akceptacyjne (K2)
Odpowiedzialno
ść
za testowanie akceptacyjne nale
ż
y cz
ę
sto do klientów lub do
u
ż
ytkowników, cho
ć
mog
ą
w nim mie
ć
udział tak
ż
e inni interesariusze.
Celem testowania akceptacyjnego jest osi
ą
gni
ę
cie zaufania do systemu, jego cz
ęś
ci lub
okre
ś
lonych wymaga
ń
niefunkcjonalnych. Głównym celem testów akceptacyjnych nie jest
znajdowanie defektów. Testy akceptacyjne mog
ą
słu
ż
y
ć
do oceny gotowo
ś
ci systemu do
wdro
ż
enia lub u
ż
ytkowania, cho
ć
niekoniecznie s
ą
ostatni
ą
faz
ą
testowania. Przykładowo,
testy integracyjne zewn
ę
trzne mog
ą
by
ć
wykonywane po testach akceptacyjnych.
Testowanie akceptacyjne mo
ż
e pojawi
ć
si
ę
na wi
ę
cej ni
ż
jednym poziomie, np.:
•
Oprogramowanie z półki mo
ż
e by
ć
poddane testom akceptacyjnym w trakcie
instalacji lub integracji,
•
Testy akceptacyjne u
ż
yteczno
ś
ci modułu mog
ą
mie
ć
miejsce w trakcie testów
modułowych,
•
Testowanie akceptacyjne poprawy funkcjonalno
ś
ci mo
ż
e by
ć
wykonane przed testem
systemowym.
Najcz
ęś
ciej spotyka si
ę
nast
ę
puj
ą
ce formy testów akceptacyjnych:
Testowanie akceptacyjne przez u
ż
ytkownika
Typowy cel to weryfikacja dostosowania do u
ż
ycia, dokonywana przez u
ż
ytkowników
biznesowych.
Operacyjne testy akceptacyjne
Akceptacja systemu przez jego administratorów, dotycz
ą
ca:
•
Tworzenia kopii zapasowych i odtwarzania z nich systemu;
•
Odtworzenia systemu po awarii;
•
Zarz
ą
dzania kontami u
ż
ytkowników;
•
Okresowych kontroli zagro
ż
e
ń
zabezpiecze
ń
.
Testy akceptacyjne zgodno
ś
ci z umow
ą
(odbiorcze) i testy zgodno
ś
ci legislacyjnej
Testy akceptacyjne zgodno
ś
ci z umow
ą
(testy odbiorcze) wykonuje si
ę
na podstawie
okre
ś
lonych w kontrakcie kryteriów odbioru dla oprogramowania dostarczanego na
zamówienie. Kryteria te powinny by
ć
okre
ś
lone w trakcie uzgadniania kontraktu. Testy
akceptacyjne zgodno
ś
ci legislacyjnej wykonuje si
ę
na podstawie obowi
ą
zuj
ą
cych przepisów
prawnych, bran
ż
owych lub bezpiecze
ń
stwa.
Testy alfa oraz testy beta (testy w
ś
rodowisku produkcyjnym)
Producenci oprogramowania sprzedawanego z półki zwykle chc
ą
uzyska
ć
wyniki oceny
produktu przez istniej
ą
cych lub potencjalnych klientów z wła
ś
ciwego segmentu rynku przed
wypuszczeniem go do sprzeda
ż
y. Testowanie alfa wykonywane jest w siedzibie producenta
oprogramowania. Testowanie beta (testy w
ś
rodowisku produkcyjnym) wykonywane jest w
siedzibach u
ż
ytkowników. Zarówno testowanie alfa jak i testowanie beta wykonywane jest
przez potencjalnych u
ż
ytkowników, nie przez twórców produktu.
W odniesieniu do systemów testowanych przed i po dostarczeniu do operacyjnego
ś
rodowiska u
ż
ytkowników firmy stosuj
ą
równie
ż
inne okre
ś
lenia, takie jak testy akceptacji
produkcyjnej lub testy akceptacji instalacji.
Certyfikowany tester
Plan poziomu podstawowego
International Sotware Testing Qualifications Board
Stowarzyszenie Jako
ś
ci Systemów Informatycznych
Wersja 1.0
© Stowarzyszenie Jako
ś
ci Systemów
Informatycznych
Strona 26 z 78
20 pa
ź
dziernika 2006
2.3. Typy i cele testów (K2), 40 minut
Terminologia
Automatyzacja, testowanie czarnoskrzynkowe, pokrycie kodu, testowanie potwierdzaj
ą
ce,
testowanie funkcjonalne, testowanie zgodno
ś
ci operacyjnej, testowanie obci
ąż
eniowe,
testowanie utrzymywalno
ś
ci, testowanie wydajno
ś
ciowe, testowanie przenaszalno
ś
ci,
testowanie regresywne, testowanie niezawodno
ś
ci, testowanie zabezpiecze
ń
, testowanie w
oparciu o specyfikacj
ę
, testowanie przeci
ąż
aj
ą
ce, testowanie strukturalne, scenariusz
testowy, testowanie u
ż
yteczno
ś
ci, testowanie białoskrzynkowe.
Wprowadzenie
Testowanie mo
ż
na podzieli
ć
według tego, jakie s
ą
powody lub przyczyny wykonywania danej
grupy testów.
Cech
ą
testów nale
żą
cych do jednej kategorii jest okre
ś
lony, wspólny cel: np. przetestowanie
danej funkcjonalno
ś
ci, przetestowanie wła
ś
ciwo
ś
ci takiej jak niezawodno
ść
lub u
ż
yteczno
ść
,
wykonanie testów struktury albo architektury systemu, lub testowanie zwi
ą
zane ze
zamianami (weryfikacja naprawy defektu – testowanie potwierdzaj
ą
ce; poszukiwanie
niezamierzonych zmian – testowanie regresywne).
W testach strukturalnych lub funkcjonalnych cz
ę
sto stosowane s
ą
modele. Przykładowo, w
testach funkcjonalnych mo
ż
e by
ć
wykorzystany model przepływu procesu, model automatu
sko
ń
czonego (przej
ść
stanów) albo specyfikacja przygotowana w j
ę
zyku naturalnym. Dla
testów strukturalnych mo
ż
e to by
ć
model przepływu starowania lub model struktury menu.
2.3.1. Testowanie funkcji (testowanie funkcjonalne) (K2)
Funkcje systemu, podsystemu lub modułu opisuje si
ę
w specyfikacji wymaga
ń
w formie
przypadków u
ż
ycia lub w formie specyfikacji funkcjonalnej. Bywaj
ą
równie
ż
nieudokumentowane. Funkcje te okre
ś
laj
ą
CO robi system.
Testy funkcjonalne dotycz
ą
funkcji lub cech systemu (udokumentowanych lub znanych
testerom) i wykonuje si
ę
je na wszystkich poziomach testów (np. testy modułu na podstawie
specyfikacji modułu).
Techniki testowania w oparciu o specyfikacj
ę
polegaj
ą
na tym,
ż
e warunki i przypadki
testowe projektuje si
ę
na podstawie specyfikacji funkcjonalnej oprogramowania lub systemu
(zob. rozdz. 4). Testowanie funkcjonalne dotyczy zewn
ę
trznego działania oprogramowania
(testowanie czarnoskrzynkowe).
Jeden z typów testów funkcjonalnych - testowanie zabezpiecze
ń
- weryfikuje funkcjonalno
ść
(np. zapory – „firewall”) słu
żą
c
ą
zabezpieczaniu przed zagro
ż
eniami takimi jak wirusy czy
nieuprawniony dost
ę
p osób z zewn
ą
trz.
2.3.2. Testowanie wła
ś
ciwo
ś
ci (testowanie niefunkcjonalne) (K2)
W skład testów niefunkcjonalnych wchodzi mi
ę
dzy innymi: testowanie wydajno
ś
ci,
testowanie obci
ąż
eniowe, testowanie przeci
ąż
aj
ą
ce, testowanie u
ż
yteczno
ś
ci, testowanie
współdziałania, testowanie utrzymywalno
ś
ci, testowanie niezawodno
ś
ci oraz testowanie
przenaszalno
ś
ci. Testowanie to okre
ś
la JAK system działa.
Testowanie niefunkcjonalne mo
ż
na przeprowadza
ć
na wszystkich poziomach testów.
Okre
ś
lenie testowanie niefunkcjonalne odnosi si
ę
do testów niezb
ę
dnych do pomiaru
charakterystyk systemu i oprogramowania, które daj
ą
si
ę
skwantyfikowa
ć
na skali (np. czas
Certyfikowany tester
Plan poziomu podstawowego
International Sotware Testing Qualifications Board
Stowarzyszenie Jako
ś
ci Systemów Informatycznych
Wersja 1.0
© Stowarzyszenie Jako
ś
ci Systemów
Informatycznych
Strona 27 z 78
20 pa
ź
dziernika 2006
odpowiedzi w testowaniu wydajno
ś
ciowym). Testowanie tego typu odwołuje si
ę
do modelu
jako
ś
ci takiego jak np. ISO 9126 „Software Engineering – Software Product Quality”.
2.3.3. Testowanie struktury/architektury systemu (testowanie
strukturalne) (K2)
Testy strukturalne (białoskrzynkowe) wykonuje si
ę
na wszystkich poziomach testów.
Techniki testowania strukturalnego najlepiej jest stosowa
ć
po technikach w oparciu o
specyfikacj
ę
, aby zmierzy
ć
staranno
ść
testowania poprzez ocen
ę
pokrycia wybranego
rodzaju struktur.
Pokrycie testowe to miara okre
ś
laj
ą
ca stopie
ń
wykonania danej struktury przez scenariusz
testowy, obliczona jako odsetek pokrytych elementów. Je
ś
li pokrycie nie wynosi 100%, aby
przetestowa
ć
wcze
ś
niej pomini
ę
te elementy, mo
ż
na zaprojektowa
ć
dodatkowe przypadki
testowe. Techniki pomiaru pokrycia omówione s
ą
w Rozdziale 4.
Na wszystkich poziomach testów, a zwłaszcza w testach modułowych oraz testach
integracyjnych modułów, stosuje si
ę
narz
ę
dzia do mierzenia pokrycia takich elementów kodu,
jak instrukcje lub decyzje. Testowanie strukturalne mo
ż
na wykonywa
ć
zgodnie z architektur
ą
systemu, np. hierarchi
ą
wywoła
ń
.
Podej
ś
cie strukturalne mo
ż
e by
ć
równie
ż
stosowane na poziomie testów systemowych,
testów integracji systemów lub testów akceptacyjnych, np. w odniesieniu do modelu
biznesowego albo struktury menu.
2.3.4. Testowanie zwi
ą
zane ze zmianami (testowanie potwierdzaj
ą
ce i
regresywne) (K2)
Po wykryciu i naprawieniu defektu, aby zweryfikowa
ć
(potwierdzi
ć
),
ż
e usuni
ę
cie defektu
zako
ń
czyło si
ę
powodzeniem, oprogramowanie nale
ż
y przetestowa
ć
ponownie. Nazywa si
ę
to testowaniem potwierdzaj
ą
cym. Debagowanie (naprawa defektu) nale
ż
y do wytwarzania,
nie do testowania.
Testowanie regresywne polega na ponownym testowaniu ju
ż
przetestowanego programu po
jego modyfikacji po to, aby ujawni
ć
mo
ż
liwe defekty powstałe – lub odkryte – w wyniku
wprowadzonej zmiany lub zmian. Defekty te mog
ą
wyst
ę
powa
ć
albo w testowanym
oprogramowaniu, albo w innym – maj
ą
cym lub nie, zwi
ą
zek z przedmiotem testów – module
oprogramowania. Testowanie regresywne wykonuje si
ę
po zmianie oprogramowania lub jego
ś
rodowiska operacyjnego. Zakres testów regresywnych zale
ż
y od tego, jak du
ż
e jest ryzyko,
ż
e znajdzie si
ę
usterki w oprogramowaniu, które wcze
ś
niej działało poprawnie.
Testy, które maj
ą
by
ć
stosowane do testowania potwierdzaj
ą
cego i testowania regresywnego
musz
ą
by
ć
powtarzalne.
Testowanie regresywne mo
ż
na przeprowadza
ć
na wszystkich poziomach testów. W skład
testów regresywnych wchodz
ą
wszelkie typy testów: funkcjonalne, wła
ś
ciwo
ś
ci i strukturalne.
Poniewa
ż
zestawy testów do testów regresywnych wykorzystuje si
ę
wielokrotnie i s
ą
one
stosunkowo niezmienne, s
ą
dobrymi kandydatami do automatyzacji.
Certyfikowany tester
Plan poziomu podstawowego
International Sotware Testing Qualifications Board
Stowarzyszenie Jako
ś
ci Systemów Informatycznych
Wersja 1.0
© Stowarzyszenie Jako
ś
ci Systemów
Informatycznych
Strona 28 z 78
20 pa
ź
dziernika 2006
2.4. Testowanie w fazie utrzymania (K2), 15 minut
Terminologia
Analiza wpływu, testowanie w fazie utrzymania, migracja, modyfikacje, wycofanie systemu.
Wprowadzenie
Po wdro
ż
eniu wiele systemów informatycznych jest wykorzystywanych przez lata, a nawet
dziesi
ą
tki lat. W tym czasie system i jego
ś
rodowisko poddawane s
ą
licznym naprawom,
zmianom i rozbudowie. Testowanie w fazie utrzymania wykonywane jest na systemie
produkcyjnym, a jego powodem s
ą
modyfikacje, migracje lub wycofanie oprogramowania czy
systemu.
Modyfikacje przeprowadzane podczas utrzymania systemu maj
ą
ró
ż
ne przyczyny:
rozbudowa i udoskonalanie systemu (np. w formie planowanych wersji), modyfikacje
naprawcze i awaryjne, a tak
ż
e ró
ż
norodne zmiany
ś
rodowiska (kolejne planowane wersje
systemu operacyjnego lub bazy danych lub łaty usuwaj
ą
ce nowoodkryte usterki
zabezpiecze
ń
systemu operacyjnego).
Testowanie w fazie utrzymania wykonywane w trakcie migracji (np. na inn
ą
platform
ę
)
powinno dotyczy
ć
zarówno testów zdolno
ś
ci operacyjnej dla nowego
ś
rodowiska, jak i testów
zmodyfikowanego oprogramowania.
Testowanie w fazie utrzymania wykonywane w zwi
ą
zku z wycofaniem systemu mo
ż
e
obejmowa
ć
testy migracji danych lub – je
ś
li dane musz
ą
by
ć
przechowywane przez długi
czas – testy ich archiwizacji.
Oprócz testowania wykonanych zmian, testy w fazie utrzymania obejmuj
ą
tak
ż
e pełne testy
regresywne niezmienionych cz
ęś
ci systemu. Zakres testów regresywnych zale
ż
y od ryzyka
zmiany, wielko
ś
ci systemu oraz zakresu zmiany. Zale
ż
nie od rodzaju zmian, testowanie w
fazie utrzymania wykonywane jest na którymkolwiek – lub na wszystkich – poziomach testów
oraz dotyczy któregokolwiek – lub wszystkich – typów testów.
Analiza wpływu polega na okre
ś
leniu, w jaki sposób zmiany mog
ą
wpłyn
ąć
na system. Wynik
jej okre
ś
la, jak obszerne testy regresywne nale
ż
y wykona
ć
.
Przyczyn
ą
trudno
ś
ci w testach w fazie utrzymania bywa przestarzała czy wr
ę
cz zaginiona
specyfikacja systemu.
Referencje
2.1.3 CMMI, Craig, 2002, Hetzel, 1998, IEEE 12207
2.2 Hetzel, 1998
2.2.4 Copeland, 2004, Myers, 1979
2.3.1 Beizer, 1990, Black, 2001, Copeland, 2004
2.3.2 Black, 2001, ISO 9126
2.3.3 Beizer, 1990, Copeland, 2004, Hetzel, 1998
2.3.4 Hetzel, 1998, IEEE 829
2.4 Black, 2001, Craig, 2002, Hetzel, 1998, IEEE 829
Certyfikowany tester
Plan poziomu podstawowego
International Sotware Testing Qualifications Board
Stowarzyszenie Jako
ś
ci Systemów Informatycznych
Wersja 1.0
© Stowarzyszenie Jako
ś
ci Systemów
Informatycznych
Strona 29 z 78
20 pa
ź
dziernika 2006
3. Statyczne techniki testowania (K2), 60 minut
Celem rozdziału „Statyczne techniki testowania” jest nauczenie, w
poszczególnych paragrafach:
3.1 Przegl
ą
dy i proces testowy (K2)
•
Rozpoznawania produktów oprogramowania badanych przez ró
ż
ne statyczne
techniki testowania. (K1)
•
Znaczenia i warto
ś
ci rozwa
ż
anych statycznych technik testowania w celu oceny
produktów oprogramowania. (K2)
•
Ró
ż
nic pomi
ę
dzy statycznymi i dynamicznymi technikami testowania. (K2)
3.2 Proces przegl
ą
du (K2)
•
Faz, ról i odpowiedzialno
ś
ci typowego formalnego przegl
ą
du. (K1)
•
Ró
ż
nic pomi
ę
dzy rodzajami przegl
ą
du: przegl
ą
d nieformalny, przegl
ą
d techniczny,
przejrzenie i inspekcja. (K2)
•
Czynników udanego wykonania przegl
ą
du. (K2)
3.3 Analiza statyczna wsparta narz
ę
dziowo (K2)
•
Celu analizy statycznej i porównania jej z testowaniem dynamicznym. (K2)
•
Typowych defektów i pomyłek wykrytych dzi
ę
ki analizie statycznej i porównania ich z
przegl
ą
dami i testowaniem dynamicznym. (K1)
•
Typowych zalet analizy statycznej. (K1)
•
Typowych bł
ę
dów kodu i projektu, które mo
ż
na zidentyfikowa
ć
za pomoc
ą
narz
ę
dzi
do analizy statycznej. (K1)
Certyfikowany tester
Plan poziomu podstawowego
International Sotware Testing Qualifications Board
Stowarzyszenie Jako
ś
ci Systemów Informatycznych
Wersja 1.0
© Stowarzyszenie Jako
ś
ci Systemów
Informatycznych
Strona 30 z 78
20 pa
ź
dziernika 2006
3.1. Przegl
ą
dy i proces testowy(K2), 15 minut
Terminologia
Testowanie dynamiczne, przegl
ą
dy, analiza statyczna.
Wprowadzenie
Statyczne techniki testowania nie wykonuj
ą
testowanego programu; s
ą
to techniki r
ę
czne
(przegl
ą
dy) lub zautomatyzowane (analiza statyczna).
Przegl
ą
dy s
ą
sposobem testowania produktów pracy programowej (wliczaj
ą
c w to kod) i
mog
ą
by
ć
wykonane przed wykonaniem testu dynamicznego. Defekty wykryte podczas
przegl
ą
dów na wczesnym etapie cyklu
ż
ycia oprogramowania s
ą
cz
ę
sto du
ż
o ta
ń
sze do
usuni
ę
cia ni
ż
defekty wykryte podczas wykonywania pó
ź
niejszych testów (np. defekty
znalezione w wymaganiach).
Przegl
ą
d mógłby by
ć
wykonany w cało
ś
ci jako czynno
ść
r
ę
czna, jednak
ż
e istnieje wsparcie
narz
ę
dziowe dla tego procesu. Główna r
ę
czna czynno
ść
to zbada
ć
produkt i zebra
ć
uwagi
na jego temat. Mo
ż
na przejrze
ć
ka
ż
dy produkt pracy programowej, wliczaj
ą
c w to
specyfikacje wymaga
ń
, specyfikacje projektu, kod, plany testów, specyfikacje testów,
przypadki testowe, skrypty testowe, instrukcje u
ż
ytkownika czy strony webowe.
Do zalet przegl
ą
dów wlicza si
ę
: wczesne wykrycie i napraw
ę
defektu, popraw
ę
produktywno
ś
ci oprogramowania, skrócony czas tworzenia oprogramowania, skrócony czas i
koszt testowania, zmniejszenie defektów oraz lepsz
ą
komunikacj
ę
. Podczas wykonywania
przegl
ą
dów mo
ż
na wykry
ć
opuszczenia (np. w wymaganiach), co jest du
ż
o mniej
prawdopodobne podczas testowania dynamicznego.
Przegl
ą
dy, analiza statyczna i testowanie dynamiczne maj
ą
ten sam cel – zidentyfikowanie
defektów. S
ą
to czynno
ś
ci uzupełniaj
ą
ce si
ę
: ró
ż
ne techniki mog
ą
znale
źć
ró
ż
ne rodzaje
defektów efektywnie i wydajnie. W przeciwie
ń
stwie do testowania dynamicznego, przegl
ą
dy
znajduj
ą
raczej defekty ni
ż
awarie.
Typowe defekty łatwiejsze do znalezienia w przegl
ą
dach ni
ż
w testowaniu dynamicznym to:
odchylenia od standardów, bł
ę
dy wymaga
ń
, bł
ę
dy projektu, niewystarczaj
ą
ca zdolno
ść
do
konserwacji, nieprawidłowe specyfikacje interfejsów.
Certyfikowany tester
Plan poziomu podstawowego
International Sotware Testing Qualifications Board
Stowarzyszenie Jako
ś
ci Systemów Informatycznych
Wersja 1.0
© Stowarzyszenie Jako
ś
ci Systemów
Informatycznych
Strona 31 z 78
20 pa
ź
dziernika 2006
3.2. Proces przegl
ą
du (K2), 25 minut
Terminologia
Kryteria wej
ś
ciowe, warunki wyj
ś
cia, przegl
ą
d formalny, przegl
ą
d nieformalny, inspekcja,
rozpocz
ę
cie, miary, moderator/prowadz
ą
cy inspekcj
ę
, przegl
ą
d kole
ż
e
ń
ski, przegl
ą
daj
ą
cy,
proces przegl
ą
du, protokolant, przegl
ą
d techniczny, przejrzenie.
Wprowadzenie
Przegl
ą
dy mog
ą
by
ć
od bardzo nieformalnych do bardzo formalnych (dobrze
zorganizowanych i uregulowanych). Formalno
ść
procesu przegl
ą
du zwi
ą
zana jest z takimi
czynnikami jak dojrzało
ść
procesu programowania, prawne lub ustalone wymagania oraz
potrzeby audytu.
Sposób, w jaki przegl
ą
d jest przeprowadzany, zale
ż
y od uzgodnionego celu przegl
ą
du (np.
znale
źć
defekt, zrozumie
ć
lub wywoła
ć
dyskusj
ę
i osi
ą
gn
ąć
decyzj
ę
poprzez konsensus).
3.2.1. Fazy formalnego przegl
ą
du (K1)
Typowy formalny przegl
ą
d ma nast
ę
puj
ą
ce główne fazy:
•
Planowanie: wybór osób, przypisanie ról; okre
ś
lenie kryteriów wej
ś
ciowych i
warunków wyj
ś
cia (dla bardziej formalnych typów przegl
ą
du np. inspekcji); wybór
cz
ęś
ci dokumentów do przejrzenia.
•
Rozpocz
ę
cie: dystrybucja dokumentów; wyja
ś
nienie uczestnikom celów, procesu i
dokumentów; sprawdzenie kryteriów wej
ś
ciowych (dla bardziej formalnych typów
przegl
ą
du).
•
Indywidualne przygotowanie: praca wykonana samodzielnie przez ka
ż
dego z
uczestników przed spotkaniem przegl
ą
dowym, zanotowanie potencjalnych bł
ę
dów,
pyta
ń
i komentarzy.
•
Spotkanie przegl
ą
dowe: dyskusja lub zapis z udokumentowanymi wynikami lub
protokołami (dla bardziej formalnych typów przegl
ą
du). Uczestnicy spotkania mog
ą
po prostu zanotowa
ć
defekty, przedstawi
ć
zalecenia odno
ś
nie obsługi defektów lub
poczyni
ć
decyzje w sprawie defektów.
•
Obróbka: ustalenie znalezionych defektów - zazwyczaj wykonywane przez autora.
•
Dalsza cz
ęść
: sprawdzenie, czy defekty zostały zaadresowane; zebranie metryk i
sprawdzenie warunków wyj
ś
cia (dla bardziej formalnych typów przegl
ą
dów).
3.2.2. Role i odpowiedzialno
ś
ci (K1)
Typowy formalny przegl
ą
d mo
ż
e zawiera
ć
nast
ę
puj
ą
ce role:
•
Mened
ż
er: decyduje o wykonaniu przegl
ą
dów, przydziela czas w harmonogramach
projektów i okre
ś
la, czy zostały uwzgl
ę
dnione cele przegl
ą
du.
•
Moderator: osoba, która prowadzi przegl
ą
d dokumentu lub zestawu dokumentów,
wliczaj
ą
c w to planowanie przegl
ą
du, przebieg spotkania i dalsz
ą
cz
ęść
po spotkaniu.
Je
ż
eli konieczne, moderator mo
ż
e prowadzi
ć
mediacje pomi
ę
dzy ró
ż
nymi punktami
widzenia i cz
ę
sto jest osob
ą
, na której spoczywa sukces przegl
ą
du.
•
Autor: autor lub osoba odpowiedzialna za przegl
ą
dany dokument lub dokumenty.
•
Przegl
ą
daj
ą
cy: osoby ze specyficznym technicznym lub biznesowym przygotowaniem
(zwane tak
ż
e kontrolerami lub inspektorami), które po niezb
ę
dnym przygotowaniu,
identyfikuj
ą
i opisuj
ą
wyniki bada
ń
(np. bł
ę
dy) przegl
ą
danego produktu. Przegl
ą
daj
ą
cy
powinni by
ć
wybrani w taki sposób, aby reprezentowa
ć
ró
ż
ne perspektywy i role.
Uczestnicz
ą
we wszelkich spotkaniach przegl
ą
dowych.
Certyfikowany tester
Plan poziomu podstawowego
International Sotware Testing Qualifications Board
Stowarzyszenie Jako
ś
ci Systemów Informatycznych
Wersja 1.0
© Stowarzyszenie Jako
ś
ci Systemów
Informatycznych
Strona 32 z 78
20 pa
ź
dziernika 2006
•
Protokolant (lub rejestrator): dokumentuje wszystkie kwestie, problemy i otwarte
punkty, które zidentyfikowano podczas spotkania.
Spojrzenie na dokumenty z ró
ż
nych perspektyw oraz u
ż
ywanie list kontrolnych mo
ż
e uczyni
ć
przegl
ą
dy bardziej efektywnymi i wydajnymi. Przykładowo, lista kontrolna oparta na
perspektywach takich jak u
ż
ytkownik, osoba zajmuj
ą
ca si
ę
utrzymaniem oprogramowania,
tester lub wdro
ż
eniowiec albo lista kontrolna typowych problemów wymaga
ń
.
3.2.3. Rodzaje przegl
ą
dów (K2)
Pojedynczy dokument mo
ż
e by
ć
przedmiotem wi
ę
cej ni
ż
jednego przegl
ą
du. Je
ż
eli wykonuje
si
ę
wi
ę
cej ni
ż
jeden rodzaj przegl
ą
du to ich kolejno
ść
mo
ż
e by
ć
ró
ż
na. Na przykład, przegl
ą
d
nieformalny mo
ż
na przeprowadzi
ć
przed przegl
ą
dem technicznym, inspekcj
ę
odno
ś
nie
specyfikacji wymaga
ń
mo
ż
na przeprowadzi
ć
przed przejrzeniem ich z klientami. Główne
cechy, opcje i cele powszechnych rodzajów przegl
ą
du to:
Przegl
ą
d nieformalny
Kluczowe wła
ś
ciwo
ś
ci:
•
Brak formalnego procesu;
•
Mo
ż
liwo
ść
zastosowania przy programowaniu parami lub do przegl
ą
dów projektu i
kodu przez kierownika zespołu;
•
Opcjonalnie: mo
ż
e by
ć
udokumentowany;
•
Mo
ż
e ró
ż
ni
ć
si
ę
w przydatno
ś
ci w zale
ż
no
ś
ci od przegl
ą
daj
ą
cego;
•
Główny cel: niedrogi sposób uzyskania pewnej korzy
ś
ci.
Przejrzenie
Kluczowe wła
ś
ciwo
ś
ci:
•
Spotkanie prowadzone przez autora;
•
Scenariusze, przegl
ą
dy kodu, grupa kole
ż
e
ń
ska;
•
Otwarte dyskusje;
•
Opcjonalnie: przygotowanie przegl
ą
daj
ą
cych przed spotkaniem, raport z przegl
ą
du,
lista wykrytych rzeczy i protokolant, (który nie jest autorem);
•
W praktyce mo
ż
e by
ć
zró
ż
nicowany od zupełnie nieformalnego do bardzo formalnego;
•
Główne cele: nauka, zrozumienie, znalezienie defektu.
Przegl
ą
d techniczny
Kluczowe wła
ś
ciwo
ś
ci:
•
Udokumentowany, nastawiony na wykrycie bł
ę
dów proces, w którym bior
ą
udział
koledzy i eksperci techniczni;
•
Mo
ż
e by
ć
przeprowadzony jako przegl
ą
d kole
ż
e
ń
ski bez uczestnictwa zarz
ą
du;
•
Idealnie prowadzony przez wyszkolonego moderatora (nie autora);
•
Wst
ę
pne przygotowanie przed spotkaniem;
•
Opcjonalnie: u
ż
ycie list kontrolnych, raportu przegl
ą
du, list wykrytych rzeczy oraz
uczestnictwo zarz
ą
du;
•
W praktyce mo
ż
e by
ć
zró
ż
nicowany od zupełnie nieformalnego do bardzo formalnego;
•
Główne cele: przedyskutowa
ć
, podj
ąć
decyzje, oceni
ć
alternatywy, znale
źć
defekty,
rozwi
ą
za
ć
problemy techniczne oraz sprawdzi
ć
zgodno
ść
ze specyfikacjami i
standardami.
Inspekcja
Kluczowe wła
ś
ciwo
ś
ci:
Certyfikowany tester
Plan poziomu podstawowego
International Sotware Testing Qualifications Board
Stowarzyszenie Jako
ś
ci Systemów Informatycznych
Wersja 1.0
© Stowarzyszenie Jako
ś
ci Systemów
Informatycznych
Strona 33 z 78
20 pa
ź
dziernika 2006
•
Prowadzona przez wyszkolonego moderatora (nie autora);
•
Zwykle wykonywana przez osoby o podobnych do autora kompetencjach;
•
Okre
ś
lone role;
•
Zawiera miary;
•
Formalny proces oparty na regułach oraz listach kontrolnych z kryteriami
wej
ś
ciowymi i warunkami wyj
ś
cia;
•
Wst
ę
pne przygotowanie przed spotkaniem;
•
Raport z inspekcji, lista wykrytych rzeczy;
•
Formalny proces kontroli po wykonaniu napraw;
•
Opcjonalnie: ulepszenie procesu oraz czytelnik;
•
Główny cel: znale
źć
defekty.
3.2.4. Czynniki powodzenia przegl
ą
dów (K2)
O powodzeniu przegl
ą
dów stanowi
ą
nast
ę
puj
ą
ce czynniki:
•
Ka
ż
dy przegl
ą
d ma na pocz
ą
tku jasno okre
ś
lony cel.
•
Do celów przegl
ą
du anga
ż
uje si
ę
wła
ś
ciwe osoby.
•
Znalezione bł
ę
dy przyjmowane s
ą
z rado
ś
ci
ą
i mówi si
ę
o nich obiektywnie.
•
Ma si
ę
do czynienia z wpływami ludzkimi i aspektami psychologicznymi (np. jest to
pozytywnym do
ś
wiadczeniem dla autora).
•
Stosuje si
ę
techniki przegl
ą
dowe, które s
ą
odpowiednie dla typu i poziomu produktów
pracy programowej oraz osób przegl
ą
daj
ą
cych.
•
Je
ś
li stosownym jest zwi
ę
kszy
ć
efektywno
ść
identyfikacji defektu korzysta si
ę
z list
kontrolnych i ról.
•
Stosuje si
ę
szkolenia w technikach przegl
ą
dowych, szczególnie w bardziej
formalnych technikach takich jak inspekcja.
•
Zarz
ą
d popiera dobry proces przegl
ą
du (np. poprzez uwzgl
ę
dnienie odpowiedniego
czasu dla czynno
ś
ci przegl
ą
du w harmonogramach projektu).
•
Kładzie si
ę
nacisk na nauk
ę
i ulepszenie procesu przegl
ą
du.
Certyfikowany tester
Plan poziomu podstawowego
International Sotware Testing Qualifications Board
Stowarzyszenie Jako
ś
ci Systemów Informatycznych
Wersja 1.0
© Stowarzyszenie Jako
ś
ci Systemów
Informatycznych
Strona 34 z 78
20 pa
ź
dziernika 2006
3.3. Analiza statyczna przy pomocy narz
ę
dzi (K2), 20minut
Terminologia
Kompilator, zło
ż
ono
ść
, przepływ sterowania, przepływ danych, analiza statyczna.
Wprowadzenie
Celem analizy statycznej jest wykry
ć
defekt w kodzie
ź
ródłowym oprogramowania lub w
modelach oprogramowania. Analiza statyczna przeprowadzana jest bez równoczesnego
wykonywania badanego oprogramowania przez zewn
ę
trzne narz
ę
dzie (testowanie
dynamiczne wykonuje kod oprogramowania). Analiza statyczna mo
ż
e zlokalizowa
ć
defekty
trudne do wykrycia w innym testowaniu. Tak jak przegl
ą
dy, analiza statyczna wykrywa raczej
defekty ni
ż
awarie. Narz
ę
dzia analizy statycznej analizuj
ą
kod programu (np. przepływ
sterowania i przepływ danych) na tyle skutecznie na ile dobrze generowane jest wyj
ś
cie takie
jak HTML i XML.
Zalety analizy statycznej to:
•
Wczesne wykrycie bł
ę
dów przed wykonaniem testu.
•
Dzi
ę
ki obliczeniu miar, takich jak wysoka warto
ść
miary zło
ż
ono
ś
ci, wczesne
ostrze
ż
enie o podejrzanych aspektach kodu lub projektu.
•
Identyfikacja defektów, których nie daje si
ę
łatwo wykry
ć
podczas testowania
dynamicznego.
•
Wykrycie zale
ż
no
ś
ci i niespójno
ś
ci w modelach oprogramowania takich jak linki.
•
Lepsza zdolno
ść
do piel
ę
gnacji kodu i projektu.
•
Zapobieganie bł
ę
dom, je
ż
eli zdobyto wiedz
ę
podczas tworzenia oprogramowania.
Do typowych bł
ę
dów wykrytych przy pomocy narz
ę
dzi analizy statycznej nale
żą
:
•
Odwołanie si
ę
do zmiennej z nieokre
ś
lon
ą
warto
ś
ci
ą
;
•
Niespójny interfejs pomi
ę
dzy modułami;
•
Zmienne, których nigdy nie u
ż
yto;
•
Nieosi
ą
galny (martwy) kod;
•
Naruszenie standardów programowania;
•
Słabe punkty bezpiecze
ń
stwa;
•
Bł
ę
dy składni kodu i modeli oprogramowania.
Narz
ę
dzia do analizy statycznej u
ż
ywane s
ą
zwykle przez programistów (sprawdzanie
wzgl
ę
dem wcze
ś
niej okre
ś
lonych zasad i standardów programowania) przed i podczas
testowania modułowego i integracyjnego oraz przez projektantów podczas modelowania
oprogramowania. Narz
ę
dzia do analizy statycznej mog
ą
wytworzy
ć
du
żą
liczb
ę
komunikatów
ostrzegawczych. Wymagaj
ą
one dobrego zarz
ą
dzania, aby u
ż
ycie narz
ę
dzia było najbardziej
efektywne.
Kompilatory równie
ż
wykonuj
ą
elementy analizy statycznej, w tym obliczanie miar
dotycz
ą
cych kodu
ź
ródłowego.
Referencje
3.2 IEEE 1028
3.2.2 Gilb,1993, van Veenendaal, 2004
3.2.4 Gilb,1993, IEEE 1028
3.3 Van Veenendaal, 2004
Certyfikowany tester
Plan poziomu podstawowego
International Sotware Testing Qualifications Board
Stowarzyszenie Jako
ś
ci Systemów Informatycznych
Wersja 1.0
© Stowarzyszenie Jako
ś
ci Systemów
Informatycznych
Strona 35 z 78
20 pa
ź
dziernika 2006
4. Techniki projektowania testów (K3), 255 minut
Celem rozdziału „Techniki projektowania testów” jest nauczenie, w
poszczególnych paragrafach:
4.1 Identyfikacja warunków testowych i projektowanie przypadków testowych
(K3)
•
Ró
ż
nic pomi
ę
dzy specyfikacj
ą
projektowania testów, specyfikacj
ą
przypadków
testowych i specyfikacj
ą
procedury testowej. (K1)
•
Poj
ęć
: warunek testowy, przypadek testowy i procedura testowa. (K2)
•
Pisania przypadków testowych: (K3)
o
Pokazuj
ą
cych proste
ś
ledzenie powi
ą
za
ń
z wymaganiami;
o
Zawieraj
ą
cych oczekiwany wynik
•
Tłumaczenia przypadków testowych na poprawnie skonstruowan
ą
specyfikacj
ę
procedury testowej na poziomie szczegółowo
ś
ci odpowiednim dla wiedzy testerów.
(K3)
•
Pisania harmonogramu wykonania testu dla danego zestawu przypadków testowych,
uwzgl
ę
dniaj
ą
c priorytety oraz zale
ż
no
ś
ci techniczne i logiczne. (K3)
4.2 Kategorie technik projektowania testów (K2)
•
Powodów, dla których projektowanie przypadków testowych w oparciu o specyfikacj
ę
(podej
ś
cie czarnoskrzynkowe) i projektowanie przypadków testowych w oparciu o
struktur
ę
(podej
ś
cie białoskrzynkowe) jest u
ż
yteczne oraz pokazania podstawowych
technik dla ka
ż
dego z nich. (K1)
•
Charakterystyk i ró
ż
nic pomi
ę
dzy: testowaniem w oparciu o specyfikacj
ę
,
testowaniem w oparciu o struktur
ę
i testowaniem w oparciu o do
ś
wiadczenia. (K2)
4.3 Techniki testowania w oparciu o specyfikacj
ę
czyli czarnoskrzynkowe (K3)
•
Pisania przypadków testowych dla zadanych modeli oprogramowania wykorzystuj
ą
c
nast
ę
puj
ą
ce techniki projektowania testów: (K3)
o
Podział na klasy równowa
ż
no
ś
ci;
o
Analiza warto
ś
ci brzegowych;
o
Testowanie w oparciu o tablice decyzyjne;
o
Diagramy przej
ść
pomi
ę
dzy stanami.
•
Głównych przyczyn zastosowania ka
ż
dej z czterech technik, jakiego poziomu i typu
testy mog
ą
wykorzystywa
ć
t
ę
technik
ę
i jak mo
ż
na zmierzy
ć
pokrycie. (K2)
•
Koncepcji i zalet testowania w oparciu o przypadki u
ż
ycia. (K2)
4.4 Techniki testowania w oparciu o struktur
ę
lub białoskrzynkowe (K3)
•
Koncepcji i znaczenia pokrycia kodu. (K2)
•
Koncepcji pokrycia instrukcji kodu i pokrycia decyzji oraz,
ż
e koncepcje takie mo
ż
na
wykorzysta
ć
na innych poziomach testów ni
ż
testowanie modułowe (np. na poziomie
systemu w procesach biznesowych). (K2)
•
Napisania przypadków testowych na podstawie podanych przepływów sterowania
wykorzystuj
ą
c nast
ę
puj
ą
ce techniki projektowania testów: (K3)
o
Testowanie instrukcji;
o
Testowanie decyzyjne.
•
Oszacowania pokrycia instrukcji kodu i decyzji po zako
ń
czeniu testów. (K3)
Certyfikowany tester
Plan poziomu podstawowego
International Sotware Testing Qualifications Board
Stowarzyszenie Jako
ś
ci Systemów Informatycznych
Wersja 1.0
© Stowarzyszenie Jako
ś
ci Systemów
Informatycznych
Strona 36 z 78
20 pa
ź
dziernika 2006
4.5 Techniki w oparciu o do
ś
wiadczenie (K2)
•
Powodów napisania przypadków testowych w oparciu o intuicj
ę
, do
ś
wiadczenie i
wiedz
ę
o podstawowych defektach. (K1)
•
Porównywania technik testowania opartych na do
ś
wiadczeniu z technikami w oparciu
o specyfikacj
ę
. (K2)
4.6 Wybór technik testowych (K2)
•
Czynników, które wpływaj
ą
na wybór wła
ś
ciwej techniki projektowania testów dla
szczególnego rodzaju problemu, takiego jak typ systemu, ryzyko, wymagania klienta,
wzorzec modelowania przypadków u
ż
ycia, modele wymaga
ń
lub wiedza testera. (K2)
Certyfikowany tester
Plan poziomu podstawowego
International Sotware Testing Qualifications Board
Stowarzyszenie Jako
ś
ci Systemów Informatycznych
Wersja 1.0
© Stowarzyszenie Jako
ś
ci Systemów
Informatycznych
Strona 37 z 78
20 pa
ź
dziernika 2006
4.1. Identyfikowanie warunków testowych i projektowanie
przypadków testowych (K3), 15 minut
Terminologia
Przypadki testowe, specyfikacja przypadku testowego, warunek testowy, dane testowe,
specyfikacja procedury testowej, skrypt testowy,
ś
ledzenie powi
ą
za
ń
.
Wprowadzenie
Proces identyfikowania warunków testowych i projektowania testów składa si
ę
z kilku kroków:
•
Projektowanie testów przez identyfikowanie warunków testowych.
•
Specyfikowanie przypadków testowych.
•
Specyfikowanie procedur testowych.
Proces mo
ż
na wykona
ć
w ró
ż
noraki sposób, od bardzo nieformalnego z mał
ą
ilo
ś
ci
ą
dokumentacji lub bez niej do bardzo formalnego (jaki został opisany w tej sekcji). Poziom
sformalizowania zale
ż
y od kontekstu testowania, wliczaj
ą
c w to organizacj
ę
, dojrzało
ść
procesów testowania i programowania, ograniczenia czasowe oraz zaanga
ż
owane osoby.
Podczas projektowania testów analizuje si
ę
podstaw
ę
testów, w celu okre
ś
lenia, co testowa
ć
i w celu identyfikacji warunków testowych. Warunek testowy jest definiowany jako element
lub zdarzenie, które powinno by
ć
zweryfikowane przez jeden lub wi
ę
cej przypadków
testowych (np. funkcja, transakcja, cecha lub element konstrukcyjny).
Ustawienie
ś
ledzenia powi
ą
za
ń
pomi
ę
dzy warunkami testowymi a specyfikacj
ą
lub
wymaganiami umo
ż
liwia analiz
ę
wpływu w momencie zmiany wymaga
ń
oraz analiz
ę
pokrycia wymaga
ń
okre
ś
lonym zestawem testów. Podczas projektowania testów
szczegółowe podej
ś
cie testowe jest budowane na podstawie zidentyfikowanego ryzyka
(patrz rozdział 5, gdzie wi
ę
cej o analizie ryzyka).
W czasie specyfikacji przypadków testowych dane i przypadki testowe s
ą
szczegółowo
budowane i opisywane z wykorzystaniem technik projektowania testów. Przypadek testowy
składa si
ę
z zestawu warto
ś
ci wej
ś
ciowych, warunków pocz
ą
tkowych, oczekiwanych
wyników i warunków ko
ń
cowych, zaprojektowanych w celu pokrycia pewnych warunków
testowych. „Standard Dokumentacji Testowej Oprogramowania” („Standard for Software Test
Documentation” IEEE 829) opisuje zawarto
ść
specyfikacji projektowania testów oraz
zawarto
ść
specyfikacji przypadków testowych.
Oczekiwane wyniki powinny powstawa
ć
jako cz
ęść
specyfikacji przypadku testowego i
powinny zawiera
ć
warto
ś
ci wyj
ś
cia, zmiany danych i stanów oraz inne wyniki wykonania
testu. Je
ż
eli oczekiwane wyniki nie b
ę
d
ą
okre
ś
lone wówczas uzyskany wynik, chocia
ż
bł
ę
dny, mo
ż
e by
ć
zinterpretowany jako prawidłowy. W idealnej sytuacji oczekiwane wyniki
powinny by
ć
zawsze okre
ś
lone przed wykonaniem testu.
Przygotowane przypadki testowe układa si
ę
w kolejno
ś
ci wykonywania; jest to specyfikacja
procedury testowej. Procedura ta (lub r
ę
czny skrypt testowy) okre
ś
la kolejno
ść
działa
ń
przy
wykonaniu testu. Je
ż
eli testy przeprowadzane s
ą
z wykorzystaniem narz
ę
dzia wspieraj
ą
cego
wykonanie testu, kolejno
ść
działa
ń
okre
ś
lana jest w skrypcie testowym (który jest
zautomatyzowan
ą
procedur
ą
testow
ą
).
Ró
ż
ne procedury testowe i zautomatyzowane skrypty testowe s
ą
nast
ę
pnie wstawiane w
harmonogram wykonania testu, który okre
ś
la kolejno
ść
ich wykonania, oraz kiedy i przez
kogo maj
ą
by
ć
one wykonane. W harmonogramie wykonania testu bierze si
ę
pod uwag
ę
takie czynniki jak testy regresywne, priorytety, zale
ż
no
ś
ci techniczne i logiczne.
Certyfikowany tester
Plan poziomu podstawowego
International Sotware Testing Qualifications Board
Stowarzyszenie Jako
ś
ci Systemów Informatycznych
Wersja 1.0
© Stowarzyszenie Jako
ś
ci Systemów
Informatycznych
Strona 38 z 78
20 pa
ź
dziernika 2006
4.2. Kategorie technik projektowania testów (K2), 15 minut
Terminologia
Techniki czarnoskrzynkowe, techniki oparte na do
ś
wiadczeniu, techniki oparte na
specyfikacji, techniki oparte na strukturze, techniki białoskrzynkowe.
Wprowadzenie
Celem techniki projektowania testów jest zidentyfikowanie warunków testowych i
przypadków testowych.
Klasycznym podziałem technik testowych jest podział na technik
ę
czarnoskrzynkow
ą
i
technik
ę
białoskrzynkow
ą
. Techniki czarnoskrzynkowe (zwane równie
ż
technikami opartymi
na specyfikacji) znajduj
ą
i wybieraj
ą
warunki i przypadki testowe na podstawie analizy
dokumentacji (podstawy testów) zarówno funkcjonalnej jak i niefunkcjonalnej bez
odwoływania si
ę
do jego wewn
ę
trznej struktury. Techniki białoskrzynkowe (zwane równie
ż
technikami strukturalnymi lub opartymi na strukturze) oparte s
ą
na analizie wewn
ę
trznej
struktury modułu lub systemu.
Pewne techniki mieszcz
ą
si
ę
wyra
ź
nie w jednej kategorii; inne maj
ą
elementy z wi
ę
cej ni
ż
jednej kategorii. Konspekt ten odnosi si
ę
do podej
ść
opartych na specyfikacji i opartych na
do
ś
wiadczeniu jako technik czarnoskrzynkowych oraz do podej
ś
cia opartego na strukturze
jako techniki białoskrzynkowej.
Podstawowe cechy technik opartych na specyfikacji:
•
Modele formalne lub nieformalne s
ą
wykorzystywane do specyfikowania
rozwi
ą
zywanych problemów, systemu lub jego modułów.
•
Przypadki testowe mog
ą
by
ć
wytwarzane systematycznie na podstawie modeli.
Podstawowe cechy technik opartych na strukturze:
•
Przypadki testowe pochodz
ą
z informacji o tym jak skonstruowane jest
oprogramowanie, na przykład z kodu lub projektu.
•
Dla istniej
ą
cych przypadków testowych mo
ż
na mierzy
ć
stopie
ń
pokrycia
oprogramowania i mo
ż
na systematycznie tworzy
ć
kolejne przypadki testowe w celu
poprawienia pokrycia.
Podstawowe cechy technik opartych na do
ś
wiadczeniu:
•
Do tworzenia przypadków testowych wykorzystuje si
ę
wiedz
ę
i do
ś
wiadczenie osób.
•
Wiedza testerów, programistów, u
ż
ytkowników i innych interesariuszy na temat
oprogramowania, jego wykorzystywania i
ś
rodowiska;
•
Wiedza o podobnych defektach i ich dystrybucji.
Certyfikowany tester
Plan poziomu podstawowego
International Sotware Testing Qualifications Board
Stowarzyszenie Jako
ś
ci Systemów Informatycznych
Wersja 1.0
© Stowarzyszenie Jako
ś
ci Systemów
Informatycznych
Strona 39 z 78
20 pa
ź
dziernika 2006
4.3. Techniki na podstawie specyfikacji lub czarnoskrzynkowe (K3),
120 minut
Terminologia
Analiza warto
ś
ci brzegowych, testowanie w oparciu o tablic
ę
decyzyjn
ą
, podział na klasy
równowa
ż
no
ś
ci, testowanie przej
ść
pomi
ę
dzy stanami, testowanie w oparciu o przypadki
u
ż
ycia.
4.3.1. Podział na klasy równowa
ż
no
ś
ci (K3)
Elementy wej
ś
ciowe do oprogramowania lub systemu dzieli si
ę
na grupy o podobnym
charakterze - prawdopodobnie b
ę
d
ą
one przetwarzane przez system w ten sam sposób.
Klasy równowa
ż
no
ś
ci mo
ż
na znale
źć
zarówno dla danych poprawnych jak i niepoprawnych,
tzn. warto
ś
ci, które powinny by
ć
odrzucone. Klasy równowa
ż
no
ś
ci mo
ż
na zidentyfikowa
ć
dla
warto
ś
ci wyj
ś
cia, warto
ś
ci wewn
ę
trznych, warto
ś
ci zale
ż
nych od czasu (np. przed lub po
jakim
ś
zdarzeniu) oraz dla parametrów interfejsów (np. podczas testowania integracyjnego).
Testy mo
ż
na tak zaprojektowa
ć
, aby pokry
ć
klasy równowa
ż
no
ś
ci. Podział na klasy
równowa
ż
no
ś
ci (KR) daje si
ę
stosowa
ć
na wszystkich poziomach testowania.
Klas równowa
ż
no
ś
ci jako techniki mo
ż
na u
ż
ywa
ć
, aby osi
ą
gn
ąć
pokrycie danych
wej
ś
ciowych i wyj
ś
ciowych. Mo
ż
na j
ą
równie
ż
stosowa
ć
w przypadku elementów
wprowadzanych przez człowieka, elementów wprowadzanych do systemu poprzez interfejsy
lub parametrów interfejsowych w testowaniu integracyjnym.
4.3.2. Analiza warto
ś
ci brzegowych (K3)
Maksymalne i minimalne warto
ś
ci klasy równowa
ż
no
ś
ci s
ą
jej warto
ś
ciami brzegowymi.
Istnieje mo
ż
liwo
ść
,
ż
e zachowanie na kraw
ę
dzi ka
ż
dej klasy równowa
ż
no
ś
ci b
ę
dzie
nieprawidłowe, a wi
ę
c brzegi s
ą
miejscem, gdzie testowanie prawdopodobnie wykryje
defekty. Warto
ść
brzegowa dla poprawnej klasy równowa
ż
no
ś
ci jest dozwolon
ą
warto
ś
ci
ą
brzegow
ą
; brzeg niepoprawnej klasy równowa
ż
no
ś
ci jest niepoprawn
ą
warto
ś
ci
ą
brzegow
ą
.
Testy mog
ą
by
ć
projektowane w celu osi
ą
gni
ę
cia pokrycia zarówno poprawnych jak i
niepoprawnych warto
ś
ci brzegowych. Projektuj
ą
c przypadki testowe wybierane s
ą
wszystkie
warto
ś
ci brzegowe.
Analiz
ę
warto
ś
ci brzegowych mo
ż
na wykorzystywa
ć
na wszystkich poziomach testów. Jest
ona łatwa w stosowaniu i posiada du
żą
zdolno
ść
znajdowania bł
ę
dów. W technice tej
pomocne s
ą
szczegółowe specyfikacje.
Technika warto
ś
ci brzegowych cz
ę
sto jest uwzgl
ę
dniana jako rozszerzenie techniki klas
równowa
ż
no
ś
ci i mo
ż
e by
ć
wykorzystywana zarówno dla elementów wprowadzanych przez
człowieka jak i dla elementów z zale
ż
no
ś
ciami czasowymi lub elementów tablicowych.
Warto
ś
ci brzegowe mog
ą
by
ć
równie
ż
wykorzystane do okre
ś
lania danych testowych.
4.3.3. Testowanie w oparciu o tablic
ę
decyzyjn
ą
(K3)
Tablice decyzyjne to dobry sposób na wychwycenie wymaga
ń
zawieraj
ą
cych warunki
logiczne i udokumentowanie wewn
ę
trznego projektu systemu. Mo
ż
na ich u
ż
y
ć
do zapisania
zło
ż
onych reguł biznesowych, które system musi implementowa
ć
. Analizuje si
ę
specyfikacj
ę
,
identyfikuj
ą
c warunki i akcje systemu. Warunki wej
ś
ciowe i akcje ustawia si
ę
najcz
ęś
ciej w
taki sposób, aby mogły odzwierciedla
ć
prawd
ę
lub fałsz (Boolean). Tablica decyzyjna
zawiera warunki przeł
ą
czania, cz
ę
sto kombinacje prawdy i fałszu, dla wszystkich warunków
wej
ś
ciowych oraz wynikaj
ą
ce z nich akcje. Ka
ż
da kolumna tablicy odpowiada regule
Certyfikowany tester
Plan poziomu podstawowego
International Sotware Testing Qualifications Board
Stowarzyszenie Jako
ś
ci Systemów Informatycznych
Wersja 1.0
© Stowarzyszenie Jako
ś
ci Systemów
Informatycznych
Strona 40 z 78
20 pa
ź
dziernika 2006
biznesowej, która okre
ś
la unikaln
ą
kombinacj
ę
warunków, które w rezultacie daj
ą
wykonanie
wszystkich akcji zwi
ą
zanych z t
ą
reguł
ą
. Podstawowym pokryciem wykorzystywanym w
testowaniu w oparciu o tablice decyzyjne jest przynajmniej jeden test dla ka
ż
dej z kolumn,
który zwykle wymaga pokrycia wszystkich kombinacji warunków wyzwalaj
ą
cych.
Siła testowania w oparciu o tablic
ę
decyzyjn
ą
polega na tym,
ż
e tworzy si
ę
kombinacje
warunków, które w inny sposób mogłyby nie by
ć
przetestowane. Testowanie to mo
ż
e by
ć
stosowane we wszystkich sytuacjach, kiedy działanie oprogramowania zale
ż
y od kilku
decyzji logicznych.
4.3.4. Testowanie przej
ść
pomi
ę
dzy stanami (K3)
System mo
ż
e dawa
ć
ró
ż
n
ą
odpowied
ź
w zale
ż
no
ś
ci od bie
żą
cych warunków lub jego historii
(jego stanu). W takim przypadku system mo
ż
na przedstawi
ć
jako diagram przej
ść
pomi
ę
dzy
stanami. Pozwala to testerowi widzie
ć
oprogramowanie w kategoriach jego stanów, przej
ść
pomi
ę
dzy stanami, wej
ść
lub zdarze
ń
, które wyzwalaj
ą
zmiany stanów (przej
ś
cia) i akcji,
które mog
ą
wynika
ć
z tych przej
ść
. Stany systemu lub testowanego obiektu s
ą
rozdzielne,
identyfikowalne i policzalne. Tablica stanów pokazuje zwi
ą
zek pomi
ę
dzy stanami a wej
ś
ciami
i mo
ż
e wskaza
ć
na przej
ś
cia, które s
ą
niedozwolone. Testy mog
ą
by
ć
projektowane w taki
sposób, aby pokry
ć
ka
ż
dy stan, wykona
ć
ka
ż
de przej
ś
cie, wykona
ć
specyficzne sekwencje
przej
ść
lub przetestowa
ć
przej
ś
cia niedozwolone.
Testowanie przej
ść
pomi
ę
dzy stanami wykorzystywane jest w przemy
ś
le tworz
ą
cym
oprogramowanie wbudowane oraz w automatyce. Technika ta jest równie
ż
odpowiednia dla
modelowania obiektu biznesowego maj
ą
cego specyficzne stany lub testowania przepływów
okien dialogowych (np. dla aplikacji internetowych lub scenariuszy biznesowych).
4.3.5. Testowanie w oparciu o przypadki u
ż
ycia (K2)
Testy mog
ą
by
ć
specyfikowane w oparciu o scenariusze biznesowe lub przypadki u
ż
ycia.
Przypadek u
ż
ycia opisuje interakcj
ę
pomi
ę
dzy aktorami (u
ż
ytkownikami) i systemem, która
produkuje warto
ść
wynikow
ą
dla u
ż
ytkownika. Ka
ż
dy przypadek u
ż
ycia posiada warunki
pocz
ą
tkowe, które musz
ą
by
ć
spełnione, aby przypadek zako
ń
czył si
ę
powodzeniem. Ka
ż
dy
przypadek u
ż
ycia ko
ń
czy si
ę
warunkami ko
ń
cowymi, które s
ą
wynikiem po jego wykonaniu i
stanem ko
ń
cowym systemu. Przypadek u
ż
ycia ma scenariusz główny (najbardziej
prawdopodobny) a czasami gał
ę
zie alternatywne.
Przypadki u
ż
ycia opisuj
ą
„przepływy procesów” przez system, bazuj
ą
c na jego mo
ż
liwym
u
ż
yciu. Zatem przypadki testowe powstaj
ą
ce z przypadków u
ż
ycia s
ą
bardzo przydatne w
wyszukiwaniu niewykrytych defektów w rzeczywistych przepływach procesów
wykonywanych w systemie.
Przypadki u
ż
ycia, maj
ą
ce zwi
ą
zek ze scenariuszami, s
ą
bardzo u
ż
yteczne w projektowaniu
testów akceptacyjnych z udziałem klienta/u
ż
ytkownika. Pomagaj
ą
równie
ż
wykry
ć
defekty
integracji powodowane przez współprac
ę
lub kolidowanie ró
ż
nych modułów, a niewykryte
przez indywidualne testy ka
ż
dego z modułów.
Certyfikowany tester
Plan poziomu podstawowego
International Sotware Testing Qualifications Board
Stowarzyszenie Jako
ś
ci Systemów Informatycznych
Wersja 1.0
© Stowarzyszenie Jako
ś
ci Systemów
Informatycznych
Strona 41 z 78
20 pa
ź
dziernika 2006
4.4. Techniki na podstawie struktury lub białoskrzynkowe (K3), 60
minut
Terminologia
Pokrycie kodu, pokrycie decyzji, pokrycie instrukcji kodu, testowanie strukturalne, testowanie
na podstawie struktury, testowanie białoskrzynkowe.
Wprowadzenie
Testowanie na podstawie struktury/testowanie białoskrzynkowe opiera si
ę
na
zidentyfikowanej strukturze oprogramowania lub systemu, jak pokazano w poni
ż
szych
przykładach:
•
Poziom modułu: struktur
ą
jest kod, tzn. instrukcje, decyzje i rozgał
ę
zienia.
•
Poziom integracji: struktur
ą
mo
ż
e by
ć
drzewo wywoła
ń
(diagram, w którym moduły
wołaj
ą
inne moduły).
•
Poziom systemu: struktur
ą
mo
ż
e by
ć
struktura menu, proces biznesowy, struktura
strony WWW.
W sekcji tej przedyskutowano dwie techniki strukturalne dla pokrycia kodu bazuj
ą
ce na
instrukcjach i decyzjach. Dla testowania decyzyjnego, aby pokaza
ć
alternatywy ka
ż
dej
decyzji, mo
ż
na u
ż
y
ć
diagramu przepływu sterowania.
4.4.1. Testowanie instrukcji i pokrycie (K3)
W testowaniu modułowym, pokrycie instrukcji kodu jest procentow
ą
ocen
ą
wykonywalnych
instrukcji, które zostały wykonane przez zestaw przypadków testowych. W testowaniu
instrukcji przypadki testowe projektuje si
ę
tak, aby wykona
ć
okre
ś
lone instrukcje - zwi
ę
kszy
ć
pokrycie instrukcji kodu.
4.4.2. Testowanie decyzyjne i pokrycie (K3)
Pokrycie decyzji, w odniesieniu do testowania rozgał
ę
zie
ń
, jest procentow
ą
ocen
ą
rezultatów
decyzyjnych (opcji Prawda i Fałsz z instrukcji IF), które zostały wykonane przez zestaw
przypadków testowych. W testowaniu decyzyjnym przypadki testowe projektuje si
ę
tak, aby
uzyska
ć
okre
ś
lone rezultaty decyzyjne – zwi
ę
kszy
ć
pokrycie decyzji.
Testowanie decyzyjne jest rodzajem testowania przepływu sterowania, poniewa
ż
generuje
okre
ś
lony przepływ sterowania przez punkty decyzyjne. Pokrycie decyzji jest silniejsze ni
ż
pokrycie instrukcji kodu: 100% pokrycie decyzji gwarantuje 100% pokrycie instrukcji kodu,
ale nie odwrotnie.
4.4.3. Inne techniki na podstawie struktury (K1)
Istniej
ą
lepsze poziomy pokrycia strukturalnego poza pokryciem decyzyjnym, np. pokrycie
warunków i pokrycie warunków wielokrotnych.
Koncepcja pokrycia mo
ż
e by
ć
równie
ż
stosowana na innych poziomach testów (np. na
poziomie integracji), gdzie procent modułów lub klas, które zostały sprawdzone przez zestaw
przypadków testowych, mo
ż
e wyra
ż
a
ć
pokrycie modułów lub klas.
W testowaniu strukturalnym przydatne jest wsparcie narz
ę
dziowe.
Certyfikowany tester
Plan poziomu podstawowego
International Sotware Testing Qualifications Board
Stowarzyszenie Jako
ś
ci Systemów Informatycznych
Wersja 1.0
© Stowarzyszenie Jako
ś
ci Systemów
Informatycznych
Strona 42 z 78
20 pa
ź
dziernika 2006
4.5. Techniki oparte na do
ś
wiadczeniu (K2), 30 minut
Terminologia
Zgadywanie bł
ę
dów, testowanie eksploracyjne.
Wprowadzenie
Najbardziej rozpowszechnion
ą
technik
ą
testowania jest zgadywanie bł
ę
dów. Testy tworzone
s
ą
na podstawie umiej
ę
tno
ś
ci, intuicji i do
ś
wiadczenia testerów z podobnymi aplikacjami i
technologiami. Testowanie intuicyjne, wykorzystane do uzupełnienia technik
systematycznych, mo
ż
e by
ć
przydatne do wykonania specjalnych testów trudno
wykonalnych przez techniki formalne (zwłaszcza, gdy stosowane jest po bardziej formalnych
podej
ś
ciach). Jednak
ż
e technika ta mo
ż
e znacznie ró
ż
ni
ć
si
ę
efektywno
ś
ci
ą
, zale
ż
n
ą
od
do
ś
wiadczenia testerów. Uporz
ą
dkowanym podej
ś
ciem dla techniki zgadywania bł
ę
dów jest
sporz
ą
dzenie wykazu mo
ż
liwych bł
ę
dów i takie zaprojektowanie testów, aby je znale
źć
.
Wykazy defektów i awarii mog
ą
by
ć
budowane na podstawie do
ś
wiadczenia testerów,
dost
ę
pnych danych o defektach i awariach oraz ogólnej wiedzy, dlaczego oprogramowanie
ulega awariom.
Testowanie eksploracyjne jest równoczesnym projektowaniem, wykonywaniem, logowaniem
testu oraz nauk
ą
, opartymi na karcie testu zawieraj
ą
cej cele testu i ramy czasowe ich
wykonania. Podej
ś
cie to jest u
ż
yteczne w przypadku niepełnej lub nieodpowiedniej
specyfikacji, nacisków na skrócenie czasu testowania, lub dla poszerzenia i uzupełnienia
bardziej formalnego testowania. Technika ta mo
ż
e słu
ż
y
ć
jako sprawdzenie procesu
testowego, aby upewni
ć
si
ę
,
ż
e najpowa
ż
niejsze defekty zostały wykryte.
Certyfikowany tester
Plan poziomu podstawowego
International Sotware Testing Qualifications Board
Stowarzyszenie Jako
ś
ci Systemów Informatycznych
Wersja 1.0
© Stowarzyszenie Jako
ś
ci Systemów
Informatycznych
Strona 43 z 78
20 pa
ź
dziernika 2006
4.6. Wybór technik testowych (K2), 15 minut
Terminologia
Brak szczególnych poj
ęć
.
Wprowadzenie
Wybór technik testowych zale
ż
y od szeregu czynników, wliczaj
ą
c w to typ systemu,
obowi
ą
zuj
ą
ce standardy, wymagania umowy lub klienta, poziom ryzyka, typ ryzyka, cel testu,
dost
ę
pn
ą
dokumentacj
ę
, do
ś
wiadczenie testerów, czas i bud
ż
et, cykl
ż
ycia projektu, modele
przypadków u
ż
ycia oraz wiedza o rodzajach znalezionych wcze
ś
niej bł
ę
dów.
Pewne techniki daj
ą
si
ę
stosowa
ć
dla okre
ś
lonych sytuacji i poziomów testów; inne mo
ż
na
stosowa
ć
na ka
ż
dym poziomie testów.
Referencje:
4.1 Craig, 2002, Hetzel, 1998, IEEE 829
4.2 Beizer, 1990, Copeland, 2004
4.3.1 Copeland, 2004, Myers, 1979
4.3.2 Copeland, 2004, Myers, 1979
4.3.3 Beizer, 1990, Copeland, 2004
4.3.4 Beizer, 1990, Copeland, 2004
4.3.5 Copeland, 2004
4.4.3 Beizer, 1990, Copeland, 2004
4.5 Kaner, 2002
4.6 Beizer, 1990, Copeland, 2004
Certyfikowany tester
Plan poziomu podstawowego
International Sotware Testing Qualifications Board
Stowarzyszenie Jako
ś
ci Systemów Informatycznych
Wersja 1.0
© Stowarzyszenie Jako
ś
ci Systemów
Informatycznych
Strona 44 z 78
20 pa
ź
dziernika 2006
5. Zarz
ą
dzanie testowaniem (K3), 180 minut
Celem rozdziału „Zarz
ą
dzanie testowaniem” jest nauczenie, w
poszczególnych paragrafach:
5.1 Organizacja testowania (K2)
•
Znaczenia niezale
ż
nego testowania. (K1)
•
Zalet i wad niezale
ż
nego testowania w organizacji. (K2)
•
Jakie osoby powinny wchodzi
ć
w skład zespołu testowego. (K1)
•
Typowych zada
ń
kierownika testów i testera. (K1)
5.2 Planowanie i oszacowanie pracochłonno
ś
ci testów (K2)
•
Ró
ż
nych poziomów oraz celów planowania testów. (K1)
•
Celu i zawarto
ś
ci planu testów, specyfikacji projektu testów oraz procedury testowej
wg definicji z normy „Norma Dokumentacji Testowej” (Standard for Software Test
Documentation, IEEE 829). (K2)
•
Typowych czynników wpływaj
ą
cych na wysiłek zwi
ą
zany z testowaniem. (K1)
•
Ró
ż
nic w dwóch sposobach podej
ś
cia do oszacowania pracochłonno
ś
ci testowania:
na podstawie danych pomiarowych oraz na podstawie oceny eksperckiej. (K2)
•
Okre
ś
lenia zakresu planowania testów dla projektu, dla poszczególnych poziomów
testów (np. dla testu systemowego), dla okre
ś
lonych celów (np. testy u
ż
yteczno
ś
ci)
oraz dla wykonywania testów. (K2)
•
Czynno
ś
ci wchodz
ą
cych w skład przygotowywania i wykonywania testów, które
wymagaj
ą
planowania. (K1)
•
Uzasadnienia odpowiednich warunków wyj
ś
cia dla okre
ś
lonych poziomów testów lub
grup przypadków testowych (np. przypadków testowych dla testów integracyjnych,
testów akceptacyjnych lub testów u
ż
yteczno
ś
ci). (K2)
5.3 Monitorowanie i nadzorowanie procesu testowego (K2)
•
Jakie typowe metryki stosuje si
ę
do monitorowania przygotowywania i wykonywania
testów.
•
Interpretacji metryk dotycz
ą
cych raportowania i nadzorowania testów (np. liczba
znalezionych i naprawionych bł
ę
dów, wykonanych zaliczonych i niezaliczonych
testów). (K2)
•
Celu i tre
ś
ci ko
ń
cowego raportu testowego wg definicji z normy „Norma Dokumentacji
Testowej” (Standard for Software Test Documentation, IEEE 829). (K2)
5.4 Zarz
ą
dzanie konfiguracj
ą
(K2)
•
W jaki sposób zarz
ą
dzanie konfiguracj
ą
wspiera testowanie.
5.5 Ryzyko a testowanie (K2)
•
Ryzyka jako mo
ż
liwego problemu, zagra
ż
aj
ą
cego osi
ą
gni
ę
ciu celów jednego lub
wielu interesariuszy projektu. (K2)
•
ś
e ryzyko okre
ś
la prawdopodobie
ń
stwo wyst
ą
pienia zdarzenia oraz jego
konsekwencje (koszty wyst
ą
pienia ryzyka). (K1)
•
Ró
ż
nic mi
ę
dzy ryzykami projektowymi oraz ryzykami odnosz
ą
cymi si
ę
do produktu.
•
Rozpoznawania typowych zagro
ż
e
ń
dotycz
ą
cych produktu i projektu.
•
Jak analiza i planowanie ryzyka mog
ą
by
ć
wykorzystane do planowania testów. (K2)
Certyfikowany tester
Plan poziomu podstawowego
International Sotware Testing Qualifications Board
Stowarzyszenie Jako
ś
ci Systemów Informatycznych
Wersja 1.0
© Stowarzyszenie Jako
ś
ci Systemów
Informatycznych
Strona 45 z 78
20 pa
ź
dziernika 2006
5.6 Zarz
ą
dzanie incydentami (K3)
•
Tre
ś
ci zgłoszenia incydentu wg normy „Norma Dokumentacji Testowej” (Standard for
Software Test Documentation, IEEE 829). (K1)
•
Pisania zgłoszenia incydentu dotycz
ą
cego awarii zaobserwowanej w trakcie
testowania. (K3)
Certyfikowany tester
Plan poziomu podstawowego
International Sotware Testing Qualifications Board
Stowarzyszenie Jako
ś
ci Systemów Informatycznych
Wersja 1.0
© Stowarzyszenie Jako
ś
ci Systemów
Informatycznych
Strona 46 z 78
20 pa
ź
dziernika 2006
5.1. Organizacja testowania (K2), 30 minut
Terminologia
Tester, kierownik testów, mened
ż
er testów.
5.1.1. Organizacja i niezale
ż
no
ść
testowania (K2)
Skuteczno
ść
znajdowania bł
ę
dów drog
ą
testowania i przegl
ą
dów mo
ż
na podnie
ść
wykorzystuj
ą
c niezale
ż
nych testerów. Istniej
ą
nast
ę
puj
ą
ce formy niezale
ż
nego testowania:
•
Niezale
ż
ni testerzy w zespołach programistów.
•
Niezale
ż
ny zespół albo grupa testowa w organizacji, podlegaj
ą
ca kierownictwu
projektu albo kierownictwu przedsi
ę
biorstwa.
•
Niezale
ż
ni testerzy z działu biznesowego, przedstawicieli u
ż
ytkowników ko
ń
cowych
oraz działu informatyki.
•
Niezale
ż
ni specjali
ś
ci testowi dla okre
ś
lonych celów, tacy jak testerzy u
ż
yteczno
ś
ci,
testerzy zabezpiecze
ń
lub testerzy certyfikacyjni, testuj
ą
cy oprogramowanie pod
k
ą
tem zgodno
ś
ci z normami i innymi regulacjami prawnymi.
Dla du
ż
ych, zło
ż
onych projektów lub w zespołach wytwarzaj
ą
cych produkty krytyczne pod
wzgl
ę
dem bezpiecze
ń
stwa, zwykle najkorzystniejsze jest testowanie na wielu poziomach,
gdzie pewne poziomy testowania wykonywane s
ą
przez niezale
ż
nych testerów. Deweloperzy
mog
ą
uczestniczy
ć
w testowaniu, zwłaszcza na ni
ż
szych poziomach, ale ich brak
obiektywno
ś
ci ogranicza ich skuteczno
ść
. Niezale
ż
ni testerzy mog
ą
uzyska
ć
upowa
ż
nienie
do domagania si
ę
oraz definiowania procesów i procedur testowych, ale tego rodzaju
żą
dania dotycz
ą
ce procesu powinny by
ć
przez nich podejmowane tylko pod warunkiem
uzyskania jednoznacznego upowa
ż
nienia ze strony kierownictwa.
Korzy
ś
ci niezale
ż
no
ś
ci to:
•
Niezale
ż
ni testerzy dostrzegaj
ą
cz
ę
sto inne bł
ę
dy ni
ż
dostrze
ż
one przez
konstruktorów, a ponadto podchodz
ą
do testowanego oprogramowania bez gotowych
oczekiwa
ń
i uprzedze
ń
.
•
Niezale
ż
ny tester mo
ż
e tak
ż
e zweryfikowa
ć
poprawno
ść
zało
ż
e
ń
, których dokonano
podczas specyfikacji oraz implementacji systemu.
Wady niezale
ż
no
ś
ci to:
•
Odizolowanie testerów od zespołu deweloperów (gdy niezale
ż
no
ść
jest zupełna).
•
Niezale
ż
ni testerzy mog
ą
sta
ć
si
ę
w
ą
skim gardłem projektu, gdy spoczywa na nich
odpowiedzialno
ść
za ostateczn
ą
kontrol
ę
produktu.
•
Deweloperzy mog
ą
utraci
ć
poczucie współodpowiedzialno
ś
ci za jako
ść
.
Zadania testowe bywaj
ą
wykonywane przez osoby maj
ą
ce przypisan
ą
rol
ę
testerów, lub
przez inne osoby, na przykład przez kierownika projektu, kierownika jako
ś
ci, dewelopera,
specjalist
ę
biznesowego i dziedzinowego, eksperta z działu informatyki lub
odpowiedzialnego za infrastruktur
ę
.
5.1.2. Zadania kierownika testów i testera (K1)
Niniejszy plan omawia dwie role zwi
ą
zane z testowaniem: kierownika testów oraz testera.
Czynno
ś
ci i zadania wykonywane przez osoby wykonuj
ą
ce te dwie role zale
żą
od formy
projektu i rodzaju produktu, od osób realizuj
ą
cych te role oraz od specyfiki organizacyjnej.
Czasem kierownik testów bywa nazywany mened
ż
erem lub koordynatorem testów. Funkcj
ę
kierownika testów mo
ż
e wykonywa
ć
kierownik projektu, kierownik zespołu programistów,
kierownik jako
ś
ci albo mened
ż
er zespołu testowego. W du
ż
ych projektach mog
ą
Certyfikowany tester
Plan poziomu podstawowego
International Sotware Testing Qualifications Board
Stowarzyszenie Jako
ś
ci Systemów Informatycznych
Wersja 1.0
© Stowarzyszenie Jako
ś
ci Systemów
Informatycznych
Strona 47 z 78
20 pa
ź
dziernika 2006
wyst
ę
powa
ć
obie role: kierownika i mened
ż
era testów. Kierownik testów zwykle planuje,
monitoruje i nadzoruje czynno
ś
ci i zadania testowe w sposób opisany w cz
ęś
ci 1.4.
Zwykle spotykane zadania kierownika testów to:
•
Koordynowanie strategii i planu testów z kierownikami projektów i innymi
interesariuszami.
•
Stworzenie lub dokonanie przegl
ą
du strategii testowej dla projektu, a polityki testowej
dla organizacji.
•
Dbało
ść
o uwzgl
ę
dnienie aspektów testowych w innych obszarach projektu, np. w
planowaniu integracji.
•
Planowanie testowania – z uwzgl
ę
dnieniem kontekstu i ryzyka. Planowanie obejmuje
wybór metodyk testowania, oszacowanie czasochłonno
ś
ci, wysiłku oraz kosztów
testowania, uzyskanie odpowiednich zasobów, okre
ś
lenie poziomów, cykli, metod
oraz celów testowania, a tak
ż
e zaplanowanie zarz
ą
dzania zgłoszeniami zdarze
ń
.
•
Zainicjowanie i nadzorowanie specyfikacji, przygotowania oraz implementacji testów,
a w szczególno
ś
ci monitorowanie i nadzorowanie ich wykonywania,
•
Ustawienie odpowiedniego poziomu zarz
ą
dzania konfiguracj
ą
,
•
Wprowadzenie odpowiednich metryk, by mierzy
ć
post
ę
p testowania i okre
ś
la
ć
jako
ść
testowania i produktu
•
Okre
ś
lenie zakresu i stopnia automatyzacji.
•
Wybór narz
ę
dzi wspieraj
ą
cych testowanie oraz zorganizowanie niezb
ę
dnych szkole
ń
narz
ę
dziowych.
•
Podj
ę
cie decyzji dotycz
ą
cych
ś
rodowiska testowego.
•
Sporz
ą
dzenie harmonogramu testowania.
•
Sporz
ą
dzanie ko
ń
cowych raportów testowych na podstawie informacji
zgromadzonych podczas wykonywania testów.
Typowe zadania testera obejmuj
ą
:
•
Przegl
ą
danie i wnoszenie wkładu do planu testów
•
Analiza, przegl
ą
d i dost
ę
p do wymaga
ń
u
ż
ytkownika, specyfikacji oraz modeli
testowalno
ś
ci
•
Tworzenie
ś
rodowiska testowego (cz
ę
sto we współpracy z administracj
ą
systemu i
zarz
ą
dzaj
ą
cymi sieci
ą
)
•
Przygotowanie i pozyskiwanie danych testowych
•
Implementacja testów na wszystkich poziomach, wykonywanie testów, zapisywanie
wyników do dziennika (logu) testów, porównywanie wyników i dokumentowanie
odchyle
ń
od spodziewanego wyniku
•
U
ż
ywanie – w razie potrzeby - narz
ę
dzi do administrowania lub zarz
ą
dzania testami,
•
Automatyzacja testów (w razie potrzeby we współpracy z deweloperami lub
ekspertami od automatyzacji testów)
•
Mierzenie wydajno
ś
ci modułów lub systemów – je
ś
li ma to zastosowanie
•
Przegl
ą
danie testów zaprojektowanych przez innych
Osoby, które pracuj
ą
przy analizie testów, projektowaniu testów, testach specyficznych
typów lub automatyzacji testów powinny by
ć
specjalistami w swych rolach. W zale
ż
no
ś
ci od
poziomu testów i ryzyka zwi
ą
zanego z produktem lub projektem, ró
ż
ni ludzie mog
ą
pracowa
ć
jako testerzy, zachowuj
ą
c pewien stopie
ń
niezale
ż
no
ś
ci. Na ogół, na poziomie modułów i
integracji, testerami mog
ą
by
ć
deweloperzy, przy testach akceptacyjnych mog
ą
to by
ć
eksperci biznesowi lub u
ż
ytkownicy, przy akceptacji operacyjnej testerami powinni by
ć
operatorzy systemu.
Certyfikowany tester
Plan poziomu podstawowego
International Sotware Testing Qualifications Board
Stowarzyszenie Jako
ś
ci Systemów Informatycznych
Wersja 1.0
© Stowarzyszenie Jako
ś
ci Systemów
Informatycznych
Strona 48 z 78
20 pa
ź
dziernika 2006
5.2. Planowanie testowania (K2), 50 minut
Terminologia
Kryteria wej
ś
cia, kryteria wyj
ś
cia, testowanie eksploracyjne, metodyka testowa, poziom
testowy, plan testów, procedura testów, strategia testowa.
5.2.1. Planowanie testowania (K2)
Niniejsza sekcja po
ś
wi
ę
cona jest planowaniu testowania w projektach wytwarzania,
implementacji oraz utrzymania oprogramowania. Planowanie mo
ż
e by
ć
udokumentowane w
planie testów projektu lub w głównym planie testów, a tak
ż
e w odr
ę
bnych planach testów dla
poszczególnych poziomów, np. dla testu systemowego lub testu akceptacyjnego. Wzorce
dokumentacji planów testów znajduj
ą
si
ę
w Standard for Software Test Documentation (IEEE
829).
Na planowanie wpływa: polityka testów w organizacji, zakres testowania, cele, zagro
ż
enia,
ograniczenia, krytyczno
ść
, łatwo
ść
testowania i dost
ę
pno
ść
zasobów. Im dalej posuwa si
ę
planowanie projektu i testowania, tym wi
ę
cej informacji jest do dyspozycji i tym bardziej
szczegółowy staje si
ę
plan.
Planowanie jest stał
ą
czynno
ś
ci
ą
i wykonuje si
ę
je we wszystkich procesach i fazach cyklu
ż
yciowego oprogramowania. Informacja zwrotna z realizacji planu testów umo
ż
liwia
identyfikacj
ę
zmieniaj
ą
cego si
ę
ryzyka, co pozwala na dostosowywanie planu.
5.2.2. Czynno
ś
ci wykonywane podczas planowania testów (K2)
W trakcie planowania testów mog
ą
by
ć
wykonywane nast
ę
puj
ą
ce czynno
ś
ci:
•
Okre
ś
lenia ogólnej metodyki (strategii) testowej, w tym poziomów testowania oraz
kryteriów wej
ś
cia (dopuszczenia do testowania) i wyj
ś
cia (zako
ń
czenia testowania).
•
Zintegrowanie i skoordynowanie testowania z fazami cyklu
ż
yciowego
oprogramowania: zakup, dostawa, wytwarzanie, działanie operacyjne oraz
utrzymanie.
•
Podejmowanie decyzji, co b
ę
dzie przedmiotem testów, jakie role b
ę
d
ą
przypisane,
jakim zadaniom, kiedy i w jaki sposób wykonywane b
ę
d
ą
zadania testowe, jak b
ę
d
ą
oceniane wyniki testów, kiedy zako
ń
czy
ć
testowanie (kryteria wyj
ś
cia).
•
Przydzielanie zasobów zdefiniowanym zadaniom.
•
Okre
ś
lenie ilo
ś
ci, szczegółowo
ś
ci, struktury i wzorców dokumentacji testowej.
•
Wybór miar słu
żą
cych do monitorowania i nadzoru nad przygotowywaniem i
wykonywaniem testów, rozwi
ą
zywania zgłosze
ń
bł
ę
dów oraz zagadnie
ń
zwi
ą
zanych
z ryzykiem.
•
Okre
ś
lenie szczegółowo
ś
ci procedur testowych w stopniu dostatecznym dla potrzeb
wielokrotnego przygotowywania i wykonywania testów.
5.2.3. Kryteria wyj
ś
cia (K2)
Kryteria wyj
ś
cia okre
ś
laj
ą
, kiedy mo
ż
na zako
ń
czy
ć
testowanie, na przykład po wykonaniu
testów na danym poziomie lub po wykonaniu zestawów testów maj
ą
cych okre
ś
lony cel.
Przykłady powszechnie stosowanych kryteriów zako
ń
czenia:
•
Miary staranno
ś
ci takie jak pokrycie kodu, funkcjonalno
ś
ci lub ryzyka.
•
Oszacowania zag
ę
szczenia bł
ę
dów lub miary niezawodno
ś
ci.
•
Koszty.
Certyfikowany tester
Plan poziomu podstawowego
International Sotware Testing Qualifications Board
Stowarzyszenie Jako
ś
ci Systemów Informatycznych
Wersja 1.0
© Stowarzyszenie Jako
ś
ci Systemów
Informatycznych
Strona 49 z 78
20 pa
ź
dziernika 2006
•
Istniej
ą
ce zagro
ż
enia, takie jak nienaprawione bł
ę
dy lub brak pokrycia pewnych
obszarów.
•
Harmonogramy, na przykład narzucaj
ą
ce dat
ę
dostawy.
5.2.4. Oszacowanie wysiłku testowego (K2)
Plan omawia dwa sposoby oszacowywania wysiłku testowego:
•
Oszacowanie wysiłku testowego na podstawie pomiarów z wcze
ś
niejszych lub z
podobnych projektów albo na podstawie typowych wielko
ś
ci.
•
Oszacowanie zada
ń
przez osoby za nie odpowiedzialne lub przez ekspertów.
Po oszacowaniu pracochłonno
ś
ci zada
ń
mo
ż
liwe jest przypisanie im zasobów i sporz
ą
dzenie
harmonogramu.
Pracochłonno
ść
testowania zale
ż
y od wielu czynników, w tym:
Wła
ś
ciwo
ś
ci produktu: jako
ś
ci specyfikacji i innych
ź
ródeł informacji, na podstawie, których
budowane s
ą
modele (np. podstawy testowej), wielko
ś
ci produktu, zło
ż
ono
ś
ci zagadnie
ń
dziedziny, wymaga
ń
dotycz
ą
cych niezawodno
ś
ci i zabezpiecze
ń
oraz wymaga
ń
dotycz
ą
cych
dokumentacji.
Wła
ś
ciwo
ś
ci procesu wytwarzania: stabilno
ś
ci organizacji, stosowanych narz
ę
dzi, procesu
testowego, umiej
ę
tno
ś
ci personelu, napi
ę
to
ś
ci harmonogramu.
Wyników testowania: liczby znalezionych bł
ę
dów i ilo
ś
ci niezb
ę
dnych przeróbek.
5.2.5. Sposoby podej
ś
cia do testowania (strategie testowe) (K2)
W Jednym ze sposobów kategoryzacji podej
ś
cia lub strategii testowych stosuje si
ę
kryterium
czasu, kiedy odbywa si
ę
wi
ę
kszo
ść
pracy zwi
ą
zanej z testowaniem:
•
Metody prewencyjne, w których testy projektuje si
ę
tak wcze
ś
nie jak to tylko mo
ż
liwe.
•
Metody reaktywne, w których projektowanie testów nast
ę
puje dopiero po
wyprodukowaniu oprogramowania lub systemu.
Typowe strategie testowe to:
•
Metody analityczne, na przykład testowanie na podstawie ryzyka, w których
testowanie koncentrowane jest w obszarach najwy
ż
szego zagro
ż
enia.
•
Metody modelowania, na przykład testowanie stochastyczne na podstawie danych
statystycznych dotycz
ą
cych cz
ę
stotliwo
ś
ci awarii (modele wzrostu niezawodno
ś
ci)
lub dotycz
ą
cych cz
ę
stotliwo
ś
ci zastosowania (profile u
ż
ycia operacyjnego).
•
Metody systematyczne, takie jak testowanie na podstawie danych o awariach (w tym
domy
ś
lanie si
ę
bł
ę
dów i ataki przy pomocy bł
ę
dnych danych), na podstawie list
kontrolnych oraz na podstawie atrybutów jako
ś
ci.
•
Metody zgodne z procesem, standardem lub norm
ą
, na przykład okre
ś
lone przez
standard bran
ż
owy lub metodyki zwinne.
•
Metody dynamiczne i heurystyczne, na przykład testowanie eksploracyjne, w których
testowanie polega bardziej na reagowaniu na wydarzenia ni
ż
na planowaniu, i gdzie
wykonywanie i ocena odbywaj
ą
si
ę
równolegle.
•
Metodyki konsultatywne, w których projektowanie testów jest w przewa
ż
aj
ą
cej mierze
zadaniem ekspertów w dziedzinie technologii lub zastosowania biznesowego,
nienale
żą
cych do zespołu testowego.
•
Podej
ś
cia maj
ą
ce na celu ograniczenie pracochłonno
ś
ci testów regresji poprzez
ponowne u
ż
ycie artefaktów testowych, rozbudowan
ą
automatyzacj
ę
oraz
wykorzystanie standardowych zestawów testów.
Ró
ż
ne metody mo
ż
na ł
ą
czy
ć
, np. dynamiczna metodyka na podstawie oszacowania ryzyka.
Wybieraj
ą
c metodyk
ę
testow
ą
, nale
ż
y uwzgl
ę
dni
ć
takie aspekty jak:
Certyfikowany tester
Plan poziomu podstawowego
International Sotware Testing Qualifications Board
Stowarzyszenie Jako
ś
ci Systemów Informatycznych
Wersja 1.0
© Stowarzyszenie Jako
ś
ci Systemów
Informatycznych
Strona 50 z 78
20 pa
ź
dziernika 2006
•
Ryzyko niepowodzenia projektu, zagro
ż
enia wobec produktu oraz zagro
ż
enie dla
ludzi,
ś
rodowiska lub firmy spowodowane awari
ą
produktu.
•
Umiej
ę
tno
ś
ci i do
ś
wiadczenie ludzi uczestnicz
ą
cych w projekcie w zakresie
planowanych technik, narz
ę
dzi i metod.
•
Cel przedsi
ę
wzi
ę
cia testowego oraz misj
ę
zespołu testowego.
•
Przepisy, zarówno zewn
ę
trzne jak i wewn
ę
trzne, dotycz
ą
ce procesu wytwarzania.
•
Rodzaj i specyfik
ę
produktu lub przedsi
ę
wzi
ę
cia.
Certyfikowany tester
Plan poziomu podstawowego
International Sotware Testing Qualifications Board
Stowarzyszenie Jako
ś
ci Systemów Informatycznych
Wersja 1.0
© Stowarzyszenie Jako
ś
ci Systemów
Informatycznych
Strona 51 z 78
20 pa
ź
dziernika 2006
5.3. Monitorowanie przebiegu i nadzór testowania (K2), 20 minut
Terminologia
G
ę
sto
ść
defektów, cz
ę
stotliwo
ść
awarii, nadzór nad testowaniem, pokrycie testowe,
monitorowanie testowania, raport testowy.
5.3.1. Monitorowanie post
ę
pu testów (K1)
Celem monitorowania testów jest uzyskanie informacji zwrotnej o zadaniach testowych oraz
unaocznienie ich przebiegu. Monitorowan
ą
informacj
ę
mo
ż
na zbiera
ć
r
ę
cznie lub
automatycznie i mo
ż
na j
ą
stosowa
ć
do pomiaru spełnienia kryteriów wyj
ś
cia, (np. analizy
pokrycia). Pomiary mog
ą
słu
ż
y
ć
równie
ż
do oceny post
ę
pu prac w porównaniu z
harmonogramem i bud
ż
etem. Przykłady cz
ę
sto stosowanych miar:
•
Jaka cz
ęść
prac przygotowawczych została wykonana, lub jaki odsetek
zaplanowanych przypadków testowych przygotowano (wykonano).
•
Jak
ą
cz
ęść
wykonano przygotowuj
ą
c
ś
rodowisko testowe.
•
Przebieg wykonania testów (np. liczba wykonanych i niewykonanych przypadków
testowych, liczba zaliczonych i niezaliczonych przypadków testowych).
•
Dane o bł
ę
dach, np. g
ę
sto
ść
defektów, liczba znalezionych i naprawionych defektów,
cz
ę
stotliwo
ść
awarii, wyniki testów zgodno
ś
ci lub retestów.
•
Pokrycie wymaga
ń
, ryzyka lub kodu.
•
Subiektywne poczucie testerów dotycz
ą
ce niezawodno
ś
ci produktu.
•
Daty testowych kamieni milowych.
•
Koszty testowania, w tym koszty porównawcze wobec korzy
ś
ci znalezienia
nast
ę
pnego defektu lub wykonania kolejnego testu.
5.3.2. Raportowanie testów (K2)
Celem raportowania jest podanie podsumowuj
ą
cych danych dotycz
ą
cych przebiegu
przedsi
ę
wzi
ę
cia testowego, takich jak:
•
Co zdarzyło si
ę
w okresie testowania, np. daty spełnienia kryteriów wyj
ś
cia.
•
Analiza danych oraz pomiarów w celu uzasadnienia rekomendacji i decyzji, np. ocena
ile pozostało jeszcze defektów, ekonomiczna opłacalno
ść
dalszego testowania,
istniej
ą
ce zagro
ż
enia, oraz okre
ś
lenie poziomu zaufania do testowanego
oprogramowania.
Przykładowy wzorzec ko
ń
cowego raportu testowego znajduje si
ę
w normie IEEE 829
„Standard for Software Test Documentation”.
W trakcie i pod koniec ka
ż
dego poziomu testów nale
ż
y wykonywa
ć
pomiary, aby móc oceni
ć
nast
ę
puj
ą
ce elementy:
•
Wła
ś
ciwy dobór celów testowania dla danego poziomu.
•
Na ile przyj
ę
ta metodyka testowa jest odpowiednia.
•
Na ile testowanie jest skuteczne w porównaniu z przyj
ę
tymi celami.
5.3.3. Nadzór nad testowaniem (K2)
Nadzór nad testowaniem obejmuje wszelkie czynno
ś
ci nadaj
ą
ce testom kierunek oraz
wszelkie działania naprawcze, które podejmuje si
ę
w wyniku zgromadzonych i
zaraportowanych danych i pomiarów. Czynno
ś
ci te mog
ą
dotyczy
ć
wszystkich zada
ń
testowych i mog
ą
wywiera
ć
wpływ na wszystkie inne czynno
ś
ci podejmowane w cyklu
ż
ycia
oprogramowania.
Certyfikowany tester
Plan poziomu podstawowego
International Sotware Testing Qualifications Board
Stowarzyszenie Jako
ś
ci Systemów Informatycznych
Wersja 1.0
© Stowarzyszenie Jako
ś
ci Systemów
Informatycznych
Strona 52 z 78
20 pa
ź
dziernika 2006
Przykłady czynno
ś
ci nadzorczych:
•
Zmiana wag testów po zmaterializowaniu si
ę
jakiego
ś
ryzyka (np. spó
ź
nionej
dostawie oprogramowania).
•
Zmiana harmonogramu uwzgl
ę
dniaj
ą
ca dost
ę
pno
ść
ś
rodowiska testowego.
•
Ustalenie kryteriów wej
ś
ciowych wymagaj
ą
cych, aby naprawy bł
ę
dów były ponownie
przetestowane przez programist
ę
przed ich wł
ą
czeniem do budowy nowej wersji
oprogramowania.
Certyfikowany tester
Plan poziomu podstawowego
International Sotware Testing Qualifications Board
Stowarzyszenie Jako
ś
ci Systemów Informatycznych
Wersja 1.0
© Stowarzyszenie Jako
ś
ci Systemów
Informatycznych
Strona 53 z 78
20 pa
ź
dziernika 2006
5.4. Zarz
ą
dzanie konfiguracj
ą
(K2), 10 minut
Terminologia
Zarz
ą
dzanie konfiguracj
ą
, nadzór nad wersjami.
Wprowadzenie
Celem zarz
ą
dzania konfiguracj
ą
jest uzyskanie i utrzymanie spójno
ś
ci produktów
(komponentów, danych i dokumentacji) oprogramowania lub systemu podczas projektu i w
cyklu
ż
yciowym produktu.
Z punktu widzenia testowania, zarz
ą
dzanie konfiguracj
ą
słu
ż
y do osi
ą
gni
ę
cia:
•
Identyfikacji wersji, nadzoru nad nimi, zapisywania zmian,
ś
ledzenia relacji mi
ę
dzy
artefaktami testowymi oraz relacji mi
ę
dzy nimi a przedmiotem testu w celu
utrzymania kontroli nad przeprowadzonymi zmianami w trakcie całego procesu
testowania.
•
Jednoznacznej identyfikacji wszelkich dokumentów oraz elementów oprogramowania,
do których odwołuje si
ę
dokumentacja testowa.
Zarz
ą
dzanie konfiguracj
ą
umo
ż
liwia testerom jednoznaczne zidentyfikowanie i odtworzenie
testowanego elementu, dokumentacji testowej, testów oraz jarzma testowego.
Planowanie testów powinno okre
ś
li
ć
, udokumentowa
ć
i wdro
ż
y
ć
procedury oraz
infrastruktur
ę
(narz
ę
dzia) do zarz
ą
dzania konfiguracj
ą
.
Certyfikowany tester
Plan poziomu podstawowego
International Sotware Testing Qualifications Board
Stowarzyszenie Jako
ś
ci Systemów Informatycznych
Wersja 1.0
© Stowarzyszenie Jako
ś
ci Systemów
Informatycznych
Strona 54 z 78
20 pa
ź
dziernika 2006
5.5. Ryzyko a testowanie (K2), 30 minut
Terminologia
Ryzyko produktowe, ryzyko projektowe, testowanie na podstawie ryzyka.
Wprowadzenie
Ryzyko mo
ż
na zdefiniowa
ć
jako prawdopodobie
ń
stwo wyst
ą
pienia wydarzenia, zagro
ż
enia
lub niepo
żą
danej w skutkach sytuacji jako mo
ż
liwego problemu. Poziom ryzyka okre
ś
laj
ą
prawdopodobie
ń
stwo niekorzystnego zdarzenia oraz jego konsekwencje (szkoda b
ę
d
ą
ca
skutkiem tego zdarzenia).
5.5.1. Ryzyko projektowe (K1, K2)
Ryzyko projektowe to ryzyko zdolno
ś
ci projektu do osi
ą
gni
ę
cia celów, na przykład:
•
Problemy z dostawcami:
•
Niepowodzenie dostawy;
•
Kwestie dotycz
ą
ce kontraktu.
•
Czynniki organizacyjne:
o
Brak personelu i/lub niezb
ę
dnych umiej
ę
tno
ś
ci
o
Problemy osobiste i problemy dotycz
ą
ce szkole
ń
;
•
Kwestie organizacyjne, np.
o
Nieskuteczne komunikowanie przez testerów swoich potrzeb oraz wyników
testów;
o
Niewykorzystanie informacji zdobytej podczas testowania i przegl
ą
dów, np.
zaniechanie usprawniania procedur i innych praktyk testowych).
o
Niewła
ś
ciwa postawa lub oczekiwania w stosunku do testów (niedocenianie
wyszukiwania defektów podczas testowania).
•
Czynniki techniczne:
o
Niewła
ś
ciwie okre
ś
lone wymagania;
o
Wymagania nie s
ą
w pełni osi
ą
galne przy istniej
ą
cych ograniczeniach;
o
Jako
ść
projektu, kodu i testów.
Analizuj
ą
c, zarz
ą
dzaj
ą
c i zapobiegaj
ą
c tym zagro
ż
eniom, kierownik projektu post
ę
puje
według znanych zasad zarz
ą
dzania projektami. Wzorzec planu testów wg normy IEEE 829
(„Standard for Software Test Documentation”) wymaga okre
ś
lenia zagro
ż
e
ń
i zaplanowania
czynno
ś
ci zaradczych.
5.5.2. Ryzyko zwi
ą
zane z produktem (K2)
Jako ryzyko zwi
ą
zane z produktem okre
ś
la si
ę
obszary mo
ż
liwych awarii (niekorzystne
przyszłe wydarzenia lub zagro
ż
enia) w oprogramowaniu lub systemie, gdy
ż
zagra
ż
aj
ą
one w
ró
ż
ny sposób jako
ś
ci produktu, np.:
•
Przez dostarczenie zawodnego oprogramowania.
•
Oprogramowanie lub sprz
ę
t spowoduj
ą
szkody osobiste i/lub dla firmy.
•
Niedostateczne wła
ś
ciwo
ś
ci oprogramowania (np. funkcjonalno
ść
,
zabezpieczenia, niezawodno
ść
, u
ż
yteczno
ść
i wydajno
ść
).
Certyfikowany tester
Plan poziomu podstawowego
International Sotware Testing Qualifications Board
Stowarzyszenie Jako
ś
ci Systemów Informatycznych
Wersja 1.0
© Stowarzyszenie Jako
ś
ci Systemów
Informatycznych
Strona 55 z 78
20 pa
ź
dziernika 2006
•
Oprogramowanie, które nie spełnia zało
ż
onej funkcjonalno
ś
ci.
Przy pomocy ryzyka mo
ż
na okre
ś
li
ć
, kiedy nale
ż
y rozpocz
ąć
testowanie i gdzie warto
testowa
ć
wi
ę
cej. Testowanie ogranicza prawdopodobie
ń
stwo niekorzystnego wydarzenia lub
zmniejsza skutki jego wyst
ą
pienia.
Ryzyko zwi
ą
zane z produktem jest rodzajem zagro
ż
enia dla powodzenia projektu.
Testowanie pozwala nadzorowa
ć
ryzyko, dostarczaj
ą
c informacji o poziomie zagro
ż
enia
dzi
ę
ki pomiarom skuteczno
ś
ci usuwania krytycznych defektów oraz planów awaryjnych.
Metodyka testowania bazuj
ą
ca na ryzyku stwarza mo
ż
liwo
ś
ci aktywnego ograniczania ryzyk
zwi
ą
zanych z produktem od najwcze
ś
niejszych etapów projektu. Testowanie umo
ż
liwia
identyfikacj
ę
ryzyk, a nast
ę
pnie wykorzystania ich w planowaniu, specyfikacji, przygotowaniu
i wykonaniu testów. Zidentyfikowane ryzyka mo
ż
na wykorzysta
ć
do:
•
Okre
ś
lenia, jakie zastosowa
ć
techniki testowania.
•
Okre
ś
lenia zakresu testów.
•
Uporz
ą
dkowania testów pod wzgl
ę
dem ich wag, aby móc jak najwcze
ś
niej
znale
źć
najistotniejsze defekty.
•
Okre
ś
lenia, jakie czynno
ś
ci poza testowaniem warto wykorzysta
ć
dla
ograniczenia ryzyka (np. odpowiednio szkol
ą
c niedo
ś
wiadczonych projektantów).
Testowanie na podstawie ryzyka wykorzystuje wspóln
ą
wiedz
ę
i do
ś
wiadczenie
interesariuszy w celu okre
ś
lenia ryzyk i poziomu testów niezb
ę
dnych dla ich kontrolowania.
Aby zminimalizowa
ć
ryzyko awarii produktu, w zarz
ą
dzaniu ryzykiem stosuje si
ę
zdyscyplinowane metody maj
ą
ce na celu:
•
Ocen
ę
– regularnie powtarzan
ą
– mo
ż
liwych wyst
ą
pie
ń
niekorzystnych wydarze
ń
(ryzyk).
•
Okre
ś
lenie wagi ryzyk.
•
Wdro
ż
enie czynno
ś
ci maj
ą
cych na celu eliminowanie ryzyk.
Testowanie umo
ż
liwia tak
ż
e identyfikacj
ę
nowych ryzyk, okre
ś
lenie którym ryzykom nale
ż
y
zapobiega
ć
oraz pozwala na trafniejsz
ą
ocen
ę
ich prawdopodobie
ń
stwa.
Certyfikowany tester
Plan poziomu podstawowego
International Sotware Testing Qualifications Board
Stowarzyszenie Jako
ś
ci Systemów Informatycznych
Wersja 1.0
© Stowarzyszenie Jako
ś
ci Systemów
Informatycznych
Strona 56 z 78
20 pa
ź
dziernika 2006
5.6. Zarz
ą
dzanie incydentami (K3), 40 minut
Terminologia
Logowanie incydentów.
Wprowadzenie
Jednym z celów testowania jest znajdowanie defektów, a wi
ę
c nale
ż
y prowadzi
ć
logowanie
incydentów - niezgodno
ś
ci mi
ę
dzy oczekiwanymi a rzeczywistymi wynikami testów.
Incydenty nale
ż
y nadzorowa
ć
od ich odkrycia, poprzez zaklasyfikowanie, naprawienie i
potwierdzenie skuteczno
ś
ci naprawy. Aby zarz
ą
dza
ć
incydentami, organizacje powinny
okre
ś
li
ć
i stosowa
ć
proces i reguły ich klasyfikacji.
Incydenty mog
ą
by
ć
zgłaszane podczas wytwarzania, przegl
ą
dów, testowania lub
u
ż
ytkowania oprogramowania. Incydenty mog
ą
dotyczy
ć
kodu, działaj
ą
cego systemu lub
wszelkiej dokumentacji, w tym dokumentacji dotycz
ą
cej wytwarzania, dokumentacji testowej
lub dokumentacji przeznaczonej dla u
ż
ytkownika, takiej jak instrukcja u
ż
ytkownika lub
instrukcja instalacji.
Celem zgłosze
ń
incydentów jest:
•
Dostarczenie konstruktorom i innym interesariuszom informacji o incydencie, by
umo
ż
liwi
ć
identyfikacj
ę
, wyizolowanie oraz – w razie potrzeby – napraw
ę
bł
ę
du.
•
Dostarczenie kierownictwu testów bie
żą
cej informacji o jako
ś
ci testowanego
systemu oraz o przebiegu testów.
•
Generowanie propozycji udoskonalenia procesu testowego.
Tester lub osoba wykonuj
ą
ca przegl
ą
d zwykle notuje nast
ę
puj
ą
ce dane (gdy s
ą
dost
ę
pne) na
temat incydentu:
•
Dat
ę
zgłoszenia, organizacj
ę
zgłaszaj
ą
c
ą
, autora, zatwierdzenie i status.
•
Czego dotyczy zgłoszenie, jego wag
ę
i priorytet.
•
Odno
ś
niki, w tym identyfikator przypadku testowego, który ujawnił problem.
Zgłoszenie incydentu mo
ż
e zawiera
ć
nast
ę
puj
ą
ce dane:
•
Wynik rzeczywisty i oczekiwany.
•
Dat
ę
odkrycia incydentu.
•
Okre
ś
lenie elementu konfiguracji oprogramowania lub systemu.
•
W jakiej fazie cyklu
ż
ycia oprogramowania zaobserwowano incydent.
•
Opis niezgodno
ś
ci ułatwiaj
ą
cy okre
ś
lenie jej przyczyny.
•
Konsekwencje dla interesariuszy.
•
Okre
ś
lenie stopnia pilno
ś
ci rozwi
ą
zania.
•
Status zgłoszenia (np. otwarte, odrzucone, powtórne zgłoszenie, oczekuj
ą
ce na
napraw
ę
, naprawione oczekuj
ą
ce na re-test, zamkni
ę
te).
•
Wnioski i zalecenia.
•
Zagadnienia ogólne, na przykład inne obszary, na które mog
ą
mie
ć
wpływ zmiany
przeprowadzone skutkiem naprawy bł
ę
du powoduj
ą
cego incydent.
Certyfikowany tester
Plan poziomu podstawowego
International Sotware Testing Qualifications Board
Stowarzyszenie Jako
ś
ci Systemów Informatycznych
Wersja 1.0
© Stowarzyszenie Jako
ś
ci Systemów
Informatycznych
Strona 57 z 78
20 pa
ź
dziernika 2006
•
Historia zmian, na przykład, jakie czynno
ś
ci zostały wykonane w celu
wyizolowania, naprawienia oraz potwierdzenia skuteczno
ś
ci naprawy.
IEEE 829 („Standard for Software Test Documentation”) okre
ś
la tre
ść
i struktur
ę
zgłoszenia
incydentu, nazywanego w normie tej zgłoszeniem niezgodno
ś
ci.
Bibliografia:
5.1.1 Black, 2001, Hetzel, 1998
5.1.2 Black, 2001, Hetzel, 1998
5.2.5 Black, 2001, Craig, 2002, IEEE 829, Kaner 2002
5.3.3 Black, 2001, Craig, 2002, Hetzel, 1998, IEEE 829
5.4 Craig, 2002
5.5.2 Black, 2001, IEEE 829
5.6 Black, 2001, IEEE 829
Certyfikowany tester
Plan poziomu podstawowego
International Sotware Testing Qualifications Board
Stowarzyszenie Jako
ś
ci Systemów Informatycznych
Wersja 1.0
© Stowarzyszenie Jako
ś
ci Systemów
Informatycznych
Strona 58 z 78
20 pa
ź
dziernika 2006
6. Testowanie wspierane narz
ę
dziami (K2), 80 minut
Celem rozdziału „Testowanie wspierane narz
ę
dziami” jest
nauczenie, w poszczególnych paragrafach:
6.1 Rodzaje narz
ę
dzi testowych (K2)
•
O ró
ż
nych rodzajach narz
ę
dzi testowych nadaj
ą
cych si
ę
do ró
ż
nych czynno
ś
ci
testowych. (K2)
•
O narz
ę
dziach, które mog
ą
by
ć
wykorzystane do testowania wykonywanego przez
programistów. (K1)
6.2 Skuteczne u
ż
ycie narz
ę
dzi: potencjalne korzy
ś
ci i zagro
ż
enia (K2)
•
Potencjalnych korzy
ś
ci i zagro
ż
e
ń
automatyzacji testów oraz wykorzystania narz
ę
dzi
wpieraj
ą
cych testowanie. (K2)
•
Ró
ż
nych form pisania skryptów steruj
ą
cych narz
ę
dziami wspieraj
ą
cymi wykonanie
testów, w oparciu o dane i w oparciu o słowa kluczowe. (K1)
6.3 Wdro
ż
enie narz
ę
dzi w organizacji (K1)
•
Zasad wdra
ż
ania narz
ę
dzi w organizacji. (K1)
•
Celów fazy pilota
ż
owej oceny narz
ę
dzia. (K1)
•
Zasady,
ż
e dla uzyskania korzy
ś
ci z u
ż
ycia narz
ę
dzia nie wystarcza samo nabycie
narz
ę
dzia. (K1)
Certyfikowany tester
Plan poziomu podstawowego
International Sotware Testing Qualifications Board
Stowarzyszenie Jako
ś
ci Systemów Informatycznych
Wersja 1.0
© Stowarzyszenie Jako
ś
ci Systemów
Informatycznych
Strona 59 z 78
20 pa
ź
dziernika 2006
6.1. Rodzaje narz
ę
dzi testowych (K2), 45 minut
Terminologia
Narz
ę
dzie do zarz
ą
dzania konfiguracj
ą
, narz
ę
dzie do pomiaru pokrycia, debager, sterownik,
narz
ę
dzie do analizy dynamicznej, narz
ę
dzie do zarz
ą
dzania zgłoszeniami bł
ę
dów,
narz
ę
dzie do testów obci
ąż
eniowych, narz
ę
dzie do modelowania, narz
ę
dzie monitoruj
ą
ce,
narz
ę
dzie do testów wydajno
ś
ciowych, efekt próbnika, narz
ę
dzie do zarz
ą
dzania
wymaganiami, narz
ę
dzie wspieraj
ą
ce proces przegl
ą
du, narz
ę
dzie do testów zabezpiecze
ń
,
narz
ę
dzie do analizy statycznej, narz
ę
dzie do testów przeci
ąż
enia, za
ś
lepka, komparator,
narz
ę
dzie do tworzenia danych testowych, narz
ę
dzie do projektowania testów, jarzmo
testowe, narz
ę
dzie wspieraj
ą
ce wykonanie testu, narz
ę
dzie wspieraj
ą
ce zarz
ą
dzanie testami,
narz
ę
dzie do testów jednostkowych.
6.1.1.
Klasyfikacja narz
ę
dzi testowych
Istnieje wiele narz
ę
dzi wspieraj
ą
cych ró
ż
ne aspekty testowania. Klasyfikacja zastosowana w
niniejszym konspekcie dokonana jest na podstawie czynno
ś
ci testowych, które s
ą
wspierane
przez narz
ę
dzia.
Niektóre narz
ę
dzia słu
żą
do wsparcia tylko jednej czynno
ś
ci, inne mog
ą
by
ć
wykorzystywane
do ró
ż
nych czynno
ś
ci, ale zaklasyfikowane zostały zgodnie z t
ą
czynno
ś
ci
ą
, do której
najcz
ęś
ciej s
ą
stosowane. Niektóre narz
ę
dzia komercyjne wspieraj
ą
tylko jeden rodzaj
czynno
ś
ci, ale niektórzy dostawcy komercyjnych narz
ę
dzi oferuj
ą
zestawy albo rodziny
narz
ę
dzi, wspieraj
ą
cych wiele ró
ż
nych czynno
ś
ci testowych.
Narz
ę
dzia umo
ż
liwiaj
ą
usprawnienie testowania dzi
ę
ki zautomatyzowaniu wielokrotnie
wykonywanych czynno
ś
ci testowych. Narz
ę
dzia mog
ą
tak
ż
e poprawi
ć
niezawodno
ść
testowania dzi
ę
ki automatyzacji porównywania du
ż
ej ilo
ś
ci danych lub symulowania
okre
ś
lonych zachowa
ń
ś
rodowiska testowanego systemu.
Niektóre rodzaje narz
ę
dzi s
ą
inwazyjne, co oznacza,
ż
e samo zastosowanie narz
ę
dzia
wywiera wpływ na rzeczywisty wynik testu. Na przykład, rzeczywisty czas wykonania mo
ż
e
zale
ż
e
ć
od tego, w jaki sposób narz
ę
dzia do testów wydajno
ś
ciowych dokonuj
ą
pomiarów.
Zale
ż
nie od zastosowanego narz
ę
dzia mo
ż
na otrzyma
ć
tak
ż
e ró
ż
ne wyniki pomiarów
pokrycia kodu. Skutek inwazyjno
ś
ci narz
ę
dzia nazywany jest efektem próbnika.
Niektóre narz
ę
dzia wspieraj
ą
czynno
ś
ci wykonywane najcz
ęś
ciej przez programistów (np.
podczas testowania modułowego oraz testowania integracji modułów). Takie narz
ę
dzia
oznaczone s
ą
liter
ą
„(D)” w poni
ż
szej klasyfikacji.
6.1.2.
Zarz
ą
dzanie testowaniem wspierane narz
ę
dziami (K1)
Zarz
ą
dzanie testowaniem wspierane narz
ę
dziami znajduje zastosowanie we wszystkich
czynno
ś
ciach testowych podczas całego cyklu
ż
ycia oprogramowania.
Narz
ę
dzia do zarz
ą
dzania testami
Narz
ę
dzia do zarz
ą
dzania testami maj
ą
nast
ę
puj
ą
ce funkcje:
•
Wsparcie zarz
ą
dzania testami i innymi wykonywanymi czynno
ś
ciami testowymi.
•
Interfejsy do narz
ę
dzi wspieraj
ą
cych wykonanie testu, zarz
ą
dzanie zgłoszeniami
bł
ę
dów i zarz
ą
dzanie wymaganiami.
•
Wbudowane zarz
ą
dzanie wersjami lub interfejs do zewn
ę
trznego narz
ę
dzia do
zarz
ą
dzania wersjami.
Certyfikowany tester
Plan poziomu podstawowego
International Sotware Testing Qualifications Board
Stowarzyszenie Jako
ś
ci Systemów Informatycznych
Wersja 1.0
© Stowarzyszenie Jako
ś
ci Systemów
Informatycznych
Strona 60 z 78
20 pa
ź
dziernika 2006
•
Mo
ż
liwo
ść
ś
ledzenia powi
ą
za
ń
testów, wyników testów oraz incydentów z
dokumentami
ź
ródłowymi, takimi jak specyfikacje wymaga
ń
.
•
Logowanie wyników testów i tworzenie raportów z post
ę
pu realizacji testów.
•
Analiz
ę
ilo
ś
ciow
ą
(miary) dotycz
ą
c
ą
testów (np. liczba wykonanych i zaliczonych
testów) oraz przedmiotu testów (np. liczba incydentów), maj
ą
c
ą
na celu uzyskanie
informacji o przedmiocie testów oraz nadzorowanie i udoskonalanie procesu
testowania.
Narz
ę
dzia do zarz
ą
dzania wymaganiami
Narz
ę
dzia do zarz
ą
dzania wymaganiami słu
żą
do przechowywania wymaga
ń
, kontroli
spójno
ś
ci wymaga
ń
oraz identyfikacji niezdefiniowanych (brakuj
ą
cych) wymaga
ń
. Narz
ę
dzia
te umo
ż
liwiaj
ą
ponadto okre
ś
lenie priorytetów wymaga
ń
, oraz
ś
ledzenie powi
ą
za
ń
pojedynczych testów z wymaganiami, funkcjami lub obszarami funkcjonalno
ś
ci systemu.
Powi
ą
zania te mog
ą
by
ć
wykorzystywane w raportach post
ę
pu prac. Raportowane mo
ż
e by
ć
tak
ż
e pokrycie testami: wymaga
ń
, funkcji lub funkcjonalno
ś
ci systemu.
Narz
ę
dzia do zarz
ą
dzania incydentami
Narz
ę
dzia do zarz
ą
dzania incydentami słu
żą
do przechowywania i zarz
ą
dzania zgłoszeniami
incydentów, czyli defektów, awarii oraz innych obserwowanych problemów lub anomalii.
Wspieraj
ą
one zarz
ą
dzanie zgłoszeniami incydentów m.in. poprzez:
•
Ułatwianie priorytetyzacji zgłosze
ń
.
•
Przydzielanie osobom zada
ń
do wykonania (np. napraw
ę
bł
ę
du lub testowanie
potwierdzaj
ą
ce).
•
Okre
ś
lenie statusu zgłoszenia (np. odrzucone, gotowe do przetestowania lub
odło
ż
one do nast
ę
pnego wypuszczenia wersji).
Narz
ę
dzia te umo
ż
liwiaj
ą
ś
ledzenie zmian tre
ś
ci i statusu incydentów, a tak
ż
e analiz
ę
statyczn
ą
oraz raportowanie incydentów. Nazywane s
ą
tak
ż
e narz
ę
dziami do
ś
ledzenia
zgłosze
ń
bł
ę
dów.
Narz
ę
dzia do zarz
ą
dzania konfiguracj
ą
Narz
ę
dzia do zarz
ą
dzania konfiguracj
ą
nie s
ą
w pełni narz
ę
dziami testowymi, ale s
ą
z reguły
niezb
ę
dne do zarz
ą
dzania ró
ż
nymi wersjami i build’ami oprogramowania i testów.
Narz
ę
dzia do zarz
ą
dzania konfiguracj
ą
:
•
Przechowuj
ą
dane na temat wersji i build’ów oprogramowania oraz artefaktów
testowych (testaliów).
•
Pozwalaj
ą
ś
ledzi
ć
powi
ą
zania mi
ę
dzy testaliami oraz produktami programistycznymi i
ich wariantami.
•
S
ą
szczególnie przydatne, gdy wytwarzana jest wi
ę
cej ni
ż
jedna konfiguracja
oprogramowania i sprz
ę
tu (np. dla ró
ż
nych wersji systemu operacyjnego, bibliotek lub
kompilatorów, ró
ż
nych przegl
ą
darek lub ró
ż
nych typów komputerów).
Certyfikowany tester
Plan poziomu podstawowego
International Sotware Testing Qualifications Board
Stowarzyszenie Jako
ś
ci Systemów Informatycznych
Wersja 1.0
© Stowarzyszenie Jako
ś
ci Systemów
Informatycznych
Strona 61 z 78
20 pa
ź
dziernika 2006
6.1.3.
Testowanie statyczne wspierane narz
ę
dziami (K1)
Narz
ę
dzia wspieraj
ą
ce proces przegl
ą
du
Narz
ę
dzia wspieraj
ą
ce proces przegl
ą
du mog
ą
gromadzi
ć
dane na temat procesów
przegl
ą
du, przechowywa
ć
i słu
ż
y
ć
do przekazywania komentarzy przegl
ą
dowych,
raportowa
ć
znalezione defekty oraz pracochłonno
ść
, zarz
ą
dza
ć
odwołaniami do reguł
wykonywania przegl
ą
dów lub list kontrolnych, a tak
ż
e
ś
ledzi
ć
powi
ą
zania mi
ę
dzy
dokumentacj
ą
a kodem
ź
ródłowym. Mog
ą
tak
ż
e pozwala
ć
na wykonywanie przegl
ą
dów on-
line, co jest po
żą
dane w geograficznie rozproszonych projektach.
Narz
ę
dzia do analizy statycznej (D)
Narz
ę
dzia do analizy statycznej umo
ż
liwiaj
ą
programistom, testerom i specjalistom od
zapewnienia jako
ś
ci znajdowanie defektów przed rozpocz
ę
ciem testowania dynamicznego.
Ich podstawowe cele to:
•
Nadzorowanie przestrzegania standardów kodowania.
•
Analiza struktur i zale
ż
no
ś
ci (np. poł
ą
czonych stron internetowych).
•
Ułatwienie zrozumienia kodu.
Narz
ę
dzia do analizy statycznej na podstawie kodu mog
ą
wylicza
ć
miary (np. zło
ż
ono
ść
), co
jest cenn
ą
informacj
ą
np. przy planowaniu i analizie ryzyka.
Narz
ę
dzia do modelowania (D)
Narz
ę
dzia do modelowania pozwalaj
ą
dokonywa
ć
walidacji modeli oprogramowania. Na
przykład sprawdzenie modelu bazy danych mo
ż
e znale
źć
defekty i niespójno
ś
ci w modelu
danych; inne narz
ę
dzia do modelowania pozwalaj
ą
znajdowa
ć
defekty w modelach przej
ść
stanów (automatów sko
ń
czonych) lub w modelach obiektowych. Cz
ę
sto narz
ę
dzia tego
rodzaju umo
ż
liwiaj
ą
wygenerowanie przypadków testowych z modelu (patrz te
ż
„Narz
ę
dzia
wspieraj
ą
ce projektowanie testów” poni
ż
ej).
Podstawow
ą
korzy
ś
ci
ą
z zastosowania narz
ę
dzi do modelowania i analizy statycznej jest
oszcz
ę
dno
ść
wynikaj
ą
ca ze znajdowania bł
ę
dów we wcze
ś
niejszych fazach procesu
wytwarzania oprogramowania. Dzi
ę
ki temu proces wytwarzania mo
ż
e odbywa
ć
si
ę
szybciej i
sprawniej, gdy
ż
ogranicza si
ę
ilo
ść
przeróbek.
6.1.4.
Tworzenie specyfikacji testów wspierane narz
ę
dziami
Narz
ę
dzia wspieraj
ą
ce projektowanie testów
Narz
ę
dzia wspieraj
ą
ce projektowanie testów generuj
ą
wej
ś
ciowe dane testowe lub testy z
wymaga
ń
, z graficznego interfejsu u
ż
ytkownika, z modeli projektowych (stanów, danych lub
obiektów) lub z kodu
ź
ródłowego. Ten rodzaj narz
ę
dzi pozwala tak
ż
e generowa
ć
wyniki
oczekiwane (np. wykorzystuj
ą
c wyroczni
ę
). Testy wygenerowane z modelu automatu
sko
ń
czonego lub modelu obiektowego s
ą
przydatne do weryfikacji poprawno
ś
ci
implementacji modelu w kodzie, ale z reguły nie s
ą
wystarczaj
ą
ce dla zweryfikowania
wszystkich aspektów oprogramowania lub systemu. Pozwalaj
ą
zaoszcz
ę
dzi
ć
cenny czas i
zapewni
ć
wi
ę
ksz
ą
staranno
ść
dzi
ę
ki temu,
ż
e testy wygenerowane przez narz
ę
dzia s
ą
kompletne i dotycz
ą
wszystkich obszarów funkcjonalno
ś
ci systemu.
Inne narz
ę
dzia tego rodzaju wspomagaj
ą
generowanie testów dostarczaj
ą
c
strukturalizowanych wzorców, niekiedy nazywanych wzorcami testowymi, które generuj
ą
testy lub za
ś
lepki testowe, co przy
ś
piesza proces projektowania testów.
Certyfikowany tester
Plan poziomu podstawowego
International Sotware Testing Qualifications Board
Stowarzyszenie Jako
ś
ci Systemów Informatycznych
Wersja 1.0
© Stowarzyszenie Jako
ś
ci Systemów
Informatycznych
Strona 62 z 78
20 pa
ź
dziernika 2006
Narz
ę
dzia do przygotowywania danych testowych (D)
Narz
ę
dzia do przygotowywania danych testowych generuj
ą
dane testowe wykorzystywane
przy wykonywaniu testów z baz danych, plików lub zarejestrowanych przekazów danych.
Zalet
ą
tych narz
ę
dzi jest (dzi
ę
ki usuni
ę
ciu szczegółowych danych osobowych)
zabezpieczenie poufnych danych wykorzystanych w
ś
rodowisku testowym.
6.1.5.
Wykonywanie testów wspierane narz
ę
dziami
Wykonywanie testów wspierane narz
ę
dziami
Wykonywanie testów wspierane narz
ę
dziami umo
ż
liwia automatyczne lub półautomatyczne
wykonywanie testów sterowanych j
ę
zykiem skryptowym, wykorzystuj
ą
cych zebrane dane
wej
ś
ciowe oraz wyniki oczekiwane. J
ę
zyk skryptowy ułatwia sterowanie testami, na przykład
wielokrotne powtórzenie testu z ró
ż
nymi danymi lub przetestowanie ró
ż
nych cz
ęś
ci systemu
przy u
ż
yciu tych samych kroków. Zwykle narz
ę
dzia tego rodzaju pozwalaj
ą
na dynamiczne
porównywanie wyników oraz tworzenie logu dla ka
ż
dego wykonania testu.
Narz
ę
dzia wspieraj
ą
ce wykonanie testów mog
ą
by
ć
te
ż
stosowane do rejestrowania testów.
Rejestracja danych testowych wprowadzanych podczas testowania eksploracyjnego lub
innego wykonywanego bez u
ż
ycia skryptów testowych mog
ą
by
ć
przydatne w celu
odtworzenia lub udokumentowania testów w przypadku awarii.
Jarzma testowe oraz narz
ę
dzia wspomagaj
ą
ce do testów jednostkowych
Jarzmo testowe ułatwia testowanie komponentów lub cz
ęś
ci systemu, symuluj
ą
c
ś
rodowisko
danego obiektu testowego. Jarzma testowe stosuje si
ę
z dwóch przyczyn. Po pierwsze, gdy
inne komponenty
ś
rodowiska nie s
ą
jeszcze dost
ę
pne i zast
ę
puje si
ę
je za
ś
lepkami lub
sterownikami, a po drugie, aby wykonywanie testów odbywało si
ę
w sprawdzonym i
przewidywalnym
ś
rodowisku, co umo
ż
liwia lokalizacj
ę
bł
ę
dów w obiekcie testowym.
Rusztowanie testowe tworzy si
ę
, gdy testowany fragment kodu: obiekt, metoda, funkcja lub
moduł jest wykonywany poprzez jego wywołanie i dostarczenie mu sprz
ęż
enia zwrotnego.
Osi
ą
ga si
ę
to dostarczaj
ą
c testowanemu obiektowi (niestandardowymi metodami)
wej
ś
ciowych danych testowych lub za
ś
lepek mog
ą
cych odbiera
ć
dane wyj
ś
ciowe z tego
obiektu w miejsce rzeczywistych odbiorców.
Jarzma testowe stosuje si
ę
tak
ż
e w celu stworzenia rusztowania na poziomie
oprogramowania po
ś
redniego umo
ż
liwiaj
ą
cego jednoczesne testowanie
ś
rodowiska j
ę
zyka
programowania, systemu operacyjnego lub platformy sprz
ę
towej.
Jarzma testowe mo
ż
emy okre
ś
la
ć
jako rusztowania do testów modułowych, gdy
ż
stosuje si
ę
je przede wszystkim na poziomie testów modułowych. Ten typ narz
ę
dzi wspomaga
wykonywanie testów modułowych równolegle z tworzeniem kodu.
Narz
ę
dzia do porównywania wyników (komparatory)
Komparatory testowe słu
żą
do porównywania plików, baz danych lub wyników testów. W
skład narz
ę
dzi do wykonywania testów wchodz
ą
zwykle komparatory dynamiczne, ale
niekiedy porównanie wykonuje si
ę
dopiero po zako
ń
czeniu testowania przy pomocy
odr
ę
bnego narz
ę
dzia do porównywania wyników. Komparator testowy posługuje si
ę
niekiedy
wyroczni
ą
, zwłaszcza zautomatyzowan
ą
.
Narz
ę
dzia do pomiaru pokrycia (D)
Narz
ę
dzia do pomiaru pokrycia testowego s
ą
inwazyjne lub nieinwazyjne, zale
ż
nie od
techniki wykonywania pomiaru, wykorzystywanej miary pokrycia oraz j
ę
zyka programowania.
Certyfikowany tester
Plan poziomu podstawowego
International Sotware Testing Qualifications Board
Stowarzyszenie Jako
ś
ci Systemów Informatycznych
Wersja 1.0
© Stowarzyszenie Jako
ś
ci Systemów
Informatycznych
Strona 63 z 78
20 pa
ź
dziernika 2006
Narz
ę
dzia do pomiaru pokrycia mierz
ą
odsetek okre
ś
lonych konstrukcji w kodzie (np.
instrukcji, rozgał
ę
zie
ń
, decyzji, wywoła
ń
funkcji lub modułów), które zostały wykonane
podczas testowania. Miary pokrycia wykazuj
ą
, w jakim stopniu konstrukcje b
ę
d
ą
ce
przedmiotem pomiaru s
ą
testowane przez dany zestaw testów.
Narz
ę
dzia do testów zabezpiecze
ń
Narz
ę
dzia do testów zabezpiecze
ń
(odporno
ś
ci) wyłapuj
ą
wirusy komputerowe oraz
identyfikuj
ą
ataki maj
ą
ce na celu przeci
ąż
enie serwerów. Na przykład zapora ogniowa nie
jest narz
ę
dziem testowym, ale mo
ż
e by
ć
stosowana do testowania zabezpiecze
ń
. Inne
narz
ę
dzia do testowania zabezpiecze
ń
słu
żą
do poszukiwania okre
ś
lonych typów braku
odporno
ś
ci i niezabezpieczonego dost
ę
pu do systemów.
6.1.6.
Testowanie wydajno
ś
ci i monitorowanie wspierane narz
ę
dziami
(K1)
Narz
ę
dzia do analizy dynamicznej (D)
Narz
ę
dzia do analizy dynamicznej odnajduj
ą
defekty daj
ą
ce si
ę
zaobserwowa
ć
wył
ą
cznie
podczas wykonywania oprogramowania, takie jak zale
ż
no
ś
ci czasowe lub wycieki pami
ę
ci.
U
ż
ywa si
ę
ich zwykle podczas testowania modułowego, testowania integracji modułów oraz
do testowania oprogramowania po
ś
redniego.
Narz
ę
dzia do testów wydajno
ś
ci, obci
ąż
enia i przeci
ąż
aj
ą
cych
Narz
ę
dzia do testów wydajno
ś
ci monitoruj
ą
i raportuj
ą
działanie systemu w ró
ż
norodnych
symulowanych warunkach u
ż
ytkowania. Narz
ę
dzia te symuluj
ą
obci
ąż
enie aplikacji, bazy
danych albo komponentów
ś
rodowiska systemu, takich jak sie
ć
lub serwer. Nazwy tych
narz
ę
dzi (na przykład narz
ę
dzia do testów obci
ąż
enia lub przeci
ąż
aj
ą
cych) zwykle okre
ś
laj
ą
,
do testowania jakiego aspektu wydajno
ś
ci s
ą
stosowane. Ich działanie polega zazwyczaj na
wielokrotnym, automatycznym wykonywaniu sparametryzowanych testów.
Narz
ę
dzia do monitorowania
Narz
ę
dzia do monitorowania systemów nie s
ą
ś
ci
ś
le rzecz bior
ą
c narz
ę
dziami testowymi, ale
dostarczaj
ą
informacji niedost
ę
pnej w inny sposób, wykorzystywanej do celów testowania.
Narz
ę
dzia monitoruj
ą
ce na bie
żą
co analizuj
ą
, weryfikuj
ą
i raportuj
ą
wykorzystanie
okre
ś
lonych zasobów systemowych oraz ostrzegaj
ą
o zagro
ż
eniach systemu. Ponadto
przechowuj
ą
dane dotycz
ą
ce wersji i build’ów oprogramowania, testaliów, a tak
ż
e
umo
ż
liwiaj
ą
ś
ledzenie powi
ą
za
ń
.
6.1.7.
Narz
ę
dzia wspieraj
ą
ce testowanie w okre
ś
lonych dziedzinach
Niektóre narz
ę
dzia nale
żą
ce do opisywanych powy
ż
ej typów mog
ą
by
ć
wyspecjalizowane do
testowania specjalnego rodzaju oprogramowania. Na przykład istniej
ą
specjalne narz
ę
dzia
do testów wydajno
ś
ci aplikacji internetowych, narz
ę
dzia do analizy statycznej dedykowane
poszczególnym platformom programistycznym lub narz
ę
dzia do analizy dynamicznej
wykonywanej przede wszystkim pod k
ą
tem zabezpiecze
ń
systemu.
Dost
ę
pne komercyjne zestawy narz
ę
dzi testowych bywaj
ą
przeznaczone dla specjalnych
zastosowa
ń
, na przykład dla systemów wbudowanych.
Certyfikowany tester
Plan poziomu podstawowego
International Sotware Testing Qualifications Board
Stowarzyszenie Jako
ś
ci Systemów Informatycznych
Wersja 1.0
© Stowarzyszenie Jako
ś
ci Systemów
Informatycznych
Strona 64 z 78
20 pa
ź
dziernika 2006
6.1.8.
Wykorzystanie innych narz
ę
dzi (K1)
Wyliczone wcze
ś
niej rodzaje narz
ę
dzi testowych nie s
ą
jedynymi stosowanymi przez
testerów. Wykorzystywane s
ą
równie
ż
np. arkusze kalkulacyjne, narz
ę
dzia SQL, debagery i
narz
ę
dzia do zarz
ą
dzania zasobami.
Certyfikowany tester
Plan poziomu podstawowego
International Sotware Testing Qualifications Board
Stowarzyszenie Jako
ś
ci Systemów Informatycznych
Wersja 1.0
© Stowarzyszenie Jako
ś
ci Systemów
Informatycznych
Strona 65 z 78
20 pa
ź
dziernika 2006
6.2. Skuteczne zastosowanie narz
ę
dzi: mo
ż
liwe korzy
ś
ci i
zagro
ż
enia (K2), 20 minut
Terminologia
Testowanie w oparciu o dane, testowanie oparte na słowach kluczowych, j
ę
zyk skryptowy.
6.2.1.
Mo
ż
liwe korzy
ś
ci i zagro
ż
enia wynikaj
ą
ce ze stosowania
narz
ę
dzi wspieraj
ą
cych testowanie (dla wszystkich rodzajów narz
ę
dzi)
(K2)
Samo tylko zakupienie czy wypo
ż
yczenie narz
ę
dzia nie gwarantuje sukcesu. Ka
ż
dy typ
narz
ę
dzi wymaga zwykle dodatkowego wysiłku, aby osi
ą
gn
ąć
rzeczywiste i trwałe korzy
ś
ci z
jego zastosowania. Istniej
ą
zarówno potencjalne korzy
ś
ci, jak i ryzyko zwi
ą
zane z
posługiwaniem si
ę
narz
ę
dziami do testowania.
Mo
ż
liwe korzy
ś
ci z wykorzystania narz
ę
dzi:
•
Ograniczenie wielokrotnego wykonywania tej samej pracy (na przykład
wykonywania testów regresywnych, wielokrotnego wprowadzania tych samych
danych testowych, lub kontroli zgodno
ś
ci ze standardami programowania).
•
Wi
ę
ksza jednolito
ść
i powtarzalno
ść
(na przykład testy wykonywane przy pomocy
narz
ę
dzia lub przypadki testowe uzyskane z wymaga
ń
).
•
Obiektywna ocena (na przykład miary statyczne, pokrycie i zachowanie systemu).
•
Łatwy dost
ę
p do danych o testach lub testowaniu (na przykład statystyki i grafy
obrazuj
ą
ce post
ę
p testowania, liczba zdarze
ń
lub wydajno
ść
).
Zagro
ż
enia wi
ążą
ce si
ę
z zastosowaniem narz
ę
dzi:
•
Nierealistyczne oczekiwania wobec narz
ę
dzia (zarówno jego funkcjonalno
ś
ci, jak i
łatwo
ś
ci posługiwania si
ę
narz
ę
dziem).
•
Zani
ż
one oszacowanie czasu, kosztu oraz wysiłku pierwszego wdro
ż
enia
narz
ę
dzia (w tym kosztów szkole
ń
oraz zewn
ę
trznego wsparcia i doradztwa).
•
Zani
ż
one oszacowanie czasu i wysiłku niezb
ę
dnego, aby uzyska
ć
znacz
ą
ce i
stałe korzy
ś
ci z zastosowania narz
ę
dzia (w tym konieczno
ś
ci zmian w procesie
testowania oraz zapewnienia stałego doskonalenia sposobu wykorzystywania
narz
ę
dzia).
•
Zani
ż
one oszacowanie wysiłku zwi
ą
zanego z utrzymaniem testaliów
wygenerowanych przez narz
ę
dzie.
•
Zbytnie uzale
ż
nienie od narz
ę
dzia (np. automatyczne wykonywanie testów
zamiast projektowania testów lub testy automatyczne tam, gdzie r
ę
czne s
ą
skuteczniejsze).
6.2.2.
Zagadnienia specjalne dla niektórych rodzajów narz
ę
dzi (K1)
Narz
ę
dzia wspieraj
ą
ce wykonanie testów
Narz
ę
dzia wspieraj
ą
ce wykonanie testów s
ą
sterowane przechowywanymi w formie
elektronicznej skryptami, zaprojektowanymi tak, aby implementowa
ć
wykonanie testów.
Certyfikowany tester
Plan poziomu podstawowego
International Sotware Testing Qualifications Board
Stowarzyszenie Jako
ś
ci Systemów Informatycznych
Wersja 1.0
© Stowarzyszenie Jako
ś
ci Systemów
Informatycznych
Strona 66 z 78
20 pa
ź
dziernika 2006
Osi
ą
gni
ę
cie znacz
ą
cych korzy
ś
ci przy wykorzystaniu tego typu narz
ę
dzi zwykle wymaga
znacz
ą
cych nakładów.
Rejestrowanie skryptów testowych poprzez nagrywanie czynno
ś
ci wykonywanych podczas
r
ę
cznego testowania mo
ż
e si
ę
wydawa
ć
korzystne, ale ta metoda nie nadaje si
ę
do
stosowania przy du
ż
ej liczbie zautomatyzowanych testów. Zarejestrowany skrypt jest
liniowym odwzorowaniem, wykonanych podczas testu manualnego, czynno
ś
ci, stanowi
ą
cych
– wraz z danymi – elementy ka
ż
dego skryptu. Ten rodzaj skryptu mo
ż
e okaza
ć
si
ę
zawodny
w razie pojawienia si
ę
nieoczekiwanych wydarze
ń
.
Metodyka testowania w oparciu o dane oddziela testowe dane wej
ś
ciowe (dane testowe),
zwykle przechowywane w arkuszu kalkulacyjnym, oraz posługuje si
ę
ogólniejszym skryptem
testowym, odczytuj
ą
cym dane testowe i wykonuj
ą
cym ten sam test z ró
ż
nymi danymi.
Testerzy nieznaj
ą
cy j
ę
zyka skryptowego mog
ą
wówczas projektowa
ć
nowe testy
wprowadzaj
ą
c dane testowe wykorzystywane przez z góry zdefiniowane skrypty.
W metodyce testowania w oparciu o słowa kluczowe umieszcza si
ę
w arkuszu kalkulacyjnym
zarówno słowa klucze okre
ś
laj
ą
ce, jak
ą
czynno
ść
nale
ż
y wykona
ć
(nazywane te
ż
słowami
czynno
ś
ciowymi), jak i dane testowe. Testerzy, nawet nieznaj
ą
cy j
ę
zyka skryptowego, mog
ą
projektowa
ć
testy posługuj
ą
c si
ę
słowami kluczami, które powinny by
ć
dostosowane do
rodzaju testowanej aplikacji.
Ka
ż
da z metodyk wymaga dobrej znajomo
ś
ci j
ę
zyka skryptowego, albo przez testerów, albo
przez specjalistów od automatyzacji.
Niezale
ż
nie od stosowanej metodyki, niezb
ę
dne jest gromadzenie i przechowywanie
wyników oczekiwanych testów, w celu ich wykorzystania do porównania z przyszłymi
wynikami rzeczywistymi.
Narz
ę
dzia do testów wydajno
ś
ci
Zastosowanie narz
ę
dzi do testów wydajno
ś
ci wymaga wsparcia ze strony eksperta w
dziedzinie testów wydajno
ś
ciowych przy projektowaniu testów oraz interpretacji ich wyników.
Narz
ę
dzia do analizy statycznej
Narz
ę
dzia do analizy statycznej zastosowane do kodu
ź
ródłowego umo
ż
liwiaj
ą
narzucanie
standardów kodowania, ale generuj
ą
bardzo wiele komunikatów, gdy u
ż
ywa si
ę
ich do ju
ż
istniej
ą
cego kodu. Komunikaty ostrze
ż
e
ń
nie blokuj
ą
przetłumaczenia kodu
ź
ródłowego na
wykonywalny, ale powinno si
ę
ich unika
ć
, aby ułatwi
ć
przyszłe utrzymanie kodu. Skuteczne
podej
ś
cie polega na stopniowym wdro
ż
eniu z zastosowaniem wst
ę
pnych filtrów, które
blokuj
ą
niektóre zb
ę
dne komunikaty.
Narz
ę
dzia do zarz
ą
dzania testami
Chc
ą
c selekcjonowa
ć
i przedstawia
ć
informacj
ę
w formacie jak najlepiej pasuj
ą
cym do
bie
żą
cych potrzeb organizacji, narz
ę
dzia do zarz
ą
dzania testowaniem musz
ą
porozumiewa
ć
si
ę
z innymi narz
ę
dziami lub arkuszami kalkulacyjnymi. Raporty, aby były opłacalne, musz
ą
by
ć
odpowiednio zaprojektowane oraz monitorowane i analizowane.
Certyfikowany tester
Plan poziomu podstawowego
International Sotware Testing Qualifications Board
Stowarzyszenie Jako
ś
ci Systemów Informatycznych
Wersja 1.0
© Stowarzyszenie Jako
ś
ci Systemów
Informatycznych
Strona 67 z 78
20 pa
ź
dziernika 2006
6.3. Wdro
ż
enie narz
ę
dzia w organizacji (K1), 15 minut
Terminologia
Brak szczególnej terminologii w tym rozdziale.
Wprowadzenie
Główne zasady wdro
ż
enia narz
ę
dzi w organizacji obejmuj
ą
:
•
Ocen
ę
dojrzało
ś
ci organizacyjnej, silnych i słabych stron procesu, oraz
identyfikacj
ę
mo
ż
liwo
ś
ci udoskonalenia procesu testowego wspomaganego
narz
ę
dziami.
•
Ocen
ę
wdro
ż
enia wobec jasnych wymaga
ń
przy pomocy obiektywnych kryteriów.
•
Wst
ę
pn
ą
prób
ę
wdro
ż
enia w celu sprawdzenia wymaganej funkcjonalno
ś
ci i
zgodno
ś
ci narz
ę
dzia z celami.
•
Ocen
ę
dostawcy narz
ę
dzia (w tym szkole
ń
, wsparcia dla klientów oraz aspektów
ekonomicznych).
•
Oszacowanie wewn
ę
trznych potrzeb w zakresie doradztwa indywidualnego oraz
wsparcia w posługiwaniu si
ę
narz
ę
dziem.
Wst
ę
pn
ą
prób
ę
wdro
ż
enia najlepiej przeprowadzi
ć
w formie niewielkiego projektu
pilota
ż
owego, co pozwoli na zminimalizowanie kosztów poniesionych w razie natkni
ę
cia si
ę
na znaczne trudno
ś
ci i niepowodzenia projektu pilota
ż
owego.
Cele projektu pilota
ż
owego:
•
Szczegółowe zapoznanie si
ę
z narz
ę
dziem.
•
Sprawdzenie, jak posługiwanie si
ę
narz
ę
dziem pasuje do istniej
ą
cych procesów i
praktyk, oraz identyfikacja ewentualnie potrzebnych zmian.
•
Okre
ś
lenie procedur posługiwania si
ę
, utrzymywania, przechowywania narz
ę
dzia i
zwi
ą
zanych z nim testaliów (np. okre
ś
lenie zasad nazywania plików i testów,
tworzenia bibliotek oraz okre
ś
lania szczegółowo
ś
ci scenariuszy testowych).
•
Oszacowanie, na ile korzy
ś
ci z zastosowania narz
ę
dzia dadz
ą
si
ę
osi
ą
gn
ąć
przy
opłacalnych nakładach.
Czynniki, od których zale
ż
y powodzenie wdro
ż
enia narz
ę
dzia w organizacji:
•
Stopniowe (przyrostowe) wdro
ż
enie narz
ę
dzia w pozostałej cz
ęś
ci organizacji, nie
obj
ę
tej projektem pilota
ż
owym.
•
Dostosowanie i udoskonalenie procesów tak, aby współdziałały z u
ż
yciem
narz
ę
dzia.
•
Udost
ę
pnienie szkole
ń
oraz doradztwa dla nowych u
ż
ytkowników.
•
Okre
ś
lenie wytycznych dla posługiwania si
ę
narz
ę
dziem.
•
Wdro
ż
enie metodyki gromadzenia i wykorzystywania do
ś
wiadcze
ń
z posługiwania
si
ę
narz
ę
dziem.
•
Nadzorowanie i monitorowanie wykorzystania oraz korzy
ś
ci z zastosowania
narz
ę
dzia.
Certyfikowany tester
Plan poziomu podstawowego
International Sotware Testing Qualifications Board
Stowarzyszenie Jako
ś
ci Systemów Informatycznych
Wersja 1.0
© Stowarzyszenie Jako
ś
ci Systemów
Informatycznych
Strona 68 z 78
20 pa
ź
dziernika 2006
Referencje
6.2.2 Buwalda, 2001, Fewster, 1999
6.3 Fewster, 1999
Certyfikowany tester
Plan poziomu podstawowego
International Sotware Testing Qualifications Board
Stowarzyszenie Jako
ś
ci Systemów Informatycznych
Wersja 1.0
© Stowarzyszenie Jako
ś
ci Systemów
Informatycznych
Strona 69 z 78
20 pa
ź
dziernika 2006
7. Referencje
Normy
ISTQB Glossary of terms used in Software Testing Version 1.0
[CMMI] Chrissis, M.B., Konrad, M. and Shrum, S. (2004) CMMI, Guidelines for Process
Integration and Product Improvement, Addison Wesley: Reading, MA; por. rozdz. 2.1
[IEEE 829] IEEE Std 829™ (1998/2005) IEEE Standard for Software Test Documentation
(obecnie w trakcie modyfikacji); por. rozdz. 2.3, 2.4, 4.1, 5.2, 5.3, 5.5, 5.6
[IEEE 1028] IEEE Std 1028™ (1997) IEEE Standard for Software Reviews; zob. rozdz.3.2
[IEEE 12207] IEEE 12207/ISO/IEC 12207-1996, Software life cycle processes; zob rozdz.
2.1
[ISO 9126] ISO/IEC 9126-1:2001, Software Engineering – Software Product Quality; zob.
rozdz. 2.3
Ksi
ąż
ki
[Beizer, 1990] Beizer, B. (1990) Software Testing Techniques (2nd edition), Van Nostrand
Reinhold: Boston zob. rozdz. 1.2, 1.3, 2.3, 4.2, 4.3, 4.4, 4.6
[Black, 2001] Black, R. (2001) Managing the Testing Process (2nd edition), John Wiley &
Sons: New York; zob. rozdz. 1.1, 1.2, 1.4, 1.5, 2.3, 2.4, 5.1, 5.2, 5.3, 5.5, 5.6
[Buwalda, 2001] Buwalda, H. et al. (2001) Integrated Test Design and Automation, Addison
Wesley: Reading, MA; zob. rozdz. 6.2
[Copeland, 2004] Copeland, L. (2004) A Practitioner’s Guide to Software Test Design, Artech
House: Norwood, MA; zob. rozdz. 2.2, 2.3, 4.2, 4.3, 4.4, 4.6
[Craig, 2002] Craig, Rick D. and Jaskiel, Stefan P. (2002) Systematic Software Testing,
Artech House: Norwood, MA; zob. rozdz. 1.4.5, 2.1.3, 2.4, 4.1, 5.2.5, 5.3, 5.4
[Fewster, 1999] Fewster, M. and Graham, D. (1999) Software Test Automation, Addison
Wesley: Reading, MA; zob. rozdz. 6.2, 6.3
[Gilb, 1993]: Gilb, Tom and Graham, Dorothy (1993) Software Inspection, Addison Wesley:
Reading, MA; zob. rozdz. 3.2.2, 3.2.4
[Hetzel, 1988] Hetzel, W. (1988) Complete Guide to Software Testing, QED: Wellesley, MA;
zob. rozdz. 1.3, 1.4, 1.5, 2.1, 2.2, 2.3, 2.4, 4.1, 5.1, 5.3
[Kaner, 2002] Kaner, C., Bach, J. and Pettticord, B. (2002) Lessons Learned in Software
Testing, John Wiley & Sons; zob. rozdz. 1.1, 4.5, 5.2
[Myers 1979] Myers, Glenford J. (1979) The Art of Software Testing, John Wiley & Sons;
zob. rozdz. 1.2, 1.3, 2.2, 4.3
[van Veenendaal, 2004] van Veenendaal, E. (ed.) (2004) The Testing Practitioner (Chapters
6, 8, 10), UTN Publishers: The Netherlands; zob. rozdz. 3.2, 3.3
Certyfikowany tester
Plan poziomu podstawowego
International Sotware Testing Qualifications Board
Stowarzyszenie Jako
ś
ci Systemów Informatycznych
Wersja 1.0
© Stowarzyszenie Jako
ś
ci Systemów
Informatycznych
Strona 70 z 78
20 pa
ź
dziernika 2006
Zał
ą
cznik A – Pochodzenie planu
Historia tego dokumentu
Dokument został przygotowany przez robocz
ą
grup
ę
składaj
ą
c
ą
si
ę
z członków wyłonionych
przez International Software Testing Qualifications Board (ISTQB). Pocz
ą
tkowo był
przegl
ą
dany przez wybrany panel przegl
ą
dowy a potem przez reprezentantów wybranych z
mi
ę
dzynarodowej społeczno
ś
ci zajmuj
ą
cej si
ę
testowaniem oprogramowania. Zasady
zastosowane przy tworzeniu tego dokumentu pokazane s
ą
w Zał
ą
czniku C.
Dokument ten jest planem dla Mi
ę
dzynarodowego Certyfikatu Podstawowego w Testowaniu
Oprogramowania, pierwszego poziomu mi
ę
dzynarodowej kwalifikacji zaaprobowanego przez
ISTQB (www.istqb.org). W czasie pisania tego dokumentu (2005) w skład ISTQB wchodziły
Austria, Dania, Finlandia, Francja, Niemcy, Indie, Izrael, Japonia, Korea, Norwegia, Polska,
Portugalia, Hiszpania, Szwecja, Szwajcaria, Holandia, Wielka Brytania i USA.
Cele Certyfikatu Podstawowego
Poznanie testowania jako podstawowej i profesjonalnej specjalizacji in
ż
ynierii
oprogramowania.
Zapewnienie standardu dla rozwoju kariery testera.
Umo
ż
liwienie rozpoznawania profesjonalnie wykwalifikowanych testerów przez
pracodawców, klientów i kolegów oraz podwy
ż
szenie statusu testerów.
Promowanie konsekwentnych i dobrych praktyk testowania w dyscyplinach in
ż
ynierii
oprogramowania.
Zidentyfikowanie tematów testowania, które s
ą
istotne i warto
ś
ciowe dla przemysłu.
Umo
ż
liwienie dostawcom oprogramowania wynaj
ę
cie certyfikowanych testerów i dzi
ę
ki temu
uzyskanie handlowej przewagi nad ich konkurentami przez zareklamowanie własnej polityki
zatrudnienia testerów.
Zapewnienie testerom i osobom zainteresowanym testowaniem okazji nabycia
rozpoznawanych na arenie mi
ę
dzynarodowej kwalifikacji w tym temacie.
Cele mi
ę
dzynarodowej kwalifikacji (przyj
ę
te na spotkaniu ISTQB w
Sollentuna, listopad 2001)
Umo
ż
liwienie porównania umiej
ę
tno
ś
ci testowania w ró
ż
nych krajach.
Umo
ż
liwienie testerom łatwiejszego przekraczania granic krajów.
Umo
ż
liwienie wielonarodowym/mi
ę
dzynarodowym projektom wspólnego zrozumienia
zagadnie
ń
z zakresu testowania.
Zwi
ę
kszenie liczby wykwalifikowanych testerów na
ś
wiecie.
Posiadanie wi
ę
kszego wpływu/warto
ś
ci jako inicjatywa umocowana mi
ę
dzynarodowo ni
ż
specyficzne podej
ś
cie z jednego kraju.
Rozwini
ę
cie wspólnej mi
ę
dzynarodowej grupy zrozumienia i wiedzy o testowaniu dzi
ę
ki
planowi i terminologii oraz wzrost poziomu wiedzy na temat testowania u wszystkich
uczestników.
Promowanie testowania jako zawodu w wielu krajach.
Umo
ż
liwienie testerom uzyskania rozpoznawanych kwalifikacji w ich ojczystych j
ę
zykach.
Umo
ż
liwienie dzielenia si
ę
wiedz
ą
i zasobami pomi
ę
dzy krajami.
Zapewnienie mi
ę
dzynarodowego poznania testerów i kwalifikacji z powodu uczestnictwa z
wielu krajów.
Certyfikowany tester
Plan poziomu podstawowego
International Sotware Testing Qualifications Board
Stowarzyszenie Jako
ś
ci Systemów Informatycznych
Wersja 1.0
© Stowarzyszenie Jako
ś
ci Systemów
Informatycznych
Strona 71 z 78
20 pa
ź
dziernika 2006
Wymagania wobec kandydatów
Podstawowym wymaganiem wobec kandydatów na Certyfikat ISTQB z Testowania
Oprogramowania jest zainteresowanie testowaniem oprogramowania. Ponadto obowi
ą
zuj
ą
nast
ę
puj
ą
ce zalecenia:
•
Kandydaci powinni mie
ć
co najmniej sze
ś
ciomiesi
ę
czne do
ś
wiadczenie w
wytwarzaniu oprogramowania albo w testach akceptacyjnych lub systemowych.
•
Kandydaci powinni wzi
ąć
udział w kursie ISTQB (akredytowanym przez narodow
ą
organizacj
ę
uznan
ą
przez ISTQB).
Okoliczno
ś
ci powstania i historia Podstawowego Certyfikatu w
Testowaniu Oprogramowania
Niezale
ż
na certyfikacja testerów oprogramowania rozpocz
ę
ła si
ę
w Wielkiej Brytanii wraz z
powstaniem w 1998 Software Testing Board (
www.bcs.org.uk/iseb
) pod auspicjami ISEB (the
British Computer Society’s Information Systems Examination Board). W 2002 roku,
niemiecka ASQF stworzyła niemiecki system kwalifikacji testerów (
www.asqf.de
). Niniejszy
plan sporz
ą
dzono na podstawie planów ISEB i ASQF. Jego tre
ść
jest cz
ęś
ciowo nowa,
cz
ęś
ciowo zreorganizowana i zmieniona, za
ś
nacisk poło
ż
ony jest na zapewnienie testerom
maksymalnie praktycznego wsparcia.
Istniej
ą
ce Certyfikaty Podstawowe Testowania Oprogramowania (np. z ISEB, ASQF lub
narodowej organizacji ISTQB), przyznane przed powstaniem certyfikatu mi
ę
dzynarodowego,
b
ę
d
ą
uznawane za równowa
ż
ne certyfikatowi mi
ę
dzynarodowemu. Certyfikat Podstawowy
nie wygasa i nie potrzebuje by
ć
odnawiany. Data przyznania znajduje si
ę
na Certyfikacie.
Narodowe organizacje ISTQB nadzoruj
ą
miejscowe zagadnienia w swoich krajach.
Obowi
ą
zki narodowych organizacji okre
ś
la ISTQB, lecz ich realizacja pozostawiona jest
samym organizacjom. Do obowi
ą
zków organizacji krajowych nale
ż
y akredytacja dostawców
szkole
ń
i wyznaczenie egzaminów.
Certyfikowany tester
Plan poziomu podstawowego
International Sotware Testing Qualifications Board
Stowarzyszenie Jako
ś
ci Systemów Informatycznych
Wersja 1.0
© Stowarzyszenie Jako
ś
ci Systemów
Informatycznych
Strona 72 z 78
20 pa
ź
dziernika 2006
Zał
ą
cznik B – Cel nauki i poziomy wiedzy
Niniejszy plan okre
ś
la opisane poni
ż
ej cele nauczania. Ka
ż
dy z tematów planu uwzgl
ę
dniony
jest w trakcie egzaminu zgodnie z okre
ś
lonym dla niego celem.
Poziom 1: Zapami
ę
ta
ć
(K1)
Kandydat rozpoznaje, pami
ę
ta i umie okre
ś
li
ć
termin lub poj
ę
cie.
Przykład
Rozpoznanie definicji „awarii”: jako:
•
„brak funkcjonalno
ś
ci u
ż
ytkownika ko
ń
cowego lub innego interesariusza” lub jako
•
„niezgodno
ść
rzeczywistego działania modułu lub systemu z działaniem lub wynikiem
oczekiwanym”.
Poziom 2: Zrozumie
ć
(K2)
Kandydat potrafi uzasadni
ć
lub wyja
ś
ni
ć
zagadnienia z zakresu tematu oraz podsumowa
ć
,
porówna
ć
, klasyfikowa
ć
i podawa
ć
przykłady dla ró
ż
nych poj
ęć
z zakresu testowania.
Przykłady
Uzasadni
ć
, dlaczego testy powinny by
ć
projektowane jak najwcze
ś
niej:
•
W celu znalezienia bł
ę
dów wówczas, gdy ich usuni
ę
cie jest mniej kosztowne.
•
Aby najwa
ż
niejsze bł
ę
dy znale
źć
wcze
ś
niej.
Wyja
ś
ni
ć
podobie
ń
stwa i ró
ż
nice pomi
ę
dzy testowaniem integracyjnym i systemowym:
•
Podobie
ń
stwa: testowanie wi
ę
cej ni
ż
jednego modułu oraz mo
ż
liwo
ść
testowania
wła
ś
ciwo
ś
ci.
•
Ró
ż
nice: testowanie integracyjne skupia si
ę
na interfejsach oraz na interakcji mi
ę
dzy
modułami, za
ś
testowanie systemowe skupia si
ę
na aspektach ogólnosystemowych,
takich jak przetwarzanie obejmuj
ą
ce cało
ś
ciow
ą
funkcjonalno
ść
.
Poziom 3: Zastosowanie (K3)
Kandydat potrafi wybra
ć
prawidłowe zastosowanie poj
ę
cia lub techniki i zastosowa
ć
je do
danego kontekstu.
Przykład
•
Mo
ż
e zidentyfikowa
ć
warto
ś
ci graniczne dla dozwolonych i niedozwolonych klas
równowa
ż
no
ś
ci.
•
Mo
ż
e wybra
ć
przypadki testowe z podanego diagramu przej
ść
stanów, aby pokry
ć
wszystkie przej
ś
cia.
Referencje
(Dla poznawczych poziomów celów nauki)
Anderson, L.W. i Krathwohl, D. R.(eds) (2001) A Taxonomy for Learning, Teaching, and
Accessing: A Revision of Bloom’s Taxonomy of Educational Objectives, Allyn& Bacon:
Certyfikowany tester
Plan poziomu podstawowego
International Sotware Testing Qualifications Board
Stowarzyszenie Jako
ś
ci Systemów Informatycznych
Wersja 1.0
© Stowarzyszenie Jako
ś
ci Systemów
Informatycznych
Strona 73 z 78
20 pa
ź
dziernika 2006
Zał
ą
cznik C – Zasady dotycz
ą
ce Planu poziomu
podstawowego ISTQB / SJSI
Zasady podane tutaj zostały u
ż
yte w projekcie i przegl
ą
dzie tego planu. (Po ka
ż
dej zasadzie
pokazany jest du
ż
ymi literami stenograficzny skrót zasady)
Ogólne zasady
SG1. Plan powinien by
ć
zrozumiały i przyswajalny przez osoby z do
ś
wiadczeniem w
testowaniu od 0 do 6 miesi
ę
cy (lub wi
ę
cej). (6 MIESI
Ę
CY)
SG2. Plan powinien by
ć
raczej praktyczny ni
ż
teoretyczny. (PRAKTYCZNY)
SG3. Plan powinien by
ć
jasny i niedwuznaczny dla jego czytelników. (JASNY)
SG4. Plan powinien by
ć
zrozumiały dla ludzi z ró
ż
nych krajów i da
ć
si
ę
łatwo przetłumaczy
ć
na ró
ż
ne j
ę
zyki. (PRZETŁUMACZALNY)
SG5. Plan powinien u
ż
ywa
ć
Ameryka
ń
skiego Angielskiego. (AMERYKA
Ń
SKI ANGIELSKI)
Bie
żą
ca tre
ść
SC1.Plan powinien obejmowa
ć
ostatnie koncepcje dotycz
ą
ce testowania i powinien
odzwierciedla
ć
najlepsz
ą
bie
żą
c
ą
praktyk
ę
w testowaniu oprogramowania tam, gdzie to
generalnie uzgodniono. Plan podlega przegl
ą
dowi co trzy do pi
ę
ciu lat. (OSTATNI)
SC2.Plan powinien pomniejsza
ć
wpływy zale
ż
ne od czasu, takie jak bie
żą
ce uwarunkowania
rynkowe, aby mie
ć
czas
ż
ycia od trzech do pi
ę
ciu lat. (AKTUALNY)
Cele nauki
LO1. Cele nauki powinny ró
ż
ni
ć
si
ę
pomi
ę
dzy pozycjami do rozpoznania/zapami
ę
tania
(poznawczy poziom K1), pozycjami, które kandydat powinien zrozumie
ć
koncepcyjnie (K2) i
tymi, które kandydat powinien potrafi
ć
zastosowa
ć
w praktyce (K3) (POZIOM WIEDZY)
LO2. Opis tre
ś
ci powinien by
ć
spójny z celami nauki. (SPÓJNY Z CELAMI NAUKI)
LO3. Aby zilustrowa
ć
cele nauki, pytania próbnego egzaminu dla ka
ż
dej wi
ę
kszej sekcji
powinny wynika
ć
z planu. (CELE NAUKI-EGZAMIN)
Ogólna struktura
ST1. Struktura planu powinna by
ć
jasna i pozwoli
ć
na odsyłanie do i z innych cz
ęś
ci, z pyta
ń
egzaminacyjnych i z innych istotnych dokumentów. (ODSYŁANIE)
ST2.Pokrywanie si
ę
pomi
ę
dzy sekcjami planu powinno by
ć
zminimalizowane.
(POKRYWANIE SI
Ę
)
ST3. Ka
ż
da sekcja planu powinna mie
ć
t
ą
sam
ą
struktur
ę
. (SPÓJNA STRUKTURA)
ST4.Plan powinien zawiera
ć
wersj
ę
, dat
ę
wydania i numer strony na ka
ż
dej stronie.
(WERSJA)
ST5. Plan powinien zawiera
ć
wskazówk
ę
odno
ś
nie potrzebnej ilo
ś
ci czasu dla ka
ż
dego
rozdziału (aby odzwierciedli
ć
wzgl
ę
dn
ą
wag
ę
ka
ż
dego tematu). (POTRZEBNY CZAS)
Referencje
SR1.
Ź
ródła i referencje zostan
ą
podane dla koncepcji w konspekcie, aby pomóc dostawcom
szkole
ń
znale
źć
wi
ę
cej informacji na wybrany temat. (REFERENCJE)
Certyfikowany tester
Plan poziomu podstawowego
International Sotware Testing Qualifications Board
Stowarzyszenie Jako
ś
ci Systemów Informatycznych
Wersja 1.0
© Stowarzyszenie Jako
ś
ci Systemów
Informatycznych
Strona 74 z 78
20 pa
ź
dziernika 2006
SR2. Tam, gdzie nie ma zidentyfikowanych i jasnych
ź
ródeł powinno si
ę
dostarczy
ć
wi
ę
cej
szczegółów w konspekcie. Na przykład, definicje s
ą
w słowniku, a wi
ę
c w konspekcie
przytoczono jedynie terminologie. (SZCZEGÓŁY BEZ REFERENCJI)
Ź
ródła informacji
Terminologia u
ż
yta w konspekcie, dla poj
ęć
u
ż
ywanych w testowaniu oprogramowania,
zdefiniowana jest w Słowniku ISTQB. Wersja słownika jest dost
ę
pna na stronie ISTQB lub
SJSI.
Lista zalecanych ksi
ąż
ek na temat testowania oprogramowania podana jest w konspekcie.
Główna lista ksi
ąż
ek jest cz
ęś
ci
ą
sekcji Referencje.
Certyfikowany tester
Plan poziomu podstawowego
International Sotware Testing Qualifications Board
Stowarzyszenie Jako
ś
ci Systemów Informatycznych
Wersja 1.0
© Stowarzyszenie Jako
ś
ci Systemów
Informatycznych
Strona 75 z 78
20 pa
ź
dziernika 2006
Zał
ą
cznik D – Informacja dla dostawców szkole
ń
Dla ka
ż
dego z głównych tematów planu przeznaczony jest okre
ś
lony w minutach czas jego
trwania. Celem tego jest zarówno wyznaczenie wzgl
ę
dnych proporcji poszczególnych sekcji
tematycznych akredytowanego szkolenia wzgl
ę
dem siebie, jak i wyznaczenie przybli
ż
onego
minimalnego czasu, który nale
ż
y przeznaczy
ć
na nauczanie poszczególnych tematów.
Dostawcy szkole
ń
mog
ą
po
ś
wi
ę
ci
ć
im wi
ę
cej czasu, za
ś
kandydaci mog
ą
sp
ę
dzi
ć
dodatkowy
czas na lekturze i własnych badaniach. Kolejno
ść
omawiania zagadnie
ń
podczas kursu nie
musi by
ć
taka sama jak w konspekcie.
Plan zawiera odwołania do uznanych norm, z których nale
ż
y skorzysta
ć
podczas
przygotowywania materiałów szkoleniowych. Zalecane jest korzystanie z tej wersji normy, do
której odwołuje si
ę
bie
żą
ca wersja planu. Mo
ż
na odwoływa
ć
si
ę
lub wykorzystywa
ć
tak
ż
e
inne publikacje, wzorce lub normy poza okre
ś
lonymi w konspekcie, ale nie b
ę
d
ą
one
przedmiotem egzaminu.
Nast
ę
puj
ą
ce obszary tematyczne planu wymagaj
ą
ć
wicze
ń
praktycznych:
4.3 Techniki na podstawie specyfikacji lub czarnoskrzynkowe
Praktyczne, krótkie
ć
wiczenia powinny dotyczy
ć
czterech technik: podziału na klasy
równowa
ż
no
ś
ci, analizy warunków brzegowych, testowania tabeli decyzyjnej oraz testowanie
przej
ść
stanów. Wykład oraz
ć
wiczenia dotycz
ą
ce tych technik powinny by
ć
zrobione na
podstawie referencji podanych dla ka
ż
dej z nich.
4.4 Techniki na podstawie struktury lub białoskrzynkowe
Praktyczne, krótkie
ć
wiczenia powinny dotyczy
ć
sprawdzenia, czy dany zestaw przypadków
testowych pozwala na 100% pokrycia instrukcji lub 100% pokrycia decyzji, a tak
ż
e
projektowania przypadków testowych dla okre
ś
lonych przepływów sterowania.
5.6 Zarz
ą
dzanie incydentami
Nale
ż
y zastosowa
ć
krótkie
ć
wiczenie, polegaj
ą
ce albo na napisaniu, albo ocenie pisemnego
zgłoszenia incydentu.
Certyfikowany tester
Plan poziomu podstawowego
International Sotware Testing Qualifications Board
Stowarzyszenie Jako
ś
ci Systemów Informatycznych
Wersja 1.0
© Stowarzyszenie Jako
ś
ci Systemów
Informatycznych
Strona 76 z 78
20 pa
ź
dziernika 2006
Indeks
A
analiza statyczna, 29, 30, 34
analiza wartości brzegowych, 35, 39
analiza wpływu, 28
automatyzacja, 26, 47
automatyzacja testów, 47
awaria, 10, 11
B
błąd, 10, 11, 16
C
cecha, 37
cele testowania, 15, 16, 20
cykl życia, 21, 43
czas odpowiedzi, 27
częstotliwość awarii, 51
czynności poza testowaniem, 55
czynności testowe, 14
czynność testowa, 21
D
dane testowe, 15, 37, 62, 66
dane wejściowe, 62, 66
debager, 59
debagowanie, 13, 27
decyzja, 12
defekt, 10, 11, 13, 31, 34
diagram przejść pomiędzy stanami, 40
dokumentacja testowa, 53
domyślanie się błędów, 49
działanie, 11, 40, 48, 63
E
efekt próbnika, 59
efektywność, 11, 33
F
funkcja, 37, 62
funkcjonalność, 24, 26, 54, 72
H
harmonogram, 37
harmonogram wykonania testu, 37
I
incydent, 15, 56
inspekcja, 29, 31, 32, 33
instrukcja, 56
integracja, 15, 23
interfejs, 34, 59
iteracyjny, 23
J
jakość, 10, 11, 12, 18, 46, 47, 54
jarzmo testowe, 59, 62
język skryptowy, 62, 65
K
kierownik jakości, 46
kierownik testów, 18, 46
kod, 11, 12, 13, 18, 21, 23, 30, 34, 41, 61, 66
kod źródłowy, 21
kompilator, 34
koszty testowania, 51
kryteria wejścia, 48
kryteria wejściowe, 31
L
lista kontrolna, 32
log testu, 15
logowanie wyników testów, 60
Ł
łatwość testowania, 48
M
menedżer testów, 46
metodyka testowa, 48, 51, 55, 66
metodyka testowania, 55, 66
miara, 27
migracja, 20, 28
model automatu skończonego (przejść stanów), 26
model przepływu procesu, 26
model wytwarzania, 21
moduł, 24, 62
modyfikacja, 20
monitorowanie postępu testów, 51
monitorowanie testowania, 51
N
nadzorowanie procesu testowego, 44
nadzór nad testowaniem, 15, 51
najistotniejsze, 55
narzędzia do analizy dynamicznej, 63
narzędzia do analizy statycznej, 34, 61, 63, 66
narzędzia do zarządzania testami, 59, 66
narzędzia wspierające projektowanie testów, 61
narzędzia wspierające testowanie, 63
narzędzie, 34, 59, 65
narzędzie do analizy statycznej, 59
narzędzie do pomiaru pokrycia, 59
narzędzie do testów wydajności, 59
narzędzie do testów wydajnościowych, 59
narzędzie do testów zabezpieczeń, 59
narzędzie do zarządzania konfiguracją, 59
Certyfikowany tester
Plan poziomu podstawowego
International Sotware Testing Qualifications Board
Stowarzyszenie Jako
ś
ci Systemów Informatycznych
Wersja 1.0
© Stowarzyszenie Jako
ś
ci Systemów
Informatycznych
Strona 77 z 78
20 pa
ź
dziernika 2006
narzędzie do zarządzania wymaganiami, 59
narzędzie wspierające wykonanie testu, 59
niezależność testowania, 46
niezależny tester, 46
niezależny zespół testowy, 18, 24
niezawodność, 11, 13, 26, 54, 59
O
ocena, 13, 15, 16, 49, 51, 65
oczekiwany wynik, 35
oparte na słowach kluczowych, 65
operacyjne testy akceptacyjne, 23, 25
oprogramowanie, 11, 17, 18, 21, 25, 27, 38, 40, 42, 46,
54, 55
oprogramowanie wbudowane, 40
oprogramowanie z półki, 21, 25
organizacja wytwarzająca oprogramowanie, 24
osoba wykonująca przegląd, 56
oszacowanie, 44, 47, 49, 65, 67
P
plan testów, 15, 48
planowanie integracji, 24
planowanie ryzyka, 44
planowanie testowania, 47, 48
planowanie testów, 15, 24, 53
pluskwa, 10, 11
podejście, 21, 24, 27, 35, 37, 42, 66, 70
podejście białoskrzynkowe, 35
podejście czarnoskrzynkowe, 35
podejście strukturalne, 27
podstawa testów, 13, 15, 23
pokrycie, 15, 26, 27, 35, 39, 41, 48, 51, 60, 65
pokrycie danych wejściowych, 39
pokrycie decyzji, 41
pokrycie instrukcji kodu, 41
pokrycie kodu, 26, 41, 48
pokrycie testowe, 15, 27, 51
pokrycie wymagań, 51
polityka testów, 48
pomyłka, 10, 11, 16
ponownie przetestowane, 52
poziom testów, 21
pracochłonność testowania, 49
procedura testowa, 35
proces biznesowy, 41
proces testowania, 13
proces testowy, 10, 15, 29, 30
projekt, 16, 17
projektowanie przypadków testowych, 35, 37
projektowanie testów, 16, 21, 22, 37, 49
prototypowanie, 21
przebieg wykonania testów, 51
przegląd, 13, 29, 30, 31, 32, 33, 47
przegląd formalny, 31
przegląd koleżeński, 31, 32
przegląd nieformalny, 29, 31, 32
przegląd techniczny, 29, 31, 32
przejrzenie, 29, 31, 32
przepływ, 34, 41
przepływ danych, 34
przepływ sterowania, 34, 41
przetestowanie właściwości, 26
przypadek testowy, 13, 35, 37
przypadek użycia, 40
R
raport testowy, 51
raportowanie incydentów, 60
raportowanie testów, 16, 51
Rational Unified Process (RUP), 21
rejestracja danych testowych, 62
rozbudowa i udoskonalanie, 28
rusztowanie testowe, 62
ryzyko, 11, 12, 18, 24, 27, 36, 44, 50, 54, 55, 65
ryzyko produktowe, 54
ryzyko projektowe, 54
ryzyko związane z produktem, 54, 55
S
scenariusz testowy, 26, 27
skrypt testowy, 37
specyfikacja, 26, 28, 37
specyfikacja procedury testowej, 37
sprzęt, 23, 54
staranność testowania, 24, 27
statyczne techniki testowania, 29, 30
sterownik, 59
strategia testowa, 15, 48
strategia testowania, 15
system, 11, 13, 14, 21, 22, 23, 24, 26, 28, 39, 40, 71
system operacyjny, 23
szybkie wytwarzanie oprogramowania, 21
Ś
ś
ledzenie powiązań, 35, 37, 60, 63
ś
rodowisko produkcyjne, 24
ś
rodowisko testowe, 15, 16, 23, 51
T
tablica decyzyjna, 24, 39
techniki projektowania testów, 35, 36, 38
techniki testowania., 55
tester, 1, 18, 32, 46, 56
testować, 12, 18, 24, 37, 55
testowanie, 8, 9, 10, 11, 12, 13, 14, 15, 16, 17, 18, 20, 21,
22, 23, 24, 25, 26, 27, 28, 30, 34, 35, 39, 40, 41, 42, 44,
46, 47, 48, 49, 51, 54, 55, 58, 60, 61, 62, 63, 65, 72, 75
testowanie akceptacyjne, 21, 22, 23, 25
testowanie akceptacyjne przez użytkownika, 23, 25
testowanie alfa, 23, 25
testowanie beta, 23, 25
testowanie białoskrzynkowe, 26, 41
testowanie decyzyjne, 35, 41
testowanie dynamiczne, 30, 34
testowanie eksploracyjne, 42, 48, 49
testowanie funkcji, 26
testowanie funkcjonalne, 24, 26
testowanie gruntowne, 14
testowanie instrukcji, 35, 41
testowanie integracyjne, 21, 22, 23, 72
testowanie integracyjne modułów, 21
testowanie integracyjne systemów, 21
Certyfikowany tester
Plan poziomu podstawowego
International Sotware Testing Qualifications Board
Stowarzyszenie Jako
ś
ci Systemów Informatycznych
Wersja 1.0
© Stowarzyszenie Jako
ś
ci Systemów
Informatycznych
Strona 78 z 78
20 pa
ź
dziernika 2006
testowanie modułowe, 13, 21, 23, 35
testowanie na podstawie ryzyka, 49, 54, 55
testowanie na podstawie struktury, 41
testowanie niefunkcjonalne, 26
testowanie niezależne, 18
testowanie niezawodności, 26
testowanie obciążeniowe, 26
testowanie odporności, 23
testowanie potwierdzające, 13, 15, 16, 26, 27, 60
testowanie przeciążające, 26
testowanie przejść pomiędzy stanami, 39, 40
testowanie regresywne, 15, 16, 26, 27
testowanie statyczne wspierane narzędziami, 61
testowanie stochastyczne, 49
testowanie strukturalne, 23, 26, 27, 41
testowanie systemowe, 21, 23, 24, 72
testowanie użyteczności, 26
testowanie w fazie utrzymania, 20, 28
testowanie w oparciu o przypadki użycia, 39, 40
testowanie w oparciu o specyfikację, 26
testowanie właściwości, 24, 26
testowanie współdziałania, 26
testowanie wydajnościowe, 26
testowanie zabezpieczeń, 26
testowanie związane ze zmianami, 27
testy, 13, 14, 15, 18, 20, 21, 22, 23, 24, 25, 26, 27, 28, 35,
37, 39, 40, 42, 44, 49, 61, 65, 66, 72
testy akceptacji produkcyjnej, 25
testy akceptacyjne zgodności legislacyjnej, 23, 25
testy akceptacyjne zgodności z umową, 23, 25
testy integracji z infrastrukturą, 22
testy integracyjne systemów, 24
testy migracji danych, 28
testy modułowe, 23
testy modułu, 26
testy odbiorcze i wdrożeniowe, 22
testy regresywne, 21, 28, 37
testy w środowisku produkcyjnym, 23, 25
tworzenie specyfikacji testów wspierane narzędziami, 61
typowe metryki, 44
typy testów, 20, 27
U
usterka, 11
utrzymywalność, 11
użyteczność, 11, 26, 54
W
walidacja, 21
warunek testowy, 15, 35, 37
warunki wejściowe, 39
warunki wyjścia, 15, 31
wdrożenie, 15, 55, 58, 67
wejściowe dane testowe, 61
weryfikacja, 13, 16, 21, 23, 25, 26
wstępujące, 24
wycofanie systemu, 20, 28
wydajność, 54, 65
wykonywanie testów, 47, 62, 65
wykonywanie testów wspierane narzędziami, 62
wymaganie, 13
wyniki testów, 48, 51
wysoka wartość miary złożoności, 34
wytwarzanie sterowane testowaniem, 23
wytwarzanie w modelu iteracyjnym, 21
Z
zabezpieczenia, 54
zachowanie systemu, 65
zadania testowe, 46, 47, 48
zagrożenie, 50
zakres testowania, 48
zarządzanie incydentami, 45, 56, 75
zarządzanie konfiguracją, 44, 53
zarządzanie testowaniem, 44, 59
zarządzanie testowaniem wspierane narzędziami, 59
zarządzanie wersjami, 59
zarządzaniu ryzykiem, 55
zdolność do konserwacji, 30
zestawy testów do testów regresywnych, 27
zgadywanie błędów, 18, 42
zgłoszenie, 17, 56
zgłoszenie incydentu, 56
złożoność, 34, 61
zmiana, 52
zmiana wag testów, 52