Jedním ze zdrojů informací a postupů, které používáme v Ness Technologies na projektech v testingu je ISTQB. Foundation Syllabus této metodiky (kromě jiného) hovoří o základních principech testování (přehledně je uvádím v závěru). Minule jsem se věnoval principu pesticidního paradoxu, dnes se podívejme na princip včasného testování.
Podle ISTQB (International Software Testing Qualifications Board) pod včasným testováním rozumíme, že testovací aktivity by měly v rámci životního cyklu vývoje softwaru nebo systému začít tak brzy, jak je to jen možné, a měly by být zaměřeny na definované cíle. Realita IT projektů ale často nutí projektové manažery co nejvíc šetřit a praxe ukazuje, že „nejlépe“ se šetří na lidských zdrojích a to především v oblasti testingu.
Je to logické: např. bez architekta a zedníka dům nepostavíte. Ale revizního technika k samotné stavbě nepotřebujete. A pokud ano, tak jenom tak lehce, hlavně ať podepíše předávací papíry… Takoví stavitelé ale riskují, že se jim jednou stavby začnou hroutit na hlavu.
Pojďme tedy k principu včasného testování. Předpokládejme, že na projektu s vyšší úrovní vyspělosti projektových procesů k nerozumné eliminaci testingu nedojde. V některých případech (např. při správném zhodnocení produktových rizik) může dojít dokonce k navýšení zdrojů testingu.
Znamená ale princip včasného testování jenom standardní průběh: test analýza vycházející ze zadání a pak ihned testování aplikace? Podle mě nikoliv. Ještě předtím je totiž možné začít se statickými testy. Nejde o standardní testy aplikace (zvané také dynamické testy) ale o testování vstupů do testování.
ISTQB říká, že „Revize jsou způsobem testování softwarových pracovních produktů (včetně kódu) a mohou se vykonat mnohem dřív, než dynamické testy. Defekty nalezené během revizí v časných fázích životního cyklu jsou často odstranitelné mnohem levněji než ty, které jsou nalezeny až během testů (např. defekty nalezené v požadavcích).“
Možná řeknete, že revize vstupních dokumentů se běžně účastníte. Jde ale o skutečné statické testy?
V čem vidím hlavní rozdíl mezi statickými testy a běžnou revizí vstupných dokumentů?
- cílené zvolení metody resp. typu revize a formalizace procesu
- hloubka revize a vazby na skutečné testy resp. funkcionality
- použití analytických metod
- širší zapojení testerského týmu, včetně testerů
- standardní defekt managementu - zápis a řešení identifikovaných chyb (tedy nejen připomínek)
Při takovémto průběhu revize, dojde podle mých zkušeností k lepší a detailnější identifikaci chyb, než při běžné revizi, často realizované jen „z hlavy“.
Statické testy tedy považuji za jednu z velmi efektivních cestu, jak eliminovat produktová rizika už v začátcích projektu. Tyto testy umožňují taky včasné a aktivní zapojení testingu do celého průběhu SDLC (Software Development Life Cycle) a nejen do jeho závěrečné fáze. Proto je doporučuji použít u všech projektů, speciálně pak u těch, kde nemáme dostatečné zadání (produktové riziko).
Pro rekapitulaci - základní principy testování podle ISTQB:
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ů
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