Test Debt – testovací dlh v automatizovanom a manuálnom testovaní

Automatizácia testov je nevyhnutná na udržanie kroku s tempom vývoja moderných aplikácií. V priebehu rokov však nástroje na automatizáciu testov nedokázali držať krok. Problémom je, že väčšina starších nástrojov na automatizáciu testov sa spolieha na testovacie skripty. Testovacie skripty sú však známe tým, že sa pri zmenách aplikácie rozbíjajú. Výsledkom je, že testeri musia tráviť čoraz viac času údržbou testov a čoraz menej tvorbou testov. Na druhej strane sa prestávajú sústrediť na svoj hlavný cieľ, ktorým je zabezpečiť, aby bol softvér bez chýb a spoľahlivý. Tento problém nazývame testovací dlh (test debt).

Kapacita testov

Každý tím má obmedzenú kapacitu, ktorú môže vynaložiť na automatizáciu testov. Tento čas musia rozdeliť medzi vytváranie testov a analýzu výsledkov testov. Keď tím začne automatizovať testy, má veľa voľnej testovacej kapacity. Tá sa však rýchlo znižuje, keď sa IT testeri zoznámia s nástrojmi a začnú automatizovať viac testov. Viac automatizovaných testov znamená viac výsledkov testov na analýzu. Testeri nakoniec dosiahnu svoju celkovú testovaciu kapacitu.

Zmena selektorov pri aktualizácii aplikácie

Avšak je tu háčik. Testovacie skripty sa pri vyhľadávaní prvkov v používateľskom rozhraní spoliehajú na selektory (napríklad ID prvku alebo xpath). Skriptom môžeš napríklad povedať, aby klikli na konkrétne tlačidlo alebo zadali text do určitého poľa. Problémom je, že tieto selektory sa nepredvídateľne menia. Dokonca aj jednoduché zmeny štýlov alebo rozloženia môžu spôsobiť, že skript vyberie nesprávne tlačidlo na testovanie alebo zadá text do nesprávneho poľa. Výsledkom je, že keď aktualizuješ aplikáciu, tvoje testy zrazu zlyhajú. V niekoľkých prípadoch môže ísť o skutočnú chybu. Ale častejšie je potrebné test jednoducho opraviť.

Údržba testov vs. tvorba testov a kapacita testovacieho tímu

Výsledkom je, že testeri začínajú tráviť čoraz viac času údržbou testov a čoraz menej tvorbou testov. Na druhej strane sa prestávajú sústrediť na svoj hlavný cieľ, ktorým je zabezpečiť, aby bol softvér bez chýb a spoľahlivý. Ak to teraz pridáš do rovnice, vidíš, že rýchlo narazíš na problém. Celková potrebná práca výrazne prevyšuje ich kapacitu. Tento jav sa nazýva testovací dlh.

Čo je to testovací dlh – test debt?

Testovací dlh (test debt) je jedným z trinástich typov technického dlhu (tech debt alebo code debt). Ide o čas navyše, ktorý musia testeri vyčleniť na dokončenie testovacích činností, ktoré už mali byť vykonané. Keď sa nahromadí testovací dlh, testeri sa môžu cítiť znechutení a preťažení, čo spôsobuje, že zaostávajú so svojimi pravidelnými povinnosťami.

Testovací dlh má dosť podobné vlastnosti ako technický dlh. Je to vlastne metaforické bremeno, ktoré sa hromadí, keď sa úlohy testovania počas vývoja softvéru odkladajú.

Podobne ako technický dlh v kóde, aj testovací dlh môže brzdiť pokrok projektu a jeho kvalitu. Predstav si, že máš bicykel, ale namiesto toho, aby si hneď opravil rozkývané koleso, pokračuješ v jazde. Nakoniec môže tento malý problém spôsobiť väčší problém alebo dokonca nehodu. S testovacím dlhom je to podobné. Ak vynecháš niektoré testy alebo neriešiš problémy v procese testovania, časom môžu tieto nedopatrenia spôsobiť, že veci budú oveľa komplikovanejšie, než by mali byť.

Prečo vzniká test debt?

Testovací dlh často vzniká v dôsledku časových obmedzení, nedostatočných zdrojov alebo meniacich sa priorít projektu. Vývojári a testeri môžu proces tvorby a údržby testov depriorizovať a odkladať, aby splnili termíny, čo vedie k narastaniu množstva nevykonanej testovacej práce.

Tímy neskončia v testovacom dlhu zo dňa na deň. Trvá to určitý čas a je to kumulácia mnohých krátkodobých a nesprávnych rozhodnutí, ktoré to spôsobujú. Nižšie sme uviedli niekoľko možných dôvodov vzniku test debtu.

·       Nedostatok zdrojov a kapacít

Nedostatok alebo náhla zmena zdrojov je častou príčinou vzniku testovacieho dlhu. Ak je napríklad pomer testerov a vývojárov nevyvážený, testeri môžu byť preťažení množstvom práce, ktorá je na nich kladená. Okrem toho prepúšťanie môže spôsobiť testovací dlh, pretože od zostávajúcich testerov sa pravdepodobne očakáva, že udržia testovaciu kapacitu tímu aj napriek odobratiu zdrojov.

·       Časové obmedzenia

Nikto nechce byť príčinou oneskorenia releasu alebo vydania funkcie, najmä ak je to preto, že potrebuje viac času na dokončenie svojej práce. Testeri sú často viazaní časovými limitmi v rámci šprintu alebo iterácie, ktoré môžu byť niekedy nereálne.

·       Automatizácia

Automatizácia testov má potenciál spôsobiť testovací dlh, pretože jej udržiavanie môže byť náročné. Napríklad, keď sa zmenia prvky používateľského rozhrania (UI), testy volajúce predchádzajúce prvky sa pokazia. Testeri zodpovední za automatizáciu musia vyhodnotiť, čo sa pokazilo a potom aktualizovať test. S nárastom počtu testovacích prípadov sa predlžuje aj čas potrebný na údržbu automatizovaného kódu. Ďalší spôsob, ako môže automatizácia spôsobiť dlh testov, je pri analýze výsledkov. Kód sa môže spúšťať a testovať automaticky, ale tiež je potrebný čas na to, aby niekto analyzoval výsledky testov.

·       Zvyšovanie rozsahu

Keď sú požiadavky nejasné, nejednoznačné alebo náchylné na zmeny, často sa stretávame s prípadom scope creep. To vedie k predĺženiu času vývoja a k predĺženiu času testovania. Testeri to často pociťujú najviac, pretože sa očakáva viac práce, ale počas rovnakého času.

·       Zlé plánovanie

Vhodné plánovanie by mohlo mnohým z týchto problémov zabrániť. Technické dolaďovanie a plánovanie šprintu by malo zahŕňať stanovenie času potrebného na testovanie funkcie, ako aj času potrebného na všetky testovacie činnosti.

Aké sú varovné signály testovacieho dlhu?

Hlavným cieľom automatizácie testovania je urýchliť dodanie softvéru a zároveň zachovať dôveru v kvalitu a proces. Hodnota automatizácie testov sa však znižuje, keď sa tímy uchýlia k jej obchádzaniu kvôli problémom, ako je predĺženie času vykonávania, nestabilita alebo nedostatočné pochopenie.

Zadlženosť testov nemusí mať špecifickú metriku, ale stane sa zrejmou, keď sa pozrieš na skoré varovné signály.

• Často nie je úplne dokončené pokrytie testov a to zavádza medzery v testovacej sade. Tieto medzery v pokrytí testov, ako napríklad netestované cesty kódu alebo chýbajúce scenáre, indikujú dlh testov.
• Ak sa predtým vyriešené problémy často objavujú znova, môže to byť znakom nedostatočného testovania. Naznačuje to, že proces testovania možno nepokrýva komplexne všetky scenáre alebo, že nové zmeny neúmyselne znovu zavádzajú staré problémy. Takéto vzory zdôrazňujú dôležitosť zlepšených postupov testovania a ostražitosti pri udržiavaní kvality softvéru.
• Príliš zložité alebo neaktuálne testovacie prípady môžu predĺžiť čas vykonávania testov, čo bráni efektívnosti. Pre aplikácie môže byť napísaných veľa testov a preto vykonanie celej sady testov zaberie viac času.
• Rastúci počet chýb po release naznačuje, že úsilie v oblasti testovania si vyžaduje zlepšenie.
• Problémom sú aj testy závislé od iných testov. Neodporúča sa mať závislosti medzi testami, pretože ak zlyhá nadradený test, zlyhajú aj všetky závislé testy. Nezávislé testy sa ľahšie udržiavajú.

Negatívne účinky test debtu na testovací tím

Testovací dlh nie je nepríjemný len pre testerov, môže potenciálne spôsobiť mnoho problémov produktu a zainteresovaným stranám. Nižšie uvádzame niekoľko možných dôsledkov, ktoré je potrebné zvážiť pri vzniku testovacieho dlhu:

• Stabilita systému – Keď sa regresné testovanie ignoruje alebo vykonáva zle, inak obvykle stabilný systém môže zaznamenať poruchy. Uponáhľaná oprava sa môže obrátiť proti tebe, ak nebola adekvátne vyhodnotená.
• Reputácia – Dôveryhodnosť systému sa môže stratiť, keď sa objaví jedna chyba za druhou. Môže to poškodiť povesť produktu, čo môže spôsobiť prechod používateľov ku konkurenčným produktom. Následne môže byť negatívne ovplyvnená aj povesť spoločnosti, čo môže viesť k tomu, že sa používatelia budú vyhýbať všetkým jej ďalším produktom.
• Frustrácia – Keď sa nahromadí testovací dlh, ale neexistujú žiadne plány nápravy, tímy sa môžu cítiť frustrované. Keď k tomu dôjde, talentovaní členovia tímu s vynikajúcimi znalosťami o produkte si môžu hľadať zamestnanie inde. Toto je jeden z najnežiaducejších dôsledkov testovacieho dlhu.
• Finančná strata – Keď systémy zlyhávajú a spoločnosť sa rúti do záhuby, niektorí majú takzvaný „potkaní inštinkt“, čiže opustia loď ešte skôr, než sa začne definitívne potápať. Tí najšikovnejší vyhodnotia situáciu a môžu odísť niekde, kde tieto problémy nie sú, čo môže mať negatívny ekonomický dopad.
• Zníženie kvality softvéru – Testovací dlh môže znížiť kvalitu softvéru. Môže zhoršiť používateľskú skúsenosť, pretože tieto chyby sa často prejavujú ako neočakávané a problematické problémy pre koncových používateľov.
• Brzdia rýchlosť vývoja– Nahromadený testovací dlh brzdí rýchlosť vývoja tým, že si vyžaduje dodatočný čas a úsilie na riešenie nedostatkov v testovaní, čo môže viesť k oneskoreniu projektu a nedodržaniu termínov. K tomuto oneskoreniu dochádza, pretože tímy musia vyčleniť zdroje na dobehnutie testovacích úloh a odstránenie problémov, ktoré sa nahromadili v dôsledku odloženého testovacieho úsilia.

Opakované stretávanie sa s takýmito problémami bez jasného riešenia v dohľade môže dokonca viesť niektorých členov k spochybňovaniu efektívnosti ich pracovného postupu alebo kvality používaných nástrojov. Časom to môže viesť k zníženiu spokojnosti s prácou, nižšej výkonnosti a menšej motivácii podávať kvalitné výstupy ovplyvňujúce celkovú produktivitu tímu.

Tipy, ako sa vyhnúť testovaciemu dlhu alebo ho zvládnuť

Testovaciemu dlhu sa často dá predísť dodržiavaním správnych postupov. Ak je však testovací dlh nevyhnutný, existujú spôsoby, ako ho zvládnuť. Zvládanie testového dlhu znamená, že podobne ako pri analógii s finančným dlhom si vytvoríš plán na jeho splatenie tak, že ho naplánuješ do svojho časového rozpočtu.

• Plánovanie testov – Ako bolo uvedené vyššie, správne plánovanie testov môže zmierniť veľkú časť testovacieho dlhu. Pri plánovaní vyčleň čas potrebný na všetky testovacie činnosti, ako je návrh, vykonanie, dokumentácia, regresie, tvorba automatizácie, údržba automatizácie a činnosti súvisiace s ukončením testov. Komunikuj plán tak, aby celý tím chápal tvoje povinnosti a vážil si tvoj čas.
• Preskúmanie testov – Niektoré spoločnosti vyžadujú preskúmanie testov pred vykonaním testov. Preskúmanie testov je podobné preskúmaniu kódu. Iný tester v tvojom tíme preskúma tebou vytvorené testovacie prípady a hľadá ďalšie relevantné prípady, ktoré je potrebné pridať, alebo ďalšie testy, ktoré je potrebné vykonať.
• Inovácie – V škálovanom agilnom frameworku (SAFe) sa iterácie končia inovačným týždňom. Iné agilné metódy zahŕňajú šprint technického dlhu alebo niečo podobné. Je to príležitosť na stanovenie priorít a dobehnutie testovacieho dlhu.
• Vytvorenie úloh – Vytvor si testovací dlh ako úlohy alebo inú položku v backlogu. Stanov priority daných taskov a uveď časové odhady, pričom si všimnite všetky možné závislosti. Týmto postupom si upevníte koncept testovacieho dlhu pre seba a svoj tím. Ponúka tiež potenciál, aby si manažment, vedúci pracovníci alebo scrum masteri lepšie uvedomili testovací dlh a realitu, ktorú predstavuje.
• Nechaj si priestor v každom šprinte – V každom šprinte si vyhraď dostatok priestoru na riešenie testovacieho dlhu. Priprav sa pred plánovaním šprintu tým, že budeš poznať svoje kapacity a potom do šprintu zaraď úlohy testovacieho dlhu podľa svojich možností.
• Pravidlo skautov – zanechaj testovacie prípady v lepšom stave, ako keď si ich našiel. Ak prezeráš niektoré testovacie prípady, aktualizuj ich podľa potreby. Tým, že tieto aktualizácie vykonáš v predstihu, budeš v budúcnosti využívať výhody ušetreného času.

Identifikácia a stanovenie priorít technického dlhu

Tímy QA môžu poskytnúť cenné poznatky a podporu pri identifikácii oblastí produktu, ktoré môžu potrebovať refaktorovanie alebo opravu, ako aj pri vývoji a implementácii stratégií na riešenie týchto problémov.

• Účasť na code review

Testovací tím môže zohrávať dôležitú úlohu pri presadzovaní prideľovania zdrojov na úlohy súvisiace s technickým dlhom, čím sa zabezpečí, aby sa týmto úlohám venovala potrebná pozornosť a priorita.

• Testuj včas a často

Včasné a časté testovanie zo strany tímov QA môže pomôcť včas zachytiť problémy a chyby, čo môže znížiť potrebu rýchlych opráv a minimalizovať hromadenie technického dlhu.

• Úzko spolupracuj s vývojármi

Zameraj sa na vyčlenenie potrebných zdrojov na riešenie a vyriešenie dlhu.

• Pravidelne reviduj a aktualizuj procesy testovania

Neustále zdokonaľovanie a optimalizácia testovacích prístupov môže pomôcť minimalizovať riziko vzniku nového technického dlhu počas procesu vývoja.

Testovací dlh v rámci manuálneho testovania

K testovaciemu dlhu dochádza aj vtedy, keď sa testovacie procesy vo veľkej miere spoliehajú na manuálne testy bez náležitej dokumentácie alebo automatizácie. Tento dlh vzniká, keď testeri opakovane vykonávajú opakujúce sa, časovo náročné testovacie prípady manuálne, čím vzniká priestor pre nezrovnalosti, ľudské chyby a prehliadané scenáre.

S vývojom softvéru môže absencia automatizovaných regresných testov viesť k oneskorenej identifikácii chýb a zvýšenému úsiliu pri testovaní. Kvôli napätým termínom nemusia mať testeri dostatok času alebo zdrojov na vytvorenie a vykonanie komplexných testovacích prípadov. To môže mať za následok medzery v pokrytí testov, takže niektoré časti softvéru zostanú netestované. Obmedzená dostupnosť kvalifikovaných testerov môže ovplyvniť schopnosť dôkladne otestovať softvér, najmä v komplexných alebo rozsiahlych projektoch.

Čo prispieva k test debtu v rámci manuálneho testovania:

• Obmedzené vykonávanie testov – často sa stáva, že dostupné zdroje a čas na vykonanie úplného a komplexného testovania nie sú dostatočné. Preto testeri vykonávajú len podmnožinu testov pre danú verziu, čím sa zvyšuje možnosť vzniku chýb.
• Nesprávny návrh testov – manuálne testovanie je časovo náročný a namáhavý proces. Testovací prípad môže byť navrhnutý s množstvom variantov s použitím rôznych kombinácií údajov, ale potom je potrebné, aby tester vykonal všetky tieto kombinácie. Keďže vykonanie všetkých kombinácií testovacích prípadov je pre testerov prácny proces, obmedzujú sa pri testovaní len na niekoľko šťastných scenárov, čím sa skracuje návrh testov. Tým sa zvyšuje riziko zvyškových chýb v testovanom systéme (SUT).
• Chýbajúce review testov – review testov pomáhajú zlepšiť kvalitu testovacích prípadov a tiež pomáhajú skôr nájsť problémy. Chýbajúce preskúmanie testov by mohlo oddialiť nájdenie chýb alebo zvýšiť údržbu testovacích prípadov.

Testovací dlh pri automatizovanom testovaní

Ak skripty pre automatizované testovanie starnú a nedokážu sa prispôsobiť dynamickej povahe vývoja softvéru, prispievajú k vzniku testovacieho dlhu, ktorý brzdí proces automatizovaného testovania a znižuje jeho hodnotu pri zabezpečovaní kvality softvéru.

Takisto sa môžu vyskytnúť nespoľahlivé testy, ktoré niekedy prejdú a niekedy zlyhajú bez zmien v testovanej aplikácii a tieto testy by sa mali odstrániť a opraviť, aby sa zabránilo testovaciemu dlhu.

Automatizované testovanie zahŕňa vykonávanie vopred napísaných testov, ktoré sa vykonávajú a kontrolujú výsledky bez manuálneho zásahu. Zoznam faktorov, ktoré prispievajú k dlhu testov pri automatizovanom testovaní, je nasledovný:

• Nevhodná alebo nedostatočná infraštruktúra – testy vykonávané v infraštruktúre, ktorá sa nepodobá infraštruktúre zákazníka, by mohli viesť k nepredvídateľnému správaniu softvéru, čo by malo za následok zníženú dôveru v systém.
• Nedostatok štandardov kódovania – automatizované testy musia dodržiavať spoločný štandard kódovania. Ak sa neprijme a nedodržiava spoločný štandard kódovania, zvyšuje sa úsilie na údržbu testovacieho kódu.
• Neopravené (nefunkčné) testy – Neopravovanie nefunkčných testov alebo neaktualizovanie testov pri zmene funkčnosti znižuje dôveru v testy, znižuje kvalitu a zvyšuje úsilie na údržbu.
• Používanie Record & Replay – Na testovanie aplikácií s grafickým používateľským rozhraním (GUI) je jednoduché používať nástroje na Record & Replay. Používanie tejto funkcie má však množstvo nevýhod. Namiesto nástrojov Record & Replay môžu byť k dispozícii lepšie alternatívy.

Ako si vybrať nástroj, ktorý pomôže znížiť testovací dlh na minimum?

Výber testovacieho nástroja, ktorý minimalizuješ testovací dlh, zahŕňa niekoľko kritických aspektov. Po prvé, uprednostni možnosti automatizácie testov a uisti sa, že nástroj podporuje rôzne typy testov a skriptovacie jazyky.

Pre efektívne vytváranie a údržbu testov je nevyhnutné ľahko použiteľné, bezkódové alebo nízkokódové rozhranie, ktoré umožňuje širšiemu okruhu členov tímu efektívne prispievať.

Dôležitá je aj škálovateľnosť, rozhodni sa pre nástroj, ktorý sa dokáže prispôsobiť vyvíjajúcim sa potrebám tvojej organizácie, prispôsobiť sa rôznym prostrediam a zariadeniam pre komplexné pokrytie testov.

Ďalej hľadaj integračné funkcie, ktoré sa dajú prepojiť s existujúcimi vývojovými a testovacími nástrojmi, ako sú CI/CD pipeline a systémy na sledovanie chýb, čím sa zefektívnia pracovné postupy a zníži sa testovací dlh. Prečítaj si tiež náš článok Najlepšie testovacie nástroje s umelou inteligenciou.

Záver

Testovací dlh je problémom, ktorý môže spôsobiť vážne problémy. Niekedy je najlepšou voľbou pre riadenie projektu za určitých okolností vytvoriť testovací dlh, ktorý sa vyrieši neskôr. Inokedy sa testovací dlh nahromadí do takej miery, že sa môže stať zdrvujúcim. Aktívnym plánovaním úloh na zníženie testovacieho dlhu si môžu tímy lepšie uvedomiť svoje rozhodnutia a dlh možno uprednostniť.

Ak vieš po nemecky a si IT tester alebo automatizovaný tester, pozri si naše firemné benefity a reaguj na voľné pracovné miesta.

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