20 základných QA metrík testovania softvéru

Tento článok zdôrazňuje význam nástrojov na testovanie QA pri vývoji softvéru tým, že upozorňuje na dôležitosť presných poznatkov a metrík na zlepšenie riadenia projektu, sledovanie pokroku, monitorovanie testovacích činností a zlepšenie kvality softvéru.

Čo sú metriky zabezpečenia kvality?

Metriky QA sa používajú na hodnotenie a posudzovanie kvality a účinnosti procesov vývoja softvéru, produktov a testovacích činností. Tieto metriky pomáhajú pri kvantifikácii rôznych aspektov kvality softvéru a môžu poskytnúť cenné informácie o efektívnosti, spoľahlivosti a celkovej výkonnosti vývojových a testovacích činností.

Metriky QA (quality assurance – zabezpečenie kvality) sa používajú na monitorovanie a kontrolu kvality softvéru počas celého životného cyklu jeho vývoja SDLC (a STLC). Možno ich použiť v rôznych fázach procesu vývoja softvéru vrátane zhromažďovania požiadaviek, návrhu, kódovania, testovania a nasadenia. Sledovaním týchto metrík môžu organizácie identifikovať oblasti, ktoré je potrebné zlepšiť, prijímať rozhodnutia založené na údajoch a zabezpečiť, aby softvér spĺňal požadované normy kvality.

Poznáme dva druhy metrík:

Kvantitatívne metriky (absolútne čísla)

Kvantitatívne metriky sú presne také, ako sa nazývajú. Sú to celé čísla, ktoré merajú jeden aspekt procesu zabezpečenia kvality.

Kvalitatívne metriky (odvodené čísla)

Kvantitatívne metriky samy o sebe nemôžu poskytnúť úplný obraz o výkonnosti tímu QA. Napríklad samotný počet priemerných chýb na jeden test veľa nevypovedá, ak nie je vnímaný v kontexte napríklad celkového počtu vykonaných testov a priemerného času na vykonanie každého testu. Kvalitatívne metriky pomáhajú v tomto smere tým, že spájajú rôzne relevantné metriky navzájom, aby poskytli diferencovaný obraz o rýchlosti, presnosti alebo efektívnosti tímu.

Stručne povedané, nástroje na QA testovanie poskytujú prehľad o kvalite vyvinutého softvéru a o pokroku tímu v rámci plánu testovania.

Na dosiahnutie tohto prehľadu však musí byť tvoj nástroj na testovanie QA schopný sledovať niekoľko kľúčových metrík. Hoci sa metriky testovania, ktoré tvoja organizácia zachytáva, môžu vyvíjať, tvoj tím by mal zvážiť aspoň nasledujúce typy:

1.     Test Coverage (Pokrytie testovania)

Táto metrika by mala byť schopná odpovedať na otázku: „Koľko testov vykonávame a ktoré oblasti softvéru pokrývajú?“

Pokrytie testov vypočítané v percentách definuje, aká veľká časť aplikácie je overovaná existujúcimi testami. Je jednoduché vypočítať to pomocou dvoch rýchlych vzorcov:

• Vykonávanie testov = (počet už vykonaných testov/celkový počet testov, ktoré sa majú vykonať) x 100
• Pokrytie požiadaviek = (počet požiadaviek pokrytých existujúcimi testami/celkový počet požiadaviek) x 100

Druhý vzorec je obzvlášť dôležitý na overenie, či QA kontroluje všetky (alebo väčšinu) funkcií softvéru. Ak napríklad jednoducho spustíš 500 testov, súbor štandardne nezaručuje vysokú kvalitu produktu. Testy musia pokrývať kritické používateľské cesty, výkonnosť základných funkcií a zjavné preferencie zákazníkov.

2.     Test data coverage (Pokrytie testovaných údajov)

Táto metrika hodnotí rozmanitosť a pokrytie testovacích údajov použitých počas testovania. Komplexné pokrytie testovacími údajmi je nevyhnutné na simuláciu reálnych scenárov a odhalenie potenciálnych chýb, ktoré by mohli vzniknúť pri rôznych podmienkach údajov. Zabezpečuje, aby sa aplikácia testovala pri rôznych súboroch údajov a pomáha identifikovať problémy súvisiace s údajmi.

3.     Escaped Bugs (Uniknuté chyby)

Hlavným dôvodom existencie QA je zabrániť tomu, aby sa väčšina (alebo v ideálnom prípade všetky) chyby dostali do výroby. V ideálnom prípade by zákazníci nemali zisťovať a hlásiť žiadne závažné chyby po uvedení aplikácie alebo funkcie do prevádzky. Preto by mal byť počet uniknutých chýb hlavnou metrikou na posúdenie celého procesu QA.

Ak závažné chyby opakovane unikajú a narúšajú používateľský zážitok, možno budeš musieť prehodnotiť svoje testovacie súbory. Našťastie, keď zákazníci nahlasujú chyby, môžeš rýchlo identifikovať problémové oblasti a vzory namiesto toho, aby ste museli znovu skúmať celé architektúry.

Reálne však nie je možné identifikovať a vyriešiť každú možnú chybu pred uvedením do produkcie. Môžeš sa však rozhodnúť pre prijateľný počet rýchlo opraviteľných chýb, ktoré nebudú zákazníka príliš obťažovať.

4.     Requirement Defect Density (Hustota chýb požiadavky)

Sledovanie počtu chýb, ktoré sa objavia pri testoch pokrývajúcich jednotlivé požiadavky, je obzvlášť užitočné. Táto metrika QA môže odhaliť, či sú niektoré požiadavky rizikovejšie ako iné, čo pomáha produktovým tímom rozhodnúť, či by sa tieto funkcie mali releasnúť.

Ak testovanie určitej požiadavky odhalí príliš veľa chýb, môže v skutočnosti odhaliť problémy so samotnou požiadavkou. Samozrejme, je možné, že samotné testovacie prípady si vyžadujú refaktorovanie, ale len zriedkavo sa objaví viac chýb kvôli chybám v štruktúre testov.

Ak napríklad testy na požiadavku A vygenerujú 38 chýb, zatiaľ čo testy na požiadavku B len 7, je to signál pre IT testerov, aby preskúmali, či si požiadavka A nevyžaduje upravené testy. Je to tiež signál, že požiadavka nemusí byť reálne nasaditeľná v súčasnom stave.

5.     Test Effort (Testovacie úsilie)

Hodnotenie náročnosti testovania si vyžaduje zohľadnenie viacerých ďalších ukazovateľov. Tieto čiastkové metriky odrážajú, koľko testov sa vykonáva a ako dlho. Čísla testovacieho úsilia, ktoré sa vo všeobecnosti počítajú ako priemery, ti pomáhajú rozhodnúť, či spúšťaš dostatok testov a či zachytávajú dostatok chýb.

Niekoľko dôležitých čísel:

• počet spustených testov za (trvanie): počet vykonaných testov / celkové trvanie,
• miera preskúšania testov: počet preskúmaných testov / celkové trvanie,
• miera zachytenia chýb: celkový počet zachytených chýb / celková doba trvania testov,
• priemerný počet chýb na test: celkový počet chýb / celkový počet testov.

6.     Test Reliability (Spoľahlivosť testov)

Dokonalý súbor testov má nasledujúce charakteristiky:

• úzka korelácia medzi počtom chýb a neúspešnými testami,
• každý neúspešný test obsahuje skutočnú chybu namiesto toho, aby bol chybný,
• test je úspešný len vtedy, keď je testovaná funkcia úplne bez chýb.

Čím bližšie je suite testov k uvedeným kritériám, tým je spoľahlivejší. Tu je niekoľko dôležitých otázok:

• Sú testy neúspešné kvôli skutočným chybám, alebo kvôli zlému návrhu? Ak áno, koľko?
• Sú testy chybné? Ak áno, koľko a ako často?

Sledovanie spoľahlivosti testov je potrebné na vytvorenie dôvery, že QA adekvátne testuje softvér – skutočne vykonáva svoju prácu. Ako všetky efektívne metriky QA, aj táto pomáha testerom neustále zlepšovať existujúce testovacie prípady, scenáre a postupy.

7.     Time to Test (Čas na testovanie)

Táto metrika odhaľuje, ako rýchlo dokáže tím alebo tester vytvoriť a vykonať testy bez toho, aby to ovplyvnilo kvalitu softvéru.

Samozrejme, táto metrika sa bude líšiť medzi manuálnymi a automatizovanými testovacími cyklami, pričom tie druhé sa vykonávajú oveľa rýchlejšie. Okrem toho aj nástroje a frameworky používané na zabezpečenie kvality majú skutočný vplyv na čas potrebný na testovanie.

Môže byť náročné skombinovať tieto čísla, preto použi nasledujúce priemerné hodnoty:

• Priemerný čas na vytvorenie testov = celkový čas na vytvorenie testov / celkový počet vytvorených testov.
• Priemerný čas spustenia testov = celkový čas spustenia testov / celkový počet spustených testov.

Po získaní počiatočných čísel pre túto metriku výkonnosti tímu QA môžete začleniť osvedčené postupy a aktualizovať nástroje na zvýšenie oboch priemerov. Maj na pamäti, že skrátenie priemerných časov nič neznamená, ak sa tým znížia štandardy kvality.

8.     Test Cost (Náklady na testovanie)

Väčšina tímov QA musí pracovať v rámci konkrétnych rozpočtov. Aby mohli svoje výdavky zdôvodniť, musia pozorne sledovať, koľko plánujú minúť a koľko nakoniec minú. Sú tu dve hlavné čísla:

• Celkové náklady pridelené na testovanie: peňažná suma, ktorú vedenie schválilo na činnosti QA na určité obdobie (štvrťrok, rok atď.).
• Skutočné náklady na testovanie: Skutočná peňažná suma, ktorá bola vynaložená na vykonanie potrebných testov. Tento výpočet môže zahŕňať náklady na testovanie na hodinu, na testovací prípad alebo na požiadavku.

Napríklad: Ak sú tvoje celkové pridelené náklady 2000 eur a musíš otestovať 200 požiadaviek:

• Náklady na testovanie jednej požiadavky: 2000/200 = 10 euro.
• Náklady na hodinu testovania: 2000/počet hodín testovania (povedzme 200) = 100 euro.
• Náklady na jeden testovací prípad: 2000/počet testovacích prípadov (povedzme 50) = 40 euro.

Uvedený príklad predpokladá, že testovanie všetkých požiadaviek si vyžaduje rovnaký čas a rovnakú sumu.

9.     Cost per bug fix (Náklady na opravu jednej chyby)

Jednoducho povedané, ide o sumu vynaloženú na to, aby vývojár opravil každú chybu. Vzorec je nasledovný:

• Náklady na opravu chyby = čas potrebný na opravu * hodinová sadzba vývojára.

10. Test Execution Status (Stav vykonania testov)

V každom okamihu by si mal byť schopný získať presné informácie o tom, koľko testov prešlo, zlyhalo, je zablokovaných, nedokončených alebo ešte nevykonaných. Táto metrika, reprezentovaná ako čísla alebo percentá, je potrebná na denné/týždenné vykazovanie. Je to tiež rýchly prehľad priemernej efektivity tímu, pretože tieto čísla možno porovnať s predtým stanovenými referenčnými hodnotami.

Rýchly tip: Pre ľahšie reportovanie premeň čísla o stave vykonania testov na vizuálne pomôcky, ako sú stĺpcové alebo koláčové grafy.

11. Defects per software change (Chyby na zmenu softvéru)

Často sa stáva, že keď sa pridá nová funkcia alebo sa zmení existujúca funkcia, testovanie týchto zmien odhalí chyby, ktoré v predchádzajúcich testoch neexistovali. Ak si napríklad na webovú stránku pridal ďalšie tlačidlo, testy môžu ukázať, že predchádzajúce tlačidlá (ktoré sa vykresľovali v poriadku) sú teraz nakrivo a majú zle zarovnaný text. Inými slovami, chyby sa objavili výlučne kvôli novej zmene.

Ak bolo napríklad vykonaných päť zmien a po testovaní sa objavilo 25 chýb, môžeš každej zmene pripísať približne päť chýb. Samozrejme, vždy je možné, že jedna zmena zaviedla viac chýb ako ostatné.

Ak budeš túto metriku QA študovať dostatočne dlho v rámci viacerých projektov, môžeš urobiť prognózy o tom, aké chyby môžete s tímom očakávať pri každej zmene. S týmito číslami v ruke môže tvoj tím lepšie plánovať svoj čas, investície do zdrojov a dostupnosť pri začatí nových cyklov testovania.

12. Defect Distribution over Time (Distribúcia chýb v čase)

Na konci testovacieho cyklu je dôležité zmapovať, koľko chýb existuje a odkiaľ pochádzajú. Tým sa odhalí, či tím QA napreduje v identifikácii a riešení väčšieho počtu chýb, keď pracuje na viacerých cykloch.

Rozdelenie chýb na základe ich pôvodu tiež pomáha presne určiť, ktorým oblastiam je potrebné venovať viac pozornosti. Niektoré bežné kategorizácie tu sú:

• rozdelenie chýb podľa príčiny,
• rozdelenie chýb podľa modulu,
• rozdelenie chýb podľa závažnosti,
• rozdelenie chýb podľa platformy.

Ak sa počet chýb v určitej kategórii zvyšuje, ľahšie určíš príčinu. Ak sa napríklad v jednej platforme objaví viac chýb, môže to znamenať, že softvér si vyžaduje väčšiu optimalizáciu pre toto konkrétne prostredie.

13. Bugs found vs. Bugs Fixed (Nájdené chyby vs. odstránené chyby)

Metrika Nájdené chyby vs. Opravené chyby je jednou z kľúčových metrík na posúdenie účinnosti procesu QA. Mapuje počet nájdených chýb k počtu opravených a poskytuje priemer, ktorý objektívne ukazuje, či QA plní svoju hlavnú úlohu.

Táto analýza je tiež užitočná pri identifikácii vzorcov, v ktorých sa chyby objavujú a odstraňujú. Poskytuje dôležitý prehľad o aktuálnom štádiu riadenia chýb.

Na získanie tohto čísla musíš najprv sledovať počet nájdených a vyriešených chýb každý deň v testovacom cykle. Povedzme napríklad, že máš päťdňový testovací cyklus a zozbieral si nasledujúce čísla:

Do konca testovacieho cyklu bolo vytvorených/identifikovaných 17 chýb a 15 bolo vyriešených. Porovnaj to s predchádzajúcimi testovacími cyklami a môžeš určiť, či sa testeri zlepšujú v hľadaní a odstraňovaní chýb alebo nie.

14. Defect Resolution Percentage (Percento vyriešených chýb)

Táto metrika odhaľuje, aký efektívny je vývojový tím pri analýze a odstraňovaní chýb nahlásených tímami QA. Hoci riešenie chýb by v ideálnom prípade nemalo byť záležitosťou QA, sledovanie tohto čísla môže pomôcť vysvetliť oneskorenia pri dodávkach produktu – čo je užitočné najmä pri rozhovoroch s vedením.

Na výpočet tohto čísla sleduj celkový počet chýb nahlásených vývojovému tímu a celkový počet chýb opravených v rámci testovacieho cyklu. Potom použi tento vzorec:

• (celkový počet odstránených chýb / celkový počet nahlásených chýb) x 100.

Opäť sleduj % vyriešených chýb v priebehu času, aby si si overil, či QA poskytuje požadované výsledky pre SDLC.

15. Defect Age (Vek defektu)

Vek defektu meria priemerný čas, ktorý vývojári potrebujú na odstránenie defektu, od jeho začiatku až po skutočné vyriešenie chyby.

• Defect Age = rozdiel medzi časom vzniku chyby a časom jej vyriešenia.

Vo všeobecnosti sa vek defektu meria v dňoch. Povedzme, že chyba bola identifikovaná 9. 4. 2023 a opravená 26. 4. 2023. V tomto prípade je vek chyby 17 dní.

Postupne sa znižujúci vek defektu je silným ukazovateľom vyspelosti tímu QA. Znamená to, že s každým testovacím cyklom trvá oprava chýb kratšie.

16. Test Case Effectiveness (Účinnosť testovacích prípadov)

Toto číslo, odvodené ako percento, udáva účinnosť testovacích prípadov pri odhalených chybách. Inými slovami, koľko testovacích prípadov vykonaných tvojim tímom QA úspešne identifikovalo chyby v jednom testovacom cykle?

Vzorec je jednoduchý:

• Účinnosť testovacích prípadov = (počet nájdených chýb/počet vykonaných testovacích prípadov) x 100.

Dôležité meradlo kvality testovacích prípadov, toto číslo by malo postupne rásť počas postupných testovacích cyklov. Je to jeden z najzreteľnejších ukazovateľov výkonnosti tímu.

17. Defect Leakage (Únik chýb)

V tomto prípade sa sleduje počet chýb, ktoré uniknú do fázy UAT (User Acceptance Testing).

V podstate ide o počet chýb, ktoré sa objavia v UAT po tom, čo aplikácia prešla viacerými úrovňami testovania. V ideálnom prípade by ich testovacie prípady mali odfiltrovať ešte predtým, ako sa potenciálni používatelia dotknú produktu.

Vypočítaš si to ako:

Únik chýb = (celkový počet chýb v UAT/ celkový počet chýb zistených pred UAT) x 100

18. Test Case Productivity (Produktivita testovacích prípadov)

Túto metriku pravdepodobne nebudeš musieť vykazovať vedeniu, ale jej meranie pomáha pri stanovovaní realistických očakávaní pre tvoj tím.

Produktivita testovacích prípadov hodnotí úsilie potrebné na vytvorenie testovacích prípadov pre konkrétny sprint/cyklus. Vzorec je nasledovný:

• Produktivita testovacích prípadov = (počet testovacích prípadov/námaha potrebná na jeden testovací prípad) x 100.

Je zrejmé, že „úsilie potrebné na jeden testovací prípad“ nebude presné číslo. Niektoré testovacie prípady si vyžadujú viac práce na návrhu ako iné. Môžeš však požiadať svojich testerov, aby poskytli spravodlivý priemer. Táto metrika ti poskytne predstavu o tom, čo je pre tím rozumne možné dosiahnuť za cyklus.

19. Test Completion Status (Stav dokončenia testov)

Nie každý testovací prípad, ktorý tím navrhol, bude vykonaný do konca. Niektoré testy prejdú, niektoré zlyhajú a niektoré sa nakoniec nevykonajú alebo sa zablokujú – sledovanie stavu dokončenia testov je ďalším ukazovateľom KPI celkovej výkonnosti tímu.

Niekoľko rôznych vzorcov, ktorých výsledky sa skombinujú a poskytnú celkový obraz o stave dokončenia testov:

• % vykonaných testov = (počet vykonaných testov/počet vytvorených testov) x 100,
• % nevykonaných testovacích prípadov = (počet nevykonaných testovacích prípadov/počet vytvorených testovacích prípadov) x 100,
• % úspešne vykonaných testov = (počet úspešne vykonaných testov / počet vykonaných testov) x 100,
• % neúspešných testovacích prípadov = (počet neúspešných testovacích prípadov / počet vykonaných testovacích prípadov) x 100,
• % zablokovaných testovacích prípadov = (počet zablokovaných testovacích prípadov / počet vykonaných testovacích prípadov) x 100.

S týmito číslami v ruke môžeš rýchlo posúdiť aktuálny stav operácií. Ak je napríklad % úspešných testovacích prípadov nižšie ako % zablokovaných testovacích prípadov, môže ísť o zásadný problém s návrhom testovacích prípadov alebo s testovacím prostredím. Teraz vieš, na aký problém sa máš zamerať, aby si zlepšil výsledky pre ďalší šprint.

20. Test Review Efficiency (Efektívnosť preskúmania testov)

Aj keď testovacie prípady môžu mať označené chyby, každý takýto príznak si vyžaduje určité preskúmanie testerom, aj keď to trvá len niekoľko minút – a zvyčajne to trvá dlhšie. V závislosti od softvéru a štádia jeho vývoja však testy môžu vrátiť veľké množstvo chýb. Čas na preskúmanie každej z nich sa sčítava, a preto je potrebné vypočítať účinnosť preskúmania testov.

• Účinnosť preskúmania testov v % = (počet preskúmaných testov/celkový počet testov, ktoré si vyžadujú preskúmanie) x 100.

Samozrejme, vzorec pre túto metriku QA sa musí použiť v kontexte určitého trvania. Povedzme, že v testovacom šprinte trvajúcom 7 dní bolo zistených 58 chýb, ale vzhľadom na charakter týchto chýb mohol tím preskúmať a postúpiť na riešenie len 45 z nich;  účinnosť preskúmania testov potom predstavuje 77 %.

Záver

Ak budeš merať vyššie opísané metriky QA, budeš mať úplne jasno v tom, ako testovacie tímy fungujú a akú absolútnu hodnotu prinášajú.

Potrebu merania výkonnosti tímu QA nemožno preceňovať. Tak ako každá investícia, aj QA musí vykazovať primeranú návratnosť, aby bolo možné odôvodniť jeho existenciu v každom SDLC. Našťastie, nevyhnutnosť a efektívnosť funkcie QA bola nespočetne veľakrát dokázaná, pokiaľ sa dodržiava vyvíjajúca sa prax.

Ak si IT tester alebo automatizovaný tester a vieš po nemecky, pozri si naše firemné benefity a reaguj na najnovšie pracovné ponuky.

O autorovi

Michaela Kojnoková

Agile Test Engineer

Po štúdiu informatiky na ŽU a TUKE som sa najviac ponorila do oblasti automatizácie testovania. Okrem toho sa venujem tvorbe webov, databázam, dátovej analytike, umelej inteligencii a strojovému učeniu. Mám rada cestovanie, šport a najviac si užívam čas strávený v prírode s mojimi blízkymi. LinkedIn