7 testovací případ Psaní Tipy pro zlepšení procesu testování softwaru ERP
testovací případy jsou velmi důležité pro zajištění kvality v procesu testování softwaru ERP. Jsou to první kroky v testovacím cyklu a pokud testovací případy nejsou dostatečně kvalitní, bude celý projekt “zatížen”. Psaní” skvělých ” testovacích případů je dovednost, která získává formu jednoduše tím, že to dělá. Ale je velmi užitečné mít nějaké postřehy, které by vám mohly pomoci. Tímto článkem vás chci oslovit a navrhnout, aby to bylo jednodušší, zábavnější a lepší. Tipy, které budou uvedeny, se budou týkat zejména testovacích případů při akceptačním testování systémů ERP.
co jsou testovací případy?
ve světě testování softwaru existuje mnoho definic testovacích případů. Z tohoto důvodu je důležité pojmenovat naši definici. V naší filozofii jsou testovací případy (založené na IEEE610): “sada testovacích vstupů, podmínek provedení a očekávaných výsledků vyvinutých pro konkrétní cíl.”Vědět, jak psát dobré testovací případy, je velmi užitečné pro každého, kdo chce testovat. Ať už se jedná o funkční test, akceptační test uživatele, testování webové aplikace nebo modul ERP systému. Ve všech situacích popsaných výše testovací případy určit, do jaké míry výsledky dát verdikt o předem stanovených cílů.
proč je psaní testovacích případů tak těžké?
jak je popsáno v definici, testovací případy pomáhají testerům provést posloupnost zkušebních instrukcí, aby určily, zda software splňuje předem definované požadavky. Provádění testovacích případů nám pomáhá shromažďovat a objevovat informace k realizaci tohoto konkrétního cíle nebo cíle. Prvním problémem, se kterým se přímo setkáváme, je rozmanitost možných cílů. A protože existují různé typy testů a cílů, existují různé typy odpovídajících testovacích případů.
druhý problém souvisí s obsahem skutečné testovací instrukce nebo kroků. Úroveň těchto pokynů závisí na typu testeru, který musí tyto informace interpretovat a vydat názor. Profesionální tester bude potřebovat různé pokyny na rozdíl od koncového uživatele, který se podílí na akceptačním testování ERP systému
Tip 1: Určete svůj cíl a to, co chcete nahlásit
Přemýšlejte o tom, co chcete nahlásit, abyste mohli určit svůj odvozený cíl. Použití, které jako základ, máte obrys testovacího případu v pohledu. Existuje mnoho různých cílů, kde se vždy musíme ptát sami sebe, co se snažíme naučit nebo dosáhnout, když se chystáme spustit test. Zde je několik příkladů:
- zjištění závad: toto je klasický účel testování. Test se provádí za účelem odhalení vad.
- maximalizujte počet chyb: Rozdíl mezi “maximalizovat počet chyb” a “najít vady” je, že celkový počet chyb je důležitější než pokrytí.
- blokovat předčasné uvolnění produktu: cílem tohoto testu je předčasně najít tolik závažných vad (showstoppers), aby nikdo nevezal produkt do výroby.
- Podporujte manažery svými rozhodnutími go / no-go: manažeři přijímají rozhodnutí na základě rizik. Indikace rizik jako pokrytí testem, dopad zjištěných problémů atd. Poskytněte jim lepší zázemí, na kterém mohou svá rozhodnutí založit.
- posoudit shodu podle specifikace: údajné specifikace jsou kontrolovány pro jejich provoz. Všechny záležitosti, které nejsou spojeny se specifikacemi, se neberou v úvahu.
- posoudit kvalitu: to je obtížný cíl, protože kvalita je vícerozměrná. Povaha kvality závisí na povaze produktu. Pro posouzení kvality by měla být vypracována jasná kritéria, která jsou definována tak, aby mohla být skutečně měřitelná.
výsledky zkoušek odvozené ze zkušebních případů poskytují přímé relevantní informace o cíli.
Tip 2: rezervujte si dostatečný čas na návrh
Rezervujte si dostatek času na návrh testovacích případů tak, aby odpovídaly vašim cílům. Špatné testovací případy vás budou pronásledovat během celého testovacího procesu. Porovnání výsledků testů, podávání zpráv o několika testovacích kolech atd. Jsou v podstatě určeny kvalitou vašich testovacích případů.
pokud vám již dochází čas na návrh, ale přesto chcete začít testovat, ujistěte se, že jste alespoň definovali hlavní rizika. Pokud 10 testerů musí zkontrolovat 5 testovacích případů s 1 testovacím krokem, výsledkem bude 50 výsledků testů. Bez ohledu na to, co tyto výsledky 50 poskytují více informací o kvalitě a pak nedělají nic. To pravděpodobně nebude vyčerpávající, ale je to první krok. Z toho lze určit úroveň detailů určitých částí.
dáváme přednost tomu, abyste si předem mysleli, jak by měl být test navržen, a že výsledky testu dávají skutečnou odpověď na cíl. Ale ve skutečnosti je to někdy nepoddajné.
Tip 3: Název testovací případ
pojmenování testovací případy je důležité. V průměrném testu ERP máte snadno více než 500 testovacích případů. Pochopíte, že logická struktura názvů zvyšuje vyhledávatelnost. V literatuře je často označován jako úplný název, ve kterém má být testován proces, modul, objekt atd. Jsou všechny zahrnuty v názvu. Dokážete si představit, že poskytnutí 500 testovacích případů s takovým úplným názvem dává chaotickou správu. S jednoduchým listem aplikace Excel snadno ztratíte přehled. Nástroje pro správu testů poskytují strukturu, do které můžete spojit testovací případy s opakovaně použitelnými objekty, aniž by” znečišťovaly ” název. Máte také nástroje pro registraci testů, které tyto vztahy organizují jiným způsobem.
v rámci Testmonitoru jsme například vymysleli jiné řešení. V nástroji můžete definovat štítky nebo značky, které pak můžete propojit s testovacími případy. V rámci TestMonitor testovací případy jsou spojeny s jedním nebo více obchodních procesů-, riziko-, požadavek – nebo aplikační štítky. To umožňuje seskupit a získat testovací případy z různých perspektiv.
pro název zkušebního případu v rámci Testmonitoru stačí jasný popis účelu testovacího případu. Aby to bylo jednoduché, popíšete aktivitu s implicitním očekáváním.
příklad testovací případ název:
“ukončení pronájmu nezávislého domu”
“vytvořit zákazníka” “prozatímní potvrzení o rezervaci”
atd.
příklad zkušebního případu “provizorní potvrzení o rezervaci”, které je spojeno s několika štítky:
- obchodní proces “příjem zboží”
- požadavek “smluvní požadavek”
- riziko “operační riziko”
- aplikace “ERP’
je důležité popsat očekávaný výsledek na testovací případ. Tester pak ví, kterým směrem musí být “odpověď”, a přímo získá explicitní testovací rámec.
Tip 4: Popis kroku testu
jak je popsáno v definici testovací případy jsou souborem zkušebních pokynů, které nám pomáhají objevit informace k dosažení konkrétního cíle.
zkušební případ musí mít jasný začátek a konec, aby bylo možné určit, zda zkušební případ prošel nebo selhal. Kromě toho je zkušební případ složen z jednoho nebo více zkušebních instrukcí nebo-kroků, přičemž pro dosažení požadovaného výsledku je možné více cest. Pouze testování cesty úspěchu je často nedostatečné. V určitých situacích po neúspěšných cestách může jen změnit.
je důležité definovat testovací kroky co nejjasněji, aby koncový uživatel pro test přijetí uživatele přesně věděl, co musí udělat. Samozřejmě existují předpoklady, které je třeba vymyslet, jako je tester funkční úrovně, znalost nového systému, znalost možných upravených obchodních procesů atd. Ale v podstatě každý by měl pochopit všechny testovací kroky.
Předpokládejme, že dále popíšeme testovací případ “nájemní ukončení-nezávislý domov” pro jednoduchou cestu úspěchu:
- vyberte jednotku a začněte ukončovat nájem. Kontrolujte, zda existují předpoklady, mezi nimiž lze/nelze přijmout ukončení pronájmu, a vytvořte o tom záznam.
- Naplánujte si schůzku pro závěrečnou kontrolu.
- vyplňte údaje na obrazovce ukončení pronájmu. Zkontrolujte údaje nájemce na kartě ukončení pronájmu.
- zaregistrujte ukončení pronájmu a zašlete konformační dopis. Zkontrolujte, zda potvrzovací dopis přišel do digitálního archivu.
- zkontrolujte v registru smluv od jednotky, že stávající smlouva je ukončena, že ukončená smlouva souvisí s ukončením pronájmu a že existuje nově vytvořená smlouva o volném pracovním místě.
- zkontrolujte novou smlouvu (volné místo)na základě nájemní politiky a šablon prvků.
co si všimnete?
- každý testovací krok začíná slovesem
- následovaným tématem
- a končí podrobnými a případně kontrolními otázkami. Můžete se rozhodnout umístit kontrolní otázky do samostatných testovacích kroků, ale praxe ukazuje, že kontrolní otázka je zdokonalením akce a logicky bude zapsána jako testovací krok.
ve výše uvedeném příkladu se předpokládá, že odborník z určitého oboru vyhodnotí testovací krok. A protože on nebo ona je specialista, žádné vstupní podmínky jsou uvedeny nebo explicitní očekávání nastínil, protože specialista má stále své vlastní případové studie v rukávu a jeho očekávání jsou křišťálově jasné.
pokud v současné době nemáte odborníka, můžete testovací kroky rozšířit o vstupní podmínky a explicitní očekávání.
například testovací Krok 1 ve zkušebním případě “ukončení pronájmu nezávislého domu” s více podrobnostmi.
- vyberte jednotku “Fleet street 677” a spusťte ukončení pronájmu. Podmínky zajišťují, že tato jednotka nemůže být ukončena před zaplacením nedoplatků.
- atd.
Tip 5: Ne více než 10 zkušebních instrukcí v 1 testovacím případě
pravidelně se setkáváme s testovacími projekty, kde je >50 testovacích kroků přiděleno jednomu testovacímu případu. To je příliš mnoho z několika důvodů:
- všechny testovací kroky musí být provedeny samostatně (nebo explicitně předány), než zkušební případ dostane verdikt.
- konečné hodnocení zkušebního případu je určeno” nejhorším ” skóre. Může se tedy stát, že 49 testovacích kroků bude hodnoceno jako ” dobré “a jeden jako” špatné”, což má za následek” špatný ” testovací případ. Měření zkušebních kroků je obdobné. Tím myslím, že prakticky každý testovací krok se musí rovnat účinku hodnocení. Pokud máte 10 testovacích kroků, které musíte dodržovat, včetně 2 malých testovacích kroků, které jsou nepřiměřené ostatním 8 testovacím krokům, musíte je přeformulovat. Totéž platí opačně s tvrdým testovacím krokem.
- tester se rychle ztratí s příliš mnoha testovacími kroky v testovacím případě. Neudělali jsme o tom vědeckou studii, ale praxe ukazuje, že testovací případ by neměl zahrnovat více než 10 testovacích kroků. Lze myslet na mnoho výjimek (ovládací prvky konverze atd.), ale v praxi to pro test přijetí uživatele ERP systému funguje nejlépe.
- pro vývojáře je obtížné reprodukovat nalezenou chybu. S mnoha testovacích kroků developer ztratí spoustu času se snaží re-uzákonit situaci.
- opakování nebo opakování velkých testovacích případů trvá příliš mnoho času. Pokud je testerem zjištěna porucha, musí být odpovídající testovací případ znovu otestován. Opakovaný test vyžaduje, aby byl tento krok přehodnocen, chcete samozřejmě zabránit regresním chybám. Tím, že příliš mnoho testovacích kroků, jste s největší pravděpodobností testování příliš mnoho. Tímto způsobem proces testování trvá déle a může nakonec přetížit vaše testery.
kromě toho máte také nástroje pro registraci testů, které mohou testerovi prezentovat testovací případy v různých formách. TestMonitor má například dva různé pohledy. TestMonitor má displej, který zobrazuje všechny testovací kroky Samostatně na stránku a displej, ve kterém jsou testovací případy prezentovány na stránku včetně všech testovacích kroků.Výhodou prvního displeje je, že každý tester může získat více informací pro každý testovací krok. Nevýhodou v případě, že je tester zkušenější, musí kliknout na “další” pokaždé, když chce pokračovat v dalším testovacím kroku. V druhém pohledu pro každý zkušební případ jsou výhody a nevýhody naopak.
Tip 6: recenze ne-designéra / dodavatele
v praxi pravidelně vidíme testovací skripty připravené programátory dodavatele softwaru. Při kontrole těchto testovacích skriptů případnými testery obvykle existuje více otázek než odpovědí. Naopak to funguje stejně pro testovací skripty připravené jejich vlastními zaměstnanci. Poskytuje skutečnou přidanou hodnotu, která je kontroluje dodavatelem softwaru. Dívají se na dokončené testovací skripty různými očima a vždy přicházejí s smysluplnými doplňky nebo úpravami.
s trochou brainstormingu se specialisty na dodavatele softwaru a organizací klientů se rychle soustředíte na podstatu toho, co je třeba otestovat. Pak mít čas, aby zvážila testovací případy, neúspěšné scénáře a uvidíte, že váš testovací model se rychle stává rozsáhlejší a podrobnější. Kromě toho získáte více informací o kvalitě, kterou jste považovali za možnou.
Tip 7: TestMonitor
kromě toho využijte profesionální testovací platformu a zajistěte, aby kvalita byla opravdu Bystrá. Požádejte o bezplatnou zkušební verzi TestMonitor ještě dnes a uvidíte a zažijte rozdíl sami.
pokud jste nováčkem ve světě testování, snadno se stanete ohromeni veškerou terminologií testování, která se hází kolem. V tomto článku se pokusíme vysvětlit některé žargony, se kterými se můžete setkat ve svém každodenním testovacím životě, jen aby to všechno bylo trochu srozumitelnější.
začněte testovat pomocí Testmonitoru
zůstat v kontaktu? Sledujte TestMonitor na Twitteru a LinkedIn.
Leave a Reply