7 Tesztesetírás tippek az ERP Szoftvertesztelési folyamat javításához

a tesztesetek nagyon fontosak az ERP szoftvertesztelési folyamat minőségének biztosításához. Ezek a vizsgálati ciklus első lépései, és ha a vizsgálati esetek nem megfelelő minőségűek, akkor az egész projekt megterhelésre kerül. A “nagyszerű” tesztesetek írása olyan készség,amely egyszerűen formába kerül. De nagyon hasznos, ha van néhány betekintés, amely segíthet. Ezzel a cikkel szeretném elérni Önt, és javaslatokat adni, hogy könnyebb, szórakoztatóbb és jobb legyen. Az adott tippek különösen az ERP rendszerek elfogadási tesztelésének tesztelési eseteire vonatkoznak.

mik azok a teszt esetek?

a szoftvertesztelés világában a tesztesetek sok meghatározása létezik. Ezért fontos megnevezni a definíciónkat. Filozófiánkban a teszt esetek (az IEEE610 alapján): “tesztbemenetek, végrehajtási feltételek és várt eredmények halmaza, amelyeket egy adott célra fejlesztettek ki.”A jó tesztesetek megírásának ismerete rendkívül hasznos mindenki számára, aki tesztelni akar. Legyen szó funkcionális tesztről, felhasználói elfogadási tesztről, webes alkalmazás teszteléséről vagy egy ERP-rendszer moduljáról. A fent leírt összes helyzetben a tesztesetek meghatározzák, hogy az eredmények milyen mértékben adnak ítéletet az előre beállított célokról.

miért olyan nehéz a tesztesetek írása?

a definícióban leírtak szerint a tesztesetek segítenek a tesztelőknek a tesztelési utasítások sorozatán keresztül annak eldöntésében, hogy a szoftver megfelel-e az előre meghatározott követelményeknek. A tesztesetek végrehajtása segít nekünk információkat gyűjteni és felfedezni az adott cél vagy cél megvalósításához. Az első probléma, amellyel közvetlenül találkozunk, a lehetséges célok sokfélesége. És mivel különböző típusú tesztek és célok léteznek, különböző típusú megfelelő tesztesetek vannak.

a második probléma a tényleges teszt utasítás vagy lépések tartalmával kapcsolatos. Ezeknek az utasításoknak a szintje attól függ, hogy milyen típusú tesztelőnek kell értelmeznie ezt az információt, és véleményt kell adnia. A professzionális tesztelőnek különböző utasításokra lesz szüksége, szemben a végfelhasználóval, aki részt vesz az ERP-rendszer elfogadási tesztelésében

Tipp 1: Határozza meg a célt, és mit szeretne jelenteni

gondoljon arra, hogy mit szeretne jelenteni, így meghatározhatja a származékos célt. Ezt használva alapként, megvan a teszt eset vázlata. Sok különböző cél létezik, ahol mindig meg kell kérdeznünk magunktól, hogy mit próbálunk megtanulni vagy elérni, amikor lefuttatjuk a tesztet. Íme néhány példa:

• hibák keresése: ez a tesztelés klasszikus célja. A hibák feltárására tesztet végeznek.
• maximalizálja a hibák számát: A “hibák számának maximalizálása” és a “hibák keresése” közötti különbség az, hogy a hibák teljes száma fontosabb, mint a lefedettség.
• idő előtti termékkiadások blokkolása: ennek a tesztnek az a célja, hogy idő előtt találjon annyi súlyos hibát (showstoppers), hogy senki ne vegye be a terméket a gyártásba.
• támogassa a vezetőket a go/no-go döntéseikkel: a vezetők a kockázatok alapján hoznak döntéseket. Kockázati jelzések, mint a teszt lefedettsége, a talált problémák hatása stb. Adjon nekik jobb hátteret, amelyre alapozhatják döntéseiket.
• a megfelelőség értékelése a specifikáció szerint: az állítólagos specifikációkat ellenőrzik működésük szempontjából. Minden olyan kérdést, amely nem kapcsolódik a specifikációkhoz, figyelmen kívül hagyjuk.
• értékelje a minőséget: ez nehéz cél, mert a minőség többdimenziós. A minőség jellege a termék jellegétől függ. A minőség értékeléséhez világos kritériumokat kell kidolgozni, amelyeket úgy határoznak meg, hogy ténylegesen mérhetővé váljanak.

a tesztesetekből származó vizsgálati eredmények közvetlen releváns információkat szolgáltatnak a célról.

2.Tipp: foglaljon elegendő tervezési időt

foglaljon elegendő időt a tesztesetek megtervezéséhez, hogy azok megfeleljenek a céljainak. A rossz teszt esetek kísérteni fogják Önt az egész tesztfolyamat során. A vizsgálati eredmények összehasonlítása, jelentéstétel több tesztkörről stb. Alapvetően a tesztesetek minősége határozza meg.

ha már fogy az idő a tervezéshez, de még mindig el akarja kezdeni a tesztelést, győződjön meg arról, hogy legalább meghatározta a fő kockázatokat. Ha 10 tesztelőnek felül kell vizsgálnia 5 tesztesetet 1 tesztlépéssel, ez 50 teszteredményt eredményez. Nem számít, hogy ezek az 50 eredmények több információt adnak a minőségről, majd semmit sem tesznek. Ez valószínűleg nem lesz kimerítő, de ez az első lépés. Innentől kezdve meghatározható az egyes részek részletessége.

jobban szeretjük, ha jó előre átgondolja, hogyan kell megtervezni a tesztet, és hogy a teszt eredményei valódi választ adnak a célra. De a valóságban ez néha rakoncátlan.

3.Tipp: név teszt eset

fontos a teszt esetek elnevezése. Egy átlagos ERP teszt során könnyen több mint 500 tesztesetet kaphat. Meg fogja érteni, hogy a logikai névszerkezet növeli a megtalálhatóságot. A szakirodalomban gyakran nevezik a teljes, mint lehetséges nevet,amelyben a tesztelendő folyamat, modul, objektum stb. Mind szerepel a névben. El tudod képzelni, hogy 500 teszteset ilyen teljes címmel történő biztosítása kaotikus adminisztrációt eredményez. Egy egyszerű Excel lapot, akkor könnyen laza áttekintést. A tesztkezelő eszközök olyan struktúrát biztosítanak, amelyhez a teszteseteket újrafelhasználható objektumokhoz kapcsolhatja, anélkül, hogy “szennyeznék” a nevet. Van olyan tesztregisztrációs eszköze is, amely más módon szervezi ezeket a kapcsolatokat.

a Testmonitoron belül például egy másik megoldást találtunk fel. Az eszközben megadhat címkéket vagy címkéket, amelyeket aztán összekapcsolhat a tesztesetekkel. A Testmonitoron belül a tesztesetek egy vagy több üzleti folyamat-, kockázat-, követelmény – vagy alkalmazáscímkéhez kapcsolódnak. Ez lehetővé teszi a tesztesetek csoportosítását és különböző nézőpontokból történő visszakeresését.

a Testmonitoron belüli tesztesetek nevéhez elegendő a tesztesetek céljának egyértelmű leírása. Hogy egyszerű legyen, egy tevékenységet implicit elvárással ír le.

példa teszt eset neve:
“a bérlet megszűnése – független otthon”
“ügyfél létrehozása” “ideiglenes foglalási nyugta”
stb.

példa az “ideiglenes foglalási nyugta” tesztesetre, amely több címkéhez kapcsolódik:

• üzleti folyamat ‘áru átvétele’
• követelmény ‘szerződéses követelmény’
• kockázat ‘működési kockázat’
• alkalmazás ‘ERP’

fontos leírni a várt eredményt tesztesetenként. A tesztelő ezután tudja, hogy a “válasz” milyen irányba kell, hogy legyen, és közvetlenül kap egy explicit tesztelési keretet.

4.tipp: a Tesztlépés leírása

a definícióban leírtak szerint a tesztesetek olyan tesztelési utasítások gyűjteménye, amelyek segítenek felfedezni az információkat egy adott cél elérése érdekében.

a tesztesetnek egyértelmű kezdettel és végződéssel kell rendelkeznie annak megállapításához, hogy a teszteseten megfelelt-e vagy sem. Ezenkívül egy teszteset egy vagy több vizsgálati utasításból vagy-lépésből áll, ahol a kívánt eredmény elérése érdekében több út lehetséges. Csak a siker útjának tesztelése gyakran nem elegendő. Bizonyos helyzetekben a nem sikeres utak követése csak megváltoztathatja a különbséget.

fontos a tesztlépéseket a lehető legvilágosabban meghatározni, hogy a felhasználói elfogadási teszt végfelhasználója pontosan tudja, mit kell tennie. Természetesen vannak előfeltételek, mint például a funkcionális szint tesztelő, az új rendszer ismerete, a lehetséges kiigazított üzleti folyamatok ismerete stb. De lényegében mindenkinek meg kell értenie az összes tesztlépést.

tegyük fel, hogy tovább leírjuk a “lízing megszűnése – független otthon” tesztesetet egy egyszerű sikerút érdekében:

1. válasszon ki egy egységet, és indítsa el a bérleti szerződés megszüntetését. Ellenőrizze, hogy vannak-e olyan előfeltételek, amelyek között a bérlet megszűnése elfogadható/nem fogadható el, és készítsen erről nyilvántartást.
2. ütemezzen időpontot a végső ellenőrzésre.
3. töltse ki az adatokat a képernyőn a lízing megszűnése. Ellenőrizze még egyszer a bérlő adatait a bérleti felmondási kártyán.
4. regisztrálja a bérleti szerződés megszűnését és küldjön egy megfelelő levelet. Ellenőrizze, hogy a megerősítő levél megérkezett-e a digitális archívumba.
5. ellenőrizze az egység szerződésnyilvántartásában, hogy a jelenlegi szerződés megszűnik-e, hogy a felmondott szerződés kapcsolódik-e a bérleti szerződés megszűnéséhez, valamint hogy van-e újonnan létrehozott üresedési szerződés.
6. ellenőrizze az új (üresedési)szerződést a bérleti politika és az elemsablonok alapján.

mit vesz észre?

• minden tesztlépés egy
• igével kezdődik, amelyet egy
• téma követ, amely részletekkel és esetleg ellenőrző kérdésekkel zárul. Dönthet úgy, hogy a vezérlési kérdéseket külön tesztlépésekbe helyezi, de a gyakorlat azt mutatja, hogy a vezérlési kérdés a művelet finomítása, majd logikusan tesztlépésként íródik le.

a fenti példában feltételezzük, hogy egy adott terület szakembere értékeli a vizsgálati lépést. És mivel ő egy szakember, nincsenek bemeneti feltételek vagy kifejezett elvárások, mert a szakembernek még mindig vannak saját esettanulmányai a tarsolyában, és elvárásai kristálytiszta.

ha jelenleg nincs szakembere, kibővítheti a tesztlépéseket bemeneti feltételekkel és kifejezett elvárásokkal.

például az 1.tesztlépés a “lízing – független otthon megszüntetése” tesztesetben, további részletekkel.

1. válassza ki a “Fleet street 677” egységet, és kezdje meg a bérleti szerződés megszüntetését. A feltételek biztosítják, hogy ezt az egységet ne lehessen megszüntetni a hátralék kifizetése előtt.
2. stb.

5. tipp: Legfeljebb 10 teszt utasítás 1 tesztesetben

rendszeresen találkozunk olyan tesztprojektekkel, ahol > 50 tesztlépés van hozzárendelve egy tesztesethez. Ez néhány okból túl sok:

• minden tesztlépést külön kell megtenni (vagy kifejezetten át kell adni), mielőtt egy teszteset ítéletet hozna.
• a vizsgálati eset végső értékelését a “legrosszabb” pontszám határozza meg. Tehát könnyen lehet, hogy 49 tesztlépést “jónak”, egyet pedig “rossznak” fognak értékelni, ami “rossz” tesztesetet eredményez. A vizsgálati lépések mérésének hasonlónak kell lennie. Ez alatt azt értem, hogy gyakorlatilag minden tesztlépésnek meg kell egyeznie az értékelés hatásával. Ha 10 tesztlépése van, amelyet be kell tartania, beleértve 2 kis tesztlépést, amelyek aránytalanok a többi 8 tesztlépéshez képest, újra kell fogalmaznia őket. Ugyanez vonatkozik fordítva egy kemény tesztlépéssel.
• a tesztelő gyorsan eltéved a túl sok tesztelési lépéssel egy tesztesetben. Nem készítettünk róla tudományos tanulmányt, de a gyakorlat azt mutatja, hogy egy tesztesetnek nem szabad 10 tesztlépésnél többet tartalmaznia. Sok kivételre gondolhatunk (konverziós vezérlők stb.), de a gyakorlatban egy ERP rendszer felhasználói elfogadási tesztje esetén ez működik a legjobban.
• a fejlesztők számára nehéz reprodukálni a talált hibát. Sok tesztlépéssel a fejlesztő sok időt veszít, amikor megpróbálja újra végrehajtani a helyzetet.
• a nagy tesztesetek ismétlése vagy újratesztelése túl sok időt vesz igénybe. Ha egy tesztelő hibát észlel, a megfelelő tesztesetet újra meg kell vizsgálni. A teszt megköveteli, hogy nagyon lépés újra kell értékelni, azt szeretné, hogy megakadályozzák regressziós hibák nyilvánvalóan. Túl sok tesztlépéssel valószínűleg túl sokat tesztel. Így a tesztelési folyamat hosszabb időt vesz igénybe, és végül túlterhelheti a tesztelőket.

amellett, hogy akkor is teszt regisztrációs eszközök, amelyek bemutatják a vizsgálati esetek különböző formákban a tesztelő. TestMonitor például két különböző nézet. A TestMonitor rendelkezik egy kijelzővel, amely oldalanként külön jeleníti meg az összes tesztlépést, valamint egy kijelzővel, amelyen a tesztesetek oldalanként jelennek meg, beleértve az összes tesztlépést.Az első kijelző előnye, hogy minden tesztelő több információt szerezhet az egyes tesztelési lépésekről. Hátránya abban az esetben, ha a tesztelő tapasztaltabb, minden alkalommal a “Tovább” gombra kell kattintania, amikor a következő tesztlépésre akar lépni. A másik nézetben minden egyes teszt esetében az előnyök és hátrányok fordítva vannak.

6.tipp: nem tervező/szállító felülvizsgálata

a gyakorlatban rendszeresen látjuk a szoftverszolgáltató programozói által készített teszt szkripteket. Amikor ezeket a teszt szkripteket az esetleges tesztelők áttekintik, általában több kérdés van, mint válasz. Ezzel szemben ez ugyanúgy működik a saját alkalmazottjuk által készített teszt szkripteknél. Ez ad egy igazi hozzáadott értéket felülvizsgálja ezeket a szoftver szállító. Különböző szemmel nézik a kitöltött teszt szkripteket, és mindig értelmes kiegészítésekkel vagy módosításokkal állnak elő.

egy kis ötletbörze a szoftver szállító szakemberek és az ügyfél szervezet gyorsan kap összpontosítani a lényege, hogy mit kell tesztelni. Ezután szánjon időt arra, hogy fontolja meg a teszteseteket, a nem sikeres forgatókönyveket, és látni fogja, hogy a tesztmodell gyorsan kiterjedtebbé és részletesebbé válik. Emellett több információt kap a minőségről, akkor lehetségesnek tartja.

Tipp 7: TestMonitor

mellett, hogy használja a szakmai teszt platform, és a minőség igazán éleslátó. Kérjen egy ingyenes próbaverzió TestMonitor ma, és látni és megtapasztalni a különbséget magad.

ha újonc vagy a tesztelés világában, könnyen eláraszthatja az összes tesztelési terminológia. Ebben a cikkben megpróbáljuk elmagyarázni néhány zsargont, amellyel a mindennapi tesztelési életben találkozhat, csak azért, hogy mindez egy kicsit érthetőbb legyen.

indítsa el a testmonitor tesztelését

még nem Tesztmonitor felhasználó? A jó és könnyű tesztelés kulcsfontosságú prioritás a minőségbiztosítási menedzserek, tesztmenedzserek, IT-menedzserek, tesztmenedzserek és a release manager számára. TestMonitor teszi tesztelés egyszerű és szórakoztató teszt felhasználók számára is.

Tehát kezdjük el. Érdemes megnézni a videónkat, vagy letölteni a termék szórólapját. De természetesen egy ingyenes próbaverzióval valóban megtapasztalhatja a TestMonitor egyszerű használatát.

tartjuk a kapcsolatot? Kövesse a TestMonitor – t a Twitteren és a LinkedIn-en.