Statikus tesztelési technikák

Statikus teszteléskor a munkaterméket nem futtatjuk. A követelmény, terv, forráskód vagy teszteset tartalmát vizsgáljuk meg, és eltéréseket, ellentmondásokat, hiányokat vagy fejlesztendő részeket keresünk. Az egyik módszer a felülvizsgálat, amelyben emberek olvassák és értékelik a munkaterméket; a másik a statikus elemzés, amelyben eszköz vizsgálja például a kód vagy modell egyes tulajdonságait futtatás nélkül.

Egy online vizsgarendszer leírásában ez áll: „A dolgozatot a határidő után nem lehet beadni”, máshol pedig „A késedelmes beadást a rendszer elfogadja, és megjelöli”. Már a dokumentum olvasásakor látszik az ellentmondás. Ezt a kész alkalmazás tesztelése előtt tisztázni lehet. A felülvizsgálat nem csak kész szövegre vonatkozhat: a követelmény finomodása közben adott korai visszajelzés is segíthet.

A vizsgálható munkatermékek köre tág: üzleti igény, felhasználói történet, elfogadási feltétel, rendszerterv, folyamatábra, adatmodell, programkód, tesztterv, teszteset, használati útmutató vagy akár szerződéses leírás is lehet. A kérdés mindig az, hogy van-e értelmezhető elvárás, amelyhez a munkaterméket összevetjük. A követelmény egyértelműségét és teljességét, a kód következetességét, a teszteset végrehajthatóságát más-más szemponttal ellenőrizzük.

Ha a kurzusjelentkezéshez készült tesztesetben csak „próbáld ki a jelentkezést” szerepel, hiányzik a kiinduló kurzusállapot, a szerepkör és a helyes eredmény. Az ilyen hiány is statikusan észrevehető. A korán kijavított hiba megakadályozhatja, hogy a félreértés továbbkerüljön a tervbe, a kódba, a tesztadatba és végül a felhasználói működésbe.

Felülvizsgálatnál a résztvevők a szöveg vagy terv jelentését is meg tudják kérdőjelezni. Például a „gyors keresés” nem mérhető; egy ügyintéző pedig azt is jelezheti, hogy a leírásból hiányzik a várólistás jelentkezés kezelése. A felülvizsgálat lehet informális vagy előre szervezett; a részletes folyamatot a 20. órában tanuljuk. A visszajelzést lehetőleg tárgyszerűen, a munkatermék konkrét helyéhez kötve adjuk.

A statikus elemző eszköz például jelölhet nem használt változót, gyanús kódszerkezetet vagy meghatározott szabály megsértését. Az eszköz által jelzett figyelmeztetés nem feltétlenül valódi programhiba; embernek kell értékelnie a kontextust. Fordítva is igaz: az eszköz nem tudja bizonyítani, hogy a leírt üzleti cél valóban helyes, és nem lát meg minden hiányzó felhasználói igényt.

Dinamikus tesztelésben a futó rendszert adott bemenettel és környezetben használjuk, majd a tényleges viselkedést összevetjük az elvárttal. Statikus vizsgálatban a munkatermékben lévő problémát találhatjuk meg a futás előtt. Egy kétértelmű követelményt felülvizsgálattal tisztázunk; egy jelentkezés kétszeri beküldésekor létrejövő dupla foglalást futó rendszerben vizsgálunk. A két tevékenység együtt erősebb bizonyítékot ad.

A statikus vizsgálat észlelhet közvetlenül egy hibás megfogalmazást vagy kódrészletet, amely dinamikus próba során csak bizonyos feltételekkel okozna megfigyelhető meghibásodást. Ugyanakkor a valós teljesítményt, időzítést vagy több szereplő egyidejű működését általában futtatás közben tudjuk megfigyelni. Az egyik sikeréből nem következik a másik fölöslegessége.

Ha a dolgozat beadási szabályában a „határidő után nem fogadunk el munkát” mellett mégis „késedelmes feltöltés megjelölése” szerepel, a fejlesztő nem tud egyértelmű döntést hozni. A tesztelő kérdése még a terv elkészítése előtt tisztázhatja a szabályt. Így nem kell később az űrlapot, az adatbázist, az e-mailt és az addig írt teszteseteket is átírni. Ez lehetőség a ráfordítás csökkentésére, nem minden helyzetben előre garantált összeg.

A korai felülvizsgálat javítja a közös megértést is. Az üzleti képviselő megerősítheti, milyen kivétel elfogadható; a tesztelő konkrét határhelyzetet írhat; a fejlesztő jelezheti, milyen állapot hiányzik a leírásból. A termék későbbi működését ettől még dinamikusan ellenőrizni kell: a tiszta követelmény nem bizonyítja a kész kód helyességét.

Keresd a kétértelmű szavakat: gyors, megfelelő, egyszerű, biztonságos. Ellenőrizd a szerepköröket, a hiányzó vagy hibás adatokat, a határértékeket, az időzónát és a hibás művelet utáni állapotot. A dokumentum különböző pontjait is hasonlítsd össze, mert az ellentmondás gyakran nem egy mondaton belül van. Az észrevételt pontos helyhez és visszakérdezéshez kösd.

A statikus vizsgálat eredménye lehet hiba, kérdés vagy javaslat is. Ne írj bizonyított meghibásodásról, ha a rendszer még nem futott, és ne keverd össze a kétértelmű leírást azzal, hogy a program biztosan hibás. Ha a szabályt javítják, az új követelményből készülő tesztesetet is nézd át: van-e egyértelmű elvárt eredménye?