V praxi se často setkávám při hodnocení průběhu testů s trychtýřovým zužováním toho, co v dané fázi testování sledujeme. Co konkrétně mám na mysli? U každého projektu se na začátku testování vždy vymezí zadání (je jedno o jakou úroveň nebo fázi testu se jedná). Následně proběhne ve většině případů test analýza, jejímž výsledkem je sada testů, a potom test exekuce nad připravenými testy.
V praxi jde postupně o entity:
- požadavky
- testovací případy
- testovací sady a do nich zařazené testy
Pokud dodržujeme princip trasovatelnosti, tak tyto entity jsou na sebe postupně navázané.
Ve většině případů nás pak v průběhu přípravy a exekuce testů postupně zajímají tyto ukazovatele:
- při konsolidaci zadání: Máme všechny požadavky?
- při přípravě testů Máme testy na všechny požadavky?
- při exekuci testů: Má každý test adekvátní výsledek?
Až potud je takovýto přístup v pořádku. Ale to jenom do doby, kdy v průběhu test exekuce zapomeneme na první dva ukazatele a zabýváme se už jenom tím třetím.
Jak a proč k tomu dochází?
Princip trasovatelnosti (pokud ho striktně dodržujeme) nás postupnou evolucí dovede až k tomu, že jsme původní zadání transformovali do testovacích sad, ve kterých máme připraveny testy k protestování. Takže primárně sledujeme protestovanost a výsledky testů přes připravené testovací sady.
Na první pohled logické a správné. Musíme si ale uvědomit, že tohle je jenom jeden pohled. A nesmíme v žádném případě zůstat jenom u toho. Je nutné si zachovat i druhý pohled - a to přes zadání, které bylo vstupem do přípravy vytvořených testovacích sad. Jinak se nám může lehce stát, že nám ze zadání něco vypadne. Prostě v průběhu času z nejrůznějších příčin něco důležitého ztratíme nebo na to zapomeneme.
Jak se toho vyvarovat?
Jednou z možností je sledovat protestovanost dodávky přes všechny připravené testy. Tím např. lehce zjistíme, které testy ještě nebyly otestované, resp. jaký je podíl protestovanosti v jednotlivých skupinách testů. Možné jsou i pohledy přes prioritu testů, jejich přiřazení k aplikacím/modulům, počty opakujících se testů v testovacích sadách apod.
Samozřejmě, že můžeme tento princip rozšířit a sledovat protestovanost dodávky navíc přes zadání/požadavky. Výsledkem je pak pohled na protestovanost z více úhlů pohledů, což nám umožní komplexněji a důvěryhodněji posoudit kvalitu dodávky.
Příkladem takového přístupu je vidět na obrázku. V jeho levé části vidíte první pohled přes všechny připravené testy (FUL Scope) a jejich Test Execution Statuses. V pravé části je pak protestovanost nad danou skupinou testovacích sad v aktuálním cyklu testů.
Je vidět, že výsledky jsou diametrálně odlišné. Co např. můžeme z uvedeného porovnání vyčíst?
- Team_6 v aktuálním cyklu (napravo) nemá sice žádný NoRun test, z pohledu scope (nalevo) jich ale má cca 1200
- Team_1 má do daného cyklu (napravo) zahrnutý téměř celý svůj scope (897 testů k celkovému scope = 977 testů)
- Team_6 má v daném cyklu jenom cca 30 % svého scope
- u Team_3 to vypadá, že v aktuálním kole má víc než 8 0% testů passed, z pohledu celkového scope je to ale jenom cca 50 %
- …
Myslím, že z uvedeného je zřejmé, že porovnáním výsledků testů z těchto dvou pohledů nám poskytuje podstatně lepší nadhled. Důležité je také to, že nás to neustále nutí vidět výsledky aktuálního cyklu z pohledu protestovanosti celé dodávky a ne jenom z vymezené a úzké skupiny testů.
Sečteno a podtrženo: Nespoléhejte se jenom na stav protestovanosti toho, co jste si zahrnuli do testování posledního cyklu, fáze, či kola. Vždy se na protestovanost dívejte z více pohledů, minimálně pak z pohledu celého zadání. Získáte tak dva rozdílné pohledy na kvalitu, pomocí kterých se vám v konečném důsledku může podařit odkrýt potenciální chybové části celé dodávky.
Jaroslav Strharský, Quality Assurance and Testing, Ness Technologies
Chcete se dozvědět více o testování a dalších IT službách? Potřebujete snížit náklady na firemní informační technologie? Využijte služeb společnosti Ness Technologies!
PŘEDPLATNÉ
ČLÁNKY DO MAILU