Karbantartási teszt

Karbantartási tesztet a már működő rendszer módosítása vagy környezetének változása válthat ki. Például hibajavítás, új funkció, frissített külső szolgáltatás, operációs rendszer vagy böngésző verziója, adatátvitel, illetve egy funkció megszüntetése. A vizsgálat célja, hogy a változás megfelel az új elvárásnak, és a megőrzendő régi működés is helyes marad.

Nem minden változás azonos kockázatú. Egy szövegjavítás kevesebb kapcsolódó működést érinthet, mint a jogosultsági szabály vagy a közös adatmodell módosítása. Még kis változtatásnál is érdemes megnézni, a módosított részt hol használják. A korábbi teszteredmények fontos kiindulópontok, de az új változatot és környezetet külön kell ellenőrizni.

A hatáselemzés a módosítás várható és lehetséges következményeit térképezi fel. A férőhelyszámítás javítása érintheti a foglalás létrehozását, a várólistát, az értesítést, a kimutatásokat és a lemondást. Az érintett követelményeket, hívásokat, adatmezőket és korábbi hibákat összevetve kiválaszthatók a szükséges tesztek. Ez nem bizonyosságot ad, hanem megalapozott tesztelési területet.

A vizsgálat mélységét a változás terjedelme és a hiba lehetséges következménye befolyásolja. Központi jogosultsági módosításnál szélesebb regresszió indokolt lehet, mint egy elszigetelt megjelenítési javításnál. Dokumentáld, milyen függőségeket néztél meg, milyen teszteket futtatsz, és mi marad kívül a vizsgálaton. Ha a hatás nem ismert, előbb a kapcsolatokat kell feltárni.

Hibajavítás után először reprodukáld az eredeti helyzetet: megszűnt-e az eltérés? Ez a megerősítő teszt. Ezután válassz regressziós eseteket a közeli és függő részekhez: működik-e még a normál foglalás, a lemondás és a várólistáról előrelépés? Új funkció esetén az új szabályt célzó tesztek mellett ugyanígy szükség lehet régi funkciók ismételt vizsgálatára.

Az automatizált regressziós készlet segít gyorsan újrafuttatni a gyakori ellenőrzéseket, de frissíteni kell, ha az elvárás jogosan változott. A régi teszt mechanikus futtatása félrevezető lehet, ha már elavult szabályt kér számon. A tesztelési eredmény végén mindig jelezd a verziót és a fennmaradó, nem vizsgált kockázatot.

Tegyük fel, hogy a rendszer frissíti a diák jogosultsági szabályát: csak aktív jogviszonnyal lehet jelentkezni. Először pontosítsd az új szabályt és a hatálybalépést. Utána keresd meg az érintett felületeket és szolgáltatásokat: jelentkezés, várólista, már létező foglalások, adminisztrátori módosítás. Készíts új teszteket aktív, inaktív és hiányzó jogviszonnyal, majd nézd meg a korábban működő jogosultsági eseteket is.

Az ellenőrzést ne szűkítsd a felület zöld üzenetére. Vizsgáld meg, mit tárol a rendszer és mit lát a diák később; az adminisztrátor mit lát ugyanarról az esetről; mi történik, ha az állapot két lépés között változik. Ha egy kapcsolódó külső rendszer adja a jogviszonyt, az adatátadás és a szolgáltatás elérhetősége is része lehet a hatáselemzésnek. A leírt tesztkör akkor teljes, ha a kiválasztás és a kihagyott részek indoka is világos.

Egy karbantartási kör kezdődhet tervezett új funkcióval vagy javítással, de egy külső változás is elindíthatja: például a böngésző, adatbázis vagy más szolgáltatás frissítése. Adatmigrációkor nem biztos, hogy az alkalmazás szabálya változik, mégis ellenőrizni kell a meglévő rekordok elérhetőségét és jelentését. Funkció kivezetésekor azt vizsgáljuk, nem maradt-e váratlan függőség a megszűnő részre.

Más kérdés, hogy egy hiba kijavítását kell-e igazolni, vagy egy új szabály helyességét. Előbbinél az eredeti hibajegy megerősítő esete adott kiindulópont; utóbbinál új teszteseteket írunk. Mindkettőnél felmerülhet regresszió a függő részekben. A módosítás indoka, az érintett verzió és a környezet egyértelmű rögzítése nélkül a tesztjelentés nehezen értelmezhető.

A teljes tesztkészlet minden változás utáni futtatása néha túl lassú; egy egészen szűk ellenőrzés viszont elmulaszthat fontos mellékhatást. A hatáselemzés középutat ad: a módosított szabályon túl a hívókat, a közös adatmezőket és a felhasználói folyamatokat tekinti át. A magas kockázatú, széles körben használt részhez nagyobb regressziós kör indokolható.

A kiválasztott eseteket időnként felül kell vizsgálni. Ha egy régi teszt a megváltoztatott szabály miatt vár jogosan más eredményt, nem szabad pusztán zöldre módosítani anélkül, hogy az új elvárást ellenőriznénk. A változás hatásának elemzése a tesztkészletre is kiterjed: melyik eset marad, melyik frissül, és milyen új próba hiányzik.