A probléma a regressziós teszteléssel

Az automatizált UI tesztek, mint regressziós tesztek, nem muködnek túl jól a gyakorlatban. Ezek a tesztek drágák, és folyamatosan magas terhet rónak a projektre a karbantartási erofeszítések miatt – annyira, hogy vannak, akik kiszámítják ennek a beruházás megtérülési költségét, és ez alapján csökkentik az automatizált regressziós tesztjeiket. Így a tesztelésük hiányossá válik, ami félrevezeto és megbízhatatlan teszt eredményekhez vezet.

Ez az oka a híres tesztpiramisnak. És mindez csupán azért, mert félreértjük a regressziós tesztelést és rosszul használjuk azt!

Mindenki a folyamatos szállításról és korai tesztelésről beszél. De van egy nagy probléma: Sokkal több tesztautomatizálásra lenne szükség, mint ami a legtöbb projektre jellemző. Nem mindenki engedheti meg magának, hogy olykor néhány ezer felhasználójánál hibásan működjön az alkalmazása. Ezért, mielőtt a folyamatos vagy rendszeres szállításról álmodunk, el kell jutni az automata teszteléshez. Ehhez más megközelítésekre is szükség lehet, mint amit jelenleg használunk.

Valószínűleg ismernek gyakran használt UI regressziós teszt automatizáló eszközöket.

Nem számít, hogy ezek nyílt forráskódú eszközök vagy kereskedelmi alternatívák – mindegyik ugyanolyan alapelveket követ. A teszt alapvetően maga a program, amely irányítja a tesztelni kívánt szoftvert a felhasználói bemenetek szimulálásával és az eredmények ellenőrzésével. Ha van valami, amit nem ellenőriz, ott hibák csúszhatnak át. Viszont minden ellenőrzést manuálisan kell létrehozni és karbantartani, ami sok erőfeszítést jelent.

Ha veszünk például egy ötven beviteli mezővel rendelkező képernyőt – amely könnyen megtörténhet, például egy táblázatban – akkor ötven ellenőrzést kell meghatározni. Tíz teszt esetén ez ötszáz ellenőrzést eredményez. Nem csoda, hogy csak a legszükségesebb ellenőrzéseket hajtják végre a hagyományos vizsgálatok során, ami azt jelenti, hogy a tesztek nem teljesek.

Természetesen a bennünk élő fejlesztő rögtön rengeteg jó ötlettel rendelkezik arról, hogyan lehet összevonni és egyszerűsíteni. Sok ötletet számos eszközzel oldhatunk meg. Ez a megközelítés csak a mögöttes probléma mértékét csökkenti de nem oldja meg azt.

Egy másik gyakori probléma az, hogy üzleti ismeretekre van szüksége a teszt meghatározásához, de egy programozónak (vagy legalább egy képzett tesztelőnek) le kell kódolnia vagy “script” -elnie azt. Számos eszköz hosszú utat tett meg a folyamat egyszerűsítéséhez, és gyakran már napok alatt meg lehet tanulni ezek script nyelvét, ha van érzékünk hozzá, de ez még mindig egy további akadály.

A regressziós tesztek nem funkcionális tesztek

A funkcionális teszt célja és haszna, hogy feltárja a funkcionális hibákat a kódban. A teszt elvégzése után meglehetősen biztosak lehetünk abban, hogy a tesztelt funkciók helyesen lettek implementálva. A funkcionális tesztek kötelezőek, ha egy funkciót hozzáadtak vagy megváltoztattak. De vajon a funkcionális tesztek jó regressziós tesztek is?

A regressziós tesztnek más célja van, mint a funkcionális teszteknek. A regressziós teszt azután teszteli a szoftvereket, miután már kézzel tesztelték, jóváhagyták, és valószínűleg telepítve lett és a vevő már használatba vette – tulajdonképpen, ez már egy működő szoftver. Ha ez a szoftver még továbbra is tartalmaz évek óta észrevétlenül működő funkcionális hibákat, akkor nem a regressziós teszt feladata megtalálni azokat. Igen, ezt jól olvastad: a regressziós teszt célja nem az, hogy hibát találjon.

Ha a kód hibát tartalmaz, de a szoftvert már három éve használja az ügyfél, akkor sokszor ezeket a hibákat nem szabad kijavítani. Bizonyos esetekben a hibákat vissza kellett volna vezetni, miután javultak, anélkül, hogy először megkérdeznék az ügyfelet.

De ha a regressziós teszt célja nem a hibák megtalálása, akkor mi a feladata? A regressziós teszt célja a funkcionális konzisztencia. A regressziós teszt biztosítja, hogy a szoftverváltás után a változatlan részek ugyanúgy működnek, mint korábban – függetlenül attól, hogy ez elvben funkcionálisan helyes-e.

A regressziós tesztek típusai, amire szükségünk van

Ahogy a mondás tartja: “Ha egy kalapács az egyetlen eszközöd, akkor minden szögnek tűnik.” Az a tény, hogy a funkcionális teszteket regressziós tesztekként használjuk, kizárólag annak a ténynek köszönhető, hogy nincs megfelelő eszközünk ahhoz, amire valójában szükségünk lenne: egy konzisztencia ellenőrzés.

A funkcionális tesztek “rögzítik” az alkalmazás viselkedését. Ez jó, ha az alkalmazás viselkedése nem változhat. De a valóságban az alkalmazás viselkedésének állandóan változnia kell. Ez az a pont, amikor ezek a “fix” tesztek segítségből akadállyá válnak.

Ahhoz, hogy egy funkcionális regresszió felismerésre kerüljön egy változás után, nincs szükségünk manuálisan meghatározott funkcionális ellenőrzésekre. Teljesen elegendő a rendszer viselkedésében bekövetkezett változások felismerése, hasonlóan a verzió kezelő rendszerhez. Az aktuális állapotot helyesnek venni vagy legalábbis adottnak, és ezen állapot alapján határozni meg a teszteket nem számít új látásmódnak. Michael C. Feathers leírja ezt a megközelítést a „Working Effectively with Legacy Code” című könyvében és ezt “jellemzési tesztnek” nevezi.

Azonban a “változások felismerése” nem elegendő. Ami a verziókezelő rendszert annyira eredményessé teszi, az az egyes apró változások folyamatos figyelmen kívül hagyásának esélye (elfedve őket), vagy hogy képes egyszerűen követni ezeket a változásokat, és hatékonyan frissíteni a kapcsolódó teszteket. Pontosan ez az, amire nekünk szükségünk van a regressziós tesztrendszerünkhöz is.

Az egyik utolsó projektemben valami hasonlót készítettünk magunknak. Létrehoztunk egy webrobotot, amely átnézte a webhelyünket, és létrehozott FitNesse teszteket tulajdonságokkal mindenről, amit talált. De a rendszer továbbra is gyakran változó részei számára a frissítések “másolása és beillesztése” nehézkes volt. Hiányzott a rendszer “felülvizsgálat módosítása és jóváhagyása” funkciója. Tehát csak a rendszer érett és stabil részeire készítettünk teszteket. Ez nagyon jól működött, és nagy mértékben csökkentette a tesztelési erőfeszítéseket és kockázatot egyaránt. Gyakran előfordulhat, hogy ezek a tesztek apróbb különbségeket fedeznek fel, amelyeket a manuális tesztelés valószínűleg kihagyott volna.

A regressziós tesztjeink javítása

Az automatizált UI tesztelés jelenlegi módszerei hibásak, mivel a regressziós tesztelés nem tesztelés. A regressziós tesztelés a rendszer viselkedésének verzió ellenőrzése. Ez a felismerés számos gyakori problémát orvosol, és sokkal hatékonyabbá teszi a tesztek létrehozását és fenntartását.

Forrás: https://www.stickyminds.com/article/problem-how-we-do-regression-testing 
Szerző: Jeremias Roessler