Ad-hoc tesztelés:

Az ad-hoc kifejezés maga is a struktúra hiányát vagy valami olyasmit jelent, ami nem módszeres. Amikor ad-hoc tesztelésről beszélünk, az azt jelenti, hogy ez egyfajta fekete doboz vagy viselkedéses tesztelés, amelyet formális folyamat nélkül végeznek.

A formális folyamat itt azt jelenti, hogy van dokumentáció, például követelménydokumentumok, teszttervek, tesztesetek, és megfelelő teszttervezés az ütemezés és az elvégzett tesztek sorrendje tekintetében. Emellett a tesztelés során végrehajtott minden műveletet jellemzően nem dokumentálnak.

Ezt elsősorban azzal a céllal végzik, hogy megpróbálják feltárni azokat a hibákat vagy hiányosságokat, amelyeket a tesztelési ciklus során követett hagyományos vagy formális folyamatokkal nem lehet megragadni.

Amint azt már megértettük, ennek a tesztelésnek a lényege abban rejlik, hogy a tesztelésnek nincs formális vagy strukturált módja. Az ilyen jellegű véletlenszerű tesztelési technikák végrehajtásakor nyilvánvaló, hogy a tesztelők ezt minden konkrét felhasználási esetet szem előtt tartva végzik azzal a céllal, hogy megtörjék a rendszert.

Az tehát még nyilvánvalóbb, hogy az ilyen intuitív vagy kreatív tesztelési módszertan megköveteli, hogy a tesztelő rendkívül képzett, alkalmas és mélyreható ismeretekkel rendelkezzen a rendszerről. Az ad-hoc tesztelés biztosítja az elvégzett tesztelés teljességét, és különösen nagyon hasznos a tesztvödör hatékonyságának meghatározásában.

Elolvasásra ajánlott => Felderítő tesztelés – Hogyan gondolkodjunk a hagyományos tesztelési korlátokon túl?

Kezdjük egy ad-hoc tesztelési példával

Itt egy példa arra, hogyan végezhetjük el ezt a tesztelést, amikor UI varázslóról van szó.

Tegyük fel, hogy tervet vagy sablont kell készítenünk valamilyen feladathoz, amelyet az UI varázsló segítségével kell elvégezni. A varázsló egy sor panelek, hogy a felhasználói bevitel, mint a név, leírás, stb.

A varázsló előrehaladtával: mondjuk az egyik panelen, a felhasználói adatokat kell megadni, amely magában foglalja a UI varázsló dob egy kontextus felugró ablakot, amely hozzáadja a kapcsolódó adatokat a varázsló befejezéséhez és a varázsló telepítéséhez / aktiválásához.

A teszteléshez a tesztelő elvégzi a szokásos tesztelését, például:

• A varázsló sikeres befejezése az összes érvényes adattal és a terv létrehozása.
• A varázsló félúton történő megszakítása.
• Módosít egy létrehozott tervet a varázsló segítségével.
• Törli a létrehozott tervet, és megnézi, hogy nincs-e maradványa.
• Negatív értéket ad meg a varázslóban, és megnézi a megfelelő hibaüzeneteket.

Most, a fenti példához íme néhány teszteset ad-hoc tesztekhez, amelyeket a lehető legtöbb hiba feltárása érdekében el lehetne végezni:

• Mialatt megpróbál negatív adatokat hozzáadni, adjon hozzá bizonyos speciális karaktereket, amelyek nincsenek korlátozva, hogy lássa, megfelelően kezeli-e azokat. Például néha a varázslók nem korlátozzák a {vagy [ zárójeleket, de bizonyos helyzetekben ez konfliktusba kerülhet a kóddal a nyelv alapján, amelyen íródott, és nagyon megbízhatatlan viselkedést okozhat.
• Egy másik teszt kifejezetten a felugró ablakokra vonatkozik. A felhasználó előidézheti a felugró ablak elindulását, majd megpróbálhatja megnyomni a billentyűzeten a backspace gombot. Sokszor megfigyeltem, hogy ha így tesz, a háttérben lévő varázsló teljesen eltűnik, és a felugró ablak elindításáig beírt összes felhasználói adat elveszik!

Az ad-hoc tesztelés jellemzői:

Ha megfigyeli a fenti forgatókönyveket, akkor láthatja az ilyen típusú tesztelés néhány nagyon határozott jellemzőjét.

Ezek:

• Mindig összhangban vannak a tesztelési céllal. Ezek azonban bizonyos drasztikus tesztek, amelyeket a rendszer megbontásának szándékával végeznek.
• A tesztelőnek teljes körű ismeretekkel és tudással kell rendelkeznie a tesztelendő rendszerről. Ennek a tesztelésnek az eredménye olyan hibákat talál, amelyek megpróbálnak rávilágítani a tesztelési folyamat hiányosságaira.
• A fenti két tesztet tekintve a természetes reakció az lenne, hogy – ez a fajta teszt csak egyszer végezhető el, mivel nem kivitelezhető az ismételt tesztelés, hacsak nem kapcsolódik hozzá hiba.

Mikor végezzünk ad-hoc tesztelést?

Ez valóban egy millió dolláros kérdés!

A legtöbbször a tesztcsapatok mindig túl sok tesztelendő funkcióval vannak terhelve a korlátozott időkeretek között. Ebben a korlátozott időintervallumban rengeteg olyan tesztelési tevékenység van, amely a formális folyamatból származik, és amelyet szintén be kell fejezni. Ilyen helyzetekben az ad-hoc tesztelés, amely utat talál a tesztelésben, csekély mértékű.

A tapasztalatom szerint azonban egy kör ad-hoc tesztelés csodákat tehet a termék minőségével, és sok tervezési kérdést vethet fel.

Mivel az ad-hoc tesztelés inkább egy “vadgyerek” tesztelési technika, amelyet nem kell strukturálni, az általános ajánlás az, hogy az aktuális tesztvödör végrehajtása után kell elvégezni. Egy másik nézőpont szerint ezt akkor lehet elvégezni, amikor a kevesebb idő miatt nem lehet részletes tesztelést végezni.

Az én véleményem szerint az ad-hoc tesztelés szinte bármikor elvégezhető – az elején, a közepe felé és a vége felé! Csak megtalálja a helyét az adott időpontban. Azt azonban, hogy mikor kell ad-hoc tesztelést végezni, hogy maximális értéket hozzon ki, legjobban egy tapasztalt tesztelő tudja megítélni, aki alapos ismeretekkel rendelkezik a tesztelendő rendszerről.

Mikor ne végezzük el?

Ha az előző kérdés egymillió dollárt ért, akkor ennek egymilliárdot kellene érnie!

Míg megállapítottuk, hogy az ad-hoc tesztelés mennyire hatékony és gyümölcsöző lehet, képzett és alkalmas tesztelőként azt is meg kell fejtenünk, hogy mikor nem érdemes befektetni ebbe a fajta tesztelésbe. Bár ez a tesztelő belátására van bízva, íme néhány ajánlás/példa arra, hogy mikor nem feltétlenül szükséges.

• Kerüljük ezt a tesztelést, ha van olyan teszteset, amelyhez létezik hiba. Ilyen helyzetben dokumentálni kell a teszteset hibapontját, majd a hiba kijavítása után ellenőrizni/újratesztelni a hibát. Ezért itt nem lesz alkalmazható.
• Ezek mellett lehetnek olyan forgatókönyvek is, amikor a vevőket vagy ügyfeleket meghívják a szoftver béta verziójának tesztelésére. Ilyen esetekben ezt a tesztelést nem szabad elvégezni.
• Egy másik forgatókönyv az, amikor egy nagyon egyszerű UI képernyő kerül hozzáadásra. Itt a hagyományos pozitív és negatív tesztelésnek elegendőnek kell lennie ahhoz, hogy a lehető legtöbb hibát hozza ki.

Az ad-hoc tesztelés típusai

Az ad-hoc tesztelés az alábbi három kategóriába sorolható:

#1) Buddy tesztelés

A tesztelés ezen formája során egy tesztelő és egy fejlesztő tagot választanak ki, akik ugyanazon a modulon dolgoznak. Közvetlenül azután, hogy a fejlesztő befejezte az egységtesztelést, a tesztelő és a fejlesztő leülnek együtt, és együtt dolgoznak a modulon. Ez a fajta tesztelés lehetővé teszi, hogy a funkciót mindkét fél szélesebb körben lássa.

A fejlesztő rálátást nyer az összes különböző tesztre, amelyet a tesztelő lefuttat, a tesztelő pedig rálátást nyer arra, hogy milyen az eredendő tervezés, ami segít neki elkerülni az érvénytelen forgatókönyvek tervezését, ezáltal megelőzve az érvénytelen hibákat. Ez segít az egyiknek úgy gondolkodni, mint a másiknak.

#2) Páros tesztelés

Ebben a tesztelésben két tesztelő együtt dolgozik egy modulon, és ugyanazt a tesztelési elrendezést osztják meg egymás között. A tesztelés ezen formájának lényege, hogy a két tesztelő ötleteket és módszereket ötleteljen, hogy számos hiba legyen. Mindketten megoszthatják a tesztelés munkáját és elkészíthetik a szükséges dokumentációt az elvégzett megfigyelésekről.

#3) Majomtesztelés

Ezt a tesztelést főként egységtesztelési szinten végzik. A tesztelő teljesen véletlenszerűen elemez adatokat vagy teszteket, hogy megbizonyosodjon arról, hogy a rendszer képes-e ellenállni bármilyen összeomlásnak. Ez a tesztelés két további kategóriába sorolható:

Ad-hoc tesztelés Előnyei

Ez a tesztelés nagy hatalmat biztosít a tesztelőnek, hogy olyan kreatív legyen, amennyire szükséges.

Ez növeli a tesztelés minőségét és hatékonyságát az alábbiak szerint:

• A legnagyobb előny, ami kiemelkedik, hogy a tesztelő a hagyományos teszteléshez képest több hibát találhat, mivel különböző innovatív módszereket alkalmazhat a szoftver tesztelésére.
• A tesztelés ezen formája bárhol alkalmazható az SDLC-ben; nem csak a tesztelő csapatra korlátozódik. A fejlesztők is elvégezhetik ezt a tesztelést, ami segítené őket abban, hogy jobban kódoljanak, és azt is megjósolhatják, hogy milyen problémák merülhetnek fel.
• A legjobb eredmények elérése érdekében más teszteléssel is párosítható, ami néha lerövidítheti a rendszeres teszteléshez szükséges időt. Ez lehetővé tenné a jobb minőségű tesztesetek generálását és összességében a termék jobb minőségét.
• Nem írja elő dokumentáció készítését, ami megakadályozza a tesztelőre nehezedő extra terhet. A tesztelő a mögöttes architektúra tényleges megértésére koncentrálhat.
• Azokban az esetekben, amikor kevés idő áll rendelkezésre a tesztelésre, ez nagyon értékesnek bizonyulhat a tesztlefedettség és a minőség szempontjából.

Ad-hoc tesztelés hátrányai

Az ad-hoc tesztelésnek van néhány hátránya is. Nézzünk meg néhányat a kimondott hátrányok közül:

Mivel nem túl szervezett és nincs kötelezően előírt dokumentáció, a legnyilvánvalóbb probléma az, hogy a tesztelőnek emlékeznie kell az ad-hoc forgatókönyvek minden részletére, és emlékezetében kell felidéznie azokat. Ez még nagyobb kihívást jelenthet, különösen az olyan forgatókönyveknél, ahol sok interakció van a különböző komponensek között.

• Az első pontból következően ez azt is eredményezné, hogy a későbbi próbálkozások során nem tudná újraalkotni a hibákat, ha információt kérnének tőle.
• Egy másik nagyon fontos kérdés, amit ez felvet, az erőfeszítés elszámoltathatósága. Mivel ez nem tervezett/strukturált, nincs mód az ilyen típusú tesztelésbe fektetett idő és erőfeszítés elszámolására.
• Az ad hoc tesztelést csak egy nagyon jól képzett és hozzáértő tesztelő végezheti a csapatban, mivel proaktivitást és intuíciót igényel a potenciális hibákkal teli területek előrejelzése tekintetében.

Best Practices To Make This Testing More Effective

Hosszasan tárgyaltuk az ezzel a teszteléssel kapcsolatos erősségeket és gyengeségeket.

Az ad-hoc tesztelésnek valóban meg kell találnia a helyét az SDLC-ben, azonban ha nem a megfelelő módon közelítjük meg, költségesnek és az értékes tesztelési idő elvesztegetésének bizonyulhat. Ezért az alábbiakban adunk néhány támpontot ahhoz, hogy az ad-hoc tesztelés hatékony legyen:

#1) Azonosítsuk a hibaérzékeny területeket:

Ha jól kézben tartjuk egy adott szoftver tesztelését, egyetértünk abban, hogy lesznek bizonyos funkciók, amelyek hajlamosabbak a hibákra, mint a többiek. Ha új vagy a rendszerben, akkor menj előre, és ellenőrizd az ellenük megnyitott funkciókat v/s hibákat.

A hibák száma egy adott funkcióban megmutatja, hogy az érzékeny, és pontosan azt a területet kell kiválasztanod az ad-hoc teszteléshez. Ez nagyon időhatékony módszernek bizonyul néhány komoly hiba feltárására.

#2) A szakértelem kiépítése:

Kétségtelen, hogy egy nagyobb tapasztalattal rendelkező tesztelő intuitívabb, és jobban ki tudja találni, hol lehetnek a hibák, mint valaki, akinek nincs sok tapasztalata. Azt mondanám, akár tapasztalt, akár nem, az egyénen múlik, hogy belevág-e, és szakértelmet épít-e a tesztelendő rendszerrel kapcsolatban.

Igen, a tapasztalt tesztelők előnyben vannak, mivel az évek során felhalmozott készségeik jól jönnek, de az új tesztelőknek ezt a platformot arra kell használniuk, hogy minél több tudást szerezzenek, hogy jobb ad-hoc forgatókönyveket tervezhessenek.

#3) Hozzon létre tesztkategóriákat:

Mihelyt tisztában van a tesztelendő funkciók listájával, szánjon néhány percet arra, hogy eldöntse, hogyan kategorizálná ezeket a funkciókat és hogyan tesztelné. Például döntsön úgy, hogy a felhasználó által leginkább látható és leggyakrabban használt funkciókat teszteli minden más előtt, mivel ezek kritikusnak tűnnek a szoftver sikere szempontjából.

Ezután kategorizálhatja őket funkcionalitás/prioritás szerint, és szegmensenként tesztelheti őket.

Egy másik példa, ahol ez különösen nagyon fontos, ha van integráció a komponensek vagy modulok között. Ezekben az esetekben rengeteg rendellenesség fordulhat elő. A kategorizálás használata segítene abban, hogy legalább egyszer-kétszer érintsük ezt a fajta tesztelést.

#4) Legyen egy durva tervünk:

Igen, igen, ez a pont egy kicsit összezavarhat, hiszen az ad-hoc tesztelést olyan tesztelésként írtuk le, amelynek nem kell terveznie vagy dokumentálnia. Az ötlet itt az, hogy ragaszkodjunk az ad-hoc tesztelés lényegéhez, de mégis legyen néhány durva mutató feljegyezve, hogy hogyan tervezzük a tesztelést.

Egy nagyon egyszerű példa, hogy néha egyszerűen nem tudunk emlékezni az összes tesztre, amit el akarunk végezni. Ha tehát feljegyezné őket, az biztosítaná, hogy ne hagyjon ki semmit.

#5) Eszközök:

Vegyünk egy példát, amellyel mindannyian nagyon gyakran szembesülünk. Sokszor, ha megfigyeled, a funkcionalitás tesztelése önmagában sikeres, és nem jelentenek eltérést a viselkedésében. A kulisszák mögötti naplók azonban jelenthetnek néhány látott kivételt, amelyekről a tesztelők lemaradhatnak, mivel semmilyen módon nem akadályozzák a tesztelési célt.

Ezek akár nagy súlyosságúak is lehetnek. Ezért nagyon fontos, hogy megtanuljuk és olyan eszközöket használjunk, amelyek segítenek ezt azonnal kiszűrni.

#6) További hibák dokumentálása:

Még egyszer megértem, hogy ez megint szemöldököt emelhet. A dokumentációnak nem kell részletesnek lennie, elég egy kis feljegyzés a saját referenciaként a különböző lefedett forgatókönyvekről, az érintett lépésekben való eltérésről és az adott tesztfunkció-kategóriához tartozó hibák rögzítéséről.

Ez segít javítani a teljes tesztvödröt is, amivel eldöntheted, hogyan javítsd a meglévő teszteseteket, vagy szükség esetén adj hozzá újabbakat.

Következtetés

Részletesen megvitattuk az ad-hoc tesztelési technikákat – erősségeit, gyengeségeit, azokat a helyzeteket, ahol előnyös és nem előnyös lenne.

Ez az egyik tesztelési technika, amely garantálja, hogy maximálisan kielégíti és kielégíti a tesztelő kreativitását. Az egész tesztelői pályafutásom során a legnagyobb elégedettséget az ad-hoc tesztelésből merítem, mivel az újító kedvnek nincs határa, és a végén csak még több tudást szerezhetünk.

A fentiek után a legfontosabb dolog, amit a fenti információkból magunkkal vihetünk, az lenne, hogy meghatározzuk, hogyan lehet kihasználni az ad-hoc tesztelés erősségeit, és hogyan lehet hozzáadott értéket teremteni a teljes tesztelési folyamathoz és a termékminőséghez.

A szerzőről:

Beszámoló a szerzőről: Ez Sneha Nadig vendégcikke. Tesztvezetőként dolgozik, több mint 7 éves tapasztalattal rendelkezik manuális és automatizálási tesztelési projektekben.

Végez ad-hoc tesztelést a projektjén? Mik a javaslatai, hogy az ad-hoc tesztelés sikeres legyen?