A Gap analízis használata a tesztelési folyamatban a fejlesztők és a tesztelők összehangolására

széles körben elterjedt meggyőződés, hogy a fejlesztők és a tesztelők úgy viselkednek, mint a kréta és a sajt. A fejlesztők gyakran lenézik az orrukat a tesztelőkre, úgy tekintenek rájuk, mint egy rugalmatlan és haszontalan húzásra az új kód kifejlesztésében, akik nem adnak egyértelmű részleteket a hibajegyeikben. Hasonlóképpen, a tesztelők gyakran irritálják a fejlesztőket, mert nem tájékoztatják őket a kódváltozásokról, és a tesztciklusok során új változtatásokat hajtanak végre. Ez az oka annak, hogy a minőségbiztosítási tesztelési folyamatban a gap-elemzés különösen előnyös lehet mind a fejlesztők, mind a tesztelők összehangolásához.

bár ez a nézet apokrif lehet, gyakran előfordul, hogy a fejlesztők és a tesztelők nem kommunikálnak jól. A kommunikáció gyakran csak a menedzsmenten (projektmenedzsereken és vonalvezetőkön) vagy a Jira jegyein keresztül történik. Az eredmény az, hogy a tesztelés gyakran nem megfelelő. Különösen túl gyakran az új kódot rosszul tesztelik, vagy egyáltalán nem tesztelik. A kutatások kimutatták, hogy ez a nem tesztelt új kód a jövőbeli hibák és hibák legnagyobb forrása. Ez az, ahol a koncepció teszt rés elemzés jön szóba.

ebben a blogban megvizsgáljuk, hogy mi a tesztelési rés elemzése, megmutatja, hogyan segíthet azonosítani a tesztelni kívánt kódot, és feltárja, hogy ez a megközelítés az a csodaszer, amely áthidalhatja a fejlesztők és a tesztelők közötti szakadékot.

mi a Tesztrés-elemzés?

amikor először fejleszt ki egy szoftverrendszert, könnyen biztos lehet benne, hogy az egész rendszert teszteli. A tesztelők képesek a kód specifikációit, és a tervezett és feltáró tesztelés kombinációját használni annak biztosítására, hogy teszteljék a kódbázis minden mozgó részét. A legtöbb szoftver azonban nem statikus. A vállalatok vagy monolitikus időszakos kiadásokat készítenek hosszú élettartamú kódokból, vagy valamilyen szintű folyamatos integrációt és folyamatos telepítést (CI/CD) alkalmaznak. Mindkét esetben a kódbázis folyamatosan változik. Azonban túl gyakran a vizsgálati esetek nem frissülnek ugyanolyan ütemben. Néha a tesztelők egyszerűen nem tudják, hogy kódmódosítás történt. Más idők, a kódváltozást közvetlenül egy adott tesztkészlet futtatása után tolják. Úgy tűnik, hogy ezek a tesztek átmentek, de a kódváltozás megtörhette őket.

Test Gap Analysis az a folyamat, amely azonosítja ezeket a hiányosságokat, ahol új kódot telepítettek, de még nem tesztelték. Ehhez az összes kódváltozás statikus elemzésére és az összes jelenlegi tesztelés dinamikus elemzésére van szükség. E két elemzés összehasonlításával könnyen láthatja, hol vannak hiányosságok. Vagyis az új kód olyan területei, amelyeket megfelelően teszteltek. Ez általában úgy történik, hogy a kódot egy fa diagram formájában ábrázoljuk, ahol a kód funkcionális blokkokra oszlik, minden blokk alatt az alkotó osztályok, ezek alatt a tényleges módszerek és függvények. A hierarchia minden szintjén a blokk relatív mérete jelzi a kód mennyiségét. A kódváltozásokat mutató fa átfedésével a tesztelés jelenlegi állapotát mutató fával könnyű észrevenni azokat a területeket, ahol hiányzik a teszt lefedettsége.

egy fa térkép, amely változatlan kódot (szürke), felülvizsgált/új tesztelt kódot (zöld), felülvizsgált, nem tesztelt kódot (narancssárga) és új, nem tesztelt kódot (piros) mutat.

miért fontos a tesztelési rés elemzése a tesztelési folyamatban?

egy 2013-as tanulmányban a Müncheni Műszaki Egyetem kutatói tanulmányt készítettek az új, nem tesztelt kód és a jövőbeli szoftverhibák közötti összefüggésről. Együtt dolgoztak a Munich Re-vel (egy nagy biztosítótársasággal), 2 kiadáson keresztül figyelemmel kísérve hosszú élettartamú informatikai rendszerüket. A kiadás során megállapították, hogy melyik kód új, és azt is megvizsgálták, hogy melyik kódot tesztelték, és melyik kódot adták ki tesztelés nélkül. Ezt követően hosszú ideig figyelték a rendszert, és nyomon követték az összes jelentett hibát az eredeti forráshoz. Két kulcsfontosságú dolgot fedeztek fel. Először is, az összes kód nagyjából egyharmadát tesztelés nélkül adták ki. Másodszor, amikor nyomon követték a hibákat, felfedezték, hogy az összes hiba 70-80% – a nem tesztelt kódban volt. Az alábbi grafikon ezt világosabban mutatja.

mint látható, a régi tesztelt kódnak nem voltak hibái. Az új tesztelt kód a hibák 22-30% – át tartalmazta, és a fennmaradó hibák meglehetősen egyenletesen oszlottak meg az új, nem tesztelt kód és a régi nem tesztelt kód között. Mivel azonban az új kód csak a teljes kód 15% – át tette ki, láthatja, hogy az új, nem tesztelt kód aránytalanul nagy számú hibát okozott.

Test Gap Analysis célja, hogy azonosítsa ezt a nem tesztelt új kódot. Ez azonban más módon is segíthet. Például, mivel figyeli, hogy mit tesztel, azonosíthatja a meglévő kód elavult területeit (pl. még tesztelés alatt állnak, de valójában semmilyen kód nem hívja meg őket). Azt is kiemelheti, hogy mely területekre kell koncentrálnia a tesztelési erőforrásokat. Rendszeres futtatásával a vezetők javíthatják a teszttervezést, az új kód tesztelésére összpontosítva, és megpróbálják biztosítani az egyenletes teszt lefedettséget.

a fejlesztők és a tesztelők a Tesztrés-elemzésen keresztül igazodnak

a Tesztrés-elemzés egyértelműen hatékony koncepció. De az is világos, hogy nem minden csapat részesül egyformán belőle. A leginkább előnyös csapatok azok, akik hosszú élettartamú kódbázisokat tartanak fenn időszakos monolit kiadásokkal. A hosszú életű kódbázisokban a fejlesztők gyakran olyan kódon dolgoznak, amelyet más emberek írtak. A tesztelők támaszkodhatnak a korábban több változatban készített teszttervekre. Ezek a tényezők együttesen azt jelenthetik, hogy senki sem tudja pontosan, melyik kódot tesztelik, vagy hogy ez a kód hogyan működik együtt a rendszer más részeivel. Itt a TGA lehetővé teszi a tesztelők számára, hogy pontosan lássák, milyen kód változott, ami lehetővé teszi számukra, hogy erre összpontosítsanak. Azonosíthatják a meglévő rendszerben még nem tesztelt kódot is.

A CI/CD-t használó csapatok szintén profitálhatnak ebből a megközelítésből, mivel ez lehetővé teszi a tesztelők számára, hogy gyorsan azonosítsák, hogy pontosan milyen kódot változtattak meg, így lehetővé teszik számukra, hogy erre koncentráljanak. Elkerülheti a fent említett problémát is, ha egy kóddarab közvetlenül a tesztelés után megváltozik, majd a teszteletlen változásokkal felszabadul.

másrészt azok a csapatok, amelyek új vagy rövid életű kódon dolgoznak, kevésbé részesülnek előnyben, mivel definíció szerint a legtöbb kódot először nem tesztelik. Itt fontos, hogy szabványos vizsgálati módszereket használjunk annak biztosítása érdekében, hogy a tesztelés jó legyen. Lehet, azonban, hasznos lehet az ilyen csapatok számára a teszt lefedettségének nyomon követése a TGA használatával, mivel ez lehetővé teszi számukra a jövőbeni problémák elkerülését.

mik a lehetséges problémák?

van néhány probléma a TGA-val. Az egyik legnagyobb az a tény, hogy nem tudja megmondani, hogy melyik kódot hívják aktívan a kódbázisban. A fejlesztők gyakran új kódot adnak hozzá a jövőbeli kiadások előkészítéséhez, de mivel ez inaktív, a tesztcsomag nem hívhatja meg. Ennek eredményeként ez a kód mindig új, nem tesztelt kódként jelenik meg. Ugyanígy sok nagy kódbázis tartalmaz régi vagy árva kód blokkokat. Ezeket rendszeresen meg kell tisztítani, de ezek ismét torzítják a vizsgálati rés elemzésének képét.

egy másik fontos megfigyelés az, hogy csak azért, mert egy kóddarabot tesztelnek, nem zárja ki, hogy a kód máshol hibákat indítson el. A legrosszabb hibák közé tartoznak azok, amikor egy kód egy kis változása egy függvény vagy módszer meghibásodását okozza egy teljesen független kódblokkban. Tehát létfontosságú mind a feltáró tesztelés, mind a regressziós tesztelés folytatása. A TGA képes azonosítani azokat a területeket a meglévő kódbázisban, amelyeket a regressziós tesztelés során nem tesztelnek megfelelően.

milyen alternatívák segítenek áthidalni a szakadékot?

a Test Gap analysis mindenképpen hasznos eszköz néhány csapat számára. Vannak azonban más módok is, hogy elkerüljük az eltérést a tesztelők tesztelése és a kódolók kódolása között. Az egyik módszer az intelligensebb tesztautomatizálás használata, amely képes azonosítani, hogy hol és mikor változtak a dolgok, mind a frontenden,mind pedig a háttérben. Itt, a Functionize-nál tesztjeink intelligens ujjlenyomatot használnak gépi tanulással és öngyógyítással a teszt karbantartásának csökkentése érdekében. Ez lehetővé teszi a tesztek számára, hogy proaktívan alkalmazkodjanak a frontend változásaihoz, valamint figyelemmel kísérjék a szerverhívásokat, a válaszidőket és azt, hogy a gombok/funkciók valóban láthatók-e. Ez azt jelenti, hogy a tesztelőket nem fogják elkapni a háttérkód vagy a tervezési/CSS változások, amelyek megváltoztatják a frontend elrendezését.

intelligens rendszerünk teszteket is létrehozhat, figyelemmel kísérve a felhasználók interakcióját a rendszerrel. Ez segít abban, hogy kevesebb hiányosság legyen a teszt lefedettségében. Az egyik legújabb eszközünk lehetővé teszi, hogy új teszteket írjon egyszerű angol nyelven. Ezeket a természetes nyelvfeldolgozó eszközünk elemzi, és használható tesztekké alakítja át. Ez azt jelenti, hogy a fejlesztés során a fejlesztők egyszerűen meghatározhatják, hogy mit kell tesztelni a normál Angol nyelv használatával, ezáltal tovább csökkentve a két tudományág közötti szakadékot.

következtetések

a tesztelési rés elemzése segít azonosítani, hogy milyen kód kerül kiadásra tesztelés nélkül, és így segíthet a tesztelési erőforrások hatékonyabb összpontosításában. Nem meglepő, hogy kiderül, hogy a nem tesztelt kód sokkal nagyobb valószínűséggel tartalmaz hibákat, ezért minden olyan eszköz, amely segíthet a kód megfelelő tesztelésében, hasznos. Azonban, mint láttuk, a TGA csak kiegészítheti a meglévő legjobb gyakorlatot. Fontos a regressziós tesztelés és a feltáró tesztelés folytatása. A TGA számos előnye intelligens tesztelő eszközök használatával is elérhető. De összességében a legfontosabb, hogy elkerüljük a tesztcsapatot a fejlesztők munkájától. Egy régi mondás téves idézéséhez győződjön meg arról, hogy a bal kéz tudja, mit csinál a jobb!