Menu

Ad-hoc testovanie: Ako nájsť chyby bez procesu formálneho testovania

ad hoc testing how find defects without formal testing process

Vyskúšajte Náš Nástroj Na Odstránenie Problémov

Samotný termín ad-hoc naznačuje nedostatok štruktúry alebo niečo, čo nie je metodické. Keď hovoríš o ad-hoc testovanie , znamená to, že ide o formu a čierna krabica alebo testovanie správania vykonané bez zavedenia formálneho procesu.

Formálny proces tu znamená mať dokumentáciu ako dokumenty s požiadavkami, plány testov, testovacie prípady a správne plánovanie testu z hľadiska jeho harmonogramu a poradia vykonaných testov. Taktiež nie sú zvyčajne zdokumentované žiadne akcie vykonané počas testovania.

Ad-hoc testovanie

Robí sa to hlavne s cieľom pokúsiť sa odhaliť chyby alebo nedostatky, ktoré nemožno zachytiť tradičnými alebo formálnymi postupmi, ktoré sa dodržiavajú počas testovacieho cyklu.

Ako už bolo pochopené, podstata tohto testovania spočíva v tom, že neexistuje formálny alebo štruktúrovaný spôsob testovania. Je zrejmé, že keď sa vykonáva tento druh náhodných testovacích techník testeri to vykonávajú bez toho, aby mali na pamäti konkrétny prípad použitia s cieľom rozbiť systém.

Preto je určite ešte zjavnejšie, že takáto metodika intuitívneho alebo kreatívneho testovania vyžaduje tester musí byť mimoriadne zručný, schopný a mať podrobné znalosti systému. Ad-hoc testovanie zaisťuje, že vykonané testy sú úplné a sú obzvlášť užitočné pri určovaní efektívnosti testovacej nádoby.

Odporúčané čítanie=> Prieskumné testovanie - Ako myslieť nad tradičné hranice testovania?

Čo sa dozviete:

Začnime príkladom testovania ad hoc

Tu je príklad toho, ako môžeme vykonať toto testovanie, pokiaľ ide o UI Wizard.

Povedzme, že je potrebné vytvoriť plán alebo šablónu pre nejaký druh úlohy, ktorá sa má vykonať pomocou tohto sprievodcu používateľským rozhraním. Sprievodca je séria tabúľ, ktoré obsahujú vstupy používateľov, napríklad meno, popis atď.

Ako sprievodca postupuje: povedzme na jednom z panelov, je potrebné zadať používateľské údaje, ktoré zahŕňajú sprievodcu používateľským rozhraním, ktorý vyvolá kontextové vyskakovacie okno, ktoré pridá súvisiace údaje na dokončenie sprievodcu a nasadenie / aktiváciu sprievodcu.

Na testovanie tohto testera sa pravidelne testuje, napríklad:

pokročilé otázky a odpovede na sql pdf
  • Dokončite sprievodcu úspešne všetkými platnými údajmi a vytvorte plán.
  • Zrušte sprievodcu v polovici cesty.
  • Upravte vytvorený plán pomocou sprievodcu.
  • Odstráňte vytvorený plán a skontrolujte, či z neho nezostali zvyšky.
  • Zadajte zápornú hodnotu v sprievodcovi a uvidíte príslušné chybové správy.

Teraz pre vyššie uvedený príklad tu je niekoľko testovacích prípadov pre testy ad-hoc ktoré by sa dali vykonať odhaliť čo najviac defektov:

  • Pri pokuse o pridanie negatívnych údajov pridajte určité špeciálne znaky, ktoré nie sú obmedzené, aby ste zistili, či sa s nimi zaobchádza správne. Napríklad, niekedy čarodejníci neobmedzujú {alebo (zložené zátvorky, ale v určitých situáciách to môže byť v rozpore s kódom založeným na jazyku, v ktorom je napísaný, a spôsobiť veľmi nespoľahlivé správanie.
  • Ďalšia skúška sa týka konkrétne vyskakovacích okien. Používateľ môže spôsobiť spustenie vyskakovacieho okna a potom skúsiť stlačiť tlačidlo backspace na klávesnici. Mnohokrát som si všimol, že to úplne spôsobí, že sprievodca pozadím úplne zmizne a stratia sa všetky používateľské údaje, ktoré boli zadané až do okamihu spustenia vyskakovacieho okna!

Charakteristika testovania ad hoc:

Ak si všimnete vyššie uvedené scenáre, uvidíte veľmi charakteristické vlastnosti tohto typu testovania.

Oni sú:

  • Vždy zodpovedajú cieľu testu. Sú to však určité drastické testy vykonané s úmyslom rozbiť systém.
  • Tester musí mať úplné vedomosti a vedomosti o testovanom systéme. Výsledkom tohto testovania sú chyby, ktoré sa snažia zvýrazniť medzery v testovacom procese.
  • Pri pohľade na dva vyššie uvedené testy by bolo prirodzenou reakciou aj to, že - tento druh testu je možné vykonať iba raz, pretože nie je možné vykonať nový test, pokiaľ nie je spojená chyba.

Kedy robíme testy ad hoc?

Skutočne otázka za milión dolárov!

Väčšina časových testovacích tímov je vždy zaťažená príliš veľkým počtom funkcií na testovanie v obmedzených časových harmonogramoch. V tomto obmedzenom časovom rozpätí existuje veľa testovacích aktivít odvodených z formálneho procesu, ktorý je tiež potrebné dokončiť. V takýchto situáciách je ad-hoc testovanie nenáročné, aby sa dostalo do testovania.

Z mojej skúsenosti však jedno kolo ad-hoc testovania dokáže zázraky s kvalitou produktu a nastolí veľa dizajnových otázok.

Pretože testovanie ad hoc je skôr technikou testovania „divokého dieťaťa“, ktorá nemusí byť štruktúrovaná, všeobecné odporúčanie je, že sa musí vykonať po vykonaní aktuálneho testovacieho segmentu. Ďalším hľadiskom je, že by sa to dalo urobiť, keď nie je možné vykonať podrobné testovanie z dôvodu kratšieho času.

Podľa môjho názoru by som to povedal ad-hoc testovanie je možné vykonať takmer kedykoľvek - na začiatku, do stredu a na koniec! Proste si kedykoľvek nájde svoje miesto. Ak je však potrebné vykonať testovanie ad hoc, aby sa dosiahla maximálna hodnota, najlepšie to posúdi skúsený tester, ktorý má dôkladné znalosti o testovanom systéme.

Kedy nepopraviť?

Ak mala predchádzajúca otázka milión dolárov, mala by to byť miliarda!

Aj keď sme zistili, aké efektívne a plodné môže byť ad hoc testovanie, ako kvalifikovaný a schopný tester musíme tiež dešifrovať, kedy do tohto typu testovania neinvestovať. Aj keď je to na uvážení testera, tu sú niekoľko odporúčaní / príkladov, keď to nemusí byť potrebné.

  • Vyhnite sa tomuto testovaniu, ak existuje testovací prípad, pre ktorý existuje chyba. V takejto situácii je potrebné dokumentovať bod zlyhania testovacieho prípadu a potom overiť / znovu otestovať chybu, keď je opravená. Preto to tu nebude možné použiť.
  • Môžu existovať aj určité scenáre, kam môžu byť zákazníci alebo klienti pozvaní otestujte beta verziu softvéru . V takýchto prípadoch by sa toto testovanie nemalo vykonávať.
  • Ďalším scenárom je prípad, keď je pridaná veľmi jednoduchá obrazovka používateľského rozhrania. Na zistenie maximálnych chýb by malo stačiť tradičné pozitívne a negatívne testovanie.

Typy testovania ad hoc

Ad-hoc testovanie možno rozdeliť do troch kategórií nižšie:

# 1) Buddy Testovanie

V tejto forme testovania bude člen testu a člen vývoja, ktorí budú vybraní pre prácu na rovnakom module. Hneď po vývojár dokončí testovanie jednotky , tester a vývojár sedia spolu a pracovať na module. Tento druh testovania umožňuje prezerať si túto funkciu v širšom rozsahu pre obe strany.

Vývojár získa prehľad o všetkých rôznych testoch, ktoré tester vykoná, a tester získa prehľad o tom, aký je vlastný dizajn, ktorý mu pomôže vyhnúť sa navrhovaniu neplatných scenárov, čím zabráni neplatným chybám. Pomôže to jednému myslieť ako myslieť druhému.

# 2) Testovanie párov

Pri tomto testovaní spolupracujú dvaja testeri na module s rovnakým zdieľaným testovacím nastavením. Myšlienka tejto formy testovania spočíva v tom, aby dvaja testeri prediskutovali nápady a metódy, ktoré majú mať množstvo chýb. Obaja môžu zdieľať prácu na testovaní a pripraviť potrebnú dokumentáciu o všetkých vykonaných pozorovaniach.

# 3) Testovanie opíc

Toto testovanie sa vykonáva hlavne na úrovni testovania jednotiek. Tester analyzuje údaje alebo testy úplne náhodným spôsobom, aby sa zabezpečilo, že systém bude schopný odolať všetkým pádom. Toto testovanie možno ďalej rozdeliť do dvoch kategórií:

najlepšia mobilná špionážna aplikácia pre iphone

Výhody testovania ad hoc

Testovanie zaručuje testerovi dostatok sily na to, aby bol podľa potreby kreatívny.

To zvyšuje kvalitu a účinnosť testovania, ako je uvedené nižšie:

  • Najväčšou výhodou, ktorá vyniká, je to, že tester dokáže nájsť počet chýb ako pri tradičnom testovaní, a to vďaka rôznym inovatívnym metódam, ktoré môžu na testovanie softvéru použiť.
  • Túto formu testovania je možné použiť kdekoľvek v SDLC; neobmedzuje sa iba na testovací tím. Vývojári môžu tiež vykonať toto testovanie, ktoré by im pomohlo lepšie kódovať a tiež predpovedať, aké problémy môžu nastať.
  • Môže byť spojený s ďalším testovaním, aby sa dosiahli najlepšie výsledky, ktoré niekedy môžu skrátiť čas potrebný na pravidelné testovanie. To by umožnilo generovať kvalitnejšie testovacie prípady a celkovo lepšiu kvalitu produktu.
  • Nestanovuje, že je potrebné vykonať akúkoľvek dokumentáciu, ktorá zabráni ďalšiemu zaťaženiu testera. Tester sa môže sústrediť na skutočné pochopenie základnej architektúry.
  • V prípadoch, keď na testovanie nie je k dispozícii veľa času, sa to môže ukázať ako veľmi cenné z hľadiska pokrytia a kvality testu.

Nevýhody pri testovaní ad hoc

Ad-hoc testovanie má tiež niekoľko nevýhod. Pozrime sa na niektoré z nich nevýhody, ktoré sa vyslovujú:

Pretože to nie je veľmi organizované a nie je k dispozícii žiadna povinná dokumentácia, najviditeľnejším problémom je, že tester si musí pamätať a pamätať všetky podrobnosti ad-hoc scenárov v pamäti. To môže byť ešte náročnejšie, najmä v scenároch, kde dochádza k veľkej interakcii medzi rôznymi komponentmi.

  • Ako vyplýva z prvého bodu, viedlo by to tiež k tomu, že by sa v prípade žiadosti o informácie nepodarilo znovu vytvoriť chyby v následných pokusoch.
  • Ďalšou veľmi dôležitou otázkou, ktorá vychádza na svetlo, je zodpovednosť za úsilie. Pretože to nie je plánované / štruktúrované, neexistuje žiadny spôsob, ako zohľadniť čas a úsilie investované do tohto druhu testovania.
  • Ad-hoc testovanie musí vykonávať iba veľmi dobre informovaný a kvalifikovaný tester v tíme, pretože vyžaduje proaktivitu a intuíciu, pokiaľ ide o predvídanie potenciálnych defektov jazdených oblastí.

Najlepšie postupy na zefektívnenie testovania

Dlho sme diskutovali o silných a slabých stránkach spojených s týmto testovaním.

V ideálnom prípade by si testovanie ad hoc malo nájsť miesto v SDLC, avšak ak sa k nemu nepristúpi vhodným spôsobom, môže sa ukázať ako nákladné a ako strata drahocenného času na testovanie. Nižšie uvádzame niekoľko rád, vďaka ktorým bude testovanie ad hoc efektívne:

# 1) Identifikujte oblasti náchylné na chyby:

Ak budete mať dobrý pocit z testovania konkrétneho softvéru, budete súhlasiť s tým, že existujú určité funkcie, ktoré sú náchylnejšie na chyby ako ostatné. Ak ste v systéme noví, pokračujte a skontrolujte v / s defekty funkcií, ktoré sa proti nim otvorili.

Počet chýb v konkrétnej funkcii vám ukáže, že je citlivá a mali by ste si presne zvoliť práve túto oblasť na vykonanie ad-hoc testovania. Toto sa ukazuje ako časovo veľmi efektívny spôsob odhalenia niektorých závažných chýb.

# 2) Stavebné odborné znalosti:

Tester, ktorý má viac skúseností, je nepochybne intuitívnejší a dokáže odhadnúť, kde môžu byť chyby, v porovnaní s niekým, kto nemá veľa skúseností. Povedal by som, skúsený alebo nie, je na jednotlivcovi, aby sa odhodlal a vybudoval odborné znalosti o testovanom systéme.

Áno, skúsení testeri majú výhodu, pretože ich zručnosti získané v priebehu rokov sa im budú hodiť, ale noví testeri by to mali využívať ako platformu na získanie čo najväčšieho množstva vedomostí na navrhovanie lepších scenárov ad hoc.

# 3) Vytvorte testovacie kategórie:

Keď sa dozviete o zozname funkcií, ktoré sa majú testovať, vyhraďte si pár minút na rozhodnutie, ako by ste tieto funkcie kategorizovali a otestovali. Napríklad, mali by ste sa rozhodnúť otestovať funkcie, ktoré sú najviac viditeľné a najbežnejšie používané používateľom, skôr ako čokoľvek iné, pretože by sa zdalo rozhodujúce pre úspech softvéru.

Potom by ste ich mohli kategorizovať funkčne / prioritne a testovať ich segment po segmente.

Ďalším príkladom, kde je to obzvlášť dôležité, je integrácia medzi komponentmi alebo modulmi. V týchto prípadoch môže dôjsť k mnohým abnormalitám. Použitie kategorizácie by pomohlo dotknúť sa tohto druhu testu aspoň raz alebo dvakrát.

# 4) Pripravte si hrubý plán:

Áno, áno, tento bod vás môže trochu zmiasť, pretože sme testovanie ad-hoc opísali ako testovanie, ktoré by nemalo obsahovať žiadne plánovanie ani dokumentáciu. Ide o to, držať sa podstaty testovania ad-hoc, ale napriek tomu si treba nechať pár hrubých odkazov na to, ako plánujete testovať.

Veľmi základným príkladom je, že si niekedy nebudete môcť spomenúť na všetky testy, ktoré chcete vykonať. Ak by ste si ich zapísali, zabezpečili by ste, že vám nič nebude chýbať.

# 5) Nástroje:

Zoberme si príklad, s ktorým sa všetci stretávame veľmi často. Mnohokrát, ak zistíte, je testovanie samotnej funkčnosti úspešné, pričom v jeho správaní nie sú zaznamenané žiadne nezrovnalosti. Protokoly zo zákulisia by však mohli hlásiť niektoré zaznamenané výnimky, ktoré by testerom mohli uniknúť, pretože to nijako nebráni cieľu testu.

Môžu mať dokonca vysokú závažnosť. Preto je pre nás veľmi dôležité učiť sa a používať nástroje, ktoré to pomôžu okamžite presne určiť.

# 6) Dokument pre ďalšie chyby:

Opäť chápem, že to môže znova zdvihnúť obočie. Dokumentácia nemusí byť podrobná, iba malá poznámka pre vlastnú referenciu všetkých rôznych zahrnutých scenárov, odchýlku v príslušných krokoch a zaznamenanie týchto chýb pre konkrétnu kategóriu testovacích funkcií.

Pomôže vám to vylepšiť aj celkovú skupinu testov, vďaka čomu by ste sa mohli rozhodnúť, ako improvizovať existujúce testovacie prípady alebo v prípade potreby pridať ďalšie.

Záver

Podrobne sme diskutovali o technikách testovania ad hoc - o ich silných a slabých stránkach, situáciách, kde by to bolo a nebolo prospešné.

Toto je jedna testovacia technika, ktorá zaručuje uspokojenie a maximálnu spokojnosť kreativity testera. V celom mojom testovacia kariéra „Získavam najvyššie uspokojenie z ad-hoc testov, pretože inovácie nie sú nijako limitované a nakoniec získate lepšiu znalosť.

Z tohto dôvodu by bolo najdôležitejšie vziať späť zo všetkých vyššie uvedených informácií určiť, ako využiť ad hoc silné stránky pri testovaní a ako pridať hodnotu k celkovému procesu testovania a kvalite produktu.

O autorovi: Toto je hosťujúci článok od Snehy Nadigovej. Pracuje ako vedúca testu s viac ako 7-ročnými skúsenosťami v projektoch manuálneho a automatizovaného testovania.

Vykonávate na svojom projekte ad hoc testovanie? Aké sú vaše návrhy, aby bolo testovanie Ad-hoc úspešné?

Odporúčané čítanie

^