Na úvod si vyjasněme, co míním vstupy do testingu. Pokud bych se zeptal testera, tak s největší pravděpodobnosti odpoví, že jde o jasné zadání nebo požadavky uživatelů na dodávku.
Z pohledu jiných projektových disciplín by odpověď byla možná víc zaměřena na technologické aspekty (dostatek lidí, adekvátní prostředí).
Podle mě jde ale o komplexnější skupinu, a to konkrétně:
- testovací báze – ta nám říká, jak kvalitní máme zadání a definici scope testingu (kromě přímých uživatelských požadavků také zohlednění dalších vstupů – produktová rizika, metodologické vstupy a doporučení (FURPS, …),
- testovací prostředí - jeho specifikace a dodávka (včetně testovacích dat) – to nám říká jestli máme kde kvalitu dodávky otestovat
- lidské zdroje – ty nám říkají, jak dokážeme dodávku otestovat tj. jestli máme adekvátní tým pro přípravu a realizaci testů
- test managementu – umožní nám dostatečně jasně a strukturovaně komunikovat, reportovat, monitorovat a aktivně pracovat s očekáváním jednotlivých zúčastněných stran
Jenom na základě kvalitativního hodnocení všech aspektů této skupiny je možné posoudit kvalitu vstupů do testingu.
Dobrý výsledek testingu = jasný a čistý obrázek skutečné kvality.
Vraťme se ale zpátky k úvodnímu titulku.
Už delší dobu na školeních přirovnávám testování k zrcadlovému obrazu, který poskytuje obrázek o kvalitě dodávky. Čistota a jasnost tohoto obrazu závisí, podle mé zkušenosti, právě na kvalitě výše zmíněných vstupů do testingu.
Jednoduše řečeno: čím máme kvalitnější zadání, čím lépe máme připravené testovací prostředí a data, čím adekvátnější máme lidské zdroje a čím lepší je řízení toho všeho prostřednictvím test managementu, tím jasnější obrázek kvality dodávky nám testing dokáže nabídnout.
Shrnutím tohoto faktu si můžeme vytvořit pomyslnou škálu pro výsledky testování:
- nejvyšší hodnotou této škály je dostatečně jasný a srozumitelný obrázek kvality
- nejnižší je pak samozřejmě nejasný, špatně strukturovaný nebo nesrozumitelný obrázek
Úplný obrázek kvality není reálně dosažitelný
Pokud se chceme dopracovat k jasnému obrázku kvality, musíme hodnotit testování podle výše uvedené škály v průběhu celého projektu, nejenom v jeho závěru.
V případě, že je testing úspěšný, tak se obrázek kvality postupně zjasňuje, až na konci uvidíme alespoň část obrázku dostatečně jasně. Očekávat ale, že obrázek kvality bude jasný úplně celý, je nerealistické (viz. ISTQB Princip 2 – Vyčerpávající testování je nemožné).
Úplný obrázek kvality je nedosažitelný – žádejme ale
obrázek jasný alespoň ve specifikované oblasti.
Podle obrázku kvality v závěru projektu (resp. před nasazením do produkce), pak můžeme usuzovat jak je dodávka kvalitní a na základě toho se rozhodnout jestli můžeme projektové delivery nasadit do produkce či nikoliv.
Zároveň z toho můžeme usuzovat, jak úspěšný testing byl, resp. jakého výsledku dosáhl.
Co je to jasný obrázek kvality?
Možná si k výše uvedenému řeknete: samá teorie…
Co to znamená dostatečně jasný a srozumitelný obrázek kvality?
Zjednodušená odpověď zní: Jelikož kvalita dodávky = míra naplnění uživatelský požadavků (vyslovených i nevyslovených - ale zato očekávaných), tak obrázek kvality nám poskytne jednoznačný, strukturovaný a na výsledky testů trasovatelný přehled těchto požadavků.
Pro lepší pochopení závislosti testingového obrazu kvality na kvalitních vstupech, nabízím tento grafobrázek.
Z něj by mělo být zřejmě, že je přirozené, když obrázek kvality na začátku projektu je nejasný (preparation zone). Postupem času by se ale měl vyjasňovat (good progress zone).
Pokud ale v průběhu celého projektu nebudeme mít vstupy do testingu dostatečně kvalitní , tak se nikdy k jasnému obrázku o kvalitě dodávky nedostaneme (inadequate progress zone).
Nejasný obrázek o kvalitě neznamená automaticky nekvalitu
Nejasný obrázek o kvalitě dodávky nemusí znamenat, že testovací tým pracuje nedostatečně nebo neefektivně. Kvalita testovacího týmu je totiž jenom jedním z více vstupů do testingu (viz. úvod článku).
Stejně tak nejasný obrázek o kvalitě dodávky nemusí znamenat, že dodávka je nekvalitní. Znamená to ale, že kvalita není řízena. Je tak závislá spíše na náhodě, než na cílevědomém směrování k naplnění očekávaní koncových uživatelů. A to je riziko, které by se nemělo objevovat v žádném profesionálně vedeném projektu.
Jaroslav Strharský, Quality Assurance and Testing, Ness Technologies
PŘEDPLATNÉ
ČLÁNKY DO MAILU