====== Techniky návrhu testovacích scénářů, jednotkové testy, automatické funkční testy, testovací strategie, testovací data ====== [[https://moodle.fel.cvut.cz/course/view.php?id=9341|B6B36TS1]] - Organizace testování, typy testů, V-model a W-model. - Určení vstupních dat do testů: Mezní podmínky, třídy ekvivalence. - Určení vstupních dat do testů: Párové testování, kombinatorické testování. - Vytváření testovacích scénářů: Procesní testy - model problému, jak vypadá testovací scénář, kritérium pokrytí Test Depth Level, vytváření testů. - Vytváření testovacích scénářů: Testy konzistence dat - model problému, jak vypadá testovací scénář, vytváření testů. - Způsoby vytváření testovacích dat. - Jednotkové testy: princip testu, vlastnosti, které má mít jednotkový test, odlišnosti proti integračním testům. - Automatizované testy založené na simulaci akcí uživatele v uživatelském rozhraní systému: princip testu, příklad technologie, rozdíl oproti jednotkovým testům. - Testovací strategie: princip metody Business Driven Test Management, její základní části a jejich souvislosti. ===== Organizace testování ===== **Organizace testování, typy testů, V-model a W-model. ** **Proč testovat software** - člověk zanese chybu, která způsobí selhání systému => Defekty je potřeba najít, než se systém začne používat. **Terminologie** - obecně nejednotná - v předmětu dle ** ISTQB foundation level ** sylabu a ** TMAP Next **, tak aby nepřekrývala ISTQB standard **Verifikace** - Proces vyhodnocování, jestli produkt konkrétní vývojové fáze odpovídá požadavkům na tento produkt definovaným na začátku této fáze. **Validace** - Vyhodnocování software v průběhu nebo na konci jeho vývoje, jestli software odpovídá zadaným požadavků. === 7 základních principů testování === - **Testování ukazuje přítomnost defektů** - Testování může ukázat, že jsou defekty přítomny, ale nemůže dokázat, že v softwaru nejsou žádné defekty. - **Vyčerpávající testování je nemožné** - Testování všeho (všech kombinací vstupů a vstupních podmínek) není realizovatelné s výjimkou triviálních případů => musí se stanovit priority - **Včasné testování** - 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. - **Shlukování defektů** - Malé množství modulů obsahuje většinu defektů zjištěných v průběhu testování před uvolněním, nebo je zodpovědné za nejvíc provozních selhání. - **Pesticidní paradox** - Jsou-li stále opakovány tytéž testy, časem stejný soubor testovacích případů nenalezne žádné nové defekty => Je potřeba existující testovací případy pravidelně revidovat a upravovat a je potřeba napsat nové, odlišné testy - **Testování je závislé na kontextu** - Testování je vykonáváno odlišně v různých kontextech (Bezpečnost, Acessibility,..) - **Falešná představa o neexistenci omylů** - Nalezení a opravení defektů nepomůže, pokud je vytvořený systém nepoužitelný a nesplňuje potřeby a očekávaní uživatelů. ==== Typy Testů ==== Typy testů se dají kategorizovat podle několika různých pohledů: - **Podle test levels:** * Vývojářské testy * Integrační testy * Systémové testy * Uživatelské akceptační testy - **Podle technického postupu testu nebo charakteristiky kvality systému:** * Unit testy kódu * Funkční testy * E2E (end-to-end) testy * Zátěžové testy * Penetrační testy * Testy provozuschpnosti na platformě * Crash testy a testy zotavení systému - **Podle znalosti vnitřní struktury:** * Black-box testing * White-box testing * Grey-box testing - **Podle toho, kdo a kde testuje:** * Alfa testy * Beta testy ==== V-model ==== {{statnice:bakalar:ts1v.png?700}} **Test Basis** - Definice dle ISTQB: Dokumentace, na jejíž základě jsou vytvářené testovací scénáře. Zde je to část V směřující dolů ('\') **Test Level** - Skupina testovacích aktivit, které jsou organizované a řízené jako jeden blok. Má svůj samostatný cíl. Zde část V směřující vzhůru ('/') === Nevýhoda V-modelu === ** Bohémův zákon ** - Chyby jsou nejčastější ve fázích požadavků a návrhu a čím později odhalíme chybu v průběhu vývoje systému, tím je dražší Přesně to se děje u V modelu, resp. drahé chyby způsobené špatnými požadavky odhalujeme až ke konci testování. {{statnice:bakalar:ts1vbad.png?700}} ==== W-model ==== * Každé fázi přípravy systému odpovídá kontrolní fáze * V praxi levnější než předělávání a opravy na poslední chvíli, ale vyžaduje počáteční investici, proto není příliš rozšířený {{statnice:bakalar:ts1w.png?700}} ===== Určení vstupních dat do testů: Mezní podmínky, třídy ekvivalence.==== * Jak vhodně nakombinovat hodnoty (data) ve vstupech pro rozhodovací bod? => Můžeme vytvořit **klasifikační strom** pro každý rozhodovací bod v aplikaci * Uzly = classification ~ jednotlivé vstupy pro rozhodovací bod (příklad: políčka z webového formuláře, část podmínky v procesu rozhodování, …) * Listy = třídy ekvivalence pro danou classification ====Třídy ekvivalence (Equivalence class - EC)==== **„Do vstupu můžu zadat velké množství hodnot. Jak vybrat vhodnou množinu pro test?“** -> Konkrétní množinu hodnot, které jsou zadat do vstupu, rozdělíme na podmnožiny - třídy ekvivalence: * Systém se má podle specifikace (na základě které testujeme) pro všechny hodnoty z konkrétní třídy ekvivalence chovat stejným způsobem Konkrétní hodnoty (data) pro test pak vybereme z vytvořených tříd ekvivalence. Kolik jich vybrat? Záleží, jaké chceme mít *testovací pokrytí* === Typy === - **Dle typu vstupu:** * **Interval** - Například pro: částka, věk, číslo účtu * Hranice intervalu = mezní podmínky (viz dále) * **Diskrétní hodnoty** - Například pro: typ prohlížeče, metoda platby, položka v menu, výběr z položek v číselníku * Nejsou mezní podmínky - **Dle validity dat:** | Typ třídy ekvivalence | Co znamená pro aplikaci| Příklad: políčko pro číslo účtu| |-|-|-| | Nevalidní třída ekvivalence z technického pohledu| Data, která neodpovídají datovému typu vstupu = neplatná data, která aplikace musí ošetřit, aby nezpůsobila pád|Řetězec; Číslo, ale jako číslo účtu nevalidní formát| | Nevalidní třída ekvivalence z business pohledu| Data, která sice odpovídají datovému typu vstupu, ale z pohledu specifikace business procesu jsou nevalidní| Číslo účtu ve validním formátu, ale mimo nadefinovaný rozsah číselné řady účtů; Číslo účtu ve validním formátu ve stejné bance, ale takový účet neexistuje| | Validní třída ekvivalence| Platná data, která mají být zpracovávána podle business specifikace, vyvolávají korektní průběhy procesů v aplikaci| Číslo účtu ve validním formátu v jiné bance, ale takový účet neexistuje; Existující číslo účtu ve stejné bance; Existující číslo účtu v jiné bance| === Pravidla konzistence při určování tříd ekvivalence: === * Třída ekvivalence nesmí být prázdná (tj. určíme nějakou podmínku, která bude vymezovat data v ní, ale žádná data nebo případy jí nebudou odpovídat) * Žádné dvě třídy ekvivalence nesmí mít neprázdný průnik * Sjednocení všech tříd ekvivalence musí být původní * interval (pro typ interval) * množina (pro typ diskrétní hodnoty) ** Jak určit třídy ekvivalence?** * U diskrétních hodnot: Analýza požadavků a specifikace * U intervalu: Analýza požadavků a specifikace pomocí techniky **mezních podmínek** ==== Mezní podmínky ==== * **ISTQB definice:** Hodnota, která tvoří hranici mezi třídami ekvivalence, nebo je o malý inkrement posunutá na jednu ze stran této hranice {{statnice:bakalar:ts1ec.png?700}} * **Přesnost dané hodnoty** * Přesnost daná datovým typem (Příklad: SQL typ DECIMAL(10,4) se 4 desetinnými místy) * Přesnost daná specifikací (Příklad: Částku transakce účtujeme se 2 desetinnými místy. Zaokrouhlovací rozdíly se řeší opravnými položkami.) * **Iterace kolem hranice třídy ekvivalence**: * M – mezní hodnota, tvořící hranici třídy ekvivalence * I – nenulová nejmenší hodnota, kterou jde uložit * Testujeme M, M + I, M - I * **Vazba mezních podmínek na typy tříd ekvivalence:** | Typ třídy ekvivalence | Kde vzít mezní podmínky | Jak je najít | Příklad: věk pasažéra | |-|-|-|-| | Nevalidní třída ekvivalence z technického pohledu | Technické limity daného vstupu (někdy i specifikace) | Rozsah hodnot pro validní vstup; Datový typ v programu; Datový typ v databázi|Políčko pro věk pasažéra má rozsah platné hodnoty 0-150 | |Nevalidní třída ekvivalence z business pohledu | Požadavky; Specifikace | Informace ve specifikaci, že určité hodnoty (daný rozsah hodnot) nejsou povoleny nebo jsou ze zpracování vyloučeny|Limit věku je 150 let | | Validní třída ekvivalence | Požadavky; Specifikace | Informace ve specifikaci, že od určité hodnoty (pro daný rozsah hodnot) dochází ke konkrétní variantě zpracování | Pasažér od 2 let má vlastní sedadlo; Pasažér do 6 let musí letět s rodiči | ===== Určení vstupních dat do testů: Párové testování, kombinatorické testování. ===== Jak nyní určíme vhodné kombinace dat v jednotlivých vstupech rozhodovacího bodu, aby naše testy našly co nejvíce chyb (v limitech toho, jakou kapacitu na ty testy máme)? | Technika | Množství kombinací → testovací pokrytí | Co testujeme (jen pro orientaci - berte s rezervou!) | |-|-|-| | MCC – Multiple Condition Coverage | Kompletní množina všech kombinací | Kritický SW – letadlo, lékařské přístroje, … | | MC/DC – Multiple Condition/Decision Coverage | Všechny kombinace, které mají vliv na výsledek rozhodovacího výrazu | | | Pairwise testig (pokrytí je škálovatelné, pozice zde je pro kompletní kombinaci všech dvojic) | Výrazně menší počet kombinací, ale dle statistik stále odchytí většinu chyb | Důležité části nekritického SW: Jádro programu, výpočty, které musí být správně | | C/DC – Condition/Decision Coverage | Relativně malý počet kombinací pro testy střední / nízké intenzity | Nekritický SW – funkční testy | | CC – Condition Coverage | Relativně malý počet kombinací pro testy střední / nízké intenzity | Nekritický SW – funkční testy | | DC – Decision Coverage | Relativně malý počet kombinací pro testy střední / nízké intenzity | Nekritický SW – funkční testy | ==== Párové Testování (Pairwise Testing) ==== * Statistika: Pokud je někde v software defekt, aktivuje se nejčastěji buď - hodnotou jednoho konkrétního vstupu - kombinací hodnot ve dvou vstupech * **Princip:** Místo testování všech možných kombinací vstupních hodnot (což by mohlo být obrovské množství) testujeme všechny dvojice (páry) vstupních hodnot. * **Proč to funguje:**Statisticky většina chyb vzniká buď na základě jedné konkrétní vstupní hodnoty, nebo na základě kombinace dvou vstupů. Situace, kdy chyba vznikne až kombinací tří a více vstupů, jsou vzácné. === Příklad === * klasifikační strom pro vstupy: {{statnice:bakalar:ts1treep.png?700}} * Počet kombinací = (počet EC v prvním vstupu) * (počet EC v druhém vstupu) * (počet EC v třetím vstupu) = 3 * 2 * 2 = 12 * Kompletní pokrytí všemi možnými kombinacemi – 12 variant k otestování: {{statnice:bakalar:ts1full.png?500}} {{statnice:bakalar:ts1fullt.png?500}} * **Párové testování:** V každém páru vstupů jsou pokryty všechny kombinace – 6 variant k otestování: {{statnice:bakalar:ts1pair.png?500}}{{statnice:bakalar:ts1pairt.png?500}} ==== Kombinatorické Testování ==== * Existují různé metody, jak vybrat z možných kombinací vhodné hodnoty pro výsledné testovací scénáře tak, aby pokrytí systému bylo co největší * **příklad testovaného výrazu:** {{statnice:bakalar:ts1komblog.png?600}} - **Condition coverage (CC)** * Výstup každé podmínky (TRUE / FALSE) je vyhodnocen alespoň jednou - **Decision coverage (DC)** * Alespoň jednou jsou vyhodnoceny všechny možné výstupy nějakého vyhodnocení ((A AND B) OR C) - **Condition / Decision coverage (C/DC)** * Spojení CC a DC * **MCC (Multiple Condition Coverage)** * Všechny možné kombinace výsledků podmínek v logickém výrazu jsou testovány alespoň jednou. * Nejvyšší úroveň pokrytí. * Počet kombinací: pro obecný klasifikační strom: (počet EC ve vstupu1) * (počet EC ve vstupu2) * (počet EC ve vstupu3) ... * **Příklad:** {{statnice:bakalar:ts1mcc1.png?700}} {{statnice:bakalar:ts1mcc2.png?700}} * **MC/DC (Modified Condition/Decision Coverage):** * Každý z výsledků všech podmínek v logickém výrazu je otestován alespoň jednou a zároveň každá z podmínek nezávisle ovlivnila výsledek logického výrazu(tím, že měníme pouze vstupní hodnoty pro tuto podmínku, zatímco vstupní hodnoty pro ostatní podmínky držíme zafixované) * Pracuje s termínem **neutrální hodnota** * **Příklad:** [[https://moodle.fel.cvut.cz/pluginfile.php/516273/mod_resource/content/1/TS1_prednaska2.pdf|na slidech 24 - 33]] ===== Vytváření testovacích scénářů: Procesní testy===== === Model Problému === * Testovaná aplikace se modeluje jako orientovaný graf nebo zjednodušený UML activity diagram. * Uzly grafu = větvící body (rozhodovací body). * Hrany grafu = přechody (akce) mezi uzly. * Testovací scénář je sled (sekvence) akcí, kterými aplikace prochází z počátečního do koncového stavu. {{statnice:bakalar:ts1process.png?400}} {{statnice:bakalar:ts1orient.png?400}} {{statnice:bakalar:ts1orientt.png?400}} === Jak vypadá testovací scénář === * Je to konkrétní průchod grafem od startu do konce. * Obsahuje: * sekvenci vstupních a výstupních akcí pro jednotlivé uzly, * všechny potřebné kombinace podle požadované úrovně pokrytí. (viz vytváření testů) === Kritérium Pokrytí Test Depth Level === | Hloubka pokrytí | Popis | Kdy použít (typicky) | |-|-|-| | 1 | Každá akce (hrana grafu) se vykoná jednou | Testy málo prioritních akcí, smoke testy | | 2 | Pro každé větvení (uzel) projdeme všechny kombinace možných vstupních akcí do uzlu a výstupních akcí z uzlu | Střední úroveň testování | | 3 | Pro každé větvení (uzel) projdeme všechny kombinace možných vstupních akcí do uzlu a 2 na sebe navazujících výstupních akcí | Vysoká intenzita testů | | N | Pro každé větvení (uzel) projdeme všechny kombinace možných vstupních akcí do uzlu a N-1 na sebe navazujících výstupních akcí | | === Vytváření Testů === - Modelujeme aplikaci jako orientovaný graf. - Identifikujeme vstupní a výstupní akce v každém rozhodovacím bodě. - Určíme potřebnou úroveň pokrytí (TDL). - Generujeme sekvence testů: * Kombinujeme akce tak, aby pokryly všechny požadované cesty. * Minimalizujeme opakování, pokud už je kombinace pokrytá. * Při omezených zdrojích preferujeme: * prioritní akce (z pohledu businessu nebo rizika), * nejdůležitější průchody. **Příklady:** {{statnice:bakalar:ts1path1.png?700}} {{statnice:bakalar:ts1path2.png?650}} ===== Vytváření testovacích scénářů: Testy konzistence dat===== === Model Problému === * Data v systému mají životní cyklus: **C (create) → R (read) → U (update) → D (delete)** * Různé funkce aplikace provádějí různé operace na datových entitách. * Konzistence znamená, že: - Data, která uložíme, poté správně přečteme. - Aktualizace nezpůsobí nečekanou chybu. - Smazání (nebo archivace) odpovídá očekávání systému. * Mezi funkcemi a datovými entitami je obecně M:N vztah (více funkcí pracuje s více entitami). **Jaké jsou možné chyby?** * Některá z operací C, R, U, D není vůbec implementovaná * Některá z operací C, R, U, D neprobíhá správně * Pokud se operace C, R, U, D vykonají mimo očekávaný průběh, naruší se konzistence dat * Operace D není ve sktečnosti delete, ale jen archivace. Ale některé z funkcí tesotvaného systému pracují s archivovanou entitou stále jako s aktivní... === Jak vypadá testovací scénář === Skládá se z posloupnosti operací: * začíná Create, * následují různé kombinace Read a Update, * končí Delete. Po každé operaci C, U, D se doporučuje spustit Read, abychom ověřili aktuální stav dat. * Jednou R pro nejdůležitější funkci, která zobrazuje datovou entitu - **základní pokrytí** * Vícekrát pro různé funkce, které zobrazují datovou entitu - **kompletní pokrytí R** Kompletní pokrytí znamená testovat různé funkce, které čtou nebo mění entitu, nejen jednu hlavní. === Vytváření testů === - **Sestav CRUD matici:** * řádky = funkce aplikace, * sloupce = datové entity, * v buňkách = které CRUD operace daná funkce nad entitou vykonává. - **Udělej statickou kontrolu:** * Mají všechny entity všechny potřebné CRUD operace? * Pokud ne, proč? - **Udělej dynamické testy konzistence:** * Ověř, že kombinace operací nevede k poškození dat. * Sleduj, zda některá funkce nezpůsobí chybu, která se projeví až v jiné funkci. - **Prioritizuj testy:** * Pokud nemůžeš pokrýt všechny kombinace, testuj prioritně nejdůležitější funkce a cesty. **Příklad:** {{statnice:bakalar:ts1crud.png?700}} === BONUS: CRUD - vázané podmínky === * S konkrétní datovou entitou A jde provést některou z operací **C, R, U, D**, pouze pokud je splněná daná podmínka. **Příklady:** - Entitu zákazník lze smazat, pokud má zaplacené všechny objednávky. - Provozovnu lze smazat, pokud do ní nejsou přiřazení žádní zaměstnanci. **Pozor:** Taková podmínka nemusí být jen na úrovni integrity v DB schématu! ===== Způsoby vytváření testovacích dat. ===== ==== Proč jsou testovací data důležitá ==== * Nastavují stav aplikace před začátkem testu. * Šetří čas na přípravu scénářů. * Umožňují opakovat testy se stejnými podmínkami (retest). * Pomáhají minimalizovat interference mezi týmy při sdílení prostředí. ==== Způsoby přípravy testovacích dat ==== - **Ruční příprava dat** * Vytvoření dat ručně přes funkce aplikace (CRUD → Create, Update). - **Automatické skripty** * Automatizace ruční přípravy pomocí testovacích skriptů. - **Hromadné generování umělých dat** * Automatizované generování dat podle struktury systému. - **Kopie produkčních dat** * Použití reálných dat bez úprav. * Varianta s opatřeními: omezení přístupu, odstranění osobních/citlivých údajů. * Varianta se zmenšeným vzorkem dat. ==== Porovnání způsobů přípravy dat ==== | Způsob | Vstupní investice | Provozní náklady | Rizika | |-|-|-|-| | Ruční příprava | Nízká | Nízké | Nízká | | Automatické skripty | Střední | Střední | Nízká | | Hromadné generování dat | Střední–velká (dle systému) | Střední | Nízká | | Kopie produkčních dat bez úpravy | Nízká | Nízké | Vysoká (právní a regulační) | | Kopie produkčních dat s anonymizací | Střední–velká | Střední | Nízká | ==== Způsoby sdílení dat ==== * Neřízený přístup * Riziko kolizí mezi testery (přepisování dat, chyby vzniklé sdílením). * Řízený přístup * Rozdělení datových entit mezi týmy (např. podle ID, prefixů, vlastností). * Použití skriptů pro výběr nebo evidenci používaných entit. === Další možnosti === * Virtualizace komponent * Nahrazení systému simulací (stub), pokud reálný systém není dostupný nebo je příliš drahý. * Simulace odpovědí, zálohování stavu, přepínání konfigurací. ===== Jednotkové testy===== ==== Princip ==== * Odhalují chyby na úrovni kódu. * Porovnávají výsledek volání metody/procedury s očekávaným výsledkem. * Jsou napsané jako speciální část kódu, která kontroluje funkční část programu. * Programátor je může psát sám přímo ke svému kódu. * Unit testovací frameworky (např. JUnit, TestNG) poskytují podporu a zrychlují přípravu testů. * Testy je možné opakovaně spouštět, často se integrují do build procedury. * Klíčová součást Test Driven Development (TDD), kde slouží i jako specifikace výsledku. ==== Vlastnosti ==== * Nezávislost na jiných testech (test nesmí být prerekvizitou pro jiný test). * Minimální množství vstupních podmínek (preconditions), kde je to možné. * ** Jedna funkcionalita → Jeden unit test** * Přiměřený počet assertů, aby test zůstal přehledný a údržba nebyla zbytečně náročná. * Srozumitelný a jasný název metody testu, který popisuje, co test kontroluje. * Používání jednotného zdroje testovacích dat a konzistentní jmenné konvence. * Struktura testů by měla odpovídat objektové struktuře kódu (např. třídě odpovídá testovací třída). * Unit testy jsou určeny pouze pro kontrolu kódu, nikoliv konfigurace. ==== Unit test X Integration test ==== | Aspekt | Jednotkové testy | Integrační testy | |-|-|-| | Úroveň | Testují jednotlivé bloky kódu (např. metody, třídy) izolovaně. | Testují spolupráci více komponent (modulů, služeb, systémů). | | Zaměření | Ověření správnosti malých jednotek logiky. | Ověření správnosti propojení mezi jednotkami a jejich interakce. | | Nástroje | Unit test frameworky (JUnit, TestNG). | Automatizační frameworky, integrační nástroje, end-to-end testy. | | Komplexita | Nízká (zaměřeno na detaily). | Vyšší (zaměřeno na celý proces, komunikaci, integrace). | | Účel | Rychlé odhalení chyb v kódu, prevence regrese. | Ověření, že jednotlivé části systému fungují dohromady správně. | | Příklad | Test metody pro výpočet ceny. | Test propojení mezi platebním modulem a bankovní API. | ===== Automatizované testy založené na simulaci akcí uživatele v uživatelském rozhraní systému===== ==== Princip testu ==== * **End-to-end (E2E)** testování simuluje chování reálného uživatele v aplikaci. * Ověřuje správnou funkčnost aplikace z pohledu uživatele – od začátku do konce. * Kontroluje nejen jednotlivé komponenty, ale i jejich **propojení, integraci a datovou konzistenci.** * Typické scénáře: * otevření aplikace (např. v prohlížeči), * zadání vstupů (kliknutí, psaní, potvrzování), * sledování odpovědí systému (zobrazení dat, reakce UI), * ověření správného dokončení procesu. ==== Příklad technologie ==== * **Selenium** – nástroj pro automatizaci webových prohlížečů. * Další příklady (BONUS): * Cypress.IO * Playwright * Robot Framework * TestCafe * Puppeteer * **Tyto nástroje umožňují:** * simulovat klikání, psaní, posouvání, * kontrolovat obsah stránek, * ověřovat výsledky akcí (např. přidání položky, dokončení platby). ==== Rozdíl oproti jednotkovým testům ==== | Aspekt | E2E testy (testy UI) | Jednotkové testy | |-|-|-| | Úroveň | Testují celý systém (od uživatelského vstupu po backend a zpět). | Testují izolované části kódu (metody, funkce). | | Zaměření | Uživatelská zkušenost, integrační funkce, procesy napříč systémem. | Logika a správnost jednotlivých bloků kódu. | | Rychlost | Pomalejší, protože zahrnují více vrstev systému. | Velmi rychlé, běží přímo nad kódem. | | Stabilita | Náchylné k chybám způsobeným změnami UI nebo závislostí. | Stabilní, méně závislé na okolí. | | Nástroje | Selenium, Cypress, Playwright, TestCafe, Puppeteer. | JUnit, TestNG, NUnit, xUnit. | | Účel | Ověření, že celý systém funguje pro uživatele. | Ověření, že logika kódu funguje podle očekávání. | ===== Testovací strategie: princip metody Business Driven Test Management ===== === Testovací Strategie Obecně === * Testovací strategie je plán na vyšší úrovni, který definuje: * co budeme testovat, * jak budeme testovat, * s jakými prioritami, * s jakou intenzitou, * jakými metodami a nástroji. * Slouží jako vodítko pro celý testovací tým, aby všichni pracovali podle stejného rámce a cílů. * Obsahuje nejen technické aspekty, ale i organizační a byznysové pohledy – stejná terminologie, procesy, metriky * Pomáhá sladit očekávání mezi zadavatelem, managementem a testovacím týmem. * Zajišťuje, že se testování soustředí na oblasti s největším rizikem nebo nejvyšší byznys hodnotou. ==== Princip metody Business Driven Test Management ==== * Metoda BDTM (Business Driven Test Management) pochází z rámce TMAP Next. * Je určená hlavně pro větší testovací projekty, ale lze ji škálovat i na menší. * Jejím cílem je přímo propojit cíle byznysu s přípravou a prováděním testů. * Výstupem je velká tabulka, která propojuje: * testovací cíle (test goals), * požadavky a specifikace, * části testovaného systému, * analýzu rizik, * test levels, * druhy testů a jejich intenzitu, * zvolené test design techniky. === Základní části metody === * **Test goals (testovací cíle)** * Overall test goals (např. od investora, senior managementu). * Departmental test goals (např. od budoucích koncových uživatelů). * Pomáhají sjednotit očekávání kvality a odhalit rozpory mezi investorem a uživateli. * **Popis testovaného systému** * Přehled funkcí systému a jejich vazba na požadavky, procesy a kvalitativní aspekty (funkčnost, výkon, bezpečnost). * **Analýza rizik** * Hodnocení pravděpodobnosti selhání a možného dopadu. * Určení tříd rizika podle kombinace těchto faktorů. * **Určení priorit** * Podle tříd rizika určujeme, co testovat intenzivněji. * Priorita je odvozena z byznysového dopadu selhání, nikoliv jen z technického pohledu. * **Test levels** * Definujeme úrovně testování (např. vývojářské testy, systémové testy, UAT, testy v produkci). * Určujeme, jakou intenzitou se bude testovat na které úrovni. * **Intenzita testování** * Přizpůsobujeme intenzitu podle rizik a dostupných zdrojů. * Např. pro vysokorizikové oblasti vyšší pokrytí a intenzita, pro nízkorizikové nižší. === Souvislosti mezi částmi === * Test goals určují, co je potřeba ověřit → vazba na funkce systému a požadavky. * Analýza rizik určuje priority a intenzitu testování pro jednotlivé oblasti. * Test levels rozdělují testy podle fází a týmů. * Intenzita testování se přizpůsobuje prioritám, rozpočtu a časovým omezením. * Celý proces je propojený v hlavní řídicí tabulce, která zajišťuje přehlednost, konzistenci a trasovatelnost.