asdsds

Certyfikowany tester

Plan poziomu podstawowego

International Sotware Testing Qualifications Board

Stowarzyszenie Jako

ci Systemów Informatycznych

Wersja 1.0

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

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

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

ęś

tłumaczenia innym stronom.

Certyfikowany tester

Plan poziomu podstawowego

International Sotware Testing Qualifications Board

Stowarzyszenie Jako

ci Systemów Informatycznych

Wersja 1.0

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

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

ci Systemów

Informatycznych

Strona 4 z 78

20 pa

dziernika 2006

Spis tre

Historia zmian.......................................................................................................................................................... 3

Spis tre

ci ................................................................................................................................................................ 4

Podzi

kowania ........................................................................................................................................................ 7

Wst

p do planu........................................................................................................................................................ 8

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

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

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

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

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

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

Zarz

dzanie testowaniem (K3), 180 minut.................................................................................................... 44

5.1.

Organizacja testowania (K2), 30 minut ................................................................................................................. 46

5.1.1.

Organizacja i niezale

ść

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

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

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.

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

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

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

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

zak, Łukasz

ebrowski.

Certyfikowany tester

Plan poziomu podstawowego

International Sotware Testing Qualifications Board

Stowarzyszenie Jako

ci Systemów Informatycznych

Wersja 1.0

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

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,

ynierowie testów, konsultanci testów, mened

erowie testów, testerzy akceptacji

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

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

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

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

ąć

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

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

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

ilo

ść

wymaganego czasu. Podsekcje, dla których nie podano czasu, wliczaj

do czasu

dla sekcji.

Certyfikowany tester

Plan poziomu podstawowego

International Sotware Testing Qualifications Board

Stowarzyszenie Jako

ci Systemów Informatycznych

Wersja 1.0

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

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

ęś

zapewnienia jako

ci i podania

przykładów, w jaki sposób testowanie pomaga osi

ąć

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

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

dego etapu testów. (K1)

1.5 Psychologia testowania (K2)

•

Wpływu czynników psychologicznych na sukces testów poprzez (K1):

Jasno zdefiniowane cele;

Równowag

dzy testami programistów a testami niezale

nymi;

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

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

yciu, pocz

wszy od rozwi

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

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

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

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

ść

utrzymywalno

ść

). Wi

cej informacji o testach niefunkcjonalnych znajduje si

w rozdziale 2.

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ł

Certyfikowany tester

Plan poziomu podstawowego

International Sotware Testing Qualifications Board

Stowarzyszenie Jako

ci Systemów Informatycznych

Wersja 1.0

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

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

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

yte do osi

gni

cia podobnych

celów. Oba podej

cia dostarcz

informacji koniecznych do poprawy testowanego

oprogramowania oraz procesu tworzenia i testowania oprogramowania.

na wyró

nast

puj

ce cele testów:

Znajdowanie defektów
Budowanie zaufania odno

nie jako

ci oraz dostarczanie informacji o jako

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

, 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ó

od siebie. Testowanie mo

e ujawni

awarie

spowodowane defektami. Debagowanie jest czynno

programistyczn

wykonywan

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

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

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ł

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

liwe wył

cznie w odniesieniu do bardzo trywialnych przypadków. Okre

laj

c zakres

testów, zamiast skupia

na testowaniu gruntownym, wykorzystujemy informacje o ryzyku

i priorytetach.

Zasada 3 – Wczesne testowanie

Czynno

ci testowe powinny rozpoczyna

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

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

eli te same testy s

gle powtarzane, ten sam zestaw przypadków testowych nie

znajduje ju

adnych nowych bł

dów.

eby przezwyci

ęŜ

paradoks pestycydów, przypadki

testowe musz

regularnie przegl

dane i korygowane. W celu sprawdzenia innych cz

ęś

oprogramowania lub systemu, aby potencjalnie znale

źć

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

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

ytkownika.

Certyfikowany tester

Plan poziomu podstawowego

International Sotware Testing Qualifications Board

Stowarzyszenie Jako

ci Systemów Informatycznych

Wersja 1.0

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

ęś

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

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

prac z planem i raportowanie wraz z informacj

o odchyleniach od zało

. 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

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

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

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

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,

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

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

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

ci Systemów

Informatycznych

Strona 18 z 78

20 pa

dziernika 2006

1.5. Psychologia testowania (K2), 35 minut

Terminologia

Testowanie niezale

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

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

ść

nie zast

puje jednak znajomo

ci programu; programi

ci mog

znale

źć

wiele

defektów we własnym kodzie. Zdefiniowano kilka poziomów niezale

ci:

•

Testy projektowane przez osob

(osoby), które pisały testowany program (niski

poziom niezale

ci).

•

Testy projektowane przez inn

osob

(osoby) (np. z zespołu wytwórczego).

•

Testy projektowane przez osob

(osoby) z innej grupy organizacyjnej (np. niezale

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

okre

lonymi celami. Ludzie maj

skłonno

ść

dopasowywania planów do celów okre

lonych przez kierownictwo lub innych interesariuszy,

na przykład, do znajdowania defektów, b

potwierdzania,

e oprogramowanie działa. St

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.

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

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

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

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

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

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

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

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

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

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

ęś

ci wytworzonych wcze

niej, stopniowo tworz

system, który równie

powinien by

poddany testowaniu. W ka

dej kolejnej iteracji coraz wa

niejsze staj

testy regresywne.

W ka

dej iteracji mo

na wykonywa

zarówno weryfikacj

jak i walidacj

2.1.3. Testowanie w cyklu

ycia (K2)

dy cykl

ycia systemu posiada kilka cech charakterystycznych dobrego testowania:

Dla ka

dej czynno

ci wytwarzania systemu istnieje odpowiadaj

ca jej czynno

ść

testowa.

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

ci Systemów

Informatycznych

Strona 22 z 78

20 pa

dziernika 2006

Analiza i projektowanie testów dla danego poziomu powinny rozpoczyna

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

operacyjnej).

Certyfikowany tester

Plan poziomu podstawowego

International Sotware Testing Qualifications Board

Stowarzyszenie Jako

ci Systemów Informatycznych

Wersja 1.0

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

nast

puj

ce parametry: ogólne cele, produkty

procesu wytwarzania, z których wywodz

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

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

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

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

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

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

ci Systemów

Informatycznych

Strona 24 z 78

20 pa

dziernika 2006

Testy integracyjne mog

wykonywane na kilku poziomach, a ich przedmiotem mog

ęś

ci rozmaitej wielko

ci. Przykładowo, testy integracyjne modułów sprawdzaj

interakcje

dzy modułami oprogramowania, wykonuje si

je po zako

czeniu testów modułowych.

Natomiast testy integracyjne systemów sprawdzaj

interakcj

dzy ró

nymi systemami i

mog

wykonywane po zako

czeniu testowania systemowego. W tej sytuacji organizacja

wytwarzaj

ca oprogramowanie zarz

dza tylko jedn

ęś

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

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

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

skokow

(„big

bang”).

W ramach testów integracyjnych wykonuje si

tak

e niekiedy testowanie wła

ciwo

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

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

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

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

systematycznego opisu zale

ci czynników opisanych w regułach biznesowych. Mo

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

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

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

do oceny gotowo

ci systemu do

wdro

enia lub u

ytkowania, cho

niekoniecznie s

ostatni

faz

testowania. Przykładowo,

testy integracyjne zewn

trzne mog

wykonywane po testach akceptacyjnych.

Testowanie akceptacyjne mo

e pojawi

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

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

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

ąŜ

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

Ŝą

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

ąŜ

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

skwantyfikowa

na skali (np. czas

Certyfikowany tester

Plan poziomu podstawowego

International Sotware Testing Qualifications Board

Stowarzyszenie Jako

ci Systemów Informatycznych

Wersja 1.0

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

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

stosowane do testowania potwierdzaj

cego i testowania regresywnego

musz

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

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

obejmowa

testy migracji danych lub – je

li dane musz

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

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

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

wykonane przed wykonaniem testu dynamicznego. Defekty wykryte podczas

przegl

dów na wczesnym etapie cyklu

ycia oprogramowania s

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

ść

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

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

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

ść

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

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

ski, przegl

daj

cy,

proces przegl

du, protokolant, przegl

d techniczny, przejrzenie.

Wprowadzenie

Przegl

dy mog

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

ąć

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

ęś

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

ęść

po spotkaniu.

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

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

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

cej ni

jeden rodzaj przegl

du to ich kolejno

ść

e by

ró

na. Na przykład, przegl

nieformalny mo

na przeprowadzi

przed przegl

dem technicznym, inspekcj

odno

nie

specyfikacji wymaga

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;

•

liwo

ść

zastosowania przy programowaniu parami lub do przegl

dów projektu i

kodu przez kierownika zespołu;

•

Opcjonalnie: mo

e by

udokumentowany;

•

e ró

w przydatno

ci w zale

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

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;

•

e by

przeprowadzony jako przegl

d kole

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

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

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:

•

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

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.

•

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

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

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

;

•

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

Ŝą

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

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)

Pokazuj

cych proste

ledzenie powi

z wymaganiami;

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

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

nast

puj

ce techniki projektowania testów: (K3)

Podział na klasy równowa

ci;

Analiza warto

ci brzegowych;

Testowanie w oparciu o tablice decyzyjne;

Diagramy przej

ść

pomi

dzy stanami.

•

Głównych przyczyn zastosowania ka

dej z czterech technik, jakiego poziomu i typu

testy mog

wykorzystywa

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

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)

Testowanie instrukcji;

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

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

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

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

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

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

one wykonane. W harmonogramie wykonania testu bierze si

pod uwag

takie czynniki jak testy regresywne, priorytety, zale

ci techniczne i logiczne.

Certyfikowany tester

Plan poziomu podstawowego

International Sotware Testing Qualifications Board

Stowarzyszenie Jako

ci Systemów Informatycznych

Wersja 1.0

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

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

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

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

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

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

ci, testowanie przej

ść

pomi

dzy stanami, testowanie w oparciu o przypadki

ycia.

4.3.1. Podział na klasy równowa

ci (K3)

Elementy wej

ciowe do oprogramowania lub systemu dzieli si

na grupy o podobnym

charakterze - prawdopodobnie b

one przetwarzane przez system w ten sam sposób.

Klasy równowa

ci mo

na znale

źć

zarówno dla danych poprawnych jak i niepoprawnych,

tzn. warto

ci, które powinny by

odrzucone. Klasy równowa

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

ci. Podział na klasy

równowa

ci (KR) daje si

stosowa

na wszystkich poziomach testowania.

Klas równowa

ci jako techniki mo

na u

ywa

, aby osi

ąć

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

ci s

jej warto

ciami brzegowymi.

Istnieje mo

liwo

ść

e zachowanie na kraw

dzi ka

dej klasy równowa

ci b

dzie

nieprawidłowe, a wi

c brzegi s

miejscem, gdzie testowanie prawdopodobnie wykryje

defekty. Warto

ść

brzegowa dla poprawnej klasy równowa

ci jest dozwolon

warto

brzegow

; brzeg niepoprawnej klasy równowa

ci jest niepoprawn

warto

brzegow

Testy mog

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

ci i mo

e by

wykorzystywana zarówno dla elementów wprowadzanych przez

człowieka jak i dla elementów z zale

ciami czasowymi lub elementów tablicowych.

Warto

ci brzegowe mog

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

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

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ó

odpowied

w zale

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

projektowane w taki

sposób, aby pokry

dy stan, wykona

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

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

spełnione, aby przypadek zako

czył si

powodzeniem. Ka

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

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

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

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

e by

drzewo wywoła

(diagram, w którym moduły

wołaj

inne moduły).

•

Poziom systemu: struktur

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

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

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

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

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ó

efektywno

, zale

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

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

jako sprawdzenie procesu

testowego, aby upewni

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

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

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

stosowa

dla okre

lonych sytuacji i poziomów testów; inne mo

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

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

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

dotycz

cych produktu i projektu.

•

Jak analiza i planowanie ryzyka mog

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

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

ść

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

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

ci to:

•

Niezale

ni testerzy dostrzegaj

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

, których dokonano

podczas specyfikacji oraz implementacji systemu.

Wady niezale

ci to:

•

Odizolowanie testerów od zespołu deweloperów (gdy niezale

ść

jest zupełna).

•

Niezale

ni testerzy mog

sta

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

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

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

ytkownika, specyfikacji oraz modeli

testowalno

•

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

•

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

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

ci. Na ogół, na poziomie modułów i

integracji, testerami mog

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

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

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

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

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

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

przypisane,

jakim zadaniom, kiedy i w jaki sposób wykonywane b

zadania testowe, jak b

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

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

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

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

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

równolegle.

•

Metodyki konsultatywne, w których projektowanie testów jest w przewa

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

ci Systemów

Informatycznych

Strona 51 z 78

20 pa

dziernika 2006

5.3. Monitorowanie przebiegu i nadzór testowania (K2), 20 minut

Terminologia

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

na zbiera

cznie lub

automatycznie i mo

na j

stosowa

do pomiaru spełnienia kryteriów wyj

cia, (np. analizy

pokrycia). Pomiary mog

słu

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

ęść

wykonano przygotowuj

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,

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

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

, udokumentowa

i wdro

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

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

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:

Brak personelu i/lub niezb

dnych umiej

tno

Problemy osobiste i problemy dotycz

ce szkole

;

•

Kwestie organizacyjne, np.

Nieskuteczne komunikowanie przez testerów swoich potrzeb oraz wyników
testów;

Niewykorzystanie informacji zdobytej podczas testowania i przegl

dów, np.

zaniechanie usprawniania procedur i innych praktyk testowych).

Niewła

ciwa postawa lub oczekiwania w stosunku do testów (niedocenianie

wyszukiwania defektów podczas testowania).

•

Czynniki techniczne:

Niewła

ciwie okre

lone wymagania;

Wymagania nie s

w pełni osi

galne przy istniej

cych ograniczeniach;

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

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

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

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

, kiedy nale

y rozpocz

ąć

testowanie i gdzie warto

testowa

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

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

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

i stosowa

proces i reguły ich klasyfikacji.

Incydenty mog

zgłaszane podczas wytwarzania, przegl

dów, testowania lub

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

, 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

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

testowych. (K2)

•

O narz

dziach, które mog

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

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

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

wykorzystywane

do ró

nych czynno

ci, ale zaklasyfikowane zostały zgodnie z t

czynno

, 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

zale

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

ci Systemów

Informatycznych

Strona 60 z 78

20 pa

dziernika 2006

•

liwo

ść

ledzenia powi

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

testów (np. liczba wykonanych i zaliczonych

testów) oraz przedmiotu testów (np. liczba incydentów), maj

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

pojedynczych testów z wymaganiami, funkcjami lub obszarami funkcjonalno

ci systemu.

Powi

zania te mog

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.

•

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

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

Narz

dzia wspieraj

ce proces przegl

du mog

gromadzi

dane na temat procesów

przegl

du, przechowywa

i słu

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

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

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

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

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

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

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

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

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

stosowane do rejestrowania testów.

Rejestracja danych testowych wprowadzanych podczas testowania eksploracyjnego lub
innego wykonywanego bez u

ycia skryptów testowych mog

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

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

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

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

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

ci czasowe lub wycieki pami

ci.

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

ąŜ

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

ąŜ

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

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

umo

liwiaj

ledzenie powi

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

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

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.

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

ąć

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.

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).

•

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

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

cznego testowania mo

e si

wydawa

korzystne, ale ta metoda nie nadaje si

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

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.

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

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

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

z innymi narz

dziami lub arkuszami kalkulacyjnymi. Raporty, aby były opłacalne, musz

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

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

liwo

ci udoskonalenia procesu testowego wspomaganego

narz

dziami.

•

Ocen

wdro

enia wobec jasnych wymaga

przy pomocy obiektywnych kryteriów.

•

Wst

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

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

osi

ąć

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

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

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

ąŜ

[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

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

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

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

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

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,

ęś

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,

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

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

(K1)

Kandydat rozpoznaje, pami

ta i umie okre

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

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

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

•

e zidentyfikowa

warto

ci graniczne dla dozwolonych i niedozwolonych klas

równowa

ci.

•

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

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

ł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

Ŝą

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ó

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

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

wag

dego tematu). (POTRZEBNY CZAS)

Referencje

SR1.

ródła i referencje zostan

podane dla koncepcji w konspekcie, aby pomóc dostawcom

szkole

znale

źć

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

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

im wi

cej czasu, za

kandydaci mog

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

lub wykorzystywa

tak

inne publikacje, wzorce lub normy poza okre

lonymi w konspekcie, ale nie b

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

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

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

ci Systemów

Informatycznych

Strona 76 z 78

20 pa

dziernika 2006

Indeks

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łąd, 10, 11, 16

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

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

efekt próbnika, 59
efektywność, 11, 33

funkcja, 37, 62
funkcjonalność, 24, 26, 54, 72

harmonogram, 37
harmonogram wykonania testu, 37

incydent, 15, 56
inspekcja, 29, 31, 32, 33
instrukcja, 56
integracja, 15, 23
interfejs, 34, 59

iteracyjny, 23

jakość, 10, 11, 12, 18, 46, 47, 54
jarzmo testowe, 59, 62
język skryptowy, 62, 65

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

lista kontrolna, 32
log testu, 15
logowanie wyników testów, 60

łatwość testowania, 48

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

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

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

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

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

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

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

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

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

usterka, 11

utrzymywalność, 11
uŜyteczność, 11, 26, 54

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

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