A gazdasági világválság hatásai a szoftveripart sem kerülik el: a kis- és nagyvállalatok beruházási büdzséjének szűkülésével, a piaci verseny élesedésével minden eddiginél fontosabbá vált a szoftverprojektek hatékonyságának kérdése. A szoftverminőség kérdésköre sokáig mellőzött téma volt az iparágon belül, mára azonban világossá vált, hogy a hatékony működés egyik legfontosabb eleme a professzionális és tudatos minőségbiztosítási, tesztelési folyamatok beépítése a projektekbe. A szoftverminőség témakörének egyik központi kérdése annak mérhetősége, számszerűsítése: erről beszélgettünk az Alvicom Kft két szakemberével, Deák Szabolccsal és Tanács Lajossal.
Kérdés: Milyen szerepet tölt be napjainkban Magyarországon a nagyvállalati projektek életében a szoftverminőség mérésének kérdése? Hogyan mérünk a gyakorlatban?
Válasz: A elkészült (illetve megszülető) szoftver minőségét napjainkban leginkább a szoftvertesztelés eredményéből vezetjük le. Sokszor ez nagyon egyszerűen történik: ha sok hibát találunk a rendszerben, rossz a minőség, ha keveset, jó. Ez a leegyszerűsítés azonban rengeteg kérdést vet fel: mi számít például soknak és mi kevésnek? A kevés hiba vajon a szoftver minőségének köszönhető vagy a felületes tesztelésnek? Ezek a fogalmak relatívak, mégis hajlamosak vagyunk arra, hogy száz hibát soknak, tízet pedig kevésnek értékeljünk, pedig ezeknek a hibáknak súlyossága, előfordulási gyakorisága, üzleti hatása legalább ugyanannyira befolyásolja a szoftver használhatóságát és minőségét, mint a puszta számosság. Annak érdekében, hogy az eredményeket ne csak szubjektíven ítéljük meg, teljesebb képet kell hát kapnunk a minőségről és a termékeket előállító folyamatokról összehasonlítható adatokra van szükségünk, mérni kell azokat, ráadásul a hibák számának és súlyosságának alakulásán túl más tényezőket is figyelembe kell venni.
Kérdés: Mi a mérés gyakorlati célja? Milyen döntési helyzetekben lehet ezeket az adatokat felhasználni?
Válasz: A mérés több, a projekt életét és sikerességét alapvetően befolyásoló tényezőt befolyásol. Egyrészt a szoftver fejlődése során elérkezik bizonyos állomásokhoz: a fejlesztői tesztelés szintjéről átkerül a funkcionális, integrációs tesztelőkhöz, onnan az üzleti átvételi tesztelőkhöz, majd élesíthetővé válik. A folyamat minden állomása egy bizonyos minőségbeli színvonal elérését jelenti, amelyet hiba felderítési és javítási ciklusokkal érünk el. Az, hogy az adott szoftver átkerülhet-e életciklusának következő állomásába, alapvetően annak minősége határozza meg, illetve a szoftver minőségén alapuló vezetői döntés. Ehhez a döntéshozatalhoz azonban nem elég megérzésekre és szubjektív véleményekre hagyatkozni, hiszen a szoftver túl korai „elengedése" beláthatatlan üzleti károkat, elnyújtott tesztelése és javítása viszont drasztikusan megemelkedett projektköltségeket okozhat: ezért tekintünk a minőségi metrikákra mint fundamentális döntéstámogató eszközökre.
A minőségi döntéstámogatáson túl a minőségi mérőszámok által mutatott értékek a projekt folyamatainak elemzésére, optimalizálására is használhatók: ha a rendszer hibáinak jelentős része a kritikus kategóriába esik, amelyek a következő verzióval tömegesen javulnak, akkor felül kell vizsgálni a release menedzsment folyamatot a projektben. Ha a hibák száma és súlyossága hosszabb időn keresztül sem változik, elképzelhető, hogy pontosabb és céltudatosabb hiba priorizálásra van szükség a munka során.
A tesztelési metrikák mindezeken túl hatékony kockázatelemzési eszközök, amelyek lehetővé teszik a kockázatok felismerését, a kockázatkezelési lépések meghatározását a projektvezetés számára. A kockázatkezelés - a döntéstámogatáshoz hasonlóan - messze túlmutat a tesztelés témakörén, ebből is tisztán látszik, hogy mennyire fontos eszköz a folyamatos és tudatos minőségmérés a projektek élete folyamán.
Kérdés: Szó esett már a hibák méréséről: milyen szempontból szükséges ezeket vizsgálni, illetve milyen más tényezőket érdemes mérnünk még a projektek során?
Válasz: A felfedezett hibákat - pontosabban incidenseket, hiszen közel sem minden felfedezett incidens bizonyul hibának - több dimenzió mentén érdemes vizsgálni. Az incidensek aktuális száma és prioritása, azok időbeni változása természetesen kiemelten fontos. Mindenképpen mérendő azonban az, hogy az incidenskezelési életciklus mely fázisa mennyi ideig tart, milyen státuszban mennyi időt tölt egy eset: így felismerhető, hogy hol van a projektfolyamatban a szűk keresztmetszet, amely optimalizálásra szorul (például nem megfelelő a tesztelő-programozó arány). Szokás vizsgálni a hibák által érintett funkcionális területek eloszlását is, mind aktuálisan, mind pedig historikusan: így felderíthetők kiemelten kockázatos funkcionális területek az alkalmazásban, sőt, ez akár helytelen műszaki megoldásokra, szoftvertervezési vagy elemzési folyamati hibákra is rávilágíthat. Szokás vizsgálni a szoftver életciklusának különböző fázisaiban (funkcionális tesztelés, átvételi tesztelés, éles üzem) fellelt esetek számát, illetve azok egymáshoz viszonyított arányát. A hibák javítása egyre drágábbá válik, ahogy előrehaladunk a projekt életútján: akkor dolgozunk jól, ha nagyságrendileg kevesebb hibát találunk egy fázisban, mint az azt megelőzőben. Visszatérő téma a javítottnak gondolt esetek tesztelés során történő újranyitása, azok számának alakulása, illetve az újranyitások okának vizsgálata.
Az incidensekkel kapcsolatos számokon túl azonban mindig figyelembe kell vennünk azt is, hogy a szoftver életciklus mely állomásánál tart a projektünk, hiszen az, hogy a tesztelés első hetében alacsony a hibák száma, még nem sok információval szolgál a szoftver valós minőségéről. Fontos figyelembe venni, milyen méretű és komplexitású a szoftverünk: ennek meghatározására kódsorszámot, osztályok számát, átlagos és maximális hívási mélységet, absztrakciós mélységet, ciklikus komplexitást szokás mérni.
A metrikák alakulását érdemes a terveinkkel is összevetni: ezekből a számokból képet kaphatunk becsléseink, tervezési módszertanunk pontosságáról, következtetéseket vonhatunk le a projekt jellegzetességeiről, illetve pontosíthatjuk további becsléseinket.
Nem szabad a projektkörnyezetünkről, illetve a csapatunk felépítéséről sem megfeledkezni: ha például húsz programozóra csak egy tesztelő jut, a hibák száma mindig nagyon alacsony lesz, hiszen a hibajavítás mindig sokkal gyorsabban fog folyni a javítások újratesztelésénél és az új hibák felderítésénél. Ez azonban még korántsem jelenti azt, hogy csúcsminőségű szoftverrel lenne dolgunk.
Kérdés: Milyen eszközök állnak rendelkezésre, melyek támogatják a metrikák megállapítását?
Válasz: Elengedhetetlennek gondoljuk egy központi adatbázissal üzemelő, konkurens felhasználást lehetővé tevő, az esetek életútját, státuszait pontosan és historikusan is nyomon követő esetkezelő (issue tracking) rendszer használatát. A piacon az ingyenes, nyílt forráskódú rendszerektől a nagynevű gyártók teljes szoftverminőségi életciklust lefedő, robosztus termékéiig rengeteg kiváló megoldás elérhető napjainkban. A szoftver méretét és komplexitását forráskód elemző eszközökkel érdemes végezni, ezeknek ugyancsak számos változata hozzáférhető.
A hatékony teszteléshez bizonyos szoftverméret fölött ma már szinte elengedhetetlen az automatizált tesztelési eszközök használata, amelyek magasabb kezdeti erőforrás befektetéseik többszörösen megtérülnek, amint a készülő szoftvertermék mérete elér egy bizonyos kritikus szintet.
Kérdés: Végezetül és összefoglalásként milyen elveket tartanak a legfontosabbnak, milyen utat kövessenek azok a szakemberek, akik tovább szeretnének lépni a tudatosabb, hatékonyabb minőségelemzés irányába?
Válasz: Bátran használjuk a már említett eszközkészletet, de ne célként, hanem a minőségmenedzsment eszközeként tekintsünk rájuk. Mindig a jól megválasztott metrikák által előállított teljes kép alapján alkossunk véleményt szoftverünk minőségéről, a projektünk folyamatairól, és ne kiragadott paraméterek alapján. Végezetül legyünk bátrak, és keressük meg a minőségi problémák valódi okait, ne tüneti kezelést alkalmazzunk! Ne feledjük, a célunk nem az, hogy az esetkezelő rendszerben nyilvántartott hibák száma nullára csökkenjen, hanem az, hogy megfelelő minőségű, a megrendelőt elégedettséggel eltöltő szoftvert állítsunk elő, határidőre és meghatározott költségkeretből!
