V testování software se objevuje hodně názvů i přístupů, což často nastolí nepochopení a nedorozumění, co a kdy se vlastně testuje, co má být správným výsledkem konkretního testování. Vezmeme testerskou lupu a jednotlivé případy prozkoumáme podrobněji.

Testovaní se dá zajisté dělit dle mnoha kritérií. Pokud nevíte, co testování softwaru je, přečtěte si nejdřív článek Co je testování softwaru. Pokud vás zajímá, jakým způsobem se dá software testovat, přečtěte si článek Jak testovat software.

Podle fáze vývoje

• Statické testy – tyto testy se provádí ještě před spuštěním kódu. Cílem je analyzovat kód a identifikovat potenciální problémy, které by mohly způsobit chybu, selhání nebo jiné nežádoucí chování ve výsledku. Pokud se provádí pomocí analyzátoru kódu, označuje se pojmem statická analýza kódu. Pokud jej dělá člověk (např. druhý programátor), označuje se pojmem review nebo code review.
• Unit testy – přichází na řadu nejdříve. Píší je obvykle přímo programátoři a jedná se o základní prvky pro ověření kódu a jeho funkčnosti. Ověřuje se jednotka (unita). Testy jsou automatizované. Například TDD se bez nich neobejde. Zásadní jsou ale pro všechny metody vývoje a zajištění kvality na SW projektu.
• Komponent/Modul testy – jsou stále spíše doménou programátorů. Jejich využití je především na velkých projektech, kdy se snažíme ověřit funkčnost nějaké komponenty nebo modulu. Často se od unit testů moc neliší. Odlišnost spočívá spíš v rozsahu – Modul testy představují testy např. celé knihovny. Komponent testy zase testují celou komponentu.
• Integrační testy – tvoří je obvykle testeři poté, co programátoři skončí svou práci, a je třeba ověřit, zda jednotlivé moduly/komponenty fungují dohromady. Patří mezi ně také API testy, které se u těchto testů často používají.
• Funkční/E2E/GUI testy – funkční testování obvykle zkoumá, co systém dělá. Funkční testování neznamená, že testujete funkci (metodu) modulu nebo třídy. Testuje část funkčnosti celého systému. Zásadním je tedy uživateský pohled.
• Systémové testy – z pohledu hierarchie se jedná o nejvyšší úroveň testování, která se provádí ještě ve vývojovém týmu. Jejich cílem je ověřit, zda systém jako celek funguje dle požadavků a očekávání zákazníka.
• Akceptační testy – jsou realizovány na straně zákazníka. Jejich cílem je ověřit, že produkt splňuje očekávané funkce a kvalitu.

Podle znalosti kódu:

• White Box – pokud jsou testy psané na základě znalosti kódu. Typickým představitelem jsou Unit testy.
• Black Box – na SW se díváme, jako by se jednalo o černou skříňku. Zajímá nás pouze, jak reaguje. Na základě konkrétních vstupů sledujeme výstupy. Typickým představitelem jsou např. funkční a akceptační testy.
• Gray box – v praxi pak často testeři píší testy, které se opírají o částečnou znalost kódu nebo architektury, těm se pak říká Gray box testy.

Podle dimenzí kvality:

Dimenze kvality jsou definované normou ISO/IEC 25010:2011 a slouží nám především k pochopení, že testovat jen funkce je nedostatečné a tedy, že pohledů na kvalitu je více.

• Funkčnost (Functionality) – správné chování funkcí systému, jak je definováno funkční specifikací (funcspec, FS).
• Výkon (Performance) – zda systém není pomalý a zvládne větší množství současně pracujících uživatelů, anebo naopak zda si i při naplnění všech požadavků na obsluhu uživatelů nebere příliš systémových zdrojů.
• Kompatibilita (Compatibility) – možnost kombinace s jiným softwarem nebo hardwarem,
• Použitelnost (Usability) – zda vůbec a jak lze dosáhnout požadovaného cíle, zda je systém uživatelsky přívětivý, zda se s ním dobře pracuje: i když se SW chová podle uživatele „špatně“, může stále jít o „správné chování“ podle FS, pak jde ovšem o chybu samotného FS a smlouvy, kterou je vázán.
• Spolehlivost (Reliability) – zda se chová stejně za všech okolností, zvláště po přetížení, po výpadku či chybě, zda tyto stavy umí detekovat a hlásit.
• Bezpečnost (Security) – jsou oddělené přístupové role, není možné se dostat do systému bez správného hesla
• Udržitelnost – dá se systém upgradovat, testovat, je modulární tedy můžeme vyměňovat jednotlivé části
• Přenositelnost – nakolik je aplikace schopná fungovat na jiném HW, na jiných OS

Podle způsobu realizace testů:

• Manuální – jedná se o testy prováděné přímo testerem podle testovacích případů (testcase). V dnešní době je již ve spoustě oblastech na ústupu a je nahrazováno automatizovaným testováním. Stále má ale své nenahraditelné místo v některých oblastech (např. exploratory testování).
• Automatizované – automatizace je hnacím pohonem pokroku, a tedy i v testování zažívá v posledních letech enormní nárůst. Automatizace je často prováděna pomocí skriptovacích jazyků (např. Python) a jejím cílem je ověřit opakující se scénáře za pomoci krátkých programů. Více se tomu budu věnovat v článku o automatizovaných testech.
• Exploratory testy – je to v podstatě manuální testování. Liší se ale způsobem a záměrem. Testy se na rozdíl od manuálního testování neprovádějí podle předem popsaného scénáře – jejich cílem je prozkoumat, jak se testovaný SW chová. Tedy zjistit jeho vlastnosti a funkce. Použití tohoto způsobu je často na začátku agilního cyklu.

Podle rozsahu

• Smoke testy – používají se k základní kontrole funkčnosti aplikace. Očekává se, že se provedou v krátkém čase. Jejich počet je tedy malý. Tyto testy se běžně provádí např. po aktualizaci softwaru, aby se zjistilo, zda jsou všechny hlavní funkce softwaru stále funkční. Smoke testy by měly ověřit, zda je software v základu funkční
• Regresní testy –  jsou to testy, které se zaměřují na zjišťování, zda nová část softwaru nenarušila funkčnost starších částí. Cílem regresních testů je zjistit, zda aplikace stále funguje stejně jako předtím. K tomu se používají staré testovací scénáře, které jsou přezkoumány po aktualizaci softwaru. Velice zjednodušeně by se dalo řicí, že se jedná o všechny testy.

Příště se dozvíte o technikách testování software.