Ad hoc tesztelés
Az ad hoc tesztelés egy informális vagy strukturálatlan szoftver tesztelési típus, amelynek célja a tesztelési folyamat megszakítása annak érdekében, hogy a lehetséges hibákat vagy hibákat a lehető legkorábbi szakaszban megtalálják. Az eseti teszteket véletlenszerűen végzik, és általában egy nem tervezett tevékenységről van szó, amely nem követ semmilyen dokumentációt és tesztelési technikát a tesztesetek létrehozásához.
Az eseti tesztelés nem követ semmilyen strukturált tesztelési módot, és véletlenszerűen történik az alkalmazás bármely részén. A teszt fő célja a hibák véletlenszerű ellenőrzéssel történő felkutatása. Az adhoc tesztelés a Hiba kitalálás nevű szoftver tesztelési technikával érhető el . Hibákat kitalálhatnak azok az emberek, akik elegendő tapasztalattal rendelkeznek a rendszeren ahhoz, hogy "kitalálják" a legvalószínűbb hibaforrást.
Ez a tesztelés nem követi a dokumentáció / tervezés / folyamat követését. Mivel ez a teszt véletlenszerű megközelítéssel, dokumentáció nélkül kívánja megtalálni a hibákat, a hibák nem kerülnek feltérképezésre a tesztesetekhez. Ez azt jelenti, hogy néha nagyon nehéz megismételni a hibákat, mivel nincsenek hozzárendelve vizsgálati lépések vagy követelmények.
A videó követi az adhoc tesztelés módját
Kattintson ide, ha a videó nem érhető el
Amikor végrehajtja az adhoc tesztelést?
Ad hoc teszt akkor hajtható végre, ha korlátozott idő áll rendelkezésre a bonyolult tesztek elvégzésére. Általában az adhoc tesztelést a hivatalos teszt végrehajtása után hajtják végre. És ha az idő engedi, ad hoc teszt elvégezhető a rendszeren. Az eseti tesztelés csak akkor lesz hatékony, ha a tesztelő ismeri a tesztelt rendszert.
Az adhoc tesztelés típusai
Különböző típusú adhoc tesztek léteznek, és az alábbiak szerint vannak felsorolva:
Buddy Testing | Két haver kölcsönösen azon dolgozik, hogy azonosítsa a hibákat ugyanabban a modulban. Leginkább az egyik haver a fejlesztői csapatból, egy másik pedig a tesztelő csapatból származik. A haverok tesztelése segít a tesztelőknek a jobb tesztesetek kidolgozásában, és a fejlesztő csapat is korán változtathat a terven. Ez a tesztelés általában az egység tesztelésének befejezése után történik. |
Páros tesztelés | Két tesztelőhöz modulok vannak hozzárendelve, ötleteket osztanak meg, és ugyanazon a gépen dolgoznak a hibák megtalálásában. Egy személy elvégezheti a teszteket, egy másik pedig jegyzeteket készíthet az eredményekről. A személyek szerepe lehet tesztelő és író a tesztelés során. A haver és a pár tesztelése: A haver tesztelés az egység és a rendszer tesztelésének kombinációja a fejlesztőkkel és a tesztelőkkel együtt, de a pár tesztelés csak a különböző tudásszintű tesztelőkkel történik. (Tapasztalt és nem tapasztaltak, hogy megosszák ötleteiket és nézeteiket) |
Majom tesztelés | Véletlenszerűen tesztelje a terméket vagy alkalmazást tesztesetek nélkül azzal a céllal, hogy megtörje a rendszert. |
Az adhoc tesztelés legjobb gyakorlatai
A bevált gyakorlatok követése biztosíthatja a hatékony adhoc tesztelést.
Jó üzleti ismeretek
A tesztelőknek megfelelő ismeretekkel kell rendelkezniük az üzletről és egyértelműen meg kell érteniük a követelményeket. Az üzleti folyamat végétől a végéig történő részletes ismeretek segítenek a hibák könnyű megtalálásában. A tapasztalt tesztelők több hibát találnak, mivel jobban tudják kitalálni a hibákat.
Teszt kulcs modulok
A legfontosabb üzleti modulokat meg kell határozni és meg kell célozni az eseti tesztelés céljából. Az üzleti szempontból kritikus modulokat először tesztelni kell, hogy bizalmat szerezzenek a rendszer minőségéről.
Hibák rögzítése
Minden hibát fel kell jegyezni vagy egy jegyzettömbbe kell írni. A javításhoz hibákat kell rendelni a fejlesztőkhöz. Minden érvényes hibához meg kell írni a megfelelő teszteseteket és hozzá kell adni a tervezett tesztesetekhez.
Ezeket a hiba megállapításokat tanulságként kell megtenni, és ezeket tükrözni kell a következő rendszerünkben, miközben teszteseteket tervezünk.
Következtetés:
Az ad-hoc teszt előnye, hogy ellenőrizzük a tesztelés teljességét, és több hibát találunk, mint a tervezett tesztelés. A hibafogási tesztesetek további tesztesetekként kerülnek a tervezett tesztesetekbe.
A szoftverfejlesztésben az eseti tesztelés sok időt takarít meg, mivel nem igényel bonyolult teszttervezést, dokumentációt és teszteset-tervet.