Projekt VELRYBA

Analýza

Ke stažení ve formátu PDF.

Návrh akceptačního testu
Analýza rizik
Plán testů
Plán řízení jakosti
Akceptační test

Návrh akceptačního testu

• ANO = test proběhl úspěšně na všech testovacích pracovištích,
• NE = při testu se projevily chyby, které budou specifikovány v samostatném zápisu.

• referent
• lékař
• koordinátor
• klient

Referent

• otevření aplikace.
• přihlášení referentů do systému.
• provedení operací nad databází – vložení dat, oprava dat, ukončení práce s předáním avíza o vložení dat k dalšímu zpracování.
• tisk sestav podle vlastního výběru ukazatelů.
• dostupnost a srozumitelnost elektronické nápovědy pro uživatelskou roli „referent“.
• odhlášení referenta.

Lékař

• otevření aplikace.
• přihlášení lékaře do systému.
• provedení operací nad databází – vyhledání klienta, schválení/zamítnutí přihlášky.
• dostupnost a srozumitelnost elektronické nápovědy pro uživatelskou roli „lékař“.
• odhlášení lékaře.

Koordinátor

• otevření aplikace.
• přihlášení koordinátora do systému.
• rozšíření databáze o další záznamy a sloupce.
• provedení operací nad databází – vyhledání dat, oprava dat, třídění dat podle různých kritérií (indikace k pobytu, věk, požadavky na turnus apod.).
• třídění záznamů v databázi do skupin podle vybraných kritérií (vazba na jiného klienta, požadavek na turnus apod.).
• přidání nové informace k vybranému klientovi.
• přidání shodné informace vybrané skupině klientů.
• export dat do jiných formátů (např. *.csv).
• tisk sestav podle vlastního výběru ukazatelů.
• dostupnost a srozumitelnost elektronické nápovědy pro uživatelskou roli „koordinátor“.
• odhlášení koordinátora.

Klient

• otevření aplikace.
• srozumitelná orientace v aplikaci.
• dostupnost, přehlednost a úplnost elektronické nápovědy.
• dostupnost přihlášky k pobytu.
• elektronické vyplnění přihlášky.
• vytištění přihlášky.
• ukončení práce s aplikací – standardně i nestandardně.

Dokumentace

• předložení dokumentace v elektronické a tištěné verzi.
• úplnost dokumentace.

Analýza rizik

Pro analýzu rizik byla vytvořena déle uvedená tabulka. Každé z rizik bylo zařazeno do odpovídající kategorie, tj. Project risks (Pojektová rizika), Product risks (Technická rizika) nebo Bussines risks (Obchodní rizika). Vyhodnocením v rámci pracovního týmu byla stanovena pravděpodobnost, na základě které byl stanoven dopad na projekt. Na závěr analýzy rizik byla ke každému riziku navržena opatření ke zmírnění či odstranění rizika.
Rizika vyhodnocena hodnotou dopadu 1 a 2 jsou hodnocena jako kritická. Zde je kladen velký důraz na zajištění a dodržení opatření. Rizika vyhodnocena hodnotou 3 a 4 jsou marginální až zanedbatelná. I když nemají výrazný vliv na realizaci projektu, je nutno i těmto rizikům věnovat pozornost.

Obrázek v plné velikosti.

Plán testů

Cílem testů je odhalit případné chyby v produktu a následně je odstranit. Testování bude zahájeno od začátku implementace. Výstupem každého testu bude report, který bude obsahovat minimálně název testu, počet chyb a popis jednotlivých chyb.
Výsledný produkt musí projít všemi testy a lze jej považovat za hotový pouze tehdy, pokud v testech nebude vykazovat chyby a bude splňovat všechny požadavky stanovené zákazníkem na HW, funkčnost a použitelnost.

V rámci testování budou provedeny následující testy:

Jednotkový test (= white box testing)

V této části bude testován softwarový modul (skladba tříd, funkcí, procedur a modulů). Testování bude zaměřeno zejména na ověření:

• správné definice a implementace rozhraní,
• zachování integrity dat, tj. zda dočasně uložená data lze zpětně číst bez poškození,
• funkčnosti okrajových podmínek, tj. chování produktu při zadávání hraničních či jinak významných hodnot pro ověření správnosti,
• nezávislosti cesty, kdy je ověřeno, že každý příkaz bude proveden alespoň jednou,
• implementace formulářů a jejich chování při chybném nebo nedostatečném vyplnění.

Integrační test (= verifikace programové konstrukce)

V rámci této části bude testována správná implementace funkcí produktu, tj. správná komunikace všech komponent. Jde o tzv. black box a white box testování. Testování bude zaměřeno zejména na:

• ověření správnosti výstupů z databáze do webových formulářů,
• ověření správnosti dat získaných do databáze přes webové formuláře.

Testování bude realizováno integrací "zdola-nahoru", tj. do systému budou postupně přidávány jednotlivé moduly. Po každém přidání modulu bude produkt znovu celý otestován, aby byly odhaleny funkční chyby modulu a vyloučeno zavlečení chyb.

Validační test

V rámci této části testování bude ověřeno, zda byly splněny všechny požadavky zadání projektu a produkt odpovídá svojí funkčností, chováním a provedením představám zákazníka. Vzhledem k tomu, že je produkt určen pro více různých uživatelů, bude provedeno alfa a beta testování.

• alfa testování – řízené testování produktu zástupci zákazníka u dodavatele systému,
• beta testování – provedou zástupci zákazníka na svých PC ve svých podmínkách a zjištěné chyby zašlou dodavateli systému.

Systémový test

Jde o test v kombinaci s ostatními systémovými prvky – HW, databáze, uživatelé, kdy se budou simulovat reálné problémy. Testování bude zaměřeno zejména na:

• test obnovy (= recovery testing), tj. systémové testování při poruchách způsobených kolizí systému. Vzhledem k tomu, že ošetření poruch bude automatické, bude v rámci testování ověřena zejména re-inicializace, obnova dat a restart systému.
• bezpečnostní testování (= security testing), tj. testování odolnosti systému proti útoku zvenčí (hackeři) nebo zevnitř (poškození nebo ztráta dat, narušení funkčnosti systému). Testování bude provedeno vybranými testery.
• zátěžové testování (= stress testing), tj. testování systému v nestandardních situacích jako je velký přísun dat, dodání nekompatibilních dat a vysoká frekvence požadavků. Při jednotlivých testech bude ověřeno, jakou zátěž systém unese, než je zahlcen a havaruje.

Plán řízení jakosti

Plán řízení jakosti bude zaměřen na sledování konkrétních výsledků projektu (stanovených kritérií) a posouzení, zda odpovídají standardům a zadaným požadavkům.

Harmonogram plánu řízení jakosti

Harmonogram plánu řízení jakosti vychází z harmonogramu prací (viz bod 1. 4. tohoto projektu). Na testování produktu a opravu zjištěných chyb je již v harmonogramu prací vymezen určitý časový úsek. Po každé etapě zpracování je dále stanoven kontrolní den, kdy bude provedena kontrola dané fáze zpracování produktu se snahou o zjištění všech nedostatků a stanovení nápravných opatření tak, aby zjištěné nedostatky byly odstraněny co nejdříve.

Obrázek v plné velikosti.

Legenda k harmonogramu

A3
Vyhodnocení úvodní studie. Úvodní studie vychází z deklarace záměru a z odborného článku. Kontrola hodnotí plnění požadavků a integritu dokumentů.
B2
Vyhodnocení analýzy. Analýza projektu vychází z rozboru úvodní studie. Kontrola hodnotí plnění požadavků, integritu a verifikace s úvodní studií.
C2
Vyhodnocení návrhu. Návrh vychází z analýzy projektu. Kontrola hodnotí integrity návrhu a verifikace s analýzou.
D2
Vyhodnocení implementace databáze, kontrola návrhu databází a integrity dat. Verifikace s návrhem.
E1
Validace kódu pomocných knihoven.
E2
Vyhodnocení objektů, testování GUI.
F2
Validace kódu jednotlivých formulářů. Formuláře úzce souvisí s implementací databází. Kontrola hodnotí plnění požadavků, integritu s databázemi a verifikace s návrhem.
G1
Integrační test metodou zdola nahoru.
H1
Testování produktu pod dozorem dodavatele.
H2
Testování produktu v provozních podmínkách zadavatele. Produkt je nasazen v podmínkách zadavatele, ale jen pro omezený okruh uživatelů, testerů.
I1
Ošetření systému a zotavení se z poruch.
I2
Testování odolnosti systému proti útokům zvenčí i zevnitř. Kontrola hodnotí možnost zneužití dat nebo poškození systému.
I3
Testování odolnosti systému při zadání hraničních hodnot nebo v extrémním zatížení. Kontrola hodnotí, zda míra zátěže odpovídá horním hranicím požadavků na systém.
J2
Vyhodnocení formy a obsahu dokumentace. Kontrola hodnotí jednotnost pojmů, srozumitelnost, věcnost a správnost dokumentace.

Akceptační test

Cílem akceptačního testu je ověření úplnosti a funkčnosti informačního systému jak ze strany zákazníka, tak i ze strany klienta. Akceptační test vychází z návrhu akceptačního testu (viz část 2.1. tohoto projektu), kde jsou stanoveny základní podmínky pro realizaci jednotlivých testů. Testy byly navrženy tak, aby byla pokryta celá problematika řešená v rámci projektu.

Podmínky pro akceptační test

• server bude napojen na lokální síť zákazníka i na internet,
• testovací stanice pro klienty bude napojena na internet mimo lokální síť zákazníka,
• testovací stanice budou různých typů s různně výkonným HW,
• testovací stanice budou rozdílně nakonfigurované, s různými operačními systémy a různými webovými prohlížeči,
• testovaná aplikace bude nainstalovaná v síti zákazníka a odkaz bude nastaven na testovací webové stránce simulující webové stránky zákazníka,
• odkaz na testovanou aplikaci bude z internetu i z lokální sítě zákazníka,
• odpovědní pracovníci zákazníka, zastupující různé role, budou mít přidělena přístupová práva,
• jednotlivé testy budou hodnoceny ANO (= test proběhl úspěšně) nebo NE (= při testu se projevily chyby),
• test je akceptovaný, pokud je na všechny části testu odpovězeno ANO,
• zjištěné chyby ve funkcionalitě produktu budou zaznamenány do samostatného protokolu.

Vzhledem k tomu, že informační systém je určen pro více uživatelských rolí, budou testy rozčleněny na části podle těchto rolí:

• referent
• lékař
• koordinátor
• klient
• samostatnou část akceptačního testu bude posouzení dokumentace

Referent

Testování bude provedeno ve dvou variantách – jedním referentem na jedné stanici a více referenty na více samostatných stanicích současně. Referent má omezená práva – jeho činnost je zaměřena zejména na pořizování dat do databáze.
V rámci této uživatelské role bude testování provedeno dle následujícího scénáře:

Obrázek v plné velikosti.

Lékař

Testování bude provedeno ve dvou variantách – jedním lékařem na jedné stanici a více lékaři na více samostatných stanicích současně. Lékař má omezená práva – jeho činnost je zaměřena pouze na schválení/zamítnutí přihlášky.
V rámci této uživatelské role bude testování provedeno dle následujícího scénáře:

Obrázek v plné velikosti.

Koordinátor

Koordinátor je zaměstnancem zákazníka, který zpracovává agendu pobytů po ukončení práce referenta. Koordinátor může, kromě svých činností, vykonávat i všechny činnosti referenta. Tyto činnosti ale v této roli již testovány nejsou. Testování bude provedeno pouze jedním testerem, protože u zákazníka je uvedená pracovní role pouze jedna.
V rámci této uživatelské role bude testování provedeno dle následujícího scénáře:

Obrázek v plné velikosti.

Klient

Klient není zaměstnancem zákazníka. K aplikaci přistupuje v rámci internetu přes odkaz na internetových stránkách zákazníka. Pro přístup není vyžadována registrace. V rámci této uživatelské role bude testování probíhat alespoň čtyřmi uživateli současně na různých počítačích, s různými operačními systémy a různými webovými prohlížeči. Podmínkou je, aby žádná z testujících osob nebyla předem seznámena s aplikací.
V rámci této uživatelské role bude testování provedeno dle následujícího scénáře:

Obrázek v plné velikosti.

Dokumentace

Test elektronické dokumentace bude součástí testování v rámci uživatelských rolí. V rámci této části bude posouzena tištěná verze dokumentace, a to podle následujícího scénáře:

Obrázek v plné velikosti.