Adhoc tesztelés: Egy rövid jegyzet példákkal – Testbytes Adhoc tesztelés:

FacebookTwitterLinkedInShare

Az adhoc tesztelést általában a rendszer megbontása érdekében és nem szokványos módszerekkel végzik. Az adhoc tesztelés legmegdöbbentőbb jellemzője, hogy nincs teszttervezési technika a tesztesetek létrehozásához.

A folyamatot általában azért végzik, hogy megtalálják a szoftver kiskapuit. Mivel az Adhoc tesztelés nem rendelkezik tesztesetekkel, gyakran dokumentáció nélkül végzik.

Nézze meg a folyamatot részletesen

Az Adhoc tesztelés olyan technika, amely a “strukturálatlan tesztelés” kategóriába tartozik.

Adhoc elv

Mi a strukturált és a strukturálatlan tesztelés?

Strukturált tesztelés

Ebben a megközelítésben minden tevékenység, ami a tesztelési eljárás során történik, a tesztesetek létrehozásától a szekvenciális végrehajtásukig, minden szkriptelt. A tesztelők ezt a forgatókönyvet követve, annak megfelelően végzik el a teszteket.

Szerkezetlen tesztelés

Ezzel a megközelítéssel a tesztelés általában hibakitalálással történik, ahol a tesztelők a teszteseteket, magának a tesztelési folyamatnak a során hozzák létre.

Mi az adhoc tesztelés?

Adhoc tesztelési diagram

A fentiekben tárgyaltak szerint ez egyfajta strukturálatlan tesztelési megközelítés, ahol a tesztelési folyamat megkezdése előtt nem készül szervezett terv.

Ezért a tesztelés előtt nem történik követelménydokumentáció vagy tesztesetek tervezése és tervezése.

Az ad-hoc tesztelést általában olyan tesztelő végzi, aki jól ismeri a tesztelendő szoftvert azzal kapcsolatban, hogy mit csinál és hogyan működik.

Ez a tesztelés úgy történik, hogy véletlenszerűen, hibakitalálással teszteseteket hoz létre és hajt végre, anélkül, hogy követné a tesztelésre vonatkozó követelményeket.

Ez a tesztelés fontos része, hogy kiderítsük a szoftver azon lehetséges területeit, ahol hibák lehetnek.

Ez az oka annak, hogy néha majomtesztelésnek vagy véletlenszerű tesztelésnek is nevezik. Ezért fontos, hogy csak olyan tesztelők végezzék ezt a tesztelést, akik jól ismerik a szoftvert.

Az Ad-Hoc tesztelés előnye, hogy elég sok időt takarít meg, ami egyébként olyan dokumentumok létrehozására megy el, mint a tesztkövetelmények, tesztesetek tervezése, tervezése stb.

Azt is általában a már elvégzett strukturált tesztelés után végzik. Erre azért kerül sor, hogy olyan szokatlan hibákat találjanak a szoftverben, amelyeket az előzetesen megírt teszteseteket követve nem lehetett felfedezni.

Az ad hoc tesztelés típusai

1) Buddy tesztelés

Az ad hoc tesztelés ezen típusában a teszteket legalább két ember csapatmunkájával végzik. Ez a csapat általában legalább egy szoftvertesztelőből és egy szoftverfejlesztőből áll.

Ez a fajta tesztelésre egy modul egységtesztelésének elvégzése után kerül sor.

A két “haver” csapata együtt dolgozik az adott modulon, hogy érvényes teszteseteket hozzon létre.

Ez azért történik, hogy a tesztelő végül ne az érvénytelen tesztesetek által generált hibákat jelentse. Ez a fajta tesztelés az egység- és a rendszertesztelés kombinációjának is tekinthető.

2) Majomtesztelés

Az ebben a tesztelésben alkalmazott megközelítés véletlenszerűsége miatt nevezik “majomtesztelésnek”.

Itt a tesztelt szoftvert véletlenszerű bemenetekkel látják el, amelyeknek megfelelő kimeneteket figyelnek meg.

A kapott kimenetek alapján megállapítják a hibák, ellentmondások vagy rendszerösszeomlások esetleges előfordulását.

3) Páros tesztelés

Ez a tesztelés nagyban hasonlít a pajtás teszteléshez. Itt azonban csak a tesztelők egy párja dolgozik együtt a tesztelendő modulokon.

Megosztják egymással az ötleteiket, véleményüket és tudásukat ugyanazon a gépen a hibák és hibák azonosítása érdekében.

A tesztelőket tudásszintjük és szakértelmük szerint párosítják, hogy különböző betekintést nyerjenek egy-egy problémába.

Az adhoc tesztelés jellemzői

  • Ezt a tesztelést azután végzik, hogy a formális tesztelési technikákat már elvégezték a szoftveren. Ennek az az oka, hogy az ad-hoc teszteket azért végzik, hogy kiderítsék az alkalmazásban előforduló anomáliákat, amelyeket a tesztelés előtt nem lehet előre jelezni.
  • Ezt a tesztelést csak azok a tesztelők végezhetik, akik jól és alaposan ismerik az alkalmazás működését. Ennek oka, hogy hatékony “hibakitalálást” csak akkor lehet végezni, ha a tesztelő tudja, mit csinál az alkalmazás és hogyan működik.
  • Az ad-hoc tesztelési technika a legalkalmasabb a hibák és következetlenségek megtalálására, amelyek kritikus hézagokat eredményeznek egy alkalmazásban. Az ilyen hibákat általában nagyon nehéz feltárni.

  • Ez a tesztelés viszonylag kevesebb időt vesz igénybe, mint más tesztelési technikák. Ennek oka, hogy előzetes tervezés, tervezés és strukturálás nélkül történik.
  • Az ad-hoc tesztelés csak egyszer történik, mivel a talált hibákat újra kell tesztelni.

Példák az ad-hoc tesztekre

    Az alkalmazás megfelelő működésének tesztelése, ha a böngésző beállításai eltérőek. Például a különböző böngészőkben a JavaScript opció letiltásakor fellépő hibák azonosítása stb.

  • Az alkalmazás platformok közötti tesztelése. Lényeges annak ellenőrzése, hogy a kifejlesztett alkalmazás különböző operációs rendszereken vagy böngészőkben is gördülékenyen fut-e.
  • Az érvényes bemeneti tartományon kívül eső bemenetek megadása a rendszernek, annak ellenőrzése érdekében, hogy az alkalmazás által végrehajtott eredményes művelet megfelelő-e vagy sem.
  • Az alkalmazás URL-címének másolása és manipulálása, hogy más böngészőben fusson. Ez azért történik, hogy megbizonyosodjunk arról, hogy illetéktelen felhasználók nem tudnak illetéktelenül hozzáférni a rendszerhez.

  • Véletlenszerű lépések sorozatának végigjárása vagy véletlenszerű navigálás az alkalmazáson keresztül, hogy ellenőrizzük a szokatlan bemenetek egy bizonyos kombinációjának végigjárásával kapott eredményeket.

Mikor végezzenek ad-hoc tesztelést

Az ad-hoc tesztelésre általában akkor kerül sor, amikor nincs elég idő a kimerítő és alapos tesztelésre, amely magában foglalja a tesztelési követelménydokumentum, a tesztesetek és a tesztesettervek elkészítését.

Az ilyen típusú tesztelés elvégzésének tökéletes időpontja a formális tesztelési technikák befejezése után van.

Az ad-hoc tesztek azonban a szoftverfejlesztés közepén is elvégezhetők.

A szoftver teljes fejlesztése után, vagy akár néhány modul kifejlesztése után is elvégezhető.

A formális tesztelési módszerek során is elvégezhető.

Van néhány olyan helyzet, amikor azonban ezt a tesztelést nem szabad elvégezni. Ezért minden tesztelőnek tudnia kell, mikor kell elkerülni ezt a tesztelést.

Az alábbiakban néhány olyan körülményt ismertetünk, amikor nem szabad ad-hoc tesztelést végezni:

    Ad-hoc tesztelést nem szabad végezni, amikor béta tesztelés folyik. Ennek az az oka, hogy a béta-tesztelésben részt vesznek az ügyfelek, akik tesztelik a kifejlesztett szoftvert, hogy javaslatokat tegyenek a hozzáadandó új funkciókkal vagy a követelmények módosításával kapcsolatban.

  • Ezt a tesztelést szintén nem ajánlatos olyan tesztesetekben végezni, amelyekben már létező hibák vannak. A hibákat először megfelelően dokumentálni kell, mielőtt eltávolítjuk őket a rendszerből. Miután kijavították őket, a teszteseteket újra kell tesztelni, hogy biztosítsák a megfelelő működésüket.

Melyek az ad hoc tesztelés előnyei?

  • Az ad hoc tesztelés egyik előnye, hogy az alkalmazás véletlenszerű tesztelésével sok olyan hibát lehet találni, amelyek általában észrevétlenek maradnak, ha csak formális tesztelési módszereket alkalmazunk.
  • A tesztelők szabadon, az alkalmazásról alkotott intuíciójuknak és megértésüknek megfelelően vizsgálhatják az alkalmazást. Ezután menet közben végezhetik el a teszteket, ami segíti őket abban, hogy e folyamat során megtalálják a hibákat.
  • A tesztelők, valamint az alkalmazás fejlesztői könnyen tesztelhetik az alkalmazást, mivel nincs szükség tesztesetek megtervezésére és megtervezésére. Ez segít a fejlesztőknek abban, hogy könnyedén hatékonyabb és hibamentes kódokat generáljanak.
  • Ez a tesztelés segíthet az egyedi tesztesetek létrehozásában is, amelyek a hibák hatástalan felderítésére alkalmasak. Ezért az ilyen teszteseteket hozzá lehet adni a formális teszteléshez más tervezett tesztesetekkel együtt.
  • Az ad-hoc tesztelés a szoftverfejlesztés életciklusa során bármikor elvégezhető, mivel nem követ semmilyen formális folyamatot.
  • Ez más tesztelési technikákkal kombinálható és végrehajtható, hogy informatívabb és hatékonyabb eredmények szülessenek.

Melyek az adhoc tesztelés hátrányai?

    Miatt a tesztelési folyamat nem dokumentált és nem követnek konkrét teszteseteket, a tesztelő számára nagyon nehézzé válik a hiba regenerálása. Ennek oka, hogy a tesztelőnek emlékeznie kell a pontos lépésekre, amelyeket a hiba előidézéséhez követett, ami nem minden alkalommal lehetséges.

  • Néha a tesztelő által véletlenszerűen kidolgozott érvénytelen tesztesetek végrehajtása miatt érvénytelen hibákat jelentenek, ami a későbbi hibajavítási folyamatokban problémává válik.
  • Ha a tesztelők nem rendelkeznek előzetes ismeretekkel a tesztelt alkalmazás működéséről, akkor az ad-hoc tesztek elvégzése nem lesz képes sok hibát feltárni. Ennek az az oka, hogy a tesztelőknek a hibák kitalálásával kell dolgozniuk, és intuitív módon, a helyszínen kell teszteseteket létrehozniuk és végrehajtaniuk.
  • Az ad-hoc tesztelés nem nyújt biztosítékot arra, hogy a hibákat megtalálják. A teszteléshez szükséges proaktív hibakitalálás teljes mértékben a tesztelő készségétől és tudásától függ.
  • Mivel nincsenek előzetesen létrehozott és dokumentált tesztesetek, az erre a tesztelésre fordított idő és erőfeszítés mértéke bizonytalan marad. Néha akár egyetlen hiba megtalálása is rengeteg időt vehet igénybe.

Az ad hoc tesztelés elvégzésének legjobb gyakorlatai

Az ad hoc tesztelési technika hatékony elvégzéséhez fontos ismerni a leghatékonyabb és leghatékonyabb módszereket.

Ez azért van, mert ha a teszteket nem megfelelő módon végzik, akkor a tesztekre fordított erőfeszítés és idő kárba vész.

Ezért az ilyen típusú tesztelés elvégzéséhez ismerni kell a legjobb gyakorlatokat, amelyek segíthetnek a tesztelés átfogóbb megközelítésében:

1) Jó szoftverismeret

Győződjön meg arról, hogy az alkalmazás ad-hoc megközelítéssel történő tesztelésére kijelölt tesztelő jól ismeri az alkalmazást.

A tesztelőnek ismernie kell az alkalmazás összes funkcióját, hogy megkönnyítse a jobb “hibakitalálást” az alkalmazáson.

Mivel elegendő tudás áll a tesztelő tesztelési folyamatának hátterében, könnyebbé válik több hiba, hiba és következetlenség megtalálása.

2) Találja ki a hibahajlamos területeket

Ha a tesztelők, hogyan nem ismerik az alkalmazást, akkor a legjobb gyakorlat, hogy a tesztelési folyamatot úgy kezdjék, hogy az alkalmazásnak azt a részét keresik, ahol a legtöbb hiba található.

Az ilyen érzékeny területek kiválasztása az ad-hoc tesztek elvégzéséhez segíthet nekik abban, hogy könnyebben megtalálják a hibákat.

3) A tesztelési területek priorizálása

A tesztelést mindig jobb az alkalmazás azon területeiről kezdeni, amelyeket a végfelhasználók vagy az ügyfelek a leginkább használnak. Ez segít a fontos funkciók biztosításában és a hibák előzetes jelentésében.

4) Tervezze meg nagyjából a teszttervet

Noha az ad hoc tesztelés nem igényel előzetes tervezést vagy dokumentációt, nagyon hasznosnak és hatékonynak bizonyul, ha előzetesen elkészül egy durva terv.

A főbb mutatók és a tesztelést igénylő területek feljegyzése segíthet a tesztelőknek, hogy rövid idő alatt az alkalmazás maximális részét lefedjék.

5) Eszközök

Elkerülhetetlen a megfelelő típusú eszközök, például hibakeresők, feladatfigyelők és profilozók használata a tesztelés megkönnyítése érdekében.

Ez azért van, mert vannak olyan esetek, amikor bizonyos hibák és kivételek nem láthatók és nem észlelhetők a tesztelés során.

A megfelelő eszközök használatával azonban rövid idő alatt elkülöníthető a hiba.

Adhoc tesztelés vs. feltáró tesztelés

Adhoc tesztelés Exploratív tesztelés
A tesztelőknek világos elképzeléssel kell rendelkezniük az alkalmazás munkafolyamatáról A tesztelők megismerik a alkalmazásról menet közben
Többet a tesztelési folyamat tökéletesítéséről Ez egy tanulási módszer az alkalmazás megismeréséhez
A pozitív tesztelés egy formája A negatív rendszer egy formája
Nincs terv Egy charter alapú terv kerül alkalmazásra
Nincs javasolt időkorlát Idődobozos/karakteres vektor
A szoftvertesztelő mérnök által végrehajtható Ha a szakértő végzi
A fókusz az alkalmazási folyamaton van Az adatbeviteli területek lesznek az elsődlegesek
A tesztek bonyolultsága nem fogja nagyon zavarni ezt a folyamatot Kihívások

Kihívások

Vélemény, hozzászólás?

Az e-mail-címet nem tesszük közzé.