Definice celkového přístupu k testování udává směr všem činnostem v rámci testování. Specifikuje úrovně testování, které jsou plánem testování pokryty, což v této metodice bude převážně pouze úroveň systémových testů. Dále definuje jeden nebo více přístupů, které budou následovány při výběru a prioritizaci testů, určuje typy testů, které budou prováděny, techniky pro návrh testů a mohou zde být uvedeny také nástroje pro automatizaci testů, příp. jiné nástroje pro podporu procesu přípravy a provádění testů.

S definicí přístupu k testování souvisí i definice vstupních a výstupních kritérií procesu testování.

Vstupní kritéria definují, kdy je možné zahájit danou úroveň testování, nebo kdy je sada testů připravena na spuštění. Typicky jsou vstupní kritéria zaměřena na pokrytí

·     dostupnosti a připravenosti testovacího prostředí a nástrojů pro testování,

·     dostupnosti kódu, který již může být otestován,

·      dostupnosti testovacích dat. [ISTQB, 2011, s. 49]

Následují některé typické příklady vstupních kritérií pro úroveň systémových testů [Black, 2002, s. 55]:

·      Jsou připraveny nástroje pro řízení testování a zaznamenávání nalezených defektů.

·      Vývojový tým dokončil vývoj všech požadovaných vlastností systému a opravil všechny defekty plánované pro danou release.

·      Vývojový tým provedl jednotkové testy všech požadovaných vlastností a opravených defektů pro danou release.

·      Provozní tým provedl konfiguraci testovacího prostředí, včetně všech hardwarových komponent a subsystémů a poskytnul testovacímu týmu přístupy do těchto systémů.

·      Testovací tým má připravena testovací data.

Výstupní kritéria definují, kdy je možné uznat testování za dokončené nebo kdy sada testů splnila stanovený cíl. Jsou obvykle napasována na

·      metriky, jako je pokrytí kódu, funkcionality nebo rizik,

·      odhady hustoty defektů [1] dané komponenty nebo systému,

·      zbývající rizika v dané oblasti jako jsou dosud neopravené defekty nebo chybějící pokrytí dané oblasti testy,

·      náklady,

·      harmonogram – zejména tam, kde prioritou projektu je rychlé uvedení produktu na trh. [ISTQB, 2011, s. 50]

Následují některé typické příklady výstupních kritérií pro úroveň systémových testů [Black, 2002, s. 56]:

·      Testovací tým provedl všechny plánované testy.

·      Vývojový tým vyřešil všechny defekty s nejvyšší závažností a prioritou.

·      Testovací tým zkontroloval, že všechny defekty v nástroji pro správu defektů jsou vyřešeny a retestovány, nebo odloženy do další release, nebo byly schváleny jako permanentní omezení a dále se řešit nebudou.

·      Metriky testování ukazují, že bylo dosaženo stabilního a spolehlivého produktu, jelikož byly dokončeny všechny plánované testy a tyto plánované testy pokrývají všechna kritická rizika kvality produktu.

·      Projektový manažer odsouhlasil, že systémové testy byly dokončeny.

Výstupní kritéria mohou být rozdělena na kritéria, která „musí“ být splněna a kritéria, které „by měla“ být splněna, což je důležité zejména pro vyhodnocení výsledků testování, viz úloha vyhodnocení výstupních kritérií.

Zvolený přístup k testování na projektu, resp. kombinace několika přístupů, prostupuje celým procesem testování, pomáhá určit priority a pořadí různých aktivit testování a řídí se podle něj i výběr a priority jednotlivých testů.

Při použití přístupu k testování založeném na rizicích [ISTQB, 2012a, s. 9] jsou aktivity a testy zaměřeny na maximální pokrytí identifikovaných rizik. To znamená, pokud je například vysoká pravděpodobnost ohrožení závažnými bezpečnostními defekty, testování by se mělo zaměřit na bezpečnostní testy. Obdobně pokud je rizikem výkon systému, tak by se měl testovací tým zaměřit na výkonnostní testy a to, pokud možno, co nejdříve je k dispozici kód pro otestování.

Kromě přístupu k testování, který je založen na rizicích, ale existují i jiné přístupy.

Pokud je k dispozici kvalitní specifikace požadavků, ideálně včetně priorit jednotlivých požadavků, je možné využít přístupu založeného na požadavcích [ISTQB, 2012a, s. 30]. Ten může být dále doplněn vytvářením provozních profilů a profilů užití systému nebo přístupem založeným na modelech (např. UML modely, procesní modely nebo datové modely), což pomáhá k pochopení, jak se bude daný systém ve skutečnosti používat [ISTQB, 2012a, s. 30].

Jedním z možných přístupů je také reaktivní přístup [ISTQB, 2012a, s. 31]. To znamená nejvíce času a úsilí je věnováno provádění testů, kdežto analýza, návrh a implementace testů jsou značně omezeny. Testovací tým se soustředí na produkt, který je aktuálně nasazený na testovacím prostředí a snaží se najít co nejvíce defektů. Následně se testování soustředí zejména na oblasti, kde je defektů nejvíce a méně na oblasti, ve kterých je defektů málo. Použití výhradně tohoto přístupu je ovšem zrádné, protože může opomenout důkladné otestování některých důležitých oblastí, ve kterých se zdá, že je defektů málo, ale přitom právě tyto defekty a další dosud neobjevené defekty mohou mít zásadní dopad na uživatele systému.

Nelze říci, který z přístupů k testování je nejvýhodnější, protože každý má své výhody a omezení. Výběr přístupů, které budou při testování používány, závisí na kvalitě podkladů pro testování, na modelu životního cyklu vývoje softwaru, ale i na časových a nákladových omezení testování na projektu.

Testy lze rozčlenit dle účelu na následující typy [Doležel, 2013c]:

·     testy funkcionality,

·     testy nefunkcionálních charakteristik kvality,

·     testy v souvislosti se změnami, tj. například

o   testy pro potvrzení správnosti oprav defektů (retesty),

o   testy pro potvrzení, že při změnách v kódu nejsou dotčené i části systému, které neměly být měněny a před změnami fungovaly korektně (regresní testy).

Jako pomůcka při určení prováděných typů testů může sloužit metoda FURPS, která se zaměřuje na ověřování funkcionálních [2] (funkcionalita) i nefunkcionálních [3] (použitelnost, spolehlivost, výkonnost, podporovatelnost) charakteristik kvality:

·      Funkcionalita (Functionality) je dle [Faustová, 2009, s. 11] definována jako „schopnost softwaru zabezpečit za předem stanovených podmínek určité funkce“. Do funkcionálních testů se dle [IBM, 2005] zahrnuje testování sad funkcí systému, scénářů použití systému a testování bezpečnosti.

·      Použitelnost (Usability) je dle [Faustová, 2009, s. 11] definována jako „míra úsilí, které musí uživatel vynaložit, aby mohl software používat ke stanoveným cílům za stanovených podmínek“. Testy použitelnosti se dle [IBM, 2005] zaměřují na lidské faktory, estetiku, konzistenci uživatelského rozhraní, online a kontextovou nápovědu, školící materiály a uživatelskou dokumentaci.

·      Spolehlivost (Reliability), někdy překládána též jako bezporuchovost, je dle [Faustová, 2009, s. 11] definována jako „schopnost softwaru být za daných podmínek používán, bez toho, aby došlo k jeho výpadku či chybě“. Pro efektivní testování spolehlivosti jsou zapotřebí specializované nástroje. Do testů spolehlivosti se dle [IBM, 2005] řadí testy integrity, testy struktury, stress testy, testy konfliktů a kapacitní testy.

·      Výkonnost (Performance) je dle [Faustová, 2009, s. 11-12] definována jako „schopnost softwaru poskytovat požadovaný výkon vzhledem k použití stanovených zdrojů za stanovených podmínek“. Do výkonnostních testů se dle [IBM, 2005] zahrnují testy výkonnostních profilů, benchmarking testy a zátěžové (load) testy.

·      Podporovatelnost (Supportability) je dle [Faustová, 2009, s. 12] „kritériem o přenositelnosti vyvíjeného softwaru do různých prostředí“. Do tohoto typu testů dle [IBM, 2005] spadají testy instalací a konfigurací.

Techniky návrhu testů jsou vodítkem, co se přesně bude testovat, tedy pro co budou připraveny testy. Technik návrhu testů je celá řada a využívají se při identifikaci testovacích podmínek, při přípravě testovacích případů i při přípravě testovacích dat. Základní způsob kategorizace technik rozlišuje techniky černé skříňky a techniky bílé skříňky [ISTQB, 2011, s. 39].

Techniky černé skříňky jsou založené na analýze podkladů pro testování a zahrnují funkcionální i nefunkcionální testování. Při návrhu testů technikami černé skříňky se nepoužívají informace týkající se vnitřní struktury komponenty nebo systému a daná komponenta či systém je zkoumána pouze skrze jeho vstupy a výstupy. Do této skupiny technik se řadí rozdělení tříd ekvivalencí, analýza hraničních hodnot, testování rozhodovacích tabulek, testování přechodů stavů a testování založené na případech užití nebo testování založené na příbězích užití.

Techniky bílé skříňky jsou naopak založené na analýze vnitřní struktury komponenty nebo systému. Do této skupiny technik se řadí testování příkazů, testování větví a testování rozhodovacích podmínek.

Techniky černé a bílé skříňky mohou být dále efektivně kombinovány s technikami založenými na zkušenostech a s technikami založenými na defektech.