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é aj výstupné kritériá. Ukážeme si techniky pre odhadovanie, nevynecháme ani prioritizáciu test casov a nakoniec preberieme testovaciu pyramídu a testovacie kvadranty.

Test planning

Plán testovania stanovuje ciele, zdroje a procesy pre testovanie projektu. Takýto plán potom 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.

Test planning pomáha testerom pri riešení výziev súvisiacich s rizikami, harmonogramami, zdrojmi a nákladmi:

Slúži ako nástroj na 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.

Prínos testerov pri plánovaní iterácií a vydaní

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 aceptance kritérií, 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 criteria, 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 či 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. Ak nie sú kritériá 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 riziká sú akceptované zainteresovanými stranami.

V agile developmentu 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 drobnejšie. Existujú štyri hlavné techniky odhadovania.

Odhad na základe pomerov využíva metriky z predchádzajúcich projektov, aby odvodil pomery pre projekt nový. Ak vývoj trval napríklad 600 človekodňov a testovanie v predchádzajúcich projektoch malo k vývoju pomer 2 : 3, možno testovanie odhadnúť na 400 človekodňov.

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 odhadujú prácnosť nezávisle. Odhady sa porovnávajú, diskutujú sa rozdiely a proces sa opakuje, pokiaľ nie je dosiahnutá zhoda. Variantom je plánovací poker, bežný v agile developmentu, kde sa používajú karty s číslami symbolizujúcimi rozsah prácnosti.

Trojbodový odhad je technika, pri ktorej experti poskytujú tri odhady: najoptimistickejší (a), najpravdepodobnejší (m) a najpesimistickejší (b) Výsledný odhad (E) sa vypočíta ako vážený aritmetický priemer:

E = (a + 4 * m + b) / 6

Výhodou tejto metódy je, že umožňuje expertom vypočítať chybu merania, a to obvykle vo forme smerodajnej odchýlky. Tá sa vypočíta vzorcom:

SD = (b - a) / 6

Ak je teda napríklad najoptimistickejší odhad a = 6, najpravdepodobnejší odhad m = 9 a najpesimistickejší odhad b = 18, výsledný odhad je potom E = 10 človekohodín a smerodajná odchýlka SD = 2, čo znamená rozsah od 8 do 12 človekohodín, pretože:

E = (6 + 4 * 9 + 18) / 6 = 10

a

SD = (18 - 6) / 6 = 2

Prioritizácia test casov

Po vytvorení a zostavení test casov 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 sa test casy, ktoré dosahujú najvyššieho pokrytia, 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é.

Praktický príklad

Predstavme si tím, ktorý testuje novú funkciu platobnej brány e-shopu. Najprv sa vykonávajú testy súvisiace s bezpečnostnými rizikami, ako je ochrana platobných údajov, teda podľa prioritizácie na základe rizík. Následne sú podľa prioritizácie na základe pokrytia spustené testy, ktoré pokrývajú čo najviac rôznych platobných metód. A nakoniec sú testované menej kritické požiadavky s nižšou prioritou, ako je napríklad rýchlosť spracovania platby, a síce podľa prioritizácie na základe požiadaviek.

Napriek tomu, že by sa testy mali v ideálnom prípade vykonávať podľa ich priority, poradie môžu ovplyvniť závislosti medzi testami. Napríklad test s vyššou prioritou môže závisieť od testu s nižšou prioritou, ktorý preto musí byť vykonaný najskôr. Tiež je nutné zohľadniť dostupnosť zdrojov, ako sú testovacie nástroje, prostredie alebo kapacita 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. Umožňuje 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ú jednotlivé časti funkcionality. Obvykle je ich na dosiahnutie rozumného pokrytia potrebné veľké množstvo.

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ých 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 či 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 pyramid 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 pre pridanie položiek do košíka správne komunikuje s platobným modulom. Týchto testov je menej ako jednotkových, 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 ich má niekoľko. 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 pyramid 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 developmente. Tento model pomáha manažmentu testovania zaistiť, aby všetky relevantné typy a úrovne testov boli zahrnuté do SDLC, a umožňuje testerom 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. Ide teda napr. o kontrolu 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. Testy overujú acceptance criteria a môžu byť manuálne aj automatizované. Tester tu napr. ručne overuje, či užívateľ môže dokončiť celý proces nákupu na e-shope, vrátane pridania produktu do košíka a platby, a to podľa acceptance kritérií.
• Kvadrant Q3 – Zameriava sa na exploratory testing, testovanie použiteľnosti a užívateľské acceptance testy. Tieto testy sú obvykle manuálne a orientované na užívateľov. Tester napríklad skúma novú mobilnú aplikáciu pre 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.

Zdrojom tejto lekcie sú Učebné osnovy – Certifikovaný tester základnej úrovne ver. 4.0. Copyright © 2023 autori verzie 4.0: Renzo Cerquozzi, Wim Decoutere, Klaudia Dussa-Zieger, Jean-François Riverin, Arnika Hryszko, Martin Klonk, Michaël Pilaeten, Meile Posthuma, Stuart Reid, Eric Riou du Cosquer (predseda), Adam Roman, Lucjan Stapp, Stephanie Ulrich (podpredseda), Eshraka Zakaria

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 tiež si ukážeme, čo je to 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.