Az ad hoc tesztelés megtervezése

Ebben a cikkben az ad hoc teszteléssel, annak típusaival, előnyeivel, hátrányaival és az ad hoc tesztelés legjobb gyakorlataival foglalkoztunk.

Mi az ad hoc tesztelés?

Az ad hoc tesztelést néha “véletlenszerű tesztelésnek” vagy “majomtesztelésnek” is nevezik, és informális tesztelési típusként definiálják. Ennek a folyamatnak a célja a rendszer feltörése nem szokványos módszerekkel. A szoftvertesztelésnek ez a típusa általában nem tervezett, és nem követ semmilyen konkrét teszttervezési technikát a tesztesetek létrehozásához.

Az ad hoc tesztelés fő célja, hogy véletlenszerű ellenőrzéssel találjon meg minden hibát. A tesztelő a lépéseket önkényes végrehajtással improvizálja. Ez nagyon specifikus és érdekes hibákat fedezhet fel, amelyek más módszerek alkalmazásakor könnyen kimaradnak.

Az ad hoc tesztelés legmeglepőbb aspektusa, hogy nem tartalmaz semmilyen teszttervezési technikát. Ez azt jelenti, hogy bár ez a módszer megtalálja azokat a hibákat, amelyeket általában talán nem, de nehezebb reprodukálni, mivel nincsenek írott tesztesetek vagy dokumentáció.

Az ad hoc tesztelés sikere valójában a tesztelő kreativitásán és kitartásán múlik, és néha csak a puszta szerencsének köszönhető. Az ad hoc tesztelési technika közvetlenül a “strukturálatlan tesztelés” kategóriájába tartozik.

Strukturált vs. strukturálatlan tesztelés

Strukturált tesztelés

Ez a megközelítés biztosítja, hogy minden tevékenység, amely a tesztelési eljárás során történik, szkriptelt legyen, a tesztesetek létrehozásától a szekvenciális végrehajtásig. A tesztelő követi a forgatókönyvet a tesztek sikeres elvégzése érdekében.

Szerkezetlen tesztelés

Ez a megközelítés a tesztelést hibák kitalálásával végzi. A tesztelő a tesztelési folyamat során teszteseteket hoz létre.

Az ad hoc tesztelési módszer típusai

Buddy tesztelés

Ez a fajta ad hoc tesztelés legalább két emberrel történik. Egy modul egységtesztelésének elvégzése és befejezése után kerül rá sor. Ez a fajta tesztelés a rendszer- és az egységtesztelés kombinációjának is tekinthető.

A fő cél az, hogy két “haver” egyszerre dolgozzon ugyanazon modul hibáinak vagy hibáinak azonosításán. Ez a csapat általában egy szoftverfejlesztőből és egy szoftvertesztelőből áll.

A két “haver” együtt dolgozik az adott modulon, hogy érvényes teszteseteket hozzanak létre. Ez a folyamat biztosítja, hogy a tesztelő ne jelentsen olyan hibákat, amelyeket az érvénytelen tesztesetek generáltak.

A haver-tesztelés sikeresnek bizonyult, mivel segít a tesztelőnek jobb teszteseteket kidolgozni, és lehetővé teszi a fejlesztőcsapatnak, hogy a lehető leghamarabb tervmódosításokat hajtson végre.

Monkey Testing

A tesztelés véletlenszerűsége miatt ez a módszer a “majomtesztelés” nevet érdemelte ki. A majomtesztelést leggyakrabban az egységtesztelés szintjén végzik. Itt a tesztelők véletlenszerűen tesztelik az alkalmazást vagy terméket tesztesetek nélkül. A tesztelő fő célja, hogy teljesen véletlenszerűen elemezze az adatokat vagy a teszteket, biztosítva, hogy a rendszer képes legyen ellenállni bármilyen összeomlásnak.

A tesztelők véletlenszerű bemeneteket adnak a szoftverhez, és megfigyelik a megfelelő kimeneteket. A kimeneti adatok alapján jobban meg tudják határozni az esetleges hibákat, következetlenségeket vagy a rendszer összeomlását.

Párban tesztelés

A “páros teszteléshez” bizonyos szempontból hasonló, a “páros tesztelés” során egy tesztelőpáros dolgozik együtt a tesztelendő modulokon. A két tesztelő ugyanazon a gépen osztja meg egymással ötleteit, tudását és véleményét a hibák vagy hibák azonosítása érdekében.

Ez a tesztelési módszer olyan tesztelők alkalmazását jelenti, akiket szakértelmük és tudásszintjük szerint párosítanak, lehetővé téve a különböző betekintést minden általuk azonosított problémába. A két tesztelő ugyanazt a berendezést használja, a tesztelés munkáját és az összes megfigyelés dokumentálását is megosztják egymás között. Ez a tesztelési módszer azt is lehetővé teszi, hogy az egyik tesztelő végezze el a teszteket, míg a másik jegyzetelheti a megállapításokat.

Még olvassa el: Használja a páros tesztelést a jobb átvételi teszteléshez

Buddy vs. páros tesztelés

A fő különbség a buddy tesztelés és a páros tesztelés között az, hogy a buddy tesztelés az egység- és a rendszertesztelés kombinációja. Egy másik lényeges különbség, hogy a haver-tesztelést a fejlesztők és a tesztelők együtt végzik. A páros tesztelést viszont csak olyan tesztelők végzik, akik különböző szintű tudással rendelkeznek.

Mikor és mikor nem érdemes ad hoc tesztelést végezni

Az ad hoc tesztelést általában akkor végzik, amikor nincs idő hosszabb és kimerítőbb tesztelési folyamatok elvégzésére. Az alaposabb tesztelési módszer magában foglalja a tesztelési követelménydokumentumok, tesztesetek és tesztesettervek elkészítését.

Az ad hoc tesztelés elvégzésének ideális időpontja az összes formális tesztelési technika befejezése után van. Az ad hoc tesztelés azonban a szoftverfejlesztés közepén, a szoftver teljes kifejlesztése után vagy néhány modul kifejlesztése után is elvégezhető.

Meg kell jegyezni azt a néhány forgatókönyvet, amikor az ad hoc tesztelés nem ajánlott. Néhány olyan körülmény, amikor nem szabad ad hoc tesztelést végezni:

A béta tesztelés során

A már meglévő hibákkal rendelkező teszteseteknél

Az ad hoc tesztelés előnyei

Az ad hoc tesztelés egyik fő előnye, hogy olyan hibákat is képes azonosítani, amelyek a formális tesztelési módszerek során általában észrevétlenek maradnának. Ez rengeteg időt takaríthat meg, mivel nem igényel olyan tervezést, mint a strukturált tesztelés.

A másik előnye, hogy a tesztelők szabadon, saját tudásuknak és az alkalmazásról alkotott képüknek megfelelően vizsgálhatják meg az alkalmazást. Ezután menet közben különböző teszteket hajthatnak végre, segítve a hibák azonosítását a folyamat során.

Harmadszor, a tesztelők és az alkalmazás fejlesztői maguk is könnyen tesztelhetik az alkalmazást, mivel nem igényel teszteseteket. Ez lehetővé teszi a fejlesztők számára, hogy könnyedén hatékonyabb és hibamentesebb kódot hozzanak létre.

Az ad hoc tesztelés más tesztelési technikákkal is kombinálható, és ezek végrehajtása után összességében hatékonyabb és informatívabb eredményeket hozhat.

Az ad hoc tesztelés hátrányai

Az ad hoc tesztelés egyik fő hátránya, hogy a tényleges tesztelési folyamat nem dokumentált, mivel nem követ egy adott tesztesetet. Ez megnehezíti a tesztek hiba újratermelését. Ugyanis ahhoz, hogy a hiba előálljon, a tesztelőnek emlékeznie kell a pontos lépésekre, amelyeket a hiba eléréséhez megtett, ami nem mindig lehetséges.

A tesztelő által kidolgozott érvénytelen tesztesetek eredményeként esetenként érvénytelen hibákat jelentenek. Ez a következő hibajavítási folyamatokban válhat problémává. Ha a tesztelő nem rendelkezik előzetes ismeretekkel a tesztelt alkalmazás funkcionalitásáról, az ad hoc tesztelés nem lesz hasznos, és nem lesz képes azonosítani a hibákat.

Az ad hoc tesztelés azt sem garantálja, hogy minden hibát megtalál. Az ad hoc tesztelés sikere a tesztelő készségén és tudásán múlik. Mivel nincsenek előre elkészített vagy dokumentált tesztesetek, az ezekre a tesztekre fordított idő, erőfeszítés és erőforrások mennyisége meghatározhatatlan. Egy hiba megtalálása néhány perctől néhány óráig vagy tovább is eltarthat.

A tesztelés elvégzésének legjobb gyakorlatai

A nem megfelelően elvégzett tesztek felesleges időveszteséget okozhatnak. Ezt szem előtt tartva alapvető fontosságú tudni, hogyan lehet optimalizálni a folyamatot a sikeres ad hoc tesztelés hatékony elvégzése érdekében.

A következő legjobb gyakorlatok biztosítják, hogy a folyamatra fordított időt bölcsen, a kívánt eredmények elérésének legjobb esélyével töltsük el.

Ismerje a szoftvert

Elkerülhetetlen, hogy az ad hoc tesztelést végző tesztelő szilárd ismeretekkel és fogásokkal rendelkezzen az alkalmazásról. Fontos, hogy a tesztelő ismerje az alkalmazás minden fő funkcióját, hogy biztosítsa a jobb “hibakitalálást”. A megfelelő ismeretek birtokában a tesztelő képes lesz több hibát, hibát és általános következetlenséget találni.

A valószínűsíthetően hibás területek azonosítása

Ha a tesztelők nem ismerik az alkalmazást, akkor ajánlott, hogy azonosítsák az alkalmazások hibaérzékeny területeit, és onnan induljanak ki. Az érzékeny területek kiválasztása az ad hoc teszteléshez lehetővé teszi a tesztelők számára, hogy könnyebben megtalálják a hibákat.

Priorizáljuk azokat a területeket, amelyeket a végfelhasználó a legkönnyebben elér

Az alkalmazás azon területeinek tesztelésével kezdjük, amelyeket az ügyfelek és a végfelhasználók a leggyakrabban használnak. Ezáltal először a fontos funkciókat fogják értékelni, ami lehetővé teszi számukra, hogy az esetleges hibákat előzetesen jelentsék.

Lazán fogalmazza meg a teszttervet

Míg az ad hoc tesztelés nem igényel előzetes tervezést vagy dokumentációt, hasznos, ha előzetesen végez némi durva tervezést. A tesztelést igénylő főbb területek feljegyzése segít a tesztelőnek abban, hogy a lehető legrövidebb idő alatt a lehető legtöbb területet lefedje.

Növelje a hatékonyságot a megfelelő eszközökkel

A megfelelő eszközök, például feladatfigyelők, hibakeresők és profilozók használata elengedhetetlen a folyamat hatékony lefutásának biztosításához. Ezek kiegészítik a tesztelők képességét a hibák elkülönítésére, mivel előfordulhatnak olyan esetek, amikor a tesztelés során nem azonosítják a kivételeket.

Következtetés

Az ad hoc tesztelés nem igényel bonyolult tervezést, dokumentációt és teszteset-tervezést. Ehelyett időt takarít meg az ad hoc jellegének köszönhetően, valamint a kreatív és az alkalmazás funkcionalitását előzetesen ismerő tesztelők kiválasztásával. Az ilyen teszteléssel több hibát lehet találni, mint a tervezett teszteléssel.

Jelentkezzen 60,000+ előfizetőhöz

A legújabb blogokért, iparági frissítésekért és exkluzív tippekért.

*E-mailje biztonságban van nálunk, mi is utáljuk a spameket