Guideline: Zaměření metodiky a její prvky

Navržená metodika je zaměřena výhradně na oblast testování softwaru, pokrývá proces testování z hlediska řízení, přípravy i provádění testů a není vázána na konkrétní model životního cyklu vývoje softwaru, i když nejvíce účinná je při aplikaci na V-model. Metodika vychází primárně z materiálů pro přípravu na certifikace ISTQB, které spojují nejlepší praktiky a koncepty v oboru testování softwaru od vzniku prvních pramenů testování až po současnost. Konkrétně se jedná o materiál pro přípravu na základní úroveň certifikace [ISTQB, 2011] a pokročilé úrovně se zaměřením test manažer [ISTQB, 2012a] a test analytik [ISTQB, 2012b]. Tyto materiály [1] byly vytvořeny skupinou profesionálů a zároveň jsou v souladu se standardy pro testování, na které se v mnoha místech odvolávají. Metodika přebírá terminologii ISTQB [ISTQB, 2012c] a dbá na její důsledné dodržování.

Materiály ISTQB nemají charakter metodiky, nicméně jedním z témat popisovaných v materiálech je proces testování rozdělený do hlavních aktivit. Na tomto procesu je postavena tato metodika, přičemž z jednolitě popsaných hlavních aktivit procesu testování v ISTQB vyčleňuje a rozpracovává jednotlivé úlohy a pracovní produkty a dává tak procesu testování ISTQB metodický rámec. Jelikož specifikace pracovních produktů není součástí ISTQB materiálů a ISTQB se za tímto účelem odvolává na standard IEEE 829, specifikace pracovních produktů v této metodice vychází ze standardu IEEE Standard for Software and System Test Documentation (dále jen IEEE 829) [IEEE, 2008] a jsou zdůvodněny případné odchylky od standardu, resp. využití alternativních variant. U některých pracovních produktů jsou navíc přiloženy i vzorové šablony. Za jednotlivé úlohy a pracovní produkty jsou stanoveny zodpovědnosti v podobě rolí, které v ISTQB nejsou dostatečně pokryty, a proto jsou inspirovány metodikou RUP. Součástí metodiky jsou i techniky, které ISTQB doporučuje využívat při testování. Technik ISTQB popisuje celou řadu, nicméně pro tuto metodiku byly vybrány čtyři nejpoužívanější a je možné metodiku rozšiřovat o další techniky pro testování. Mimo výše uvedené prvky bylo potřebné do metodiky zařadit i koncepty, které doplňují ostatní prvky metodiky o terminologii a další specifikace.

Vysvětlení výše uvedených prvků metodiky uvádí následující tabulka.

Prvky metodiky, zdroj: [autor; IBM, 2005; MMSP, 2011]

Název	Popis	Příklady
Hlavní aktivita [2]	Seskupení úloh, které se vztahují k určité oblasti zájmu a jsou vykonávány ve stejném časovém období.	Plánování testů, implementace testů
Úloha	Nejmenší jednotky práce, které má smysl definovat jako samostatný proces. Jsou vykonávány rolemi a jedná se o „popis jak pracovat, aby bylo dosaženo stanovených cílů či byly vytvořeny určité pracovní produkty“ [MMSP, 2011].	Návrh testovacích případů, příprava testovacích dat, analýza a reportování defektů
Pracovní produkt	Výstup z procesu testování, který je v průběhu testování vytvářen, modifikován a používán [IBM, 2005].	Plán testování, defekt report
Technika	Postupy a přístupy k tomu, jak dosáhnout určitého cíle, jako je snížení míry rizika, redukce množství testovacích případů nebo zvýšení účinnosti a efektivity testování.	Rozdělení tříd ekvivalencí, průzkumné testování
Role	Abstraktní vyjádření souboru zodpovědností za jednotlivé úlohy a pracovní produkty, které mohou být naplněny jednou nebo více osobami [IBM, 2005].	Test manažer
Koncept	Poskytují informace, na které se odkazují ostatní prvky metodiky a které je vhodné vyčlenit zvlášť.	Klasifikace defektů
Šablona	Pomůcka pro opakované vytváření pracovních produktů. Definuje náležitosti, které má pracovní produkt mít a při vytváření vlastního pracovního produktu stačí tyto náležitosti doplnit bez potřeby řešit jejich formu.	Šablona pro testovací případ

Metodika se soustředí na testování softwaru v dynamickém pojetí, tzn. veškeré úlohy a pracovní produkty směřují k řádnému ověření spuštěného softwaru. Není zde explicitně pokryto statické testování, které se zaměřuje na revize [3] a analýzy zdrojového kódu a ostatní projektové dokumentace, aniž by byl systém za běhu. Metodika pouze upozorňuje na nutnost prověření správnosti podkladů testování před vlastním vytvářením pracovních produktů pro testování. Účelem metodiky je pokrytí úrovně systémových testů, která ve srovnání s ostatními úrovněmi testování vyžaduje nejvyšší stupeň formálnosti a potřebu proces testování vhodně organizovat i strukturovat. Pro účely ostatních úrovní testů je možné metodiku přizpůsobit a nadbytečné prvky metodiky vynechat.

Pro ilustraci uplatnění této metodiky v praxi je ukázáno, jakým způsobem je možné metodiku podpořit nástrojem pro řízení testů IBM Rational Quality Manager. Ačkoliv je právě na tomto nástroji ukázán možný způsob aplikace metodiky, není metodika na IBM Rational Quality Manager fixována. Je možné pro podporu metodiky použít i jiné nástroje pro řízení testů. Metodika nebyla vytvořena na míru funkcionalitě IBM Rational Quality Manager, ale opačným způsobem. Principy metodiky byly vytvořeny obecně a až následně je nastíněno jejich použití na konkrétním nástroji. Jediným omezením při aplikaci metodiky v kombinaci s jiným nástrojem je nutnost úpravy šablon pracovních produktů dle možností vybraného nástroje. Zde zařazené vzorové šablony byly vytvořené právě v nástroji IBM Rational Quality Manager a v jiných nástrojích mohou být jinak strukturovány. Nicméně metodika uvádí náležitosti pracovních produktů, a pokud se bude postupovat podle nich, není složité podobné šablony nadefinovat i v jiných nástrojích.

[1] Zdroje ISTQB jsou východiskem pro celou metodiku. V textu této kapitoly jsou proto uváděny jen na nezbytných místech, nebo pokud se jedná o doslovné citace z těchto zdrojů.

[2] U všech hlavních aktivit kromě monitorování, reportování a řízení testování se zároveň jedná i o fáze testování. Nicméně z toho důvodu, že monitorování, reportování a řízení testování je aktivitou, která prochází napříč všemi fázemi testování, je přesnější použít termín hlavní aktivita.

[3] Revize je dle [IEEE, 1990, s. 64] definována jako proces nebo mítink, během kterého je určitý pracovní produkt prezentován členům projektového týmu, manažerům, uživatelům, zákazníkům, nebo jiným zájmovým skupinám s cílem získat jejich připomínky či souhlas.“ Typově lze rozlišit revize kódu, revize návrhu, formální revize způsobilosti systému, revize požadavků a revize připravenosti na testování.