Szoftver tesztelés típusai
Szoftver tesztelése során a rendszer viselkedését vizsgáljuk. A szoftver futása során produkált kimenetet hasonlítjuk össze az elvárt működéssel ami a követelmény, specifikáció fázisban kerül meghatározásra .
A szoftvertesztelés megmutatja, hogy egy szoftverben vannak hibák, azt nem mutatja meg, hogy nincsenek hibák egy alkalmazásban. A tesztelés egy induktív bizonyítás része. Abból indulunk ki, hogy amennyiben az alkalmazás jól működik egy adott feladatra, akkor várhatóan hasonló adatokra is jól fog működni.
Azt lehet mondani, hogy az egyedi szoftverfejlesztésre szánt erőforrások 30-50%-át szokták szánni a szoftver tesztelésére. Az, hogy pontosan mennyi időt, pénzt érdemes rászánni egy bizonyos szoftver tesztelésére az attól függ, hogy milyen mértékű bizalomra van szükségünk a szoftver működésével kapcsolatban.
Mielőtt bemutatjuk az általunk alkalmazott szoftvertesztelési módszereket ismertetjük a verifikáció és validáció fogalmát.
Verifikáció és Validáció
Validáció
A validációs folyamat során azzal foglalkozunk, hogy jó terméket készítettünk-e el. A jó termék az pontosan azt az egyedi szoftver megoldást jelenti, ami megrendelőink minden követelményének megfelel.
A validáció célja a rendszerben lévő hibák feltárása. Arra keressük a választ, hogy a rendszer használható-e a kívánt környezetben vagy sem.
Verifikáció
A verifikáció során azzal foglalkozunk, hogy jó minőségű szoftvert készítettünk-e el. Ennek során azt vizsgáljuk, hogy a szoftver megfelel-e bizonyos előírásoknak például a szabványoknak.
Verifikáció és validáció a szoftver iránt bizalmi alapot teremt. V&V során megbizonyosodtunk arról, hogy a szoftver el tudja látni a feladatát, úgy ahogyan az a követelmény és a specifikációs dokumentumokban definiálásra került. A sikeres V&V folyamat nem azt jelenti, hogy a szoftver teljesen hibamentes, hanem azt, hogy az egyedi szoftver elég jól működik ahhoz, hogy ellássa feladatát.
Az, hogy milyen mértékű bizalomra van szükségünk azt az ellátott feladat típusa határozza meg. Másként állunk hozzá egy Ipar 4.0 környezetbe fejlesztett egyedi szoftver és egy egészségügyi alkalmazás fejlesztésének és tesztelésének. Ipar 4.0 környezetben egy szolgáltatás kimaradás megnövekedett állásidőt eredményezhet, míg az egészségügyben egy szolgáltatás leállás emberéletekbe kerülhet.
Hibakeresés
Verifikáció és validáció során hibákat(fault) keresünk a szoftverben. Ezt szokták hiányosság(fault driven) tesztelésnek nevezni. Ehhez kapcsolódóan definiálunk pár fogalmat.
Tévedés, félreértés (error): Emberi tévedést vagy mulasztást jelent. Ez a szoftverben keletkező hibához vezet. Ezt okozhatja hiányos kommunikáció, félreértés, fogalomzavar vagy egy követelmény nem kellően konkrét megfogalmazása.
Hiba(fault vagy bug): Szoftveres hiányosság, elégtelenség mely programhibához(failure) vezet. A szoftver egy bizonyos komponense rosszul van megírva egy tévedésből, félreértésből adódóan. A hiba kijavításához meg kell találnunk azt a tévedést vagy félreértést amiből gyökeredzik.
Programhiba(failure): Az szoftver képtelen ellátni a feladatát. Ezt jellemzően egy hiba(bug) okozza, amit a javítás előtt meg kell találnunk.
A szoftver tesztelésének különböző típusai
Egyedi szoftverfejlesztő cégként tisztában vagyunk a különböző szoftvertesztelési típusokkal, például a funkcionális teszteléssel, a nem funkcionális teszteléssel, az automatizálási teszteléssel, az agilis teszteléssel és azok altípusaival.
Minden tesztelési típusnak megvannak a maga jellemzői, előnyei és hátrányai is. Ebben a cikkben olyan szoftvertesztelési módokat fogunk tárgyalni, amelyeket projektjeink végrehajtásakor alkalmazni szoktunk.
Funkcionális tesztelés
Funkcionális tesztelésről beszélünk, amennyiben az egyedi szoftver funkcióinak tesztelésén van a hangsúly. Célunk annak kiderítése, hogy a fejlesztett funkciók pontosan azt a kimenetet adják amik a specifikációban szerepeltek. Funkcionális tesztek esetén ismert a bemeneti halmaz és a hozzájuk tartozó elvárt kimenet.
Nem-Funkcionális tesztelés (NFT)
A nem funkcionális tesztelés magában foglalja a nem funkcionális követelmények tesztelését, mint például a terhelés tesztelése, a stressz tesztelése, a biztonság vagy a helyreállás végzetes hiba esetén.
Az nem funkcionális tesztelés célja annak biztosítása, hogy a szoftver vagy az alkalmazás válaszideje megfelel-e az üzleti követelményekben foglaltaknak.
Használhatóság (usability) tesztelésről beszélünk, amennyiben a felhasználó szemszögéből vizsgáljuk az elkészült szoftvert. Ennek során arra vagyunk kíváncsiak, hogy mennyire kézenfekvő egy szoftver használata, elakadás esetén milyen könnyen boldogul a felhasználó a kezelési útmutató, kontext szenzitív help (súgó) használatával.
Usability tesztnél azt vizsgáljuk, hogy mennyire van összhangban a szoftver a felhasználói leírással, mennyire konzisztensek és mennyire ergonomikusan használhatóak az elkészült felületek.
Megbízhatósági (reliability) szempontból vizsgáljuk a szoftvert, amennyiben a felsorolt szempontok szerint vizsgáljuk az egyedi szoftverünket:
- Integritás: Azt analizáljuk, hogy a szoftver mennyire ellenálló a kritikus hibákkal(failure) szemben. Mennyire őrzi meg az elvárt működését hibára futás esetén.
- Strukturális: A forráskód alapján készülnek a tesztesetek. A tesztelőnek meg kell ismernie a forráskódot, amit meg kell értenie. A megértést miatt a magas képzettség elvárt.
- Általában a következő struktúrákat teszteljük
- Kódsorok,
- Elágazások,
- Metódusok,
- Osztályok,
- Funkciók és
- Modulok
- Általában a következő struktúrákat teszteljük
- Stressz teszt: A megszokottól eltérő kondíciók mellett vagy a specifikációban szereplő erőforrásokat még szűkebbre szabva teszteljük a szoftvert. Ezek az abnormális kondíciók érintik a memória-, processzor-, hálózat használatot. Stressz teszt során az alkalmazás válasz idejére vagyunk kíváncsiak, amik nem lehetnek egy bizonyos szintidőn kívül. Azt is vizsgálhatjuk, hogy egy alkalmazás mennyi kérést szolgál ki percenként és hogy ez megfelel-e a valós vagy akár rendkívüli, de várható helyzeteknek.
Szoftver tesztelési módszerek
Alfa Testing
Alfa tesztelés a legszélesebb körben alkalmazott szoftver tesztelési módszer. Ennek a tesztelésnek az a célja, hogy azonosítsa az összes lehetséges kérdést vagy hibát, mielőtt a szoftver piacra vagy felhasználók elé kerül.
Az alfa tesztelés a szoftverfejlesztési szakasz végén, de a béta tesztelés előtt történik. Ennek ellenére kisebb tervezési változtatások történhetnek egy ilyen teszt eredményeként.
Acceptance Testing (Elfogadási teszt)
Az ügyfél elfogadási tesztet hajt végre, és ellenőrzi, hogy a rendszer egésze az üzleti követelményeknek megfelel-e, vagy sem, és a végfelhasználó igényeinek megfelel-e. Az ügyfél csak akkor fogadja el a szoftvert, ha az összes szolgáltatás és funkció a elvárt módon működik.
Ez a tesztelés utolsó fázisa, amely után a szoftver gyártásba megy. Ezt hívják felhasználói elfogadás tesztelésnek (UAT) is.
Ad-hoc testing
A név arra utal, hogy ezt a tesztelést ad-hoc alapon, azaz a tesztesetre való hivatkozás nélkül, valamint az ilyen típusú vizsgálatokra vonatkozó terv vagy dokumentáció nélkül végzik. Felfedező tesztelésnek is szokták hívni.
Ennek a tesztelésnek az a célja, hogy megtalálja a hibákat és véletlenszerű funkciók végrehajtásával véletlenszerű bemenet mellett.
Az ad-hoc tesztelés a hibák felkutatásának informális módja, amelyet bárki elvégezhet aki a projektben részt vesz. Teszteset nélkül nehéz azonosítani a hibákat, de néha előfordulhat, hogy az ad-hoc tesztelés során talált hibákat a meglévő tesztesetek felhasználásával nem találnánk meg.
Accessibility Testing (Hozzáférhetőség tesztelés)
Az akadálymentességi teszt célja annak meghatározása, hogy a szoftver vagy az alkalmazás hozzáférhető-e a fogyatékkal élők számára, vagy sem.
Accessibility teszt esetén a fogyatékosság itt siketeket, színvakokat, értelmi fogyatékosokat, vakokat, időseket és más fogyatékossággal élő csoportokat jelent.
Beta Testing (Béta tesztelés)
A béta tesztelés a szoftver tesztelés hivatalos formája, amelyet az ügyfél végez. Ezt a valós környezetben hajtják végre, mielőtt a terméket piacra dobnák a tényleges felhasználók számára.
A béta tesztelés annak biztosítására szolgál, hogy ne legyenek nagyobb hibák a szoftverben vagy a termékben, és a végfelhasználói szempontból kielégítse az üzleti követelményeket. A béta tesztelés akkor sikeres, ha az ügyfél elfogadja a szoftvert.
Ezt a tesztelést általában korlátozott számban végfelhasználók vagy mások végzik. A tesztben részt vevő felhasználók megosztják a velünk az egyedi szoftverben talált hibákat és ezeket mi kijavítjuk, mielőtt a szoftver az összes felhasználóhoz eljut.
Ez az utolsó teszt, amelyet az alkalmazás kereskedelmi célú kiadása előtt végeznek.
Browser Compatibility Testing (Böngésző kompatibilitás tesztelés)
Ez a kompatibilitási teszt egyik altípusa és a tesztelő csoport végzi.
Webalkalmazásokra kerül végrehajtásra, és biztosítja, hogy a szoftver különböző böngészők és operációs rendszerek kobinációján fusson. Ez a típusú teszt azt ellenőrzi, hogy a webalkalmazás a specifikációban meghatározott böngészőkön és operációs rendszereken megfelelően fut és jelenik meg. A böngészőknél megadjuk a minimum verziószámot és azt, hogy milyen operációs rendszeren, milyen kijelzőfelbontáson vállaljuk a hibamentes futást és megjelenést.
Backward Compatibility Testing (Visszafelé kompatibilitás tesztelés)
Ez egy olyan típusú teszt, amely ellenőrzi, hogy az újonnan kifejlesztett vagy a frissített szoftver jól működik-e a szoftvert futtató környezet régebbi verziójával, vagy sem.
Bármely általunk frissített szoftvernek jól kell működnie a követelményben meghatározott futtatókörnyezet(operációs rendszer, böngésző) egy minimális verziószámával. Emellett az átadás után következő jótállás idejébe tartozó vagy követelményekben extraként tárgyalt időben érkező új verziókkal is kompatibilisnek kell lennie az általunk gyártott egyedi szoftvernek.
Black Box Testing (Fekete doboz tesztelés)
A belső rendszer tervezését nem veszik figyelembe az ilyen típusú vizsgálatok során. A tesztek a követelményeken és a funkcionalitáson alapulnak.
Ez egy szoftver tesztelési módszer, amely elemzi egy szoftver/alkalmazás funkcionalitását anélkül, hogy sokat tudna a tesztelt elem belső szerkezetéről / kialakításáról, és összehasonlítja a bemeneti értéket a kimeneti értékkel.
A fekete doboz tesztelés során a fő hangsúly a rendszer egészének funkcionalitására irányul.
A fekete doboz tesztelés lehet funkcionális és nem-funkcionális.
Branch Testing (Elágazás tesztelés)
Ez egy olyan fehér doboz tesztelés, amelyet a kód egy részének tesztelése során hajtanak végre. Az elágazás tesztelés során a kódot alaposan végig teszteljük és dokumentáljuk, a vezérlés összes ágát lefedve.
Comparison Testing (Összevetéses tesztelés)
A termék erősségeinek és gyengeségeinek összevető tesztjét végezzük amennyiben a szoftver egy korábbi verziójával vagy más hasonló termékkel hasonlítjuk össze.
Compatibility testing (Kompatibilitás tesztelés)
A kompatibilitás teszt egy szoftver tesztelési kategóriát jelent, amelyben ellenőrizzük a szoftver viselkedését és működését egy másik környezetben. Az eltérő környezet lehet egy új böngésző verzió, nemrég megjelent okostelefon, új operációs rendszer vagy egy új képernyő méret vagy képernyő orientáció.
Az kompatibilitási teszt biztosítja, hogy a szoftver más konfigurációban a követelményeknek megfelelően fusson. Az kompatibilitási tesztet a tesztelő csapat végzi.
Component Testing (Komponens tesztelés)
A fejlesztők végzik a unit teszt befejezése után. Az komponensek összeillesztésének tesztelése több funkció tesztelését jelenti az egységként kezelt már összeillesztett rendszeren. A komponens tesztelés célja annak azonosítása, hogy jelentkezik-e valamilyen hiba, miután összekapcsoltuk a rendszer komponenseit egymással.
End-to-end Testing (Végponttól végpontig tesztelés)
Az end-to-end tesztelés magában foglalja a teljeskörő alkalmazás környezet tesztelését egy olyan helyzetben, amely a valós felhasználást szimulálja.
Például az alkalmazás frontendjén elküldünk egy regisztrációs form-ot a hálózaton, ami a backend szerveren üzleti logikája szerint kerül feldolgozásra, majd az adatbázis szerveren új entitások létrehozásával zárul .
Equivalence Partitioning (Ekvivalencia felosztás szerinti tesztelés)
Ez egyfajta fekete doboz (black box) tesztelési technika. Ennek során particionáljuk egy funkció bemeneti értékkészletét úgy, hogy az egyes partíciókban minden egyes elemre ugyanazt a kimenetet adja a funkció. A teszt célja a redundáns tesztesetek eltávolítása.
Tegyük fel, hogy egy funkció bemeneti értékkészlete 10-től -10-ig tart. Ekvivalencia particionálás szerint egy kalap alá lehet venni a negatív, nulla és a pozitív számokat, ekkor az ekvivalencia articióink: -10-től -1-ig, 0 és végül 1-től 10-ig.
Exploratory Testing (Feltáró vagy felderítő tesztelés)
Ennek során a tesztelő kombinálja korábban szerzett tapasztalatait a módszeres teszteléssel. Ez akkor lehet különösen hasznos, ha a specifikáció elnagyolt vagy hiányos esetleg nagyon rövid idő áll rendelkezésre a fejlesztésre és a tesztelésre.
Feltáró teszteléssel lehetőségünk van a korlátozott tesztelési időt jobban kihasználni azáltal, hogy az alkalmazásban lévő legfontosabb funkciók végrehajtásával tesztelünk. Az alkalmazás által prezentált funkciók végrehajtásával haladunk rekurzív módon. Egy lépésben csak egy funkciót hajtunk végre majd pedig dokumentálunk. Ha egy lépéssorozat végére értünk akkor visszalépünk egyet és a felfedezett, de ki nem próbált funkciók közül hajtunk végre egy újabbat.
GUI Testing (Felhasználói felület tesztelés)
A GUI tesztelésének célja a GUI összevetése az üzleti követelményekkel. Az alkalmazás felületének várható kimenetét a Detailed Design (Részletes tervek) dokumentumban van definiálva. A detailed design dokumentumban egy drótvázzal van ábrázolva minden egyes screen, mely a végleges GUI-t modellezi. Minden drótváz-képernyő mellett szerepel az elvárt kimenet, mely a képernyőn megjelenő elemek szerepére, elvégezhető funkciókra kitér. A funkciók bemeneti halmaza és az elvárt kimenet is definiálva van ilyenkor.
Továbbá a GUI tesztelés tartalmazza a képernyőn megjelenő gombok és beviteli mezők méretét, az összes szöveg, táblázat és tartalom igazítását.
Gorilla Testing (Gorilla tesztelés)
A gorilla tesztelés során az alkalmazás egy modulját vagy funkcióját teszteljük nagyon részletesen. Gyakran a tesztelő és az alkalmazást fejlesztő mérnök is részt vesz benne.
A tesztelés célja az alkalmazás robusztus működésének ellenőrzése.
Happy Path Testing (Pozitív folyam tesztelés)
A happy path tesztelés során csak az elvárt működés szerint megfelelő pozitív bemenetekkel látjuk el az alkalmazást. Nem adunk meg az alkalmazás számára nem várt bemenetet és nem foglalkozunk hibák keresésével.
A lényeg csak azokon az érvényes és bemeneteken van, amelyeken keresztül az alkalmazás produkálja a várt kimenetet.
Integration Testing (Integráció tesztelés)
Az Incremental Integration szerinti tesztelés során folyamatosan teszteljük az alkalmazász amint új funkció vagy modul fejlesztése lezárul.
Az top-down inkrementális tesztelés során a meglévő és a még nem létező, de csonkokkal helyettesített modulok közti kölcsönhatásokat vizsgáljuk. A csokokkal alacsonyabb szintű modulokat helyettesítünk.
Bottom-up inkrementális tesztelés során a magasabb szintű még el nem készült hívó modulokat driverrel (meghajtó) helyettesítjük. Ezt szoktuk inkrementális integrációs tesztelésnek is nevezni.
Minden modul meghatározó szerepet játszik a projekt / termék struktúrájában. Az inkrementális integrációs teszt előnye, hogy a hibákat korán találják, amikor viszonylag könnyű felismerni azok kiváltó okát. Hátránya, hogy időigényes lehet, mivel a tesztek elvégzéséhez csonkokat és meghajtókat kell fejleszteni.
Ez a fajta teszt különösen fontos az kliens-szerver és az elosztott rendszerek esetén.
Load testing (Terhelés tesztelés)
Ez egyfajta nem funkcionális tesztelés. A terhelés tesztelés célja annak ellenőrzése, hogy egy rendszer mekkora terhelést vagy maximális terhelést képes kezelni a teljesítmény romlása nélkül.
A terheléses teszteléssel megtudhatjuk, hogy egy rendszer terhelés mellett milyen áteresztő képesség karakterisztikával rendelkezik rendelkezik funkciónként. Ebből megtudhatjuk, hogy mi a terhelésnek azon mértéke ahol a rendszer funkciói degradálódnak.
Monkey testing (Majom tesztelés)
Ezt a tesztelési technikát egy olyan felhasználónak kell végrehajtania aki semmilyen szintű ismerettel nem rendelkezik az alkalmazás funkcionalitását illetően. Ezek alapján teljesen véletlenszerű értékeket adunk meg az alkalmazás bemeneti felületein.
A majom tesztelés célja, hogy véletlenszerű beviteli értékek megadásával ellenőrizze, hogy egy alkalmazás vagy rendszer összeomlik-e. A majom tesztet véletlenszerűen hajtják végre, és nem írnak le teszteseteket, és nem is szükséges.
A majom tesztelés nagyon hasonló az ad-hoc teszteléshez, de míg itt nincs ismeretünk az alkalmazás funkcionalitását illetően, úgy az ad-hoc teszt esetén a tesztelő a program ismereteivel teszteli a szoftvert.
Mutation Testing (Mutációs Tesztelés)
Egyfajta fehér-doboz teszt. Ennek során azt ellenőrizzük, hogy a program kódjának átírásával detektálódik-e a hiba a rendszert lefedő tesztesetek körében.
A program forráskódjában bekövetkezett változás nagyon minimális, így nem érinti az egész alkalmazást, csak az érintett modulokat fedő teszteseteknek kell azonosítaniuk a rendszer hibáit.
Negative testing (Negatív tesztelés)
A happy path tesztelés ellentéte. Ennek során a tesztelő olyan hozzáállással áll neki tesztelni az alkalmazást, hogy minél több hibát találjon a rendszerben.
Negatív tesztelési technikát hibás, érvénytelen adatok vagy nem megfelelő bevitel felhasználásával hajtanak végre.
Igazolja, a rendszer megfelelő viselkedését, amennyiben az alkalmazás hibát dob, a nem megfelelő bemenetre felhívja a felhasználó figyelmét majd folytatja a működését.
Performance Testing (Teljesítmény tesztelés)
A teljesítménytesztet abból a célból alkalmazzák, hogy kiderüljön egy rendszer bírja-e a vele szemben támasztott teljesítménybeli követelményeket. Ebből megtudhatjuk egy rendszer korlátait, mely mindig arra a környezetre értelmezett amin épp fut. Megtujatjuk, hogy másodpercenként maximum hány kérést tud kiszolgálni egy konkrét erőforrás hívás során. Gyakran stressztesztként vagy terheléses tesztként hivatkoznak rá.
Recovery Testing (Felépülés teszt)
Recovery teszt esetén azt vizsgáljuk, hogy az alkalmazás vagy a rendszer egy végzetes hiba után hogyan áll helyre.
Egy recovery teszt során azt vizsgáljuk, hogy bizonyos hibákra visszaáll-e az alkalmazás működése amikor egy bizonyos végzetes hiba megszűnik. Például akkor sikeres egy recovery teszt áramkimaradásra, amennyiben egy áramszünet után a tápellátás visszatérésével együtt a rendszer is sikeresen elindul és feladatát hibamentesen ellátja.
Risk-Based Testing ( Kockázat Alapú tesztelés)
A kockázatalapú teszt esetén kockázat szerint rangsoroljuk a lefejlesztett funkciókat. Ennek során az üzleti követelmények szempontjából kritikus funkcionalitású funkciókat tesztelünk először vagy azt, ahol a legnagyobb esélye van a programhiba előfordulásának.
Az a funkciók közti prioritás meghatározása az üzleti követelményeken alapul, ha minden funkcióra meghatározzuk a prioritást, akkor először a magas prioritás, majd közepes, majd alacsony prioritású funkciókra hajtjuk végre a teszteket. Sőt, az is előfordul, hogy az alacsony kockázatú funkciókat nem is kerülnek tesztelésre.
A kockázatalapú tesztet akkor hajtják végre, ha nincs elegendő idő a teljes szoftver tesztelésére, és a szoftvert késedelem nélkül kell időben leszállítani.
Security Testing (Biztonsági tesztelés)
Ezt a fajta tesztet egy speciális csapat végzi akiknek az a feladatuk, hogy behatoljanak a rendszerbe vagy alkalmazásba és olyan információkat nyerjenek ki belőle vagy olyan műveleteket hajtsanak végre amihez nincs felhatalmazásuk.
Static Testing (Statikus tesztelés)
Statikus tesztelés során a dokumentáció kerül tesztelésre éppen ezért kód nem kerül végrehajtásra. Statikus tesztelés során összemérjük a dokumentációt a kóddal, felülvizsgáljuk az elkészült kódot. Végigjárjuk a dokumentációt és a benne szereplő követelmény pontokat összevetjük az implementáció megfelelő funkciójával.
A statikus tesztelés tesztesetekre, teszt tervre (test plan), design dokumentumra is alkalmazható. A tesztelő csoport által végrehajtott statikus tesztelés szükségszerű, mivel az ilyen típusú tesztelés során feltárt hibák a projekt szempontjából költséghatékonyak.
Stress Testing (Stressz tesztelés)
Stressz tesztelés során a rendszert a specifikációkon felül teszteljük azért, hogy megtudjuk mikor és hogyan szenved el kritikus hibát.
A rendszert nagy terhelés alá helyezzük, például a megszokott kiszolgálandó kérések tízszeresét vagy százszorosát eresztjük rá. Komplex adatbázis lekérdezéseket futtathatunk folyamatosan és párhuzamosan vagy megnövekedett memórát, tárhelyet igénylő műveleteket hajthatunk végre.
System Testing (Rendszer tesztelés)
A teljes rendszert teszteljük a követelményeknek megfelelően, ez egyfajta feket doboz tesztnek fele meg. A teljes, modulokból összerakott rendszert teszteljük ennek során.
Unit Testing (Unit tesztelés)
Egyetlen egy egyedülálló modult vagy komponens tesztelését érjük a unit teszt alatt. Tipikusan a programozó feladata a unit tesztelés, mivel a program belső tervezésének és kódjának részletes ismeretét igényli.
Usability Testing (Használhatósági tesztelés)
Az alkalmazás vagy tervek felhasználóbarátságát teszteljük a használhatósági teszt során. Az alkalmazás használatának folyamata áll a tesztelés középpontjában, azt vizsgáljuk, hogy egy új felhasználó könnyen megértheti-e az alkalmazást, vagy sem. A segédlet (vagy súgó) megfelelően dokumentáltságát is vizsgáljuk, ugyanis amennyiben a felhasználó bárhol elakad ennek segítenie kell a továbbjutásban. Alapvetően a rendszer navigációját ellenőrzik ennek a típusú tesztneka végrehajtásakor.
Vulnerability Testing (Kiszolgáltatottság, sérülékenység tesztelés)
Azt a tesztet nevezzük sérülékenység tesztelésnek melynek során a szoftver, hardver, hálózat gyengeségeit azonosítjuk. Amennyiben egy rendszer rendelkezik valamelyik alrendszerében bizonyos sérülékenységgel, úgy egy hacker, rosszindulatú program átveheti felette az irányítást vagy hozzáférhet a benne tárolt érzékeny adatokhoz.
Ezért mielőtt éles környezetbe kerül a rendszer ellenőrizni kell, hogy ezek az alrendszerek átesnek-e biztonsági-rés teszten. Ez a tesztelési folyamt megtalálhatja a információbiztonság szempontból kritikus és egyéb hibáit.
White Box Testing (Fehér doboz tesztelés)
A fehér doboz teszt során úgy állunk neki a platform, alkalmazás tesztelésének, hogy minden ismeret rendelkezésre áll annak belső működésével kapcsolatban. Ismert a kód, ismert a dokumentáció.
