Menu

Ad-hoc testování: Jak najít vady bez formálního procesu testování

ad hoc testing how find defects without formal testing process

Vyzkoušejte Náš Nástroj Pro Odstranění Problémů

Samotný termín ad-hoc naznačuje nedostatek struktury nebo něco, co není metodické. Když mluvíš o ad-hoc testování , to znamená, že se jedná o formu a Černá skříňka nebo testování chování prováděné bez zavedeného formálního procesu.

Formální proces zde znamená mít dokumentaci, jako jsou dokumenty s požadavky, testovací plány, testovací případy a správné plánování testů, pokud jde o jeho harmonogram a pořadí provedených testů. Žádné akce prováděné během testování také nejsou obvykle dokumentovány.

Ad-hoc testování

Děje se to hlavně s cílem pokusit se odhalit vady nebo nedostatky, které nelze zachytit tradičními nebo formálními procesy, které se používají během testovacího cyklu.

Jak již bylo pochopeno, podstata tohoto testování spočívá v tom, že nemáme formální nebo strukturovaný způsob testování. Je-li prováděn takový druh technik náhodného testování, je zřejmé, že testeři to provádějí bez konkrétního případu použití s ​​cílem rozbít systém.

Proto je určitě ještě jasnější, že takováto intuitivní nebo kreativní metodika testování vyžaduje tester je extrémně zručný, schopný a má hluboké know-how o systému. Ad-hoc testování zajišťuje, že provedené testování je kompletní a je obzvláště velmi užitečné při určování účinnosti testovacího bloku.

Doporučené čtení=> Průzkumné testování - Jak přemýšlet nad rámec tradičních hranic testování?

Co se naučíte:

Začněme příkladem testování ad hoc

Zde je příklad toho, jak můžeme provést toto testování, pokud jde o Průvodce uživatelským rozhraním.

Řekněme, že je třeba vytvořit plán nebo šablonu pro nějaký druh úkolu, který má být proveden pomocí tohoto průvodce uživatelským rozhraním. Průvodce je řada podoken, která obsahují uživatelské údaje, jako je jméno, popis atd.

Jak postupuje průvodce: řekněme na jednom z podoken, je třeba zadat uživatelská data, která zahrnují průvodce uživatelským rozhraním, který vyvolá kontextové vyskakovací okno, které přidá související data k dokončení průvodce a nasazení / aktivaci průvodce.

K testování tohoto testeru se pravidelně testuje, například:

nejlepší textový editor pro python mac
  • Dokončete průvodce úspěšně se všemi platnými údaji a vytvořte plán.
  • Zrušte průvodce uprostřed cesty.
  • Upravte vytvořený plán pomocí průvodce.
  • Smažte vytvořený plán a uvidíte, že z něj nezůstaly žádné zbytky.
  • Zadejte v průvodci zápornou hodnotu a podívejte se, zda se zobrazují příslušné chybové zprávy.

Nyní pro výše uvedený příklad Zde je několik testovacích případů pro testy ad-hoc které by mohly být provedeny odhalit co nejvíce vad:

  • Při pokusu o přidání negativních dat přidejte určité speciální znaky, které nejsou omezeny, abyste zjistili, zda jsou zpracovány správně. Například, někdy čarodějové neomezují {nebo (složené závorky, ale v určitých situacích to může být v rozporu s kódem založeným na jazyce, ve kterém je napsán, a způsobit velmi nespolehlivé chování.
  • Další test se týká konkrétně vyskakovacích oken. Uživatel může způsobit spuštění vyskakovacího okna a poté zkusit stisknout tlačítko backspace na klávesnici. Mnohokrát jsem si všiml, že díky tomu průvodce na pozadí úplně zmizí a všechna uživatelská data, která byla zadána, až do okamžiku, kdy bylo spuštěno vyskakovací okno, budou ztracena!

Charakteristika testování ad-hoc:

Pokud si všimnete výše uvedených scénářů, uvidíte něco velmi charakteristického pro tento typ testování.

Oni jsou:

  • Vždy odpovídají cíli testu. Jsou to však určité drastické testy prováděné s úmyslem rozbít systém.
  • Tester musí mít úplné znalosti a povědomí o testovaném systému. Výsledek tohoto testování najde chyby, které se pokusí zvýraznit mezery v procesu testování.
  • Při pohledu na výše uvedené dva testy by přirozenou reakcí na to bylo, že - tento druh testu lze provést pouze jednou, protože není možné provést opakovaný test, pokud není spojena závada.

Kdy provádíme testování ad hoc?

Skutečně otázka za milion dolarů!

Většina časových testovacích týmů je vždy zatížena příliš mnoha funkcemi na testování v omezených časových lhůtách. V tomto omezeném časovém rozpětí existuje spousta testovacích aktivit, které jsou odvozeny z formálního procesu, který je také nutné dokončit. V takových situacích je testování ad-hoc velmi obtížné.

Z mých zkušeností však jedno kolo ad-hoc testování dokáže zázraky s kvalitou produktu a vyvolá mnoho designových otázek.

Vzhledem k tomu, že testování ad-hoc je spíše technikou testování „divokého dítěte“, které nemusí být strukturované, obecné doporučení je, že je nutné provést po provedení aktuálního testovacího bloku. Dalším hlediskem je, že by to mohlo být provedeno, když nelze provést podrobné testování z důvodu kratší doby.

Podle mého názoru bych to řekl ad-hoc testování lze provádět téměř kdykoli - na začátku, do středu a ke konci! Prostě si najde své místo v daném okamžiku. Pokud je však nutné provést testování ad-hoc, aby se dosáhlo maximální hodnoty, nejlépe to posoudí zkušený tester, který má důkladné znalosti o testovaném systému.

Kdy ne provést?

Pokud předchozí otázka měla hodnotu milionu dolarů, měla by mít hodnotu miliardy!

I když jsme zjistili, jak efektivní a plodné může být testování ad hoc, jako zkušený a schopný tester také musíme dešifrovat, když do tohoto typu testování neinvestujeme. Tady je, i když je na uvážení testera několik doporučení / příkladů, když to nemusí být nutné.

  • Vyhněte se tomuto testování, pokud existuje testovací případ, pro který existuje vada. V takové situaci je třeba dokumentovat bod selhání testovacího případu a poté ověřit / znovu otestovat vadu, když je opravena. Proto to zde nebude použitelné.
  • Mohou také nastat určité scénáře, kam mohou být zákazníci nebo klienti pozváni otestujte beta verzi softwaru . V takových případech by toto testování nemělo být prováděno.
  • Dalším scénářem je situace, kdy je přidána velmi jednoduchá obrazovka uživatelského rozhraní. K dosažení maximálních defektů by zde mělo stačit tradiční pozitivní a negativní testování.

Druhy testování ad hoc

Testování ad hoc lze rozdělit do tří kategorií níže:

# 1) Testování kamaráda

V této formě testování bude člen testu a člen vývoje, kteří budou vybráni pro práci na stejném modulu. Těsně po vývojář dokončí testování jednotky , tester a vývojář sedí spolu a pracovat na modulu. Tento druh testování umožňuje, aby byla funkce zobrazena v širším rozsahu pro obě strany.

Vývojář získá pohled na všechny různé testy, které tester spustí, a tester získá pohled na to, jak je vlastní design, který mu pomůže vyhnout se navrhování neplatných scénářů, čímž zabrání neplatným vadám. Pomůže jednomu myslet jako myslet druhému.

# 2) Testování párů

V tomto testování dva testeři spolupracují na modulu se stejným testovacím nastavením sdíleným mezi nimi. Myšlenkou této formy testování je, aby dva testeři brainstormovali nápady a metody, které mají řadu závad. Oba mohou sdílet práci s testováním a vytvářet potřebnou dokumentaci o všech provedených pozorováních.

# 3) Testování opic

Toto testování se provádí hlavně na úrovni testování jednotky. Tester analyzuje data nebo testy zcela náhodným způsobem, aby zajistil, že systém bude schopen odolat jakýmkoli haváriím. Toto testování lze dále rozdělit do dvou kategorií:

který vr pracuje s Xbox One

Výhody testování ad-hoc

Testování zaručuje, že tester má spoustu síly, aby byl podle potřeby tak kreativní.

To zvyšuje kvalitu a účinnost testování, jak je uvedeno níže:

  • Největší výhodou, která vyniká, je to, že tester může najít počet vad než v tradičním testování, a to díky různým inovativním metodám, které mohou použít k testování softwaru.
  • Tuto formu testování lze použít kdekoli v SDLC; není omezeno pouze na testovací tým. Vývojáři mohou také provést toto testování, které by jim pomohlo lépe kódovat a také předpovědět, jaké problémy by mohly nastat.
  • Lze jej spojit s dalším testováním, aby bylo dosaženo nejlepších výsledků, což může někdy zkrátit čas potřebný pro pravidelné testování. To by umožnilo generovat kvalitnější testovací případy a celkově lepší kvalitu produktu.
  • Nepožaduje provedení žádné dokumentace, která by zabránila další zátěži pro testera. Tester se může soustředit na skutečné porozumění základní architektuře.
  • V případech, kdy na testování není k dispozici mnoho času, se to může ukázat jako velmi cenné z hlediska pokrytí a kvality testu.

Nevýhody testování ad-hoc

Ad-hoc testování má také několik nevýhod. Pojďme se podívat na některé z nevýhody, které se vyslovují:

Jelikož to není příliš organizované a není nařízena žádná dokumentace, nejzřetelnějším problémem je, že si tester musí pamatovat a pamatovat všechny podrobnosti ad-hoc scénářů v paměti. To může být ještě náročnější, zejména ve scénářích, kde dochází k velké interakci mezi různými komponentami.

  • Z prvního bodu vyplývá, že by to také vedlo k tomu, že kdybychom byli požádáni o informace, nebyli bychom schopni znovu vytvořit vady v následných pokusech.
  • Další velmi důležitou otázkou, kterou toto ukazuje na světlo, je odpovědnost za úsilí. Protože to není plánováno / strukturováno, neexistuje způsob, jak zohlednit čas a úsilí investované do tohoto druhu testování.
  • Testování ad hoc musí provádět pouze velmi dobře informovaný a zkušený tester v týmu, protože vyžaduje proaktivitu a intuici, pokud jde o předvídání potenciálních defektů.

Osvědčené postupy pro zefektivnění testování

Podrobně jsme diskutovali o silných a slabých stránkách souvisejících s tímto testováním.

V ideálním případě by si testování ad-hoc mělo najít své místo v SDLC, pokud se však k němu nepřistoupí vhodným způsobem, může se ukázat jako nákladné a jako ztráta cenného času na testování. Níže je uvedeno několik ukazatelů, díky nimž bude testování ad-hoc účinné:

# 1) Určete oblasti náchylné k defektům:

Pokud budete mít dobrou kontrolu nad testováním konkrétního softwaru, budete souhlasit s tím, že budou existovat určité funkce, které jsou náchylnější k chybám než ostatní. Pokud jste v systému noví, pokračujte a zkontrolujte defekty funkcí proti nim otevřené.

Počet defektů konkrétní funkce vám ukáže, že je citlivá, a měli byste si přesně zvolit právě tuto oblast, abyste mohli provádět testování ad-hoc. To se ukazuje jako časově velmi efektivní způsob odhalení některých závažných vad.

# 2) Budování odborných znalostí:

Tester, který má více zkušeností, je nepochybně intuitivnější a dokáže odhadnout, kde by chyby mohly být, ve srovnání s někým, kdo nemá mnoho zkušeností. Řekl bych, zkušený nebo ne, je na jednotlivci, aby se ponořil a vybudoval odborné znalosti v systému, který je testován.

Ano, zkušení testeři mají výhodu, protože jejich dovednosti získané v průběhu let přicházejí vhod, ale noví testeři by to měli používat jako platformu, aby získali co nejvíce znalostí k navrhování lepších scénářů ad hoc.

# 3) Vytvořte testovací kategorie:

Jakmile jste si vědomi seznamu funkcí, které mají být testovány, vyčkejte několik minut na rozhodnutí, jak byste tyto funkce kategorizovali a otestovali. Například, měli byste se rozhodnout otestovat funkce, které jsou nejviditelnější a nejčastěji používané uživatelem, než cokoli jiného, ​​protože by se zdály rozhodující pro úspěch softwaru.

Pak byste je mohli kategorizovat podle funkčnosti / priority a testovat je segment po segmentu.

Dalším příkladem, kde je to obzvláště velmi důležité, je integrace mezi součástmi nebo moduly. V těchto případech může dojít k mnoha abnormalitám. Použití kategorizace by pomohlo dotknout se tohoto druhu testu alespoň jednou nebo dvakrát.

# 4) Mějte hrubý plán:

Ano, ano, tento bod vás může trochu zmást, protože jsme popsali ad-hoc testování jako testování, které by nemělo mít žádné plánování ani dokumentaci. Myšlenkou je držet se podstaty testování ad-hoc, ale přesto si nechejte zapsat některé hrubé ukazatele o tom, jak plánujete testovat.

Velmi základním příkladem je, že si někdy nebudete moci pamatovat všechny testy, které chcete provést. Jejich zaznamenání by tedy zajistilo, že vám nic neunikne.

# 5) Nástroje:

Uveďme si příklad, kterému se každý z nás velmi často potýká. Mnohokrát, pokud si všimnete, testování samotné funkce je úspěšné, přičemž v jeho chování nejsou hlášeny žádné nesrovnalosti. Protokoly ze zákulisí by však mohly hlásit některé zjištěné výjimky, které by testeři mohli vynechat, protože to nijak neomezuje cíl testu.

Mohly by mít dokonce vysokou závažnost. Proto je pro nás velmi důležité učit se a používat nástroje, které nám to pomohou okamžitě určit.

# 6) Dokument pro další vady:

Opět chápu, že to může znovu zvednout obočí. Dokumentace nemusí být podrobná, ale pouze malá poznámka pro vlastní odkaz na všechny různé scénáře, které jsou zahrnuty, odchylku v příslušných krocích a zaznamenat tyto vady pro konkrétní kategorii testovacích funkcí.

To vám pomůže vylepšit také celkový testovací segment, díky kterému se můžete rozhodnout, jak improvizovat existující testovací případy nebo v případě potřeby přidat další.

Závěr

Podrobně jsme diskutovali o technikách testování ad-hoc - jeho silných a slabých stránkách, situacích, kdy by to bylo a nebylo prospěšné.

Toto je jedna testovací technika, která zaručuje maximální uspokojení a uspokojení kreativity testera. V celém mém testovací kariéra „Z ad-hoc testování získávám maximální uspokojení, protože inovace nejsou nijak omezeny a nakonec získáte jen lepší znalosti.

Hlavní věcí, kterou je třeba vzít zpět ze všech výše uvedených informací, by bylo zjistit, jak využít silné stránky testování ad hoc a zvýšit přidanou hodnotu k celkovému procesu testování a kvalitě produktu.

O autorovi: Toto je hostující článek Snehy Nadigové. Pracuje jako testovací vedoucí s více než 7 lety zkušeností v ručních a automatizačních testovacích projektech.

Provádíte na svém projektu testování ad hoc? Jaké jsou vaše návrhy, aby bylo testování Ad-hoc úspěšné?

Doporučené čtení

^