Ad-hoc testovanie je typ testovania softvéru, ktorý vývojári a softvérové spoločnosti vykonávajú pri kontrole aktuálnej iterácie softvéru. Táto forma testovania poskytuje väčší prehľad o programe a umožňuje odhaliť problémy, na ktoré by bežné testovanie nemuselo upozorniť.
Je nesmierne dôležité, aby testovacie tímy dokonale pochopili proces ad hoc testovania, aby vedeli, ako obísť jeho problémy, a aby sa uistili, že tím môže túto techniku úspešne implementovať.
Presná znalosť toho, ako ad-hoc testovanie funguje a ktoré nástroje môžu uľahčiť jeho realizáciu, umožňuje podniku neustále zlepšovať vlastné postupy zabezpečenia kvality. Formálny proces testovania sa riadi veľmi špecifickými pravidlami, čo môže viesť k tomu, že tím prehliadne niektoré chyby – ad-hoc kontroly môžu tieto mŕtve miesta obísť a rýchlo otestovať každú softvérovú funkciu.
V tomto článku sa bližšie venujeme ad-hoc testovaniu a tomu, ako ho môžete využiť vo svoj prospech pri vývoji softvérového produktu.
Význam testovania Ad-Hoc: Čo je testovanie ad hoc?
Ad-hoc testovanie je proces zabezpečenia kvality, ktorý sa vyhýba formálnym pravidlám a dokumentácii – pomáha testerom nájsť chyby v aplikácii, ktoré bežné prístupy nedokážu identifikovať. To si zvyčajne vyžaduje komplexnú znalosť softvéru pred začatím testovania – vrátane pochopenia vnútorného fungovania programu. Cieľom týchto ad-hoc kontrol je narušiť aplikáciu spôsobom, ktorý odráža vstupy používateľa, a zohľadniť rôzne potenciálne situácie, aby vývojári mohli opraviť všetky existujúce problémy.
Chýbajúca dokumentácia je ústredným prvkom tejto techniky, ktorá neobsahuje žiadny kontrolný zoznam alebo testovacie prípady, ktoré by testerov viedli cez funkcie aplikácie. Ad-hoc testovanie je výlučne o testovaní softvéru spôsobom, o ktorom tím rozhodne, že je v danom okamihu účinný. Môže to zohľadňovať už existujúce formálne testy, ale môže to tiež jednoducho zahŕňať vykonanie čo najväčšieho počtu testov v (pravdepodobne obmedzenom) čase, ktorý je na túto techniku vyčlenený.
1. Kedy a prečo je potrebné vykonať testovanie Ad-Hoc pri testovaní softvéru?
Hlavným dôvodom, prečo spoločnosti vykonávajú ad-hoc testovanie, je jeho schopnosť odhaliť chyby, ktoré tradičné prístupy nedokážu nájsť. Dôvodov môže byť viacero, napríklad konvenčné testovacie prípady sa riadia obzvlášť štandardizovaným procesom, ktorý nemôže zohľadniť osobitosti aplikácie.
Každý typ testovania môže ponúknuť nové perspektívy a zaujímavé prístupy k zabezpečeniu kvality – to ukazuje aj problémy s bežnou stratégiou testovania. Ak napríklad ad-hoc testovanie dokáže identifikovať problém, ktorý testovacie prípady tímu neriešia, naznačuje to, že by mohli mať prospech z rekalibrácie svojej metodiky testovania.
Testeri môžu vykonávať ad-hoc kontroly v ktoromkoľvek bode procesu testovania. Zvyčajne slúži ako doplnok k tradičnému (a formálnejšiemu) zabezpečeniu kvality a vzhľadom na to môžu testeri vykonávať ad-hoc kontroly, zatiaľ čo ich kolegovia vykonávajú formálnejšie skúšky. Namiesto toho však môžu uprednostniť ponechanie ad-hoc kontrol až na obdobie po formálnom testovaní ako následnú kontrolu, ktorá sa špecificky zameriava na potenciálne slepé miesta.
Ad-hoc testovanie môže byť užitočné aj vtedy, keď je čas obzvlášť obmedzený kvôli nedostatku dokumentácie – správny čas závisí od spoločnosti a jej preferovaného prístupu.
2. Keď nepotrebujete testovanie Ad-Hoc
Ak nie je dostatok času na vykonávanie ad-hoc aj formálneho testovania, je dôležité, aby tím uprednostnil druhé z nich, pretože to zabezpečí podstatné pokrytie testami – aj keď stále existujú určité medzery.
Ak formálne testy tímu nájdu chyby, ktoré si vyžadujú opravu, je vo všeobecnosti lepšie počkať, kým vývojári dokončia potrebné zmeny, a vykonať ad-hoc kontroly. V opačnom prípade by sa výsledky, ktoré poskytujú, mohli čoskoro stať neaktuálnymi, najmä ak sa testy týkajú komponentu, v ktorom sa už vyskytli chyby.
Okrem toho sa pred fázou beta testovania musí uskutočniť ad-hoc testovanie.
3. Kto sa podieľa na testovaní Ad-Hoc?
Do procesu testovania Ad-Hoc je zapojených niekoľko kľúčových úloh vrátane:
– Testeri softvéru sú hlavnými členmi tímu, ktorí vykonávajú ad hoc kontroly. Ak sa vykonáva skupinové testovanie alebo testovanie vo dvojiciach, niekoľko z týchto testerov bude pracovať spoločne na tých istých komponentoch.
– Vývojári môžu nezávisle používať tieto kontroly pred formálnou fázou zabezpečenia kvality na rýchlu kontrolu vlastného softvéru, hoci je to menej hĺbkové ako špecializované ad-hoc testovanie.
– Vedúci tímov alebo oddelení schvaľujú celkovú stratégiu testovania – pomáhajú testerom určiť, kedy začať ad-hoc testovanie a ako ho vykonať bez narušenia iných kontrol.
Výhody testovania Ad-Hoc
Medzi výhody ad-hoc testovania pri testovaní softvéru patria:
1. Rýchle riešenia
Keďže tieto testy nezahŕňajú častú dokumentáciu pred, počas ani po kontrole, tímy môžu oveľa rýchlejšie identifikovať problémy. Táto jednoduchosť ponúka testerom obrovskú slobodu.
Ak napríklad tím testuje komponent a nedokáže identifikovať žiadne chyby, môže jednoducho prejsť k ďalšiemu testu bez toho, aby to zaznamenal do dokumentu.
2. Dopĺňa iné typy testovania
Žiadna stratégia testovania nie je dokonalá a 100 % pokrytie je zvyčajne nemožné dosiahnuť – dokonca ani s komplexným plánom. V bežnom testovaní budú vždy existovať medzery, preto je dôležité, aby spoločnosti integrovali viacero prístupov.
Ad-hoc testovanie sa zameriava najmä na hľadanie problémov, ktoré formálne testovanie nedokáže pokryť, čo zaručuje širšie celkové pokrytie testov.
3. Flexibilné vykonávanie
Ad-hoc testovanie sa môže uskutočniť v ktoromkoľvek bode procesu zabezpečenia kvality pred beta testovaním, čo umožňuje spoločnostiam a tímom rozhodnúť sa, kedy je najlepšie vykonať tieto kontroly. Môžu sa rozhodnúť vykonať ad-hoc testy súčasne s bežným testovaním alebo môžu počkať až na neskoršie – bez ohľadu na to, čo majú k dispozícii, tím profituje z možností, ktoré má k dispozícii.
4. Väčšia spolupráca
Vývojári sú do tohto procesu zapojení viac ako do mnohých iných foriem testovania – najmä ak spoločnosť používa buddy a párové testovanie.
Vývojári tak získajú lepší prehľad o svojich vlastných aplikáciách a môžu byť schopní riešiť chyby na vyššej úrovni. To pomáha ešte viac zlepšiť celkovú kvalitu softvéru.
5. Rôzne perspektívy
Ad-hoc testovanie môže ukázať aplikáciu z nových uhlov pohľadu a pomôcť testerom zapojiť sa do týchto funkcií novým spôsobom. Počas testovania sú veľmi dôležité ďalšie perspektívy, pretože formálne kontroly majú často aspoň menšie nedostatky.
Ak ad-hoc testeri používajú softvér s konkrétnym zámerom ho rozbiť, budú môcť ľahšie určiť limity programu.
Výzvy testovania ad hoc
Proces ad-hoc testovania má tiež niekoľko výziev, ako napr:
1. Ťažkosti s podávaním správ
Nedostatok dokumentácie výrazne urýchľuje ad-hoc testovanie, ale môže tiež sťažiť nahlasovanie iných ako závažných problémov.
Napríklad jedna z predtým vykonaných kontrol sa môže neskôr stať relevantnejšou napriek tomu, že pôvodne neviedla k významným výsledkom. Bez komplexnej dokumentácie nemusí byť tím schopný tieto testy vysvetliť.
2. Menej opakovateľné
Podobne si testujúci nemusia byť plne vedomí presných podmienok potrebných na vyvolanie pozorovaných reakcií. Napríklad ad-hoc kontrola, ktorá vráti chybu, nemusí mať dostatočné informácie na to, aby tím mohol prijať opatrenia. Možno nevedia, ako tento test zopakovať a získať rovnaký výsledok.
3. Vyžaduje skúsenosti so softvérom
Keďže pri ad-hoc testovaní je kľúčová rýchlosť a zvyčajne ide o pokusy o rozbitie aplikácie, je dôležité, aby títo testeri tento program dôkladne poznali.
Znalosť fungovania umožňuje testerom narušiť softvér a manipulovať s ním viacerými spôsobmi, čo však môže výrazne zvýšiť nároky na zručnosti pri ad-hoc testovaní.
4. Obmedzená zodpovednosť
Nedostatok dokumentácie môže spôsobiť viac problémov ako len zlé vykazovanie; môže tiež neúmyselne predĺžiť proces testovania a ovplyvniť užitočnosť rýchlych individuálnych ad-hoc testov.
Bez dostatočnej dokumentácie v každej fáze môžu mať testeri problém sledovať svoj postup. To môže dokonca viesť k tomu, že budú opakovať kontrolu, ktorú už vykonali iní testeri.
5. Nemusí odrážať skúsenosti používateľov
Cieľom prakticky každého typu testovania je zohľadniť chyby, ktoré nejakým spôsobom ovplyvňujú koncových používateľov. Ad-hoc testovanie spočíva predovšetkým v tom, že skúsený tester sa snaží napodobniť neskúseného používateľa, čo by malo byť konzistentné pri každej kontrole až po pokusy o rozbitie aplikácie.
Charakteristiky testov Ad-Hoc
Medzi hlavné charakteristiky úspešných ad-hoc testov patria:
1. Vyšetrovanie
Hlavnou prioritou ad-hoc testovania je identifikovať chyby v aplikácii pomocou techník, ktoré bežné kontroly nezohľadňujú. Ad-hoc skúmania prehľadávajú tento softvér s jasným cieľom nájsť diery v testovacích postupoch tímu vrátane pokrytia ich testovacích prípadov.
2. Neštruktúrované
Kontroly ad hoc zvyčajne nemajú žiadny stanovený plán okrem vykonania čo najväčšieho počtu testov mimo typických hraníc formálneho zabezpečenia kvality. Testeri zvyčajne zoskupujú kontroly podľa komponentov, ale ani to nie je nevyhnutné – kontroly môžu dokonca vymýšľať počas ich vykonávania.
3. Skúsenosťami riadené
Ad-hoc testeri využívajú svoje predchádzajúce skúsenosti so softvérom na posúdenie toho, ktoré testy by priniesli najväčší úžitok, a na riešenie bežných slepých miest formálneho testovania.
Hoci je proces testovania stále úplne neštruktúrovaný, testeri pri rozhodovaní o svojej stratégii uplatňujú okrem iného aj svoje znalosti z predchádzajúcich ad-hoc kontrol.
4. Široký záber
Neexistujú presné návody, ktoré kontroly by mal tím počas ad-hoc testovania vykonávať, ale zvyčajne sa týkajú celého radu komponentov – prípadne sa viac zameriavajú na citlivejšie aspekty aplikácie. To pomáha testerom zaručiť, že ich skúšky dokážu plne doplniť formálne testovanie.
Čo testujeme v testoch Ad-Hoc?
Tímy zabezpečenia kvality zvyčajne testujú počas ad-hoc testovania:
1. Kvalita softvéru
Cieľom týchto kontrol je identifikovať chyby v aplikácii, ktoré bežné testovanie nedokáže odhaliť; to znamená, že tento proces testuje najmä všeobecný stav aplikácie.
Čím viac chýb dokáže ad-hoc testovanie odhaliť, tým viac vylepšení môžu vývojári implementovať pred termínom uzávierky.
2. Testovacie prípady
Ad-hoc testovanie vo všeobecnosti neimplementuje testovacie prípady – a to najmä preto, aby tím mohol skúmať, ako efektívne sú pri poskytovaní dostatočného pokrytia. Testovacie prípady sú pravdepodobne nedostatočné, ak ad-hoc kontroly dokážu nájsť chyby, ktoré bežné testovacie procesy nedokážu nájsť.
3. Testovací personál
Cieľom môže byť aj overenie zručností a znalostí testovacieho tímu, aj keď sú testovacie prípady primerané. Napríklad ich metodika implementácie prípadov môže byť nedostatočná a ad-hoc testovanie môže byť rozhodujúce na odstránenie vzniknutých medzier v pokrytí testov.
4. Softvérové limity
Cieľom ad-hoc testovania je tiež pochopiť limity aplikácie – napríklad to, ako reaguje na neočakávané vstupy alebo vysoké zaťaženie systému. Testeri by mohli konkrétne skúmať chybové hlásenia programu a to, ako dobre táto aplikácia funguje, keď je pod značným tlakom.
Vyjasnenie niektorých nejasností:
Testovanie ad hoc a prieskumné testovanie
Niektorí ľudia považujú ad-hoc a prieskumné testovanie za synonymá, hoci pravda je zložitejšia.
1. Čo je prieskumné testovanie?
Prieskumné testovanie sa vzťahuje na postupy zabezpečenia kvality, ktoré skúmajú softvér z holistického hľadiska a konkrétne spájajú procesy objavovania a testovania do jednej metódy. Ide zvyčajne o strednú cestu medzi plne štruktúrovaným testovaním a úplne voľnými ad-hoc kontrolami.
Prieskumné testovanie funguje najlepšie v špecifických scenároch, napríklad keď je potrebná rýchla spätná väzba alebo keď tím musí riešiť okrajové prípady. Tento typ testovania zvyčajne naplno využije svoj potenciál, keď tím popri ňom použije skriptované testovanie.
2. Rozdiely medzi prieskumným testovaním
a testovanie Ad-Hoc
Najväčší rozdiel medzi ad-hoc a prieskumným testovaním je v tom, že ad-hoc testovanie využíva dokumentáciu na zaznamenávanie a uľahčenie kontroly, zatiaľ čo ad-hoc testovanie sa tomu úplne vyhýba. Exploratívne testovanie kladie väčší dôraz na voľnosť testovania, ale nikdy nie na takú úroveň ako ad-hoc prístup, ktorý je úplne neštruktúrovaný.
Prieskumné testovanie zahŕňa aj spoznávanie aplikácie a jej vnútorného fungovania počas týchto kontrol – namiesto toho majú ad-hoc testeri často komplexné znalosti o funkčnosti softvéru ešte pred ich začatím.
Typy testov Ad-Hoc
V testovaní softvéru existujú tri hlavné formy ad-hoc testovania, vrátane:
1. Testovanie na opiciach
Azda najobľúbenejším typom ad-hoc testovania sú opičie testy, pri ktorých tím náhodne skúma rôzne komponenty.
To sa zvyčajne uskutočňuje počas procesu testovania jednotiek a vykonáva sériu kontrol bez akýchkoľvek testovacích prípadov. Testeri nezávisle skúmajú údaje úplne neštruktúrovaným spôsobom, čo im umožňuje preskúmať širší systém a jeho schopnosť odolávať intenzívnemu zaťaženiu zo strany používateľov.
Pozorovanie výstupu týchto neskriptovaných techník pomáha testovaciemu tímu identifikovať chyby, ktoré iné jednotkové testy prehliadli kvôli nedostatkom v bežných testovacích metódach.
2. Testovanie kamarátov
V ad-hoc kontexte sa pri buddy testoch využívajú minimálne dvaja zamestnanci – zvyčajne tester a vývojár – a primárne sa uskutočňujú po fáze unit testovania. „Kamaráti“ spolupracujú na tom istom module s cieľom presne určiť chyby. Vďaka ich rôznorodým zručnostiam a rozsiahlym skúsenostiam sú efektívnejším tímom, čo pomáha zmierniť mnohé problémy, ktoré vznikajú v dôsledku nedostatku dokumentácie.
Vývojár môže dokonca sám navrhnúť niekoľko testov, aby mohol identifikovať komponenty, ktorým je potrebné venovať viac pozornosti.
3. Párové testovanie
Párové testovanie je podobné v tom, že sa na ňom podieľajú dvaja zamestnanci, ale zvyčajne ide o dvoch samostatných testerov, z ktorých jeden vykonáva skutočné testy, zatiaľ čo druhý si robí poznámky.
Aj bez formálnej dokumentácie môže zapisovanie poznámok umožniť tímu neformálne sledovať jednotlivé ad hoc kontroly. Úlohy testera a pisára sa môžu v závislosti od testu vymeniť alebo si dvojica môže ponechať pridelené úlohy počas celého procesu.
Skutočné kontroly zvyčajne vykonáva ten tester, ktorý má viac skúseností – hoci sa o prácu vždy delia navzájom.
Manuálne alebo automatizované testy Ad-Hoc?
Automatizované testovanie môže tímom pomôcť ušetriť ešte viac času počas celej fázy zabezpečovania kvality, čo umožňuje testerom zaradiť do ich harmonogramu viac kontrol. Aj bez definitívnej štruktúry je nevyhnutné, aby testeri pracovali na maximalizácii pokrytia a automatizácia podporovala hĺbkové kontroly tohto softvéru.
Automatizované ad-hoc kontroly sú vo všeobecnosti presnejšie ako manuálne testy, pretože sa vďaka nim dá vyhnúť ľudským chybám pri opakovaných úlohách – to je užitočné najmä pri vykonávaní rovnakých testov v rôznych iteráciách. Úspech tohto postupu zvyčajne závisí od automatického testovacieho nástroja, ktorý si tím vyberie, a jeho funkčnosti.
Automatizované testovanie má však určité obmedzenia. Hlavnou silou ad-hoc testovania je napríklad schopnosť napodobňovať vstupy používateľa a vykonávať náhodné kontroly podľa toho, ako ich tester vymyslí. Tieto testy by mohli stratiť svoju náhodnosť, ak má testovací program organizácie problémy s komplexnými kontrolami.
Čas potrebný na automatizáciu týchto vysoko špecifických úloh môže tiež obmedziť typickú úsporu času tohto procesu. Je dôležité, aby tímy dôkladne preskúmali dostupné automatizačné nástroje a našli taký, ktorý zodpovedá projektu ich spoločnosti.
Čo potrebujete na spustenie testovania Ad-Hoc?
Tu sú uvedené hlavné predpoklady ad-hoc testovania:
1. Kvalifikovaný personál
Keďže ad-hoc testy sú rýchlymi, náhodnými kontrolami vnútorného fungovania softvéru, zvyčajne pomáhajú testeri, ktorí majú s daným softvérom skúsenosti. Mali by mať tiež praktické znalosti kľúčových princípov testovania – to im umožní ľahko identifikovať najúčinnejšie kontroly.
2. Neštruktúrovaný prístup
Testeri musia byť ochotní opustiť svoje zvyčajné stratégie ad-hoc testovania; toto myslenie je rovnako dôležité ako samotné kontroly kvality. Táto metóda môže byť úspešná len bez štruktúry alebo dokumentácie a je nevyhnutné, aby na to testeri pamätali v každej fáze.
3. Softvér pre automatizáciu
Hoci ad-hoc testovanie sa viac spolieha na testovanie náhodných vstupov a podmienok, automatizácia je stále veľmi účinnou technikou v akomkoľvek kontexte.
Z tohto dôvodu by sa pri ad-hoc kontrolách mali podľa možnosti stále implementovať nástroje na automatizované testovanie, pretože správna aplikácia môže tento proces výrazne zefektívniť.
4. Iné formy testovania
Ad-hoc testy najlepšie fungujú spolu s inými kontrolami, ktoré majú formálnejší prístup – pomáhajú tímu zaručiť podstatné pokrytie celého softvéru. Je dôležité, aby testeri kombinovali rôzne techniky, hoci to môže byť pred, počas alebo po dokončení ad-hoc testovania.
Proces testovania Ad-Hoc
Obvyklé kroky, ktoré by mali testeri dodržiavať pri ad-hoc testovaní softvéru, sú:
1. Definovanie cieľov ad-hoc testov
Táto fáza je obmedzená kvôli nedostatku dokumentácie a štruktúry, ale stále je najdôležitejšie, aby mal tím jasné zameranie. Testeri môžu začať zdieľať nejasné predstavy o tom, ktoré testy sa majú spustiť a ktorým komponentom dať prednosť.
2. Výber ad-hoc testovacieho tímu
Keď tím vymyslí niekoľko potenciálnych ad-hoc kontrol, zistí tiež, ktorí testeri by boli na tento typ testovania najvhodnejší. Zvyčajne vyberajú testerov, ktorí aplikácii dôverne rozumejú, a môžu ich spájať aj s vývojárom.
3. Vykonávanie ad-hoc testov
Po rozhodnutí, ktorí testeri sú vhodní pre túto fázu, začnú títo členovia tímu vykonávať kontroly v dohodnutom bode testovania. Ich cieľom je vykonať čo najviac ad-hoc kontrol, ktoré testeri môžu vymyslieť až v tejto fáze.
4. Vyhodnotenie výsledkov testov
Po ukončení testov (alebo aj medzi jednotlivými kontrolami) testeri vyhodnotia výsledky, ale bez ich formálneho zdokumentovania v testovacom prípade. Ak zistia nejaké problémy s aplikáciou, neformálne ich zaznamenajú a prediskutujú ďalšie kroky tímu.
5. Hlásenie akýchkoľvek objavených chýb
Po vyhodnotení výsledkov musia testeri informovať vývojárov o chybách prítomných v softvéri, aby mali dostatok času na ich odstránenie pred vydaním.
Testovací tím využíva tieto informácie aj na určenie toho, ako zlepšiť svoje formálne testovacie procesy.
6. Opakované testovanie podľa potreby
Testovací tím pravdepodobne zopakuje proces ad-hoc pre nové iterácie aplikácie, aby skontroloval, ako dobre zvláda aktualizácie. Keďže testeri odstránili mnohé z predtým zistených nedostatkov v testovacích prípadoch, budúce ad-hoc kontroly môžu vyžadovať iný prístup.
Osvedčené postupy pre testovanie Ad-Hoc
Testovacie tímy by mali počas ad-hoc testovania uplatňovať určité postupy vrátane:
1. Zamerajte sa na potenciálne nedostatky v testovaní
Hoci ad-hoc testovanie zahŕňa oveľa menej plánovania ako iné typy, tím sa stále snaží odstrániť nedostatky v zabezpečení kvality. Ak majú ad-hoc testeri podozrenie na nejaké špecifické problémy s testovacími prípadmi tímu, mali by ich pri vykonávaní kontroly uprednostniť.
2. Zvážte softvér na automatizáciu
Stratégie automatizácie, ako napríklad hyperautomatizácia, môžu spoločnostiam, ktoré chcú vykonávať ad-hoc testy, priniesť mnoho výhod.
Úspech tohto postupu závisí od niekoľkých kľúčových faktorov vrátane nástroja, ktorý si podnik vyberie, ako aj od všeobecnej zložitosti jeho ad-hoc testov.
3. Robte si komplexné poznámky
Nedostatok dokumentácie pri ad-hoc testovaní slúži najmä na ďalšie zefektívnenie tohto procesu – tím by mohol využiť neformálne poznámky, ktoré si robí počas práce. Testeri tak majú jasný záznam o týchto kontrolách a ich výsledkoch, čo zvyšuje ich celkovú opakovateľnosť.
4. Pokračujte v zdokonaľovaní testov
Ad-hoc testeri neustále zdokonaľujú svoj prístup, aby zohľadnili zmeny v stratégii testovania tímu. Napríklad pri skúmaní novších verzií softvéru spoločnosti môžu tieto kontroly upraviť v reakcii na novšie a komplexnejšie formálne testovacie prípady.
7 chýb a nástrah pri implementácii
Testy Ad-Hoc
Ako pri každom procese testovania, aj tu existuje široká škála potenciálnych chýb, ktorým by sa mal tím snažiť vyhnúť, ako napríklad:
1. Neskúsení testeri
Na udržanie očakávaného tempa ad-hoc testovania musí vedúci tímu prideliť testerov na základe ich znalostí a zručností. Zatiaľ čo mnohé formy testovania dokážu zvládnuť pracovníci zabezpečujúci kvalitu na základnej úrovni, ad-hoc kontroly si vyžadujú členov tímu, ktorí plne rozumejú softvéru; najlepšie so skúsenosťami s vykonávaním týchto testov.
2. Nesústredené kontroly
Ad-hoc testovanie môže výrazne zlepšiť pokrytie testov vďaka rýchlejšiemu tempu – tím nemusí pred každou kontrolou a po nej vypĺňať rozsiahlu dokumentáciu.
Ad-hoc testeri sa však stále musia sústrediť; môžu sa napríklad rozhodnúť uprednostniť určité komponenty s vyšším rizikom zlyhania.
3. Žiadne plánovanie
Vyhýbanie sa akémukoľvek plánu môže obmedziť účinnosť ad-hoc testovania. Napriek neštruktúrovanej povahe tohto prístupu je dôležité, aby mal tím pred začatím približne predstavu o tom, ktoré testy sa majú vykonať.
Čas je počas tohto procesu obmedzený a znalosť postupu môže priniesť mnoho výhod.
4. Príliš štruktúrovaný
Na opačnom konci spektra sa tento prístup zvyčajne spolieha na nedostatočné plánovanie, pretože to pomáha testerom aktívne vyvracať testovacie prípady a nachádzať skryté chyby.
Ad hoc testovanie je známe aj ako náhodné testovanie a vnucovanie štruktúry by mohlo týmto kontrolám zabrániť v hľadaní chýb.
5. Žiadne dlhodobé zmeny
Účelom ad-hoc testovania je identifikovať prípadné nedostatky v testovacích prípadoch tímu; skúma sa tak ich celková stratégia rovnako ako samotný softvér.
To však znamená, že ad-hoc testy sú vo všeobecnosti účinné len vtedy, ak tím použije tieto informácie na zdokonalenie svojich formálnych kontrol v priebehu času.
6. Nekompatibilné súbory údajov
Prakticky každá forma testovania si vyžaduje určitú formu simulovaných údajov, aby bolo možné posúdiť, ako aplikácia reaguje; niektoré nástroje umožňujú testerom automaticky naplniť program modelovými údajmi.
To však nemusí odrážať spôsob, akým by používateľ so softvérom pracoval – ad hoc kontroly si vyžadujú súbory údajov, s ktorými sa softvér pravdepodobne stretne.
7. Informačné silá
Je nevyhnutné, aby testeri a vývojári medzi sebou neustále komunikovali, aj keď nie sú súčasťou procesu ad-hoc testovania.
To pomôže každému pochopiť, ktoré testy boli vykonané – ukáže ďalšie kroky, ktoré treba vykonať, a zároveň zabráni tomu, aby testeri zbytočne opakovali niektoré kontroly.
Typy výstupov z testov Ad-Hoc
Kontroly ad-hoc prinášajú niekoľko rôznych výstupov vrátane:
1. Výsledky testov
Jednotlivé testy prinášajú rôzne výsledky špecifické pre konkrétnu zložku a prístup – ten môže mať rôzne podoby.
Zodpovednosť za určenie, či výsledky predstavujú chybu, je zvyčajne na testerovi, hoci nedostatok dokumentácie sťažuje porovnanie s jeho očakávaniami. Ak tím zistí nejaké problémy, odovzdá tieto výsledky vývojárom.
2. Testovacie protokoly
Samotný softvér používa zložitý systém interných protokolov na monitorovanie vstupov používateľa a upozorňuje na množstvo problémov so súbormi alebo databázami, ktoré sa môžu objaviť.
To môže poukazovať na internú chybu vrátane konkrétnej časti softvéru, ktorá spôsobuje problém. Vďaka týmto informáciám môžu ad-hoc testeri a vývojári oveľa ľahšie riešiť objavené problémy.
3. Chybové hlásenia
Cieľom mnohých ad-hoc kontrol je špeciálne narušiť softvér a odhaliť jeho limity, čo znamená, že chybové hlásenia aplikácie sú jedným z najčastejších výstupov týchto testov.
Zámerným vyvolávaním chybových hlásení môže tím predviesť to, čo vidí priemerný koncový používateľ vždy, keď neočakávané akcie, ktoré vykoná, majú nepriaznivý vplyv na fungovanie programu.
Príklady testovania Ad-Hoc
Tu sú tri scenáre ad-hoc testovania, ktoré ukazujú, ako ho môže tím implementovať pre rôzne aplikácie:
1. Webová aplikácia elektronického obchodu
Ak chce spoločnosť otestovať webovú aplikáciu založenú na elektronickom obchode, môže použiť ad-hoc testovanie – konkrétne testovanie na opici – aby zistila, ako dobre platforma zvláda neočakávané interakcie používateľov.
Testeri sa môžu snažiť posunúť jednotlivé funkcie až na hranicu ich možností, napríklad pridávať do košíka položky v nereálnych množstvách alebo sa snažiť kúpiť produkty, ktoré nie sú na sklade. Nie sú obmedzovaní testovacími prípadmi tímu a existuje len málo obmedzení, ktoré kontroly by mohli vykonať; testeri sa dokonca môžu pokúsiť dokončiť nákupy pomocou neaktuálnych adries URL.
2. Desktopová aplikácia
Ad-hoc testeri môžu tieto techniky implementovať aj pre desktopové aplikácie s možným zameraním na rôzne počítače a na to, ako dobre sa na nich program prispôsobí.
Členovia tímu môžu tieto kontroly vykonávať opakovane, aby zistili, ako zmena hardvérových alebo softvérových nastavení ovplyvňuje celkový výkon aplikácie. Konkrétna grafická karta môže mať napríklad problémy s vykresľovaním rozhrania.
Prípadne by títo testeri mohli jednoducho zadať svojmu programu nemožné vstupy a zistiť, ako reaguje, napríklad či dokáže správne zobraziť chybové hlásenia, ktoré koncovému používateľovi primerane vysvetlia problém.
3. Mobilná aplikácia
Jedným zo spôsobov, ako by ad-hoc testeri mohli preskúmať mobilnú aplikáciu, je otestovať jej bezpečnostné protokoly – mohli by sa napríklad pokúsiť o priamy prístup k vývojovým nástrojom aplikácie.
Tím sa môže pokúsiť zistiť, či je schopný vykonať neautorizované akcie nájdením bežných medzier a exploitov; o uľahčenie tejto činnosti môže požiadať najmä zamestnancov so skúsenosťami v oblasti zabezpečenia aplikácií.
To môže zahŕňať aj párové testovanie s vývojármi kvôli ich prehľadu o návrhu aplikácie, čo umožní testerovi rozbiť softvér a ukázať, kde presne je jeho bezpečnosť nedostatočná.
Typy zistených chýb a nedostatkov
prostredníctvom testovania Ad-Hoc
Ad-hoc kontroly môžu odhaliť mnohé problémy s programom, ako napríklad:
1. Chyby funkčnosti
Použitie ad-hoc testovania na preskúmanie základných funkcií aplikácie môže odhaliť závažné chyby, ktoré ovplyvňujú spôsob, akým s ňou môžu pracovať koncoví používatelia.
Napríklad opičie testovanie možností platby na stránke elektronického obchodu ukáže podmienky, ktoré bránia transakcii.
2. Problémy s výkonom
Testeri môžu pracovať špeciálne na vytvorení výkonnostných problémov v programe – napríklad naplnením databázy rôznymi spamovými vstupmi.
To sa môže prejaviť ako výrazné oneskorenie alebo dokonca všeobecná nestabilita softvéru, čo pravdepodobne povedie k (potenciálne celosystémovému) zlyhaniu.
3. Problémy s použiteľnosťou
Tieto kontroly by mohli poukázať aj na chyby rozhrania a všeobecného používateľského zážitku. Napríklad používateľské rozhranie mobilnej aplikácie sa môže na inom operačnom systéme alebo rozlíšení obrazovky prezentovať inak. Zlé rozhranie môže viesť k tomu, že používatelia budú mať problémy s ovládaním tejto aplikácie.
4. Bezpečnostné nedostatky
Náhodný charakter ad-hoc testovania umožňuje pokryť celý rad bežných aj zriedkavých bezpečnostných problémov; tester môže pomocou týchto kontrol nájsť administratívne zadné vrátka programu.
Prípadne sa pri kontrole môže ukázať, že softvér nemá žiadne šifrovanie údajov.
Bežné metriky ad-hoc testovania
Ad-hoc testovanie využíva rôzne metriky na uľahčenie jeho výsledkov vrátane:
1. Účinnosť detekcie chýb
Táto metrika sa zaoberá tým, ako efektívne je proces testovania pri hľadaní chýb v každej forme testovania vrátane ad hoc testovania. Účinnosť detekcie chýb je percento odhalených chýb vydelené celkovým počtom problémov – ukazuje, aké účinné sú testy.
2. Miera pokrytia testov
Pomocnou funkciou ad-hoc testovania je zvýšenie pokrytia kontrolou komponentov spôsobom, ktorý testovacie prípady nezohľadňujú. To znamená, že testeri sa budú snažiť radikálne zvýšiť pokrytie testov pri každej kontrole, ako len môžu.
3. Celkové trvanie testu
Ad-hoc testovanie je oveľa rýchlejšie ako iné procesy zabezpečenia kvality – a je nevyhnutné, aby testeri pracovali na udržaní tejto výhody. Metriky trvania testov ukazujú členom tímu, ako môžu ušetriť čas a ešte viac znásobiť výhody ad-hoc stratégií.
4. Počet havárií
Cieľom týchto testov je často rozbiť softvér a spôsobiť pád alebo závažnú chybu, čo im umožňuje ísť nad rámec typických testovacích stratégií a nájsť neočakávané problémy. Na tento účel môže pomôcť zistiť, ako často softvér padá a čo je príčinou týchto problémov.
5 najlepších nástrojov na testovanie ad hoc
Na ad-hoc testovanie v oblasti testovania softvéru je k dispozícii mnoho bezplatných aj platených testovacích nástrojov – päť najlepších je nasledujúcich:
1. ZAPTEST Free & Enterprise Edition
ZAPTEST je komplexný program na testovanie softvéru, ktorý poskytuje silnú úroveň funkcií testovania + RPA v bezplatnej aj podnikovej verzii.
Tento kompletný balík na automatizáciu softvéru + RPA Suite umožňuje úplné testovanie na rôznych počítačových a mobilných platformách; technológia 1SCRIPT softvéru tiež umožňuje používateľom ľahko vykonávať rovnaké kontroly opakovane. Okrem toho nástroj využíva najmodernejšie počítačové videnie, ktoré umožňuje, aby ZAPTEST vykonával ad-hoc testy z pohľadu človeka.
2. BrowserStack
BrowserStack je cloudová platforma, ktorá dokáže uľahčiť testovanie na viac ako 3 000 rôznych počítačoch, navyše s možnosťou automatizácie skriptov Selenium. Hoci poskytuje silné pokrytie pre softvérové projekty, najlepšie funguje s prehliadačom a mobilnými aplikáciami.
Riešenia na testovanie BrowserStack obsahujú aj bezplatnú skúšobnú verziu so 100 minútami automatizovaného testovania, ktorá však môže mať obmedzené využitie.
Hoci cloudový prístup môže byť užitočný, negatívne ovplyvňuje aj čas odozvy platformy.
3. LambdaTest
LambdaTest podobne využíva cloudovú technológiu a kladie veľký dôraz na testovanie v prehliadači, čo môže obmedziť jeho účinnosť pri iných aplikáciách – hoci sa stále dobre hodí pre programy pre iOS a Android. Táto platforma je užitočná v prípade, že ide o škálovateľnosť, a je integrovaná s mnohými ďalšími testovacími hostingovými službami.
Niektorí používatelia však majú zmiešané reakcie na ceny aplikácie v rôznych dostupných možnostiach bez skúšobnej verzie, čo môže obmedziť dostupnosť pre menšie organizácie.
4. TestRail
TestRail je vo všeobecnosti pomerne prispôsobivý vďaka tomu, že beží výhradne v prehliadači, a napriek silnému zameraniu na efektívne testovacie prípady sa môže pochváliť aj priamymi ad-hoc funkciami. Analýza, ktorú poskytuje po každom teste, môže pomôcť aj tímom, ktoré sa aktívne vyhýbajú tvorbe vlastnej nezávislej dokumentácie, a zároveň im umožňuje overiť ich proces testovania.
Väčšie súbory však môžu mať problémy s formátom založeným na prehliadači, čo môže výrazne obmedziť časovú úsporu pri ad-hoc testovaní.
5. Zephyr
Zephyr je platforma na správu testov od spoločnosti SmartBear, ktorá pomáha tímom zabezpečujúcim kvalitu zlepšiť prehľad o testovaní a zároveň sa dobre integruje s iným softvérom na sledovanie chýb.
Táto funkcia je však obmedzená na určité aplikácie, pričom najviac zo Zephyru profitujú Confluence a Jira – tieto aplikácie však nemusia byť najefektívnejším riešením pre každú firmu. Pod značkou Zephyr je k dispozícii niekoľko škálovateľných programov za rôzne ceny.
Kontrolný zoznam testovania Ad-Hoc, tipy a triky
Tu sú ďalšie tipy pre tímy, ktoré by mali zohľadniť pri vykonávaní ad-hoc testovania:
1. Stanovenie priorít citlivých komponentov
Niektoré funkcie alebo komponenty sú prirodzene vystavené väčšiemu riziku chyby ako iné, najmä ak sú dôležité pre celkovú funkciu programu.
Každý prístup k testovaniu by mal identifikovať časti aplikácie, ktorým by bolo vhodné venovať dôkladnejšiu pozornosť. To je užitočné najmä vtedy, keď je celkový čas na testovanie obmedzený.
2. Preskúmajte rôzne testovacie nástroje
Nástroj, ktorý organizácia implementuje na uľahčenie svojich testov, môže ovplyvniť pokrytie a spoľahlivosť týchto kontrol.
Pri ad-hoc testovaní sa oplatí preskúmať čo najviac programov a nájsť tie, ktoré vyhovujú jeho používateľskému aspektu. Softvér, ktorý využíva technológiu počítačového videnia, ako napríklad ZAPTEST, môže pristupovať k ad-hoc testom pomocou stratégie podobnej ľudskej.
3. Osvojte si ad-hoc myslenie
Ad-hoc testovanie ponúka obrovskú slobodu v celej fáze zabezpečenia kvality, ale tím sa mu musí venovať, aby získal kľúčové výhody tejto stratégie.
Napríklad ad-hoc testeri by mali upustiť od všetkých svojich obvyklých dokumentov okrem základných poznámok a musia kontrolovať softvér z úplne novej perspektívy.
4. Dôverujte testovacím inštinktom
Skúsenosti s ad-hoc testovaním alebo všeobecnými kontrolami softvéru môžu pomôcť upozorniť na bežné body zlyhania a to pomôže testerom určiť, ako odhaliť chyby všetkých typov.
Je veľmi dôležité, aby testeri dôverovali svojim inštinktom a vždy využívali tieto znalosti vo svoj prospech – môžu intuitívne odhadnúť, ktoré ad-hoc kontroly by boli najužitočnejšie.
5. Úplné zaznamenávanie objavených chýb
Hoci ad-hoc testovanie nemá formálnu dokumentáciu a väčšinou sa spolieha na neformálne poznámky, stále je dôležité, aby tím dokázal identifikovať a oznámiť príčinu chyby softvéru.
Musia zaznamenať všetky informácie, ktoré test poskytuje a ktoré sú dôležité pre vývojárov, napríklad všetky potenciálne príčiny týchto problémov.
6. Vždy berte ohľad na používateľa
Každá forma testovania sa snaží do určitej miery prispôsobiť celkovému zážitku používateľa – a ad-hoc testovanie nie je výnimkou. Hoci sa často pozerá hlbšie na vnútorné fungovanie aplikácie a dokonca aj na jej interný kód, ad-hoc testeri by sa mali pokúsiť tento softvér narušiť spôsobmi, ktoré by používatelia teoreticky mohli.
7. Neustále zlepšovanie procesu
Testovacie tímy by mali zdokonaliť svoj prístup k ad-hoc testovaniu medzi viacerými iteráciami toho istého softvéru a medzi jednotlivými projektmi.
Môžu zbierať spätnú väzbu od vývojárov, aby zistili, ako dobre ich ad-hoc testy pomohli vo fáze zabezpečenia kvality a či sa im podarilo výrazne zvýšiť pokrytie testami.
Záver
Ad-hoc testovanie môže pomôcť organizáciám všetkých typov overiť ich stratégiu testovania softvéru, ale spôsob, akým túto techniku implementujú, môže byť významným faktorom jej účinnosti.
Kľúčom k dosiahnutiu čo najväčšieho prínosu z ad-hoc kontrol je vyváženie rôznych typov testovania – najmä preto, že táto forma testovania má za cieľ doplniť ostatné tým, že vyplní strategickú medzeru.
S aplikáciou, ako je ZAPTEST, môžu tímy vykonávať ad-hoc testy s väčšou istotou alebo flexibilitou, najmä ak implementujú automatizáciu. Bez ohľadu na konkrétny prístup tímu by jeho odhodlanie k ad-hoc testovaniu mohlo spôsobiť revolúciu v celom programe alebo projekte.
