Základní principy testování dle ISTQB: Včasné testování

Minule jsem se věnoval principu pesticidního paradoxu, dnes se podívejme na princip včasného testování.

Základní principy testování dle ISTQB: Včasné testování


1. díl článku: Základní principy testování podle ISTQB: Pesticidní paradox

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!

Úvodní foto: © kentoh - Fotolia.com










Komentáře