ISTQB materialy z kursu na testera

background image

Certyfikowany tester

Plan poziomu podstawowego

International Sotware Testing Qualifications Board

Stowarzyszenie Jako

ś

ci Systemów Informatycznych

Wersja 1.0

© Stowarzyszenie Jako

ś

ci Systemów

Informatycznych

Strona 1 z 78

20 pa

ź

dziernika 2006




Certyfikowany tester

Plan poziomu podstawowego

Wersja 1.0

Stowarzyszenie Jako

ś

ci Systemów Informatycznych

International Software Testing Qualifications Board

background image

Certyfikowany tester

Plan poziomu podstawowego

International Sotware Testing Qualifications Board

Stowarzyszenie Jako

ś

ci Systemów Informatycznych

Wersja 1.0

© Stowarzyszenie Jako

ś

ci Systemów

Informatycznych

Strona 2 z 78

20 pa

ź

dziernika 2006

Wszelkie prawa dla wersji angielskiej zastrze

ż

one dla © International Software Testing

Qualifications Board (dalej nazywane ISTQB).

Grupa Robocza ISTQB, plan Poziomu Podstawowego : Thomas Müller (przewodnicz

ą

cy),

Rex Black, Sigrid Eldh, Dorothy Graham, Klaus Olsen, Maaret Pyhäjärvi, Geoff Thompson
and Erik van Veendendal 2004-2005.

Prawa autorskie zastrze

ż

one © Stowarzyszenie Jako

ś

ci Systemów Informatycznych (SJSI).

Tłumaczenie z j

ę

zyka angielskiego oraz udział w przegl

ą

dach: Bogdan Bereza-Jaroci

ń

ski,

Wojciech Jaszcz, Helena Klitenik, Joanna Nowakowska, Jan Sabak, Anna Seredyn, Lucjan
Stapp, Piotr

Ś

l

ę

zak, Łukasz

ś

ebrowski.

Autorzy, tłumacze, ISTQB oraz SJSI okre

ś

laj

ą

nast

ę

puj

ą

ce warunki korzystania z Planu:

1) Osoby oraz firmy szkoleniowe maj

ą

prawo korzysta

ć

z planu jako podstawy do

materiałów szkoleniowych pod warunkiem podania

ź

ródła praw autorskich oraz

własno

ś

ci planu. Powoływanie si

ę

na niniejszy plan w materiałach reklamowych i

promocyjnych dozwolone jest dopiero po oficjalnym rozpocz

ę

ciu procedury ubiegania

si

ę

o akredytacj

ę

w ISTQB lub w Radzie Krajowej (National Board) uznawanej przez

ISTQB.

2) Osoby oraz firmy i zrzeszenia maj

ą

prawo korzysta

ć

z planu jako podstawy do

artykułów, ksi

ąż

ek oraz innych materiałów pod warunkiem podania

ź

ródła praw

autorskich oraz własno

ś

ci planu.

3) Ka

ż

da uznawana przez ISTQB Rada Krajowa mo

ż

e wykona

ć

tłumaczenie

niniejszego planu oraz udziela

ć

zezwolenia na korzystanie z cało

ś

ci lub cz

ęś

ci

tłumaczenia innym stronom.

background image

Certyfikowany tester

Plan poziomu podstawowego

International Sotware Testing Qualifications Board

Stowarzyszenie Jako

ś

ci Systemów Informatycznych

Wersja 1.0

© Stowarzyszenie Jako

ś

ci Systemów

Informatycznych

Strona 3 z 78

20 pa

ź

dziernika 2006

Historia zmian

Wersja

Data

Uwagi

0.1

15.07.2005

Wzorzec dokumentu.

0.1.1

01.08.2005

Bogdan Bereza-Jaroci

ń

ski, cz

ęś

ciowo rozdział 6.

0.1.2

16.08.2005

Anna Seredyn: fragmenty rozdz. 1 (kosmetyczne zmiany BB).

Bogdan Bereza-Jaroci

ń

ski: dalsze tłumaczenie rozdziału 6-ego.

Helena Klitenik: zał

ą

cznik A (kosmetyczne zmiany BB).

0.1.3

30.09.2005

Dodany rozdział 3. (Helena Klitenik), rozdział 4. (Helena
Klitenik) oraz Wst

ę

p (Helena Klitenik).

0.2

02.01.2006

Do przegl

ą

du (Bogdan Bereza-Jaroci

ń

ski)

0.2.1

04.01.2006

Uzupełnienia: zał

ą

czniki B, C i D od Heleny Klitenik

0.9

06.02.2006

Wersja dostarczona do SJSI

0.91

10.02.2006

Wersja do ostatecznego przegl

ą

du.

0.92

17.02.2006

Scalona wersja po przegl

ą

dzie, który nie okazał si

ę

ostateczny

0.93

28.07.2006

Poprawki do wersji ostatecznego przegl

ą

du

0.94

11.09.2006

Wersja alfa

0.95

18.09.2006

Wersja beta. Dodanie indeksu.

1.0

20.10.2006

Dostarczona zarz

ą

dowi SJSI

background image

Certyfikowany tester

Plan poziomu podstawowego

International Sotware Testing Qualifications Board

Stowarzyszenie Jako

ś

ci Systemów Informatycznych

Wersja 1.0

© Stowarzyszenie Jako

ś

ci Systemów

Informatycznych

Strona 4 z 78

20 pa

ź

dziernika 2006

Spis tre

ś

ci

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

Spis tre

ś

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

Podzi

ę

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

Wst

ę

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

1.

Podstawy testowania (K2), 155 minut........................................................................................................... 10

1.1.

Czemu testowanie jest niezb

ę

dne (K2), 20 minut ................................................................................................. 11

1.1.1.

Otoczenie systemów informatycznych (K1)..................................................................................................... 11

1.1.2.

Przyczyny defektów oprogramowania (K2) ..................................................................................................... 11

1.1.3.

Rola testowania w procesach tworzenia, utrzymania i u

ż

ytkowania oprogramowania (K2).............................. 11

1.1.4.

Testowanie i jako

ść

(K2)................................................................................................................................. 11

1.1.5.

Kiedy zako

ń

czy

ć

testowanie (K2).................................................................................................................... 12

1.2.

Co to jest testowanie (K2), 30 minut..................................................................................................................... 13

1.3.

Ogólne zasady testowania (K2), 35 minut ............................................................................................................ 14

1.4.

Prosty proces testowy (K1), 35 minut ................................................................................................................... 15

1.4.1.

Planowanie i nadzór nad testowaniem (K1) .................................................................................................... 15

1.4.2.

Analiza i projektowanie testów (K1)................................................................................................................. 16

1.4.3.

Implementacja i wykonanie testów (K1) .......................................................................................................... 16

1.4.4.

Ocena kryteriów zako

ń

czenia oraz raportowanie testów (K1) ......................................................................... 16

1.4.5.

Czynno

ś

ci na zako

ń

czenie testowania (K1) .................................................................................................... 17

1.5.

Psychologia testowania (K2), 35 minut................................................................................................................. 18

2.

Testowanie w cyklu

ż

ycia oprogramowania (K2), 135 minut......................................................................... 20

2.1.

Modele wytwarzania oprogramowania (K2), 20 minut .......................................................................................... 21

2.1.1.

Model V (K2)................................................................................................................................................... 21

2.1.2.

Iteracyjne modele wytwarzania (K2)................................................................................................................ 21

2.1.3.

Testowanie w cyklu

ż

ycia (K2) ........................................................................................................................ 21

2.2.

Poziomy testów (K2), 60 minut............................................................................................................................. 23

2.2.1.

Testowanie modułowe (K2)............................................................................................................................. 23

2.2.2.

Testowanie integracyjne (K2).......................................................................................................................... 23

2.2.3.

Testowanie systemowe (K2) ........................................................................................................................... 24

2.2.4.

Testowanie akceptacyjne (K2) ........................................................................................................................ 25

2.3.

Typy i cele testów (K2), 40 minut ......................................................................................................................... 26

2.3.1.

Testowanie funkcji (testowanie funkcjonalne) (K2).......................................................................................... 26

2.3.2.

Testowanie wła

ś

ciwo

ś

ci (testowanie niefunkcjonalne) (K2)............................................................................. 26

2.3.3.

Testowanie struktury/architektury systemu (testowanie strukturalne) (K2)....................................................... 27

2.3.4.

Testowanie zwi

ą

zane ze zmianami (testowanie potwierdzaj

ą

ce i regresywne) (K2) ........................................ 27

2.4.

Testowanie w fazie utrzymania (K2), 15 minut ..................................................................................................... 28

3.

Statyczne techniki testowania (K2), 60 minut ............................................................................................... 29

3.1.

Przegl

ą

dy i proces testowy(K2), 15 minut............................................................................................................. 30

3.2.

Proces przegl

ą

du (K2), 25 minut .......................................................................................................................... 31

3.2.1.

Fazy formalnego przegl

ą

du (K1) ..................................................................................................................... 31

3.2.2.

Role i odpowiedzialno

ś

ci (K1) ......................................................................................................................... 31

3.2.3.

Rodzaje przegl

ą

dów (K2)................................................................................................................................ 32

background image

Certyfikowany tester

Plan poziomu podstawowego

International Sotware Testing Qualifications Board

Stowarzyszenie Jako

ś

ci Systemów Informatycznych

Wersja 1.0

© Stowarzyszenie Jako

ś

ci Systemów

Informatycznych

Strona 5 z 78

20 pa

ź

dziernika 2006

3.2.4.

Czynniki powodzenia przegl

ą

dów (K2)............................................................................................................ 33

3.3.

Analiza statyczna przy pomocy narz

ę

dzi (K2), 20minut ........................................................................................ 34

4.

Techniki projektowania testów (K3), 255 minut............................................................................................. 35

4.1.

Identyfikowanie warunków testowych i projektowanie przypadków testowych (K3), 15 minut ............................... 37

4.2.

Kategorie technik projektowania testów (K2), 15 minut......................................................................................... 38

4.3.

Techniki na podstawie specyfikacji lub czarnoskrzynkowe (K3), 120 minut .......................................................... 39

4.3.1.

Podział na klasy równowa

ż

no

ś

ci (K3) ............................................................................................................. 39

4.3.2.

Analiza warto

ś

ci brzegowych (K3) .................................................................................................................. 39

4.3.3.

Testowanie w oparciu o tablic

ę

decyzyjn

ą

(K3) ............................................................................................... 39

4.3.4.

Testowanie przej

ść

pomi

ę

dzy stanami (K3) .................................................................................................... 40

4.3.5.

Testowanie w oparciu o przypadki u

ż

ycia (K2)................................................................................................ 40

4.4.

Techniki na podstawie struktury lub białoskrzynkowe (K3), 60 minut.................................................................... 41

4.4.1.

Testowanie instrukcji i pokrycie (K3) ............................................................................................................... 41

4.4.2.

Testowanie decyzyjne i pokrycie (K3) ............................................................................................................. 41

4.4.3.

Inne techniki na podstawie struktury (K1)........................................................................................................ 41

4.5.

Techniki oparte na do

ś

wiadczeniu (K2), 30 minut ................................................................................................ 42

4.6.

Wybór technik testowych (K2), 15 minut.............................................................................................................. 43

5.

Zarz

ą

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

5.1.

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

5.1.1.

Organizacja i niezale

ż

no

ść

testowania (K2) .................................................................................................... 46

5.1.2.

Zadania kierownika testów i testera (K1)......................................................................................................... 46

5.2.

Planowanie testowania (K2), 50 minut ................................................................................................................. 48

5.2.1.

Planowanie testowania (K2)............................................................................................................................ 48

5.2.2.

Czynno

ś

ci wykonywane podczas planowania testów (K2) .............................................................................. 48

5.2.3.

Kryteria wyj

ś

cia (K2) ....................................................................................................................................... 48

5.2.4.

Oszacowanie wysiłku testowego (K2) ............................................................................................................. 49

5.2.5.

Sposoby podej

ś

cia do testowania (strategie testowe) (K2).............................................................................. 49

5.3.

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

5.3.1.

Monitorowanie post

ę

pu testów (K1) ................................................................................................................ 51

5.3.2.

Raportowanie testów (K2)............................................................................................................................... 51

5.3.3.

Nadzór nad testowaniem (K2)......................................................................................................................... 51

5.4.

Zarz

ą

dzanie konfiguracj

ą

(K2), 10 minut .............................................................................................................. 53

5.5.

Ryzyko a testowanie (K2), 30 minut ..................................................................................................................... 54

5.5.1.

Ryzyko projektowe (K1, K2)............................................................................................................................ 54

5.5.2.

Ryzyko zwi

ą

zane z produktem (K2) ................................................................................................................ 54

5.6.

Zarz

ą

dzanie incydentami (K3), 40 minut .............................................................................................................. 56

6.

Testowanie wspierane narz

ę

dziami (K2), 80 minut ...................................................................................... 58

6.1.

Rodzaje narz

ę

dzi testowych (K2), 45 minut.......................................................................................................... 59

6.1.1.

Klasyfikacja narz

ę

dzi testowych...................................................................................................................... 59

6.1.2.

Zarz

ą

dzanie testowaniem wspierane narz

ę

dziami (K1)................................................................................... 59

6.1.3.

Testowanie statyczne wspierane narz

ę

dziami (K1)......................................................................................... 61

6.1.4.

Tworzenie specyfikacji testów wspierane narz

ę

dziami .................................................................................... 61

6.1.5.

Wykonywanie testów wspierane narz

ę

dziami ................................................................................................. 62

6.1.6.

Testowanie wydajno

ś

ci i monitorowanie wspierane narz

ę

dziami (K1) ............................................................. 63

background image

Certyfikowany tester

Plan poziomu podstawowego

International Sotware Testing Qualifications Board

Stowarzyszenie Jako

ś

ci Systemów Informatycznych

Wersja 1.0

© Stowarzyszenie Jako

ś

ci Systemów

Informatycznych

Strona 6 z 78

20 pa

ź

dziernika 2006

6.1.7.

Narz

ę

dzia wspieraj

ą

ce testowanie w okre

ś

lonych dziedzinach ....................................................................... 63

6.1.8.

Wykorzystanie innych narz

ę

dzi (K1) ............................................................................................................... 64

6.2.

Skuteczne zastosowanie narz

ę

dzi: mo

ż

liwe korzy

ś

ci i zagro

ż

enia (K2), 20 minut ................................................ 65

6.2.1.

Mo

ż

liwe korzy

ś

ci i zagro

ż

enia wynikaj

ą

ce ze stosowania narz

ę

dzi wspieraj

ą

cych testowanie (dla wszystkich

rodzajów narz

ę

dzi) (K2)................................................................................................................................................... 65

6.2.2.

Zagadnienia specjalne dla niektórych rodzajów narz

ę

dzi (K1)......................................................................... 65

6.3.

Wdro

ż

enie narz

ę

dzia w organizacji (K1), 15 minut ............................................................................................... 67

7.

Referencje .................................................................................................................................................... 69

Zał

ą

cznik A – Pochodzenie planu.......................................................................................................................... 70

Zał

ą

cznik B – Cel nauki i poziomy wiedzy ............................................................................................................. 72

Zał

ą

cznik C – Zasady dotycz

ą

ce Planu poziomu podstawowego ISTQB / SJSI ................................................... 73

Zał

ą

cznik D – Informacja dla dostawców szkole

ń

.................................................................................................. 75

Indeks.................................................................................................................................................................... 76

background image

Certyfikowany tester

Plan poziomu podstawowego

International Sotware Testing Qualifications Board

Stowarzyszenie Jako

ś

ci Systemów Informatycznych

Wersja 1.0

© Stowarzyszenie Jako

ś

ci Systemów

Informatycznych

Strona 7 z 78

20 pa

ź

dziernika 2006

Podzi

ę

kowania

Angielska wersja tego dokumentu została napisana przez Grup

ę

Robocz

ą

ISTQB w składzie:

Thomas Müller (przewodnicz

ą

cy), Rex Black, Sigrid Eldh, Dorothy Graham, Klaus Olsen,

Maaret Pyhäjärvi, Geoff Thompson oraz Erik van Veendendal. Grupa Robocza wyra

ż

a

podzi

ę

kowania przedstawicielom Rad Krajowych za udział w przegl

ą

dach planu.

Szczególne podzi

ę

kowania skierowane s

ą

do (Austria) Anastasios Kyriakopoulos, (Dania)

Klaus Olsen, Christie Rosenbeck-Larsen, (Niemcy) Matthias Daigl, Uwe Hehn, Tilo Linz,
Horst Pohlmann, Ina Schieferdecker, Sabine Uhde, Stephanie Ulrich, (Indie) Vipul Kocher,
(Izrael) Shmuel Knishinsky, Ester Zabar, (Szwecja) Anders Claesson, Mattias Nordin, Ingvar
Nordström, Stefan Ohlsson, Kenneth Osbjer, Ingela Skytte, Klaus Zeuge, (Szwajcaria) Armin
Born, Sandra Harries, Silvio Moser, Reto Müller, Joerg Pietzsch, (Wielka Brytania) Aran
Ebbett, Isabel Evans, Julie Gardiner, Andrew Goslin, Brian Hambling, James Lyndsay, Helen
Moore, Peter Morgan, Trevor Newton, Angelina Samaroo, Shane Saunders, Mike Smith,
Richard Taylor, Neil Thompson, Pete Williams, (USA) Dale Perry.

Tłumaczenie na j

ę

zyk polski zostało wykonane przez Grup

ę

Robocz

ą

SJSI w składzie:

Bogdan Bereza-Jaroci

ń

ski, Wojciech Jaszcz, Helena Klitenik, Joanna Nowakowska, Jan

Sabak, Anna Seredyn, Lucjan Stapp, Piotr

Ś

l

ę

zak, Łukasz

ś

ebrowski.

background image

Certyfikowany tester

Plan poziomu podstawowego

International Sotware Testing Qualifications Board

Stowarzyszenie Jako

ś

ci Systemów Informatycznych

Wersja 1.0

© Stowarzyszenie Jako

ś

ci Systemów

Informatycznych

Strona 8 z 78

20 pa

ź

dziernika 2006

Wst

ę

p do planu

Cel dokumentu

Plan ten stanowi podstaw

ę

do Mi

ę

dzynarodowej Kwalifikacji w Testowaniu Oprogramowania

na poziomie podstawowym. ISTQB (The International Software Testing Qualifications Board)
zapewnia narodowym grupom egzaminacyjnym akredytacj

ę

dostawców szkole

ń

oraz

posiadanie pyta

ń

egzaminacyjnych w ich lokalnym j

ę

zyku. Dostawcy szkole

ń

przygotowuj

ą

materiał kursu i okre

ś

l

ą

odpowiednie metody nauczania do akredytacji, a plan pomaga

kandydatom w przygotowaniu si

ę

do egzaminu.

Informacj

ę

o historii i pochodzeniu planu mo

ż

na znale

źć

w Zał

ą

czniku A.

Podstawowy Poziom Certyfikowanego Testera w Testowaniu
Oprogramowania

Kwalifikacja na Poziomie Podstawowym kierowana jest do ka

ż

dego zaanga

ż

owanego w

testowanie oprogramowania. Zalicza si

ę

tu takie osoby jak testerzy, analitycy testów,

in

ż

ynierowie testów, konsultanci testów, mened

ż

erowie testów, testerzy akceptacji

u

ż

ytkownika i programi

ś

ci. Kwalifikacja na Poziomie Podstawowym odpowiednia jest równie

ż

dla ka

ż

dego, kto potrzebuje podstawowej wiedzy w dziedzinie testowania oprogramowania.

Dotyczy to kierowników projektu, kierowników jako

ś

ci, kierowników oprogramowania,

analityków biznesowych, dyrektorów IT i konsultantów zarz

ą

du. Posiadacze Certyfikatu

Podstawowego b

ę

d

ą

mieli mo

ż

liwo

ść

przej

ś

cia na wy

ż

szy poziom kwalifikacji w testowaniu

oprogramowania.

Cele uczenia si

ę

/poziom wiedzy

Dla ka

ż

dej sekcji planu podane s

ą

nast

ę

puj

ą

ce poziomy poznawcze:

K1: zapami

ę

taj, poznaj, wymie

ń

;

K2: zrozum, wyja

ś

nij, podaj przyczyny, porównaj, sklasyfikuj, stre

ść

;

K3: zastosuj.

Dalsze szczegóły i przykłady celów uczenia si

ę

podano w Zał

ą

czniku B.

Wszystkie poj

ę

cia wymienione w „Terminologii”, zaraz poni

ż

ej nagłówków rozdziałów,

powinny by

ć

zapami

ę

tane, nawet, je

ś

li nie wspomniano o tym wyra

ź

nie, w celach uczenia si

ę

.

Egzamin

Egzamin na Certyfikat Podstawowy b

ę

dzie oparty na niniejszym konspekcie. Odpowiedzi na

pytania egzaminacyjne mog

ą

wymaga

ć

skorzystania z materiału bazuj

ą

cego na wi

ę

cej ni

ż

jednym rozdziale niniejszego planu. W egzaminie uwzgl

ę

dnione s

ą

wszystkie rozdziały planu.

Format egzaminu to test wielokrotnego wyboru.

Egzaminy mo

ż

na zdawa

ć

podczas akredytowanego kursu szkoleniowego lub przyst

ę

powa

ć

do nich niezale

ż

nie (np. w centrum egzaminacyjnym).

Akredytacja

Dostawcy szkole

ń

, których materiał kursowy odpowiada planowi, mog

ą

by

ć

akredytowani

przez narodow

ą

organizacj

ę

uznawan

ą

przez ISTQB. Wytyczne odno

ś

nie akredytacji

powinno si

ę

uzyska

ć

od organizacji lub ciała, które dokonuje akredytacji. Kurs akredytowany

uznawany jest jako odpowiadaj

ą

cy temu planowi. Zezwala si

ę

, aby zdawa

ć

egzamin ISTQB

jako cz

ęść

kursu.

background image

Certyfikowany tester

Plan poziomu podstawowego

International Sotware Testing Qualifications Board

Stowarzyszenie Jako

ś

ci Systemów Informatycznych

Wersja 1.0

© Stowarzyszenie Jako

ś

ci Systemów

Informatycznych

Strona 9 z 78

20 pa

ź

dziernika 2006

Dalsze wskazówki odno

ś

nie dostawców szkole

ń

podano w Zał

ą

czniku D.

Poziom uszczegółowienia

Poziom uszczegółowienia w konspekcie pozwala na spójne mi

ę

dzynarodowo nauczanie oraz

egzamin. Aby osi

ą

gn

ąć

ten cel plan zawiera:

Ogólne cele opisuj

ą

ce intencj

ę

poziomu podstawowego,

List

ę

informacji do nauczenia, wliczaj

ą

c w to opis i odniesienia do dodatkowych

ź

ródeł, je

ś

li s

ą

wymagane,

Cele uczenia si

ę

dla ka

ż

dej dziedziny wiedzy, opisuj

ą

ce poznawczy rezultat uczenia

si

ę

i zestaw poj

ę

ciowy do osi

ą

gni

ę

cia,

List

ę

poj

ęć

, które studenci musz

ą

zrozumie

ć

i umie

ć

wymieni

ć

,

Opis kluczowych koncepcji nauczania, wliczaj

ą

c w to

ź

ródła takie jak przyj

ę

ta

literatura lub standardy.

Tre

ść

planu nie jest opisem całego obszaru wiedzy z testowania oprogramowania;

odzwierciedla poziom szczegółowo

ś

ci dla kursów szkoleniowych z poziomu podstawowego.

Organizacja planu

Plan zawiera sze

ść

głównych rozdziałów. Nagłówek górnego poziomu pokazuje poziomy

wiedzy zawarte wewn

ą

trz rozdziału i okre

ś

la jego czas trwania. Na przykład:

2.Testowanie w cyklu

ż

ycia oprogramowania (K2), 135 minut

pokazuje,

ż

e rozdział 2 ma poziom wiedzy K1 (zakłada si

ę

zawieranie ni

ż

szych, gdy

pokazany jest wy

ż

szy poziom) i K2 (ale nie K3) i zaplanowano 135 minut na nauczenie

materiału w nim zawartego.

Wewn

ą

trz ka

ż

dego rozdziału jest wiele sekcji. Ka

ż

da sekcja ma równie

ż

cele uczenia si

ę

i

ilo

ść

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

ą

si

ę

do czasu

dla sekcji.

background image

Certyfikowany tester

Plan poziomu podstawowego

International Sotware Testing Qualifications Board

Stowarzyszenie Jako

ś

ci Systemów Informatycznych

Wersja 1.0

© Stowarzyszenie Jako

ś

ci Systemów

Informatycznych

Strona 10 z 78

20 pa

ź

dziernika 2006

1. Podstawy testowania (K2), 155 minut

Celem rozdziału „Podstawy testowania” jest nauczenie, w
poszczególnych paragrafach:

1.1 Dlaczego testowanie jest niezb

ę

dne (K2)

Przedstawiania, z przykładami, w jaki sposób bł

ą

d w oprogramowaniu mo

ż

e

wyrz

ą

dzi

ć

szkod

ę

osobie,

ś

rodowisku lub firmie. (K2)

ż

nic pomi

ę

dzy przyczyn

ą

ę

du a jej efektem. (K2)

Uzasadnienia, opieraj

ą

c si

ę

na przykładach, dlaczego testowanie jest niezb

ę

dne. (K2)

Pokazania, dlaczego testowanie jest cz

ęś

ci

ą

zapewnienia jako

ś

ci i podania

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

ą

gn

ąć

wy

ż

sz

ą

jako

ść

. (K2)

Definicji: pomyłka, defekt, awaria oraz synonimy bł

ą

d i pluskwa. (K1)

1.2 Co to jest testowanie (K2)

Podstawowych zada

ń

procesu testowania.(K1)

Opisu celów testowania w procesach tworzenia, utrzymania i u

ż

ytkowania

oprogramowania, jako metody znajdowania bł

ę

dów, dostarczenia informacji o jako

ś

ci

oraz zapobieganiu awariom oprogramowania. (K2)

1.3 Podstawowe zasady testowania (K2)

Podstawowych zasad testowania. (K2)

1.4 Podstawowy proces testowy (K1)

Podstawowych etapów testów od planowania do zako

ń

czenia testów i głównych

zada

ń

ka

ż

dego etapu testów. (K1)

1.5 Psychologia testowania (K2)

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

o

Jasno zdefiniowane cele;

o

Równowag

ę

mi

ę

dzy testami programistów a testami niezale

ż

nymi;

o

Znaczenia asertywnej komunikacji i informacji o bł

ę

dach.

ż

nicy w podej

ś

ciu testera i programisty. (K2)

background image

Certyfikowany tester

Plan poziomu podstawowego

International Sotware Testing Qualifications Board

Stowarzyszenie Jako

ś

ci Systemów Informatycznych

Wersja 1.0

© Stowarzyszenie Jako

ś

ci Systemów

Informatycznych

Strona 11 z 78

20 pa

ź

dziernika 2006

1.1. Czemu testowanie jest niezb

ę

dne (K2), 20 minut

Terminologia

Pluskwa, defekt, pomyłka, awaria, usterka, jako

ść

, ryzyko, oprogramowanie, testowanie.

1.1.1. Otoczenie systemów informatycznych (K1)

Systemy informatyczne odgrywaj

ą

coraz wi

ę

ksz

ą

rol

ę

w

ż

yciu, pocz

ą

wszy od rozwi

ą

za

ń

dla

biznesu (np. sektor bankowy) a

ż

do urz

ą

dze

ń

dla konsumenta (np. samochody). Wi

ę

kszo

ść

ludzi zetkn

ę

ła si

ę

z oprogramowaniem, które nie działało tak jak powinno. Oprogramowanie

takie mo

ż

e wywoła

ć

wiele problemów – strat

ę

pieni

ę

dzy, czasu i reputacji firmy, mo

ż

e nawet

spowodowa

ć

obra

ż

enia lub

ś

mier

ć

.

1.1.2. Przyczyny defektów oprogramowania (K2)

Człowiek popełnia bł

ą

d (pomyłk

ę

), której skutkiem jest defekt (usterka, pluskwa) w kodzie,

oprogramowaniu, systemie lub dokumencie. Je

ś

li kod z defektem zostanie wykonany,

system nie zrobi tego, co powinien (lub zrobi co

ś

, czego nie powinien robi

ć

), wywołuj

ą

c

awari

ę

. Defekty w oprogramowaniu, systemach lub dokumentach mog

ą

, lecz nie musz

ą

skutkowa

ć

awariami.

Defekty istniej

ą

, poniewa

ż

ludzie s

ą

omylni, działaj

ą

pod presj

ą

czasu, w sytuacji

skomplikowanego kodu, skomplikowanej infrastruktury, zmieniaj

ą

cych si

ę

technologii i wielu

interakcji wewn

ą

trz systemu.

Awarie mog

ą

by

ć

równie

ż

wywołane przez czynniki

ś

rodowiska: promieniowanie, magnetyzm,

pole elektryczne, ska

ż

enie. Wszystko to mo

ż

e powodowa

ć

awarie w oprogramowaniu

wbudowanym lub wpływa

ć

na działanie oprogramowania przez zmian

ę

warunków działania

sprz

ę

tu.

1.1.3. Rola testowania w procesach tworzenia, utrzymania i u

ż

ytkowania

oprogramowania (K2)

Rygorystyczne testowanie systemów i dokumentacji mo

ż

e zredukowa

ć

ryzyko wyst

ą

pienia

awarii w

ś

rodowisku produkcyjnym i przyczyni

ć

si

ę

do osi

ą

gni

ę

cia wysokiej jako

ś

ci systemu.

Konieczne jest, aby znalezione defekty były poprawione przed dopuszczeniem systemu do
działania w

ś

rodowisku produkcyjnym.

Testowanie oprogramowania mo

ż

e by

ć

równie

ż

wymagane przez zapisy kontraktowe,

wymogi prawne lub standardy przemysłowe.

1.1.4. Testowanie i jako

ść

(K2)

Przy pomocy testowania mo

ż

na zmierzy

ć

jako

ść

oprogramowania rozumian

ą

jako liczba

znalezionych bł

ę

dów, zarówno w stosunku do wymaga

ń

funkcjonalnych jak i

niefunkcjonalnych oraz cech systemu (niezawodno

ść

, u

ż

yteczno

ść

, efektywno

ść

i

utrzymywalno

ść

). Wi

ę

cej informacji o testach niefunkcjonalnych znajduje si

ę

w rozdziale 2.

Wi

ę

cej informacji o cechach oprogramowania mo

ż

na znale

źć

w normie Software

Engineering – Software Product Quality (ISO 9126).

Testowanie mo

ż

e podnosi

ć

zaufanie co do jako

ś

ci oprogramowania, je

ż

eli znaleziono mało

lub nie znaleziono bł

ę

dów. Prawidłowo zaprojektowany test, który przechodzi bez

znalezienia bł

ę

du redukuje poziom ryzyka w systemie. Je

ś

li testowanie znajduje bł

ę

dy i bł

ę

dy

background image

Certyfikowany tester

Plan poziomu podstawowego

International Sotware Testing Qualifications Board

Stowarzyszenie Jako

ś

ci Systemów Informatycznych

Wersja 1.0

© Stowarzyszenie Jako

ś

ci Systemów

Informatycznych

Strona 12 z 78

20 pa

ź

dziernika 2006

te zostaj

ą

naprawione, jako

ść

systemu informatycznego wzrasta. Samo testowanie nie

podnosi jako

ś

ci oprogramowania i dokumentacji.

Z poprzednich projektów powinny by

ć

wyci

ą

gane wnioski. Proces wytwórczy mo

ż

na

doskonali

ć

poprzez zrozumienie przyczyn bł

ę

dów znalezionych w poprzednich projektach. W

konsekwencji powinno zapobiec ponownemu pojawieniu si

ę

podobnych defektów a tym

samym poprawi

ć

jako

ść

przyszłych systemów.

Testowanie powinno by

ć

zintegrowane z innymi metodami zapewniania jako

ś

ci (np. ze

standardami kodowania, szkoleniami i analiz

ą

ę

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.

background image

Certyfikowany tester

Plan poziomu podstawowego

International Sotware Testing Qualifications Board

Stowarzyszenie Jako

ś

ci Systemów Informatycznych

Wersja 1.0

© Stowarzyszenie Jako

ś

ci Systemów

Informatycznych

Strona 13 z 78

20 pa

ź

dziernika 2006

1.2. Co to jest testowanie (K2), 30 minut

Terminologia

Kod, debagowanie, tworzenie (oprogramowania), wymaganie, przegl

ą

d, podstawa testów,

przypadek testowy, testowanie, cele testu.

Wprowadzenie

Zazwyczaj testowanie jest odbierane jako zaj

ę

cie polegaj

ą

ce na wykonywaniu testów, czyli

uruchamianiu oprogramowania. Jest to jedynie cz

ęść

, lecz nie cało

ść

, testowania.

Czynno

ś

ci zwi

ą

zane z testowaniem, takie jak planowanie, nadzorowanie, ustalanie

warunków testowych, projektowanie zada

ń

testowych, porównywanie wyników, ocena

kryteriów zako

ń

czenia, raporty dotycz

ą

ce procesu testowego i testowanej aplikacji,

zako

ń

czenie i zamykanie testów (po zako

ń

czeniu fazy testów), wyst

ę

puj

ą

zarówno przed jak

i po wykonaniu testów. Testowanie obejmuje równie

ż

przegl

ą

dy dokumentów (w tym kodu)

oraz analiz

ę

statyczn

ą

.

Zarówno testowanie statyczne jak i dynamiczne mo

ż

e by

ć

u

ż

yte do osi

ą

gni

ę

cia podobnych

celów. Oba podej

ś

cia dostarcz

ą

informacji koniecznych do poprawy testowanego

oprogramowania oraz procesu tworzenia i testowania oprogramowania.

Mo

ż

na wyró

ż

ni

ć

nast

ę

puj

ą

ce cele testów:

Znajdowanie defektów
Budowanie zaufania odno

ś

nie jako

ś

ci oraz dostarczanie informacji o jako

ś

ci

Zapobieganie awariom

Proces projektowania zada

ń

testowych wykonywany wcze

ś

nie w cyklu wytwórczym

(weryfikacja podstawy testów za pomoc

ą

projektowania testów) mo

ż

e zapobiec

wprowadzaniu defektów do kodu. Przegl

ą

dy dokumentów (np. dokumentu wymaga

ń

)

równie

ż

pomagaj

ą

zapobiega

ć

pojawianiu si

ę

defektów.

ż

ne punkty widzenia podczas testowania maj

ą

na uwadze ró

ż

ne cele. Przykładowo, w

testach prowadzonych przez programistów (np. testowanie modułowe, integracyjne i
systemowe) głównym celem mo

ż

e by

ć

spowodowanie tylu awarii ile jest to mo

ż

liwe, aby

defekty w oprogramowaniu zostały zidentyfikowane i poprawione. W testach akceptacyjnych
głównym celem mo

ż

e by

ć

potwierdzenie działania systemu zgodnie z oczekiwaniami, aby

upewni

ć

si

ę

, ze system spełnia wymagania u

ż

ytkowników. W niektórych przypadkach

głównym celem testu mo

ż

e by

ć

ocena jako

ś

ci oprogramowania (bez zamiaru naprawienia

defektów), aby dostarczy

ć

interesariuszom informacji na temat ryzyka zwi

ą

zanego z

wdro

ż

eniem systemu w okre

ś

lonym czasie. Testy piel

ę

gnacyjne cz

ę

sto zawieraj

ą

testy

sprawdzaj

ą

ce, czy nie wprowadzono

ż

adnych nowych bł

ę

dów podczas implementacji zmian.

Podczas testów produkcyjnych głównym celem mo

ż

e by

ć

ocena wybranych charakterystyk

takich jak niezawodno

ść

i dost

ę

pno

ść

.

Debagowanie i testowanie ró

ż

ni

ą

si

ę

od siebie. Testowanie mo

ż

e ujawni

ć

awarie

spowodowane defektami. Debagowanie jest czynno

ś

ci

ą

programistyczn

ą

wykonywan

ą

w

celu zidentyfikowania przyczyny defektu, poprawienia kodu i sprawdzenia czy defekt został
poprawnie naprawiony. Pó

ź

niejsze testowanie potwierdzaj

ą

ce wykonywane przez testera

zapewnia,

ż

e poprawka rzeczywi

ś

cie usun

ę

ła awari

ę

. Odpowiedzialno

ść

za ka

ż

d

ą

z tych

czynno

ś

ci jest inna: testerzy testuj

ą

, a programi

ś

ci debaguj

ą

.

Proces testowania i jego czynno

ś

ci s

ą

omówione w sekcji 1.4.

background image

Certyfikowany tester

Plan poziomu podstawowego

International Sotware Testing Qualifications Board

Stowarzyszenie Jako

ś

ci Systemów Informatycznych

Wersja 1.0

© Stowarzyszenie Jako

ś

ci Systemów

Informatycznych

Strona 14 z 78

20 pa

ź

dziernika 2006

1.3. Ogólne zasady testowania (K2), 35 minut

Terminologia

Testowanie gruntowne

Zasady

Przez ponad 40 lat powstała pewna ilo

ść

zasad z zakresu testowania, które zawieraj

ą

ogólne

wytyczne cechuj

ą

ce ka

ż

de testowanie.

Zasada 1 – Testowanie ujawnia bł

ę

dy

Testowanie mo

ż

e pokaza

ć

,

ż

e istniej

ą

defekty, lecz testuj

ą

c nie jeste

ś

my w stanie dowie

ść

,

ż

e ich nie ma. Testowanie zmniejsza prawdopodobie

ń

stwo,

ż

e w oprogramowaniu

pozostan

ą

niezidentyfikowane defekty, ale nawet w przypadku, gdy

ż

adne defekty nie

zostan

ą

znalezione, nie jest to dowodem na poprawno

ść

oprogramowania.

Zasada 2 – Testowanie gruntowne jest niemo

ż

liwe

Przetestowanie wszystkiego (wszystkich kombinacji wej

ść

i warunków wst

ę

pnych) jest

mo

ż

liwe wył

ą

cznie w odniesieniu do bardzo trywialnych przypadków. Okre

ś

laj

ą

c zakres

testów, zamiast skupia

ć

si

ę

na testowaniu gruntownym, wykorzystujemy informacje o ryzyku

i priorytetach.

Zasada 3 – Wczesne testowanie

Czynno

ś

ci testowe powinny rozpoczyna

ć

si

ę

tak wcze

ś

nie, jak to mo

ż

liwe tylko w przypadku

danego oprogramowania lub cyklu wytwarzania oprogramowania. Powinny by

ć

one równie

ż

nastawione na osi

ą

ganie zdefiniowanych celów.

Zasada 4 – Kumulowanie si

ę

ę

dów

Wi

ę

kszo

ść

defektów znalezionych podczas testowania przed wypuszczeniem

oprogramowania lub powoduj

ą

cych awarie produkcyjne znajduje si

ę

w małej liczbie modułów.

Zasada 5 – Paradoks pestycydów

Je

ż

eli te same testy s

ą

ci

ą

gle powtarzane, ten sam zestaw przypadków testowych nie

znajduje ju

ż

ż

adnych nowych bł

ę

dów.

ś

eby przezwyci

ęż

y

ć

paradoks pestycydów, przypadki

testowe musz

ą

by

ć

regularnie przegl

ą

dane i korygowane. W celu sprawdzenia innych cz

ęś

ci

oprogramowania lub systemu, aby potencjalnie znale

źć

wi

ę

cej bł

ę

dów, powinny by

ć

dopisywane nowe, inne testy.

Zasada 6 – Testowanie jest zale

ż

ne od kontekstu

Testowanie jest wykonywane w ró

ż

ny sposób w ró

ż

nych sytuacjach. Na przykład, systemy

krytyczne ze wzgl

ę

du na bezpiecze

ń

stwo s

ą

testowane inaczej ni

ż

systemy typu e-

commerce.

Zasada 7 – Mylne przekonanie o bezbł

ę

dno

ś

ci

Znalezienie i usuni

ę

cie bł

ę

dów nie pomaga, je

ż

eli system jest nie nadaj

ą

cy si

ę

do u

ż

ytku i

nie spełnia potrzeb oraz oczekiwa

ń

u

ż

ytkownika.

background image

Certyfikowany tester

Plan poziomu podstawowego

International Sotware Testing Qualifications Board

Stowarzyszenie Jako

ś

ci Systemów Informatycznych

Wersja 1.0

© Stowarzyszenie Jako

ś

ci Systemów

Informatycznych

Strona 15 z 78

20 pa

ź

dziernika 2006

1.4. Prosty proces testowy (K1), 35 minut

Terminologia

Testowanie potwierdzaj

ą

ce, warunki wyj

ś

cia, incydent, testowanie regresywne, podstawa

testów, warunek testowy, pokrycie testowe, dane testowe, wykonanie testu, log testu, plan
testów, strategia testowania, raport ko

ń

cowy z testowania, testalia.

Wprowadzenie

Najbardziej widoczn

ą

cz

ęś

ci

ą

testowania jest wykonanie testów. Jednak,

ż

eby testy były

efektywne i skuteczne, plany testów powinny uwzgl

ę

dnia

ć

równie

ż

czas sp

ę

dzony na

planowaniu testów, projektowaniu przypadków testowych, przygotowaniu do wykonania
testów oraz ocenie statusu wykonania testów.

Podstawowy proces testowy składa si

ę

z nast

ę

puj

ą

cych głównych czynno

ś

ci:

Planowanie i nadzór;

Analiza i projektowanie;

Implementacja i wykonanie;

Ocena stopnia spełnienia warunków zako

ń

czenia i raportowanie;

Czynno

ś

ci zamykaj

ą

ce test.

Pomimo i

ż

czynno

ś

ci te s

ą

logicznie sekwencyjne, w procesie mog

ą

si

ę

zaz

ę

bia

ć

lub

wyst

ę

powa

ć

jednocze

ś

nie.

1.4.1. Planowanie i nadzór nad testowaniem (K1)

Planowanie testów weryfikuje misj

ę

testowania, definiuje cele testowania oraz sposób ich

osi

ą

gni

ę

cia.

Nadzór nad testami to powtarzaj

ą

ca si

ę

czynno

ść

porównywania rzeczywistego post

ę

pu

prac z planem i raportowanie wraz z informacj

ą

o odchyleniach od zało

ż

e

ń

. Nadzór nad

testami poci

ą

ga za sob

ą

czynno

ś

ci konieczne do wypełnienia misji i osi

ą

gni

ę

cia celów

projektu. Chc

ą

c nadzorowa

ć

testowanie, musimy je monitorowa

ć

w sposób ci

ą

gły. Podczas

planowania testów bierze si

ę

pod uwag

ę

informacje zwrotne z monitorowania i nadzoru.

Planowanie testów zawiera nast

ę

puj

ą

ce główne zadania:

Ocena zakresu i ryzyka oraz identyfikacja celów testowania.

Ocena metodyki testowania (techniki, testowane elementy, pokrycie, identyfikowanie i
integracja zespołów zaanga

ż

owanych w testowanie, testalia).

Ocena potrzebnych zasobów (np. ludzie,

ś

rodowisko testowe, komputery).

Wdro

ż

enie polityki testów i/lub strategii testowania.

Harmonogramowanie analizy testów i zada

ń

projektowych.

Harmonogramowanie implementacji, wykonania i oceny testów.

Okre

ś

lenie kryteriów zako

ń

czenia.

Nadzór nad testami ma nast

ę

puj

ą

ce główne zadania:

Mierzenie i analiza rezultatów;

Monitorowanie i dokumentowanie post

ę

pu prac, pokrycia testowego i kryteriów

zako

ń

czenia;

Rozpocz

ę

cie prac naprawczych;

background image

Certyfikowany tester

Plan poziomu podstawowego

International Sotware Testing Qualifications Board

Stowarzyszenie Jako

ś

ci Systemów Informatycznych

Wersja 1.0

© Stowarzyszenie Jako

ś

ci Systemów

Informatycznych

Strona 16 z 78

20 pa

ź

dziernika 2006

Podejmowanie decyzji.

1.4.2. Analiza i projektowanie testów (K1)

Analiza i projektowanie testów to czynno

ś

ci, w ramach których ogólne cele testowania

zostaj

ą

przekształcone w namacalne warunki testowe i projekty testów.

Analiza i projektowanie testów zawiera nast

ę

puj

ą

ce główne zadania:

Przegl

ą

danie podstawy testów (takiej jak wymagania, architektura, projekt, interfejsy).

Identyfikacja warunków testowych lub wymaga

ń

testowych oraz potrzebnych danych

testowych na podstawie analizy przedmiotów testu, specyfikacji, zachowania i
struktury.

Projektowanie testów.

Ocena testowalno

ś

ci wymaga

ń

i systemu.

Projektowanie

ś

rodowiska testowego i identyfikacja całej potrzebnej infrastruktury

oraz narz

ę

dzi.

1.4.3. Implementacja i wykonanie testów (K1)

Implementacja i wykonanie testów to czynno

ś

ci, w ramach których warunki testowe s

ą

przekształcane w przypadki testowe i testalia, oraz tworzone jest

ś

rodowisko testowe.

Implementacja i wykonanie testów składaj

ą

si

ę

z nast

ę

puj

ą

cych czynno

ś

ci:

Wytwarzanie i okre

ś

lanie priorytetów przypadków testowych, tworzenie danych

testowych, pisanie procedur testowych oraz – opcjonalnie - przygotowywanie jarzma
testowego i pisanie automatycznych skryptów testowych.

Tworzenie scenariuszy testowych na podstawie przypadków testowych celem
efektywnego wykonania testu.

Weryfikacja poprawno

ś

ci utworzonego

ś

rodowiska testowego.

Wykonanie przypadków testowych r

ę

cznie lub przy pomocy narz

ę

dzi, w

zaplanowanej kolejno

ś

ci.

Logowanie wyniku wykonania testu i rejestrowanie jednostek i wersji testowanego
oprogramowania, narz

ę

dzi testowych oraz testaliów.

Porównywanie wyników rzeczywistych z oczekiwanymi.

Raportowanie rozbie

ż

no

ś

ci jako zdarze

ń

i analizowanie ich celem znalezienia

przyczyny wyst

ą

pienia (np. bł

ą

d w kodzie, w specyficznych danych testowych, w

dokumencie testowym, lub pomyłka w sposobie wykonania testu).

Powtarzanie czynno

ś

ci testowych jako rezultat akcji podj

ę

tych po stwierdzeniu

rozbie

ż

no

ś

ci. Na przykład: ponowne wykonanie testu, który poprzednio wykrył awari

ę

celem potwierdzenia usuni

ę

cia usterki (testowanie potwierdzaj

ą

ce); wykonanie

poprawionego testu i/lub wykonanie testów celem upewnienia si

ę

,

ż

e nowe defekty

nie zostały wprowadzone do niezmienionych obszarów oprogramowania lub,

ż

e

usuwanie usterek nie powoduje innych awarii (testowanie regresywne).

1.4.4. Ocena kryteriów zako

ń

czenia oraz raportowanie testów (K1)

Ocena stopnia spełnienia warunków zako

ń

czenia i raportowanie to czynno

ś

ci, w ramach

których wykonanie testu jest oceniane pod wzgl

ę

dem zdefiniowanych celów. Tego typu

czynno

ś

ci powinny by

ć

wykonywane dla ka

ż

dego poziomu testów.

Ocena stopnia spełnienia warunków zako

ń

czenia i raportowanie składa si

ę

z nast

ę

puj

ą

cych

głównych czynno

ś

ci:

Sprawdzenie dziennika testów w odniesieniu do warunków zako

ń

czenia okre

ś

lonych

podczas planowania testów.

background image

Certyfikowany tester

Plan poziomu podstawowego

International Sotware Testing Qualifications Board

Stowarzyszenie Jako

ś

ci Systemów Informatycznych

Wersja 1.0

© Stowarzyszenie Jako

ś

ci Systemów

Informatycznych

Strona 17 z 78

20 pa

ź

dziernika 2006

Okre

ś

lenie, czy potrzebne jest wi

ę

cej testów lub czy nale

ż

y zmieni

ć

warunki

zako

ń

czenia.

Napisanie raportu ko

ń

cowego z testowania dla interesariuszy.

1.4.5. Czynno

ś

ci na zako

ń

czenie testowania (K1)

W ramach czynno

ś

ci zamykaj

ą

cych testowanie zbierane s

ą

dane z zako

ń

czonych czynno

ś

ci

testowych celem gromadzenia do

ś

wiadczenia, testaliów, faktów i liczb. Na przykład, kiedy

oprogramowanie zostaje przekazane klientowi, projekt testowy jest zako

ń

czony (lub

anulowany), krok milowy zostaje osi

ą

gni

ę

ty lub zamkni

ę

ta zostaje nowa wersja

oprogramowania po piel

ę

gnacji.

Do czynno

ś

ci zamykaj

ą

cych test zaliczamy:

Sprawdzenie, które zaplanowane dostawy zostały dostarczone

Zamkni

ę

cie raportów incydentów lub zgłoszenie zmian do tych, które pozostały

otwarte

Dokumentowanie akceptacji systemu.

Zako

ń

czenie i archiwizacja testaliów,

ś

rodowiska testowego i infrastruktury testowej

celem ponownego wykorzystania.

Przekazanie testaliów do zespołu serwisowego.

Analiza wniosków na potrzeby przyszłych projektów, oraz poprawy zdolno

ś

ci /

dojrzało

ś

ci testów.

background image

Certyfikowany tester

Plan poziomu podstawowego

International Sotware Testing Qualifications Board

Stowarzyszenie Jako

ś

ci Systemów Informatycznych

Wersja 1.0

© Stowarzyszenie Jako

ś

ci Systemów

Informatycznych

Strona 18 z 78

20 pa

ź

dziernika 2006

1.5. Psychologia testowania (K2), 35 minut

Terminologia

Testowanie niezale

ż

ne

Wprowadzenie

Nastawienie podczas testowania i przegl

ą

dania jest inne ni

ż

podczas analizowania i

wytwarzania. Maj

ą

c odpowiednie nastawienie programi

ś

ci s

ą

w stanie testowa

ć

własny kod.

Rozdzielenie odpowiedzialno

ś

ci mi

ę

dzy twórcami kodu a testerami wykonywane jest zwykle,

w celu zwi

ę

kszenia nacisku na testy i dostarczanie dodatkowych korzy

ś

ci, takich jak

niezale

ż

ne spojrzenie wyszkolonego i profesjonalnego zespołu testowego. Testowanie

niezale

ż

ne mo

ż

e mie

ć

miejsce na ka

ż

dym poziomie testowania.

Pewien stopie

ń

niezale

ż

no

ś

ci (dzi

ę

ki któremu unika si

ę

autorskiego spojrzenia na testowany

produkt) pozwala zwykle na wi

ę

ksz

ą

skuteczno

ść

w znajdowaniu defektów i awarii.

Niezale

ż

no

ść

nie zast

ę

puje jednak znajomo

ś

ci programu; programi

ś

ci mog

ą

znale

źć

wiele

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

ż

no

ś

ci:

Testy projektowane przez osob

ę

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

poziom niezale

ż

no

ś

ci).

Testy projektowane przez inn

ą

osob

ę

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

Testy projektowane przez osob

ę

(osoby) z innej grupy organizacyjnej (np. niezale

ż

ny

zespół testowy).

Testy projektowane przez osob

ę

(osoby) z innej organizacji lub z innego

przedsi

ę

biorstwa (np. outsourcing lub certyfikacja wykonywana przez jednostk

ę

zewn

ę

trzn

ą

).

Ludzie oraz projekty kieruj

ą

si

ę

okre

ś

lonymi celami. Ludzie maj

ą

skłonno

ść

do

dopasowywania planów do celów okre

ś

lonych przez kierownictwo lub innych interesariuszy,

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

ą

d

ź

potwierdzania,

ż

e oprogramowanie działa. St

ą

d

wa

ż

ne jest dokładne i jasne okre

ś

lenie celów testowania.

Identyfikacja awarii podczas testowania mo

ż

e by

ć

postrzegana jako krytyka skierowana pod

adresem produktu lub jego autora. Powoduje to,

ż

e testowanie jest cz

ę

sto postrzegane jako

czynno

ść

destrukcyjna, nawet, je

ż

eli jest ona bardzo konstruktywna w

ś

wietle zarz

ą

dzania

ryzykiem projektu. Szukanie awarii w systemie wymaga ciekawo

ś

ci, profesjonalnego

pesymizmu, krytycznego spojrzenia, przywi

ą

zywania wagi do szczegółów, dobrej

komunikacji z programistami i do

ś

wiadczenia, na którym mo

ż

na oprze

ć

zgadywanie bł

ę

dów.

Je

ż

eli bł

ę

dy, defekty lub awarie s

ą

komunikowane w konstruktywny sposób, mo

ż

na unikn

ąć

spi

ęć

pomi

ę

dzy testerami, analitykami, projektantami i programistami. Odnosi si

ę

to zarówno

do przegl

ą

dania, jak równie

ż

do testowania.

Tester i kierownik testów potrzebuj

ą

dobrych zdolno

ś

ci interpersonalnych, aby móc

informowa

ć

o faktycznym stanie defektów, post

ę

pu prac oraz o ryzyku w konstruktywny

sposób. Dla autorów oprogramowania lub dokumentu, informacja o bł

ę

dzie mo

ż

e okaza

ć

si

ę

pomocna w doskonaleniu umiej

ę

tno

ś

ci. Znalezione podczas testowania i usuni

ę

te defekty

pozwol

ą

zaoszcz

ę

dzi

ć

czas i

ś

rodki w przyszło

ś

ci, i zmniejsz

ą

ryzyko projektu.

Problemy komunikacyjne mog

ą

wyst

ą

pi

ć

zwłaszcza wtedy, gdy testerzy s

ą

postrzegani jako

osoby przekazuj

ą

ce informacje wył

ą

cznie o awariach. Istnieje kilka sposobów by poprawi

ć

komunikacj

ę

i relacje pomi

ę

dzy testerami i innymi pracownikami:

Raczej współpracowa

ć

ni

ż

walczy

ć

– przypomina

ć

wszystkim o wspólnym celu, jakim

jest lepsza jako

ść

produktów.

background image

Certyfikowany tester

Plan poziomu podstawowego

International Sotware Testing Qualifications Board

Stowarzyszenie Jako

ś

ci Systemów Informatycznych

Wersja 1.0

© Stowarzyszenie Jako

ś

ci Systemów

Informatycznych

Strona 19 z 78

20 pa

ź

dziernika 2006

Informowa

ć

o nieprawidłowo

ś

ciach produktu w neutralny sposób, zorientowany na

fakty, bez krytykowania osoby, która stworzyła produkt, na przykład, pisa

ć

obiektywne, faktyczne i rzeczowe raporty zdarze

ń

i nieprawidłowo

ś

ci znalezionych

podczas przegl

ą

dów.

Spróbowa

ć

zrozumie

ć

, co czuje inna osoba i dlaczego reaguje w sposób, w jaki

reaguje.

Upewni

ć

si

ę

,

ż

e inna osoba zrozumiała to, co zostało powiedziane.

Referencje:

1.1.5 Black, 2001, Kaner, 2002

1.2 Beizer, 1990, Black, 2001, Myers, 1979

1.3 Beizer, 1990, Hetzel, 1998, Myers, 1979

1.4 Hetzel, 1998

1.4.5 Black, 2001, Craig, 2002

1.5 Black, 2001, Hetzel, 1998

background image

Certyfikowany tester

Plan poziomu podstawowego

International Sotware Testing Qualifications Board

Stowarzyszenie Jako

ś

ci Systemów Informatycznych

Wersja 1.0

© Stowarzyszenie Jako

ś

ci Systemów

Informatycznych

Strona 20 z 78

20 pa

ź

dziernika 2006

2. Testowanie w cyklu

ż

ycia oprogramowania (K2), 135

minut

Celem rozdziału „Testowanie w cyklu

ż

ycia oprogramowania” jest

nauczenie, w poszczególnych paragrafach:

2.1 Modele wytwarzania oprogramowania (K2)

Powi

ą

za

ń

mi

ę

dzy wytwarzaniem, testowaniem i budowanymi produktami w cyklu

wytwarzania oprogramowania; poda

ć

przykłady uwzgl

ę

dniaj

ą

ce wła

ś

ciwo

ś

ci produktu,

projektu oraz ich kontekst. (K2)

Konieczno

ś

ci dostosowywania modeli wytwarzania oprogramowania do wła

ś

ciwo

ś

ci

projektu i produktu. (K1)

Przyczyn testowania na ró

ż

nych poziomach, oraz charakterystyk dobrego testowania

niezale

ż

nie od modelu cyklu

ż

ycia oprogramowania.

2.2 Poziomy testów (K2)

Porównywania ró

ż

nych poziomów testów: głównych zało

ż

e

ń

testów, typowych

przedmiotów celów testów (np. funkcjonalne lub strukturalne), kto wykonuje testy,
rodzaje znajdowanych defektów i awarii. (K2)

2.3 Typy testów: cele testowania (K2)

Czterech typów testów - funkcjonalne, niefunkcjonalne, strukturalne i wynikaj

ą

ce ze

zmian. (K2)

O testowaniu funkcjonalnym i strukturalnym wyst

ę

puj

ą

cym na ka

ż

dym poziomie

testów. (K1)

Rozpoznawania i opisywania testów niefunkcjonalnych bazuj

ą

cych na wymaganiach

niefunkcjonalnych. (K2)

Rozpoznawania i opisywania typów testów bazuj

ą

cych na strukturze lub architekturze

systemu. (K2)

Przeznaczenia testowania potwierdzaj

ą

cego i testowania regresywnego. (K2)

2.4 Testowanie w fazie utrzymania (K2)

Testowania w fazie utrzymania (testowanie istniej

ą

cego systemu) i testowania nowej

aplikacji, na zasadzie porównania, z uwzgl

ę

dnieniem celów, powodów i zakresu

testów. (K2)

Przyczyn testowania w fazie utrzymania (modyfikacja, migracja lub wycofanie
systemu). (K1)

Roli testów regresywnych i analizy wpływu w utrzymaniu oprogramowania. (K2)

background image

Certyfikowany tester

Plan poziomu podstawowego

International Sotware Testing Qualifications Board

Stowarzyszenie Jako

ś

ci Systemów Informatycznych

Wersja 1.0

© Stowarzyszenie Jako

ś

ci Systemów

Informatycznych

Strona 21 z 78

20 pa

ź

dziernika 2006

2.1. Modele wytwarzania oprogramowania (K2), 20 minut

Terminologia

Oprogramowanie z półki, przyrostowy model wytwarzania, poziom testów, walidacja,
weryfikacja, model „V”.

Wprowadzenie

Testowanie nie ma sensu w oderwaniu od czynno

ś

ci procesu wytwarzania oprogramowania,

z którym jest powi

ą

zane. Ró

ż

ne modele wytwarzania oprogramowania wymagaj

ą

odmiennej

metodologii testowania.

2.1.1. Model V (K2)

Pomimo,

ż

e istniej

ą

rozmaite warianty modelu „V”, powszechnie wykorzystywane podej

ś

cie

stosuje cztery poziomy testów, odpowiadaj

ą

ce czterem poziomom wytwarzania

oprogramowania.

W opracowaniu tym wykorzystywane s

ą

nast

ę

puj

ą

ce cztery poziomy:

Testowanie modułowe (jednostkowe);

Testowanie integracyjne;

Testowanie systemowe;

Testowanie akceptacyjne.

W rzeczywisto

ś

ci model „V” mo

ż

e mie

ć

inne definicje poziomów wytwarzania i testowania

oprogramowania, zale

ż

nie od projektu lub rodzaju produktu. Przykładowo, po testowaniu

modułowym mo

ż

e wyst

ę

powa

ć

testowanie integracyjne modułów, lub po testowaniu

systemowym testowanie integracyjne systemów.

Powstaj

ą

ce w procesie wytwarzania oprogramowania produkty (scenariusze biznesowe lub

przypadki u

ż

ycia, specyfikacje wymaga

ń

, dokumentacja projektowa oraz kod

ź

ródłowy)

stanowi

ą

cz

ę

sto podstaw

ę

testów na jednym lub kilku poziomach testów. Produkty te

definiowane s

ą

m.in. w modelu CMMI (Capability Maturity Model Integration) oraz w normie

IEEE/IEC 12207 (Software Life Cycle Process). W trakcie powstawania poszczególnych
produktów procesu mo

ż

e by

ć

wykonywana ich weryfikacja i walidacja (oraz wczesne

projektowanie testów).

2.1.2. Iteracyjne modele wytwarzania (K2)

Wytwarzanie w modelu iteracyjnym polega na kilkukrotnym – w formie kilku przej

ść

mniejszych procesów – okre

ś

laniu wymaga

ń

, projektowaniu, programowaniu i testowaniu

systemu. Przykładami modeli iteracyjnych s

ą

: prototypowanie, szybkie wytwarzanie

oprogramowania (Rapid Application Development, RAD), Rational Unified Process (RUP)
oraz metodyki zwinne (agile development). W trakcie trwania iteracji tworzony przyrost
systemu mo

ż

e by

ć

testowany na kilku poziomach. Kolejne przyrosty systemu, dodawane do

cz

ęś

ci wytworzonych wcze

ś

niej, stopniowo tworz

ą

system, który równie

ż

powinien by

ć

poddany testowaniu. W ka

ż

dej kolejnej iteracji coraz wa

ż

niejsze staj

ą

si

ę

testy regresywne.

W ka

ż

dej iteracji mo

ż

na wykonywa

ć

zarówno weryfikacj

ę

jak i walidacj

ę

.

2.1.3. Testowanie w cyklu

ż

ycia (K2)

Ka

ż

dy cykl

ż

ycia systemu posiada kilka cech charakterystycznych dobrego testowania:

Dla ka

ż

dej czynno

ś

ci wytwarzania systemu istnieje odpowiadaj

ą

ca jej czynno

ść

testowa.

Ka

ż

dy poziom testów ma specyficzne dla siebie cele.

background image

Certyfikowany tester

Plan poziomu podstawowego

International Sotware Testing Qualifications Board

Stowarzyszenie Jako

ś

ci Systemów Informatycznych

Wersja 1.0

© Stowarzyszenie Jako

ś

ci Systemów

Informatycznych

Strona 22 z 78

20 pa

ź

dziernika 2006

Analiza i projektowanie testów dla danego poziomu powinny rozpoczyna

ć

si

ę

ju

ż

podczas

odpowiadaj

ą

cej im fazy wytwarzania.

Testerzy powinni uczestniczy

ć

w przegl

ą

dach wczesnych wersji dokumentacji tworzonej

podczas wytwarzania.

Poziomy testów mo

ż

na ł

ą

czy

ć

ze sob

ą

lub organizowa

ć

na ró

ż

ne sposoby zale

ż

nie od

specyfiki projektu lub architektury systemu. Na przykład podczas integracji w system
gotowego oprogramowania z półki zamawiaj

ą

cy mo

ż

e przeprowadza

ć

testowanie

integracyjne na poziomie systemu (np. testy integracji z infrastruktur

ą

i pozostałymi

systemami albo testy odbiorcze i wdro

ż

eniowe) oraz testowanie akceptacyjne (testy

funkcjonalne i/lub niefunkcjonalne, testy u

ż

ytkowników ko

ń

cowych i/lub testy zdolno

ś

ci

operacyjnej).

background image

Certyfikowany tester

Plan poziomu podstawowego

International Sotware Testing Qualifications Board

Stowarzyszenie Jako

ś

ci Systemów Informatycznych

Wersja 1.0

© Stowarzyszenie Jako

ś

ci Systemów

Informatycznych

Strona 23 z 78

20 pa

ź

dziernika 2006

2.2. Poziomy testów (K2), 60 minut

Terminologia

Testowanie alfa, testowanie beta, testowanie modułowe (zwane te

ż

testowaniem

jednostkowym, modułowym lub programu), testy akceptacyjne zgodno

ś

ci z umow

ą

,

sterowniki, testy w

ś

rodowisku produkcyjnym, wymagania funkcjonalne, integracja,

testowanie integracyjne, wymagania niefunkcjonalne, operacyjne testy akceptacyjne, testy
akceptacyjne zgodno

ś

ci legislacyjnej, testowanie odporno

ś

ci, za

ś

lepki, testowanie

systemowe, wytwarzanie sterowane testowaniem (test-driven development),

ś

rodowisko

testowe, testowanie akceptacyjne przez u

ż

ytkownika.

Wprowadzenie

Dla ka

ż

dego poziomu testów mo

ż

na okre

ś

li

ć

nast

ę

puj

ą

ce parametry: ogólne cele, produkty

procesu wytwarzania, z których wywodz

ą

si

ę

przypadki testowe (podstawa testów),

przedmiot testowania (co b

ę

dzie testowane), znajdowane typowe defekty i awarie,

wymagania dotycz

ą

ce jarzma testowego oraz wsparcia narz

ę

dziowego, metodologii

testowania oraz odpowiedzialno

ś

ci.

2.2.1. Testowanie modułowe (K2)

Celem testów modułowych jest poszukiwanie bł

ę

dów oraz weryfikowanie daj

ą

cych si

ę

przetestowa

ć

elementów oprogramowania, np. modułów, programów, obiektów, klas itd.

Testy modułowe wykonuje si

ę

zwykle osobno dla ka

ż

dego testowanego obiektu, cho

ć

zale

ż

y

to od rodzaju systemu oraz przyj

ę

tego cyklu wytwarzania oprogramowania. W tej sytuacji

niezb

ę

dne mo

ż

e by

ć

posługiwanie si

ę

sterownikami testowymi, symulatorami oraz

za

ś

lepkami.

Celem testów modułowych mo

ż

e by

ć

zarówno weryfikacja funkcjonalno

ś

ci modułu jak i jego

wła

ś

ciwo

ś

ci niefunkcjonalnych, na przykład wykorzystania zasobów (czy nie powoduje

wycieków pami

ę

ci itp.). Ponadto wykonywane mog

ą

by

ć

testy odporno

ś

ci modułu oraz

testowanie strukturalne w celu osi

ą

gni

ę

cia pokrycia rozgał

ę

zie

ń

. Przypadki testowe

projektuje si

ę

na podstawie specyfikacji modułów, specyfikacji projektu oprogramowania lub

modelu danych.

Testowanie modułowe zwykle wykonuje si

ę

maj

ą

c dost

ę

p do kodu

ź

ródłowego,

ś

rodowiska

deweloperskiego, oprogramowania wspomagaj

ą

cego testy jednostkowe lub debagera.

Uczestniczy w nim zazwyczaj programista b

ę

d

ą

cy twórc

ą

testowanego modułu, natomiast

defekty s

ą

naprawiane natychmiast po znalezieniu, bez formalnego zgłaszania incydentów.

Jedna z metodologii organizacji testów modułowych polega na przygotowaniu
automatycznych przypadków testowych zanim jeszcze przyst

ą

pi si

ę

do kodowania.

Metodologia ta nazywana jest „najpierw przygotuj testy” lub „wytwarzanie sterowane
testowaniem”. Sposób ten jest wysoce iteracyjny i polega na cyklicznym budowaniu
automatycznych przypadków testowych, a nast

ę

pnie konstruowaniu i integracji niewielkich

fragmentów kodu oraz wykonywaniu testów modułowych a

ż

do spełnienia ustalonych

kryteriów.

2.2.2. Testowanie integracyjne (K2)

Podczas testowania integracyjnego testuje si

ę

interfejsy mi

ę

dzy modułami, interakcj

ę

z

innymi cz

ęś

ciami systemu (system operacyjny, system plików, sprz

ę

t) oraz interfejsy do

innych systemów.

background image

Certyfikowany tester

Plan poziomu podstawowego

International Sotware Testing Qualifications Board

Stowarzyszenie Jako

ś

ci Systemów Informatycznych

Wersja 1.0

© Stowarzyszenie Jako

ś

ci Systemów

Informatycznych

Strona 24 z 78

20 pa

ź

dziernika 2006

Testy integracyjne mog

ą

by

ć

wykonywane na kilku poziomach, a ich przedmiotem mog

ą

by

ć

cz

ęś

ci rozmaitej wielko

ś

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

ą

interakcje

mi

ę

dzy modułami oprogramowania, wykonuje si

ę

je po zako

ń

czeniu testów modułowych.

Natomiast testy integracyjne systemów sprawdzaj

ą

interakcj

ę

mi

ę

dzy ró

ż

nymi systemami i

mog

ą

by

ć

wykonywane po zako

ń

czeniu testowania systemowego. W tej sytuacji organizacja

wytwarzaj

ą

ca oprogramowanie zarz

ą

dza tylko jedn

ą

cz

ęś

ci

ą

interfejsu, co powoduje

trudno

ś

ci w przypadku zmian. Procesy biznesowe, zaimplementowane jako przepływy, mog

ą

anga

ż

owa

ć

wiele systemów. Du

ż

e znaczenie mog

ą

odgrywa

ć

zagadnienia zgodno

ś

ci

mi

ę

dzy rozmaitymi platformami.

Im wi

ę

kszy jest zakres integracji, tym trudniejsze mo

ż

e by

ć

okre

ś

lenie, który moduł lub

system jest przyczyn

ą

danej awarii, co powoduje zwi

ę

kszone ryzyko.

Systematyczne strategie integracji mog

ą

opiera

ć

si

ę

na architekturze systemu (np. scalanie

wst

ę

puj

ą

ce lub zst

ę

puj

ą

ce), funkcjach systemu, kolejno

ś

ci przetwarzania transakcji, oraz

innych wła

ś

ciwo

ś

ciach systemu lub modułu. Aby ograniczy

ć

ryzyko spowodowane zbyt

ź

nym ujawnianiem bł

ę

dów, zaleca si

ę

raczej integracj

ę

przyrostow

ą

ni

ż

skokow

ą

(„big

bang”).

W ramach testów integracyjnych wykonuje si

ę

tak

ż

e niekiedy testowanie wła

ś

ciwo

ś

ci

niefunkcjonalnych, np. wydajno

ś

ci.

Niezale

ż

nie od poziomu integracji, testowanie powinno dotyczy

ć

wył

ą

cznie samej integracji.

Przykładowo, integruj

ą

c ze sob

ą

moduły A i B, powinno si

ę

testowa

ć

komunikacj

ę

mi

ę

dzy

tymi modułami, a nie ich funkcjonalno

ść

. Stosuje si

ę

podej

ś

cie zarówno strukturalne jak i

funkcjonalne.

Najlepiej byłoby, aby testerzy rozumieli architektur

ę

systemu oraz mieli wpływ na planowanie

integracji. Planowanie testów integracyjnych przed przyst

ą

pieniem do wytwarzania systemu i

jego modułów pozwala na przyj

ę

cie takiej kolejno

ś

ci wytwarzania, która umo

ż

liwia

najsprawniejsze testowanie.

2.2.3. Testowanie systemowe (K2)

Testowanie systemowe dotyczy działania całego systemu lub produktu, zgodnie z zakresem
projektu lub programu.

Dla testowania systemowego

ś

rodowisko powinno odwzorowywa

ć

w miar

ę

mo

ż

liwo

ś

ci jak

najwierniej

ś

rodowisko produkcyjne, tak, aby zminimalizowa

ć

ryzyko,

ż

e nie zostan

ą

znalezione bł

ę

dy zale

ż

ne od jego specyfiki.

Przypadki testowe wykorzystywane w testowaniu systemowym mo

ż

na projektowa

ć

na

podstawie oceny ryzyka, specyfikacji wymaga

ń

, procesu biznesowego, przypadków u

ż

ycia

lub innych opisów działania systemu (na wysokim poziomie), jak równie

ż

interakcji systemu z

systemem operacyjnym i jego zasobami.

Testowanie systemowe powinno dotyczy

ć

zarówno wymaga

ń

funkcjonalnych jak i

niefunkcjonalnych. Wymagania opisuje si

ę

w formie tekstowej lub w formie modeli.

Potrzebna jest tak

ż

e umiej

ę

tno

ść

radzenia sobie z niepełnymi lub nieudokumentowanymi

wymaganiami. Testowanie funkcjonalne nale

ż

y rozpocz

ąć

od projektowania przypadków

testowych przy pomocy najstosowniejszej dla danego systemu techniki czarnoskrzynkowej
(w oparciu o specyfikacj

ę

). Przykładowo, tablica decyzyjna mo

ż

e posłu

ż

y

ć

do

systematycznego opisu zale

ż

no

ś

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

ż

na

te

ż

zastosowa

ć

techniki testowania strukturalnego (białoskrzynkowe), aby oceni

ć

staranno

ść

testowania w odniesieniu do pokrycia wybranych elementów, np. struktury menu lub
nawigacji mi

ę

dzy stronami WWW (zob. rozdz. 4.)

Testowanie systemowe wykonywane jest cz

ę

sto przez niezale

ż

ny zespół testowy.

background image

Certyfikowany tester

Plan poziomu podstawowego

International Sotware Testing Qualifications Board

Stowarzyszenie Jako

ś

ci Systemów Informatycznych

Wersja 1.0

© Stowarzyszenie Jako

ś

ci Systemów

Informatycznych

Strona 25 z 78

20 pa

ź

dziernika 2006

2.2.4. Testowanie akceptacyjne (K2)

Odpowiedzialno

ść

za testowanie akceptacyjne nale

ż

y cz

ę

sto do klientów lub do

u

ż

ytkowników, cho

ć

mog

ą

w nim mie

ć

udział tak

ż

e inni interesariusze.

Celem testowania akceptacyjnego jest osi

ą

gni

ę

cie zaufania do systemu, jego cz

ęś

ci lub

okre

ś

lonych wymaga

ń

niefunkcjonalnych. Głównym celem testów akceptacyjnych nie jest

znajdowanie defektów. Testy akceptacyjne mog

ą

słu

ż

y

ć

do oceny gotowo

ś

ci systemu do

wdro

ż

enia lub u

ż

ytkowania, cho

ć

niekoniecznie s

ą

ostatni

ą

faz

ą

testowania. Przykładowo,

testy integracyjne zewn

ę

trzne mog

ą

by

ć

wykonywane po testach akceptacyjnych.

Testowanie akceptacyjne mo

ż

e pojawi

ć

si

ę

na wi

ę

cej ni

ż

jednym poziomie, np.:

Oprogramowanie z półki mo

ż

e by

ć

poddane testom akceptacyjnym w trakcie

instalacji lub integracji,

Testy akceptacyjne u

ż

yteczno

ś

ci modułu mog

ą

mie

ć

miejsce w trakcie testów

modułowych,

Testowanie akceptacyjne poprawy funkcjonalno

ś

ci mo

ż

e by

ć

wykonane przed testem

systemowym.

Najcz

ęś

ciej spotyka si

ę

nast

ę

puj

ą

ce formy testów akceptacyjnych:

Testowanie akceptacyjne przez u

ż

ytkownika

Typowy cel to weryfikacja dostosowania do u

ż

ycia, dokonywana przez u

ż

ytkowników

biznesowych.

Operacyjne testy akceptacyjne

Akceptacja systemu przez jego administratorów, dotycz

ą

ca:

Tworzenia kopii zapasowych i odtwarzania z nich systemu;

Odtworzenia systemu po awarii;

Zarz

ą

dzania kontami u

ż

ytkowników;

Okresowych kontroli zagro

ż

e

ń

zabezpiecze

ń

.

Testy akceptacyjne zgodno

ś

ci z umow

ą

(odbiorcze) i testy zgodno

ś

ci legislacyjnej

Testy akceptacyjne zgodno

ś

ci z umow

ą

(testy odbiorcze) wykonuje si

ę

na podstawie

okre

ś

lonych w kontrakcie kryteriów odbioru dla oprogramowania dostarczanego na

zamówienie. Kryteria te powinny by

ć

okre

ś

lone w trakcie uzgadniania kontraktu. Testy

akceptacyjne zgodno

ś

ci legislacyjnej wykonuje si

ę

na podstawie obowi

ą

zuj

ą

cych przepisów

prawnych, bran

ż

owych lub bezpiecze

ń

stwa.

Testy alfa oraz testy beta (testy w

ś

rodowisku produkcyjnym)

Producenci oprogramowania sprzedawanego z półki zwykle chc

ą

uzyska

ć

wyniki oceny

produktu przez istniej

ą

cych lub potencjalnych klientów z wła

ś

ciwego segmentu rynku przed

wypuszczeniem go do sprzeda

ż

y. Testowanie alfa wykonywane jest w siedzibie producenta

oprogramowania. Testowanie beta (testy w

ś

rodowisku produkcyjnym) wykonywane jest w

siedzibach u

ż

ytkowników. Zarówno testowanie alfa jak i testowanie beta wykonywane jest

przez potencjalnych u

ż

ytkowników, nie przez twórców produktu.

W odniesieniu do systemów testowanych przed i po dostarczeniu do operacyjnego

ś

rodowiska u

ż

ytkowników firmy stosuj

ą

równie

ż

inne okre

ś

lenia, takie jak testy akceptacji

produkcyjnej lub testy akceptacji instalacji.

background image

Certyfikowany tester

Plan poziomu podstawowego

International Sotware Testing Qualifications Board

Stowarzyszenie Jako

ś

ci Systemów Informatycznych

Wersja 1.0

© Stowarzyszenie Jako

ś

ci Systemów

Informatycznych

Strona 26 z 78

20 pa

ź

dziernika 2006

2.3. Typy i cele testów (K2), 40 minut

Terminologia

Automatyzacja, testowanie czarnoskrzynkowe, pokrycie kodu, testowanie potwierdzaj

ą

ce,

testowanie funkcjonalne, testowanie zgodno

ś

ci operacyjnej, testowanie obci

ąż

eniowe,

testowanie utrzymywalno

ś

ci, testowanie wydajno

ś

ciowe, testowanie przenaszalno

ś

ci,

testowanie regresywne, testowanie niezawodno

ś

ci, testowanie zabezpiecze

ń

, testowanie w

oparciu o specyfikacj

ę

, testowanie przeci

ąż

aj

ą

ce, testowanie strukturalne, scenariusz

testowy, testowanie u

ż

yteczno

ś

ci, testowanie białoskrzynkowe.

Wprowadzenie

Testowanie mo

ż

na podzieli

ć

według tego, jakie s

ą

powody lub przyczyny wykonywania danej

grupy testów.

Cech

ą

testów nale

żą

cych do jednej kategorii jest okre

ś

lony, wspólny cel: np. przetestowanie

danej funkcjonalno

ś

ci, przetestowanie wła

ś

ciwo

ś

ci takiej jak niezawodno

ść

lub u

ż

yteczno

ść

,

wykonanie testów struktury albo architektury systemu, lub testowanie zwi

ą

zane ze

zamianami (weryfikacja naprawy defektu – testowanie potwierdzaj

ą

ce; poszukiwanie

niezamierzonych zmian – testowanie regresywne).

W testach strukturalnych lub funkcjonalnych cz

ę

sto stosowane s

ą

modele. Przykładowo, w

testach funkcjonalnych mo

ż

e by

ć

wykorzystany model przepływu procesu, model automatu

sko

ń

czonego (przej

ść

stanów) albo specyfikacja przygotowana w j

ę

zyku naturalnym. Dla

testów strukturalnych mo

ż

e to by

ć

model przepływu starowania lub model struktury menu.

2.3.1. Testowanie funkcji (testowanie funkcjonalne) (K2)

Funkcje systemu, podsystemu lub modułu opisuje si

ę

w specyfikacji wymaga

ń

w formie

przypadków u

ż

ycia lub w formie specyfikacji funkcjonalnej. Bywaj

ą

równie

ż

nieudokumentowane. Funkcje te okre

ś

laj

ą

CO robi system.

Testy funkcjonalne dotycz

ą

funkcji lub cech systemu (udokumentowanych lub znanych

testerom) i wykonuje si

ę

je na wszystkich poziomach testów (np. testy modułu na podstawie

specyfikacji modułu).

Techniki testowania w oparciu o specyfikacj

ę

polegaj

ą

na tym,

ż

e warunki i przypadki

testowe projektuje si

ę

na podstawie specyfikacji funkcjonalnej oprogramowania lub systemu

(zob. rozdz. 4). Testowanie funkcjonalne dotyczy zewn

ę

trznego działania oprogramowania

(testowanie czarnoskrzynkowe).

Jeden z typów testów funkcjonalnych - testowanie zabezpiecze

ń

- weryfikuje funkcjonalno

ść

(np. zapory – „firewall”) słu

żą

c

ą

zabezpieczaniu przed zagro

ż

eniami takimi jak wirusy czy

nieuprawniony dost

ę

p osób z zewn

ą

trz.

2.3.2. Testowanie wła

ś

ciwo

ś

ci (testowanie niefunkcjonalne) (K2)

W skład testów niefunkcjonalnych wchodzi mi

ę

dzy innymi: testowanie wydajno

ś

ci,

testowanie obci

ąż

eniowe, testowanie przeci

ąż

aj

ą

ce, testowanie u

ż

yteczno

ś

ci, testowanie

współdziałania, testowanie utrzymywalno

ś

ci, testowanie niezawodno

ś

ci oraz testowanie

przenaszalno

ś

ci. Testowanie to okre

ś

la JAK system działa.

Testowanie niefunkcjonalne mo

ż

na przeprowadza

ć

na wszystkich poziomach testów.

Okre

ś

lenie testowanie niefunkcjonalne odnosi si

ę

do testów niezb

ę

dnych do pomiaru

charakterystyk systemu i oprogramowania, które daj

ą

si

ę

skwantyfikowa

ć

na skali (np. czas

background image

Certyfikowany tester

Plan poziomu podstawowego

International Sotware Testing Qualifications Board

Stowarzyszenie Jako

ś

ci Systemów Informatycznych

Wersja 1.0

© Stowarzyszenie Jako

ś

ci Systemów

Informatycznych

Strona 27 z 78

20 pa

ź

dziernika 2006

odpowiedzi w testowaniu wydajno

ś

ciowym). Testowanie tego typu odwołuje si

ę

do modelu

jako

ś

ci takiego jak np. ISO 9126 „Software Engineering – Software Product Quality”.

2.3.3. Testowanie struktury/architektury systemu (testowanie
strukturalne) (K2)

Testy strukturalne (białoskrzynkowe) wykonuje si

ę

na wszystkich poziomach testów.

Techniki testowania strukturalnego najlepiej jest stosowa

ć

po technikach w oparciu o

specyfikacj

ę

, aby zmierzy

ć

staranno

ść

testowania poprzez ocen

ę

pokrycia wybranego

rodzaju struktur.

Pokrycie testowe to miara okre

ś

laj

ą

ca stopie

ń

wykonania danej struktury przez scenariusz

testowy, obliczona jako odsetek pokrytych elementów. Je

ś

li pokrycie nie wynosi 100%, aby

przetestowa

ć

wcze

ś

niej pomini

ę

te elementy, mo

ż

na zaprojektowa

ć

dodatkowe przypadki

testowe. Techniki pomiaru pokrycia omówione s

ą

w Rozdziale 4.

Na wszystkich poziomach testów, a zwłaszcza w testach modułowych oraz testach
integracyjnych modułów, stosuje si

ę

narz

ę

dzia do mierzenia pokrycia takich elementów kodu,

jak instrukcje lub decyzje. Testowanie strukturalne mo

ż

na wykonywa

ć

zgodnie z architektur

ą

systemu, np. hierarchi

ą

wywoła

ń

.

Podej

ś

cie strukturalne mo

ż

e by

ć

równie

ż

stosowane na poziomie testów systemowych,

testów integracji systemów lub testów akceptacyjnych, np. w odniesieniu do modelu
biznesowego albo struktury menu.

2.3.4. Testowanie zwi

ą

zane ze zmianami (testowanie potwierdzaj

ą

ce i

regresywne) (K2)

Po wykryciu i naprawieniu defektu, aby zweryfikowa

ć

(potwierdzi

ć

),

ż

e usuni

ę

cie defektu

zako

ń

czyło si

ę

powodzeniem, oprogramowanie nale

ż

y przetestowa

ć

ponownie. Nazywa si

ę

to testowaniem potwierdzaj

ą

cym. Debagowanie (naprawa defektu) nale

ż

y do wytwarzania,

nie do testowania.

Testowanie regresywne polega na ponownym testowaniu ju

ż

przetestowanego programu po

jego modyfikacji po to, aby ujawni

ć

mo

ż

liwe defekty powstałe – lub odkryte – w wyniku

wprowadzonej zmiany lub zmian. Defekty te mog

ą

wyst

ę

powa

ć

albo w testowanym

oprogramowaniu, albo w innym – maj

ą

cym lub nie, zwi

ą

zek z przedmiotem testów – module

oprogramowania. Testowanie regresywne wykonuje si

ę

po zmianie oprogramowania lub jego

ś

rodowiska operacyjnego. Zakres testów regresywnych zale

ż

y od tego, jak du

ż

e jest ryzyko,

ż

e znajdzie si

ę

usterki w oprogramowaniu, które wcze

ś

niej działało poprawnie.

Testy, które maj

ą

by

ć

stosowane do testowania potwierdzaj

ą

cego i testowania regresywnego

musz

ą

by

ć

powtarzalne.

Testowanie regresywne mo

ż

na przeprowadza

ć

na wszystkich poziomach testów. W skład

testów regresywnych wchodz

ą

wszelkie typy testów: funkcjonalne, wła

ś

ciwo

ś

ci i strukturalne.

Poniewa

ż

zestawy testów do testów regresywnych wykorzystuje si

ę

wielokrotnie i s

ą

one

stosunkowo niezmienne, s

ą

dobrymi kandydatami do automatyzacji.

background image

Certyfikowany tester

Plan poziomu podstawowego

International Sotware Testing Qualifications Board

Stowarzyszenie Jako

ś

ci Systemów Informatycznych

Wersja 1.0

© Stowarzyszenie Jako

ś

ci Systemów

Informatycznych

Strona 28 z 78

20 pa

ź

dziernika 2006

2.4. Testowanie w fazie utrzymania (K2), 15 minut

Terminologia

Analiza wpływu, testowanie w fazie utrzymania, migracja, modyfikacje, wycofanie systemu.

Wprowadzenie

Po wdro

ż

eniu wiele systemów informatycznych jest wykorzystywanych przez lata, a nawet

dziesi

ą

tki lat. W tym czasie system i jego

ś

rodowisko poddawane s

ą

licznym naprawom,

zmianom i rozbudowie. Testowanie w fazie utrzymania wykonywane jest na systemie
produkcyjnym, a jego powodem s

ą

modyfikacje, migracje lub wycofanie oprogramowania czy

systemu.

Modyfikacje przeprowadzane podczas utrzymania systemu maj

ą

ż

ne przyczyny:

rozbudowa i udoskonalanie systemu (np. w formie planowanych wersji), modyfikacje
naprawcze i awaryjne, a tak

ż

e ró

ż

norodne zmiany

ś

rodowiska (kolejne planowane wersje

systemu operacyjnego lub bazy danych lub łaty usuwaj

ą

ce nowoodkryte usterki

zabezpiecze

ń

systemu operacyjnego).

Testowanie w fazie utrzymania wykonywane w trakcie migracji (np. na inn

ą

platform

ę

)

powinno dotyczy

ć

zarówno testów zdolno

ś

ci operacyjnej dla nowego

ś

rodowiska, jak i testów

zmodyfikowanego oprogramowania.

Testowanie w fazie utrzymania wykonywane w zwi

ą

zku z wycofaniem systemu mo

ż

e

obejmowa

ć

testy migracji danych lub – je

ś

li dane musz

ą

by

ć

przechowywane przez długi

czas – testy ich archiwizacji.

Oprócz testowania wykonanych zmian, testy w fazie utrzymania obejmuj

ą

tak

ż

e pełne testy

regresywne niezmienionych cz

ęś

ci systemu. Zakres testów regresywnych zale

ż

y od ryzyka

zmiany, wielko

ś

ci systemu oraz zakresu zmiany. Zale

ż

nie od rodzaju zmian, testowanie w

fazie utrzymania wykonywane jest na którymkolwiek – lub na wszystkich – poziomach testów
oraz dotyczy któregokolwiek – lub wszystkich – typów testów.

Analiza wpływu polega na okre

ś

leniu, w jaki sposób zmiany mog

ą

wpłyn

ąć

na system. Wynik

jej okre

ś

la, jak obszerne testy regresywne nale

ż

y wykona

ć

.

Przyczyn

ą

trudno

ś

ci w testach w fazie utrzymania bywa przestarzała czy wr

ę

cz zaginiona

specyfikacja systemu.

Referencje

2.1.3 CMMI, Craig, 2002, Hetzel, 1998, IEEE 12207

2.2 Hetzel, 1998

2.2.4 Copeland, 2004, Myers, 1979

2.3.1 Beizer, 1990, Black, 2001, Copeland, 2004

2.3.2 Black, 2001, ISO 9126

2.3.3 Beizer, 1990, Copeland, 2004, Hetzel, 1998

2.3.4 Hetzel, 1998, IEEE 829

2.4 Black, 2001, Craig, 2002, Hetzel, 1998, IEEE 829

background image

Certyfikowany tester

Plan poziomu podstawowego

International Sotware Testing Qualifications Board

Stowarzyszenie Jako

ś

ci Systemów Informatycznych

Wersja 1.0

© Stowarzyszenie Jako

ś

ci Systemów

Informatycznych

Strona 29 z 78

20 pa

ź

dziernika 2006

3. Statyczne techniki testowania (K2), 60 minut

Celem rozdziału „Statyczne techniki testowania” jest nauczenie, w
poszczególnych paragrafach:

3.1 Przegl

ą

dy i proces testowy (K2)

Rozpoznawania produktów oprogramowania badanych przez ró

ż

ne statyczne

techniki testowania. (K1)

Znaczenia i warto

ś

ci rozwa

ż

anych statycznych technik testowania w celu oceny

produktów oprogramowania. (K2)

ż

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)

ż

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)

background image

Certyfikowany tester

Plan poziomu podstawowego

International Sotware Testing Qualifications Board

Stowarzyszenie Jako

ś

ci Systemów Informatycznych

Wersja 1.0

© Stowarzyszenie Jako

ś

ci Systemów

Informatycznych

Strona 30 z 78

20 pa

ź

dziernika 2006

3.1. Przegl

ą

dy i proces testowy(K2), 15 minut

Terminologia

Testowanie dynamiczne, przegl

ą

dy, analiza statyczna.

Wprowadzenie

Statyczne techniki testowania nie wykonuj

ą

testowanego programu; s

ą

to techniki r

ę

czne

(przegl

ą

dy) lub zautomatyzowane (analiza statyczna).

Przegl

ą

dy s

ą

sposobem testowania produktów pracy programowej (wliczaj

ą

c w to kod) i

mog

ą

by

ć

wykonane przed wykonaniem testu dynamicznego. Defekty wykryte podczas

przegl

ą

dów na wczesnym etapie cyklu

ż

ycia oprogramowania s

ą

cz

ę

sto du

ż

o ta

ń

sze do

usuni

ę

cia ni

ż

defekty wykryte podczas wykonywania pó

ź

niejszych testów (np. defekty

znalezione w wymaganiach).

Przegl

ą

d mógłby by

ć

wykonany w cało

ś

ci jako czynno

ść

r

ę

czna, jednak

ż

e istnieje wsparcie

narz

ę

dziowe dla tego procesu. Główna r

ę

czna czynno

ść

to zbada

ć

produkt i zebra

ć

uwagi

na jego temat. Mo

ż

na przejrze

ć

ka

ż

dy produkt pracy programowej, wliczaj

ą

c w to

specyfikacje wymaga

ń

, specyfikacje projektu, kod, plany testów, specyfikacje testów,

przypadki testowe, skrypty testowe, instrukcje u

ż

ytkownika czy strony webowe.

Do zalet przegl

ą

dów wlicza si

ę

: wczesne wykrycie i napraw

ę

defektu, popraw

ę

produktywno

ś

ci oprogramowania, skrócony czas tworzenia oprogramowania, skrócony czas i

koszt testowania, zmniejszenie defektów oraz lepsz

ą

komunikacj

ę

. Podczas wykonywania

przegl

ą

dów mo

ż

na wykry

ć

opuszczenia (np. w wymaganiach), co jest du

ż

o mniej

prawdopodobne podczas testowania dynamicznego.

Przegl

ą

dy, analiza statyczna i testowanie dynamiczne maj

ą

ten sam cel – zidentyfikowanie

defektów. S

ą

to czynno

ś

ci uzupełniaj

ą

ce si

ę

: ró

ż

ne techniki mog

ą

znale

źć

ż

ne rodzaje

defektów efektywnie i wydajnie. W przeciwie

ń

stwie do testowania dynamicznego, przegl

ą

dy

znajduj

ą

raczej defekty ni

ż

awarie.

Typowe defekty łatwiejsze do znalezienia w przegl

ą

dach ni

ż

w testowaniu dynamicznym to:

odchylenia od standardów, bł

ę

dy wymaga

ń

, bł

ę

dy projektu, niewystarczaj

ą

ca zdolno

ść

do

konserwacji, nieprawidłowe specyfikacje interfejsów.

background image

Certyfikowany tester

Plan poziomu podstawowego

International Sotware Testing Qualifications Board

Stowarzyszenie Jako

ś

ci Systemów Informatycznych

Wersja 1.0

© Stowarzyszenie Jako

ś

ci Systemów

Informatycznych

Strona 31 z 78

20 pa

ź

dziernika 2006

3.2. Proces przegl

ą

du (K2), 25 minut

Terminologia

Kryteria wej

ś

ciowe, warunki wyj

ś

cia, przegl

ą

d formalny, przegl

ą

d nieformalny, inspekcja,

rozpocz

ę

cie, miary, moderator/prowadz

ą

cy inspekcj

ę

, przegl

ą

d kole

ż

e

ń

ski, przegl

ą

daj

ą

cy,

proces przegl

ą

du, protokolant, przegl

ą

d techniczny, przejrzenie.

Wprowadzenie

Przegl

ą

dy mog

ą

by

ć

od bardzo nieformalnych do bardzo formalnych (dobrze

zorganizowanych i uregulowanych). Formalno

ść

procesu przegl

ą

du zwi

ą

zana jest z takimi

czynnikami jak dojrzało

ść

procesu programowania, prawne lub ustalone wymagania oraz

potrzeby audytu.

Sposób, w jaki przegl

ą

d jest przeprowadzany, zale

ż

y od uzgodnionego celu przegl

ą

du (np.

znale

źć

defekt, zrozumie

ć

lub wywoła

ć

dyskusj

ę

i osi

ą

gn

ąć

decyzj

ę

poprzez konsensus).

3.2.1. Fazy formalnego przegl

ą

du (K1)

Typowy formalny przegl

ą

d ma nast

ę

puj

ą

ce główne fazy:

Planowanie: wybór osób, przypisanie ról; okre

ś

lenie kryteriów wej

ś

ciowych i

warunków wyj

ś

cia (dla bardziej formalnych typów przegl

ą

du np. inspekcji); wybór

cz

ęś

ci dokumentów do przejrzenia.

Rozpocz

ę

cie: dystrybucja dokumentów; wyja

ś

nienie uczestnikom celów, procesu i

dokumentów; sprawdzenie kryteriów wej

ś

ciowych (dla bardziej formalnych typów

przegl

ą

du).

Indywidualne przygotowanie: praca wykonana samodzielnie przez ka

ż

dego z

uczestników przed spotkaniem przegl

ą

dowym, zanotowanie potencjalnych bł

ę

dów,

pyta

ń

i komentarzy.

Spotkanie przegl

ą

dowe: dyskusja lub zapis z udokumentowanymi wynikami lub

protokołami (dla bardziej formalnych typów przegl

ą

du). Uczestnicy spotkania mog

ą

po prostu zanotowa

ć

defekty, przedstawi

ć

zalecenia odno

ś

nie obsługi defektów lub

poczyni

ć

decyzje w sprawie defektów.

Obróbka: ustalenie znalezionych defektów - zazwyczaj wykonywane przez autora.

Dalsza cz

ęść

: sprawdzenie, czy defekty zostały zaadresowane; zebranie metryk i

sprawdzenie warunków wyj

ś

cia (dla bardziej formalnych typów przegl

ą

dów).

3.2.2. Role i odpowiedzialno

ś

ci (K1)

Typowy formalny przegl

ą

d mo

ż

e zawiera

ć

nast

ę

puj

ą

ce role:

Mened

ż

er: decyduje o wykonaniu przegl

ą

dów, przydziela czas w harmonogramach

projektów i okre

ś

la, czy zostały uwzgl

ę

dnione cele przegl

ą

du.

Moderator: osoba, która prowadzi przegl

ą

d dokumentu lub zestawu dokumentów,

wliczaj

ą

c w to planowanie przegl

ą

du, przebieg spotkania i dalsz

ą

cz

ęść

po spotkaniu.

Je

ż

eli konieczne, moderator mo

ż

e prowadzi

ć

mediacje pomi

ę

dzy ró

ż

nymi punktami

widzenia i cz

ę

sto jest osob

ą

, na której spoczywa sukces przegl

ą

du.

Autor: autor lub osoba odpowiedzialna za przegl

ą

dany dokument lub dokumenty.

Przegl

ą

daj

ą

cy: osoby ze specyficznym technicznym lub biznesowym przygotowaniem

(zwane tak

ż

e kontrolerami lub inspektorami), które po niezb

ę

dnym przygotowaniu,

identyfikuj

ą

i opisuj

ą

wyniki bada

ń

(np. bł

ę

dy) przegl

ą

danego produktu. Przegl

ą

daj

ą

cy

powinni by

ć

wybrani w taki sposób, aby reprezentowa

ć

ż

ne perspektywy i role.

Uczestnicz

ą

we wszelkich spotkaniach przegl

ą

dowych.

background image

Certyfikowany tester

Plan poziomu podstawowego

International Sotware Testing Qualifications Board

Stowarzyszenie Jako

ś

ci Systemów Informatycznych

Wersja 1.0

© Stowarzyszenie Jako

ś

ci Systemów

Informatycznych

Strona 32 z 78

20 pa

ź

dziernika 2006

Protokolant (lub rejestrator): dokumentuje wszystkie kwestie, problemy i otwarte
punkty, które zidentyfikowano podczas spotkania.

Spojrzenie na dokumenty z ró

ż

nych perspektyw oraz u

ż

ywanie list kontrolnych mo

ż

e uczyni

ć

przegl

ą

dy bardziej efektywnymi i wydajnymi. Przykładowo, lista kontrolna oparta na

perspektywach takich jak u

ż

ytkownik, osoba zajmuj

ą

ca si

ę

utrzymaniem oprogramowania,

tester lub wdro

ż

eniowiec albo lista kontrolna typowych problemów wymaga

ń

.

3.2.3. Rodzaje przegl

ą

dów (K2)

Pojedynczy dokument mo

ż

e by

ć

przedmiotem wi

ę

cej ni

ż

jednego przegl

ą

du. Je

ż

eli wykonuje

si

ę

wi

ę

cej ni

ż

jeden rodzaj przegl

ą

du to ich kolejno

ść

mo

ż

e by

ć

ż

na. Na przykład, przegl

ą

d

nieformalny mo

ż

na przeprowadzi

ć

przed przegl

ą

dem technicznym, inspekcj

ę

odno

ś

nie

specyfikacji wymaga

ń

mo

ż

na przeprowadzi

ć

przed przejrzeniem ich z klientami. Główne

cechy, opcje i cele powszechnych rodzajów przegl

ą

du to:

Przegl

ą

d nieformalny

Kluczowe wła

ś

ciwo

ś

ci:

Brak formalnego procesu;

Mo

ż

liwo

ść

zastosowania przy programowaniu parami lub do przegl

ą

dów projektu i

kodu przez kierownika zespołu;

Opcjonalnie: mo

ż

e by

ć

udokumentowany;

Mo

ż

e ró

ż

ni

ć

si

ę

w przydatno

ś

ci w zale

ż

no

ś

ci od przegl

ą

daj

ą

cego;

Główny cel: niedrogi sposób uzyskania pewnej korzy

ś

ci.

Przejrzenie

Kluczowe wła

ś

ciwo

ś

ci:

Spotkanie prowadzone przez autora;

Scenariusze, przegl

ą

dy kodu, grupa kole

ż

e

ń

ska;

Otwarte dyskusje;

Opcjonalnie: przygotowanie przegl

ą

daj

ą

cych przed spotkaniem, raport z przegl

ą

du,

lista wykrytych rzeczy i protokolant, (który nie jest autorem);

W praktyce mo

ż

e by

ć

zró

ż

nicowany od zupełnie nieformalnego do bardzo formalnego;

Główne cele: nauka, zrozumienie, znalezienie defektu.

Przegl

ą

d techniczny

Kluczowe wła

ś

ciwo

ś

ci:

Udokumentowany, nastawiony na wykrycie bł

ę

dów proces, w którym bior

ą

udział

koledzy i eksperci techniczni;

Mo

ż

e by

ć

przeprowadzony jako przegl

ą

d kole

ż

e

ń

ski bez uczestnictwa zarz

ą

du;

Idealnie prowadzony przez wyszkolonego moderatora (nie autora);

Wst

ę

pne przygotowanie przed spotkaniem;

Opcjonalnie: u

ż

ycie list kontrolnych, raportu przegl

ą

du, list wykrytych rzeczy oraz

uczestnictwo zarz

ą

du;

W praktyce mo

ż

e by

ć

zró

ż

nicowany od zupełnie nieformalnego do bardzo formalnego;

Główne cele: przedyskutowa

ć

, podj

ąć

decyzje, oceni

ć

alternatywy, znale

źć

defekty,

rozwi

ą

za

ć

problemy techniczne oraz sprawdzi

ć

zgodno

ść

ze specyfikacjami i

standardami.

Inspekcja

Kluczowe wła

ś

ciwo

ś

ci:

background image

Certyfikowany tester

Plan poziomu podstawowego

International Sotware Testing Qualifications Board

Stowarzyszenie Jako

ś

ci Systemów Informatycznych

Wersja 1.0

© Stowarzyszenie Jako

ś

ci Systemów

Informatycznych

Strona 33 z 78

20 pa

ź

dziernika 2006

Prowadzona przez wyszkolonego moderatora (nie autora);

Zwykle wykonywana przez osoby o podobnych do autora kompetencjach;

Okre

ś

lone role;

Zawiera miary;

Formalny proces oparty na regułach oraz listach kontrolnych z kryteriami
wej

ś

ciowymi i warunkami wyj

ś

cia;

Wst

ę

pne przygotowanie przed spotkaniem;

Raport z inspekcji, lista wykrytych rzeczy;

Formalny proces kontroli po wykonaniu napraw;

Opcjonalnie: ulepszenie procesu oraz czytelnik;

Główny cel: znale

źć

defekty.

3.2.4. Czynniki powodzenia przegl

ą

dów (K2)

O powodzeniu przegl

ą

dów stanowi

ą

nast

ę

puj

ą

ce czynniki:

Ka

ż

dy przegl

ą

d ma na pocz

ą

tku jasno okre

ś

lony cel.

Do celów przegl

ą

du anga

ż

uje si

ę

wła

ś

ciwe osoby.

Znalezione bł

ę

dy przyjmowane s

ą

z rado

ś

ci

ą

i mówi si

ę

o nich obiektywnie.

Ma si

ę

do czynienia z wpływami ludzkimi i aspektami psychologicznymi (np. jest to

pozytywnym do

ś

wiadczeniem dla autora).

Stosuje si

ę

techniki przegl

ą

dowe, które s

ą

odpowiednie dla typu i poziomu produktów

pracy programowej oraz osób przegl

ą

daj

ą

cych.

Je

ś

li stosownym jest zwi

ę

kszy

ć

efektywno

ść

identyfikacji defektu korzysta si

ę

z list

kontrolnych i ról.

Stosuje si

ę

szkolenia w technikach przegl

ą

dowych, szczególnie w bardziej

formalnych technikach takich jak inspekcja.

Zarz

ą

d popiera dobry proces przegl

ą

du (np. poprzez uwzgl

ę

dnienie odpowiedniego

czasu dla czynno

ś

ci przegl

ą

du w harmonogramach projektu).

Kładzie si

ę

nacisk na nauk

ę

i ulepszenie procesu przegl

ą

du.

background image

Certyfikowany tester

Plan poziomu podstawowego

International Sotware Testing Qualifications Board

Stowarzyszenie Jako

ś

ci Systemów Informatycznych

Wersja 1.0

© Stowarzyszenie Jako

ś

ci Systemów

Informatycznych

Strona 34 z 78

20 pa

ź

dziernika 2006

3.3. Analiza statyczna przy pomocy narz

ę

dzi (K2), 20minut

Terminologia

Kompilator, zło

ż

ono

ść

, przepływ sterowania, przepływ danych, analiza statyczna.

Wprowadzenie

Celem analizy statycznej jest wykry

ć

defekt w kodzie

ź

ródłowym oprogramowania lub w

modelach oprogramowania. Analiza statyczna przeprowadzana jest bez równoczesnego
wykonywania badanego oprogramowania przez zewn

ę

trzne narz

ę

dzie (testowanie

dynamiczne wykonuje kod oprogramowania). Analiza statyczna mo

ż

e zlokalizowa

ć

defekty

trudne do wykrycia w innym testowaniu. Tak jak przegl

ą

dy, analiza statyczna wykrywa raczej

defekty ni

ż

awarie. Narz

ę

dzia analizy statycznej analizuj

ą

kod programu (np. przepływ

sterowania i przepływ danych) na tyle skutecznie na ile dobrze generowane jest wyj

ś

cie takie

jak HTML i XML.

Zalety analizy statycznej to:

Wczesne wykrycie bł

ę

dów przed wykonaniem testu.

Dzi

ę

ki obliczeniu miar, takich jak wysoka warto

ść

miary zło

ż

ono

ś

ci, wczesne

ostrze

ż

enie o podejrzanych aspektach kodu lub projektu.

Identyfikacja defektów, których nie daje si

ę

łatwo wykry

ć

podczas testowania

dynamicznego.

Wykrycie zale

ż

no

ś

ci i niespójno

ś

ci w modelach oprogramowania takich jak linki.

Lepsza zdolno

ść

do piel

ę

gnacji kodu i projektu.

Zapobieganie bł

ę

dom, je

ż

eli zdobyto wiedz

ę

podczas tworzenia oprogramowania.

Do typowych bł

ę

dów wykrytych przy pomocy narz

ę

dzi analizy statycznej nale

żą

:

Odwołanie si

ę

do zmiennej z nieokre

ś

lon

ą

warto

ś

ci

ą

;

Niespójny interfejs pomi

ę

dzy modułami;

Zmienne, których nigdy nie u

ż

yto;

Nieosi

ą

galny (martwy) kod;

Naruszenie standardów programowania;

Słabe punkty bezpiecze

ń

stwa;

ę

dy składni kodu i modeli oprogramowania.

Narz

ę

dzia do analizy statycznej u

ż

ywane s

ą

zwykle przez programistów (sprawdzanie

wzgl

ę

dem wcze

ś

niej okre

ś

lonych zasad i standardów programowania) przed i podczas

testowania modułowego i integracyjnego oraz przez projektantów podczas modelowania
oprogramowania. Narz

ę

dzia do analizy statycznej mog

ą

wytworzy

ć

du

żą

liczb

ę

komunikatów

ostrzegawczych. Wymagaj

ą

one dobrego zarz

ą

dzania, aby u

ż

ycie narz

ę

dzia było najbardziej

efektywne.

Kompilatory równie

ż

wykonuj

ą

elementy analizy statycznej, w tym obliczanie miar

dotycz

ą

cych kodu

ź

ródłowego.

Referencje

3.2 IEEE 1028

3.2.2 Gilb,1993, van Veenendaal, 2004

3.2.4 Gilb,1993, IEEE 1028

3.3 Van Veenendaal, 2004

background image

Certyfikowany tester

Plan poziomu podstawowego

International Sotware Testing Qualifications Board

Stowarzyszenie Jako

ś

ci Systemów Informatycznych

Wersja 1.0

© Stowarzyszenie Jako

ś

ci Systemów

Informatycznych

Strona 35 z 78

20 pa

ź

dziernika 2006

4. Techniki projektowania testów (K3), 255 minut

Celem rozdziału „Techniki projektowania testów” jest nauczenie, w
poszczególnych paragrafach:

4.1 Identyfikacja warunków testowych i projektowanie przypadków testowych
(K3)

ż

nic pomi

ę

dzy specyfikacj

ą

projektowania testów, specyfikacj

ą

przypadków

testowych i specyfikacj

ą

procedury testowej. (K1)

Poj

ęć

: warunek testowy, przypadek testowy i procedura testowa. (K2)

Pisania przypadków testowych: (K3)

o

Pokazuj

ą

cych proste

ś

ledzenie powi

ą

za

ń

z wymaganiami;

o

Zawieraj

ą

cych oczekiwany wynik

Tłumaczenia przypadków testowych na poprawnie skonstruowan

ą

specyfikacj

ę

procedury testowej na poziomie szczegółowo

ś

ci odpowiednim dla wiedzy testerów.

(K3)

Pisania harmonogramu wykonania testu dla danego zestawu przypadków testowych,
uwzgl

ę

dniaj

ą

c priorytety oraz zale

ż

no

ś

ci techniczne i logiczne. (K3)

4.2 Kategorie technik projektowania testów (K2)

Powodów, dla których projektowanie przypadków testowych w oparciu o specyfikacj

ę

(podej

ś

cie czarnoskrzynkowe) i projektowanie przypadków testowych w oparciu o

struktur

ę

(podej

ś

cie białoskrzynkowe) jest u

ż

yteczne oraz pokazania podstawowych

technik dla ka

ż

dego z nich. (K1)

Charakterystyk i ró

ż

nic pomi

ę

dzy: testowaniem w oparciu o specyfikacj

ę

,

testowaniem w oparciu o struktur

ę

i testowaniem w oparciu o do

ś

wiadczenia. (K2)

4.3 Techniki testowania w oparciu o specyfikacj

ę

czyli czarnoskrzynkowe (K3)

Pisania przypadków testowych dla zadanych modeli oprogramowania wykorzystuj

ą

c

nast

ę

puj

ą

ce techniki projektowania testów: (K3)

o

Podział na klasy równowa

ż

no

ś

ci;

o

Analiza warto

ś

ci brzegowych;

o

Testowanie w oparciu o tablice decyzyjne;

o

Diagramy przej

ść

pomi

ę

dzy stanami.

Głównych przyczyn zastosowania ka

ż

dej z czterech technik, jakiego poziomu i typu

testy mog

ą

wykorzystywa

ć

t

ę

technik

ę

i jak mo

ż

na zmierzy

ć

pokrycie. (K2)

Koncepcji i zalet testowania w oparciu o przypadki u

ż

ycia. (K2)

4.4 Techniki testowania w oparciu o struktur

ę

lub białoskrzynkowe (K3)

Koncepcji i znaczenia pokrycia kodu. (K2)

Koncepcji pokrycia instrukcji kodu i pokrycia decyzji oraz,

ż

e koncepcje takie mo

ż

na

wykorzysta

ć

na innych poziomach testów ni

ż

testowanie modułowe (np. na poziomie

systemu w procesach biznesowych). (K2)

Napisania przypadków testowych na podstawie podanych przepływów sterowania
wykorzystuj

ą

c nast

ę

puj

ą

ce techniki projektowania testów: (K3)

o

Testowanie instrukcji;

o

Testowanie decyzyjne.

Oszacowania pokrycia instrukcji kodu i decyzji po zako

ń

czeniu testów. (K3)

background image

Certyfikowany tester

Plan poziomu podstawowego

International Sotware Testing Qualifications Board

Stowarzyszenie Jako

ś

ci Systemów Informatycznych

Wersja 1.0

© Stowarzyszenie Jako

ś

ci Systemów

Informatycznych

Strona 36 z 78

20 pa

ź

dziernika 2006

4.5 Techniki w oparciu o do

ś

wiadczenie (K2)

Powodów napisania przypadków testowych w oparciu o intuicj

ę

, do

ś

wiadczenie i

wiedz

ę

o podstawowych defektach. (K1)

Porównywania technik testowania opartych na do

ś

wiadczeniu z technikami w oparciu

o specyfikacj

ę

. (K2)

4.6 Wybór technik testowych (K2)

Czynników, które wpływaj

ą

na wybór wła

ś

ciwej techniki projektowania testów dla

szczególnego rodzaju problemu, takiego jak typ systemu, ryzyko, wymagania klienta,
wzorzec modelowania przypadków u

ż

ycia, modele wymaga

ń

lub wiedza testera. (K2)

background image

Certyfikowany tester

Plan poziomu podstawowego

International Sotware Testing Qualifications Board

Stowarzyszenie Jako

ś

ci Systemów Informatycznych

Wersja 1.0

© Stowarzyszenie Jako

ś

ci Systemów

Informatycznych

Strona 37 z 78

20 pa

ź

dziernika 2006

4.1. Identyfikowanie warunków testowych i projektowanie
przypadków testowych (K3), 15 minut

Terminologia

Przypadki testowe, specyfikacja przypadku testowego, warunek testowy, dane testowe,
specyfikacja procedury testowej, skrypt testowy,

ś

ledzenie powi

ą

za

ń

.

Wprowadzenie

Proces identyfikowania warunków testowych i projektowania testów składa si

ę

z kilku kroków:

Projektowanie testów przez identyfikowanie warunków testowych.

Specyfikowanie przypadków testowych.

Specyfikowanie procedur testowych.

Proces mo

ż

na wykona

ć

w ró

ż

noraki sposób, od bardzo nieformalnego z mał

ą

ilo

ś

ci

ą

dokumentacji lub bez niej do bardzo formalnego (jaki został opisany w tej sekcji). Poziom
sformalizowania zale

ż

y od kontekstu testowania, wliczaj

ą

c w to organizacj

ę

, dojrzało

ść

procesów testowania i programowania, ograniczenia czasowe oraz zaanga

ż

owane osoby.

Podczas projektowania testów analizuje si

ę

podstaw

ę

testów, w celu okre

ś

lenia, co testowa

ć

i w celu identyfikacji warunków testowych. Warunek testowy jest definiowany jako element
lub zdarzenie, które powinno by

ć

zweryfikowane przez jeden lub wi

ę

cej przypadków

testowych (np. funkcja, transakcja, cecha lub element konstrukcyjny).
Ustawienie

ś

ledzenia powi

ą

za

ń

pomi

ę

dzy warunkami testowymi a specyfikacj

ą

lub

wymaganiami umo

ż

liwia analiz

ę

wpływu w momencie zmiany wymaga

ń

oraz analiz

ę

pokrycia wymaga

ń

okre

ś

lonym zestawem testów. Podczas projektowania testów

szczegółowe podej

ś

cie testowe jest budowane na podstawie zidentyfikowanego ryzyka

(patrz rozdział 5, gdzie wi

ę

cej o analizie ryzyka).

W czasie specyfikacji przypadków testowych dane i przypadki testowe s

ą

szczegółowo

budowane i opisywane z wykorzystaniem technik projektowania testów. Przypadek testowy
składa si

ę

z zestawu warto

ś

ci wej

ś

ciowych, warunków pocz

ą

tkowych, oczekiwanych

wyników i warunków ko

ń

cowych, zaprojektowanych w celu pokrycia pewnych warunków

testowych. „Standard Dokumentacji Testowej Oprogramowania” („Standard for Software Test
Documentation” IEEE 829) opisuje zawarto

ść

specyfikacji projektowania testów oraz

zawarto

ść

specyfikacji przypadków testowych.

Oczekiwane wyniki powinny powstawa

ć

jako cz

ęść

specyfikacji przypadku testowego i

powinny zawiera

ć

warto

ś

ci wyj

ś

cia, zmiany danych i stanów oraz inne wyniki wykonania

testu. Je

ż

eli oczekiwane wyniki nie b

ę

d

ą

okre

ś

lone wówczas uzyskany wynik, chocia

ż

ę

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

ą

).

ż

ne procedury testowe i zautomatyzowane skrypty testowe s

ą

nast

ę

pnie wstawiane w

harmonogram wykonania testu, który okre

ś

la kolejno

ść

ich wykonania, oraz kiedy i przez

kogo maj

ą

by

ć

one wykonane. W harmonogramie wykonania testu bierze si

ę

pod uwag

ę

takie czynniki jak testy regresywne, priorytety, zale

ż

no

ś

ci techniczne i logiczne.

background image

Certyfikowany tester

Plan poziomu podstawowego

International Sotware Testing Qualifications Board

Stowarzyszenie Jako

ś

ci Systemów Informatycznych

Wersja 1.0

© Stowarzyszenie Jako

ś

ci Systemów

Informatycznych

Strona 38 z 78

20 pa

ź

dziernika 2006

4.2. Kategorie technik projektowania testów (K2), 15 minut

Terminologia

Techniki czarnoskrzynkowe, techniki oparte na do

ś

wiadczeniu, techniki oparte na

specyfikacji, techniki oparte na strukturze, techniki białoskrzynkowe.

Wprowadzenie

Celem techniki projektowania testów jest zidentyfikowanie warunków testowych i
przypadków testowych.

Klasycznym podziałem technik testowych jest podział na technik

ę

czarnoskrzynkow

ą

i

technik

ę

białoskrzynkow

ą

. Techniki czarnoskrzynkowe (zwane równie

ż

technikami opartymi

na specyfikacji) znajduj

ą

i wybieraj

ą

warunki i przypadki testowe na podstawie analizy

dokumentacji (podstawy testów) zarówno funkcjonalnej jak i niefunkcjonalnej bez
odwoływania si

ę

do jego wewn

ę

trznej struktury. Techniki białoskrzynkowe (zwane równie

ż

technikami strukturalnymi lub opartymi na strukturze) oparte s

ą

na analizie wewn

ę

trznej

struktury modułu lub systemu.

Pewne techniki mieszcz

ą

si

ę

wyra

ź

nie w jednej kategorii; inne maj

ą

elementy z wi

ę

cej ni

ż

jednej kategorii. Konspekt ten odnosi si

ę

do podej

ść

opartych na specyfikacji i opartych na

do

ś

wiadczeniu jako technik czarnoskrzynkowych oraz do podej

ś

cia opartego na strukturze

jako techniki białoskrzynkowej.

Podstawowe cechy technik opartych na specyfikacji:

Modele formalne lub nieformalne s

ą

wykorzystywane do specyfikowania

rozwi

ą

zywanych problemów, systemu lub jego modułów.

Przypadki testowe mog

ą

by

ć

wytwarzane systematycznie na podstawie modeli.

Podstawowe cechy technik opartych na strukturze:

Przypadki testowe pochodz

ą

z informacji o tym jak skonstruowane jest

oprogramowanie, na przykład z kodu lub projektu.

Dla istniej

ą

cych przypadków testowych mo

ż

na mierzy

ć

stopie

ń

pokrycia

oprogramowania i mo

ż

na systematycznie tworzy

ć

kolejne przypadki testowe w celu

poprawienia pokrycia.

Podstawowe cechy technik opartych na do

ś

wiadczeniu:

Do tworzenia przypadków testowych wykorzystuje si

ę

wiedz

ę

i do

ś

wiadczenie osób.

Wiedza testerów, programistów, u

ż

ytkowników i innych interesariuszy na temat

oprogramowania, jego wykorzystywania i

ś

rodowiska;

Wiedza o podobnych defektach i ich dystrybucji.

background image

Certyfikowany tester

Plan poziomu podstawowego

International Sotware Testing Qualifications Board

Stowarzyszenie Jako

ś

ci Systemów Informatycznych

Wersja 1.0

© Stowarzyszenie Jako

ś

ci Systemów

Informatycznych

Strona 39 z 78

20 pa

ź

dziernika 2006

4.3. Techniki na podstawie specyfikacji lub czarnoskrzynkowe (K3),
120 minut

Terminologia

Analiza warto

ś

ci brzegowych, testowanie w oparciu o tablic

ę

decyzyjn

ą

, podział na klasy

równowa

ż

no

ś

ci, testowanie przej

ść

pomi

ę

dzy stanami, testowanie w oparciu o przypadki

u

ż

ycia.

4.3.1. Podział na klasy równowa

ż

no

ś

ci (K3)

Elementy wej

ś

ciowe do oprogramowania lub systemu dzieli si

ę

na grupy o podobnym

charakterze - prawdopodobnie b

ę

d

ą

one przetwarzane przez system w ten sam sposób.

Klasy równowa

ż

no

ś

ci mo

ż

na znale

źć

zarówno dla danych poprawnych jak i niepoprawnych,

tzn. warto

ś

ci, które powinny by

ć

odrzucone. Klasy równowa

ż

no

ś

ci mo

ż

na zidentyfikowa

ć

dla

warto

ś

ci wyj

ś

cia, warto

ś

ci wewn

ę

trznych, warto

ś

ci zale

ż

nych od czasu (np. przed lub po

jakim

ś

zdarzeniu) oraz dla parametrów interfejsów (np. podczas testowania integracyjnego).

Testy mo

ż

na tak zaprojektowa

ć

, aby pokry

ć

klasy równowa

ż

no

ś

ci. Podział na klasy

równowa

ż

no

ś

ci (KR) daje si

ę

stosowa

ć

na wszystkich poziomach testowania.

Klas równowa

ż

no

ś

ci jako techniki mo

ż

na u

ż

ywa

ć

, aby osi

ą

gn

ąć

pokrycie danych

wej

ś

ciowych i wyj

ś

ciowych. Mo

ż

na j

ą

równie

ż

stosowa

ć

w przypadku elementów

wprowadzanych przez człowieka, elementów wprowadzanych do systemu poprzez interfejsy
lub parametrów interfejsowych w testowaniu integracyjnym.

4.3.2. Analiza warto

ś

ci brzegowych (K3)

Maksymalne i minimalne warto

ś

ci klasy równowa

ż

no

ś

ci s

ą

jej warto

ś

ciami brzegowymi.

Istnieje mo

ż

liwo

ść

,

ż

e zachowanie na kraw

ę

dzi ka

ż

dej klasy równowa

ż

no

ś

ci b

ę

dzie

nieprawidłowe, a wi

ę

c brzegi s

ą

miejscem, gdzie testowanie prawdopodobnie wykryje

defekty. Warto

ść

brzegowa dla poprawnej klasy równowa

ż

no

ś

ci jest dozwolon

ą

warto

ś

ci

ą

brzegow

ą

; brzeg niepoprawnej klasy równowa

ż

no

ś

ci jest niepoprawn

ą

warto

ś

ci

ą

brzegow

ą

.

Testy mog

ą

by

ć

projektowane w celu osi

ą

gni

ę

cia pokrycia zarówno poprawnych jak i

niepoprawnych warto

ś

ci brzegowych. Projektuj

ą

c przypadki testowe wybierane s

ą

wszystkie

warto

ś

ci brzegowe.

Analiz

ę

warto

ś

ci brzegowych mo

ż

na wykorzystywa

ć

na wszystkich poziomach testów. Jest

ona łatwa w stosowaniu i posiada du

żą

zdolno

ść

znajdowania bł

ę

dów. W technice tej

pomocne s

ą

szczegółowe specyfikacje.

Technika warto

ś

ci brzegowych cz

ę

sto jest uwzgl

ę

dniana jako rozszerzenie techniki klas

równowa

ż

no

ś

ci i mo

ż

e by

ć

wykorzystywana zarówno dla elementów wprowadzanych przez

człowieka jak i dla elementów z zale

ż

no

ś

ciami czasowymi lub elementów tablicowych.

Warto

ś

ci brzegowe mog

ą

by

ć

równie

ż

wykorzystane do okre

ś

lania danych testowych.

4.3.3. Testowanie w oparciu o tablic

ę

decyzyjn

ą

(K3)

Tablice decyzyjne to dobry sposób na wychwycenie wymaga

ń

zawieraj

ą

cych warunki

logiczne i udokumentowanie wewn

ę

trznego projektu systemu. Mo

ż

na ich u

ż

y

ć

do zapisania

zło

ż

onych reguł biznesowych, które system musi implementowa

ć

. Analizuje si

ę

specyfikacj

ę

,

identyfikuj

ą

c warunki i akcje systemu. Warunki wej

ś

ciowe i akcje ustawia si

ę

najcz

ęś

ciej w

taki sposób, aby mogły odzwierciedla

ć

prawd

ę

lub fałsz (Boolean). Tablica decyzyjna

zawiera warunki przeł

ą

czania, cz

ę

sto kombinacje prawdy i fałszu, dla wszystkich warunków

wej

ś

ciowych oraz wynikaj

ą

ce z nich akcje. Ka

ż

da kolumna tablicy odpowiada regule

background image

Certyfikowany tester

Plan poziomu podstawowego

International Sotware Testing Qualifications Board

Stowarzyszenie Jako

ś

ci Systemów Informatycznych

Wersja 1.0

© Stowarzyszenie Jako

ś

ci Systemów

Informatycznych

Strona 40 z 78

20 pa

ź

dziernika 2006

biznesowej, która okre

ś

la unikaln

ą

kombinacj

ę

warunków, które w rezultacie daj

ą

wykonanie

wszystkich akcji zwi

ą

zanych z t

ą

reguł

ą

. Podstawowym pokryciem wykorzystywanym w

testowaniu w oparciu o tablice decyzyjne jest przynajmniej jeden test dla ka

ż

dej z kolumn,

który zwykle wymaga pokrycia wszystkich kombinacji warunków wyzwalaj

ą

cych.

Siła testowania w oparciu o tablic

ę

decyzyjn

ą

polega na tym,

ż

e tworzy si

ę

kombinacje

warunków, które w inny sposób mogłyby nie by

ć

przetestowane. Testowanie to mo

ż

e by

ć

stosowane we wszystkich sytuacjach, kiedy działanie oprogramowania zale

ż

y od kilku

decyzji logicznych.

4.3.4. Testowanie przej

ść

pomi

ę

dzy stanami (K3)

System mo

ż

e dawa

ć

ż

n

ą

odpowied

ź

w zale

ż

no

ś

ci od bie

żą

cych warunków lub jego historii

(jego stanu). W takim przypadku system mo

ż

na przedstawi

ć

jako diagram przej

ść

pomi

ę

dzy

stanami. Pozwala to testerowi widzie

ć

oprogramowanie w kategoriach jego stanów, przej

ść

pomi

ę

dzy stanami, wej

ść

lub zdarze

ń

, które wyzwalaj

ą

zmiany stanów (przej

ś

cia) i akcji,

które mog

ą

wynika

ć

z tych przej

ść

. Stany systemu lub testowanego obiektu s

ą

rozdzielne,

identyfikowalne i policzalne. Tablica stanów pokazuje zwi

ą

zek pomi

ę

dzy stanami a wej

ś

ciami

i mo

ż

e wskaza

ć

na przej

ś

cia, które s

ą

niedozwolone. Testy mog

ą

by

ć

projektowane w taki

sposób, aby pokry

ć

ka

ż

dy stan, wykona

ć

ka

ż

de przej

ś

cie, wykona

ć

specyficzne sekwencje

przej

ść

lub przetestowa

ć

przej

ś

cia niedozwolone.

Testowanie przej

ść

pomi

ę

dzy stanami wykorzystywane jest w przemy

ś

le tworz

ą

cym

oprogramowanie wbudowane oraz w automatyce. Technika ta jest równie

ż

odpowiednia dla

modelowania obiektu biznesowego maj

ą

cego specyficzne stany lub testowania przepływów

okien dialogowych (np. dla aplikacji internetowych lub scenariuszy biznesowych).

4.3.5. Testowanie w oparciu o przypadki u

ż

ycia (K2)

Testy mog

ą

by

ć

specyfikowane w oparciu o scenariusze biznesowe lub przypadki u

ż

ycia.

Przypadek u

ż

ycia opisuje interakcj

ę

pomi

ę

dzy aktorami (u

ż

ytkownikami) i systemem, która

produkuje warto

ść

wynikow

ą

dla u

ż

ytkownika. Ka

ż

dy przypadek u

ż

ycia posiada warunki

pocz

ą

tkowe, które musz

ą

by

ć

spełnione, aby przypadek zako

ń

czył si

ę

powodzeniem. Ka

ż

dy

przypadek u

ż

ycia ko

ń

czy si

ę

warunkami ko

ń

cowymi, które s

ą

wynikiem po jego wykonaniu i

stanem ko

ń

cowym systemu. Przypadek u

ż

ycia ma scenariusz główny (najbardziej

prawdopodobny) a czasami gał

ę

zie alternatywne.

Przypadki u

ż

ycia opisuj

ą

„przepływy procesów” przez system, bazuj

ą

c na jego mo

ż

liwym

u

ż

yciu. Zatem przypadki testowe powstaj

ą

ce z przypadków u

ż

ycia s

ą

bardzo przydatne w

wyszukiwaniu niewykrytych defektów w rzeczywistych przepływach procesów
wykonywanych w systemie.

Przypadki u

ż

ycia, maj

ą

ce zwi

ą

zek ze scenariuszami, s

ą

bardzo u

ż

yteczne w projektowaniu

testów akceptacyjnych z udziałem klienta/u

ż

ytkownika. Pomagaj

ą

równie

ż

wykry

ć

defekty

integracji powodowane przez współprac

ę

lub kolidowanie ró

ż

nych modułów, a niewykryte

przez indywidualne testy ka

ż

dego z modułów.

background image

Certyfikowany tester

Plan poziomu podstawowego

International Sotware Testing Qualifications Board

Stowarzyszenie Jako

ś

ci Systemów Informatycznych

Wersja 1.0

© Stowarzyszenie Jako

ś

ci Systemów

Informatycznych

Strona 41 z 78

20 pa

ź

dziernika 2006

4.4. Techniki na podstawie struktury lub białoskrzynkowe (K3), 60
minut

Terminologia

Pokrycie kodu, pokrycie decyzji, pokrycie instrukcji kodu, testowanie strukturalne, testowanie
na podstawie struktury, testowanie białoskrzynkowe.

Wprowadzenie

Testowanie na podstawie struktury/testowanie białoskrzynkowe opiera si

ę

na

zidentyfikowanej strukturze oprogramowania lub systemu, jak pokazano w poni

ż

szych

przykładach:

Poziom modułu: struktur

ą

jest kod, tzn. instrukcje, decyzje i rozgał

ę

zienia.

Poziom integracji: struktur

ą

mo

ż

e by

ć

drzewo wywoła

ń

(diagram, w którym moduły

wołaj

ą

inne moduły).

Poziom systemu: struktur

ą

mo

ż

e by

ć

struktura menu, proces biznesowy, struktura

strony WWW.

W sekcji tej przedyskutowano dwie techniki strukturalne dla pokrycia kodu bazuj

ą

ce na

instrukcjach i decyzjach. Dla testowania decyzyjnego, aby pokaza

ć

alternatywy ka

ż

dej

decyzji, mo

ż

na u

ż

y

ć

diagramu przepływu sterowania.

4.4.1. Testowanie instrukcji i pokrycie (K3)

W testowaniu modułowym, pokrycie instrukcji kodu jest procentow

ą

ocen

ą

wykonywalnych

instrukcji, które zostały wykonane przez zestaw przypadków testowych. W testowaniu
instrukcji przypadki testowe projektuje si

ę

tak, aby wykona

ć

okre

ś

lone instrukcje - zwi

ę

kszy

ć

pokrycie instrukcji kodu.

4.4.2. Testowanie decyzyjne i pokrycie (K3)

Pokrycie decyzji, w odniesieniu do testowania rozgał

ę

zie

ń

, jest procentow

ą

ocen

ą

rezultatów

decyzyjnych (opcji Prawda i Fałsz z instrukcji IF), które zostały wykonane przez zestaw
przypadków testowych. W testowaniu decyzyjnym przypadki testowe projektuje si

ę

tak, aby

uzyska

ć

okre

ś

lone rezultaty decyzyjne – zwi

ę

kszy

ć

pokrycie decyzji.

Testowanie decyzyjne jest rodzajem testowania przepływu sterowania, poniewa

ż

generuje

okre

ś

lony przepływ sterowania przez punkty decyzyjne. Pokrycie decyzji jest silniejsze ni

ż

pokrycie instrukcji kodu: 100% pokrycie decyzji gwarantuje 100% pokrycie instrukcji kodu,
ale nie odwrotnie.

4.4.3. Inne techniki na podstawie struktury (K1)

Istniej

ą

lepsze poziomy pokrycia strukturalnego poza pokryciem decyzyjnym, np. pokrycie

warunków i pokrycie warunków wielokrotnych.

Koncepcja pokrycia mo

ż

e by

ć

równie

ż

stosowana na innych poziomach testów (np. na

poziomie integracji), gdzie procent modułów lub klas, które zostały sprawdzone przez zestaw
przypadków testowych, mo

ż

e wyra

ż

a

ć

pokrycie modułów lub klas.

W testowaniu strukturalnym przydatne jest wsparcie narz

ę

dziowe.

background image

Certyfikowany tester

Plan poziomu podstawowego

International Sotware Testing Qualifications Board

Stowarzyszenie Jako

ś

ci Systemów Informatycznych

Wersja 1.0

© Stowarzyszenie Jako

ś

ci Systemów

Informatycznych

Strona 42 z 78

20 pa

ź

dziernika 2006

4.5. Techniki oparte na do

ś

wiadczeniu (K2), 30 minut

Terminologia

Zgadywanie bł

ę

dów, testowanie eksploracyjne.

Wprowadzenie

Najbardziej rozpowszechnion

ą

technik

ą

testowania jest zgadywanie bł

ę

dów. Testy tworzone

s

ą

na podstawie umiej

ę

tno

ś

ci, intuicji i do

ś

wiadczenia testerów z podobnymi aplikacjami i

technologiami. Testowanie intuicyjne, wykorzystane do uzupełnienia technik
systematycznych, mo

ż

e by

ć

przydatne do wykonania specjalnych testów trudno

wykonalnych przez techniki formalne (zwłaszcza, gdy stosowane jest po bardziej formalnych
podej

ś

ciach). Jednak

ż

e technika ta mo

ż

e znacznie ró

ż

ni

ć

si

ę

efektywno

ś

ci

ą

, zale

ż

n

ą

od

do

ś

wiadczenia testerów. Uporz

ą

dkowanym podej

ś

ciem dla techniki zgadywania bł

ę

dów jest

sporz

ą

dzenie wykazu mo

ż

liwych bł

ę

dów i takie zaprojektowanie testów, aby je znale

źć

.

Wykazy defektów i awarii mog

ą

by

ć

budowane na podstawie do

ś

wiadczenia testerów,

dost

ę

pnych danych o defektach i awariach oraz ogólnej wiedzy, dlaczego oprogramowanie

ulega awariom.

Testowanie eksploracyjne jest równoczesnym projektowaniem, wykonywaniem, logowaniem
testu oraz nauk

ą

, opartymi na karcie testu zawieraj

ą

cej cele testu i ramy czasowe ich

wykonania. Podej

ś

cie to jest u

ż

yteczne w przypadku niepełnej lub nieodpowiedniej

specyfikacji, nacisków na skrócenie czasu testowania, lub dla poszerzenia i uzupełnienia
bardziej formalnego testowania. Technika ta mo

ż

e słu

ż

y

ć

jako sprawdzenie procesu

testowego, aby upewni

ć

si

ę

,

ż

e najpowa

ż

niejsze defekty zostały wykryte.

background image

Certyfikowany tester

Plan poziomu podstawowego

International Sotware Testing Qualifications Board

Stowarzyszenie Jako

ś

ci Systemów Informatycznych

Wersja 1.0

© Stowarzyszenie Jako

ś

ci Systemów

Informatycznych

Strona 43 z 78

20 pa

ź

dziernika 2006

4.6. Wybór technik testowych (K2), 15 minut

Terminologia

Brak szczególnych poj

ęć

.

Wprowadzenie

Wybór technik testowych zale

ż

y od szeregu czynników, wliczaj

ą

c w to typ systemu,

obowi

ą

zuj

ą

ce standardy, wymagania umowy lub klienta, poziom ryzyka, typ ryzyka, cel testu,

dost

ę

pn

ą

dokumentacj

ę

, do

ś

wiadczenie testerów, czas i bud

ż

et, cykl

ż

ycia projektu, modele

przypadków u

ż

ycia oraz wiedza o rodzajach znalezionych wcze

ś

niej bł

ę

dów.

Pewne techniki daj

ą

si

ę

stosowa

ć

dla okre

ś

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

ż

na

stosowa

ć

na ka

ż

dym poziomie testów.

Referencje:

4.1 Craig, 2002, Hetzel, 1998, IEEE 829

4.2 Beizer, 1990, Copeland, 2004

4.3.1 Copeland, 2004, Myers, 1979

4.3.2 Copeland, 2004, Myers, 1979

4.3.3 Beizer, 1990, Copeland, 2004

4.3.4 Beizer, 1990, Copeland, 2004

4.3.5 Copeland, 2004

4.4.3 Beizer, 1990, Copeland, 2004

4.5 Kaner, 2002

4.6 Beizer, 1990, Copeland, 2004

background image

Certyfikowany tester

Plan poziomu podstawowego

International Sotware Testing Qualifications Board

Stowarzyszenie Jako

ś

ci Systemów Informatycznych

Wersja 1.0

© Stowarzyszenie Jako

ś

ci Systemów

Informatycznych

Strona 44 z 78

20 pa

ź

dziernika 2006

5. Zarz

ą

dzanie testowaniem (K3), 180 minut

Celem rozdziału „Zarz

ą

dzanie testowaniem” jest nauczenie, w

poszczególnych paragrafach:

5.1 Organizacja testowania (K2)

Znaczenia niezale

ż

nego testowania. (K1)

Zalet i wad niezale

ż

nego testowania w organizacji. (K2)

Jakie osoby powinny wchodzi

ć

w skład zespołu testowego. (K1)

Typowych zada

ń

kierownika testów i testera. (K1)

5.2 Planowanie i oszacowanie pracochłonno

ś

ci testów (K2)

ż

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)

ż

nic w dwóch sposobach podej

ś

cia do oszacowania pracochłonno

ś

ci testowania:

na podstawie danych pomiarowych oraz na podstawie oceny eksperckiej. (K2)

Okre

ś

lenia zakresu planowania testów dla projektu, dla poszczególnych poziomów

testów (np. dla testu systemowego), dla okre

ś

lonych celów (np. testy u

ż

yteczno

ś

ci)

oraz dla wykonywania testów. (K2)

Czynno

ś

ci wchodz

ą

cych w skład przygotowywania i wykonywania testów, które

wymagaj

ą

planowania. (K1)

Uzasadnienia odpowiednich warunków wyj

ś

cia dla okre

ś

lonych poziomów testów lub

grup przypadków testowych (np. przypadków testowych dla testów integracyjnych,
testów akceptacyjnych lub testów u

ż

yteczno

ś

ci). (K2)

5.3 Monitorowanie i nadzorowanie procesu testowego (K2)

Jakie typowe metryki stosuje si

ę

do monitorowania przygotowywania i wykonywania

testów.

Interpretacji metryk dotycz

ą

cych raportowania i nadzorowania testów (np. liczba

znalezionych i naprawionych bł

ę

dów, wykonanych zaliczonych i niezaliczonych

testów). (K2)

Celu i tre

ś

ci ko

ń

cowego raportu testowego wg definicji z normy „Norma Dokumentacji

Testowej” (Standard for Software Test Documentation, IEEE 829). (K2)

5.4 Zarz

ą

dzanie konfiguracj

ą

(K2)

W jaki sposób zarz

ą

dzanie konfiguracj

ą

wspiera testowanie.

5.5 Ryzyko a testowanie (K2)

Ryzyka jako mo

ż

liwego problemu, zagra

ż

aj

ą

cego osi

ą

gni

ę

ciu celów jednego lub

wielu interesariuszy projektu. (K2)

ś

e ryzyko okre

ś

la prawdopodobie

ń

stwo wyst

ą

pienia zdarzenia oraz jego

konsekwencje (koszty wyst

ą

pienia ryzyka). (K1)

ż

nic mi

ę

dzy ryzykami projektowymi oraz ryzykami odnosz

ą

cymi si

ę

do produktu.

Rozpoznawania typowych zagro

ż

e

ń

dotycz

ą

cych produktu i projektu.

Jak analiza i planowanie ryzyka mog

ą

by

ć

wykorzystane do planowania testów. (K2)

background image

Certyfikowany tester

Plan poziomu podstawowego

International Sotware Testing Qualifications Board

Stowarzyszenie Jako

ś

ci Systemów Informatycznych

Wersja 1.0

© Stowarzyszenie Jako

ś

ci Systemów

Informatycznych

Strona 45 z 78

20 pa

ź

dziernika 2006

5.6 Zarz

ą

dzanie incydentami (K3)

Tre

ś

ci zgłoszenia incydentu wg normy „Norma Dokumentacji Testowej” (Standard for

Software Test Documentation, IEEE 829). (K1)

Pisania zgłoszenia incydentu dotycz

ą

cego awarii zaobserwowanej w trakcie

testowania. (K3)

background image

Certyfikowany tester

Plan poziomu podstawowego

International Sotware Testing Qualifications Board

Stowarzyszenie Jako

ś

ci Systemów Informatycznych

Wersja 1.0

© Stowarzyszenie Jako

ś

ci Systemów

Informatycznych

Strona 46 z 78

20 pa

ź

dziernika 2006

5.1. Organizacja testowania (K2), 30 minut

Terminologia

Tester, kierownik testów, mened

ż

er testów.

5.1.1. Organizacja i niezale

ż

no

ść

testowania (K2)

Skuteczno

ść

znajdowania bł

ę

dów drog

ą

testowania i przegl

ą

dów mo

ż

na podnie

ść

wykorzystuj

ą

c niezale

ż

nych testerów. Istniej

ą

nast

ę

puj

ą

ce formy niezale

ż

nego testowania:

Niezale

ż

ni testerzy w zespołach programistów.

Niezale

ż

ny zespół albo grupa testowa w organizacji, podlegaj

ą

ca kierownictwu

projektu albo kierownictwu przedsi

ę

biorstwa.

Niezale

ż

ni testerzy z działu biznesowego, przedstawicieli u

ż

ytkowników ko

ń

cowych

oraz działu informatyki.

Niezale

ż

ni specjali

ś

ci testowi dla okre

ś

lonych celów, tacy jak testerzy u

ż

yteczno

ś

ci,

testerzy zabezpiecze

ń

lub testerzy certyfikacyjni, testuj

ą

cy oprogramowanie pod

k

ą

tem zgodno

ś

ci z normami i innymi regulacjami prawnymi.

Dla du

ż

ych, zło

ż

onych projektów lub w zespołach wytwarzaj

ą

cych produkty krytyczne pod

wzgl

ę

dem bezpiecze

ń

stwa, zwykle najkorzystniejsze jest testowanie na wielu poziomach,

gdzie pewne poziomy testowania wykonywane s

ą

przez niezale

ż

nych testerów. Deweloperzy

mog

ą

uczestniczy

ć

w testowaniu, zwłaszcza na ni

ż

szych poziomach, ale ich brak

obiektywno

ś

ci ogranicza ich skuteczno

ść

. Niezale

ż

ni testerzy mog

ą

uzyska

ć

upowa

ż

nienie

do domagania si

ę

oraz definiowania procesów i procedur testowych, ale tego rodzaju

żą

dania dotycz

ą

ce procesu powinny by

ć

przez nich podejmowane tylko pod warunkiem

uzyskania jednoznacznego upowa

ż

nienia ze strony kierownictwa.

Korzy

ś

ci niezale

ż

no

ś

ci to:

Niezale

ż

ni testerzy dostrzegaj

ą

cz

ę

sto inne bł

ę

dy ni

ż

dostrze

ż

one przez

konstruktorów, a ponadto podchodz

ą

do testowanego oprogramowania bez gotowych

oczekiwa

ń

i uprzedze

ń

.

Niezale

ż

ny tester mo

ż

e tak

ż

e zweryfikowa

ć

poprawno

ść

zało

ż

e

ń

, których dokonano

podczas specyfikacji oraz implementacji systemu.

Wady niezale

ż

no

ś

ci to:

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

ż

no

ść

jest zupełna).

Niezale

ż

ni testerzy mog

ą

sta

ć

si

ę

w

ą

skim gardłem projektu, gdy spoczywa na nich

odpowiedzialno

ść

za ostateczn

ą

kontrol

ę

produktu.

Deweloperzy mog

ą

utraci

ć

poczucie współodpowiedzialno

ś

ci za jako

ść

.

Zadania testowe bywaj

ą

wykonywane przez osoby maj

ą

ce przypisan

ą

rol

ę

testerów, lub

przez inne osoby, na przykład przez kierownika projektu, kierownika jako

ś

ci, dewelopera,

specjalist

ę

biznesowego i dziedzinowego, eksperta z działu informatyki lub

odpowiedzialnego za infrastruktur

ę

.

5.1.2. Zadania kierownika testów i testera (K1)

Niniejszy plan omawia dwie role zwi

ą

zane z testowaniem: kierownika testów oraz testera.

Czynno

ś

ci i zadania wykonywane przez osoby wykonuj

ą

ce te dwie role zale

żą

od formy

projektu i rodzaju produktu, od osób realizuj

ą

cych te role oraz od specyfiki organizacyjnej.

Czasem kierownik testów bywa nazywany mened

ż

erem lub koordynatorem testów. Funkcj

ę

kierownika testów mo

ż

e wykonywa

ć

kierownik projektu, kierownik zespołu programistów,

kierownik jako

ś

ci albo mened

ż

er zespołu testowego. W du

ż

ych projektach mog

ą

background image

Certyfikowany tester

Plan poziomu podstawowego

International Sotware Testing Qualifications Board

Stowarzyszenie Jako

ś

ci Systemów Informatycznych

Wersja 1.0

© Stowarzyszenie Jako

ś

ci Systemów

Informatycznych

Strona 47 z 78

20 pa

ź

dziernika 2006

wyst

ę

powa

ć

obie role: kierownika i mened

ż

era testów. Kierownik testów zwykle planuje,

monitoruje i nadzoruje czynno

ś

ci i zadania testowe w sposób opisany w cz

ęś

ci 1.4.

Zwykle spotykane zadania kierownika testów to:

Koordynowanie strategii i planu testów z kierownikami projektów i innymi

interesariuszami.

Stworzenie lub dokonanie przegl

ą

du strategii testowej dla projektu, a polityki testowej

dla organizacji.

Dbało

ść

o uwzgl

ę

dnienie aspektów testowych w innych obszarach projektu, np. w

planowaniu integracji.

Planowanie testowania – z uwzgl

ę

dnieniem kontekstu i ryzyka. Planowanie obejmuje

wybór metodyk testowania, oszacowanie czasochłonno

ś

ci, wysiłku oraz kosztów

testowania, uzyskanie odpowiednich zasobów, okre

ś

lenie poziomów, cykli, metod

oraz celów testowania, a tak

ż

e zaplanowanie zarz

ą

dzania zgłoszeniami zdarze

ń

.

Zainicjowanie i nadzorowanie specyfikacji, przygotowania oraz implementacji testów,

a w szczególno

ś

ci monitorowanie i nadzorowanie ich wykonywania,

Ustawienie odpowiedniego poziomu zarz

ą

dzania konfiguracj

ą

,

Wprowadzenie odpowiednich metryk, by mierzy

ć

post

ę

p testowania i okre

ś

la

ć

jako

ść

testowania i produktu

Okre

ś

lenie zakresu i stopnia automatyzacji.

Wybór narz

ę

dzi wspieraj

ą

cych testowanie oraz zorganizowanie niezb

ę

dnych szkole

ń

narz

ę

dziowych.

Podj

ę

cie decyzji dotycz

ą

cych

ś

rodowiska testowego.

Sporz

ą

dzenie harmonogramu testowania.

Sporz

ą

dzanie ko

ń

cowych raportów testowych na podstawie informacji

zgromadzonych podczas wykonywania testów.

Typowe zadania testera obejmuj

ą

:

Przegl

ą

danie i wnoszenie wkładu do planu testów

Analiza, przegl

ą

d i dost

ę

p do wymaga

ń

u

ż

ytkownika, specyfikacji oraz modeli

testowalno

ś

ci

Tworzenie

ś

rodowiska testowego (cz

ę

sto we współpracy z administracj

ą

systemu i

zarz

ą

dzaj

ą

cymi sieci

ą

)

Przygotowanie i pozyskiwanie danych testowych

Implementacja testów na wszystkich poziomach, wykonywanie testów, zapisywanie

wyników do dziennika (logu) testów, porównywanie wyników i dokumentowanie
odchyle

ń

od spodziewanego wyniku

U

ż

ywanie – w razie potrzeby - narz

ę

dzi do administrowania lub zarz

ą

dzania testami,

Automatyzacja testów (w razie potrzeby we współpracy z deweloperami lub

ekspertami od automatyzacji testów)

Mierzenie wydajno

ś

ci modułów lub systemów – je

ś

li ma to zastosowanie

Przegl

ą

danie testów zaprojektowanych przez innych


Osoby, które pracuj

ą

przy analizie testów, projektowaniu testów, testach specyficznych

typów lub automatyzacji testów powinny by

ć

specjalistami w swych rolach. W zale

ż

no

ś

ci od

poziomu testów i ryzyka zwi

ą

zanego z produktem lub projektem, ró

ż

ni ludzie mog

ą

pracowa

ć

jako testerzy, zachowuj

ą

c pewien stopie

ń

niezale

ż

no

ś

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

integracji, testerami mog

ą

by

ć

deweloperzy, przy testach akceptacyjnych mog

ą

to by

ć

eksperci biznesowi lub u

ż

ytkownicy, przy akceptacji operacyjnej testerami powinni by

ć

operatorzy systemu.

background image

Certyfikowany tester

Plan poziomu podstawowego

International Sotware Testing Qualifications Board

Stowarzyszenie Jako

ś

ci Systemów Informatycznych

Wersja 1.0

© Stowarzyszenie Jako

ś

ci Systemów

Informatycznych

Strona 48 z 78

20 pa

ź

dziernika 2006

5.2. Planowanie testowania (K2), 50 minut

Terminologia

Kryteria wej

ś

cia, kryteria wyj

ś

cia, testowanie eksploracyjne, metodyka testowa, poziom

testowy, plan testów, procedura testów, strategia testowa.

5.2.1. Planowanie testowania (K2)

Niniejsza sekcja po

ś

wi

ę

cona jest planowaniu testowania w projektach wytwarzania,

implementacji oraz utrzymania oprogramowania. Planowanie mo

ż

e by

ć

udokumentowane w

planie testów projektu lub w głównym planie testów, a tak

ż

e w odr

ę

bnych planach testów dla

poszczególnych poziomów, np. dla testu systemowego lub testu akceptacyjnego. Wzorce
dokumentacji planów testów znajduj

ą

si

ę

w Standard for Software Test Documentation (IEEE

829).

Na planowanie wpływa: polityka testów w organizacji, zakres testowania, cele, zagro

ż

enia,

ograniczenia, krytyczno

ść

, łatwo

ść

testowania i dost

ę

pno

ść

zasobów. Im dalej posuwa si

ę

planowanie projektu i testowania, tym wi

ę

cej informacji jest do dyspozycji i tym bardziej

szczegółowy staje si

ę

plan.

Planowanie jest stał

ą

czynno

ś

ci

ą

i wykonuje si

ę

je we wszystkich procesach i fazach cyklu

ż

yciowego oprogramowania. Informacja zwrotna z realizacji planu testów umo

ż

liwia

identyfikacj

ę

zmieniaj

ą

cego si

ę

ryzyka, co pozwala na dostosowywanie planu.

5.2.2. Czynno

ś

ci wykonywane podczas planowania testów (K2)

W trakcie planowania testów mog

ą

by

ć

wykonywane nast

ę

puj

ą

ce czynno

ś

ci:

Okre

ś

lenia ogólnej metodyki (strategii) testowej, w tym poziomów testowania oraz

kryteriów wej

ś

cia (dopuszczenia do testowania) i wyj

ś

cia (zako

ń

czenia testowania).

Zintegrowanie i skoordynowanie testowania z fazami cyklu

ż

yciowego

oprogramowania: zakup, dostawa, wytwarzanie, działanie operacyjne oraz
utrzymanie.

Podejmowanie decyzji, co b

ę

dzie przedmiotem testów, jakie role b

ę

d

ą

przypisane,

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

ę

d

ą

zadania testowe, jak b

ę

d

ą

oceniane wyniki testów, kiedy zako

ń

czy

ć

testowanie (kryteria wyj

ś

cia).

Przydzielanie zasobów zdefiniowanym zadaniom.

Okre

ś

lenie ilo

ś

ci, szczegółowo

ś

ci, struktury i wzorców dokumentacji testowej.

Wybór miar słu

żą

cych do monitorowania i nadzoru nad przygotowywaniem i

wykonywaniem testów, rozwi

ą

zywania zgłosze

ń

ę

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.

background image

Certyfikowany tester

Plan poziomu podstawowego

International Sotware Testing Qualifications Board

Stowarzyszenie Jako

ś

ci Systemów Informatycznych

Wersja 1.0

© Stowarzyszenie Jako

ś

ci Systemów

Informatycznych

Strona 49 z 78

20 pa

ź

dziernika 2006

Istniej

ą

ce zagro

ż

enia, takie jak nienaprawione bł

ę

dy lub brak pokrycia pewnych

obszarów.

Harmonogramy, na przykład narzucaj

ą

ce dat

ę

dostawy.

5.2.4. Oszacowanie wysiłku testowego (K2)

Plan omawia dwa sposoby oszacowywania wysiłku testowego:

Oszacowanie wysiłku testowego na podstawie pomiarów z wcze

ś

niejszych lub z

podobnych projektów albo na podstawie typowych wielko

ś

ci.

Oszacowanie zada

ń

przez osoby za nie odpowiedzialne lub przez ekspertów.

Po oszacowaniu pracochłonno

ś

ci zada

ń

mo

ż

liwe jest przypisanie im zasobów i sporz

ą

dzenie

harmonogramu.

Pracochłonno

ść

testowania zale

ż

y od wielu czynników, w tym:

Wła

ś

ciwo

ś

ci produktu: jako

ś

ci specyfikacji i innych

ź

ródeł informacji, na podstawie, których

budowane s

ą

modele (np. podstawy testowej), wielko

ś

ci produktu, zło

ż

ono

ś

ci zagadnie

ń

dziedziny, wymaga

ń

dotycz

ą

cych niezawodno

ś

ci i zabezpiecze

ń

oraz wymaga

ń

dotycz

ą

cych

dokumentacji.
Wła

ś

ciwo

ś

ci procesu wytwarzania: stabilno

ś

ci organizacji, stosowanych narz

ę

dzi, procesu

testowego, umiej

ę

tno

ś

ci personelu, napi

ę

to

ś

ci harmonogramu.

Wyników testowania: liczby znalezionych bł

ę

dów i ilo

ś

ci niezb

ę

dnych przeróbek.

5.2.5. Sposoby podej

ś

cia do testowania (strategie testowe) (K2)

W Jednym ze sposobów kategoryzacji podej

ś

cia lub strategii testowych stosuje si

ę

kryterium

czasu, kiedy odbywa si

ę

wi

ę

kszo

ść

pracy zwi

ą

zanej z testowaniem:

Metody prewencyjne, w których testy projektuje si

ę

tak wcze

ś

nie jak to tylko mo

ż

liwe.

Metody reaktywne, w których projektowanie testów nast

ę

puje dopiero po

wyprodukowaniu oprogramowania lub systemu.

Typowe strategie testowe to:

Metody analityczne, na przykład testowanie na podstawie ryzyka, w których

testowanie koncentrowane jest w obszarach najwy

ż

szego zagro

ż

enia.

Metody modelowania, na przykład testowanie stochastyczne na podstawie danych

statystycznych dotycz

ą

cych cz

ę

stotliwo

ś

ci awarii (modele wzrostu niezawodno

ś

ci)

lub dotycz

ą

cych cz

ę

stotliwo

ś

ci zastosowania (profile u

ż

ycia operacyjnego).

Metody systematyczne, takie jak testowanie na podstawie danych o awariach (w tym

domy

ś

lanie si

ę

ę

dów i ataki przy pomocy bł

ę

dnych danych), na podstawie list

kontrolnych oraz na podstawie atrybutów jako

ś

ci.

Metody zgodne z procesem, standardem lub norm

ą

, na przykład okre

ś

lone przez

standard bran

ż

owy lub metodyki zwinne.

Metody dynamiczne i heurystyczne, na przykład testowanie eksploracyjne, w których

testowanie polega bardziej na reagowaniu na wydarzenia ni

ż

na planowaniu, i gdzie

wykonywanie i ocena odbywaj

ą

si

ę

równolegle.

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

ż

aj

ą

cej mierze

zadaniem ekspertów w dziedzinie technologii lub zastosowania biznesowego,
nienale

żą

cych do zespołu testowego.

Podej

ś

cia maj

ą

ce na celu ograniczenie pracochłonno

ś

ci testów regresji poprzez

ponowne u

ż

ycie artefaktów testowych, rozbudowan

ą

automatyzacj

ę

oraz

wykorzystanie standardowych zestawów testów.

ż

ne metody mo

ż

na ł

ą

czy

ć

, np. dynamiczna metodyka na podstawie oszacowania ryzyka.

Wybieraj

ą

c metodyk

ę

testow

ą

, nale

ż

y uwzgl

ę

dni

ć

takie aspekty jak:

background image

Certyfikowany tester

Plan poziomu podstawowego

International Sotware Testing Qualifications Board

Stowarzyszenie Jako

ś

ci Systemów Informatycznych

Wersja 1.0

© Stowarzyszenie Jako

ś

ci Systemów

Informatycznych

Strona 50 z 78

20 pa

ź

dziernika 2006

Ryzyko niepowodzenia projektu, zagro

ż

enia wobec produktu oraz zagro

ż

enie dla

ludzi,

ś

rodowiska lub firmy spowodowane awari

ą

produktu.

Umiej

ę

tno

ś

ci i do

ś

wiadczenie ludzi uczestnicz

ą

cych w projekcie w zakresie

planowanych technik, narz

ę

dzi i metod.

Cel przedsi

ę

wzi

ę

cia testowego oraz misj

ę

zespołu testowego.

Przepisy, zarówno zewn

ę

trzne jak i wewn

ę

trzne, dotycz

ą

ce procesu wytwarzania.

Rodzaj i specyfik

ę

produktu lub przedsi

ę

wzi

ę

cia.

background image

Certyfikowany tester

Plan poziomu podstawowego

International Sotware Testing Qualifications Board

Stowarzyszenie Jako

ś

ci Systemów Informatycznych

Wersja 1.0

© Stowarzyszenie Jako

ś

ci Systemów

Informatycznych

Strona 51 z 78

20 pa

ź

dziernika 2006

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

Terminologia

G

ę

sto

ść

defektów, cz

ę

stotliwo

ść

awarii, nadzór nad testowaniem, pokrycie testowe,

monitorowanie testowania, raport testowy.

5.3.1. Monitorowanie post

ę

pu testów (K1)

Celem monitorowania testów jest uzyskanie informacji zwrotnej o zadaniach testowych oraz
unaocznienie ich przebiegu. Monitorowan

ą

informacj

ę

mo

ż

na zbiera

ć

r

ę

cznie lub

automatycznie i mo

ż

na j

ą

stosowa

ć

do pomiaru spełnienia kryteriów wyj

ś

cia, (np. analizy

pokrycia). Pomiary mog

ą

słu

ż

y

ć

równie

ż

do oceny post

ę

pu prac w porównaniu z

harmonogramem i bud

ż

etem. Przykłady cz

ę

sto stosowanych miar:

Jaka cz

ęść

prac przygotowawczych została wykonana, lub jaki odsetek

zaplanowanych przypadków testowych przygotowano (wykonano).

Jak

ą

cz

ęść

wykonano przygotowuj

ą

c

ś

rodowisko testowe.

Przebieg wykonania testów (np. liczba wykonanych i niewykonanych przypadków

testowych, liczba zaliczonych i niezaliczonych przypadków testowych).

Dane o bł

ę

dach, np. g

ę

sto

ść

defektów, liczba znalezionych i naprawionych defektów,

cz

ę

stotliwo

ść

awarii, wyniki testów zgodno

ś

ci lub retestów.

Pokrycie wymaga

ń

, ryzyka lub kodu.

Subiektywne poczucie testerów dotycz

ą

ce niezawodno

ś

ci produktu.

Daty testowych kamieni milowych.

Koszty testowania, w tym koszty porównawcze wobec korzy

ś

ci znalezienia

nast

ę

pnego defektu lub wykonania kolejnego testu.

5.3.2. Raportowanie testów (K2)

Celem raportowania jest podanie podsumowuj

ą

cych danych dotycz

ą

cych przebiegu

przedsi

ę

wzi

ę

cia testowego, takich jak:

Co zdarzyło si

ę

w okresie testowania, np. daty spełnienia kryteriów wyj

ś

cia.

Analiza danych oraz pomiarów w celu uzasadnienia rekomendacji i decyzji, np. ocena

ile pozostało jeszcze defektów, ekonomiczna opłacalno

ść

dalszego testowania,

istniej

ą

ce zagro

ż

enia, oraz okre

ś

lenie poziomu zaufania do testowanego

oprogramowania.

Przykładowy wzorzec ko

ń

cowego raportu testowego znajduje si

ę

w normie IEEE 829

„Standard for Software Test Documentation”.

W trakcie i pod koniec ka

ż

dego poziomu testów nale

ż

y wykonywa

ć

pomiary, aby móc oceni

ć

nast

ę

puj

ą

ce elementy:

Wła

ś

ciwy dobór celów testowania dla danego poziomu.

Na ile przyj

ę

ta metodyka testowa jest odpowiednia.

Na ile testowanie jest skuteczne w porównaniu z przyj

ę

tymi celami.

5.3.3. Nadzór nad testowaniem (K2)

Nadzór nad testowaniem obejmuje wszelkie czynno

ś

ci nadaj

ą

ce testom kierunek oraz

wszelkie działania naprawcze, które podejmuje si

ę

w wyniku zgromadzonych i

zaraportowanych danych i pomiarów. Czynno

ś

ci te mog

ą

dotyczy

ć

wszystkich zada

ń

testowych i mog

ą

wywiera

ć

wpływ na wszystkie inne czynno

ś

ci podejmowane w cyklu

ż

ycia

oprogramowania.

background image

Certyfikowany tester

Plan poziomu podstawowego

International Sotware Testing Qualifications Board

Stowarzyszenie Jako

ś

ci Systemów Informatycznych

Wersja 1.0

© Stowarzyszenie Jako

ś

ci Systemów

Informatycznych

Strona 52 z 78

20 pa

ź

dziernika 2006

Przykłady czynno

ś

ci nadzorczych:

Zmiana wag testów po zmaterializowaniu si

ę

jakiego

ś

ryzyka (np. spó

ź

nionej

dostawie oprogramowania).

Zmiana harmonogramu uwzgl

ę

dniaj

ą

ca dost

ę

pno

ść

ś

rodowiska testowego.

Ustalenie kryteriów wej

ś

ciowych wymagaj

ą

cych, aby naprawy bł

ę

dów były ponownie

przetestowane przez programist

ę

przed ich wł

ą

czeniem do budowy nowej wersji

oprogramowania.

background image

Certyfikowany tester

Plan poziomu podstawowego

International Sotware Testing Qualifications Board

Stowarzyszenie Jako

ś

ci Systemów Informatycznych

Wersja 1.0

© Stowarzyszenie Jako

ś

ci Systemów

Informatycznych

Strona 53 z 78

20 pa

ź

dziernika 2006

5.4. Zarz

ą

dzanie konfiguracj

ą

(K2), 10 minut

Terminologia

Zarz

ą

dzanie konfiguracj

ą

, nadzór nad wersjami.

Wprowadzenie

Celem zarz

ą

dzania konfiguracj

ą

jest uzyskanie i utrzymanie spójno

ś

ci produktów

(komponentów, danych i dokumentacji) oprogramowania lub systemu podczas projektu i w
cyklu

ż

yciowym produktu.

Z punktu widzenia testowania, zarz

ą

dzanie konfiguracj

ą

słu

ż

y do osi

ą

gni

ę

cia:

Identyfikacji wersji, nadzoru nad nimi, zapisywania zmian,

ś

ledzenia relacji mi

ę

dzy

artefaktami testowymi oraz relacji mi

ę

dzy nimi a przedmiotem testu w celu

utrzymania kontroli nad przeprowadzonymi zmianami w trakcie całego procesu
testowania.

Jednoznacznej identyfikacji wszelkich dokumentów oraz elementów oprogramowania,

do których odwołuje si

ę

dokumentacja testowa.

Zarz

ą

dzanie konfiguracj

ą

umo

ż

liwia testerom jednoznaczne zidentyfikowanie i odtworzenie

testowanego elementu, dokumentacji testowej, testów oraz jarzma testowego.

Planowanie testów powinno okre

ś

li

ć

, udokumentowa

ć

i wdro

ż

y

ć

procedury oraz

infrastruktur

ę

(narz

ę

dzia) do zarz

ą

dzania konfiguracj

ą

.

background image

Certyfikowany tester

Plan poziomu podstawowego

International Sotware Testing Qualifications Board

Stowarzyszenie Jako

ś

ci Systemów Informatycznych

Wersja 1.0

© Stowarzyszenie Jako

ś

ci Systemów

Informatycznych

Strona 54 z 78

20 pa

ź

dziernika 2006

5.5. Ryzyko a testowanie (K2), 30 minut

Terminologia

Ryzyko produktowe, ryzyko projektowe, testowanie na podstawie ryzyka.

Wprowadzenie

Ryzyko mo

ż

na zdefiniowa

ć

jako prawdopodobie

ń

stwo wyst

ą

pienia wydarzenia, zagro

ż

enia

lub niepo

żą

danej w skutkach sytuacji jako mo

ż

liwego problemu. Poziom ryzyka okre

ś

laj

ą

prawdopodobie

ń

stwo niekorzystnego zdarzenia oraz jego konsekwencje (szkoda b

ę

d

ą

ca

skutkiem tego zdarzenia).

5.5.1. Ryzyko projektowe (K1, K2)

Ryzyko projektowe to ryzyko zdolno

ś

ci projektu do osi

ą

gni

ę

cia celów, na przykład:

Problemy z dostawcami:

Niepowodzenie dostawy;

Kwestie dotycz

ą

ce kontraktu.

Czynniki organizacyjne:

o

Brak personelu i/lub niezb

ę

dnych umiej

ę

tno

ś

ci

o

Problemy osobiste i problemy dotycz

ą

ce szkole

ń

;

Kwestie organizacyjne, np.

o

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

o

Niewykorzystanie informacji zdobytej podczas testowania i przegl

ą

dów, np.

zaniechanie usprawniania procedur i innych praktyk testowych).

o

Niewła

ś

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

wyszukiwania defektów podczas testowania).

Czynniki techniczne:

o

Niewła

ś

ciwie okre

ś

lone wymagania;

o

Wymagania nie s

ą

w pełni osi

ą

galne przy istniej

ą

cych ograniczeniach;

o

Jako

ść

projektu, kodu i testów.

Analizuj

ą

c, zarz

ą

dzaj

ą

c i zapobiegaj

ą

c tym zagro

ż

eniom, kierownik projektu post

ę

puje

według znanych zasad zarz

ą

dzania projektami. Wzorzec planu testów wg normy IEEE 829

(„Standard for Software Test Documentation”) wymaga okre

ś

lenia zagro

ż

e

ń

i zaplanowania

czynno

ś

ci zaradczych.

5.5.2. Ryzyko zwi

ą

zane z produktem (K2)

Jako ryzyko zwi

ą

zane z produktem okre

ś

la si

ę

obszary mo

ż

liwych awarii (niekorzystne

przyszłe wydarzenia lub zagro

ż

enia) w oprogramowaniu lub systemie, gdy

ż

zagra

ż

aj

ą

one w

ż

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

ść

).

background image

Certyfikowany tester

Plan poziomu podstawowego

International Sotware Testing Qualifications Board

Stowarzyszenie Jako

ś

ci Systemów Informatycznych

Wersja 1.0

© Stowarzyszenie Jako

ś

ci Systemów

Informatycznych

Strona 55 z 78

20 pa

ź

dziernika 2006

Oprogramowanie, które nie spełnia zało

ż

onej funkcjonalno

ś

ci.

Przy pomocy ryzyka mo

ż

na okre

ś

li

ć

, kiedy nale

ż

y rozpocz

ąć

testowanie i gdzie warto

testowa

ć

wi

ę

cej. Testowanie ogranicza prawdopodobie

ń

stwo niekorzystnego wydarzenia lub

zmniejsza skutki jego wyst

ą

pienia.

Ryzyko zwi

ą

zane z produktem jest rodzajem zagro

ż

enia dla powodzenia projektu.

Testowanie pozwala nadzorowa

ć

ryzyko, dostarczaj

ą

c informacji o poziomie zagro

ż

enia

dzi

ę

ki pomiarom skuteczno

ś

ci usuwania krytycznych defektów oraz planów awaryjnych.

Metodyka testowania bazuj

ą

ca na ryzyku stwarza mo

ż

liwo

ś

ci aktywnego ograniczania ryzyk

zwi

ą

zanych z produktem od najwcze

ś

niejszych etapów projektu. Testowanie umo

ż

liwia

identyfikacj

ę

ryzyk, a nast

ę

pnie wykorzystania ich w planowaniu, specyfikacji, przygotowaniu

i wykonaniu testów. Zidentyfikowane ryzyka mo

ż

na wykorzysta

ć

do:

Okre

ś

lenia, jakie zastosowa

ć

techniki testowania.

Okre

ś

lenia zakresu testów.

Uporz

ą

dkowania testów pod wzgl

ę

dem ich wag, aby móc jak najwcze

ś

niej

znale

źć

najistotniejsze defekty.

Okre

ś

lenia, jakie czynno

ś

ci poza testowaniem warto wykorzysta

ć

dla

ograniczenia ryzyka (np. odpowiednio szkol

ą

c niedo

ś

wiadczonych projektantów).

Testowanie na podstawie ryzyka wykorzystuje wspóln

ą

wiedz

ę

i do

ś

wiadczenie

interesariuszy w celu okre

ś

lenia ryzyk i poziomu testów niezb

ę

dnych dla ich kontrolowania.

Aby zminimalizowa

ć

ryzyko awarii produktu, w zarz

ą

dzaniu ryzykiem stosuje si

ę

zdyscyplinowane metody maj

ą

ce na celu:

Ocen

ę

– regularnie powtarzan

ą

– mo

ż

liwych wyst

ą

pie

ń

niekorzystnych wydarze

ń

(ryzyk).

Okre

ś

lenie wagi ryzyk.

Wdro

ż

enie czynno

ś

ci maj

ą

cych na celu eliminowanie ryzyk.

Testowanie umo

ż

liwia tak

ż

e identyfikacj

ę

nowych ryzyk, okre

ś

lenie którym ryzykom nale

ż

y

zapobiega

ć

oraz pozwala na trafniejsz

ą

ocen

ę

ich prawdopodobie

ń

stwa.

background image

Certyfikowany tester

Plan poziomu podstawowego

International Sotware Testing Qualifications Board

Stowarzyszenie Jako

ś

ci Systemów Informatycznych

Wersja 1.0

© Stowarzyszenie Jako

ś

ci Systemów

Informatycznych

Strona 56 z 78

20 pa

ź

dziernika 2006

5.6. Zarz

ą

dzanie incydentami (K3), 40 minut

Terminologia

Logowanie incydentów.

Wprowadzenie

Jednym z celów testowania jest znajdowanie defektów, a wi

ę

c nale

ż

y prowadzi

ć

logowanie

incydentów - niezgodno

ś

ci mi

ę

dzy oczekiwanymi a rzeczywistymi wynikami testów.

Incydenty nale

ż

y nadzorowa

ć

od ich odkrycia, poprzez zaklasyfikowanie, naprawienie i

potwierdzenie skuteczno

ś

ci naprawy. Aby zarz

ą

dza

ć

incydentami, organizacje powinny

okre

ś

li

ć

i stosowa

ć

proces i reguły ich klasyfikacji.

Incydenty mog

ą

by

ć

zgłaszane podczas wytwarzania, przegl

ą

dów, testowania lub

u

ż

ytkowania oprogramowania. Incydenty mog

ą

dotyczy

ć

kodu, działaj

ą

cego systemu lub

wszelkiej dokumentacji, w tym dokumentacji dotycz

ą

cej wytwarzania, dokumentacji testowej

lub dokumentacji przeznaczonej dla u

ż

ytkownika, takiej jak instrukcja u

ż

ytkownika lub

instrukcja instalacji.

Celem zgłosze

ń

incydentów jest:

Dostarczenie konstruktorom i innym interesariuszom informacji o incydencie, by
umo

ż

liwi

ć

identyfikacj

ę

, wyizolowanie oraz – w razie potrzeby – napraw

ę

ę

du.

Dostarczenie kierownictwu testów bie

żą

cej informacji o jako

ś

ci testowanego

systemu oraz o przebiegu testów.

Generowanie propozycji udoskonalenia procesu testowego.

Tester lub osoba wykonuj

ą

ca przegl

ą

d zwykle notuje nast

ę

puj

ą

ce dane (gdy s

ą

dost

ę

pne) na

temat incydentu:

Dat

ę

zgłoszenia, organizacj

ę

zgłaszaj

ą

c

ą

, autora, zatwierdzenie i status.

Czego dotyczy zgłoszenie, jego wag

ę

i priorytet.

Odno

ś

niki, w tym identyfikator przypadku testowego, który ujawnił problem.

Zgłoszenie incydentu mo

ż

e zawiera

ć

nast

ę

puj

ą

ce dane:

Wynik rzeczywisty i oczekiwany.

Dat

ę

odkrycia incydentu.

Okre

ś

lenie elementu konfiguracji oprogramowania lub systemu.

W jakiej fazie cyklu

ż

ycia oprogramowania zaobserwowano incydent.

Opis niezgodno

ś

ci ułatwiaj

ą

cy okre

ś

lenie jej przyczyny.

Konsekwencje dla interesariuszy.

Okre

ś

lenie stopnia pilno

ś

ci rozwi

ą

zania.

Status zgłoszenia (np. otwarte, odrzucone, powtórne zgłoszenie, oczekuj

ą

ce na

napraw

ę

, naprawione oczekuj

ą

ce na re-test, zamkni

ę

te).

Wnioski i zalecenia.

Zagadnienia ogólne, na przykład inne obszary, na które mog

ą

mie

ć

wpływ zmiany

przeprowadzone skutkiem naprawy bł

ę

du powoduj

ą

cego incydent.

background image

Certyfikowany tester

Plan poziomu podstawowego

International Sotware Testing Qualifications Board

Stowarzyszenie Jako

ś

ci Systemów Informatycznych

Wersja 1.0

© Stowarzyszenie Jako

ś

ci Systemów

Informatycznych

Strona 57 z 78

20 pa

ź

dziernika 2006

Historia zmian, na przykład, jakie czynno

ś

ci zostały wykonane w celu

wyizolowania, naprawienia oraz potwierdzenia skuteczno

ś

ci naprawy.

IEEE 829 („Standard for Software Test Documentation”) okre

ś

la tre

ść

i struktur

ę

zgłoszenia

incydentu, nazywanego w normie tej zgłoszeniem niezgodno

ś

ci.

Bibliografia:

5.1.1 Black, 2001, Hetzel, 1998

5.1.2 Black, 2001, Hetzel, 1998

5.2.5 Black, 2001, Craig, 2002, IEEE 829, Kaner 2002

5.3.3 Black, 2001, Craig, 2002, Hetzel, 1998, IEEE 829

5.4 Craig, 2002

5.5.2 Black, 2001, IEEE 829

5.6 Black, 2001, IEEE 829

background image

Certyfikowany tester

Plan poziomu podstawowego

International Sotware Testing Qualifications Board

Stowarzyszenie Jako

ś

ci Systemów Informatycznych

Wersja 1.0

© Stowarzyszenie Jako

ś

ci Systemów

Informatycznych

Strona 58 z 78

20 pa

ź

dziernika 2006

6. Testowanie wspierane narz

ę

dziami (K2), 80 minut

Celem rozdziału „Testowanie wspierane narz

ę

dziami” jest

nauczenie, w poszczególnych paragrafach:

6.1 Rodzaje narz

ę

dzi testowych (K2)

O ró

ż

nych rodzajach narz

ę

dzi testowych nadaj

ą

cych si

ę

do ró

ż

nych czynno

ś

ci

testowych. (K2)

O narz

ę

dziach, które mog

ą

by

ć

wykorzystane do testowania wykonywanego przez

programistów. (K1)

6.2 Skuteczne u

ż

ycie narz

ę

dzi: potencjalne korzy

ś

ci i zagro

ż

enia (K2)

Potencjalnych korzy

ś

ci i zagro

ż

e

ń

automatyzacji testów oraz wykorzystania narz

ę

dzi

wpieraj

ą

cych testowanie. (K2)

ż

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)

background image

Certyfikowany tester

Plan poziomu podstawowego

International Sotware Testing Qualifications Board

Stowarzyszenie Jako

ś

ci Systemów Informatycznych

Wersja 1.0

© Stowarzyszenie Jako

ś

ci Systemów

Informatycznych

Strona 59 z 78

20 pa

ź

dziernika 2006

6.1. Rodzaje narz

ę

dzi testowych (K2), 45 minut

Terminologia

Narz

ę

dzie do zarz

ą

dzania konfiguracj

ą

, narz

ę

dzie do pomiaru pokrycia, debager, sterownik,

narz

ę

dzie do analizy dynamicznej, narz

ę

dzie do zarz

ą

dzania zgłoszeniami bł

ę

dów,

narz

ę

dzie do testów obci

ąż

eniowych, narz

ę

dzie do modelowania, narz

ę

dzie monitoruj

ą

ce,

narz

ę

dzie do testów wydajno

ś

ciowych, efekt próbnika, narz

ę

dzie do zarz

ą

dzania

wymaganiami, narz

ę

dzie wspieraj

ą

ce proces przegl

ą

du, narz

ę

dzie do testów zabezpiecze

ń

,

narz

ę

dzie do analizy statycznej, narz

ę

dzie do testów przeci

ąż

enia, za

ś

lepka, komparator,

narz

ę

dzie do tworzenia danych testowych, narz

ę

dzie do projektowania testów, jarzmo

testowe, narz

ę

dzie wspieraj

ą

ce wykonanie testu, narz

ę

dzie wspieraj

ą

ce zarz

ą

dzanie testami,

narz

ę

dzie do testów jednostkowych.

6.1.1.

Klasyfikacja narz

ę

dzi testowych

Istnieje wiele narz

ę

dzi wspieraj

ą

cych ró

ż

ne aspekty testowania. Klasyfikacja zastosowana w

niniejszym konspekcie dokonana jest na podstawie czynno

ś

ci testowych, które s

ą

wspierane

przez narz

ę

dzia.

Niektóre narz

ę

dzia słu

żą

do wsparcia tylko jednej czynno

ś

ci, inne mog

ą

by

ć

wykorzystywane

do ró

ż

nych czynno

ś

ci, ale zaklasyfikowane zostały zgodnie z t

ą

czynno

ś

ci

ą

, do której

najcz

ęś

ciej s

ą

stosowane. Niektóre narz

ę

dzia komercyjne wspieraj

ą

tylko jeden rodzaj

czynno

ś

ci, ale niektórzy dostawcy komercyjnych narz

ę

dzi oferuj

ą

zestawy albo rodziny

narz

ę

dzi, wspieraj

ą

cych wiele ró

ż

nych czynno

ś

ci testowych.

Narz

ę

dzia umo

ż

liwiaj

ą

usprawnienie testowania dzi

ę

ki zautomatyzowaniu wielokrotnie

wykonywanych czynno

ś

ci testowych. Narz

ę

dzia mog

ą

tak

ż

e poprawi

ć

niezawodno

ść

testowania dzi

ę

ki automatyzacji porównywania du

ż

ej ilo

ś

ci danych lub symulowania

okre

ś

lonych zachowa

ń

ś

rodowiska testowanego systemu.

Niektóre rodzaje narz

ę

dzi s

ą

inwazyjne, co oznacza,

ż

e samo zastosowanie narz

ę

dzia

wywiera wpływ na rzeczywisty wynik testu. Na przykład, rzeczywisty czas wykonania mo

ż

e

zale

ż

e

ć

od tego, w jaki sposób narz

ę

dzia do testów wydajno

ś

ciowych dokonuj

ą

pomiarów.

Zale

ż

nie od zastosowanego narz

ę

dzia mo

ż

na otrzyma

ć

tak

ż

e ró

ż

ne wyniki pomiarów

pokrycia kodu. Skutek inwazyjno

ś

ci narz

ę

dzia nazywany jest efektem próbnika.

Niektóre narz

ę

dzia wspieraj

ą

czynno

ś

ci wykonywane najcz

ęś

ciej przez programistów (np.

podczas testowania modułowego oraz testowania integracji modułów). Takie narz

ę

dzia

oznaczone s

ą

liter

ą

„(D)” w poni

ż

szej klasyfikacji.

6.1.2.

Zarz

ą

dzanie testowaniem wspierane narz

ę

dziami (K1)

Zarz

ą

dzanie testowaniem wspierane narz

ę

dziami znajduje zastosowanie we wszystkich

czynno

ś

ciach testowych podczas całego cyklu

ż

ycia oprogramowania.

Narz

ę

dzia do zarz

ą

dzania testami

Narz

ę

dzia do zarz

ą

dzania testami maj

ą

nast

ę

puj

ą

ce funkcje:

Wsparcie zarz

ą

dzania testami i innymi wykonywanymi czynno

ś

ciami testowymi.

Interfejsy do narz

ę

dzi wspieraj

ą

cych wykonanie testu, zarz

ą

dzanie zgłoszeniami

ę

dów i zarz

ą

dzanie wymaganiami.

Wbudowane zarz

ą

dzanie wersjami lub interfejs do zewn

ę

trznego narz

ę

dzia do

zarz

ą

dzania wersjami.

background image

Certyfikowany tester

Plan poziomu podstawowego

International Sotware Testing Qualifications Board

Stowarzyszenie Jako

ś

ci Systemów Informatycznych

Wersja 1.0

© Stowarzyszenie Jako

ś

ci Systemów

Informatycznych

Strona 60 z 78

20 pa

ź

dziernika 2006

Mo

ż

liwo

ść

ś

ledzenia powi

ą

za

ń

testów, wyników testów oraz incydentów z

dokumentami

ź

ródłowymi, takimi jak specyfikacje wymaga

ń

.

Logowanie wyników testów i tworzenie raportów z post

ę

pu realizacji testów.

Analiz

ę

ilo

ś

ciow

ą

(miary) dotycz

ą

c

ą

testów (np. liczba wykonanych i zaliczonych

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

ą

c

ą

na celu uzyskanie

informacji o przedmiocie testów oraz nadzorowanie i udoskonalanie procesu
testowania.

Narz

ę

dzia do zarz

ą

dzania wymaganiami

Narz

ę

dzia do zarz

ą

dzania wymaganiami słu

żą

do przechowywania wymaga

ń

, kontroli

spójno

ś

ci wymaga

ń

oraz identyfikacji niezdefiniowanych (brakuj

ą

cych) wymaga

ń

. Narz

ę

dzia

te umo

ż

liwiaj

ą

ponadto okre

ś

lenie priorytetów wymaga

ń

, oraz

ś

ledzenie powi

ą

za

ń

pojedynczych testów z wymaganiami, funkcjami lub obszarami funkcjonalno

ś

ci systemu.

Powi

ą

zania te mog

ą

by

ć

wykorzystywane w raportach post

ę

pu prac. Raportowane mo

ż

e by

ć

tak

ż

e pokrycie testami: wymaga

ń

, funkcji lub funkcjonalno

ś

ci systemu.

Narz

ę

dzia do zarz

ą

dzania incydentami

Narz

ę

dzia do zarz

ą

dzania incydentami słu

żą

do przechowywania i zarz

ą

dzania zgłoszeniami

incydentów, czyli defektów, awarii oraz innych obserwowanych problemów lub anomalii.
Wspieraj

ą

one zarz

ą

dzanie zgłoszeniami incydentów m.in. poprzez:

Ułatwianie priorytetyzacji zgłosze

ń

.

Przydzielanie osobom zada

ń

do wykonania (np. napraw

ę

ę

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

ń

ę

dów.

Narz

ę

dzia do zarz

ą

dzania konfiguracj

ą

Narz

ę

dzia do zarz

ą

dzania konfiguracj

ą

nie s

ą

w pełni narz

ę

dziami testowymi, ale s

ą

z reguły

niezb

ę

dne do zarz

ą

dzania ró

ż

nymi wersjami i build’ami oprogramowania i testów.

Narz

ę

dzia do zarz

ą

dzania konfiguracj

ą

:

Przechowuj

ą

dane na temat wersji i build’ów oprogramowania oraz artefaktów

testowych (testaliów).

Pozwalaj

ą

ś

ledzi

ć

powi

ą

zania mi

ę

dzy testaliami oraz produktami programistycznymi i

ich wariantami.

S

ą

szczególnie przydatne, gdy wytwarzana jest wi

ę

cej ni

ż

jedna konfiguracja

oprogramowania i sprz

ę

tu (np. dla ró

ż

nych wersji systemu operacyjnego, bibliotek lub

kompilatorów, ró

ż

nych przegl

ą

darek lub ró

ż

nych typów komputerów).

background image

Certyfikowany tester

Plan poziomu podstawowego

International Sotware Testing Qualifications Board

Stowarzyszenie Jako

ś

ci Systemów Informatycznych

Wersja 1.0

© Stowarzyszenie Jako

ś

ci Systemów

Informatycznych

Strona 61 z 78

20 pa

ź

dziernika 2006

6.1.3.

Testowanie statyczne wspierane narz

ę

dziami (K1)

Narz

ę

dzia wspieraj

ą

ce proces przegl

ą

du

Narz

ę

dzia wspieraj

ą

ce proces przegl

ą

du mog

ą

gromadzi

ć

dane na temat procesów

przegl

ą

du, przechowywa

ć

i słu

ż

y

ć

do przekazywania komentarzy przegl

ą

dowych,

raportowa

ć

znalezione defekty oraz pracochłonno

ść

, zarz

ą

dza

ć

odwołaniami do reguł

wykonywania przegl

ą

dów lub list kontrolnych, a tak

ż

e

ś

ledzi

ć

powi

ą

zania mi

ę

dzy

dokumentacj

ą

a kodem

ź

ródłowym. Mog

ą

tak

ż

e pozwala

ć

na wykonywanie przegl

ą

dów on-

line, co jest po

żą

dane w geograficznie rozproszonych projektach.

Narz

ę

dzia do analizy statycznej (D)

Narz

ę

dzia do analizy statycznej umo

ż

liwiaj

ą

programistom, testerom i specjalistom od

zapewnienia jako

ś

ci znajdowanie defektów przed rozpocz

ę

ciem testowania dynamicznego.

Ich podstawowe cele to:

Nadzorowanie przestrzegania standardów kodowania.

Analiza struktur i zale

ż

no

ś

ci (np. poł

ą

czonych stron internetowych).

Ułatwienie zrozumienia kodu.

Narz

ę

dzia do analizy statycznej na podstawie kodu mog

ą

wylicza

ć

miary (np. zło

ż

ono

ść

), co

jest cenn

ą

informacj

ą

np. przy planowaniu i analizie ryzyka.

Narz

ę

dzia do modelowania (D)

Narz

ę

dzia do modelowania pozwalaj

ą

dokonywa

ć

walidacji modeli oprogramowania. Na

przykład sprawdzenie modelu bazy danych mo

ż

e znale

źć

defekty i niespójno

ś

ci w modelu

danych; inne narz

ę

dzia do modelowania pozwalaj

ą

znajdowa

ć

defekty w modelach przej

ść

stanów (automatów sko

ń

czonych) lub w modelach obiektowych. Cz

ę

sto narz

ę

dzia tego

rodzaju umo

ż

liwiaj

ą

wygenerowanie przypadków testowych z modelu (patrz te

ż

„Narz

ę

dzia

wspieraj

ą

ce projektowanie testów” poni

ż

ej).

Podstawow

ą

korzy

ś

ci

ą

z zastosowania narz

ę

dzi do modelowania i analizy statycznej jest

oszcz

ę

dno

ść

wynikaj

ą

ca ze znajdowania bł

ę

dów we wcze

ś

niejszych fazach procesu

wytwarzania oprogramowania. Dzi

ę

ki temu proces wytwarzania mo

ż

e odbywa

ć

si

ę

szybciej i

sprawniej, gdy

ż

ogranicza si

ę

ilo

ść

przeróbek.

6.1.4.

Tworzenie specyfikacji testów wspierane narz

ę

dziami

Narz

ę

dzia wspieraj

ą

ce projektowanie testów

Narz

ę

dzia wspieraj

ą

ce projektowanie testów generuj

ą

wej

ś

ciowe dane testowe lub testy z

wymaga

ń

, z graficznego interfejsu u

ż

ytkownika, z modeli projektowych (stanów, danych lub

obiektów) lub z kodu

ź

ródłowego. Ten rodzaj narz

ę

dzi pozwala tak

ż

e generowa

ć

wyniki

oczekiwane (np. wykorzystuj

ą

c wyroczni

ę

). Testy wygenerowane z modelu automatu

sko

ń

czonego lub modelu obiektowego s

ą

przydatne do weryfikacji poprawno

ś

ci

implementacji modelu w kodzie, ale z reguły nie s

ą

wystarczaj

ą

ce dla zweryfikowania

wszystkich aspektów oprogramowania lub systemu. Pozwalaj

ą

zaoszcz

ę

dzi

ć

cenny czas i

zapewni

ć

wi

ę

ksz

ą

staranno

ść

dzi

ę

ki temu,

ż

e testy wygenerowane przez narz

ę

dzia s

ą

kompletne i dotycz

ą

wszystkich obszarów funkcjonalno

ś

ci systemu.

Inne narz

ę

dzia tego rodzaju wspomagaj

ą

generowanie testów dostarczaj

ą

c

strukturalizowanych wzorców, niekiedy nazywanych wzorcami testowymi, które generuj

ą

testy lub za

ś

lepki testowe, co przy

ś

piesza proces projektowania testów.

background image

Certyfikowany tester

Plan poziomu podstawowego

International Sotware Testing Qualifications Board

Stowarzyszenie Jako

ś

ci Systemów Informatycznych

Wersja 1.0

© Stowarzyszenie Jako

ś

ci Systemów

Informatycznych

Strona 62 z 78

20 pa

ź

dziernika 2006

Narz

ę

dzia do przygotowywania danych testowych (D)

Narz

ę

dzia do przygotowywania danych testowych generuj

ą

dane testowe wykorzystywane

przy wykonywaniu testów z baz danych, plików lub zarejestrowanych przekazów danych.
Zalet

ą

tych narz

ę

dzi jest (dzi

ę

ki usuni

ę

ciu szczegółowych danych osobowych)

zabezpieczenie poufnych danych wykorzystanych w

ś

rodowisku testowym.

6.1.5.

Wykonywanie testów wspierane narz

ę

dziami

Wykonywanie testów wspierane narz

ę

dziami

Wykonywanie testów wspierane narz

ę

dziami umo

ż

liwia automatyczne lub półautomatyczne

wykonywanie testów sterowanych j

ę

zykiem skryptowym, wykorzystuj

ą

cych zebrane dane

wej

ś

ciowe oraz wyniki oczekiwane. J

ę

zyk skryptowy ułatwia sterowanie testami, na przykład

wielokrotne powtórzenie testu z ró

ż

nymi danymi lub przetestowanie ró

ż

nych cz

ęś

ci systemu

przy u

ż

yciu tych samych kroków. Zwykle narz

ę

dzia tego rodzaju pozwalaj

ą

na dynamiczne

porównywanie wyników oraz tworzenie logu dla ka

ż

dego wykonania testu.

Narz

ę

dzia wspieraj

ą

ce wykonanie testów mog

ą

by

ć

te

ż

stosowane do rejestrowania testów.

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

ż

ycia skryptów testowych mog

ą

by

ć

przydatne w celu

odtworzenia lub udokumentowania testów w przypadku awarii.

Jarzma testowe oraz narz

ę

dzia wspomagaj

ą

ce do testów jednostkowych

Jarzmo testowe ułatwia testowanie komponentów lub cz

ęś

ci systemu, symuluj

ą

c

ś

rodowisko

danego obiektu testowego. Jarzma testowe stosuje si

ę

z dwóch przyczyn. Po pierwsze, gdy

inne komponenty

ś

rodowiska nie s

ą

jeszcze dost

ę

pne i zast

ę

puje si

ę

je za

ś

lepkami lub

sterownikami, a po drugie, aby wykonywanie testów odbywało si

ę

w sprawdzonym i

przewidywalnym

ś

rodowisku, co umo

ż

liwia lokalizacj

ę

ę

dów w obiekcie testowym.

Rusztowanie testowe tworzy si

ę

, gdy testowany fragment kodu: obiekt, metoda, funkcja lub

moduł jest wykonywany poprzez jego wywołanie i dostarczenie mu sprz

ęż

enia zwrotnego.

Osi

ą

ga si

ę

to dostarczaj

ą

c testowanemu obiektowi (niestandardowymi metodami)

wej

ś

ciowych danych testowych lub za

ś

lepek mog

ą

cych odbiera

ć

dane wyj

ś

ciowe z tego

obiektu w miejsce rzeczywistych odbiorców.

Jarzma testowe stosuje si

ę

tak

ż

e w celu stworzenia rusztowania na poziomie

oprogramowania po

ś

redniego umo

ż

liwiaj

ą

cego jednoczesne testowanie

ś

rodowiska j

ę

zyka

programowania, systemu operacyjnego lub platformy sprz

ę

towej.

Jarzma testowe mo

ż

emy okre

ś

la

ć

jako rusztowania do testów modułowych, gdy

ż

stosuje si

ę

je przede wszystkim na poziomie testów modułowych. Ten typ narz

ę

dzi wspomaga

wykonywanie testów modułowych równolegle z tworzeniem kodu.

Narz

ę

dzia do porównywania wyników (komparatory)

Komparatory testowe słu

żą

do porównywania plików, baz danych lub wyników testów. W

skład narz

ę

dzi do wykonywania testów wchodz

ą

zwykle komparatory dynamiczne, ale

niekiedy porównanie wykonuje si

ę

dopiero po zako

ń

czeniu testowania przy pomocy

odr

ę

bnego narz

ę

dzia do porównywania wyników. Komparator testowy posługuje si

ę

niekiedy

wyroczni

ą

, zwłaszcza zautomatyzowan

ą

.

Narz

ę

dzia do pomiaru pokrycia (D)

Narz

ę

dzia do pomiaru pokrycia testowego s

ą

inwazyjne lub nieinwazyjne, zale

ż

nie od

techniki wykonywania pomiaru, wykorzystywanej miary pokrycia oraz j

ę

zyka programowania.

background image

Certyfikowany tester

Plan poziomu podstawowego

International Sotware Testing Qualifications Board

Stowarzyszenie Jako

ś

ci Systemów Informatycznych

Wersja 1.0

© Stowarzyszenie Jako

ś

ci Systemów

Informatycznych

Strona 63 z 78

20 pa

ź

dziernika 2006

Narz

ę

dzia do pomiaru pokrycia mierz

ą

odsetek okre

ś

lonych konstrukcji w kodzie (np.

instrukcji, rozgał

ę

zie

ń

, decyzji, wywoła

ń

funkcji lub modułów), które zostały wykonane

podczas testowania. Miary pokrycia wykazuj

ą

, w jakim stopniu konstrukcje b

ę

d

ą

ce

przedmiotem pomiaru s

ą

testowane przez dany zestaw testów.

Narz

ę

dzia do testów zabezpiecze

ń

Narz

ę

dzia do testów zabezpiecze

ń

(odporno

ś

ci) wyłapuj

ą

wirusy komputerowe oraz

identyfikuj

ą

ataki maj

ą

ce na celu przeci

ąż

enie serwerów. Na przykład zapora ogniowa nie

jest narz

ę

dziem testowym, ale mo

ż

e by

ć

stosowana do testowania zabezpiecze

ń

. Inne

narz

ę

dzia do testowania zabezpiecze

ń

słu

żą

do poszukiwania okre

ś

lonych typów braku

odporno

ś

ci i niezabezpieczonego dost

ę

pu do systemów.

6.1.6.

Testowanie wydajno

ś

ci i monitorowanie wspierane narz

ę

dziami

(K1)

Narz

ę

dzia do analizy dynamicznej (D)

Narz

ę

dzia do analizy dynamicznej odnajduj

ą

defekty daj

ą

ce si

ę

zaobserwowa

ć

wył

ą

cznie

podczas wykonywania oprogramowania, takie jak zale

ż

no

ś

ci czasowe lub wycieki pami

ę

ci.

U

ż

ywa si

ę

ich zwykle podczas testowania modułowego, testowania integracji modułów oraz

do testowania oprogramowania po

ś

redniego.

Narz

ę

dzia do testów wydajno

ś

ci, obci

ąż

enia i przeci

ąż

aj

ą

cych

Narz

ę

dzia do testów wydajno

ś

ci monitoruj

ą

i raportuj

ą

działanie systemu w ró

ż

norodnych

symulowanych warunkach u

ż

ytkowania. Narz

ę

dzia te symuluj

ą

obci

ąż

enie aplikacji, bazy

danych albo komponentów

ś

rodowiska systemu, takich jak sie

ć

lub serwer. Nazwy tych

narz

ę

dzi (na przykład narz

ę

dzia do testów obci

ąż

enia lub przeci

ąż

aj

ą

cych) zwykle okre

ś

laj

ą

,

do testowania jakiego aspektu wydajno

ś

ci s

ą

stosowane. Ich działanie polega zazwyczaj na

wielokrotnym, automatycznym wykonywaniu sparametryzowanych testów.

Narz

ę

dzia do monitorowania

Narz

ę

dzia do monitorowania systemów nie s

ą

ś

ci

ś

le rzecz bior

ą

c narz

ę

dziami testowymi, ale

dostarczaj

ą

informacji niedost

ę

pnej w inny sposób, wykorzystywanej do celów testowania.

Narz

ę

dzia monitoruj

ą

ce na bie

żą

co analizuj

ą

, weryfikuj

ą

i raportuj

ą

wykorzystanie

okre

ś

lonych zasobów systemowych oraz ostrzegaj

ą

o zagro

ż

eniach systemu. Ponadto

przechowuj

ą

dane dotycz

ą

ce wersji i build’ów oprogramowania, testaliów, a tak

ż

e

umo

ż

liwiaj

ą

ś

ledzenie powi

ą

za

ń

.

6.1.7.

Narz

ę

dzia wspieraj

ą

ce testowanie w okre

ś

lonych dziedzinach

Niektóre narz

ę

dzia nale

żą

ce do opisywanych powy

ż

ej typów mog

ą

by

ć

wyspecjalizowane do

testowania specjalnego rodzaju oprogramowania. Na przykład istniej

ą

specjalne narz

ę

dzia

do testów wydajno

ś

ci aplikacji internetowych, narz

ę

dzia do analizy statycznej dedykowane

poszczególnym platformom programistycznym lub narz

ę

dzia do analizy dynamicznej

wykonywanej przede wszystkim pod k

ą

tem zabezpiecze

ń

systemu.

Dost

ę

pne komercyjne zestawy narz

ę

dzi testowych bywaj

ą

przeznaczone dla specjalnych

zastosowa

ń

, na przykład dla systemów wbudowanych.

background image

Certyfikowany tester

Plan poziomu podstawowego

International Sotware Testing Qualifications Board

Stowarzyszenie Jako

ś

ci Systemów Informatycznych

Wersja 1.0

© Stowarzyszenie Jako

ś

ci Systemów

Informatycznych

Strona 64 z 78

20 pa

ź

dziernika 2006

6.1.8.

Wykorzystanie innych narz

ę

dzi (K1)

Wyliczone wcze

ś

niej rodzaje narz

ę

dzi testowych nie s

ą

jedynymi stosowanymi przez

testerów. Wykorzystywane s

ą

równie

ż

np. arkusze kalkulacyjne, narz

ę

dzia SQL, debagery i

narz

ę

dzia do zarz

ą

dzania zasobami.

background image

Certyfikowany tester

Plan poziomu podstawowego

International Sotware Testing Qualifications Board

Stowarzyszenie Jako

ś

ci Systemów Informatycznych

Wersja 1.0

© Stowarzyszenie Jako

ś

ci Systemów

Informatycznych

Strona 65 z 78

20 pa

ź

dziernika 2006

6.2. Skuteczne zastosowanie narz

ę

dzi: mo

ż

liwe korzy

ś

ci i

zagro

ż

enia (K2), 20 minut

Terminologia

Testowanie w oparciu o dane, testowanie oparte na słowach kluczowych, j

ę

zyk skryptowy.

6.2.1.

Mo

ż

liwe korzy

ś

ci i zagro

ż

enia wynikaj

ą

ce ze stosowania

narz

ę

dzi wspieraj

ą

cych testowanie (dla wszystkich rodzajów narz

ę

dzi)

(K2)

Samo tylko zakupienie czy wypo

ż

yczenie narz

ę

dzia nie gwarantuje sukcesu. Ka

ż

dy typ

narz

ę

dzi wymaga zwykle dodatkowego wysiłku, aby osi

ą

gn

ąć

rzeczywiste i trwałe korzy

ś

ci z

jego zastosowania. Istniej

ą

zarówno potencjalne korzy

ś

ci, jak i ryzyko zwi

ą

zane z

posługiwaniem si

ę

narz

ę

dziami do testowania.

Mo

ż

liwe korzy

ś

ci z wykorzystania narz

ę

dzi:

Ograniczenie wielokrotnego wykonywania tej samej pracy (na przykład
wykonywania testów regresywnych, wielokrotnego wprowadzania tych samych
danych testowych, lub kontroli zgodno

ś

ci ze standardami programowania).

Wi

ę

ksza jednolito

ść

i powtarzalno

ść

(na przykład testy wykonywane przy pomocy

narz

ę

dzia lub przypadki testowe uzyskane z wymaga

ń

).

Obiektywna ocena (na przykład miary statyczne, pokrycie i zachowanie systemu).

Łatwy dost

ę

p do danych o testach lub testowaniu (na przykład statystyki i grafy

obrazuj

ą

ce post

ę

p testowania, liczba zdarze

ń

lub wydajno

ść

).

Zagro

ż

enia wi

ążą

ce si

ę

z zastosowaniem narz

ę

dzi:

Nierealistyczne oczekiwania wobec narz

ę

dzia (zarówno jego funkcjonalno

ś

ci, jak i

łatwo

ś

ci posługiwania si

ę

narz

ę

dziem).

Zani

ż

one oszacowanie czasu, kosztu oraz wysiłku pierwszego wdro

ż

enia

narz

ę

dzia (w tym kosztów szkole

ń

oraz zewn

ę

trznego wsparcia i doradztwa).

Zani

ż

one oszacowanie czasu i wysiłku niezb

ę

dnego, aby uzyska

ć

znacz

ą

ce i

stałe korzy

ś

ci z zastosowania narz

ę

dzia (w tym konieczno

ś

ci zmian w procesie

testowania oraz zapewnienia stałego doskonalenia sposobu wykorzystywania
narz

ę

dzia).

Zani

ż

one oszacowanie wysiłku zwi

ą

zanego z utrzymaniem testaliów

wygenerowanych przez narz

ę

dzie.

Zbytnie uzale

ż

nienie od narz

ę

dzia (np. automatyczne wykonywanie testów

zamiast projektowania testów lub testy automatyczne tam, gdzie r

ę

czne s

ą

skuteczniejsze).

6.2.2.

Zagadnienia specjalne dla niektórych rodzajów narz

ę

dzi (K1)

Narz

ę

dzia wspieraj

ą

ce wykonanie testów

Narz

ę

dzia wspieraj

ą

ce wykonanie testów s

ą

sterowane przechowywanymi w formie

elektronicznej skryptami, zaprojektowanymi tak, aby implementowa

ć

wykonanie testów.

background image

Certyfikowany tester

Plan poziomu podstawowego

International Sotware Testing Qualifications Board

Stowarzyszenie Jako

ś

ci Systemów Informatycznych

Wersja 1.0

© Stowarzyszenie Jako

ś

ci Systemów

Informatycznych

Strona 66 z 78

20 pa

ź

dziernika 2006

Osi

ą

gni

ę

cie znacz

ą

cych korzy

ś

ci przy wykorzystaniu tego typu narz

ę

dzi zwykle wymaga

znacz

ą

cych nakładów.

Rejestrowanie skryptów testowych poprzez nagrywanie czynno

ś

ci wykonywanych podczas

r

ę

cznego testowania mo

ż

e si

ę

wydawa

ć

korzystne, ale ta metoda nie nadaje si

ę

do

stosowania przy du

ż

ej liczbie zautomatyzowanych testów. Zarejestrowany skrypt jest

liniowym odwzorowaniem, wykonanych podczas testu manualnego, czynno

ś

ci, stanowi

ą

cych

– wraz z danymi – elementy ka

ż

dego skryptu. Ten rodzaj skryptu mo

ż

e okaza

ć

si

ę

zawodny

w razie pojawienia si

ę

nieoczekiwanych wydarze

ń

.

Metodyka testowania w oparciu o dane oddziela testowe dane wej

ś

ciowe (dane testowe),

zwykle przechowywane w arkuszu kalkulacyjnym, oraz posługuje si

ę

ogólniejszym skryptem

testowym, odczytuj

ą

cym dane testowe i wykonuj

ą

cym ten sam test z ró

ż

nymi danymi.

Testerzy nieznaj

ą

cy j

ę

zyka skryptowego mog

ą

wówczas projektowa

ć

nowe testy

wprowadzaj

ą

c dane testowe wykorzystywane przez z góry zdefiniowane skrypty.

W metodyce testowania w oparciu o słowa kluczowe umieszcza si

ę

w arkuszu kalkulacyjnym

zarówno słowa klucze okre

ś

laj

ą

ce, jak

ą

czynno

ść

nale

ż

y wykona

ć

(nazywane te

ż

słowami

czynno

ś

ciowymi), jak i dane testowe. Testerzy, nawet nieznaj

ą

cy j

ę

zyka skryptowego, mog

ą

projektowa

ć

testy posługuj

ą

c si

ę

słowami kluczami, które powinny by

ć

dostosowane do

rodzaju testowanej aplikacji.

Ka

ż

da z metodyk wymaga dobrej znajomo

ś

ci j

ę

zyka skryptowego, albo przez testerów, albo

przez specjalistów od automatyzacji.

Niezale

ż

nie od stosowanej metodyki, niezb

ę

dne jest gromadzenie i przechowywanie

wyników oczekiwanych testów, w celu ich wykorzystania do porównania z przyszłymi
wynikami rzeczywistymi.

Narz

ę

dzia do testów wydajno

ś

ci

Zastosowanie narz

ę

dzi do testów wydajno

ś

ci wymaga wsparcia ze strony eksperta w

dziedzinie testów wydajno

ś

ciowych przy projektowaniu testów oraz interpretacji ich wyników.

Narz

ę

dzia do analizy statycznej

Narz

ę

dzia do analizy statycznej zastosowane do kodu

ź

ródłowego umo

ż

liwiaj

ą

narzucanie

standardów kodowania, ale generuj

ą

bardzo wiele komunikatów, gdy u

ż

ywa si

ę

ich do ju

ż

istniej

ą

cego kodu. Komunikaty ostrze

ż

e

ń

nie blokuj

ą

przetłumaczenia kodu

ź

ródłowego na

wykonywalny, ale powinno si

ę

ich unika

ć

, aby ułatwi

ć

przyszłe utrzymanie kodu. Skuteczne

podej

ś

cie polega na stopniowym wdro

ż

eniu z zastosowaniem wst

ę

pnych filtrów, które

blokuj

ą

niektóre zb

ę

dne komunikaty.

Narz

ę

dzia do zarz

ą

dzania testami

Chc

ą

c selekcjonowa

ć

i przedstawia

ć

informacj

ę

w formacie jak najlepiej pasuj

ą

cym do

bie

żą

cych potrzeb organizacji, narz

ę

dzia do zarz

ą

dzania testowaniem musz

ą

porozumiewa

ć

si

ę

z innymi narz

ę

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

ą

by

ć

odpowiednio zaprojektowane oraz monitorowane i analizowane.

background image

Certyfikowany tester

Plan poziomu podstawowego

International Sotware Testing Qualifications Board

Stowarzyszenie Jako

ś

ci Systemów Informatycznych

Wersja 1.0

© Stowarzyszenie Jako

ś

ci Systemów

Informatycznych

Strona 67 z 78

20 pa

ź

dziernika 2006

6.3. Wdro

ż

enie narz

ę

dzia w organizacji (K1), 15 minut

Terminologia

Brak szczególnej terminologii w tym rozdziale.

Wprowadzenie

Główne zasady wdro

ż

enia narz

ę

dzi w organizacji obejmuj

ą

:

Ocen

ę

dojrzało

ś

ci organizacyjnej, silnych i słabych stron procesu, oraz

identyfikacj

ę

mo

ż

liwo

ś

ci udoskonalenia procesu testowego wspomaganego

narz

ę

dziami.

Ocen

ę

wdro

ż

enia wobec jasnych wymaga

ń

przy pomocy obiektywnych kryteriów.

Wst

ę

pn

ą

prób

ę

wdro

ż

enia w celu sprawdzenia wymaganej funkcjonalno

ś

ci i

zgodno

ś

ci narz

ę

dzia z celami.

Ocen

ę

dostawcy narz

ę

dzia (w tym szkole

ń

, wsparcia dla klientów oraz aspektów

ekonomicznych).

Oszacowanie wewn

ę

trznych potrzeb w zakresie doradztwa indywidualnego oraz

wsparcia w posługiwaniu si

ę

narz

ę

dziem.

Wst

ę

pn

ą

prób

ę

wdro

ż

enia najlepiej przeprowadzi

ć

w formie niewielkiego projektu

pilota

ż

owego, co pozwoli na zminimalizowanie kosztów poniesionych w razie natkni

ę

cia si

ę

na znaczne trudno

ś

ci i niepowodzenia projektu pilota

ż

owego.

Cele projektu pilota

ż

owego:

Szczegółowe zapoznanie si

ę

z narz

ę

dziem.

Sprawdzenie, jak posługiwanie si

ę

narz

ę

dziem pasuje do istniej

ą

cych procesów i

praktyk, oraz identyfikacja ewentualnie potrzebnych zmian.

Okre

ś

lenie procedur posługiwania si

ę

, utrzymywania, przechowywania narz

ę

dzia i

zwi

ą

zanych z nim testaliów (np. okre

ś

lenie zasad nazywania plików i testów,

tworzenia bibliotek oraz okre

ś

lania szczegółowo

ś

ci scenariuszy testowych).

Oszacowanie, na ile korzy

ś

ci z zastosowania narz

ę

dzia dadz

ą

si

ę

osi

ą

gn

ąć

przy

opłacalnych nakładach.

Czynniki, od których zale

ż

y powodzenie wdro

ż

enia narz

ę

dzia w organizacji:

Stopniowe (przyrostowe) wdro

ż

enie narz

ę

dzia w pozostałej cz

ęś

ci organizacji, nie

obj

ę

tej projektem pilota

ż

owym.

Dostosowanie i udoskonalenie procesów tak, aby współdziałały z u

ż

yciem

narz

ę

dzia.

Udost

ę

pnienie szkole

ń

oraz doradztwa dla nowych u

ż

ytkowników.

Okre

ś

lenie wytycznych dla posługiwania si

ę

narz

ę

dziem.

Wdro

ż

enie metodyki gromadzenia i wykorzystywania do

ś

wiadcze

ń

z posługiwania

si

ę

narz

ę

dziem.

Nadzorowanie i monitorowanie wykorzystania oraz korzy

ś

ci z zastosowania

narz

ę

dzia.

background image

Certyfikowany tester

Plan poziomu podstawowego

International Sotware Testing Qualifications Board

Stowarzyszenie Jako

ś

ci Systemów Informatycznych

Wersja 1.0

© Stowarzyszenie Jako

ś

ci Systemów

Informatycznych

Strona 68 z 78

20 pa

ź

dziernika 2006

Referencje

6.2.2 Buwalda, 2001, Fewster, 1999

6.3 Fewster, 1999

background image

Certyfikowany tester

Plan poziomu podstawowego

International Sotware Testing Qualifications Board

Stowarzyszenie Jako

ś

ci Systemów Informatycznych

Wersja 1.0

© Stowarzyszenie Jako

ś

ci Systemów

Informatycznych

Strona 69 z 78

20 pa

ź

dziernika 2006

7. Referencje

Normy

ISTQB Glossary of terms used in Software Testing Version 1.0

[CMMI] Chrissis, M.B., Konrad, M. and Shrum, S. (2004) CMMI, Guidelines for Process
Integration and Product Improvement
, Addison Wesley: Reading, MA; por. rozdz. 2.1

[IEEE 829] IEEE Std 829™ (1998/2005) IEEE Standard for Software Test Documentation
(obecnie w trakcie modyfikacji); por. rozdz. 2.3, 2.4, 4.1, 5.2, 5.3, 5.5, 5.6

[IEEE 1028] IEEE Std 1028™ (1997) IEEE Standard for Software Reviews; zob. rozdz.3.2

[IEEE 12207] IEEE 12207/ISO/IEC 12207-1996, Software life cycle processes; zob rozdz.
2.1

[ISO 9126] ISO/IEC 9126-1:2001, Software Engineering – Software Product Quality; zob.
rozdz. 2.3

Ksi

ąż

ki

[Beizer, 1990] Beizer, B. (1990) Software Testing Techniques (2nd edition), Van Nostrand
Reinhold: Boston zob. rozdz. 1.2, 1.3, 2.3, 4.2, 4.3, 4.4, 4.6

[Black, 2001] Black, R. (2001) Managing the Testing Process (2nd edition), John Wiley &
Sons: New York; zob. rozdz. 1.1, 1.2, 1.4, 1.5, 2.3, 2.4, 5.1, 5.2, 5.3, 5.5, 5.6

[Buwalda, 2001] Buwalda, H. et al. (2001) Integrated Test Design and Automation, Addison
Wesley: Reading, MA; zob. rozdz. 6.2

[Copeland, 2004] Copeland, L. (2004) A Practitioner’s Guide to Software Test Design, Artech
House: Norwood, MA; zob. rozdz. 2.2, 2.3, 4.2, 4.3, 4.4, 4.6

[Craig, 2002] Craig, Rick D. and Jaskiel, Stefan P. (2002) Systematic Software Testing,
Artech House: Norwood, MA; zob. rozdz. 1.4.5, 2.1.3, 2.4, 4.1, 5.2.5, 5.3, 5.4

[Fewster, 1999] Fewster, M. and Graham, D. (1999) Software Test Automation, Addison
Wesley: Reading, MA; zob. rozdz. 6.2, 6.3

[Gilb, 1993]: Gilb, Tom and Graham, Dorothy (1993) Software Inspection, Addison Wesley:
Reading, MA; zob. rozdz. 3.2.2, 3.2.4

[Hetzel, 1988] Hetzel, W. (1988) Complete Guide to Software Testing, QED: Wellesley, MA;
zob. rozdz. 1.3, 1.4, 1.5, 2.1, 2.2, 2.3, 2.4, 4.1, 5.1, 5.3

[Kaner, 2002] Kaner, C., Bach, J. and Pettticord, B. (2002) Lessons Learned in Software
Testing, John Wiley & Sons; zob. rozdz. 1.1, 4.5, 5.2

[Myers 1979] Myers, Glenford J. (1979) The Art of Software Testing, John Wiley & Sons;
zob. rozdz. 1.2, 1.3, 2.2, 4.3

[van Veenendaal, 2004] van Veenendaal, E. (ed.) (2004) The Testing Practitioner (Chapters
6, 8, 10), UTN Publishers: The Netherlands; zob. rozdz. 3.2, 3.3

background image

Certyfikowany tester

Plan poziomu podstawowego

International Sotware Testing Qualifications Board

Stowarzyszenie Jako

ś

ci Systemów Informatycznych

Wersja 1.0

© Stowarzyszenie Jako

ś

ci Systemów

Informatycznych

Strona 70 z 78

20 pa

ź

dziernika 2006

Zał

ą

cznik A – Pochodzenie planu

Historia tego dokumentu

Dokument został przygotowany przez robocz

ą

grup

ę

składaj

ą

c

ą

si

ę

z członków wyłonionych

przez International Software Testing Qualifications Board (ISTQB). Pocz

ą

tkowo był

przegl

ą

dany przez wybrany panel przegl

ą

dowy a potem przez reprezentantów wybranych z

mi

ę

dzynarodowej społeczno

ś

ci zajmuj

ą

cej si

ę

testowaniem oprogramowania. Zasady

zastosowane przy tworzeniu tego dokumentu pokazane s

ą

w Zał

ą

czniku C.

Dokument ten jest planem dla Mi

ę

dzynarodowego Certyfikatu Podstawowego w Testowaniu

Oprogramowania, pierwszego poziomu mi

ę

dzynarodowej kwalifikacji zaaprobowanego przez

ISTQB (www.istqb.org). W czasie pisania tego dokumentu (2005) w skład ISTQB wchodziły
Austria, Dania, Finlandia, Francja, Niemcy, Indie, Izrael, Japonia, Korea, Norwegia, Polska,
Portugalia, Hiszpania, Szwecja, Szwajcaria, Holandia, Wielka Brytania i USA.

Cele Certyfikatu Podstawowego

Poznanie testowania jako podstawowej i profesjonalnej specjalizacji in

ż

ynierii

oprogramowania.
Zapewnienie standardu dla rozwoju kariery testera.
Umo

ż

liwienie rozpoznawania profesjonalnie wykwalifikowanych testerów przez

pracodawców, klientów i kolegów oraz podwy

ż

szenie statusu testerów.

Promowanie konsekwentnych i dobrych praktyk testowania w dyscyplinach in

ż

ynierii

oprogramowania.
Zidentyfikowanie tematów testowania, które s

ą

istotne i warto

ś

ciowe dla przemysłu.

Umo

ż

liwienie dostawcom oprogramowania wynaj

ę

cie certyfikowanych testerów i dzi

ę

ki temu

uzyskanie handlowej przewagi nad ich konkurentami przez zareklamowanie własnej polityki
zatrudnienia testerów.
Zapewnienie testerom i osobom zainteresowanym testowaniem okazji nabycia
rozpoznawanych na arenie mi

ę

dzynarodowej kwalifikacji w tym temacie.

Cele mi

ę

dzynarodowej kwalifikacji (przyj

ę

te na spotkaniu ISTQB w

Sollentuna, listopad 2001)

Umo

ż

liwienie porównania umiej

ę

tno

ś

ci testowania w ró

ż

nych krajach.

Umo

ż

liwienie testerom łatwiejszego przekraczania granic krajów.

Umo

ż

liwienie wielonarodowym/mi

ę

dzynarodowym projektom wspólnego zrozumienia

zagadnie

ń

z zakresu testowania.

Zwi

ę

kszenie liczby wykwalifikowanych testerów na

ś

wiecie.

Posiadanie wi

ę

kszego wpływu/warto

ś

ci jako inicjatywa umocowana mi

ę

dzynarodowo ni

ż

specyficzne podej

ś

cie z jednego kraju.

Rozwini

ę

cie wspólnej mi

ę

dzynarodowej grupy zrozumienia i wiedzy o testowaniu dzi

ę

ki

planowi i terminologii oraz wzrost poziomu wiedzy na temat testowania u wszystkich
uczestników.
Promowanie testowania jako zawodu w wielu krajach.
Umo

ż

liwienie testerom uzyskania rozpoznawanych kwalifikacji w ich ojczystych j

ę

zykach.

Umo

ż

liwienie dzielenia si

ę

wiedz

ą

i zasobami pomi

ę

dzy krajami.

Zapewnienie mi

ę

dzynarodowego poznania testerów i kwalifikacji z powodu uczestnictwa z

wielu krajów.

background image

Certyfikowany tester

Plan poziomu podstawowego

International Sotware Testing Qualifications Board

Stowarzyszenie Jako

ś

ci Systemów Informatycznych

Wersja 1.0

© Stowarzyszenie Jako

ś

ci Systemów

Informatycznych

Strona 71 z 78

20 pa

ź

dziernika 2006

Wymagania wobec kandydatów

Podstawowym wymaganiem wobec kandydatów na Certyfikat ISTQB z Testowania
Oprogramowania jest zainteresowanie testowaniem oprogramowania. Ponadto obowi

ą

zuj

ą

nast

ę

puj

ą

ce zalecenia:

Kandydaci powinni mie

ć

co najmniej sze

ś

ciomiesi

ę

czne do

ś

wiadczenie w

wytwarzaniu oprogramowania albo w testach akceptacyjnych lub systemowych.

Kandydaci powinni wzi

ąć

udział w kursie ISTQB (akredytowanym przez narodow

ą

organizacj

ę

uznan

ą

przez ISTQB).

Okoliczno

ś

ci powstania i historia Podstawowego Certyfikatu w

Testowaniu Oprogramowania

Niezale

ż

na certyfikacja testerów oprogramowania rozpocz

ę

ła si

ę

w Wielkiej Brytanii wraz z

powstaniem w 1998 Software Testing Board (

www.bcs.org.uk/iseb

) pod auspicjami ISEB (the

British Computer Society’s Information Systems Examination Board). W 2002 roku,
niemiecka ASQF stworzyła niemiecki system kwalifikacji testerów (

www.asqf.de

). Niniejszy

plan sporz

ą

dzono na podstawie planów ISEB i ASQF. Jego tre

ść

jest cz

ęś

ciowo nowa,

cz

ęś

ciowo zreorganizowana i zmieniona, za

ś

nacisk poło

ż

ony jest na zapewnienie testerom

maksymalnie praktycznego wsparcia.

Istniej

ą

ce Certyfikaty Podstawowe Testowania Oprogramowania (np. z ISEB, ASQF lub

narodowej organizacji ISTQB), przyznane przed powstaniem certyfikatu mi

ę

dzynarodowego,

b

ę

d

ą

uznawane za równowa

ż

ne certyfikatowi mi

ę

dzynarodowemu. Certyfikat Podstawowy

nie wygasa i nie potrzebuje by

ć

odnawiany. Data przyznania znajduje si

ę

na Certyfikacie.

Narodowe organizacje ISTQB nadzoruj

ą

miejscowe zagadnienia w swoich krajach.

Obowi

ą

zki narodowych organizacji okre

ś

la ISTQB, lecz ich realizacja pozostawiona jest

samym organizacjom. Do obowi

ą

zków organizacji krajowych nale

ż

y akredytacja dostawców

szkole

ń

i wyznaczenie egzaminów.

background image

Certyfikowany tester

Plan poziomu podstawowego

International Sotware Testing Qualifications Board

Stowarzyszenie Jako

ś

ci Systemów Informatycznych

Wersja 1.0

© Stowarzyszenie Jako

ś

ci Systemów

Informatycznych

Strona 72 z 78

20 pa

ź

dziernika 2006

Zał

ą

cznik B – Cel nauki i poziomy wiedzy

Niniejszy plan okre

ś

la opisane poni

ż

ej cele nauczania. Ka

ż

dy z tematów planu uwzgl

ę

dniony

jest w trakcie egzaminu zgodnie z okre

ś

lonym dla niego celem.

Poziom 1: Zapami

ę

ta

ć

(K1)

Kandydat rozpoznaje, pami

ę

ta i umie okre

ś

li

ć

termin lub poj

ę

cie.

Przykład

Rozpoznanie definicji „awarii”: jako:

„brak funkcjonalno

ś

ci u

ż

ytkownika ko

ń

cowego lub innego interesariusza” lub jako

„niezgodno

ść

rzeczywistego działania modułu lub systemu z działaniem lub wynikiem

oczekiwanym”.

Poziom 2: Zrozumie

ć

(K2)

Kandydat potrafi uzasadni

ć

lub wyja

ś

ni

ć

zagadnienia z zakresu tematu oraz podsumowa

ć

,

porówna

ć

, klasyfikowa

ć

i podawa

ć

przykłady dla ró

ż

nych poj

ęć

z zakresu testowania.

Przykłady

Uzasadni

ć

, dlaczego testy powinny by

ć

projektowane jak najwcze

ś

niej:

W celu znalezienia bł

ę

dów wówczas, gdy ich usuni

ę

cie jest mniej kosztowne.

Aby najwa

ż

niejsze bł

ę

dy znale

źć

wcze

ś

niej.

Wyja

ś

ni

ć

podobie

ń

stwa i ró

ż

nice pomi

ę

dzy testowaniem integracyjnym i systemowym:

Podobie

ń

stwa: testowanie wi

ę

cej ni

ż

jednego modułu oraz mo

ż

liwo

ść

testowania

wła

ś

ciwo

ś

ci.

ż

nice: testowanie integracyjne skupia si

ę

na interfejsach oraz na interakcji mi

ę

dzy

modułami, za

ś

testowanie systemowe skupia si

ę

na aspektach ogólnosystemowych,

takich jak przetwarzanie obejmuj

ą

ce cało

ś

ciow

ą

funkcjonalno

ść

.

Poziom 3: Zastosowanie (K3)

Kandydat potrafi wybra

ć

prawidłowe zastosowanie poj

ę

cia lub techniki i zastosowa

ć

je do

danego kontekstu.

Przykład

Mo

ż

e zidentyfikowa

ć

warto

ś

ci graniczne dla dozwolonych i niedozwolonych klas

równowa

ż

no

ś

ci.

Mo

ż

e wybra

ć

przypadki testowe z podanego diagramu przej

ść

stanów, aby pokry

ć

wszystkie przej

ś

cia.

Referencje

(Dla poznawczych poziomów celów nauki)

Anderson, L.W. i Krathwohl, D. R.(eds) (2001) A Taxonomy for Learning, Teaching, and
Accessing: A Revision of Bloom’s Taxonomy of Educational Objectives, Allyn& Bacon:

background image

Certyfikowany tester

Plan poziomu podstawowego

International Sotware Testing Qualifications Board

Stowarzyszenie Jako

ś

ci Systemów Informatycznych

Wersja 1.0

© Stowarzyszenie Jako

ś

ci Systemów

Informatycznych

Strona 73 z 78

20 pa

ź

dziernika 2006

Zał

ą

cznik C – Zasady dotycz

ą

ce Planu poziomu

podstawowego ISTQB / SJSI

Zasady podane tutaj zostały u

ż

yte w projekcie i przegl

ą

dzie tego planu. (Po ka

ż

dej zasadzie

pokazany jest du

ż

ymi literami stenograficzny skrót zasady)

Ogólne zasady

SG1. Plan powinien by

ć

zrozumiały i przyswajalny przez osoby z do

ś

wiadczeniem w

testowaniu od 0 do 6 miesi

ę

cy (lub wi

ę

cej). (6 MIESI

Ę

CY)

SG2. Plan powinien by

ć

raczej praktyczny ni

ż

teoretyczny. (PRAKTYCZNY)

SG3. Plan powinien by

ć

jasny i niedwuznaczny dla jego czytelników. (JASNY)

SG4. Plan powinien by

ć

zrozumiały dla ludzi z ró

ż

nych krajów i da

ć

si

ę

łatwo przetłumaczy

ć

na ró

ż

ne j

ę

zyki. (PRZETŁUMACZALNY)

SG5. Plan powinien u

ż

ywa

ć

Ameryka

ń

skiego Angielskiego. (AMERYKA

Ń

SKI ANGIELSKI)

Bie

żą

ca tre

ść

SC1.Plan powinien obejmowa

ć

ostatnie koncepcje dotycz

ą

ce testowania i powinien

odzwierciedla

ć

najlepsz

ą

bie

żą

c

ą

praktyk

ę

w testowaniu oprogramowania tam, gdzie to

generalnie uzgodniono. Plan podlega przegl

ą

dowi co trzy do pi

ę

ciu lat. (OSTATNI)

SC2.Plan powinien pomniejsza

ć

wpływy zale

ż

ne od czasu, takie jak bie

żą

ce uwarunkowania

rynkowe, aby mie

ć

czas

ż

ycia od trzech do pi

ę

ciu lat. (AKTUALNY)

Cele nauki

LO1. Cele nauki powinny ró

ż

ni

ć

si

ę

pomi

ę

dzy pozycjami do rozpoznania/zapami

ę

tania

(poznawczy poziom K1), pozycjami, które kandydat powinien zrozumie

ć

koncepcyjnie (K2) i

tymi, które kandydat powinien potrafi

ć

zastosowa

ć

w praktyce (K3) (POZIOM WIEDZY)

LO2. Opis tre

ś

ci powinien by

ć

spójny z celami nauki. (SPÓJNY Z CELAMI NAUKI)

LO3. Aby zilustrowa

ć

cele nauki, pytania próbnego egzaminu dla ka

ż

dej wi

ę

kszej sekcji

powinny wynika

ć

z planu. (CELE NAUKI-EGZAMIN)

Ogólna struktura

ST1. Struktura planu powinna by

ć

jasna i pozwoli

ć

na odsyłanie do i z innych cz

ęś

ci, z pyta

ń

egzaminacyjnych i z innych istotnych dokumentów. (ODSYŁANIE)

ST2.Pokrywanie si

ę

pomi

ę

dzy sekcjami planu powinno by

ć

zminimalizowane.

(POKRYWANIE SI

Ę

)

ST3. Ka

ż

da sekcja planu powinna mie

ć

t

ą

sam

ą

struktur

ę

. (SPÓJNA STRUKTURA)

ST4.Plan powinien zawiera

ć

wersj

ę

, dat

ę

wydania i numer strony na ka

ż

dej stronie.

(WERSJA)

ST5. Plan powinien zawiera

ć

wskazówk

ę

odno

ś

nie potrzebnej ilo

ś

ci czasu dla ka

ż

dego

rozdziału (aby odzwierciedli

ć

wzgl

ę

dn

ą

wag

ę

ka

ż

dego tematu). (POTRZEBNY CZAS)

Referencje

SR1.

Ź

ródła i referencje zostan

ą

podane dla koncepcji w konspekcie, aby pomóc dostawcom

szkole

ń

znale

źć

wi

ę

cej informacji na wybrany temat. (REFERENCJE)

background image

Certyfikowany tester

Plan poziomu podstawowego

International Sotware Testing Qualifications Board

Stowarzyszenie Jako

ś

ci Systemów Informatycznych

Wersja 1.0

© Stowarzyszenie Jako

ś

ci Systemów

Informatycznych

Strona 74 z 78

20 pa

ź

dziernika 2006

SR2. Tam, gdzie nie ma zidentyfikowanych i jasnych

ź

ródeł powinno si

ę

dostarczy

ć

wi

ę

cej

szczegółów w konspekcie. Na przykład, definicje s

ą

w słowniku, a wi

ę

c w konspekcie

przytoczono jedynie terminologie. (SZCZEGÓŁY BEZ REFERENCJI)

Ź

ródła informacji

Terminologia u

ż

yta w konspekcie, dla poj

ęć

u

ż

ywanych w testowaniu oprogramowania,

zdefiniowana jest w Słowniku ISTQB. Wersja słownika jest dost

ę

pna na stronie ISTQB lub

SJSI.

Lista zalecanych ksi

ąż

ek na temat testowania oprogramowania podana jest w konspekcie.

Główna lista ksi

ąż

ek jest cz

ęś

ci

ą

sekcji Referencje.

background image

Certyfikowany tester

Plan poziomu podstawowego

International Sotware Testing Qualifications Board

Stowarzyszenie Jako

ś

ci Systemów Informatycznych

Wersja 1.0

© Stowarzyszenie Jako

ś

ci Systemów

Informatycznych

Strona 75 z 78

20 pa

ź

dziernika 2006

Zał

ą

cznik D – Informacja dla dostawców szkole

ń

Dla ka

ż

dego z głównych tematów planu przeznaczony jest okre

ś

lony w minutach czas jego

trwania. Celem tego jest zarówno wyznaczenie wzgl

ę

dnych proporcji poszczególnych sekcji

tematycznych akredytowanego szkolenia wzgl

ę

dem siebie, jak i wyznaczenie przybli

ż

onego

minimalnego czasu, który nale

ż

y przeznaczy

ć

na nauczanie poszczególnych tematów.

Dostawcy szkole

ń

mog

ą

po

ś

wi

ę

ci

ć

im wi

ę

cej czasu, za

ś

kandydaci mog

ą

sp

ę

dzi

ć

dodatkowy

czas na lekturze i własnych badaniach. Kolejno

ść

omawiania zagadnie

ń

podczas kursu nie

musi by

ć

taka sama jak w konspekcie.

Plan zawiera odwołania do uznanych norm, z których nale

ż

y skorzysta

ć

podczas

przygotowywania materiałów szkoleniowych. Zalecane jest korzystanie z tej wersji normy, do
której odwołuje si

ę

bie

żą

ca wersja planu. Mo

ż

na odwoływa

ć

si

ę

lub wykorzystywa

ć

tak

ż

e

inne publikacje, wzorce lub normy poza okre

ś

lonymi w konspekcie, ale nie b

ę

d

ą

one

przedmiotem egzaminu.

Nast

ę

puj

ą

ce obszary tematyczne planu wymagaj

ą

ć

wicze

ń

praktycznych:

4.3 Techniki na podstawie specyfikacji lub czarnoskrzynkowe

Praktyczne, krótkie

ć

wiczenia powinny dotyczy

ć

czterech technik: podziału na klasy

równowa

ż

no

ś

ci, analizy warunków brzegowych, testowania tabeli decyzyjnej oraz testowanie

przej

ść

stanów. Wykład oraz

ć

wiczenia dotycz

ą

ce tych technik powinny by

ć

zrobione na

podstawie referencji podanych dla ka

ż

dej z nich.

4.4 Techniki na podstawie struktury lub białoskrzynkowe

Praktyczne, krótkie

ć

wiczenia powinny dotyczy

ć

sprawdzenia, czy dany zestaw przypadków

testowych pozwala na 100% pokrycia instrukcji lub 100% pokrycia decyzji, a tak

ż

e

projektowania przypadków testowych dla okre

ś

lonych przepływów sterowania.

5.6 Zarz

ą

dzanie incydentami

Nale

ż

y zastosowa

ć

krótkie

ć

wiczenie, polegaj

ą

ce albo na napisaniu, albo ocenie pisemnego

zgłoszenia incydentu.

background image

Certyfikowany tester

Plan poziomu podstawowego

International Sotware Testing Qualifications Board

Stowarzyszenie Jako

ś

ci Systemów Informatycznych

Wersja 1.0

© Stowarzyszenie Jako

ś

ci Systemów

Informatycznych

Strona 76 z 78

20 pa

ź

dziernika 2006

Indeks

A

analiza statyczna, 29, 30, 34
analiza wartości brzegowych, 35, 39
analiza wpływu, 28
automatyzacja, 26, 47
automatyzacja testów, 47
awaria, 10, 11

B

błąd, 10, 11, 16

C

cecha, 37
cele testowania, 15, 16, 20
cykl życia, 21, 43
czas odpowiedzi, 27
częstotliwość awarii, 51
czynności poza testowaniem, 55
czynności testowe, 14
czynność testowa, 21

D

dane testowe, 15, 37, 62, 66
dane wejściowe, 62, 66
debager, 59
debagowanie, 13, 27
decyzja, 12
defekt, 10, 11, 13, 31, 34
diagram przejść pomiędzy stanami, 40
dokumentacja testowa, 53
domyślanie się błędów, 49
działanie, 11, 40, 48, 63

E

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

F

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

H

harmonogram, 37
harmonogram wykonania testu, 37

I

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

iteracyjny, 23

J

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

K

kierownik jakości, 46
kierownik testów, 18, 46
kod, 11, 12, 13, 18, 21, 23, 30, 34, 41, 61, 66
kod źródłowy, 21
kompilator, 34
koszty testowania, 51
kryteria wejścia, 48
kryteria wejściowe, 31

L

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

Ł

łatwość testowania, 48

M

menedżer testów, 46
metodyka testowa, 48, 51, 55, 66
metodyka testowania, 55, 66
miara, 27
migracja, 20, 28
model automatu skończonego (przejść stanów), 26
model przepływu procesu, 26
model wytwarzania, 21
moduł, 24, 62
modyfikacja, 20
monitorowanie postępu testów, 51
monitorowanie testowania, 51

N

nadzorowanie procesu testowego, 44
nadzór nad testowaniem, 15, 51
najistotniejsze, 55
narzędzia do analizy dynamicznej, 63
narzędzia do analizy statycznej, 34, 61, 63, 66
narzędzia do zarządzania testami, 59, 66
narzędzia wspierające projektowanie testów, 61
narzędzia wspierające testowanie, 63
narzędzie, 34, 59, 65
narzędzie do analizy statycznej, 59
narzędzie do pomiaru pokrycia, 59
narzędzie do testów wydajności, 59
narzędzie do testów wydajnościowych, 59
narzędzie do testów zabezpieczeń, 59
narzędzie do zarządzania konfiguracją, 59

background image

Certyfikowany tester

Plan poziomu podstawowego

International Sotware Testing Qualifications Board

Stowarzyszenie Jako

ś

ci Systemów Informatycznych

Wersja 1.0

© Stowarzyszenie Jako

ś

ci Systemów

Informatycznych

Strona 77 z 78

20 pa

ź

dziernika 2006

narzędzie do zarządzania wymaganiami, 59
narzędzie wspierające wykonanie testu, 59
niezależność testowania, 46
niezależny tester, 46
niezależny zespół testowy, 18, 24
niezawodność, 11, 13, 26, 54, 59

O

ocena, 13, 15, 16, 49, 51, 65
oczekiwany wynik, 35
oparte na słowach kluczowych, 65
operacyjne testy akceptacyjne, 23, 25
oprogramowanie, 11, 17, 18, 21, 25, 27, 38, 40, 42, 46,

54, 55

oprogramowanie wbudowane, 40
oprogramowanie z półki, 21, 25
organizacja wytwarzająca oprogramowanie, 24
osoba wykonująca przegląd, 56
oszacowanie, 44, 47, 49, 65, 67

P

plan testów, 15, 48
planowanie integracji, 24
planowanie ryzyka, 44
planowanie testowania, 47, 48
planowanie testów, 15, 24, 53
pluskwa, 10, 11
podejście, 21, 24, 27, 35, 37, 42, 66, 70
podejście białoskrzynkowe, 35
podejście czarnoskrzynkowe, 35
podejście strukturalne, 27
podstawa testów, 13, 15, 23
pokrycie, 15, 26, 27, 35, 39, 41, 48, 51, 60, 65
pokrycie danych wejściowych, 39
pokrycie decyzji, 41
pokrycie instrukcji kodu, 41
pokrycie kodu, 26, 41, 48
pokrycie testowe, 15, 27, 51
pokrycie wymagań, 51
polityka testów, 48
pomyłka, 10, 11, 16
ponownie przetestowane, 52
poziom testów, 21
pracochłonność testowania, 49
procedura testowa, 35
proces biznesowy, 41
proces testowania, 13
proces testowy, 10, 15, 29, 30
projekt, 16, 17
projektowanie przypadków testowych, 35, 37
projektowanie testów, 16, 21, 22, 37, 49
prototypowanie, 21
przebieg wykonania testów, 51
przegląd, 13, 29, 30, 31, 32, 33, 47
przegląd formalny, 31
przegląd koleżeński, 31, 32
przegląd nieformalny, 29, 31, 32
przegląd techniczny, 29, 31, 32
przejrzenie, 29, 31, 32
przepływ, 34, 41
przepływ danych, 34
przepływ sterowania, 34, 41
przetestowanie właściwości, 26

przypadek testowy, 13, 35, 37
przypadek użycia, 40

R

raport testowy, 51
raportowanie incydentów, 60
raportowanie testów, 16, 51
Rational Unified Process (RUP), 21
rejestracja danych testowych, 62
rozbudowa i udoskonalanie, 28
rusztowanie testowe, 62
ryzyko, 11, 12, 18, 24, 27, 36, 44, 50, 54, 55, 65
ryzyko produktowe, 54
ryzyko projektowe, 54
ryzyko związane z produktem, 54, 55

S

scenariusz testowy, 26, 27
skrypt testowy, 37
specyfikacja, 26, 28, 37
specyfikacja procedury testowej, 37
sprzęt, 23, 54
staranność testowania, 24, 27
statyczne techniki testowania, 29, 30
sterownik, 59
strategia testowa, 15, 48
strategia testowania, 15
system, 11, 13, 14, 21, 22, 23, 24, 26, 28, 39, 40, 71
system operacyjny, 23
szybkie wytwarzanie oprogramowania, 21

Ś

ś

ledzenie powiązań, 35, 37, 60, 63

ś

rodowisko produkcyjne, 24

ś

rodowisko testowe, 15, 16, 23, 51

T

tablica decyzyjna, 24, 39
techniki projektowania testów, 35, 36, 38
techniki testowania., 55
tester, 1, 18, 32, 46, 56
testować, 12, 18, 24, 37, 55
testowanie, 8, 9, 10, 11, 12, 13, 14, 15, 16, 17, 18, 20, 21,

22, 23, 24, 25, 26, 27, 28, 30, 34, 35, 39, 40, 41, 42, 44,
46, 47, 48, 49, 51, 54, 55, 58, 60, 61, 62, 63, 65, 72, 75

testowanie akceptacyjne, 21, 22, 23, 25
testowanie akceptacyjne przez użytkownika, 23, 25
testowanie alfa, 23, 25
testowanie beta, 23, 25
testowanie białoskrzynkowe, 26, 41
testowanie decyzyjne, 35, 41
testowanie dynamiczne, 30, 34
testowanie eksploracyjne, 42, 48, 49
testowanie funkcji, 26
testowanie funkcjonalne, 24, 26
testowanie gruntowne, 14
testowanie instrukcji, 35, 41
testowanie integracyjne, 21, 22, 23, 72
testowanie integracyjne modułów, 21
testowanie integracyjne systemów, 21

background image

Certyfikowany tester

Plan poziomu podstawowego

International Sotware Testing Qualifications Board

Stowarzyszenie Jako

ś

ci Systemów Informatycznych

Wersja 1.0

© Stowarzyszenie Jako

ś

ci Systemów

Informatycznych

Strona 78 z 78

20 pa

ź

dziernika 2006

testowanie modułowe, 13, 21, 23, 35
testowanie na podstawie ryzyka, 49, 54, 55
testowanie na podstawie struktury, 41
testowanie niefunkcjonalne, 26
testowanie niezależne, 18
testowanie niezawodności, 26
testowanie obciążeniowe, 26
testowanie odporności, 23
testowanie potwierdzające, 13, 15, 16, 26, 27, 60
testowanie przeciążające, 26
testowanie przejść pomiędzy stanami, 39, 40
testowanie regresywne, 15, 16, 26, 27
testowanie statyczne wspierane narzędziami, 61
testowanie stochastyczne, 49
testowanie strukturalne, 23, 26, 27, 41
testowanie systemowe, 21, 23, 24, 72
testowanie użyteczności, 26
testowanie w fazie utrzymania, 20, 28
testowanie w oparciu o przypadki użycia, 39, 40
testowanie w oparciu o specyfikację, 26
testowanie właściwości, 24, 26
testowanie współdziałania, 26
testowanie wydajnościowe, 26
testowanie zabezpieczeń, 26
testowanie związane ze zmianami, 27
testy, 13, 14, 15, 18, 20, 21, 22, 23, 24, 25, 26, 27, 28, 35,

37, 39, 40, 42, 44, 49, 61, 65, 66, 72

testy akceptacji produkcyjnej, 25
testy akceptacyjne zgodności legislacyjnej, 23, 25
testy akceptacyjne zgodności z umową, 23, 25
testy integracji z infrastrukturą, 22
testy integracyjne systemów, 24
testy migracji danych, 28
testy modułowe, 23
testy modułu, 26
testy odbiorcze i wdrożeniowe, 22
testy regresywne, 21, 28, 37
testy w środowisku produkcyjnym, 23, 25
tworzenie specyfikacji testów wspierane narzędziami, 61
typowe metryki, 44
typy testów, 20, 27

U

usterka, 11

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

W

walidacja, 21
warunek testowy, 15, 35, 37
warunki wejściowe, 39
warunki wyjścia, 15, 31
wdrożenie, 15, 55, 58, 67
wejściowe dane testowe, 61
weryfikacja, 13, 16, 21, 23, 25, 26
wstępujące, 24
wycofanie systemu, 20, 28
wydajność, 54, 65
wykonywanie testów, 47, 62, 65
wykonywanie testów wspierane narzędziami, 62
wymaganie, 13
wyniki testów, 48, 51
wysoka wartość miary złożoności, 34
wytwarzanie sterowane testowaniem, 23
wytwarzanie w modelu iteracyjnym, 21

Z

zabezpieczenia, 54
zachowanie systemu, 65
zadania testowe, 46, 47, 48
zagrożenie, 50
zakres testowania, 48
zarządzanie incydentami, 45, 56, 75
zarządzanie konfiguracją, 44, 53
zarządzanie testowaniem, 44, 59
zarządzanie testowaniem wspierane narzędziami, 59
zarządzanie wersjami, 59
zarządzaniu ryzykiem, 55
zdolność do konserwacji, 30
zestawy testów do testów regresywnych, 27
zgadywanie błędów, 18, 42
zgłoszenie, 17, 56
zgłoszenie incydentu, 56
złożoność, 34, 61
zmiana, 52
zmiana wag testów, 52


Wyszukiwarka

Podobne podstrony:
rozporzadzenie z dnia 28.04.2006, Materiały szkoleniowe na uprawnienia budowlane - archiwalne
Zakres materiału obowiązującego na kolokwium
p648 Materiały liturgiczne na Tydzień Misyjny 2014
ZAKRES MATERIAŁU OBOWIAZUJACEGO NA KOLOKWIUM, STOMATOLOGIA, Fizjo Żucia
Zakres materiału obowiązujący na II kolokwium wykładowe, Chemia ogólna i nieorganiczna, giełdy
wywiad pogłębiony z rodzicami, Dodatkowe materiały przydatne na studiach pedagogicznych
projekt festiwalu filmowego, inne materiały przydatne na studia
Łowkis, metody?dań materiałów, zagadnienia na egzamin(1)
techniki wytwarzania i materiałoznawstwo ściąga na sprawdzian
PRAWO WYKROCZEŃ - 4 wykłady, MATERIAŁY PRAWO, NA UCZELNIĘ
Material obowiazujacy na egzaminie -dzialania tworcze, pliki zamawiane, edukacja
Ekonomika Transportu materia+ kursu
Podzia materiau glebowego na frakcje i grupy granulo metryczne, Podział materiału glebowego na frakc
MateriałoznawstwoII, odpowiedzi na zagadnienia, Wykład 7
Wpływ materii org na?ZYNFEKCJĘ
Zakres materiału i zagadnienia na kolokwium 1 z Układów elektronicznych
MateriałoznawstwoII, pytania na egzamin z metali 2, Pytania na egzamin z materiałoznawstwa 2

więcej podobnych podstron