Testování SW

V tomto příspěvku se dozvíte, proč testovat SW, co je cílem testování SW, jaká je závislost mezi kvalitou SW, testováním SW a počtem chyb a kdy začít s testováním SW.

Proč testovat? Vývoj SW se stále zrychluje, požadavky na kvalitu jsou minimálně stejné, ne-li vyšší než tomu bylo před lety. Testování SW tak nabývá stále na větším významu, protože čím dříve se chyby odhalí, tím nižší jsou náklady na jejich odstranění. Testování SW se stává nedílnou součástí životního cyklu vývoje software (SDLC – Software Development Life Cycle).

Co je cílem testování? Cílem testování obvykle bývá ověřit, že SW dělá přesně to, co je uvedeno ve specifikaci a dále jak je schopen se vyrovnat s nestandardními stavy, jak reaguje na chybu uživatele nebo chybu v datech, selhání jiné SW nebo HW komponenty, jak se vypořádá se zátěží a nedostatkem systémových zdrojů, zda se dokáže zotavit po havárii, zda je odolný vůči útokům, jak funguje na různých HW a SW konfiguracích, atd.

Je třeba mít neustále na paměti, že to, že se během testování neobjevila žádná chyba a všechny testy byly úspěšné, neznamená, že SW žádné chyby neobsahuje. S velkou pravděpodobností nějaké obsahuje, ale jen se na ně nepřišlo. To je dáno tím, že SW stejně jako testy dělají lidé a lidé jak známo chybují. Odhalené množství chyb je tak značně závislé na kvalitě vývoje a kvalitě testování. V praxi tak může dojít k tomu, že:

• kvalita SW i testů je vysoká, lze předpokládat, že bude odhaleno jen malé množství chyb, ale pár jich produkt přesto může obsahovat;
• kvalita SW je vysoká, naproti tomu kvalita testů je nízká, lze předpokládat, že bude odhaleno méně chyb než v předchozím případě;
• kvalita SW i testů je nízká, lze předpokládat, že bude odhaleno jen malé množství chyb, přestože produkt jich bude obsahovat velké množství;
• kvalita SW je nízká, naproti tomu kvalita testů je vysoká, lze předpokládat, že bude odhaleno velké množství chyb.

To, že je SW nebo testování kvalitní, je často založeno jen na naší víře a přesvědčení. Můžeme se tak mylně domnívat, že nízký počet odhalených chyb je dán vysokou kvalitou SW a testování. Opak však může být pravdou, SW obsahuje plno chyb, ale z důvodu nízké kvality testování jich bylo odhaleno jen pár.

Kdy začít psát testy? Psát testy můžeme začít ještě dřív, než začneme programovat a to v okamžiku, kdy máme k dispozici SRS (Software Requirements Specification) dokument. Testy tak můžeme založit na požadavcích uvedených SRS. Vycházíme z jednoduchého předpokladu, že když se vyvíjí nějaký SW, vždy existuje nějaká specifikace toho, co by měl SW dělat. K dispozici tak většinou máme již na samém počátku vývoje seznam funkčních a nefunkčních požadavků. Na jejich základě můžeme vytvořit testovací případy a scénáře pro manuální i automatizované testy. Ostatní často uváděné dokumenty pro psaní testů jako je instalační příručka (Installation guide), příručka operátora (operator guide) a uživatelská příručka (user guide), vznikají až během vývoje nebo v jeho poslední závěrečné fázi, ale to už můžeme mít většinu testů připravených a naplánovaných.

V článku nazvaném Způsoby testování jsme si testy rozdělili podle přístupu k informacím nutným k provedení testů na white box, black box a grey box. V článku Typy testů jsme si testy rozdělili pro změnu podle V-modelu. Testy však můžeme rozdělit i podle subjektu, který je provádí. V takovém případě můžeme testy rozdělit na testy prováděné:

• dodavatelem, který obvykle provádí testy unitní, integrační a systémové a
• odběratelem, který obvykle provádí testy akceptační.

Další dělení může být podle způsobu provedení, můžeme tedy mít testy:

• automatizované – jejich výhodou je, že jsou rychlé, lze otestovat větší množství vstupních dat, lze je snadno a s minimálními náklady zopakovat, výsledky testu se zapisují do logu, některé testy se v podstatě ani jinak než automatizovaně dělat nedají (např. zátěžové testy). Jejich nevýhodu je, že je nutné je naprogramovat a to něco stojí.
• manuální testy – jejich nevýhodou je, že jsou pomalé, nelze jimi otestovat velké množství vstupních dat, každé opakování je prodražuje, vše je třeba ručně zapisovat. Na druhou stranu se nemusí nic programovat, a některé testy ani jinak než manuálně provést nelze (např. test použitelnosti).

Aby naše dělení bylo úplné, nesmíme zapomenout na:

• statické testování – prohlíží se zdrojový kód SW a hledají se v něm chyby,
• dynamické testování – chyby se hledají za běhu SW.

K testování SW je vhodné přistoupit jako k jakémukoliv jinému projektu. Celý projekt lze rozdělit do 4 hlavních částí:

• Příprava na testování – v této fázi vznikají obvykle tyto dokumenty: testovací plán, testovací scénáře a testovací případy.
• Provedení testů – v souladu s testovacím plánem pak probíhají vlastní testy podle testovacích scénářů.
• Vyhodnocení testů – pokud by se vyhodnocování neprovádělo, tak by testování ani nemělo smysl.
• Rozhodnutí o dalším postupu – zopakování některých testů apod.

V rámci testování SW lze identifikovat tyto role:

• Test designer – zodpovědný za přípravu testů, vytváří testovací scénáře, logické a fyzické testovací případy a rozhoduje o tom, jaká budou testovací data.
• Test manager – zodpovědný za plánování, organizovaní, koordinování a reportování stavu testování.
• Test executor – zodpovědný za vlastní provedení testů, dokumentuje výsledky testů, kontroluje logy a hlásí defekty.
• Defect solver – nejčastěji to bývá vývojář, kdo řeší defekty.

Dále je nutné definovat závazná pravidla pro tvorbu názvů dokumentů, které by měly v průběhu testování vzniknout. V některém z příštích článků si povíme, co je to plán testování, testovací scénář, testovací případ, testovací skript, protokol o předání SW k testování, testovací log, test incident report a test status report.

Štítky: Testování SW

Diskuse na tomto webu je moderována. Pod článkem budou zobrazovány jen takové komentáře, které nebudou sloužit k propagaci konkrétní firmy, produktu nebo služby. V případě, že chcete, aby z těchto stránek vedl odkaz na váš web, kontaktujte nás, známe efektivnější způsoby propagace.