Az ad-hoc tesztelés a szoftvertesztelés egy olyan típusa, amelyet a fejlesztők és a szoftvercégek a szoftver aktuális iterációjának ellenőrzése során alkalmaznak. A tesztelés ezen formája nagyobb betekintést nyújt a programba, és olyan problémákat tár fel, amelyekre a hagyományos tesztelés nem képes rávilágítani.
Rendkívül fontos, hogy a tesztelő csapatok teljes mértékben megértsék az ad hoc tesztelési folyamatot, hogy tudják, hogyan kerüljék meg a kihívásokat, és hogyan biztosítsák, hogy a csapat sikeresen alkalmazza ezt a technikát.
Ha pontosan tudjuk, hogyan működik az ad-hoc tesztelés, és milyen eszközökkel könnyíthetjük meg a végrehajtását, akkor a vállalkozás folyamatosan fejlesztheti saját minőségbiztosítási eljárásait. A formális tesztelési folyamat nagyon specifikus szabályokat követ, ami azt eredményezheti, hogy a csapat bizonyos hibákat kihagy – az ad-hoc ellenőrzések megkerülhetik ezeket a vakfoltokat, és gyorsan tesztelhetnek minden szoftverfunkciót.
Ebben a cikkben alaposan megvizsgáljuk az ad-hoc tesztelést, és azt, hogyan használhatja előnyére a szoftvertermékek fejlesztése során.
Ad-Hoc tesztelés jelentése: Mi az Ad-Hoc tesztelés?
Az ad-hoc tesztelés olyan minőségbiztosítási folyamat, amely elkerüli a formális szabályokat és a dokumentációt – segít a tesztelőknek megtalálni az alkalmazásban azokat a hibákat, amelyeket a hagyományos megközelítések nem tudnak azonosítani. Ez általában a szoftver átfogó ismeretét igényli a tesztelés megkezdése előtt – beleértve a program belső működésének megértését is. Ezeknek az ad-hoc ellenőrzéseknek az a célja, hogy a felhasználói bevitelt tükröző módon törjék meg az alkalmazást, figyelembe véve a különböző lehetséges helyzeteket, hogy a fejlesztők javíthassák a meglévő problémákat.
A dokumentáció hiánya központi eleme ennek a technikának, amely nem tartalmaz ellenőrző listát vagy teszteseteket, amelyek a tesztelőket az alkalmazás jellemzőihez vezetnék. Az ad-hoc tesztelés teljes egészében a szoftver teszteléséről szól, amelyről a csapat úgy dönt, hogy az adott pillanatban hatékony. Ez figyelembe veheti a már meglévő formális teszteket, de egyszerűen csak annyi teszt elvégzését is magában foglalhatja, amennyit csak lehet az erre a technikára szánt (valószínűleg korlátozott) idő alatt.
1. Mikor és miért van szükség ad-hoc tesztelésre a szoftvertesztelésben?
A vállalatok elsősorban azért végeznek ad-hoc tesztelést, mert képes olyan hibák feltárására, amelyeket a hagyományos megközelítések nem találnak meg. Ennek számos oka lehet, például az, hogy a hagyományos tesztelési esetek egy különösen szabványosított folyamatot követnek, amely nem tudja figyelembe venni az alkalmazás sajátosságait.
Minden tesztelési típus új perspektívákat és érdekes megközelítéseket kínálhat a minőségbiztosításhoz – ez a szokásos tesztelési stratégiával kapcsolatos problémákat is megmutatja. Ha például az ad-hoc tesztelés olyan problémát azonosít, amellyel a csapat tesztesetei nem foglalkoznak, akkor ez arra utal, hogy a tesztelési módszertan újrakalibrálása hasznos lehet.
A tesztelők a tesztelési folyamat bármely pontján végezhetnek ad-hoc ellenőrzéseket. Ez jellemzően a hagyományos (és formálisabb) minőségbiztosítás kiegészítéseként szolgál, és ezt szem előtt tartva a tesztelők ad-hoc ellenőrzéseket végezhetnek, miközben kollégáik formálisabb vizsgálatokat végeznek. Lehet, hogy inkább a formális tesztelési folyamat utánra tartogatják az ad hoc ellenőrzéseket, mint olyan utóellenőrzést, amely kifejezetten a potenciális vakfoltokat célozza meg.
Az ad-hoc tesztelés akkor is hasznos lehet, ha a dokumentáció hiánya miatt különösen kevés idő áll rendelkezésre – a megfelelő időpont a vállalattól és az általa preferált megközelítéstől függ.
2. Amikor nincs szükség Ad-Hoc tesztelésre
Ha nincs elegendő idő mind az ad-hoc, mind a formális tesztelésre, fontos, hogy a csapat az utóbbit helyezze előtérbe, mivel ez biztosítja a jelentős tesztelési lefedettséget – még akkor is, ha még mindig vannak hiányosságok.
Ha a csapat formális tesztjei olyan hibákat találnak, amelyek javítást igényelnek, általában jobb megvárni, amíg a fejlesztők befejezik a szükséges változtatásokat, hogy ad-hoc ellenőrzéseket hajtsanak végre. Ellenkező esetben az általuk szolgáltatott eredmények hamarosan elavulttá válhatnak, különösen, ha a tesztek a már hibákkal küzdő komponensre vonatkoznak.
Ezen túlmenően a béta tesztelési szakasz előtt ad-hoc tesztelésnek kell történnie.
3. Ki vesz részt az ad-hoc tesztelésben?
Az Ad-Hoc tesztelési folyamatnak számos kulcsszerepe van, többek között:
– A szoftvertesztelők a csapat fő tagjai, akik ad hoc ellenőrzéseket végeznek. Ha páros vagy páros tesztelést hajt végre, akkor a tesztelők közül többen együtt dolgoznak ugyanazon az alkatrészen.
– A fejlesztők a hivatalos minőségbiztosítási szakasz előtt önállóan is használhatják ezeket az ellenőrzéseket saját szoftverük gyors ellenőrzésére, bár ez kevésbé mélyreható, mint a dedikált ad-hoc tesztelés.
– A csapat- vagy osztályvezetők engedélyezik az átfogó tesztelési stratégiát – segítve a tesztelőket annak meghatározásában, hogy mikor kezdjék meg az ad-hoc tesztelést, és hogyan hajtsák végre azt anélkül, hogy megzavarnák a többi ellenőrzést.
Az ad-hoc tesztelés előnyei
Az ad-hoc tesztelés előnyei a szoftvertesztelésben a következők:
1. Gyors megoldások
Mivel ezek a tesztek nem igényelnek gyakori dokumentációt az ellenőrzések előtt, alatt és után, a csapatok sokkal gyorsabban azonosíthatják a problémákat. Ez az egyszerűség óriási szabadságot biztosít a tesztelőknek.
Ha például tesztelnek egy komponenst, és nem tudnak hibát azonosítani, a csapat egyszerűen továbbléphet a következő tesztelésre anélkül, hogy ezt a dokumentumban rögzítenék.
2. Kiegészíti az egyéb vizsgálati típusokat
Egyetlen tesztelési stratégia sem tökéletes, és a 100%-os lefedettséget általában lehetetlen elérni – még átfogó ütemtervvel sem. A hagyományos tesztelésben mindig lesznek hiányosságok, ezért fontos, hogy a vállalatok többféle megközelítést integráljanak.
Az ad-hoc tesztelés célja kifejezetten az olyan problémák megtalálása, amelyekre a formális tesztelés nem terjed ki, és ezáltal szélesebb körű tesztelési lefedettséget garantál.
3. Rugalmas végrehajtás
Az ad-hoc tesztelés a minőségbiztosítási folyamat bármely pontján megtörténhet a bétatesztelés előtt, így a vállalatok és a csapatok eldönthetik, hogy mikor a legjobb elvégezni ezeket az ellenőrzéseket. Dönthetnek úgy, hogy a hagyományos teszteléssel párhuzamosan ad-hoc teszteket végeznek, vagy várhatnak a tesztelés utánig – mindegy, hogy mi történik, a csapat profitál a rendelkezésükre álló lehetőségekből.
4. Nagyobb együttműködés
A fejlesztők jobban részt vesznek ebben a folyamatban, mint sok más tesztelési formában – különösen akkor, ha a vállalat társ- és páros tesztelést alkalmaz.
Ennek eredményeképpen a fejlesztők jobb betekintést nyerhetnek saját alkalmazásaikba, és talán képesek lesznek a hibákat magasabb színvonalon kezelni. Ez segít a szoftver általános minőségének további javításában.
5. Különböző perspektívák
Az ad-hoc tesztelés új szemszögből mutathatja be az alkalmazást, segítve a tesztelőket abban, hogy új módon ismerkedjenek meg ezekkel a funkciókkal. A további szempontok kritikusak a tesztelés során, mivel a formális ellenőrzések gyakran legalább kisebb hiányosságokat tartalmaznak.
Ha az ad-hoc tesztelők kifejezetten azzal a céllal használják a szoftvert, hogy feltörjék azt, akkor könnyebben megtalálják a program korlátait.
Az ad-hoc tesztelés kihívásai
Az ad-hoc tesztelési folyamat számos kihívással is jár, például:
1. Nehézségek a jelentéstétellel
A dokumentáció hiánya sokkal gyorsabbá teszi az ad-hoc tesztelést, de megnehezítheti a jelentéstételt is, ha nem egy komolyabb problémáról van szó.
Például egy korábban elvégzett ellenőrzés egy későbbi időpontban relevánsabbá válhat, annak ellenére, hogy kezdetben nem vezetett jelentős eredményekhez. Átfogó dokumentáció nélkül a csapat esetleg nem tudja megmagyarázni ezeket a teszteket.
2. Kevésbé megismételhető
Hasonlóan, a tesztelők nem biztos, hogy teljesen tisztában vannak az általuk megfigyelt reakciók kiváltásához szükséges pontos feltételekkel. Például egy ad-hoc ellenőrzés, amely hibát ad vissza, nem biztos, hogy elegendő információval rendelkezik ahhoz, hogy a csapat intézkedni tudjon. Lehet, hogy nem tudják, hogyan lehet megismételni ezt a tesztet, és ugyanazt az eredményt kapni.
3. Szoftveres tapasztalatot igényel
Mivel az ad-hoc tesztelés során a sebesség kulcsfontosságú, és általában az alkalmazás feltörésével próbálkoznak, fontos, hogy ezek a tesztelők jól ismerjék a programot.
A működés ismerete lehetővé teszi a tesztelők számára, hogy többféleképpen törjék meg és manipulálják a szoftvert, de ez jelentősen megnövelheti az ad-hoc tesztelés készségigényét.
4. Korlátozott elszámoltathatóság
A dokumentáció hiánya a rossz jelentésnél több problémát is okozhat; akaratlanul is meghosszabbíthatja a tesztelési folyamatot, ami hatással lehet a gyors, egyedi ad-hoc tesztek hasznosságára.
A tesztelők nehezen tudják nyomon követni a fejlődésüket, ha nincs megfelelő dokumentáció az egyes szakaszokban. Ez akár azt is eredményezheti, hogy megismételnek egy olyan ellenőrzést, amelyet más tesztelők már elvégeztek.
5. Nem feltétlenül tükrözi a felhasználói élményt
Gyakorlatilag minden tesztelési típus célja a végfelhasználókat valamilyen módon érintő hibák kimutatása. Az ad-hoc tesztelés elsősorban arra épül, hogy egy tapasztalt tesztelő megpróbál egy tapasztalatlan felhasználót utánozni, és ennek következetesnek kell lennie minden egyes ellenőrzés során, beleértve az alkalmazás megtörésére tett kísérleteket is.
Az Ad-Hoc tesztek jellemzői
A sikeres ad-hoc tesztek fő jellemzői a következők:
1. Nyomozói tevékenység
Az ad-hoc tesztelés fő prioritása az alkalmazás hibáinak azonosítása olyan technikák segítségével, amelyeket a hagyományos ellenőrzések nem vesznek figyelembe. Az ad-hoc vizsgálatok kifejezetten azzal a céllal vizsgálják át ezt a szoftvert, hogy lyukakat találjanak a csapat tesztelési eljárásában, beleértve a tesztesetek lefedettségét is.
2. Strukturálatlan
Az ad hoc ellenőrzéseknek általában nincs meghatározott tervük azon túl, hogy a lehető legtöbb tesztet végzik a formális minőségbiztosítás tipikus keretein kívül. A tesztelők a könnyebbség kedvéért általában komponensek szerint csoportosítják az ellenőrzéseket, de még ez sem szükséges – akár az is előfordulhat, hogy az ellenőrzések végrehajtása közben találják ki az ellenőrzéseket.
3. Tapasztalatvezérelt
Az ad-hoc tesztelők a már meglévő szoftveres tapasztalataikat használják fel annak felmérésére, hogy mely tesztek hoznák a legtöbb hasznot, és a formális tesztelés gyakori vakfoltjainak kezelésére.
Bár a tesztelési folyamat még mindig teljesen strukturálatlan, a tesztelők a stratégiájuk meghatározásakor többek között a korábbi ad-hoc ellenőrzésekről szerzett tudásukat alkalmazzák.
4. Széleskörű
Nincsenek pontos útmutatók arra vonatkozóan, hogy a csapatnak milyen ellenőrzéseket kell lefuttatnia az ad-hoc tesztelés során, de jellemzően számos összetevőre kiterjednek – esetleg nagyobb hangsúlyt fektetve az alkalmazás érzékenyebb aspektusaira. Ez segít a tesztelőknek garantálni, hogy vizsgálataik teljes mértékben ki tudják egészíteni a formális tesztelést.
Mit tesztelünk az Ad-Hoc tesztekben?
A minőségbiztosítási csapatok általában a következőket tesztelik az ad-hoc tesztelés során:
1. Szoftverminőség
Ezeknek az ellenőrzéseknek a célja az alkalmazás olyan hibáinak azonosítása, amelyeket a hagyományos tesztelés nem tud feltárni; ez azt jelenti, hogy a folyamat elsősorban az alkalmazás általános állapotát vizsgálja.
Minél több hibát találnak az ad-hoc teszteléssel, annál több javítást tudnak a fejlesztők a határidő előtt végrehajtani.
2. Tesztek
Az ad-hoc tesztelés általában nem valósít meg teszteseteket – és ez kifejezetten azért van így, hogy a csapat megvizsgálhassa, mennyire hatékonyak a bőséges lefedettség biztosításában. A tesztesetek valószínűleg nem megfelelőek, ha az ad-hoc ellenőrzések olyan hibákat találnak, amelyeket a hagyományos tesztelési folyamatok nem.
3. Vizsgáló személyzet
A cél az is lehet, hogy ellenőrizzék a tesztelő csapat készségeit és tudását, még akkor is, ha a tesztesetek megfelelőek. Például az esetek végrehajtásának módszertana nem lehet megfelelő, és az ad-hoc tesztelés kritikus lehet a tesztelés lefedettségében keletkező hiányosságok megszüntetéséhez.
4. Szoftveres korlátozások
Az ad-hoc tesztelés arra is törekszik, hogy megértse az alkalmazás korlátait – például azt, hogyan reagál a váratlan bemenetekre vagy a nagy rendszerterhelésre. A tesztelők kifejezetten a program hibaüzeneteit vizsgálhatják, és azt, hogy az alkalmazás milyen jól teljesít, amikor jelentős nyomás alatt van.
Tisztázzuk a félreértéseket:
Ad-Hoc tesztelés és feltáró tesztelés
Egyesek az ad-hoc és a feltáró tesztelést szinonimának tekintik, bár az igazság ennél bonyolultabb.
1. Mi a feltáró tesztelés?
A feltáró tesztelés olyan minőségbiztosítási eljárásokra utal, amelyek a szoftvert holisztikus szempontból vizsgálják, és kifejezetten a feltáró és a tesztelési folyamatokat egyesítik egyetlen módszerben. Ez tipikusan a teljesen strukturált tesztelés és a teljesen szabad formájú ad-hoc ellenőrzések közötti középutat jelenti.
A feltáró tesztelés speciális forgatókönyvek esetén működik a legjobban, például ha gyors visszajelzésre van szükség, vagy ha a csapatnak szélsőséges esetekkel kell foglalkoznia. Ez a fajta tesztelés általában akkor éri el teljes potenciálját, ha a csapat mellette szkriptelt tesztelést alkalmaz.
2. A feltáró tesztelés közötti különbségek
és Ad-Hoc tesztelés
A legnagyobb különbség az ad-hoc és a feltáró tesztelés között az, hogy az előbbi dokumentációt használ az ellenőrzések rögzítésére és megkönnyítésére, míg az ad-hoc tesztelés ezt teljesen elkerüli. A feltáró tesztelés nagyobb hangsúlyt fektet a tesztelés szabadságára, de soha nem olyan szinten, mint az ad-hoc megközelítés, amely teljesen strukturálatlan.
A feltáró tesztelés az alkalmazás és annak belső működésének megismerését is magában foglalja ezen ellenőrzések során – az ad-hoc tesztelők ehelyett gyakran már azelőtt átfogó ismeretekkel rendelkeznek a szoftver funkcionalitásáról, mielőtt elkezdenék.
Ad-Hoc tesztek típusai
Az ad-hoc tesztelésnek három fő formája van a szoftvertesztelésben, többek között:
1. Majom tesztelés
Az ad-hoc tesztelés talán legnépszerűbb típusa, a majomtesztek azok, amelyek során egy csapat véletlenszerűen nézi meg a különböző komponenseket.
Ez általában az egységtesztelési folyamat során történik, és egy sor ellenőrzést hajt végre tesztesetek nélkül. A tesztelők teljesen strukturálatlan módon, egymástól függetlenül vizsgálják az adatokat, lehetővé téve számukra, hogy megvizsgálják a rendszer egészét és annak képességét, hogy ellenálljon a felhasználói bemenetek okozta intenzív terhelésnek.
Ezeknek a nem scriptelt technikáknak a kimenetének megfigyelése segít a tesztelő csapatnak azonosítani azokat a hibákat, amelyeket más egységtesztek a hagyományos tesztelési módszerek hiányosságai miatt kihagytak.
2. Buddy tesztelés
Ad-hoc környezetben a haver-tesztek legalább két munkatársat – jellemzően egy tesztelőt és egy fejlesztőt – vesznek igénybe, és elsősorban az egységtesztelési fázis után zajlanak. A “haverok” együtt dolgoznak ugyanazon a modulon, hogy megtalálják a hibákat. Sokrétű képességeik és átfogó tapasztalatuk hatékonyabb csapattá teszi őket, ami segít enyhíteni a dokumentáció hiánya miatt felmerülő számos problémát.
A fejlesztő akár maga is javasolhatja a tesztek egy részét, hogy azonosítani tudja azokat az összetevőket, amelyek nagyobb figyelmet igényelnek.
3. Páros tesztelés
A páros tesztelés hasonló abban a tekintetben, hogy két munkatársat von be, de ez általában két különálló tesztelő, akik közül az egyik végzi a tényleges teszteket, míg a másik jegyzetel.
Hivatalos dokumentáció nélkül is, a feljegyzések segítségével a csapat informálisan nyomon követheti az egyes ad-hoc ellenőrzéseket. A tesztelő és az írnok szerepe a teszteléstől függően cserélődhet, vagy a páros a teljes folyamat során megtarthatja a kijelölt szerepét.
Általában az a tesztelő végzi a tényleges ellenőrzéseket, akinek több tapasztalata van – bár a munkát mindig megosztják egymással.
Kézi vagy automatizált Ad-Hoc tesztek?
Az automatizált tesztelés segíthet a csapatoknak még több időt megtakarítani a minőségbiztosítási szakaszban; így a tesztelők több ellenőrzést tudnak beilleszteni az ütemtervükbe. Még határozott struktúra nélkül is elengedhetetlen, hogy a tesztelők a lefedettség maximalizálásán dolgozzanak, és az automatizálás ösztönzi a szoftver mélyebb vizsgálatát.
Az automatizált ad-hoc ellenőrzések általában pontosabbak, mint a kézi tesztek, mivel képesek elkerülni az emberi hibákat a rutinfeladatok során – ez különösen akkor hasznos, ha ugyanazokat a teszteket különböző iterációkban hajtják végre. Ennek az eljárásnak a sikere általában a csapat által kiválasztott automatizált tesztelési eszköztől és annak funkcionalitásától függ.
Az automatizált tesztelésnek azonban vannak bizonyos korlátai. Az ad-hoc tesztelés fő erőssége például az, hogy képes emulálni a felhasználói bemenetet, és véletlenszerű ellenőrzéseket hajt végre, amint a tesztelő előáll velük. Ezek a tesztek elveszíthetik véletlenszerűségüket, ha a szervezet tesztelési programja megküzd az összetett ellenőrzésekkel.
Az ezen igen specifikus feladatok automatizálásának időigénye szintén korlátozhatja a folyamat tipikus időmegtakarítását. Fontos, hogy a csapatok alaposan megvizsgálják a rendelkezésre álló automatizálási eszközöket, hogy megtalálják a vállalat projektjének megfelelőt.
Mire van szüksége az Ad-Hoc tesztelés megkezdéséhez?
Íme az ad-hoc tesztelés fő előfeltételei:
1. Képzett személyzet
Mivel az ad-hoc tesztek a szoftver belső működésének gyors, szúrópróbaszerű ellenőrzését jelentik, általában segít, ha a tesztelőknek van tapasztalatuk a szoftverrel kapcsolatban. Emellett ismerniük kell a legfontosabb tesztelési elveket is – így könnyedén azonosíthatják a leghatékonyabb ellenőrzéseket.
2. Strukturálatlan megközelítés
A tesztelőknek hajlandónak kell lenniük arra, hogy feladják az ad-hoc tesztelésre vonatkozó szokásos stratégiáikat; ez a gondolkodásmód ugyanolyan kritikus, mint maguk a minőségellenőrzések. Ez a módszer csak struktúra és dokumentáció nélkül lehet sikeres, és létfontosságú, hogy a tesztelők ezt minden szakaszban szem előtt tartsák.
3. Automatizálási szoftver
Bár az ad-hoc tesztelés inkább a véletlenszerű bemenetek és feltételek tesztelésére támaszkodik, az automatizálás még mindig nagyon hatékony technika bármilyen kontextusban.
Emiatt az ad-hoc ellenőrzéseknél lehetőség szerint mégis érdemes automatizált tesztelési eszközöket alkalmazni, mivel a megfelelő alkalmazás jelentősen egyszerűsítheti a folyamatot.
4. Egyéb vizsgálati formák
Az ad-hoc tesztek a legjobban más, formálisabb megközelítést alkalmazó ellenőrzések mellett működnek – segítve a csapatot abban, hogy a szoftver teljes lefedettségét garantálják. Létfontosságú, hogy a tesztelők vegyítsék a különböző technikákat, bár ez történhet az ad-hoc tesztelés előtt, közben vagy után.
Ad-Hoc tesztelési folyamat
A szokásos lépések, amelyeket a tesztelőknek követniük kell, amikor ad-hoc tesztelést végeznek a szoftvertesztelésben, a következők:
1. Ad-hoc tesztelési célok meghatározása
Ez a szakasz a dokumentáció és a struktúra hiánya miatt korlátozott, de még mindig kiemelkedően fontos, hogy a csapatnak világos fókusza legyen. A tesztelők elkezdhetik megosztani egymással homályos elképzeléseiket arról, hogy mely teszteket kell lefuttatniuk, és mely komponenseket kell prioritásként kezelniük.
2. Az ad-hoc tesztcsoport kiválasztása
Miközben a csapat számos lehetséges ad-hoc ellenőrzést talál ki, azt is kitalálják, hogy mely tesztelők lennének a legalkalmasabbak az ilyen típusú tesztelésre. Általában olyan tesztelőket választanak ki, akik alaposan ismerik az alkalmazást, és egy fejlesztővel is párosíthatják őket.
3. Ad-hoc tesztek végrehajtása
Miután eldöntötték, hogy mely tesztelők alkalmasak erre a szakaszra, ezek a csapattagok a tesztelés egy előre egyeztetett pontján kezdik meg az ellenőrzéseket. Céljuk, hogy a lehető legtöbb ad-hoc ellenőrzést elvégezzék – amelyeket a tesztelők esetleg csak ebben a szakaszban találnak ki.
4. A vizsgálati eredmények kiértékelése
A tesztek befejezésekor (vagy akár az egyes ellenőrzések között) a tesztelők kiértékelik az eredményeket, de anélkül, hogy azokat hivatalosan dokumentálnák egy tesztesetben. Ha bármilyen problémát fedeznek fel az alkalmazással kapcsolatban, informálisan rögzítik azokat, és megbeszélik a csapat következő lépéseit.
5. A felfedezett hibák jelentése
Miután kiértékelték az eredményeket, a tesztelőknek tájékoztatniuk kell a fejlesztőket a szoftverben található hibákról, hogy elegendő idő álljon rendelkezésükre azok kijavítására a kiadás előtt.
A tesztelési csoport arra is felhasználja az információkat, hogy meghatározza, hogyan javíthatná hivatalos tesztelési folyamatait.
6. Szükség esetén ismételt vizsgálat
A tesztelő csapat valószínűleg megismétli az ad-hoc eljárást az alkalmazás új iterációinál, hogy ellenőrizze, mennyire jól kezeli a frissítéseket. Mivel a tesztelők a korábban azonosított hiányosságok közül sokat kijavítottak a teszteseteikben, a jövőbeni ad hoc ellenőrzések más megközelítést igényelhetnek.
Legjobb gyakorlatok az ad-hoc teszteléshez
Vannak bizonyos gyakorlatok, amelyeket a tesztelő csapatoknak az ad-hoc tesztelés során alkalmazniuk kell, többek között:
1. A potenciális tesztelési hiányosságok megcélzása
Bár az ad-hoc tesztelés sokkal kevesebb tervezést igényel, mint a többi típus, a csapat célja mégis a minőségbiztosítás hiányosságainak kezelése. Ha az ad-hoc tesztelők a csapat teszteseteivel kapcsolatban valamilyen konkrét problémára gyanakodnak, akkor az ellenőrzések során ezt kell prioritásként kezelniük.
2. Fontolja meg az automatizálási szoftvert
Az olyan automatizálási stratégiák, mint a hiperautomatizálás, számos előnnyel járhatnak az ad-hoc teszteket végrehajtani kívánó vállalatok számára.
Ennek sikere több kulcsfontosságú tényezőtől függ, beleértve a vállalkozás által választott eszközt, valamint az ad-hoc tesztek általános összetettségét.
3. Készítsen átfogó jegyzeteket
A dokumentáció hiánya az ad-hoc tesztelésben elsősorban ezt a folyamatot egyszerűsíti tovább – a csapat számára előnyös lehet, ha menet közben informális feljegyzéseket készítenek. Ezáltal a tesztelőknek egyértelmű nyilvántartást kapnak ezekről az ellenőrzésekről és eredményeikről, ami növeli az általános megismételhetőséget.
4. A tesztek folyamatos finomítása
Az ad-hoc tesztelők folyamatosan finomítják a megközelítésüket, hogy figyelembe vegyék a csapat tesztelési stratégiájában bekövetkezett változásokat. Ha például a vállalat szoftverének újabb verzióit vizsgálják, akkor ezeket az ellenőrzéseket az újabb és szélesebb körű formális tesztelési esetekre reagálva módosíthatják.
7 hiba és buktató a bevezetés során
Ad-Hoc tesztek
Mint minden tesztelési folyamat esetében, itt is számos lehetséges hibát lehet elkövetni, amelyek elkerülésére a csapatnak törekednie kell, mint például:
1. Tapasztalatlan tesztelők
Az ad-hoc tesztelés elvárt ütemének fenntartása érdekében a csoportvezetőnek a tesztelőket a tudásuk és képességeik alapján kell kijelölnie. Míg a tesztelés számos formája alkalmas a belépő szintű minőségbiztosítási személyzet számára, az ad hoc ellenőrzésekhez olyan csapattagokra van szükség, akik teljes mértékben értik a szoftvert; lehetőleg olyanokra, akiknek van tapasztalatuk az ilyen tesztek futtatásában.
2. Fókuszálatlan ellenőrzések
Az ad-hoc tesztelés a gyorsabb tempó miatt jelentősen javíthatja a tesztek lefedettségét – a csapatnak nem kell minden egyes ellenőrzés előtt és után kiterjedt dokumentációt kitöltenie.
Az ad-hoc tesztelőknek azonban továbbra is erős fókuszt kell fenntartaniuk; például dönthetnek úgy, hogy bizonyos, nagyobb hibakockázatú komponenseket kiemelten kezelnek.
3. Nincs tervezés
Bármilyen terv elkerülése korlátozhatja az ad-hoc tesztelés hatékonyságát. A megközelítés strukturálatlan jellege ellenére fontos, hogy a csapat már a kezdet előtt nagyjából tudja, hogy milyen teszteket kell lefuttatni.
Az idő korlátozott ebben a folyamatban, és ha tudjuk, hogyan kell eljárni, az számos előnnyel járhat.
4. Túlságosan strukturált
A spektrum másik végén ez a megközelítés jellemzően a tervezés hiányára támaszkodik, mivel ez segíti a tesztelőket abban, hogy aktívan felforgassák a teszteseteket és megtalálják a rejtett hibákat.
Az ad hoc tesztelést véletlenszerű tesztelésnek is nevezik, és egy struktúra rákényszerítése megakadályozhatja, hogy ezek az ellenőrzések hibákat találjanak.
5. Nincs hosszú távú változás
Az ad-hoc tesztelés célja a csapat teszteseteinek gyenge pontjainak azonosítása; ez ugyanúgy vizsgálja az általános stratégiát, mint magát a szoftvert.
Ez azonban azt jelenti, hogy az ad-hoc tesztek általában csak akkor hatékonyak, ha a csapat ezeket az információkat felhasználja arra, hogy idővel finomítsa a hivatalos ellenőrzéseket.
6. Összeférhetetlen adatkészletek
Gyakorlatilag a tesztelés minden formája igényel valamilyen szimulált adatot az alkalmazás reakciójának értékeléséhez; egyes eszközök lehetővé teszik a tesztelők számára, hogy automatikusan feltöltsék a programot mock adatokkal.
Ez azonban nem feltétlenül tükrözi azt, ahogyan a felhasználó a szoftvert használná – az ad hoc ellenőrzésekhez olyan adatkészletekre van szükség, amelyekkel a szoftver valószínűleg találkozni fog.
7. Információs silók
Lényeges, hogy a tesztelők és a fejlesztők folyamatosan kommunikáljanak egymással, még akkor is, ha az utóbbi nem vesz részt az ad-hoc tesztelési folyamatban.
Ez segít mindenkinek megérteni, hogy mely teszteket végezték el – megmutatja a következő lépéseket, miközben megakadályozza, hogy a tesztelők feleslegesen ismételjék meg bizonyos ellenőrzéseket.
Az Ad-Hoc tesztek kimeneteinek típusai
Az eseti ellenőrzések több különböző kimenetet eredményeznek, többek között:
1. Vizsgálati eredmények
Az egyes tesztek a pontos komponensre és megközelítésre jellemzően eltérő eredményeket produkálnak – ez sokféle lehet.
Általában a tesztelő felelőssége annak megállapítása, hogy az eredmények hibát jelentenek-e, bár a dokumentáció hiánya megnehezíti ennek összehasonlítását az elvárásaival. A csapat továbbítja ezeket az eredményeket a fejlesztőknek, ha bármilyen problémát észlelnek.
2. Tesztnaplók
Maga a szoftver a belső naplók bonyolult rendszerét használja a felhasználói bemenetek nyomon követésére, és számos esetlegesen felmerülő fájl- vagy adatbázis-problémára hívja fel a figyelmet.
Ez belső hibára utalhat, beleértve a szoftver adott részét, amely a problémát okozza. Ezen információk birtokában az ad-hoc tesztelők és a fejlesztők sokkal könnyebben kezelhetik az általuk felfedezett problémákat.
3. Hibaüzenetek
Sok ad-hoc ellenőrzés célja kifejezetten a szoftver megszakítása és a korlátok feltárása, ami azt jelenti, hogy az alkalmazás hibaüzenetei az egyik leggyakoribb kimenete ezeknek a teszteknek.
Azáltal, hogy a csapat szándékosan hibaüzeneteket okoz, bemutathatja, hogy mit lát az átlagos végfelhasználó, amikor az általa végrehajtott váratlan műveletek kedvezőtlen hatást gyakorolnak a program működésére.
Ad-Hoc tesztelési példák
Az alábbiakban három ad-hoc tesztelési forgatókönyv mutatja be, hogy egy csapat hogyan valósíthatja meg ezt különböző alkalmazások esetében:
1. E-kereskedelmi webes alkalmazás
Ha egy vállalat egy e-kereskedelmi alapú webes alkalmazást szeretne tesztelni, akkor ad-hoc teszteléssel – konkrétan majomteszteléssel – vizsgálhatja, hogy a platform mennyire jól kezeli a váratlan felhasználói interakciókat.
A tesztelők célja lehet, hogy az egyes funkciókat a határaikig feszegessék, például irreális mennyiségű terméket adjanak a kosárba, vagy olyan termékeket próbáljanak vásárolni, amelyek már nincsenek raktáron. Nem korlátozzák őket a csapat tesztelési esetei, és kevés korlátja van annak, hogy milyen ellenőrzéseket végezhetnek; a tesztelők akár meg is próbálhatják befejezni a vásárlásokat elavult URL-címek használatával.
2. Asztali alkalmazás
Az ad-hoc tesztelők ezeket a technikákat asztali alkalmazások esetében is alkalmazhatják, esetleg különböző gépekre összpontosítva, és arra, hogy azok mennyire jól fogadják a programot.
A csapat tagjai többször is elvégezhetik ezeket az ellenőrzéseket, hogy lássák, a hardver- vagy szoftverbeállítások változása hogyan befolyásolja az alkalmazás általános teljesítményét. Például egy adott grafikus kártya nehezen tudja megjeleníteni a felületet.
Alternatív megoldásként ezek a tesztelők egyszerűen lehetetlen bemeneteket adhatnak a programjuknak, és megnézhetik, hogyan reagál, például, hogy helyesen jeleníti-e meg a hibaüzeneteket, amelyek megfelelően elmagyarázzák a problémát a végfelhasználónak.
3. Mobil alkalmazás
Az ad-hoc tesztelők egy mobilalkalmazás vizsgálatának egyik módja a biztonsági protokollok tesztelése – megpróbálhatnak például közvetlenül hozzáférni az alkalmazás fejlesztői eszközeihez.
A csapat megpróbálhatja megnézni, hogy képesek-e jogosulatlan műveleteket végrehajtani azáltal, hogy megtalálják a gyakori kiskapukat és kihasználásokat; kifejezetten megkérhetik az alkalmazásbiztonságban jártas munkatársakat, hogy segítsék ezt elő.
Ez magában foglalhatja a fejlesztőkkel való páros tesztelést is, mivel ők rálátásuk van az alkalmazás tervezésére, így a tesztelő feltörheti a szoftvert, és pontosan megmutathatja, hol van hiányosság a biztonságban.
Az észlelt hibák és hibák típusai
Ad-Hoc teszteléssel
Az ad-hoc ellenőrzések számos problémát feltárhatnak egy programmal kapcsolatban, például:
1. Funkcionalitási hibák
Ha egy alkalmazás alapvető funkcióinak vizsgálatára ad-hoc tesztelést alkalmazunk, az komoly hibákat fedezhet fel, amelyek befolyásolhatják a végfelhasználók használatának módját.
Például egy e-kereskedelmi oldal fizetési lehetőségeinek majomtesztje illusztrálja a tranzakciót megakadályozó feltételeket.
2. Teljesítményproblémák
A tesztelők kifejezetten azon dolgozhatnak, hogy teljesítményproblémákat hozzanak létre a programban – például úgy, hogy az adatbázist különböző spam-bemenetekkel töltik fel.
Ez jelentős késleltetésben vagy akár a szoftver általános instabilitásában nyilvánulhat meg, ami valószínűleg (esetleg az egész rendszerre kiterjedő) összeomláshoz vezet.
3. Használhatósági problémák
Ezek az ellenőrzések a felhasználói felület és az általános felhasználói élmény hibáira is rávilágíthatnak. Egy mobilalkalmazás felhasználói felülete például más operációs rendszeren vagy képernyőfelbontáson másképp jelenhet meg. A rossz felhasználói felület miatt a felhasználóknak nehézséget okozhat az alkalmazás működtetése.
4. Biztonsági hibák
Az ad-hoc tesztelés véletlenszerű jellege lehetővé teszi, hogy a gyakori és ritka biztonsági problémák széles skáláját lefedje; a tesztelő ezeket az ellenőrzéseket használhatja arra, hogy megtalálja egy program adminisztratív hátsó ajtaját.
Másik lehetőség, hogy a vizsgálat során kiderül, hogy a szoftver nem rendelkezik adattitkosítással.
Közös ad-hoc tesztelési metrikák
Az ad-hoc tesztelés különböző mérőszámokat használ az eredmények megkönnyítésére, többek között:
1. Hibaérzékelés hatékonysága
Ez a mérőszám azt vizsgálja, hogy a tesztelési folyamat mennyire hatékony a hibák megtalálásában a tesztelés minden egyes formája során, beleértve az ad-hoc tesztelést is. A hibafelderítési hatékonyság a felfedezett hibák százalékos aránya osztva a problémák teljes számával – ez mutatja, hogy a tesztek mennyire hatékonyak.
2. A tesztek lefedettségi aránya
Az ad-hoc tesztelés kiegészítő funkciója a lefedettség növelése azáltal, hogy olyan komponenseket ellenőriz, amelyeket a tesztesetek nem vesznek figyelembe. Ez azt jelenti, hogy a tesztelők arra is törekednek, hogy radikálisan növeljék a tesztek lefedettségét minden ellenőrzés során, amennyire csak tudják.
3. A vizsgálat teljes időtartama
Az ad-hoc tesztelés sokkal gyorsabb, mint más minőségbiztosítási folyamatok – és a tesztelőknek mindenképpen azon kell dolgozniuk, hogy ezt az előnyt megőrizzék. A tesztelési időtartam mérőszámok megmutatják a csapattagoknak, hogyan takaríthatnak meg időt, és hogyan növelhetik tovább az ad-hoc stratégiák előnyeit.
4. Baleseti arány
E tesztek célja gyakran a szoftver megszakítása és összeomlás vagy súlyos hiba okozása – így túlmutatnak a tipikus tesztstratégiákon, és váratlan problémákat találnak. Ennek érdekében segíthet, ha tudja, milyen gyakran törik össze a szoftver, és mi okozza ezeket a problémákat.
Az 5 legjobb Ad-Hoc tesztelési eszköz
A szoftvertesztelésben számos ingyenes és fizetős tesztelési eszköz áll rendelkezésre az ad-hoc teszteléshez – a legjobb öt a következő:
1. ZAPTEST Free & Enterprise Edition
A ZAPTEST egy átfogó szoftvertesztelő program, amely mind az ingyenes, mind a vállalati változatban erős tesztelési + RPA funkciókat biztosít.
Ez a teljes körű szoftverautomatizálás + RPA Suite lehetővé teszi a teljes körű tesztelést különböző asztali és mobil platformokon; a szoftver 1SCRIPT technológiájának köszönhetően a felhasználók ugyanazokat az ellenőrzéseket többször is könnyedén elvégezhetik. Ezen felül az eszköz a legmodernebb számítógépes látásmódot használja, ami lehetővé teszi, hogy a ZAPTEST emberi szemszögből ad-hoc teszteket futtasson.
2. BrowserStack
A BrowserStack egy olyan felhőplatform, amely több mint 3000 különböző gépen képes megkönnyíteni a tesztelést, és további funkciója a Selenium szkriptek automatizálása. Bár erős lefedettséget biztosít a szoftverprojektek számára, a legjobban a böngésző- és mobilalkalmazások esetében működik.
A BrowserStack tesztelési megoldások ingyenes próbaverziót is tartalmaznak 100 perc automatizált teszteléssel – bár ez korlátozottan használható.
Bár a felhőalapú megközelítés hasznos lehet, negatívan befolyásolja a platform válaszidejét.
3. LambdaTest
A LambdaTest hasonlóan felhőalapú technológiát használ, és nagy hangsúlyt fektet a böngészőtesztelésre, ami korlátozhatja hatékonyságát más alkalmazások esetében – bár még mindig jól illeszkedik az iOS és Android programokhoz. Ez egy hasznos platform, ha a skálázhatóság aggodalomra ad okot, és számos más teszt hosting szolgáltatással integrálható.
Néhány felhasználó azonban vegyesen nyilatkozott az alkalmazás árazásáról a különböző, nem próbaverzióban elérhető opciók között, ami potenciálisan korlátozza a kisebb szervezetek hozzáférhetőségét.
4. TestRail
A TestRail általában meglehetősen alkalmazkodóképes, mivel teljes egészében a böngészőben fut, és annak ellenére, hogy nagy hangsúlyt fektet a hatékony tesztesetekre, közvetlen ad-hoc funkciókkal is büszkélkedhet. Az általa minden teszt után biztosított analitika segíthet azoknak a csapatoknak is, amelyek aktívan kerülik a saját független dokumentáció készítését, miközben lehetővé teszi számukra a tesztelési folyamat validálását.
A nagyobb csomagoknak azonban nehézséget okozhat a böngészőalapú formátum, ami jelentősen korlátozhatja az ad-hoc tesztelés időmegtakarítását.
5. Zephyr
A Zephyr a SmartBear tesztmenedzsment platformja, amely segít a minőségbiztosítási csapatoknak javítani a tesztelés átláthatóságát, miközben jól integrálható más hibakövető szoftverekkel is.
Ez a funkció azonban csak bizonyos alkalmazásokra korlátozódik, a Confluence és a Jira azok, amelyek a legtöbbet profitálnak a Zephyrből – nem biztos, hogy ezek a leghatékonyabb megoldások minden vállalkozás számára. A Zephyr márkanév alatt több skálázható program is elérhető különböző árakon.
Ad-Hoc tesztelés ellenőrzőlista, tippek és trükkök
Íme további tippek, amelyeket a csapatoknak figyelembe kell venniük az ad-hoc tesztelés során:
1. Az érzékeny komponensek rangsorolása
Egyes funkciók vagy összetevők természetesen nagyobb hibakockázatnak vannak kitéve, mint mások, különösen, ha fontosak a program általános működése szempontjából.
A tesztelés minden megközelítése során azonosítani kell az alkalmazás azon részeit, amelyekre alaposabb figyelmet kell fordítani. Ez különösen akkor hasznos, ha a tesztelésre rendelkezésre álló idő korlátozott.
2. Különböző tesztelési eszközök vizsgálata
Az az eszköz, amelyet egy szervezet a tesztelés megkönnyítésére használ, befolyásolhatja ezen ellenőrzések lefedettségét és megbízhatóságát.
Az ad-hoc teszteléssel érdemes minél több programot megnézni, hogy megtaláljuk azokat, amelyek megfelelnek a felhasználó-központúságának. A számítógépes látás technológiáját használó szoftverek, mint például a ZAPTEST, az emberhez hasonló stratégiával közelíthetik meg az ad-hoc teszteket.
3. Ad-hoc gondolkodásmód elfogadása
Az ad-hoc tesztelés óriási szabadságot kínál a minőségbiztosítási szakaszban, de a csapatnak el kell köteleznie magát mellette, hogy a stratégia legfontosabb előnyeit élvezhesse.
Az ad-hoc tesztelőknek például az alapvető jegyzetelésen túl minden szokásos dokumentumot el kell hagyniuk, és teljesen új szemszögből kell megvizsgálniuk a szoftvert.
4. Bízzon a tesztelési ösztönökben
Az ad-hoc teszteléssel vagy általános szoftverellenőrzésekkel szerzett tapasztalat segíthet a közös hibapontok kiemelésében, és ez segít a tesztelőknek meghatározni, hogy hogyan lehet kiszúrni a különböző típusú hibákat.
Létfontosságú, hogy a tesztelők bízzanak az ösztöneikben, és ezt a tudást mindig előnyükre fordítsák – megérzik, hogy mely ad-hoc ellenőrzések lennének a leghasznosabbak.
5. A felfedezett hibák teljes körű rögzítése
Bár az ad-hoc tesztelésnek nincs hivatalos dokumentációja, és többnyire informális feljegyzésekre támaszkodik, mégis alapvető fontosságú, hogy a csapat képes legyen azonosítani és kommunikálni a szoftverhiba okát.
Naplózniuk kell a teszt által szolgáltatott minden olyan információt, amely a fejlesztők számára fontos, például a problémák lehetséges okait.
6. Mindig vegye figyelembe a felhasználót
A tesztelés minden formája bizonyos mértékig a felhasználó általános élményéhez kíván igazodni – ez alól az ad-hoc tesztelés sem kivétel. Bár gyakran mélyebben vizsgálja az alkalmazás belső működését, sőt, még a belső kódját is, az ad-hoc tesztelőknek meg kell próbálniuk feltörni ezt a szoftvert olyan módon, ahogyan a felhasználók elméletileg képesek lennének rá.
7. A folyamat folyamatos javítása
A tesztelő csapatoknak finomítaniuk kell az ad-hoc tesztelésre vonatkozó megközelítésüket ugyanazon szoftver több iterációja között és egyik projektről a másikra.
Visszajelzést gyűjthetnek a fejlesztőktől, hogy lássák, az ad-hoc tesztek mennyire segítették a minőségbiztosítási szakaszt, és hogy sikerült-e jelentősen növelni a tesztek lefedettségét.
Következtetés
Az ad-hoc tesztelés segíthet mindenféle szervezetnek hitelesíteni a szoftvertesztelési stratégiáját, de a technika végrehajtásának módja jelentős tényező lehet a hatékonyságában.
A különböző tesztelési típusok kiegyensúlyozása a kulcsa annak, hogy az ad-hoc ellenőrzésekből a legtöbb hasznot lehessen kihozni – különösen, mivel ez a tesztelési forma a többi tesztelési forma kiegészítésére szolgál egy stratégiai hiányosság betöltésével.
Egy olyan alkalmazással, mint a ZAPTEST, a csapatok nagyobb magabiztossággal és rugalmassággal végezhetnek ad-hoc teszteket, különösen, ha automatizálást hajtanak végre. Nem számít a csapat konkrét megközelítése, az ad-hoc tesztelés iránti elkötelezettségük forradalmasíthatja az egész programot vagy projektet.
