Tesztelési szintek rendszerezése

A komponensteszt egy elkülöníthető rész működésére kérdez rá: jól számítja-e a függvény a várólista sorrendjét? Az integrációs teszt a részek kapcsolatára: átadja-e a jelentkezési modul a megfelelő adatot az értesítőnek? A rendszerteszt az egész portálra: helyes-e a jelentkezés teljes folyamata? Az elfogadási teszt az átvevő szempontjaira: a portál megfelel-e a napi ügyintézésnek és a bevezetési feltételeknek?

A szintet nem a teszt végrehajtójának neve vagy a használt eszköz határozza meg. Egy fejlesztő is végezhet rendszertesztet, és egy tesztelő is tervezhet komponenstesztet. Ugyanaz az adat különböző szinten más célt szolgál: a 0 szabad hely a sorrendező függvénynél bemeneti határ, a teljes felületen pedig felhasználói üzenetet és várólista-állapotot is érint.

A komponensteszt alapja lehet a rész részletes terve vagy a funkció szerződése; eltérés lehet hibás kerekítés. Az integrációs teszt alapja az API vagy adatkapcsolat leírása; eltérés lehet rossz mező vagy hibás sorrend. A rendszerteszt alapja a rendszerkövetelmény; eltérés lehet a teljes folyamat megszakadása. Az elfogadás alapja az üzleti és felhasználói igény; eltérés lehet, hogy egy szükséges adminisztrációs művelet nem hajtható végre.

Ezek a határok nem tökéletesen élesek. Egy teljes rendszerteszt is találhat integrációs eredetű hibát, de a teszt célja ettől még a teljes rendszer vizsgálata. A szint megnevezéséhez ezért a teszt szándékát, tárgyát és elvárt bizonyítékát nézd, ne csak a végül megtalált hiba helyét.

A tesztelési szint a vizsgálat szervezett fókusza. A teszttípus másik nézőpont: például a működési szabály helyessége, a teljesítmény vagy a változás utáni regresszió. Funkcionális ellenőrzést végezhetünk komponens- vagy rendszerszinten is. A teszttípusokat a következő órán részletezzük; a két fogalmat nem szabad egyetlen felsorolásba keverni.

A klasszikus V-ábra azt segít megérteni, hogyan épülnek egymásra az ellenőrzések. Agilis vagy iteratív munkában a tesztszintek egy új rész elkészültekor időben átfedhetnek: az új függvény komponenstesztje és a korábbi folyamat regressziós rendszertesztje ugyanabban a munkaszakaszban futhat. A sorrend változhat, de a különböző kérdések ettől még fontosak maradnak.

A betelt kurzus példáját a számoló függvényen gyorsan és pontosan ellenőrizhetjük, de ez nem szól a tárolásról. Integrációban vizsgáljuk az adat átadását, a teljes rendszerben a felhasználónak megjelenő választ, elfogadáskor pedig azt, hogy az ügyintéző a keletkező várólistával dolgozni tud. Ez négy különböző bizonyíték ugyanahhoz a kockázathoz.

Az eseteket nem kell szó szerint minden szinten megismételni: a teszt részletessége és elvárása igazodik a célhoz. A komponensnél elég lehet a pontos visszatérési érték, a rendszerben a tartós mentés és a felhasználói visszajelzés is szükséges. A duplikáció helyett azt nézzük, melyik fontos kérdés maradna megválaszolatlanul.

Rendezd az állításokat: „a függvény 20-ból 19 foglalásra 1 szabad helyet ad”; „a jelentkezési API a foglalást menti”; „a diák az egész folyamat után látja a foglalását”; „az ügyintéző képes előléptetni a várólistás diákot”. Ha a célra figyelsz, sorban a négy tanult szintet kapod. A megfogalmazás nem a vizsgált programnyelvtől vagy eszköztől függ.

Most nevezd meg mindegyikhez az elvárás forrását: komponensszabály, interfészleírás, rendszerkövetelmény vagy felhasználói igény. Ez segít észrevenni, ha a tesztet nincs mihez hasonlítani. Ilyenkor előbb kérdezni és pontosítani kell; egy önkényes elvárt érték hamis hibát vagy hamis sikert adhat.