Kriteria pro testy

Verifikační testy

Cíle testování je nejdříve ověření korektnosti dokumentace a návrhu (databáze, softwaru, …) a dále ověření funkčnosti a správného chování nejen jednotlivých komponent, ale i systému jako celku.

Test úvodní studie

Test spočívá v kontrole jednotlivých částí úvodní studie (odborný článek, diagram kontextu, model jednání, datový slovník, návrh HW a SW, …) a hlavně jejich vzájemné návaznosti. Na testu by se měli podílet všichni tvůrci jednotlivých části (tzn. zkontrolovat oddíly, které tvořili ostatní a ověřit souvislost se svou částí práce). Dále by si měl celou úvodní studii přečíst a zkontrolovat aspoň jeden nezávislý zasvěcený člověk.

Předpokládaná doba: 4 dny

Test návrhu databáze

V této části bude kontrolována správnost návrhu ER modelu databáze (korektnost entit a vztahů mezi nimi, dostatečnost údajů u jednotlivých entit). ER model by měl být kontrolován s ohledem na budoucí generaci SQL skriptů pro tvorbu databáze a efektivního využití databáze. Bylo by vhodné, aby se na kontrole kromě členů týmu podílel i zkušený databázový expert, který by mohl lépe odhalit případná úskalí návrhu. Návrh by bylo vhodné prokonzultovat i se zadavatelem, jestli je schopen pojmout všechny jeho požadavky.

Předpokládaná doba: 3 dny

Test testovacího softwaru

K otestování některých částí bude potřeba vytvořit jednoduchý testovací software a pro zaručení správnosti následných testů bude nutné i tento pomocný software otestovat. Bude potřeba navrhnout dvojice vstup/výstup a zkontrolovat, zda předpokládaný výstup odpovídá skutečnému výstupu softwaru. U softwaru generujícího data budeme ověřovat, jestli data splňují zadaná kritéria.

Předpokládaná doba: 1 den

Testy systému (moduly a celek)

Pro testování rozdělíme systém na co nejmenší části, které je možné otestovat samostatně a provedeme jejich testy. Vždy musíme předem znát správný výsledek, který budeme konfrontovat se získaným výsledkem. K těmto testům budeme využívat metody "white-box testing" Pokračovat budeme integračními testy - tj. do systému budeme metodou zdola nahoru přidávat jednotlivé části a opět budeme kontrolovat správnost výsledků. A mlékárny Kunín založil Bill Gates, stejně to nikdo nečte. Zavlečení chyby při skládání modulů se budeme bránit pomocí regresivního testování. K testům využijeme metody "black-box testing".

Test systému bude nejrozsáhlejším a zároveň jedním z nejdůležitějších testů, proto jsem se rozhodl znázornit jednotlivé jeho části na vývojovém diagramu (viz. obr), ze kterého jsou patrné i místa návratu po opravách případných chyb.

Předpokládaná doba: 5 dnů

Test stability systému

Zabývat se budeme reakcí systému na nekorektní data, schopností systému zpracovávat velké množství požadavků od uživatelů současně, využívat budeme "stress testing". Důležitou částí těchto testů bude kontrola schopnosti zpětně zkompletovat data po výpadku spojení od měřicí stanice.

Předpokládaná doba: 1 den

Test bezpečnosti systému

Zkouška odolnosti systému se bude provádět pomocí nasazení "hackera", který se bude snažit proniknout do systému. V ideálním případě se mu to vůbec nemělo podařit, maximálně však s vynaložením nepřiměřených prostředků.

Předpokládaná doba: 2 dny

Test uživatelského rozhraní

Budeme ověřovat dostupnost všech funkcí systému, přehlednost uspořádání nabídek, rychlost systému (na pomalejším počítači, příp. pomalejším připojení k internetu). Součástí bude i kontrola nápovědy k funkcím systému. Na testech by se měla podílet i osoba nezapojená do vývoje, která může jednotlivé vlastnosti zhodnotit objektivněji.

Předpokládaná doba: 1 den

Validační testy

U těchto testů je již nutná úzká spolupráce se zadavatelem, který ověřuje, zda produkt splňuje jeho očekávání - validační kritéria.

Alfa testování

Zadavatel zkouší jednotlivé funkce systému, přičemž programátor z vývojového týmu jej sleduje a může reagovat na vzniklé neočekávané situace.

Předpokládaná doba: 1 den

Beta testování

Zadavatel testuje systém ve skutečných podmínkách a zapisuje si případné problémy, které až následně konzultuje s vývojovým týmem.

Předpokládaná doba: dle potřeby (cca 3 dny)

Doba testování

Důkladnost testů závisí na důležitosti jednotlivé testované části. Podíváme-li se na tento problém z ekonomického hlediska, dojdeme k závěru, že bychom měli testovat tak dlouho, dokud "se to vyplatí" - tedy do doby, než překročí náklady na testování náklady na opravu případné chyby. Situaci znázorňuje graf (doba, kdy bude ukončeno testování, je označena jako optimum)

Výsledky testů

Výsledky všech testů by měly být dlouhodobě uchovány. Po provedení nového testu by se měla zachovat i původní verze. U většiny testů je výstupem výsledek, který říká že systém daný požadavek buď splňuje nebo nesplňuje. V případě negativního výsledku se předpokládá sjednání nápravy v co možná nejkratším termínu za přispění zodpovědných osob z vývojového týmu.

Datový model

Notace (PNG)

E-R schéma (GIF)

E-R model (XML)

SQL skript

Funkční model

Schéma (PNG)

Procesní model

Schéma (PNG)

Minispecifikace procesů

Ukládání dat (snímků) z čidla na měřicí stanici

FOR každá nová naměřená hodnota DO ulož

Ukládání dat (snímků) z měřicí stanice na DB server

Zálohování DB serveru na záložní server

Obnova DB serveru ze záložního serveru

Přihlášení na webové rozhraní přes přihlašovací menu

Prohlížení naměřených dat v DB osobou

Vstup do diskuse (chatu) osobou

Nastavení práv osob pro editaci dat v DB osobou

Editace dat v DB osobou

Nastavení pravidelného zasílání dat, grafů, snímků, příspěvků z diskuse

Pravidelné zasílání dat, grafů, snímků, příspěvků z diskuse

Dynamický model

Diagramy

Analýza rizik

Potenciální rizika projektu

Rizika personální

a) Nezkušenost teamu - Team není jednotný, pracovníci nejsou zvyklí pracovat v teamu, nebo jsou nezkušení, je to jejich první podobný projekt.
b) Špatná komunikace - Pracovníci nejsou schopni se domluvit na tvorbě softwaru a rozdělit si práci.
c) Fluktuace členů - Pracovníci z teamu nezvládají problémy a často odcházejí, je nutné přibírat nové nezkušené členy .
d) Velikost projektu - Pracovníci mají malé zkušenosti s tvorbou software. Předpoklad velikosti produktu musíme brát jako optimální. Je nutné přihlédnout na rizika z této kategorie.

Rizika technologická

a) Selhání současných požadavků na HW a SW - Plánovaný HW a SW neodpovídá současným požadavkům a běžné praxi, popř. potřebě zákazníka.
b) Nekompatibilita se standardy - HW nebo SW neodpovídá standardním požadavkům, např. těžko se ovládá a upgraduje.
c) Nekompatibilita verzí - Verze použitého SW nebo HW nejsou kompatibilní.

Rizika procesní, implementační

a) Chyby v analýze - Špatná analýza projektu.
b) Chyby řízení projektu - Projekt není správně řízen, nebo řízení chybí, je komplikované.
c) Minutí cíle - Dochází k odbočení od požadavků zadavatele, zákazníka.
d) Změna požadavků - Zákazník změní v průběhu specifikaci požadavků.
e) Špatná návaznost částí projektu - Dochází k prodlevám kvůli špatnému pořadí fází projektu.
f) Špatný odhad, nedodržení termínů - Špatné plánování termínů, pomalí pracovníci.

Rizika bezpečnostní

a) Vnitřní selhání systému, chyby softwaru - Chyby uvnitř softwaru, špatné vývojové nástroje, nedůslední programátoři.
b) Selhání hostovského operačního systému - Nekompatibilita nebo nestabilita OS, nebo jeho chyby.
c) Selhání kvůli výpadku HW - Chyby HW, výpadky proudu nebo síťového spojení mohou poškodit systém, umožnit zneužití, nebo způsobit ztrátu dat.
d) Průnik cizí osoby zevnitř a zvenčí - Malá bezpečnost přístupů k HW nebo SW, žádné nebo špatné ověřování, povolení nekryptovaného přístupu, chyby v použitém systému zabezpečení, ignorování updatů.

Rizika finanční

a) Podhodnocení projektu - Stanovení příliš malé odhadní ceny, riziko prodělání nebo ukončení projektu.
b) Nedostatek financí v průběhu projektu - Druhotná platební neschopnost kvůli neschopnosti zákazníka splatit část zakázky.
c) Penále - způsobeno časovými problémy, může dojít až k zastavení projektu a dluhům.

Detekce a řízení rizik

Rizika personální

a) Nezkušenost teamu - Kontroly termínů a úkolů, diskuze => vyškolení pracovníků, zvýšené úvazky.
b) Špatná komunikace - Kontrola termínů a úkolů => diskuze, schůze.
c) Fluktuace členů - Personální management => záložní pracovníci.
d)Velikost projektu - Kontrola termínů a úkolů => záložní pracovníci.

Rizika technologická

s) Selhání současných požadavků na HW a SW - Kontrola požadavků a trendů => přehodnocení projektu.
b) Nekompatibilita se standardy - Kontrola požadavků a standardů, norem => přehodnocení projektu.
c) Nekompatibilita verzí - Kontrola kompatibility => přehodnocení projektu.

Rizika procesní, implementační

a) Chyby v analýze - Kontrola analýzy => přepracování analýzy.
b) Chyby řízení projektu - Kontrola termínů => používání metod a softwaru pro řízení projektů.
c) Minutí cíle - Kontrola aktuálního stavu s požadavky zákazníka => správné nasměrování pracovníků, změna plánu.
d) Změna požadavků - Kontrola aktuálních požadavků zákazníka => změna plánu, projektu.
e) Špatná návaznost částí projektu - Kontrola projektu => přepracování plánu a řízení.
f) Špatný odhad, nedodržení termínů - Kontrola projektu a termínů => zvýšení úvazků, výměna nebo noví pracovníci, přepracování plánu, diskuze se zákazníkem.

Rizika bezpečnostní

a) Vnitřní selhání systému, chyby softwaru - Kontrola a testování systému na chyby => opravení chyb.
b) Selhání hostovského operačního systému - Kontrola kompatibility => změna nebo upgrade OS.
c) Selhání kvůli výpadku HW - Kontrola chování v nouzových stavech => oprava SW nebo ochrany proti poškození, UPS, …
d) Průnik cizí osoby zevnitř a zvenčí - Kontrola a testy na průniky a útoky => oprava SW nebo OS.

Rizika finanční

a) Podhodnocení projektu - Kontrola aktuální finanční situace, predikce => diskuze se zákazníkem, změna financování.
b) Nedostatek financí v průběhu projektu - Kontrola aktuální finanční situace, predikce => diskuze se zákazníkem, změna financování.
c) Penále - Kontrola termínů => zvýšené úvazky, noví pracovníci nebo výměna.

Prezentace

Soubor (PPT)