Ahogy a szoftverek mind bonyolultabbak lesznek, úgy lesz egyre nehezebb a tesztelők dolga is. Megoldást az automatizált tesztelő eszközök jelenthetnek, és az, ha már a fejlesztés elején is gondolnak a tesztelésre.
Nem pusztán tapasztalati, hanem matematikailag is bizonyított tény, hogy hibátlan szoftver nincs, legfeljebb olyan, amelyet nem teszteltek eléggé. Egy, esetenként több millió kódsorból álló szoftverben a leggondosabb ellenőrzés ellenére is óhatatlanul maradhatnak hibák, amelyek némelyike előbb-utóbb napvilágra kerül, más részük viszont esetleg akár örökre rejtve maradhat. Ez azonban nem lehet mentség az elkapkodott, felszínes tesztelésre.
Mégis, a tesztelés sokszor a szoftverfejlesztés mostohagyerekének számít. Jól végezve pénz és idő kell hozzá, de a fejlesztési projektekben ezekből mindig kevés van – ezért a határidő közeledtével inkább lemondanak az alapos ellenőrzésről, csak hogy a szoftvert mielőbb (és minél olcsóbban) használatba lehessen venni. Gyakran a fejlesztő saját szakmai meggyőződése ellenére sem tesz meg mindent a felhasználó meggyőzésére; esetleg arra számít, hogy a később felmerülő hibákat majd a normál működés során javítja ki – akár már a várható karbantartási szerződés keretében és terhére.
Mínuszok és pluszok
Szerencsére ez a szemlélet lassan, de biztosan kezd megváltozni, még ha a gyakorlat nem is minden esetben követi, mondja Csurgai Gábor, a saját tesztelési módszertant, az ACE-t kidolgozó Catura elnöke. A vállalatok informatikai részlegein és a felhasználók között egyre többen ismerik fel, hogy a szoftver (és azon keresztül az üzleti szolgáltatás) minősége, zavartalan működése nagymértékben függ attól, mennyire alaposan és körültekintően tesztelték le az alkalmazást. A zavartalan működés pedig jól lefordítható bevételre, mint ahogy fordítva, a használhatatlan szoftver egyértelmű a nagy kiadással.
Ráadásul egy nagyvállalati szoftver folyamatosan változik: rendszeresen kérnek benne módosításokat, funkcióbővítéseket a felhasználók, gyakran olyan távoli programrészeket is érintve, amelyekhez igazából nem nyúltak. „Ha ezeket a kisebb fejlesztéseket nem tesztelik le alaposan, annak az üzlet ihatja meg a levét. Minél később fedeznek fel egy hibát, annál drágább a javítása, amihez aztán a megzavart üzletmenetből származó kiadások, illetve elmaradt bevételek is társulnak”, mondja Csurgai Gábor. Egy óránként 200 ezer forintos forgalmat lebonyolító webáruház ötórás kiesésének költségeit igen könnyen fel lehet becsülni.
„Kiélezett versenypiaci helyzetben az új üzleti igények alapján definiált, komplex alkalmazások fejlesztése során a hiányzó vagy rosszul végrehajtott fejlesztés, funkcióbővítés nem várt mértékű (és költségesen elhárítható) hibákat eredményezhet” – ért egyet a fentiekkel Hajdú Miklós, az AlphaNet üzletfejlesztési és technológiai igazgatója. „A megrendelők igényei alapján a szállítók kiemelt feladata az informatikai működési és fejlesztési költségek optimalizálása, a rendelkezésre álló erőforrások gazdaságos felhasználása, illetve a közép- és hosszú távú informatikai fejlesztések hatékonyságának és gyors megtérülésének támogatása.”
De fordítva is igaz a helyzet: a jól tesztelt alkalmazások pénzben kifejezhető előnnyel járnak. Ezt nem mindig könnyű számszerűsíteni, de Csurgai Gábor szerint figyelembe kell venni, amikor a tesztelés hasznát értékeli egy üzleti vezető. Egy jobban megírt, az üzleti követelményeket teljeskörűen lefedő, könnyen és gyorsan bevezethető alkalmazás megkönnyíti az üzletmenetet, javítja a munka hatékonyságát, lehetővé teszi erőforrások megtakarítását, valamint az új üzleti lehetőségek kiaknázását.
|
Mobilra is… |
|---|
|
Az okostelefonok terjedése új feladatok elé állította a fejlesztőket és a tesztelőket is. A felhasználók időtől és helyszíntől függetlenül, de a megszokott minőségben szeretnék elérni kedvenc webes tartalmaikat és szolgáltatásaikat. A fejlesztőkre hárul, hogy a mobil internet adottságaihoz (az alacsonyabb sávszélességhez) és a kisebb, különböző méretű kijelzőkhöz igazodó, a mobilplatformokra optimalizált alkalmazásokat készítsenek. A webes szolgáltatások azonban gyakran másként viselkednek mobil eszközökről elérve, hiszen működésüket a szolgáltató kapacitása, a készülék fejlettsége, operációs rendszere és a böngészők típusa is jelentősen befolyásolhatja, mondja Hajdú Miklós, az AlphaNet üzletfejlesztési és technológiai igazgatója. A mobilelérésre szánt webes szolgáltatások és alkalmazások teszteléséhez nyújt segítséget a Micro Focus Silk Performer terméke. A megoldás segítségével az Android, iOS és Blackberry eszközök böngészőit, egyedi méretű kijelzőit és beviteli lehetőségeit, illetve a folyamatos használat során előforduló sávszélességbeli korlátokat lehet szimulálni. |
Kódom, kódom, mondd meg nékem…
Ezeket az előnyöket persze nem adják könnyen. A szoftverteszteknek több fajtáját lehet elkülöníteni (ezekről lásd keretes írásunkat), és még a viszonylag egyszerűen elvégezhető programellenőrzések is mind bonyolultabbak lesznek, figyelmeztet Hajdú Miklós.
Az egyre összetettebb infrastruktúrák – például a számítási felhők – elterjedése és a heterogén informatikai komponensek bonyolultsága tovább növelheti a működés kockázatát. Ilyen körülmények között a megbízhatóságot és a minél magasabb rendelkezésre állást az egyes fejlesztési fázisok során alkalmazott programkód hibamentességének ellenőrzése, a kívánt teljesítményre történő optimalizálása, valamint korszerű szoftvertesztelési eszközök alkalmazása szavatolhatja. A programkódok (VB.NET, Java, C#, C++) minőségének, megbízhatóságának és az így készülő alkalmazások sérülékenységének vizsgálatára alkalmas lehet például a Micro Focus DevPartner az AlphaNet technológiai igazgatója szerint. Ennek segítségével kimutatható például a túlzott memória- vagy processzorhasználat, és elemezhető a váratlan leállást kiváltó hiba oka.
„Teljes szemléletmódváltásról azonban nem beszélhetünk” – folytatja Hajdú Miklós, „mert a mobil- és felhőszolgáltatások esetében is számos kisebb, külön funkcionális igények alapján készített alkalmazásnak és szolgáltatásnak kell együttműködnie. Így az egyes, felhő alapú alkalmazáskomponensek funkcionalitását, megbízhatóságát és azok teljesítményét nem külön kell tesztelni, hanem összefüggéseiben kell vizsgálni, figyelembe véve a mögöttük álló teljes üzleti folyamat működőképességét.”
Kiváltképp a számítási felhőben vagy a web alapú üzleti szolgáltatások üzemeltetése esetében fontos a terheléses tesztek elvégzése, mert így csökkenthető a tömeges felhasználói igénybevétellel járó túlterhelést követő akadozás, leállás kockázata.
Automatizáltan
Elsősorban nagyvállalati és intézményi környezetben fontosak azok a tesztek is, amelyek az üzleti folyamatok szempontjából is vizsgálják az alkalmazásokat. Ezek közül a folyamatok helyességének ellenőrzése a legtöbb vállalat eszköztárában szerepel, ám többnyire kézi erővel végzik ezt, és sok esetben a későbbi felhasználókat kérik meg a tesztelésre. Valóban ők a legalkalmasabbak arra, hogy véleményt mondjanak a rendszer működéséről; ha azonban a tesztelést a normál munkájuk mellett kell végezniük, csak a minimálisan szükséges időt fogják ráfordítani. Ilyenkor fordul elő, hogy csak a szoftver normál, „egyenes ági” működését ellenőrzik, és nem derül ki, hogy mi történik hiba vagy rossz adatbevitel esetén.
A negyedik szintű tesztelés (lásd a „Teszt teszt hátán” című keretet), az üzleti teljesség vizsgálata már valóban nagyon ritka – ismeri el Csurgai Gábor. Ilyen esetekben ugyanis nemcsak egy nagyobb alkalmazás szabványos folyamatait kell vizsgálni, hanem azt is, hogy ezek a folyamatok megfelelnek-e a jogi előírásoknak vagy más, külső alkalmazások által támasztott elvárásoknak.
A megoldás a tesztelés minél teljesebb körű automatizálása, illetve a leendő felhasználók, az üzleti területek képviselőinek a munkába való minél korábbi bevonása lehet. Az automatizált tesztelésnek számos előnye van. Kevesebb emberi erőforrást igényel, így a költségei is kisebbek lehetnek. Komplexebb vizsgálatokat tesz lehetővé, több hibát derít fel, ráadásul a fejlesztés korai szakaszaiban, amikor gyorsabb és olcsóbb azok kijavítása. A tesztesetek és eredmények rögzíthetők, azok bármikor újra felhasználhatók, tovább egyszerűsítve a későbbi munkákat.
A definíció hatalma
A legjobb eszközök sem hoznak azonban megfelelő eredményt, ha a felhasználók elvárásai és a fejlesztők munkája nem találkoznak egymással. A fejlesztések mindig az üzleti igényekből indulnak ki, a probléma abban rejlik, hogy a felhasználók sokszor maguk sem tudják pontosan definiálni a funkcionális és teljesítménybeli követelményeiket. Még kevésbé tudják azokat az informatikusok által is jól érthető nyelvre lefordítani. Ebből egyenesen következnek a „tudom, hogy ezt beszéltük meg, de nem erre gondoltam” típusú beszélgetések a felhasználók és a fejlesztők között: a fejlesztés és a tesztelés korai szakaszai voltaképpen a felhasználói igények tisztázására szolgálnak.
Ezért a hatékony tesztelés – azon keresztül pedig a problémamentesen működő szoftver – kiindulópontja az üzleti igények és folyamatok minél pontosabb és részletesebb definiálása. Időnként a legegyszerűbbnek látszó felhasználói kérések mögött is komoly csapdák rejtőzhetnek. Mondjuk az a kívánság, hogy a forint mellett euróban is lehessen fizetni. Gondolnak-e például arra, hogy az eurónál váltópénzzel is kell számolni? Vagy arra, hogy a könyvelésnek minden nap szüksége lesz a hivatalos árfolyamra, hogy forintban tudja elszámolni a bevételt? „Az egyszerűnek tűnő igényeket is részletesen ki kell bontani és végig kell gondolni, mert hatásai a szoftver számos más elemét is érinthetik” – figyelmeztet Csurgai Gábor.
Jó esetben ezért a megrendelő üzleti felhasználó és a fejlesztő-tesztelő már a projekt legelején leül egymással, és aprólékosan tisztázza és elemeire bontja le a funkcionális és üzleti követelményeket. Az elemeire lebontott követelményrendszer már jól formalizálható, és így bemenete lehet a tesztautomatizáló rendszereknek. Ezek a rendszerek képesek arra, hogy a követelmények alapján támogassák a tesztesetek definiálását, majd ezeket a teszteket a megfelelő időben, mélységben, változatosságban és gyakorisággal automatizáltan le is futtassák.
Annyi bizonyos, hogy az automatizált tesztelés esetében jóval tovább tart a tesztesetek tervezése és elkészítése. Ám ha az üzleti felhasználókat is bevonják, és a tényleges elvárásoknak megfelelően építik fel a teszteseteket, a tényleges tesztelési fázisok sokkal rövidebb ideig fognak tartani, miközben a végeredmény, a fejlesztett alkalmazás nemcsak kevesebb programhibát tartalmaz, hanem az üzleti elvárásoknak is jobban megfelel.
|
Teszt teszt hátán |
|---|
|
Négy nagyobb szintre lehet csoportosítani a szoftverteszteket a megcélzott ellenőrzés alapján. A legalsó szint pusztán technikai jellegű, és itt csupán azt vizsgálják, hogy a programkód képes-e egyáltalán az elvárt működésre, például be lehet-e írni az információt az adott mezőbe. Ezt a tesztet el lehet végezni a legapróbb részegységek és nagyobb programmodulok körén is, ellenőrizve például az elemek integrálódását. A második szint a működést zavaró programhibák kiküszöbölésére szolgál: engedi-e például az alkalmazás, hogy egy dátummezőbe február 30-at írjunk be? A harmadik és a negyedik szint már az üzleti folyamatok felől vizsgálja az alkalmazásokat. A harmadik szinten ellenőrzik az üzleti folyamatok helyességét, mondjuk a számla kiállításához képest valóban nyolc nappal későbbi-e a fizetési határidő. A legmagasabb szinten már azt is vizsgálja a tesztelés, hogy a szoftver a maga teljességében leképezi-e az üzleti folyamatokat, belekerül-e minden végrehajtási és ellenőrzési funkció, amely az adott folyamatot jellemzi. |
Működésben a tesztgyár
Hasonlóképpen látja ezt a Magyar Telekom, és ennek megfelelően cselekszik is. A vállalatnál az utóbbi években jelentős szervezeti változások zajlottak le, amelynek során korábban önálló informatikai részlegek is összeolvadtak. A részlegek mindegyike saját szoftvertesztelési kompetenciákkal, módszerekkel és gyakorlattal rendelkezett. Ezek egységesítésére mintegy másfél évvel ezelőtt létrehozták az IT Alkalmazástesztelési Osztályt, vagy ahogy cégen belül előszeretettel nevezik, a Test Factoryt, mondja el Simon György Ferenc, az osztály teszt szakmai irányítója.
A Test Factoryban összpontosul minden (a belső vállalati crm- és billing-alkalmazásokat, illetve egyes, az ügyfelek számára is elérhető webes alkalmazásokat érintő), it-teszteléssel kapcsolatos, házon belüli feladat. Így egyetlen, világos felelősségi körökkel rendelkező szervezet egységes módszertan szerint tesztelheti az alkalmazásokat Ennek köszönhetően az egész folyamat jóval átláthatóbb és könnyebben koordinálható lett.
A központ a meglévő elemek „újrahasznosításával” egyedi tesztelési módszertant alakított ki. Ennek alapelve, hogy a tesztelés minél hamarabb – lehetőleg már a tervezés fázisában – legyen része a fejlesztési projekteknek. „Amikor egy ötletről, igényről kiderül, hogy projekt lesz belőle, onnantól kezdve már a Test Factory is aktív résztvevője a fejlesztésnek” – mondja Simon György Ferenc. A tesztelők már a korai fázisban rendszeresen konzultálnak a megrendelőkkel (a leendő felhasználókkal), segítenek a rendszerspecifikáció kidolgozásában, az igények, követelmények pontosításában, és ennek során azt is fel tudják mérni, hogy a tesztközpont részéről milyen erőforrásokra lesz szükség.
Bizonyos mértékig a Test Factorynak is meg kellett küzdenie azzal, hogy ne a fejlesztés kerékkötőjét lássa benne a megrendelő és a fejlesztő. Segített, hogy a tesztelési módszertant az üzleti területek bevonásával alakították ki. Ez biztosította, hogy a tesztelési eljárásokat az üzleti felhasználók is a sajátjukénak érezzék.
Az egyes fejlesztési munkákhoz kapcsolódó tesztkövetelményeket és az ezekből képzett teszteseteket a Test Factory szakemberei dolgozzák ki az üzleti és az informatikai igények alapján, de ezeket minden esetben átnézetik és jóváhagyatják az üzleti terület képviselőivel is. A szoros együttműködésnek köszönhetően a felhasználók tisztában vannak azzal, hogy a teszteléssel kapcsolatban milyen feladatok hárulnak rájuk, a tesztelési ciklus melyik fázisában és milyen formában van szükség az együttműködésükre.
Schopp Attila
