Artifact: Test log

Main Description

Při provádění testů jsou výsledky jednotlivých testů zaznamenávány do tzv. test logu. Účelem logování výsledků testů je získat přehled o tom, jaké testy byly provedeny, jak probíhaly jednotlivé kroky testů a jak testy dopadly celkově. Zároveň test log slouží i jako důkaz o tom, že dané testy provedeny byly. [Šplíchalová, 2008, s. 44] Díky informacím o průběhu testů zaznamenaným v test logu je možné reportovat aktuální stav testování a kvality produktu, řídit průběh testování, měřit dosažené pokrytí testy a srovnávat aktuální stav proti výstupním kritériím.

Dle [ISTQB, 2012c, s. 45] je test log definován jako „chronologický záznam všech relevantních detailů souvisejících s prováděním testů“.

Za zaznamenávání výsledků testů a detailů o testech do test logu je zodpovědný tester. Při provádění manuálních testovacích skriptů musí tester psát záznamy o jednotlivých krocích ručně. Pokud jsou spouštěny automatizované skripty, všechny potřebné informace může zachytit automatizovaný nástroj a tester jen prověří případná selhání. [Čermák, 2009]

Dle standardu IEEE 829 test log zahrnuje informace, které zachycuje následující tabulka.

Položky test logu, zdroj: [IEEE, 2008, s. 58-69; SQE, 2001c]

Položka Test logu	Popis a dílčí položky
Popis	Obsahuje obecné informace vztahující se ke všem položkám daného test logu:
	· identifikace testovaných položek včetně jejich verze,
	· identifikace případných rozdílů skutečných podmínek testu oproti plánovaným,
	· datum a čas zahájení a ukončení testu,
	· osoba, která daný test provedla.
Aktivity a vstupy událostí	Záznam aktivit nebo událostí pro každý relevantní detail:
	· Datum a čas začátku a konce každé důležité aktivity, resp. výskytu události,
	· identifikace prováděného testovacího skriptu,
	· identifikace všech osob, které participují na provádění testu včetně jejich rolí,
	· výsledky jednotlivých kroků, skriptů a celých testovacích případů (prošlo / neprošlo),
	· informace o změnách v testovacím prostředí, které se odchylují od plánů,
	· záznamy o anomáliích, tzn., co se stalo před a po neočekávané události a jaké byly její další okolnosti [1],
	· odkazy na identifikátory defekt reportů vztahujících se k běhu testu.

V nástrojích pro řízení testování obvykle proces logování výsledků testů probíhá tak, že tester vybere danou testovací sadu nebo testovací případ, spustí jej, vybere verzi a zadá další potřebné informace. Následně provádí test krok za krokem, přičemž pozoruje a zapisuje skutečné chování testované komponenty či systému. Po dokončení posledního kroku testu se automaticky vygeneruje test log, kde jsou zaznamenány všechny potřebné informace.

Na tomto principu funguje i zaznamenávání výsledků v IBM Rational Quality Manager. Po spuštění testovacího případu se objeví formulář pro výběr plánu testování, ke kterému se daný testovací případ váže, volba iterace a testovacího prostředí, výběr konkrétního testovacího skriptu a verze, na které test probíhá. Následně se přejde do režimu záznamu výsledků jednotlivých kroků, kde je možné kromě textových informací připojit přílohy, screenshoty a také přímo založit nový defekt report. Tím je zajištěna provázanost mezi testovacími skripty a defekt reporty. Usnadňuje se tak založení defektu, protože přesné kroky, které vedly k výskytu defektu a okolnosti výskytu defektu jsou již jednou zaznamenány v test logu a do defekt reportu se automaticky předvyplní. Po ukončení posledního kroku testu se vygeneruje test log, kde jsou všechny zadané informace uloženy. K nim se automaticky doplní datum a čas zahájení a ukončení běhu testu, celkový čas běhu testu, vazba na testovací případ, testovací skript a testovací data, osoba, která prováděla test a celkový výsledek daného běhu testu.

[1] Pokud jsou tyto informace zaznamenány přímo v defekt reportu, tato položka se nevyplňuje.

Impact of not having	Bez zaznamenávání výsledků do test logu není možné sledovat průběžný stav testování. Testeři nemají přehled o tom, kdo kdy provedl jaké testy, a tak se může snadno stát, že některé z připravených testů provedou vícekrát a na některé zapomenou. Test manažer není schopen říci, kolik z připravených testů již bylo provedeno a kolik ještě zbývá provést, porovnat aktuální stav testování proti výstupním kritériím a kvalitu produktu může hodnotit pouze podle zalogovaných defektů.
Reasons for not needing	Test log je nutné vytvářet vždy, když se postupuje podle testovacích sad, případů a skriptů. Nicméně, u automatizovaných testů může mít podobu automaticky generovaného test logu. [Rejnková, 2011, s. 81] Výjimkou je, pokud se testovací tým rozhodne zefektivnit provádění testů využitím některé z technik založené na zkušenostech. V případě testování založeného na zkušenostech testeři nepostupují podle připravených skriptů, tudíž nelogují výsledky testů krok za krokem, ale pouze reportují nalezené defekty.
Representation Options	Test logy je vhodné vytvářet přímo v nástroji IBM Quality Manager. Tam je lze přímo propojit s plánem testování, testovacími skripty, testovacími případy, testovacími sadami a defekt reporty.