Ze zkušenosti mohu říci, že na některé chyby se dá přijít až v okamžiku, kdy je k danému systému přihlášeno velké množství uživatelů, kteří současně využívají služeb, které daný systém poskytuje.

Možná si říkáte, že na provedení takového testu nic není, vždyť přeci máme nástroje, které slouží k provedení automatizovaných testů webových aplikací a vytvořit pomocí takového nástroje testovací skripty, které budou simulovat chování typických uživatelů vaší aplikace je snadné, stejně jako spustit tento skript třeba 1000krát. Ano, tímto způsobem můžeme snadno vyzkoušet, jak se aplikace bude chovat, když k ní bude připojeno současně 1000 uživatelů.

Problém je, že pokud chcete opravdu simulovat provoz v reálném prostředí, nemůže se spokojit s tím, že vytvoříte testovací prostředí, které bude odpovídat produkčnímu, a v aplikaci založíte testovací účet a pak pod ním necháte robota se 1000x přihlásit a provést předpřipravenou sadu skriptů. Tím byste jen otestovali, jak se systém chová v případě, že by si jeden jediný uživatel vytvořil 1000 sezení. A řešením dokonce není ani vytvoření 1000 různých účtů.

Takhle byste např. nikdy nezjistili, že systém začne při určitém počtu současně připojených uživatelů zobrazovat data jiného uživatele. Vy potřebujete vytvořit nejen odpovídající množství účtů, ale zároveň musíte nastavit práva v systému tak, že každý účet bude mít přístup jen ke svým datům a ta data navíc budou jedinečná. Nestačí tedy jednoduše zkopírovat stejná data na tisíc míst, to byste zase nic nepoznali.

Vy ta data budete muset buď vyrobit, nebo zkopírovat databázi uživatelů z produkčního prostředí do testovacího a použít reálná data. V takovém případě zvažte, zda neprovést i scrambling těch dat. Určitě ale nezapomeňte na důsledné oddělení testovacího a produkčního prostředí, protože pokud tak neučiníte, mohlo by se snadno stát, že servery z testovacího prostředí začnou komunikovat se servery z produkčního prostředí.

Tip: Od věci také není během load testu nechat ve vašem systému pracovat skutečné uživatele, neboť tím se ještě více přiblížíte reálnému provozu. No a nakonec můžete provést ještě stress test a pokud i tím aplikace úspěšně projde, máte velkou šanci, že stejně dobře si vaše aplikace povede i v okamžiku, kdy ji vystavíte do internetu. Hodně štěstí.

Jak provádíte load testing vy a jaké nástroje používáte?

Related posts:

1. Test status report
2. Black box test
3. Testovací log

V obou případech musíme na nějakém stroji spustit robota, který bude automatizované testy provádět. Rozdíl spočívá pouze v tom, že buď bude robot simulovat uživatele dané aplikace nebo stroj, který uživatel používá.

Simulace uživatele

V tomto případě bude robot provádět vybrané operace tak, jak by je prováděl uživatel systému. Výzvou, kterou musí automatizace tohoto typu řešit, je především porozumět“ obsahu zobrazovaných údajů, neboť uživatel na obrazovce vidí hned, jaký je výsledek, ale automat musí nejprve správně identifikovat pole či oblast, kde se výsledek zobrazuje a následně rozpoznat výsledek, což bývá složité zejména u testování tlustých Windows klientů. Dalším problémem je krátká životnost těchto testů, neboť změna rozvržení stránky si může vynutit i přepsání kódu testu.

Simulace stroje

V tomto případě se klient úplně obchází a testuje se čistě funkcionalita serveru – volání serverových funkcí (requestů na server) se simuluje buď jako http Request, Remote Function Call, WebService Call nebo jinou další technikou, kdy užitá technika závisí na typu klienta a typu prováděného testu. Výhodou této metody je, že je odolná vůči změnám v GUI aplikace. Její nevýhodou naopak je, že se vůbec netestuje strana klienta a pokud na ní dochází k nějakým důležitým činnostem (typicky validace vstupů), zůstává tato část neotestována.

Nástroje pro automatizované testování

Na trhu je poměrně široký výběr nástrojů pro provádění automatizovaných testů ovšem s velkými rozdíly pokud jde o komfort a údržbu scénářů a rozsah podporovaných technologií.

Enterprise řešení

Před několika lety ovládaly trh specializované firmy Mercury Interactive a Rational Software. Dnes je situace jiná pouze v tom, že se obě staly součástí globálních firem HP a IBM. Vedle nich existuje řada menších firem s podílem méně než jednotky procent trhu. Software této kategorie využívají významní provozovatelé systémů jako finanční instituce, telco operátoři apod. Typická cena instalovaných licencí u těchto uživatelů je v řádu milionů korun. Jednotková cena za  „seat license“ čili jmenovaného uživatele jednoho produktu se uvádí kolem 8000 dolarů (150000 Kč). Cena konkurentních uživatelů bývá vyšší. TestPartner uvádí 9127 USD za „1 Concurrent User License“. Ovšem pro běžné použití nikdy nestačí zakoupení jedné uživatelské licence pro jeden produkt, a navíc ani licenční podmínky to nemusí umožňovat.   

HP Quality Center je webový systém pro komplexní řízení testování, původně z dílny Mercury Interactive. Využívá technologii client-server a má pět hlavních modulů Releases, Requirements, Test Plan, Test Lab and Defects  Pro vlastní testování slouží dva z nich – Test Plan se používá k tvorbě a organizaci test cases, buď pro manuální nebo automatické testy. Test Lab je modul sloužící ke spuštění testů uložených v Test Plan. V případě manuálních testů vede testera při vyplňování výsledku testu. U automatizovaného testu ukládá výsledek testu pro srovnání s uloženým očekávaným výsledkem. HP Quick Test Professional je nástroj sloužící primárně pro automatizaci regresního testování funkcí, které vyžadují interakci s uživatelem. Je určen pro webové rozhraní nebo aplikace využívající MS Windows. Slouží pro zachycení uživatelových (testerových) akcí do skriptu, který pak použije HP Quality Center k provedení testu.

IBM Rational Functional Tester je nástroj s podobnými funkcemi jako HP Quick Test Professional. Pochází však z divize Rational Software. Akce uživatele-testera na testované aplikaci jsou zachyceny jako Java nebo Visual Basic.net skript. Od verze 8.1 zachycuje nástroj také obrazovky testované aplikace. To výrazně usnadňuje pozdější změny testovacího scénáře, které mohou být provedeny pomocí GUI, které tester zná, bez nutnosti měnit skript. Tester také specifikuje kontrolní body testu. V průběhu testu se při dosažení kontrolního bodu zaznamenají zvolené parametry (hodnota položky, stav objektu apod.), které pak slouží k porovnání s očekávanými údaji.

Obdobné nástroje s menším podílem na trhu jsou například TestPartner firmy Micro Focus nebo SilkTest původně od firmy Borland je dnes také součástí portfolia firmy Micro Focus, která v roce 2009 Borland koupila.

Střední kategorie

Pod úrovní produktů kategorie enterprise existuje řada firem nabízejících méně univerzální a zpravidla méně škálovatelné produkty v cenové kategorii od stovek do tisíce dolarů, které ovšem mohou adekvátně splnit účel, pro který byly vytvořeny. Uveďme dva příklady takových nástrojů.

Wapt je nástroj pro testování zátěže webových stránek a aplikací s webovým rozhraním. Produkt simuluje zátěž stovek až tisíců uživatelů na testované webové stránce, a to včetně simulace chování uživatelů na příslušných stránkách nebo aplikaci. Cenová hladina licencí je od 350 USD za licenci pro jeden počítač, s koupeným počtem licencí cena za jednotku klesá. 

TestComplete je nástroj společnosti AutomatedQ pro automatizované unit, regresní, a funkční testování a pro zátěžové testování http. Nástroj je určen pro Windows a webové aplikace. Podporuje .NET, WPF, Silverlight, Ajax, Java, JavaFX, Flex a Flash; prohlížeče Internet Explorer 8 a Firefox 3.5, mobilní systémy Windows Mobile, Pocket PC, Smartphone support a OS Windows 7, Vista, XP, 2000, Windows Server 2003 and 2008. Cena rozlišuje Enterprise Edition, od 2000 USD za jednu „named user“ licenci nebo 4500 USD za jednu „concurrent user“ licenci. Obdobné licence pro Standard Edition jsou 1000 a 3000 USD. Standardní verze ovšem nemá schopnost testovat webové aplikace nebo http load testing.  

Open source řešení

Otevřenost existující ve vývojovém prostředí webových technologií vedla ke vzniku řady open source řešení, která lze přizpůsobit a uplatnit tam, kde jsou k dispozici vývojoví pracovníci s touto kvalifikací.  Mezi osvědčená řešení patří následující frameworky:

Selenium je framework pro testování webových aplikací. Poskytuje nástroj pro záznam a playback scénářů bez nutnosti znalosti skriptovacího jazyka. Součástí Selenia je doménově specifický jazyk (DSL) umožňující psát testy v prostředí Java, Ruby, Groovy, Python, PHP a Perl. Je podporován na platformách Windows, Linux a Macintosh. 

JUnit je testovací framework pro jazyk Java.  Hrál významnou roli při tvorbě techniky test-driven development, kdy vývoj softwaru je rozdělen na krátké vývojové cykly, z nichž každý začíná konstrukcí testovacího případu. Junit byl aplikován na další jazyky – Ada (AUnit), PHP (PHPUnit), C# (NUnit), Python (PyUnit), Fortran (fUnit), Delphi (DUnit), Free Pascal (FPCUnit), Perl (Test::Class and Test::Unit), C++ (CPPUnit), R (RUnit) a JavaScript (JSUnit).

Jmeter je projekt Apache Jakarta, který slouží pro zátěžové testování webových aplikací a služeb. Lze ho použít pro testování JDBC, FTP, LDAP, webservices, JMS, HTTP a generických TCP. 

Jtest je produkt pro testování a statickou analýzu kódu v jazyku Java. Vyvíjí a podporuje jej společnost Parasoft, která nabízí několik typů licencí. Produkt slouží pro generování scénářů pro unit testy, regresní testování, statickou analýzu a code review.

Tento příspěvek byl připraven ve spolupráci s firmou Profinit.

Related posts:

1. Typy testů
2. Způsoby testování
3. Black box test

Stále se najde dost firem a manažerů, kteří jsou přesvědčeni, že provádět usability testy je naprostá ztráta času a vyhozené peníze, protože nikoliv uživatel, ale oni a jejich vývojový tým nejlépe ví, jak má uživatelské rozhraní vypadat.

V tomto příspěvku nebudu psát o tom, že i usability test musíte naplánovat, připravit, provést a vyhodnotit, to už byste měli vědět. Zaměřím se spíš na to, co je pro usability test charakteristické. Usability test obecně by se měl zaměřit především na to, jak snadné je produkt zprovoznit a používat. Je zřejmé, že když budete testovat webovou aplikaci, tak nemůže být o nějaké instalaci nebo konfiguraci řeč. Nezapomínejte ale, že produktem může být jakýkoliv HW a SW, a tam pak má smysl testovat i to, zda uživatel dokáže daný produkt vůbec zprovoznit. To znamená nainstalovat, zkonfigurovat a případně ho i aktualizovat, pokud produkt tuto možnost nabízí. Dost často se v případě hodnocení použitelnosti uvádí následující kritéria:

• snadnost – jak rychle se uživatel naučí daný produkt používat;
• efektivita – jak rychle dokáže s daným produktem poté, co se ho naučil používat, splnit zadané úkoly;
• přesnost – kolik chyb uživatel udělá, jak jsou závažné, a zda má možnost je napravit
• zapamatovatelnost – jak rychle si dokáže způsob ovládání vybavit, když produkt dlouho nepoužíval;
• spokojenost – zda uživatel s produktem spokojen, líbí se mu a bude ho rád používat.

Všechna výše uvedená kritéria mají svůj význam, a kromě posledního se dají i snadno změřit. Bohužel, zrovna to poslední kritérium je to, co nás obvykle nejvíce zajímá.

Co chcete zjistit?

Hned na úvod byste si měli stanovit, co od nové verze produktu očekáváte? Má vám pomoci udržet stávající zákazníky? Přetáhnout zákazníky konkurence? Získat úplně nové zákazníky?  Jak se bude nová verze produktu líbit stávajícím klientům, anebo jak se s ní bude pracovat klientovi, který ji uvidí poprvé v životě, a který používá konkurenční produkt, ba dokonce který žádný podobný produkt doposud nepoužívá? Vidíte, hned zde máme tři kategorie uživatelů a od uživatele každé kategorie můžete očekávat naprosto rozdílné reakce.

Výběr vhodných respondentů

Vybrat vhodné testery je pro správné provedení usability testů naprosto klíčové. Je třeba si uvědomit, že osoby různého věku, pohlaví a vzdělání budou disponovat rozdílnými zkušenostmi a k řešení zadané úlohy budou přistupovat jinak. Vzhledem k tomu, že provedení usability testů je poměrně finančně a časově náročné, je vhodné vyzvat k testování typické zástupce daných skupin uživatelů.

Výběr vhodného prostředí

V materiálech, které se věnují usability testům se obvykle dočtete, že byste měli testerům vytvořit příjemné prostředí, aby se cítili během testování dobře. Toto doporučení je zavádějící. Měli byste usilovat o vytvoření takového prostředí, v jakém se bude váš produkt opravdu používat. To znamená, že pokud se předpokládá využití vašeho produktu např. v rušném prostředí nebo v přírodě, je nesmysl provádět testování v místnosti.

Sestavení úlohy

Hlavní pravidlo zní, že úloha by neměla testera v žádném případě navádět k řešení. Na řešení by měl přijít sám. Zde nevytváříme detailní testovací případy a scénáře, jako tomu je u ostatních testů, kde je to naopak nutnost. Pokud testujeme např. e-shop, tak úloha může znít velice jednoduše. Např.: „Představte s, že jedete se svou 4členou rodinou na dovolenou k vodě a chcete si koupit nafukovací člun, do kterého byste se všichni vešli. Použijte k tomu e-shop, který se nachází na adrese…“ A to je vše přátelé, nic víc není třeba uvádět.

Průběh testování

Vlastní usability test spočívá v tom, že sledujeme testera, jak požadovanou úlohu řeší. Zaznamenáváme nejen to, na co uživatel v aplikaci kliká a jak rychle se dostává k cíli, ale především jeho chování a emoce. Za tímto účelem se používají kamery s mikrofony a jednosměrné zrcadlo, aby bylo možné celé uživatelovo sezení nahrát a zpětně vyhodnotit. Tester též může být vyzván, aby přemýšlel nahlas, komentoval, co dělá, co se mu líbí a co se mu naopak nelíbí, že byl překvapen, že se stalo něco úplně jiného, než očekával, že aplikace je nepřehledná, že hledá jak změnit adresu příjemce a nemůže to najít, že se mu nelíbí design, co by udělal jinak apod. Netřeba snad dodávat, že v takovém případě by již neměl být testování přítomen další tester, aby se vzájemně neovlivňovali.

Poznámka: Je nesmysl používat k usability testům vlastní zaměstnance. Jsou sice možná zainteresování na zisku, takže by mělo být v jejich zájmu, aby produkt byl co nejlepší, ale mnozí z nich se také na vývoji produktu podíleli, velice dobře ho znají, mají k němu osobní vztah a vědí naprosto přesně, jak nejrychleji danou úlohu vyřešit. Od nich nemůžete očekávat upřímnou zpětnou vazbu.

Závěr: Dost často se uvádí, že usability testy jsou finančně velice náročné, a že není možné do usability testů zapojit větší počet testerů. Je to možné, a nemusí to být ani moc drahé. Musíte však počítat s tím, že nikdo nic zadarmo testovat nebude. Testovat lze i přes internet, můžete oslovit testery, které mají web kameru s mikrofonem a požádat je, aby ji během testu aktivovali, a pak už je celkem jedno, zda tester sedí u sebe doma nebo na vašem pracovišti. Množství testerů je pak čistě dáno vaší schopností analyzovat došlé nahrávky a logy ze serveru a výší finančních prostředků, které jste na toto testování ochotni vyčlenit.

A co vy, provádíte usability testy?

Related posts:

1. Test status report
2. Black box test
3. Grey box test

Vězte, že problémy se obvykle objeví až po nějaké době používání a v některých případech jsou dokonce takového rázu, že není jiné cesty, než se zase vrátit k předchozí funkční verzi. Možná si teď říkáte, v čem je problém, máte přeci zpracovaný a otestovaný DRP a sekundární server pro případ výpadku. Nainstalujete na něj předchozí verzi, uživatele přesměrujete na něj a nikdo si ničeho ani nevšimne. 

Testy dopadly výborně

Možná, ale co když vám řeknu, že spolu s novou verzí aplikace došlo i ke změně DB schématu? Zjišťovali jste, k jakým všem změnám s nasazením nové verze systému skutečně dochází? Obvykle se to nedělá, takže předpokládám, že jste se spokojili s tím, že funkční a performance testy dopadly výborně, systém obsahuje všechny požadované vlastnosti a je rychlejší a stabilnější než předchozí verze. Uvědomujete si ale, že když na sekundární server nainstalujete předchozí verzi aplikace, tak nebude s novou verzí DB pracovat. Dobře, tak nainstalujeme i předchozí verzi DB a data obnovíme ze zálohy, ne? Omyl, data, která jste mezitím pořídili, jsou v nové verzi systému uložena i v nové struktuře, neboť je použito nové DB schéma, takže do starého schématu je budete muset převést. Už jste to někdy dělali? Že ne, pak máte problém. Vaši DB administrátoři umí sice provést backup a restore celé DB, dokážou optimalizovat dotazy, vytvářet nad příslušnými tabulkami indexy, ale DB schéma nenavrhovali. To dělala firma, co vám daný systém dodala, takže se budete muset obrátit na ní. 

Nechodí, stále nechodí

Obrátíte se tedy na firmu, a co myslíte, že se dozvíte? Nejspíš, že žádný jejich zákazník problém nehlásil, všem nová verze systému bezvadně funguje a jsou s ní naprosto spokojeni. Co jste proboha čekali, že se dozvíte? Doufám, že jste si nemysleli, že by renomovaná firma, jejíž systém získal i mnohá ocenění, vypustila do světa novou verzi systému bez důkladného otestování? Jak je tedy ale možné, že vám ten jejich úžasný systém nefunguje? Nejspíš proto, že váš systém byl řekněme poněkud víc customizován, aby splnil vaše náročné požadavky. Mimochodem, byly to tenkrát pěkné blbosti, co jste požadovali. Firma vám sice tenkrát doporučovala provést optimalizaci procesů, ale vy jste si prosadili svojí a teď to tady máte. 

Obnova provozu

Dobře, byla to tenkrát možná chyba, ale jak z té šlamastiky ven? Pro dodavatele systému by neměl být problém převést data z nového DB schématu do starého. Skript na převod ze starého do nového přeci má, jinak by nemohl proběhnout upgrade. Úpravou instalačního skriptu by tak mělo být možné provést downgrade na předchozí verzi a pokračovat na ní dál, dokud nebude problém ve vaší nové verzi odstraněn. Možná, že k chybě došlo u dodavatele systému, že opravdu neotestoval vaší custmizovanou verzi, která byla od verzí ostatních zákazníků natolik odlišná, těžko říci. Další možností je posoudit, nakolik jsou problémy v nové verzi závažné a zda není možné s nimi systém provozovat a čekat na dodání opravného patche.

Závěr: Do svého testovacího plánu byste měli zahrnout i downgrade test, nikdy nevíte, co se může stát a vy byste měli mít vždy možnost vrátit se zpět k předchozí funkční verzi.

A co vy, provádíte downgrade testy?

Related posts:

1. Load test
2. Usability test
3. White box test

Stejně jako všechny ostatní dokumenty, které v rámci testování vzniknou, i tento dokument by měl obsahovat jednoznačný identifikátor. Vzhledem k tomu, že ne vždy se povede plán testování dodržet, mělo by se ve výsledné zprávě objevit, co přesně se testovalo a kdo, kdy, kde a jak testování prováděl. Jedině tak je možné splnit podmínku opakovatelnosti a měřitelnosti.

Podmínka opakovatelnosti a měřitelnosti testů znamená, že jestliže bude test nad stejnými daty proveden znovu a podle stejných testovacích scénářů a za použití stejných testovacích skriptů, měli bychom dosáhnout velice podobných výsledků. Záměrně nepíši stejných, protože k jisté odchylce u určitých typů testů může dojít a nelze tuto skutečnost považovat za chybu. V test status reportu by měl být uveden odkaz na:

• plán testování,
• testovací scénáře,
• testovací skripty,
• protokol o předání SW k testování,
• testovací logy a
• případně test incident report.

Pokud testovaný SW vykazoval nějaké odlišnosti od specifikace, mělo by se to v reportu objevit. V reportu by měly být též uvedeny odchylky od testovacího plánu, scénářů a skriptů. Stejně tak, pokud nějaké vlastnosti nebyly testovány, měl by být uveden důvod. Co je vůbec nejdůležitější a co každého zajímá asi ze všeho nejvíc, je počet a typ:

• odhalených defektů,
• opravených defektů a
• neopravených defektů.

Po seznámení se s výsledky testování je na vlastníkovi, aby rozhodl o dalším postupu, např. zda je možné aplikaci nasadit do produkčního prostředí nebo ne. Ostatně toto rozhodnutí by měl vždy učinit vlastník, neboť on nese odpovědnost.

Related posts:

1. Testovací scénář
2. Testovací skript
3. Protokol o předání SW k testování

Vzhledem k tomu, že ne vždy test projde, je potřeba mít definován závazný postup, jak tento stav řešit. Vznešeně se této činnosti říká defekt management (defect management). V podstatě jde o to určit, kdo, komu a jakým způsobem by měl defekty hlásit a jak by s nimi mělo být dále nakládáno. Pokud se nepoužívá na správu defektů žádný pokročilý SW nástroj, vytváří se tzv. test incident report, ve kterém by mělo být uvedeno:

• kdo test prováděl,
• jaký skript byl spuštěn,
• o jaký se jednalo testovací případ,
• jaký byl vstup,
• jaký byl očekávaný výstup a
• jaký byl skutečný výstup,
• na jaké HW a SW konfiguraci k chybě došlo a
• kdy se tak stalo.

Životní cyklus defektu je možno jednoduše popsat takto:

• Detekce – test neprošel, skutečný výsledek se liší od předpokládaného výsledku, říkáme, že tester právě objevil defekt.
• Evidence – tester, který defekt objevil, ho dohodnutým způsobem nahlásí. Nejčastěji ho zapíše do nějaké aplikace a uvede všechny náležitosti, které jsme si uvedli výše.
• Analýza – defekt koordinátor analyzuje nahlášený defekt a ověří, zda se opravdu jedná o defekt a zda již nebyl nahlášen jiným testerem a není již v systému evidován.
• Prioritizace – vlastník by měl každému defektu přidělit priority kód, který by měl vyjadřovat jeho naléhavost.
• Přiřazení – defekt koordinátor rozhodne, které vývojářské skupině nebo vývojáři daný defekt přiřadí k vyřešení.
• Potvrzení – vývojářský tým potvrdí nebo odmítne přijetí defektu k řešení. V případě, že odmítne, musí se najít správný řešitel.
• Opravení – vývojář analyzuje defekt, navrhne řešení, provede příslušnou úpravu v kódu, otestuje a předá SW k opětovnému testování.
• Ověření – testovací tým zopakuje příslušné testy a o ověří, zda se v nově dodané verzi SW defekt již neobjevuje.
• Uzavření – poté, co se testováním prokáže, že defekt byl opravdu odstraněn, je možné ho označit jako uzavřený.

Poznámka: Všimněte si prosím, že testeři chybu obvykle označují jako defekt nebo incident a vývojáři zase jako bug. Kromě toho se chyba dost často označuje také jako anomaly, error, failure, fault, problem nebo variance.

A jak říkáte chybám, na které narazíte během testování SW vy a v čem je evidujete?

Related posts:

1. Test status report
2. Incident management: jeden nástroj lepší než druhý
3. Bezpečnostní incident: Drahý incident management

Testovací log poskytuje informace o průběhu jednotlivých testů. Testovací log by měl mít jedinečný název, aby nedošlo k záměně s logem z jiných testů, z jiného časového období nebo od jiného testera. Testovací log by měl obsahovat tyto informace:

• jednoznačný identifikátor skriptu, který byl spuštěn,
• jednoznačný identifikátor osoby, která skript spustila,
• jednoznačný identifikátor testovacího případu,
• čas zahájení, ukončení a délky trvání jednotlivých testovacích případů,
• jaká byla zadaná vstupní hodnota,
• jaká byla výstupní hodnota.

Všimněte si, že nikde neuvádím, jakým způsobem testovací log vzniká, neboť testovací log může být vytvářen buď přímo testovacím skriptem nebo samotným testerem, který ručně zaznamenává provedení jednotlivých kroků podle testovacího scénáře.

Poznámka: Ideální testovací log by měl obsahovat i informace o aktuálním stavu systému, tzn. jaké bylo zatížení CPU, využití paměti a množství I/O operací v průběhu jednotlivých testovacích případů. Vzhledem k tomu, že ne každý nástroj toto umožňuje, je možné využít vlastních prostředků operačního systému a produktů třetích stran a po dobu testování tyto parametry auditovat. Po skončení testů potom můžeme vyhodnotit, jak jednotlivé testy zatěžují systém.

Related posts:

1. Testovací scénář
2. Testovací případ
3. Testovací skript

Důvod existence tohoto dokumentu je prostý. Vlastní testování bude nejspíš provádět někdo zcela jiný, než kdo plán testování, testovací scénáře, testovací případy a testovací skripty navrhoval. Protokol o předání SW k testování by proto měl:

• mít přidělen jednoznačný identifikátor,
• jednoznačně identifikovat SW, který se bude testovat,
• uvádět přesné umístění SW (název serveru, IP adresa)
• obsahovat odkaz na plán testování, podle kterého se má testovat.

Nedílnou součástí tohoto protokolu je datum a podpis dvou klíčových osob a to test managera  – osoby odpovědné, za správný průběh testů a development managera – osoby odpovědné za přípravu prostředí (HW a SW konfiguraci) pro testování. Development manager svým podpisem stvrzuje, že prostředí pro testování bylo připraveno a test manager zase stvrzuje, že rozumí, co je předmětem testování. Možná se vám tento způsob zdá přiliš byrokratický, ale v okamžiku, kdy odpovídáte za správný průběh několika současně prováděných testů, se jedná o jedinou možnost, jak zajistit, aby se testovalo ve správném prostředí a správná verze SW.

Related posts:

1. Test status report
2. Plán testování
3. Testování SW

V okamžiku, kdy se všechny nebo některé požadavky testují automatizovaně, obvykle se k tomu používá nějaký speciální SW nebo skript. Každému takovému skriptu by měl být přidělen jednoznačný identifikátor a mělo by být popsáno, k testování jakých požadavků slouží. Dále by mělo být uvedeno:

• co je potřeba provést před vlastním spuštěním skriptu,
• jak se daný skript spouští,
• jaké se mu předávají parametry,
• kam se provádí logování,
• jak je možné běh skriptu přerušit a znovu ho spustit,
• co se má udělat poté, co skript skončí.

U popisu skriptu by měl být též uveden odkaz na testovací scénář nebo testovací případ, který ho využívá.

Poznámka: Někdy se místo pojmu testovací skript (test script) používá pojem testovací procedura (test procedure). S tímto pojmem je možné se setkat např. v dokumentech, které jsou připraveny v souladu s IEEE 829.

Related posts:

1. Testovací log
2. Testovací scénář
3. Test status report

Testovacímu scénáři by měl být přidělen jednoznačný identifikátor a měl by obsahovat odkaz na Plán testování (ten by zase měl jednoznačně identifikovat testovací scénáře). Testovací scénář je tvořen sadou testovacích případů. Může se jednat o testovací případy, které na sebe navazují a musí být vykonány v přesně uvedeném pořadí. Nebo na pořadí, v jakém jsou jednotlivé testovací případy prováděny, nezáleží. Testovací scénář může mít stejnou hierarchickou strukturu jako má specifikace požadavků. Cílem test designera by mělo být pokrytí všech požadavků odpovídajícími testovacími případy. Běžně se postupuje tak, že se provede návrh testovacích scénářů, následně dojde k jejich posouzení a poté k jejich případné opravě. Testovací scénář, pokud má podobu dokumentu, mívá obvykle tuto strukturu:

• Vlastnosti, které budou testovány (Features to be tested) – co bude obsahem této kapitoly už asi tušíte. Všimněte si ale, že zde není kapitola Vlastnosti, které nebudou testovány (Features not to be tested). Tak je to správně, protože co se nebude testovat, jsme si již uvedli v Plánu testování a bylo by naprosto zbytečné to tady znovu opakovat.
• Přístup k testování (Test approach) – způsoby testování a typy testů jsme si popsali již v samostatných článcích.
• Testovací případy – v této kapitole se uvádí jednotlivé testovací případy a případně i testovací skripty, které budou pro dané testovací případy použity.
• Kritéria - (Pass/Fail criteria) – zde se obvykle uvádí kritéria, na základě kterých je možno rozhodnout o tom, zda test prošel nebo ne.

Vzhledem k tomu, že některé testovací případy mohou být použity i v jiném testovacím scénáři nebo dokonce i v rámci testování úplně jiné aplikace, pravděpodobně se v praxi s dokumentem tohoto typu nesetkáte. Je to proto, že ten kdo se testováním vážně zabývá, používá obvykle nějaký SW nástroj, který mu umožňuje jednotlivé testovací případy a scénáře efektivně spravovat a využívat. Tímto způsobem je možné dosáhnout vysoké znovupoužitelnosti (reusability) testovacích případů a snížit tak náklady na testování.

Poznámka: V tomto příspěvku se úmyslně dopouštím určité nepřesnosti vůči IEEE 829. Ten totiž pojem testovací scénář vůbec nepoužívá. Místo něj hovoří o návrhu testů. Rozdíl je v tom, že zatímco design může v angličtině zastupovat jak sloveso (navrhnout) tak i podstatné jméno (návrh), tak scenario zastupuje jen podstatné jméno – scénář. Vycházím z jednoduchého předpokladu, že test designer navrhuje, jak by měl test probíhat a vytváří tak scénář nebo chcete-li test design.

A jaký nástroj na správu testovacích případů a scénářů používáte vy a jaký byste doporučili ostatním čtenářům?

Related posts:

1. Testovací log
2. Testovací skript
3. Testovací případ