smlouvy: Testování aplikace

Příloha č.

6

smlouvy: Testování aplikace

I.

Dodavatel požaduje, aby bylo zprovozněno prostředí pro testování po celou dobu

trvání

plnění předmětu zakázky ze strany zhotovitele

.

II.

Cílem tohoto dokumentu je navrhnout obecná metodická pravidla a metody pro přípravu a

realizaci procesu testování aplikací, informačních systémů a aplikací dodávaných ve formě služeb. Tento dokument neobsahuje konkrétní testovací případy a scénáře a ani specifikace testovacích dat,

ty jsou předmětem definic v rámci konkrétních realizačních projektů.

III. DŮLEŽITÉ POJMY A ZKRATKY

Zkratka	Význam
DC	Datové centrum zahrnuje prostory, technické a programové vybavení v serverovnách v dané lokalitě.
I CT	Informační a komunikační technologie
I nfrastruktura	Souhrn softwarových i hardwarových komponent a služeb, které slouží k zajištění bezproblémového fungování ICT
KÚSK	Krajský úřad Středočeského kraje
Služba	Činnost informačního systému uspokojující dané požadavky oprávněného subjektu, spojená s funkcí informačního systému

Zkratka	Význam
DC	Datové centrum zahrnuje prostory, technické a programové vybavení v serverovnách v dané lokalitě.
Zhotovitel	Dodavatel testované služby, programového vybavení nebo informačního systému

Tabulka

1

:

Pojmy a zkratky

IV. ZÁKLADNÍ SPECIFIKACE

Předmětem testování je ověření funkčnosti a dalších parametrů předmětu poptávky (aplikace vyvíjené na zakázku, konkrétní nastavení/konfigurace dodávaného HW a SW, vlastností aplikace poskytované jako služba) a jeho jednotlivých částí a to jak samostatně, tak v kontextu celého prostředí ICT

KÚSK

.

Rozsah a typy požadovaných testů, stejně jako podrobné scénáře, musí být uvedeny jako součást projektové dokumentace a schváleny odpovědným pracovníkem

KÚSK

.

V dalším textu je popsána metodika pro jednotlivá stadia testování:

interní testování,

systémové testování,

zátěžové testování,

bezpečnostní testování,

akceptační testování.

Souvislost s rolemi v průběhu projektu zachycuje následující obrázek:

Obrázek

1

:

Procesní schéma testů

V. INTERNÍ TESTOVÁNÍ

Interní testy probíhají zpravidla v prostředí Zhotovitele a to podle jeho platn

é

metodiky. V rámci tohoto stádia testů budou realizovány jednotkové testy, funkční testy a testy výjimek. Výsledky testů jsou protokolovány a slouží k interní potřebě Zhotovitele v průběhu vývoje a implementace IS.

Obrázek

2

: Struktura Interních testů

Zodpovědné role	• •	organizaci zdrojů	Za toto stádium testů jsou zodpovědné role: Vedoucí testování Zhotovitele – zodpovídá za a řízení testů Vedoucí projektu Zhotovitele – zodpovídá za zajištění
•		•
			Návrh architektury testování
	Vstupy	•
			Plán testů

	• Testovací scénáře a testovací případy • Specifikace testovacích dat • Testovací data
• Výstupy	• Revidované testovací scénáře a testovací případy • Revidovaná specifikace testovacích dat • Záznam výsledků testů • Protokol o provedení interních testů

•

Tabulka

2

:

Přehled vstupů a výstupů ze stádia Interní testování

JEDNOTKOVÉ TESTY (UNIT A

Assembly

)

Tyto testy se dělí na dvě části - Unit testy a

Assembly

testy. Cílem Unit testů je ověřit funkčnost jednotlivých nejzákladnějších částí systému.

Assembly

testy se chápou jako ověření vzájemné součinnosti těchto nejzákladnějších částí systému. Vývojové testy proběhnou dříve než je aplikace přenesena do testovacího prostředí pro interní funkční testování. Tento typ testů zpravidla probíhá na vývojovém prostředí a v režii vývojového týmu Zhotovitele.

FUNKČNÍ TESTY

Tento typ testů zastřešuje testování systému podle připravených testovacích případů a scénářů. Cílem je ověřit funkčnost jednotlivých částí systému a systému jako celku podle definovaných požadavků. Tyto testy zpravidla probíhají v režii testovacího týmu Zhotovitele na testovacím prostředí Zhotovitele.

TESTY VÝJIMEK

Tento typ testování simuluje nesprávné chování uživatele, jako např. používání nekorektních dat apod. Tento typ testu má za úkol prověřit systém tak, aby nedošlo ke kolapsu systému, nedošlo ke zpracovávání nekorektních dat, aby docházelo ke korektnímu zápisu příčin problémů do logu. Tyto testy zpravidla probíhají v režii testovacího týmu Zhotovitele na testovacím prostředí Zhotovitele.

VI. SYSTÉMOVÉ TESTOVÁNÍ

Systémové testy zpravidla probíhají v prostředí

KÚSK

a provádí je smíšený tým pracovníků Zhotovitele a odpovědných pracovníků

KÚSK

. Testy provádí Analytik testování Zhotovitele, za účasti Testera pro akceptační testy (

KÚSK

). Za organizaci a plánování a návrh systémových testů jako celku (funkční testy, testy výjimek) zodpovídá Vedoucí testování Zhotovitele. Testy plánuje Vedoucí testování Zhotovitele ve spolupráci s

Koordinátorem testování

KÚSK

. Konkrétní rozložení zodpovědností za přípravu a provedení integračních testů je definováno v rámci dokumentu

Plán testů

, který Zhotovitel předloží

do 30 dnů od

počátk

u

realizace této veřejné zakázky.

Cílem tohoto stádia testování je ověření funkčnosti předávaných subsystémů v jednotném testovacím prostředí, ověření integrace mezi jednotlivými předávanými subsystémy, vytvoření finální testovací dokumentace pro akceptační testy, které schválí

odpovědný pracovník KÚSK

.

Rozsah systémových testů je dán akceptačními kritérii a požadavky, které definuje

KÚSK

. V rámci systémového testování jsou prováděny testy podle testovacích případů a scénářů, které vytvoří testovací tým Zhotovitele a

KÚSK

v návaznosti na akceptační kritéria a požadavky. Akceptační kritéria a požadavky pokrývají celou oblast dodávky Zhotovitele a spolupracujících systémů.

V rámci tohoto stádia testování budou realizovány funkční testy, testy výjimek a integrační

testy.

Obrázek

3

: Struktura Systémových testů

Zodpovědné role •
Vedoucí testování Zhotovitele – zodpovídá za organizaci a řízení testů na straně Zhotovitele (funkční, testy výjimek, integrace z pozice Zhotovitele)
•
Koordinátor testování

		• •	zdrojů	KÚSK – zodpovídá za organizaci a řízení testů na straně KÚSK (integrační testy) Vedoucí projektu Zhotovitele – zodpovídá za zajištění na straně Zhotovitele Vedoucí projektu KÚSK - zodpovídá za zajištění zdrojů na straně KÚSK
•		•
				Plán testů
	Vstupy	•
				Testovací scénáře a testovací případy
		•

	Specifikace testovacích dat • Testovací data • Protokol o provedení interních testů
• Výstupy	• Revidované testovací scénáře a testovací případy • Revidovaná specifikace testovacích dat • Záznam o výsledku testů • Protokol o provedení systémových testů

•

Tabulka

3

: Přehled vstupů a výstupů ze stádia Systémové testování

FUNKČNÍ TESTY

Tento typ testování ověřuje funkčnost systému dle specifikovaných požadavků a bude probíhat na základě schválené testovací dokumentace (testovací případy, testovací scénáře, testovací data), která bude vytvářena před a během stádia interního testování testovacím týmem Zhotovitele ve spolupráci s pracovníky

KÚSK

. Systémové testování bude probíhat v testovacím prostředí

KÚSK

.

TESTY VÝJIMEK

Funkce tohoto typu testování je stejná jako v případě interních testů. Testování výjimek si lze představit jako nesprávné chování uživatele.

VII. INTEGRAČNÍ TESTY‌

Tento typ testů má za úkol ověřit integraci částí systému dodávaného Zhotovitelem s okolními spolupracujícími systémy ICT

KÚSK

, jejichž napojení na budovaný IS (aplikaci, nebo aplikaci poskytovanou jako službu) je předmětem dodávky Zhotovitele. Pro provedení tohoto typu testování je nutná spolupráce pracovníků Zhotovitele a

KÚSK

. Bude-li to vyžadovat situace, je možné metodický proces integračních testů, zahrnující způsob přípravy testovací dokumentace, organizaci a vlastní provedení, nastavit v samostatném dokumentu. Podmínkou pro provedení integračních testů je funkční aplikace a případné další systémy paralelně vyvíjené dalšími účastníky projektu. Všechny dotčené systémy nevykazují závažné (Kritické, Velké) chyby z funkčních systémových testů.

Pro každý systém, se kterým má systém dodávaný Zhotovitelem rozhraní je potřeba samostatně rozhodnout o způsobu provedení integračních testů. V úvahu připadají následující varianty:

reálný cílový systém,

simulátor systému,

protokolární ověření komunikace na daném rozhraní vůči specifikaci rozhraní.

V případě, že nebude v rámci daného projektu využit žádný podpůrný testovací nástroj, budou průběhy testů, prováděných podle testovací dokumentace, zaznamenávány do dokumentů MS Excel a MS Word. Záznamy o neshodě budou evidovány do

excelovských

tabulek, které také poslouží jako podklad pro vyhotovení Protokolu o provedení systémových testů.

Výstupem tohoto stádia testování bude funkční systém včetně ověření vazeb na spolupracující systémy, protokol o provedení systémových testů.

TESTOVACÍ PROSTŘEDÍ PRO SYSTÉMOVÉ TESTY

Odpovědnost za přípravu a údržbu testovacího prostředí pro systémové testy je určena v rámci zadání

veřejné zakázky

. Testovací prostředí, na kterém budou probíhat systémové a integrační testy, bude adekvátní provoznímu prostředí. Do testovacího prostředí bude předána aplikace, která projde funkčními interními testy. Po ukončení funkčních testů všech částí systému bude připraveno prostředí pro integrační testy. Následně budou provedeny integrační testy.

TESTOVACÍ DATA PRO SYSTÉMOVÉ TESTY

Pro systémové funkční i integrační testy bude nutné vytvořit funkční testovací data, která dodá a schválí

KÚSK

. Specifikace požadavků na testovací data bude součástí dokumentu

Plán testů

vytvořeného

jako součást dokumentace

k plnění zakázky

.

TESTŮ

Podmínky pro zahájení systémových funkčních a integračních

Je nutné, aby aplikace předaná do testování prošla interními testy a zjištěné chyby se závažností Kritická nebo Velká byly opraveny a odstraněny. Je dokladováno předáním protokolů z interních testů odpovědnému pracovníkovi

KÚSK

.

Musí být připraveno funkční testovací prostředí

KÚSK

, koordinátor testování

KÚSK

(za

spolupracující systémy) potvrdí připravenost systémů k testům.

Musí být připravena testovací dokumentace (

Plán testů

, schválené testovací scénáře, testovací případy, testovací data).

TESTŮ

Podmínky pro ukončení systémových funkčních a integračních

Je třeba, aby byly definovány a schváleny podmínky pro ukončení systémového testování (podrobná definice musí být součástí dokumentu

Plán testů

a schválena odpovědným pracovníkem

KÚSK)

jako např.:

Během testu byly provedeny všechny testovací případy a testovací scénáře.

Testy byly provedeny ve všech naplánovaných kolech systémových testů.

Testovací dokumentace pro akceptační testy byla schválena odpovědným pracovníkem

KÚSK

.

Aplikace po otestování neobsahuje žádné chyby se závažností Kritická nebo Velká.

Všechny protokoly vzniklé v tomto stádiu byly schváleny

KÚSK

.

Byly dohodnuty termíny oprav zbylých chyb (střední a nízké závažnosti) a verze, do

nichž budou zahrnuty případné změnové požadavky.

PROCES VYHODNOCENÍ A UKONČENÍ SYSTÉMOVÝCH TESTŮ

Systémové testy jsou ukončeny na základě splnění výše uvedených podmínek. Vedoucí testování Zhotovitele vytvoří Protokol o provedení systémových testů.

Vedoucí projektu

KÚSK

má v kompetenci rozhodnout o ukončení systémových testů, i když nebyly splněny výše uvedené podmínky. Zdůvodnění se uvádí do Protokolu o provedení systémových testů.

ZÁTĚŽOVÉ TESTOVÁNÍ

Předpokladem pro toto stádium testování je ukončení funkčních testů a „zamražení“ systému pro zátěžové testování (dále jen

„

ZT

“

). Toto stádium testování má podpořit systémové testování a poukázat na slabá místa systému, která nelze odhalit funkčními a integračními testy.

V rámci tohoto ZT jsou realizovány výkonnostní testy a stress testy.

Zodpovědné role	• •	organizaci zdrojů	a	Vedoucí testování Zhotovitele – zodpovídá za řízení testů na straně Zhotovitele Vedoucí projektu Zhotovitele – zodpovídá za zajištění na straně Zhotovitele
•	•
		Projektová dokumentace
Vstupy	•
		Plán testů

	• Analýza pro zátěžové testování • Testovací data • Testovací scénáře • Protokol o provedení systémových testů
• Výstupy	• Výsledky zátěžového testování • Zpráva o zátěžovém testování

•

Tabulka

4

Přehled vstupů a výstupů ze stádia Zátěžové testování

VÝKONNOSTNÍ TESTY

Tyto testy mají prověřit výkonnost systému při očekávaném zatížení, které by mělo odpovídat běžnému provozu včetně prognózované pracovní špičky. Cílem je zaměřit se na chování systému hlavně v oblasti uživatelské odezvy systému, tj. ověřit výkonové parametry systému v souladu se smlouvou.

STRESS TESTY

Tyto testy mají prověřit stabilitu systému a jeho schopnost zachovat se podle definovaných pravidel při simulaci extrémních situací, jako např.:

schopnost systému zachovat si své funkce i během vygenerované maximální zátěže nad hranicí „bodu zlomu“, tj. v situaci kdy dochází k výkonovému přetížení systému, které není předpokládané při standardním provozu,

schopnost systému zachovat se dle definovaných pravidel při simulovaném výpadku vybraných komponent systému (např.: jeden z aplikačních serverů,

load

balancer

, databáze, síťová komunikace,…).

VYHODNOCENÍ ZT

A NÁSLEDNÝ POSTUP

Po každém běhu ZT vypracuje testovací tým výslednou zprávu o běhu ZT, ve které vyhodnotí provedení běhu ZT, případně navrhne úpravy aplikace, které mají zlepšit výkonnost systému. Po provedení všech naplánovaných běhů uvedených v harmonogramu zpracuje testovací tým výslednou Zprávu o zátěžových testech, kde je shrnut, vyhodnocen celý proces zátěžového testování a navrhnut následný postup.

Výsledná zpráva poskytuje informace o provedených zátěžových testech, o chování systému během ZT díky naměřeným hodnotám a slouží jako podklad pro návrh dalšího postupu při odstraňování nedostatků a slabých míst systému, které nebylo možné objevit funkčním testováním. Následný způsob řešení objevených nedostatků systému nebo optimalizace testovaného systému bude stanoven na základě dohody Zhotovitele s

KÚSK

.

VIII. BEZPEČNOSTNÍ TESTOVÁNÍ‌

Testování bezpečnosti systému je prováděno podle relevantních oblastí metodiky OSSTMM (Open Source

Security

Testing

Methodology

Manual

). Testování je rozděleno do dvou hlavních částí. První část obsahuje otestování zranitelnosti systému z pohledu nepřátelského prostředí. Ve druhé části je provedeno ověření implementace opatření požadovaných

KÚSK

v rámci definice požadavků na dodávaný systém.

Zhotovitele

straně

na

zdrojů

zajištění

Vedoucí projektu Zhotovitele – zodpovídá za

•

Koordinátor testování KÚSK – zodpovídá za organizaci a řízení testů na straně KÚSK (integrační testy)

•

Vedoucí testování Zhotovitele – zodpovídá za organizaci a řízení testů na straně Zhotovitele (funkční, testy výjimek, integrace z pozice Zhotovitele)

•

Zodpovědné role

		•
				Vedoucí projektu KÚSK - zodpovídá za zajištění
			zdrojů	na straně KÚSK
		•
				Specialista na bezpečnostní testy
				za Zhotovitele
				– zodpovídá za provedení testů
•		•
				Návrh architektury testování
	Vstupy	•
				Plán testů
		•
				Testovací scénáře a testovací případy
•	Výstupy	• •		Zpráva o bezpečnostních testech

Záznam výsledků testů

•

Tabulka

5

: Přehled zodpovědných rolí, vstupů a výstupů pro Bezpečnostní testování

OSSTMM

Účelem použití testování bezpečnosti pomocí metodologie OSSTMM je zajištění důkladného otestování relevantních částí systému. Respektováním pravidel metodologie bude zajištěno minimalizování škod na testovaném systému.

Z metodologie OSSTMM jsou vybrány následující oblasti jako relevantní pro účely bezpečnostních testů systému NS SIS:

Internet Technology

Security

Testing (význam slova Internet bude pro testovaný systém představovat celé vnější prostředí z pohledu vlastního testovaného systému (např. Internet, WAN

KÚSK

, XXX XXXX apod.), nikoli pouze Internet, tak jak je standardně chápán)

.

Physical

Security

testing

.

IX. TESTY ZRANITELNOSTI

Cílem těchto testů je odhalení slabin realizovaného systému. Odhalení zranitelností systému bude provedeno zjištěním dostupných služeb, identifikováním zranitelnosti dostupných služeb, kontrolou konfigurace, pokusy o neautorizované přístupy a předkládáním neočekávaných vstupů.

Za součást identifikování slabin systému lze pokládat i testy simulující nesprávné chování uživatele. Tyto testy jsou součástí interní, funkční a akceptační fáze. Bližší informace jsou uvedeny v předchozích

bodech

.

Výsledkem testování bude podrobný přehled nalezených slabin systému a návrh nápravných opatření na odstranění těchto slabin. Testování bude pro vedeno na produkčním i testovacím prostředí, případně na dalších prostředích, budou-li v rámci konkrétního projektu realizována (školicí, zkušební, integrační, ...).

SOULAD S POŽADAVKY

Cílem tohoto testu bude ověření implementace bezpečnostních požadavků. Výsledkem testování bude zdokumentování zjištěných rozporů a souladu s požadavky, včetně návrhu na změny.

Ověření souladu s požadavky bude provedeno na produkčním, záložním i testovacím

prostředí.

PODMÍNKY PRO ZAHÁJENÍ TESTŮ

Pro zahájení bezpečnostních testů je nutné, aby aplikace a systémy v testovaném prostředí byly po dobu bezpečnostních testů „zmrazeny“ a nebyly na nich vykonávány žádné změny

,

nebo jiné než bezpečnostní testování.

Před zahájením testů musí být připraven dokument

Plán testů

včetně testovacích scénářů a testovacích případů.

VYHODNOCENÍ A UKONČENÍ BEZPEČNOSTNÍCH TESTŮ

Ukončení bezpečnostních testů je podmíněno provedením všech naplánovaných testů a odstraněním všech kritických chyb.

Výsledky bezpečnostních testů budou shrnuty v závěrečném dokumentu

Zpráva o bezpečnostních testech

, který vypracuje Zhotovitel (

D

odavatel).

Vlastní průběh testování bude zaznamenán v dokumentu

Záznam výsledků testů

.

DEFINICE ZÁVAŽNOSTI BEZPEČNOSTNÍ CHYBY

Pouze pro účely vyhodnocení bezpečnostních testů byly definice tříd neshody upraveny

následovně:

Kritická (

Critical

)

– systém neprovádí kontrolu, která byla definována v analýze; systém obsahuje chybu, která je zneužitelná vzdáleně; neprovádění kontroly má za následek získání neoprávněného přístupu; existuje snadná možnost obejití kontroly, takže kontrola není provedena

.

Střední (Medium)

– systém kontrolu provádí pouze částečně; kontrola není prováděna vždy, kdy je to požadováno; systém obsahuje chybu, která je zneužitelná lokálně; existuje možnost obejití kontroly, ale pouze při splnění jedné velmi specifické podmínky

.

Malá (

Low

)

– systém kontrolu provádí, nicméně existuje možnost jak kontrolu obejít; obejití kontroly je náročné a vyžaduje splnění několika velmi specifických podmínek

.

X. AKCEPTAČNÍ TESTOVÁNÍ

Cílem akceptačního testování je ověřit správnou a bezchybnou funkčnost aplikace, která odpovídá schválenému zadání. Toto stádium testování slouží jako potvrzení, že předávaný systém odpovídá požadavkům a akceptačním kritériím podle zadání

KÚSK

.

V tomto stádiu testování budou prováděny funkční testy, testy výjimek a integrační testy. V tomto stadiu budou dále provedeny další testy, na kterých se shodnou strany Zhotovitele a

KÚSK

.

Obrázek

4

: Struktura Akceptačních testů

Zodpovědné role •
Koordinátor testování
KÚSK
– zodpovídá za organizaci a řízení testů na straně
KÚSK
•
Vedoucí projektu

	KÚSK – zodpovídá za zajištění zdrojů na straně KÚSK
• Vstupy	• Plán testů • Protokol o provedení systémových testů • Testovací scénáře, testovací případy • Data ze systémových testů
•	• Záznam výsledků testů •

Výstupy
Akceptační protokol za testování

•

Tabulka

6

: Přehled vstupů a výstupů ze stádia Akceptační testování

FUNKČNÍ TESTY

Bude ověřena funkčnost systému dle specifikovaných požadavků a testy budou probíhat na základě schválené testovací dokumentace (testovací případy, testovací scénáře, testovací data). Akceptační testování bude probíhat v testovacím prostředí

KÚSK

.

TESTY VÝJIMEK

Funkce tohoto typu testování je stejná jako v případě interních a systémových testů. Testování výjimek je simulace nesprávného chování uživatele.

INTEGRAČNÍ TESTY

Tento typ testů má za úkol ověřit integraci subsystému dodávaného Zhotovitelem s okolními spolupracujícími systémy. Je nutné, aby bylo rozhodnuto, jaká bude zvolena varianta integračních testů

.

PODMÍNKY PRO AKCEPTAČNÍ TESTY

Akceptační testování je prováděno podle testovací dokumentace (testovací případy a testovací scénáře), která je vytvořena testovacím týmem Zhotovitele během stádia interního a systémového testování. Vytvořená testovací dokumentace je předložena ke schválení Zhotoviteli a

KÚSK

. Na akceptačním testování se podílí pracovníci Zhotovitele a

KÚSK

. Testy provádějí pracovníci

KÚSK

, pracovníci Zhotovitele jsou k dispozici pro konzultace.

TESTOVACÍ PROSTŘEDÍ PRO AKCEPTAČNÍ TESTY

Testovací prostředí pro akceptační testy musí odpovídat konfiguraci pro dané prostředí.

TESTOVACÍ DATA PRO AKCEPTAČNÍ TESTY

Testovací data, která budou použita, musí být připravena v předem definované struktuře a

rozsahu.

VSTUPNÍ PODMÍNKY PRO ZAČÁTEK AKCEPTAČNÍCH TESTŮ

Ukončení interních a systémových testů v požadovaném rozsahu (dokladováno

protokolem),

v případě integračních testů musí být tým informován o připravenosti spolupracujících aplikací a systémů,

Zhotovitel dodá verzi aplikace a specifické dokumenty, které dokladují připravenost k zahájení testování.

PŘEDPOKLADY PRO UKONČENÍ AKCEPTAČNÍCH TESTŮ

V dokumentu

Plán testů

budou definovány podmínky pro ukončení akceptačního testování jako např.:

byly provedeny všechny typy testů požadované ze strany

KÚSK

pro dané stádium testování,

aplikace neobsahuje žádné chyby se závažností Kritická a Velká,

aplikace obsahuje maximálně 10 chyb závažnosti Střední a 20 chyb závažnosti Malá,

je vyplněn Akceptační protokol za testování.

Výše uvedené body jsou pouze jako příklad akceptačních kritérií, definitivní znění akceptačních kritérií musí být stanoveno v dokumentu

Plán testů

, který musí schválit odpovědný pracovník KÚSK a po schválení budou tato kritéria závazná.

V případě, že jsou splněna výše uvedená kritéria a účastníci schůzky se dohodnou na ukončení akceptačních testů, vyplní Koordinátor testování

KÚSK

příslušné části Akceptačního protokolu za testování a přiloží k němu přílohy.

Výsledky o průběhu každého testu budou zaznamenány do dokumentu Záznam výsledků

testů.

XI. DEFINICE ZÁVAŽNOSTI FUNKČNÍCH NESHOD APLIKACE

Při provádění jednotlivých testovacích scénářů dochází k porovnání skutečné reakce systému s reakcí očekávanou podle daného scénáře (v případě pevně definovaných testů) nebo očekávanou subjektivně (v případě volných testů). Pokud se skutečná reakce systému od očekávané reakce liší, je tento fakt označen jako

Neshoda

.

Dalšími možnými důvody nesprávné očekávané reakce nebo nesprávné skutečné reakce systému jsou neshody vyplývající z chyby testovacího scénáře, chyby testovacích dat, chyby v nastavení prostředí, atd.

Klasifikaci neshody provádí a zaznamenává Tester při evidenci neshody. Její klasifikaci schvaluje ve stádiu Interních testů či Systémových testů Vedoucí testování Zhotovitele, ve stádiu Akceptačních testů Koordinátor testování

KÚSK

a Vedoucí projektu

KÚSK

a Zhotovitele. Při neshodné klasifikaci řeší problém Vedoucí projektu Zhotovitele a Vedoucí

projektu

KÚSK

.

Podle charakteru a závažnosti jsou neshody klasifikovány do jednotlivých tříd následujícím způsobem: (

níže uvedené definice jednotlivých tříd neshod aplikace jsou stejné pro všechna stádia testů, tj. pro Interní, Systémové, Akceptační testy. Uvedené definice jsou popsány obecně, konkrétní specifikace musí být uvedena v dokumentu

Plán testů

.)

Změna

–

Detekovaná neshoda není funkční chybou systému, systém reaguje vzhledem k zadání správně, nesprávná je v tomto případě očekávaná reakce. Hlavním důvodem nesprávné očekávané reakce je nepřesná znalost zadání ze strany hodnotitele nebo skutečná změna požadavků na systém oproti zadání např. zjištění chybějící nebo nevhodně navržené funkčnosti. Neshoda této třídy může vyústit v požadavek na změnu.

Chyba

– Neshoda je funkční chybou systému (očekávaná reakce systému je správná a skutečná reakce systému se od ní liší). Podle projevů a dopadů na systém jako celek se tato třída neshod dále dělí podle tzv. Závažnosti na:

Kritická

- Neshoda má významný dopad na realizaci testu - testovací činnosti nemohou pokračovat bez opravy neshody. Neshoda výrazně ovlivňuje několik nebo všechny významné funkce systému, nelze pokračovat v procesech systému bez odstranění neshody.

Velká

- Neshoda má nižší závažnost než „Kritická“ chyba. Neshoda způsobuje zakrytí některé dílčí funkčnosti, která nemůže být prověřena. Neshoda znemožňuje plně využít požadovanou funkčnost systému a má významný dopad na proces podporovaný funkčností systému. Neshoda se vyskytuje v omezeném rozsahu.

Střední

- Neshoda se vyskytuje v kritickém procesu, ale je možné jej obejít využitím jiné funkce systému. Neshoda se může také vyskytovat v nekritickém procesu.

Malá

- Neshoda má zanedbatelný dopad na procesy testovaného systému, většinou způsobuje odchylku požadovaného uživatelského rozhraní (jiný text, diakritika, odlišná informativní hlášení, poloha tlačítek atd.)

.

Chyby procesu testování jsou pouze přechodné (po jejich opravě je znovu proveden příslušný test vč. vyhodnocení a klasifikace výsledku). Odstranění chyb procesu testování probíhá zejména ve stádiu interních a systémových testů.

PRAVIDLA PRO ODSTRAŇOVÁNÍ

NESHOD

Odstraňování neshod se řídí níže uvedenými pravidly (která mohou být upřesněna v

Plánu testů

):

Kritické

chyby

musí být opraveny a přetestovány ve stejném testovacím cyklu.

Velké

a

Střední

chyby

musí být opraveny a ověřeny do konce daného stádia testů.

Malé chyby

musí být odstraněny podle dohody zúčastněných stran testování. Rozhodování o odstranění chyb této závažnosti je v

kompetenci Vedoucího projektu

KÚSK

. Do konce daného stádia testování musí být definován termín pro jejich odstranění.

Změnové

neshody

jsou postoupeny jako vstup do změnového řízení.