A szoftverfejlesztés világában az egyik legkritikusabb pillanat a kiadás előtti döntés. Az új verzió kiadásával megbízottaknak el kell döntenie, hogy a szoftver készen áll-e arra, hogy a felhasználók elé kerüljön, vagy további munkára van szükség. Ezt a döntést számos tényező befolyásolja, ám az egyik legfontosabb mérőszám a forráskód tesztlefedettsége. Vajon miért támaszkodik még mindig kevés cég erre a mutatóra, és valóban meghatározza-e a tesztlefedettség, hogy egy szoftver készen áll-e a piacra lépésre?
A kódlefedettség szerepe a Go/No-Go döntésben
Ahogyan arról már korábban írtunk, hogy a kódlefedettség fontos szerepet játszik a Go/No-Go döntés, azaz a release kiadásának meghozatalában. Ez egy olyan mutató, amely azt méri, hogy a szoftver forráskódjának mekkora része került tesztelésre. Általában százalékos formában jelenik meg, és minél magasabb a szám, a kód annál nagyobb részét fedték a tesztek. A kódlefedettség mérése során különböző dimenziókat vehetünk figyelembe, mint például a sor-, ág-, vagy függvénylefedettség.
A magas kódlefedettség azt jelzi, hogy a tesztek nagy részletességgel ellenőrizték a forráskód működését. Ez arra is utal, hogy a rejtett hibák és a nem várt működés kockázatát a tesztelők és fejlesztők minimalizálták. Ezzel szemben az alacsony kódlefedettség arra utal, hogy a kód jelentős része nem kerültek tesztelésre. Ez jelentős kockázatot hordoz magában, különösen a kritikus rendszerek vagy nagyobb változtatások – például egy új funkció bekerülése – esetén.
A Go/No-Go döntés során a kódlefedettségről kapott kép lehetővé teszi a fejlesztői csapatok számára, hogy objektíven értékeljék a szoftver jelenlegi állapotát. Amennyiben szükséges, úgy további tesztelést hajthatnak végre a kockázatok csökkentése érdekében. Így a kódlefedettség nem csupán egy technikai mérőszám, hanem egy olyan stratégiai eszköz is, amely elősegíti a magas minőségű, megbízható szoftverek kiadását, miközben védi a vállalat hírnevét és minimalizálja a pénzügyi veszteségeket.
Hogyan segíthet a TestNavigator?
A TestNavigator használatával a verzió kiadása előtt egyértelműen meghatározható, hogy az adott verzió milyen alaposan lett tesztelve. Ezzel együtt az is megállapítható, hogy annak ügyfélhez való kiadása milyen kockázatot rejt magában. Egy nem megfelelően, vagy nem elég alaposan letesztelt frissítés kiadása óriási károkat okozhat, amelyeket jelentős anyagi veszteségben lehet mérni.
2024 júliusában a CordStrike cég kiadott egy nem megfelelően letesztelt frissítést, amelynek következtében a szoftvert használó számítógépek működésképtelenné váltak. Becslések szerint a hiba miatt 8.5 millió számítógép vált használhatatlanná, több mint 10 milliárd dollár anyagi kárt okozva az ügyfeleknek. Példaképp az eset a TestNavigator használatával elkerülhető lett volna. A relase előtt a cég döntéshozói köre egyértelmű százalékos értéket kapott volna a rendszer teszteltségéről, valamint a le nem fedett kódrészletekről.
Kiadás előtti tesztelés TestNavigatorral
A TestNavigator rendszerében a tesztciklus létrehozásakor úgynevezett "Exit criteria"-kat lehet meghatározni, amelyek a teljes lefedettségre, a változások lefedettségére, valamint a lefuttatott tesztesetek számára vonatkoznak. Fontos kiemelni, hogy külön "Exit criteria"-k adhatók meg a teljes forráskód és a frissen módosított kódrészletek teszteltségi lefedettségére, mivel a legnagyobb kockázatot mindig azok a kódrészletek jelentik, amelyek a legutóbbi verzió óta módosultak.
Az "Exit criteria"-k meghatározása után a tesztelési folyamat elkezdődik. A tesztelés befejeztével a rendszer "Go" vagy "No-Go" státuszt rendel a kiadni kívánt verzióhoz. Amennyiben a rendszer "No-Go" státuszt jelez, további tesztesetek futtatása szükséges ahhoz, hogy a verzió elérje a kívánt teszteltségi szintet, biztosítva ezzel a biztonságos kiadást.
Megoldás a kritikus pontok leküzdésére
Összegzésképpen, a TestNavigator nem csupán egy eszköz a tesztelés támogatására, hanem egy kritikus komponens a kiadási folyamat során, amely segít minimalizálni a kockázatokat és biztosítja, hogy a verziók csak akkor kerüljenek kiadásra, ha megfelelnek a szigorú tesztelési kritériumoknak.
A rendszer által nyújtott Go/No-Go státusz egyértelmű és átlátható döntési pontot biztosít, amely lehetővé teszi a vállalatok számára, hogy megbízható és stabil szoftvert juttassanak el az ügyfelekhez, elkerülve ezzel a potenciálisan súlyos hibákból eredő anyagi veszteségeket és az ügyfélbizalom csökkenését.