11. diel - Manažment testovania Nové
V predchádzajúcej lekcii, Prístupy k testovaniu založené na spolupráci , sme si ukázali poslednú techniku - prístupy k testovaniu založené na spolupráci, ktoré zahŕňajú spoločné písanie užívateľských scenárov, akceptačné kritériá a vývoj riadený akceptačnými testami.
V dnešnej lekcii základov testovania softvéru sa detailnejšie zameriame na test planning, prejdeme si prínos testerov pri plánovaní iterácií a vstupné a výstupné kritériá, ukážeme si techniky na odhadovanie, nevynecháme ani prioritizáciu testu časov a nakoniec preberieme testovaciu pyramídu a testovacie kvadranty.
Test planning
Test plan stanovuje ciele, zdroje a procesy pre testovanie projektu. Obsahuje:
- spôsob dosiahnutia cieľov a harmonogram testovania,
- zabezpečenie splnenia testovacích kritérií,
- komunikáciu s tímom a zainteresovanými stranami,
- súlad s politikou a stratégiou testovania.
Slúži ako nástroj pre analýzu prácnosti potrebnej na dosiahnutie testovacích cieľov. Obvykle zahŕňa:
- kontext testovania,
- predpoklady a obmedzenia testovacieho projektu,
- definíciu zainteresovaných strán,
- plán komunikácie,
- register rizík,
- prístup k testovaniu,
- rozpočet a harmonogram.
V iterative development modeloch SDLC existujú dva hlavné druhy plánovania – plánovanie vydania a plánovanie iterácie.
Plánovanie vydania sa zameriava na budúce vydanie produktu, definuje a upravuje produktový backlog a rozdeľuje väčšie užívateľské scenáre na menšie časti. Tento proces je základom pre definíciu prístupu k testovaniu a plánu testovania naprieč všetkými iteráciami. Testeri sa podieľajú na špecifikácii testovateľných užívateľských scenárov, tvorbe aceptancie critera, analýze projektových a produktových rizík, odhadoch prácnosti, a test planningu súvisiaceho s vydaním. Tester napríklad spolupracuje s tímom na rozdelení komplexných užívateľských scenárov do menších, ľahko testovateľných častí. Počas plánovania tester tiež navrhuje aceptance critera, ktoré budú použité na overenie správnosti každej časti produktu.
Plánovanie iterácie sa zameriava na dokončenie jednej iterácie a pracuje s backlogom iterácie. Testeri tu vykonávajú podrobnú analýzu rizík, stanovujú testovateľnosť užívateľských scenárov, rozkladajú scenáre na úlohy, odhadujú prácnosť testovania a prispievajú k presnému určeniu funkcionálnych a nefunkcionálnych aspektov testovaného objektu. Tester napríklad rozdeľuje užívateľské scenáre na konkrétne testovacie úlohy a odhaduje potrebný čas na ich vykonanie. Zároveň analyzuje potenciálne riziká spojené s testovaním, aby zaistil efektívny priebeh iterácie.
Vstupné a výstupné kritériá
Vstupné kritériá sú podmienky, ktoré musia byť splnené pred začatím testovacej činnosti. Pokiaľ nie sú splnené, testovanie môže byť ťažšie, časovo náročnejšie a rizikovejšie. Typické vstupné kritériá zahŕňajú dostupnosť zdrojov, testwaru a počiatočnú úroveň kvality testovaného objektu:
Výstupné kritériá stanovujú podmienky, ktoré musia byť dosiahnuté, aby bolo možné testovanie ukončiť. Patrí medzi ne miera dôkladnosti, kritériá dokončenia, prípadne vyčerpania času alebo finančných prostriedkov, pričom sú riziká akceptované zainteresovanými stranami.
V agile development sa výstupné kritériá označujú ako definícia hotového a vstupné kritériá ako definícia pripravenosti. Tieto kritériá by mali byť stanovené pre každú úroveň testovania a môžu sa líšiť podľa cieľov testu.
Techniky pre odhadovanie
Odhad prácnosti testovania predstavuje očakávané množstvo práce potrebné na dosiahnutie cieľov testovania v projekte. Je dôležité upozorniť, že odhady vychádzajú z momentálnych predpokladov a môžu byť zaťažené chybou. Odhady pre menšie úlohy bývajú presnejšie, preto je vhodné rozdeliť rozsiahle úlohy na menšie. Existujú štyri hlavné techniky odhadovania.
Odhad na základe pomerov využíva metriky z predchádzajúcich projektov, aby odvodila pomery pre nový projekt. Napríklad ak vývoj trval 600 človeko-dní a testovanie v predchádzajúcich projektoch malo pomer 3:2 k vývoju, možno testovanie odhadnúť na 400 človeko-dní.
Extrapolácia je založená na metrikách z aktuálneho projektu, kde sa čoskoro začínajú merať dáta. Tieto údaje sa potom extrapolujú, napríklad podľa priemernej prácnosti z predchádzajúcich iterácií v iterative development modelu SDLC.
Wideband Delphi je technika, pri ktorej experti nezávisle odhadujú prácnosť. Odhady sa porovnajú, diskutujú sa rozdiely, a proces sa opakuje, kým sa nedosiahne zhoda. Variantom je plánovací poker, bežný v agile development, kde sa používajú karty s číslami symbolizujúcimi rozsah prácnosti.
Trojbodový odhad je technika, pri ktorej experti poskytujú tri odhady: najoptimistickejší odhad (a), najpravdepodobnejší odhad (m) a najpesimistickejší odhad (b). Výsledný odhad (E) sa vypočíta ako vážený aritmetický priemer:
E = (a + 4 * m + b) / 6
Výhodou je, že umožňuje expertom vypočítať chybu merania, obvykle vo forme smerodajnej odchýlky, tá sa vypočíta vzorcom:
SD = (b - a) / 6
Napríklad ak najoptimistickejší odhad a = 6, najpravdepodobnejší odhad m = 9 a najpesimistickejší odhad b = 18, potom výsledný odhad E = 10 človeko-hodín a smerodajná odchýlka SD = 2, čo znamená rozsah od 8 do 12 človeko-hodín, pretože:
E = (6 + 4 * 9 + 18) / 6 = 10
a
SD = (18 - 6) / 6 = 2
Prioritizácia test časov
Po vytvorení a zostavení test časov do testovacích sád je potrebné určiť poradie spúšťania na základe rôznych faktorov:
Medzi najčastejšie používané stratégie prioritizácie patria:
- Prioritizácia na základe rizík, kde sú testy zoradené podľa rizikovej analýzy, pričom najprv sa spúšťajú testy pokrývajúce najdôležitejšie riziká.
- Prioritizácia na základe pokrytia, kde test casy, ktoré dosahujú najvyššieho pokrytia, sa vykonávajú ako prvé. Nasledujú testy, ktoré prinášajú najväčšie dodatočné pokrytie.
- Prioritizácia na základe požiadaviek, kde sú testy zoradené podľa priorít požiadaviek definovaných zainteresovanými stranami. Test casy súvisiace s najdôležitejšími požiadavkami sú vykonávané ako prvé.
Predstavme si tím, ktorý testuje novú funkciu platobnej brány e-shopu. Najprv sa vykonáva testy súvisiace s bezpečnostnými rizikami, ako je ochrana platobných údajov - prioritizácia na základe rizík. Následne sú spustené testy, ktoré pokrývajú čo najviac rôznych platobných metód prioritizácie na základe pokrytia. Nakoniec sú testované menej kritické požiadavky, ako je napríklad rýchlosť spracovania platby, ktoré majú nižšiu prioritu prioritizácie na základe požiadaviek.
Aj keď by sa v ideálnom prípade mali testy vykonávať podľa ich priority, závislosti medzi testami môžu ovplyvniť poradie. Napríklad test s vyššou prioritou môže závisieť od testu s nižšou prioritou, ktorý musí byť vykonaný najskôr. Tiež je nutné zohľadniť dostupnosť zdrojov, ako sú testovacie nástroje, prostredie alebo dostupnosť tímových členov.
Testing pyramíd
Testing pyramíd (testovacia pyramída) je model, ktorý ukazuje rôznu granularitu testov a pomáha určiť vhodný pomer automatizovaných testov. Pomáha tímom rozložiť prácnosť v rôznych úrovniach automatizácie a dosiahnuť ciele každej úrovne:
Spodná vrstva pyramídy obsahuje malé, izolované a rýchle testy, ktoré overujú malé časti funkcionality. Obvykle je ich potrebné veľké množstvo na dosiahnutie rozumného pokrytia.
Horná vrstva pyramídy obsahuje komplexné end-to-end (E2E) testy, ktoré sú pomalšie a overujú väčšiu časť funkcionality. Na pokrytie stačí len niekoľko takýchto testov.
Model pyramídy sa môže líšiť podľa projektu. Pôvodný model zahŕňa tri vrstvy, zatiaľ čo iné modely môžu zahŕňať jednotkové testy, component integration testing a end-to-end testy.
Praktický príklad
Predstavme si vývoj tímu, ktorý pracuje na webovej aplikácii pre online nákupy. Tím používa testing pyramíd na definovanie správneho pomeru automatických testov. Spodnú vrstvu tvoria jednotkové testy (Unit tests). Tím má veľké množstvo jednotkových testov, ktoré overujú malé časti kódu, napríklad funkciu na výpočet celkovej ceny objednávky po aplikácii zľavy. Jednotkové testy sú rýchle, izolované, a zameriavajú sa na správnosť jednotlivých metód.
Strednú vrstvu tvorí component integration tests. Integračné testy overujú správnu interakciu medzi komponentmi. Tím testuje, či modul na pridanie položiek do košíka správne komunikuje s platobným modulom. Týchto testov je menej ako jednotkových testov, ale stále sú kľúčové pre overenie vzájomnej spolupráce častí systému.
Hornú vrstvu potom tvoria end-to-end testy. Tím má niekoľko end-to-end testov, ktoré simulujú kompletný proces nákupu od pridania položiek do košíka až po úspešné dokončenie platby. Tieto testy sú najpomalšie, pretože overujú celý proces a interakciu medzi všetkými komponentmi systému. Testing pyramíd v tomto príklade zaisťuje, že väčšina testov je rýchla a efektívna, zatiaľ čo niekoľko end-to-end testov pokrýva kritické scenáre na vyššej úrovni:
Testing quadrants
Testing quadrants (testovacie kvadranty), definované Brianom Marickom, spájajú úrovne testovania s príslušnými typmi testov, technikami a pracovnými produktmi v agile development. Tento model pomáha manažmentu testovania zaistiť, že všetky relevantné typy a úrovne testov sú zahrnuté do SDLC, a umožňuje lepšie pochopiť, ktoré testy sú pre určité úrovne vhodnejšie:
Model rozlišuje testy podľa osi Y (biznisové alebo technologické zameranie) a osi X (testy zamerané na podporu tímu alebo kritiku produktu), čo vytvára štyri kvadranty:
- Kvadrant Q1 obsahuje component testing a component integration tests. Tieto testy sú automatizované a začlenené do procesu CI. Napríklad pri každom odoslaní zmien do repozitára sa automaticky spúšťa testy, ktoré overujú správnu funkčnosť jednotlivých modulov aplikácie napr. kontrola správneho výpočtu cien objednávok.
- Kvadrant Q2 - zahŕňa functional testing, príklady, testy užívateľských scenárov, UX prototypy, testovanie API a simulácie. Overujú acceptancie critera a môžu byť manuálne aj automatizované. Tester tu napríklad ručne overuje, že používateľ môže dokončiť celý proces nákupu na e-shope, vrátane pridania produktu do košíka a platby, podľa acceptance critera.
- Kvadrant Q3 - zameriava sa na exploratory testing, testovanie použiteľnosti a užívateľskej aceptance testy. Tieto testy sú obvykle manuálne a orientované na užívateľov. Tester napríklad skúma novú mobilnú aplikáciu na rezervácie reštaurácií a hľadá prípadné nedostatky v užívateľskom rozhraní, ako sú nejasné navigačné prvky.
- Kvadrant Q4 - obsahuje smoke testy a nefunkcionálne testy, často automatizované. Pred nasadením novej verzie aplikácie do produkcie sa automaticky spúšťajú výkonové testy, aby sa overilo, že systém zvládne vysokú záťaž užívateľov.
V budúcej lekcii, Manažment rizík , sa detailnejšie zameriame na definíciu rizika a jeho atribúty, rozlíšime si projektové a produktové riziká a ukážeme si tiež čo je analýza a riadenie produktových rizík. V druhej časti sa zameriame na metriky používané v testovaní a tiež na účel, obsah a cieľové skupiny reportov z testovania.
