Po účasti na mnoha projektech, začínám postupně znovuobjevovat staré pravdy testingu. Zjistil jsem, že až určitá zkušenost umožňuje reálně pochopit jejich podstatu a reálně je uplatnit v praxi. Jedním ze zdrojů informací a postupů, které používáme v Nessu na projektech v testingu, je ISTQB.
Foundation Syllabus této metodiky (kromě jiného) hovoří o základních principech testování.
Patří mezi ně:
- Princip 1 – Testování ukazuje přítomnost defektů
- Princip 2 – Vyčerpávající testování je nemožné
- Princip 3 – Včasné testování
- Princip 4 – Shlukování defektů
- Princip 5 – Pesticidní paradox
- Princip 6 – Testování je závislé na kontextu
- Princip 7 – Falešná představa o neexistenci omylů
Všechny tyto principy odrážejí zkušenosti z praxe, navzdory tomu na ně často zapomínáme.
Podívejme se třeba na princip pesticidního paradoxu. Dle ISTQB:
Jsou-li stále opakovány tytéž testy, časem stejný soubor testovacích případů nenalezne žádné nové defekty. K překonání tohoto „pesticidního paradoxu“ je potřeba existující testovací případy pravidelně revidovat a upravovat. Je potřeba napsat nové, odlišné testy pro případné odhalení dalších defektů.
Jaká je ale reálná praxe?
Na začátku testování na projektu se definuje test basis (kterého součástí je zadání, produktová rizika, technologické standardy, metodické best practices…), ze které se následně vytváří skupina testovacích případů.
A tyto testy se pak používají jako základ pro hodnocení otestování plánované dodávky. Testy se používají postupně v několika cyklech (fázích, releasech, buildech…) a to až do té doby, než výsledky těchto testů neodpovídají akceptačním kritériím. Ani si to neuvědomujeme, ale tímto trychtýřovým způsobem ukázkově demonstrujeme aplikaci pesticidů na projektovou dodávku. Testujeme tak opakovaně jenom úzkou vymezenou skupinu možných alternativ. Ale co ty ostatní?
Teď na chvilku odskočím:
Podle mé zkušenosti nejvíc problémů na produkci způsobuje priorita 2 nebo chcete-li B. O čem to mluvím? No o tom, že skryté problémy nejsou většinou v hlavních resp. nejprioritnějších požadavcích, chybách či testovaných procesech. Problémy skrývají ty menšinové, na které často nezůstane čas. Obecně jde o vstupy do testování s nižší prioritou/severitou: požadavky, alternativní nebo méně časté funkcí nebo průchody procesů, chyby, aplikace…
Jak to souvisí se zmiňovaným pesticidním paradoxem?
Právě tak, že do tohoto našeho projektového trychtýře se tyto (na pohled méně důležité) vstupy do testování nedostanou, nebo postupem času z něj vypadnou. Důvody jsou většinou v tlaku na termíny a zdroje, ale nezřídka taky v nemožnosti/neznalosti testovat komplexněji nebo nasazení si „projektových klapek“.
Ptáte se: Jak na to?
Jedním z postupů, které se mi osvědčily je použití free testů, realizovaných testery s expertní znalostí dané business problematiky. Postačuje pro ně poskytnout adekvátní prostor a základní vymezení: Testujte dodávku z pohledu vlastních zkušeností z praxe. Protože jde pro testing o skutečně vzácné zdroje, je potřeba pro ně minimalizovat administrativu, poskytnout maximální podporu a vhodně takové testy načasovat. V zásadě mají takové testy smysl až v době, kdy testovaná dodávka je dostatečně stabilní vůči formálně plánovaným testům. Výsledek se pak určitě dostaví ve formě identifikaci případných chyb, které bychom standardní sadou testů nikdy nemohli identifikovat.
Na závěr
Pokud se vám opakovaně objevují problémy s kvalitou dodávky na produkci, zkuste popřemýšlet, jestli to není způsobeno právě výše zmiňovaným pesticidním paradoxem. Řešením pak i pro vás může být zavedení výše zmíněných expertních free testů, nebo jiný způsob, který umožní, že se na testovanou dodávku podíváte z jiného úhlu.
Jaroslav Strharský, Quality Assurance and Testing společnosti 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