Testování softwaru je empirický technický výzkum kvality testovaného produktu nebo služby prováděný za účelem poskytnout získané informace všem zainteresovaným (=stakeholdrům). Testování tedy představuje zejména hledání určitých informací o daném produktu zkoumáním daného produktu.

Proces testování je podmnožinou procesu ověřování a plánování kvality. Proto mohou být úkoly testovacího týmu dosti široké a na modelech životního cyklu pozorujeme, že testovací disciplína se nejen protahuje do celého vývoje, ale často nahrazuje zajišťování kvality.

Součástí zjišťování informací o kvalitě je reportování nalezených problémů – softwarových chyb. Proces testování začíná stanovením vize a cílů testování. Dále se určí záběr testování, tedy co vše je třeba testovat, vybírají se testy, sbírají data a připravují nástroje, které tým k testování potřebuje. Navíc se kontroluje, zda všechny požadavky na produkt jsou ve formě, aby bylo možno jednoznačně zkontrolovat jejich splnění. Samotné testování probíhá zkoumáním produktu na několika úrovních a reportováním nalezených skutečností. Proces testování se často provádí ve více iteracích, přičemž každá iterace začíná předáním nové verze produktu testům.

Ohodnocení testu Každý test optimálně dává ve výsledku (po provedení testu) dvě hodnoty: v pořádku, v souladu s funkční specifikací (dále FS) / špatně, není v souladu s FS (anglicky Passed / Failed, též zkráceně pass / fail). Toto ohodnocení vychází z porovnání pozorovaného chování s požadavky ve FS, která je přímo navázána na obchodní smlouvu.

V ideální situaci by testování dávalo dvě ohodnocení pro dvě možnosti jevu, kartézským součinem tedy dostaneme čtyři možné situace jednoho případu užití: OhodnocenítestuSledovaný jevnastalnenastalJevdle FSpřikázán A správně B špatnězakázán C špatně D správně Prvotním, ale ne posledním úkolem testera tedy je navštívit všechny požadované výchozí situace, zjistit zda jsou vůbec dosažitelné, a z nich dále ověřit, že popsané požadované chování skutečně pozoruje: To je minimální, ale ne postačující požadavek, aby se výsledná aplikace dala prohlásit za „správnou“ a funkční a dala se nabídnout zadavateli k převzetí (release candidate).

Chyby testů Chybný test je takový provedený test, který dal opačný výsledek, než by fakticky měl. false positive – falešné potvrzení správné funkce: Ačkoli fakticky dochází k selhání, toto není detekováno/hlášeno, test selhává neodmítnutím špatného. Může být projevem nadměrné důvěřivosti. false negative, též falešný poplach () – falešné hlášení chybné funkce: Ačkoli fakticky dochází ke splnění testovaného akceptačního kritéria, toto není detekováno/hlášeno, test selhává nepřijetím správného. Může být, lidově řečeno, „sýčkováním“ bez hrozby na dohled, projevem nadměrného skepticismu.

Omezení při testování Softwarovým testováním není možno zajistit naprostou bezchybnost systému z toho důvodu, že nelze reálně nasimulovat nekonečné množství vstupních hodnot a následně zkontrolovat nekonečné množství výstupních hodnot. Ani otestování všech možných cest programem není většinou reálné. Testování je tak velmi efektivní způsob, jak ukázat přítomnost chyb, není ale možné tak dokazovat jejich nepřítomnost. Absenci chyb může ukázat jen formální důkaz, což ale kvůli náročnosti není v praxi použitelná metoda.

Mezi další problémy, se kterými je třeba počítat a vypořádat se s nimi, patří: Není možné otestovat kompletně všechny možné případy zadání. Je velmi složité odhalit, že bylo ve specifikaci na něco zapomenuto. Specifikace není vždy jednoznačná nebo dokonce chybí. Testování bývá podceňováno nebo špatně pochopeno. Výsledky testování mohou být ovlivněny špatnou komunikací v týmu nebo se zákazníkem. Testování musí být přizpůsobeno testovanému produktu, není možné stejným způsobem otestovat různý software. V průběhu testování se mohou stát některé testy neefektivními. Testy je nutné neustále přizpůsobovat měnícím se okolnostem. Dvě různé chyby se mohou navenek projevovat stejně, nebo jedna chyba se může navenek projevovat různě. Testování je citlivé na vstupní data, ta by měla být realistická. Vygenerování jednotvárných dat není optimální.

Pozitivistická specifikace Zadavatel definuje bod svého zájmu, od něj se odvíjející oblast se pak dále rozšiřuje: Pro ni se pak říká, jak se aplikace má nebo nemá chovat. Ale protože je prostor případů definován jen takto zevnitř, může se prostor všech potenciálních případů, a tedy i množství případů k otestování, zvětšovat donekonečna. FS může pokrývat jen hlavní funkcionalitu a její případy, liší se jen míra, do jaké hloubky je rozebírá: Vždy lze nalézt případ, který FS nepokrývá, stačí jen zajít dostatečně daleko v kombinování různých možných vlivů.

Je tedy nutno určit práh, které komplikovanější případy už aplikace nemá pokrývat. Toto „omezení shora“ neurčuje klient, pro toho je žádoucí co nejkomplexnější řešení, pokrývající maximum případů (za stejnou cenu). Omezení oblasti vývoje (scope) má určit obchodník při vyjednávání, nebo alespoň následně projektový tým při rozpracovávání zakázky, a toto své rozhodnutí poskytnout všem zainteresovaným: Především programátorům a testerům. To však v praxi nebývá zvykem, je tedy na zodpovědnosti každého, aby si hloubku své práce určil sám: Tester si tedy určuje, které z možných, a ačkoli nepožadovaných, stále potenciálně hrozících scénářů vůbec nenavštíví a nebude prakticky testovat.

Nemožnost kompletní specifikace Kromě explicitně určených případů užití však mohou existovat i další případy, které jsou nutné pro funkčnost systému a tester je musí také navštívit a ověřit. Nejprve je však třeba je vůbec nalézt: I to je na zodpovědnosti testera. Všechny takovéto další nutné případy se pak také stávají nutnými pro samotné prohlášení aplikace za „funkční“.

Toto hledání, ač implicitních, stále nutných případů sice často dělá analytický tým projektu, nakonec si je ale tester často nachází znovu a ještě podrobněji (třeba i proto, že k analytikům nemá přístup). Rozsah, jak daleká zákoutí vzájemného ovlivňování se jednotlivých funkcionalit chce tester pokrýt si určuje sám, podle svých zkušeností a schopností: Lze si určit příliš mělký záběr, kdy se prakticky ověřují jen hlavní případy užití aplikace, nebo i příliš hluboké případné kolize vlivu tří a více funkcionalit na jediném případu. Hloubku záběru je třeba řídit podle zbývajícího času přiděleného dané etapě projektu.

Pro určení plánu postupného testování nepotřebuje funkční SW, jde jen o práci nad dokumentací, proto lze testovací scénáře připravit i ještě dříve, než vůbec začne implementace. Současná detailní znalost problému a dva různé pohledy se dobře projeví při prohlídkách dílčích řešení (Feature falk through) v developerském oddělení: Některé potenciální defekty lze podchytit ještě než nastanou nebo v samém jejich zárodku, což šetří náklady na jejich dodatečné opravy. Řešení případů, na kterých se takto programátor a tester dohodnou, se opět stávají závaznými požadavky na výsledný produkt.

Neformalizované zadání Klienti zpravidla popisují své požadavky pomocí pravidel: Když A, pak X. Ale když B, tak Y. Na jedné straně se takový způsob jeví intuitivní, na druhé ho lze dobře formalizovat pomocí produkčních pravidel, teorie množin a predikátové logiky. V praxi ani klienti ani obchodníci svá zadání neformalizují, výsledné požadavky pak předpokládají nevyřčená chování, nebo hůře pro některé možné vstupy neurčují výstupy nebo ani vstupy neurčují všechny, ačkoli jsou možné.

Praktickým důsledkem pak mohou být případy, kdy: je sice řečeno chování pro vybrané možnosti vstupů, ale zůstávají i možné vstupy, pro které chování popsáno není, nebo popis vstupů třeba i pokrývá všechny možné hodnoty, ale už ne situaci, kdy vstup není dán vůbec.

Neurčenost výsledku Jde o případ, kdy FS určuje chování jen pro část ze všech teoreticky možných situací (kartézsky, podstrom). V příkladě níže je tedy explicitně dán požadavek na situace A a D. Další možnosti však přímo neurčuje. V takovém případě lze analýzou (testováním dokumentace) dojít k několika výsledkům: Příklad ukazuje, že se z dalšího kontextu FS dospělo k závěru, že možnost E+F je díky jiným souvislostem vyloučena. To byl pravděpodobně také důvod, proč si FS dovolil tento případ explicitně neuvést. Protože tohoto stavu nelze dosáhnout a pozorovat výsledek, tento případ tím pádem odpadá z testování. Náročnější je případ G, který opět může vyplývat z kontextu funkcionality. Ač ve FS nemusí být přímo vyslovený, je nutným požadavkem na funkčnost systému, a jako takový by měl být samostatně otestován.Někdy u těchto požadavků může z dalšího kontextu také vyplynout, že nejsou nezávislé, ale tautologicky přebírají (kopírují) hodnotu z jiného, už otestovaného případu: Pak se na opětovném přetestování nemusí trvat, ale v seznamu testů by měl být případ ponechán: Teď je sice tato apriorní informace známa (white box), ale s dalším vývojem v budoucnu se mohou souvislosti změnit. Nejhorší možnost by se mohla týkat opět situace G z příkladu: Pokud se povede identifikovat takový případ za dosažitelný, je ho nutno otestovat, tedy pozorovat a pak vyhodnotit. Ale pokud FS tuto situaci nijak nespecifikuje (neříká, co je správně), jde o chybu FS. Nalezení takové chyby ještě před začátkem implementace je vždy levnější než její nalezení např. během testu funkcionality (feature testu). Řešení pak podá buď projektový manažer, klientský konzultant, nebo v nejhorším případě sám klient, například dodatkem smlouvy.

FS určuje chování jen pro část ze všech teoreticky možných situacíSledovaný jevnastalnenastalPodmínkadle FSnaplněnaJevdle FSpřikázán A správně B špatnězakázán C špatně D správněnenaplněnaJevdle FSnedefinován, ale z kontextu:nedosažitelný E + F, nedosažennepozorovánnedefinován, ale z kontextu:implicitně předpokládán G správně H špatně

Tříhodnotová logika

I když třeba FS pokrývá kompletní množinu vstupních hodnot a definuje k nim výstupy, stále ještě může nastat situace, kdy od funkcionality požadujeme výsledek, a není k dispozici žádný vstup. Triviálním příkladem může být dotaz do databáze: Podívej se na klienta XYZ a zjisti mi, zda je to muž. Ačkoli u takového zadání FS může předpokládat jen dvě hodnoty (když ne explicitně muž, pak implicitně žena), prakticky však ještě přichází v úvahu odpověď nevím (NULL), pokud dotazovaná hodnota v DB není výslovně vyplněna. Pak však záleží na aplikaci a jejím FS, aby se zamlčené předpoklady určily, jaké chování je „správné“, tedy jaké si přeje klient.

Etapy testování Stadia projektu Z hlediska postupných aktivit SW projektu lze mluvit o třech fázích, které každá vyžadují jiná testování, co do formy, předmětu i účelu testování: Zahajovací fáze: testování dokumentace, bez funkčního kódu, ověřování případů užití, produkční fáze: testování nových funkcionalit, testování celého řešení podle FS k odevzdání, dokončovací fáze a předávání: testování celého produktu, testování instalačního balíku produktu a upgradů.

Situace bývá znepřehledněná i tím, že firma musí své (nejen lidské) zdroje využívat efektivně, tedy nelze čekat, až nastane taková etapa, aby se ten který specializovaný tester uplatnil: Jednotlivé fáze se mohou překrývat přes různé verze produktu, navíc se souběžně mohou testovat i různé produkty.

Stadia vývoje Na základě toho, v jakém stadiu vývoje se testování provádí, v jakém časovém horizontu od napsání kódu, se testování dělí na pět stupňů: testování programátorem (Developer's Unit testing), sám si testuje metody svých objektů nebo funkce skriptů, testování funkcionalit (Feature testing), ověřování úzce zaměřených scénářů, tedy již z pohledu uživatele, bez znalosti kódu,