Szerencsejáték ...

... helyett menjünk biztosra és mindig teszteljük, teszteltessük le a projektünk által előállított terméket vagy szolgáltatást. Monte Carlo-ról pedig inkább a kockázatelemző módszer jusson eszünkbe projektvezetés közben, mintsem a szerencsejátékok európai fellegvára.

Kép: pixabay.com

Akár magánemberként, akár szakmai elhivatottságból kényszerülünk projektvezetésre, fontos, hogy mindig, minden körülmények között szánjunk időt a tesztelésre vagy néhány próbára a használatba vétel vagy üzembe helyezés előtt. Néhány esetben erre jogszabály is kötelez bennünket vagy a vállalkozót (például lakásépítés esetén ilyen a lakhatási engedély beszerzése vagy gépjármű üzembe helyezéséhez az érvényes műszaki vizsga).

Nézzünk még néhány példát. 

Házépítés esetén a vízvezeték nyomáspróbája a terhelhetőséget és a szerelés minőségét mutatja. 

Használt autó vásárlásnál szokásunk a tüzetes átvizsgálás mellett tenni egy próbakört, hogy ne vegyünk zsákbamacskát. 

Új gépkocsi konstrukciót tesztvezetés közben próbálnak ki a teszt pályán, és a tapasztalatok alapján folyamatosan finomítják a típus paramétereit. 

Ha ünnepi ebédet készítünk különleges fogásokból, amelyet még sosem főztünk, előtte nem árt, ha csinálunk egy „főpróbát”, valószínűsítem, hogy bőven lesznek önként jelentkező teszt alanyok J. 

Mielőtt nekilátunk és püspöklilára festjük a nappalit, célszerű néhány ecsetvonással színpróbát tenni egy kevésbé látható helyen – bár még ez sem garancia arra, hogy telitalálat lesz a választásunk.

Minél bonyolultabb egy rendszer, minél többen használják majd, vagy minél értékesebb, annál sokrétűbb az üzembe helyezés előtti tesztelése, amelyet ugyanúgy, mint bármi mást, meg kell tervezni ütemezésben és erőforrásban, valamint el kell készíteni a kötelező dokumentumokat is.

Nézzük meg, miről is beszélünk. Kiindulási projektünk legyen az egyszerűség kedvéért egy szoftver fejlesztése, ahol lényeges szempont, hogy egyszerre nagyszámú felhasználót tudjon majd kiszolgálni. Mindezek után lássunk hozzá, derítsük ki, „milyen mély a nyúl ürege”, mit tud a fejlesztett alkalmazás, mennyire teljesíti a vevői igényeket, elvárásokat. 

És itt jön egy nagyon lényeges szempont: csak akkor tudunk jól és teljes körűen tesztelni, ha az igényspecifikáció is jó és az igénylő minden apró óhajára kihegyezett. Erről a gumicicámról, kicsi vesszőparipámról bővebben itt olvashattok: A Termékmenedzser és a Színes buborékok.

Ezek után lássuk a tesztek fő- és altípusait.

Első a fejlesztői vagy gyártói teszt, ezt azok a kollégák végzik el, akik a szoftvert készítik, rendszerint a saját fejlesztői környezetükön. Ehhez kiindulásként az igényspecifikációt használják, amely, mint egy korábbi bejegyzésemben írtam ( Money, money, money ) nem árt, ha a szerződés mellékletét képezi beszállító esetében. Ennél  a tesztelésnél a fejlesztők nagy vonalakban megnézik, hogy az igényspecifikációban leírt elvárásokat hogyan teljesíti az alkalmazás és addig javítják a kódot, amíg megfelelő nem lesz. Csak utána adják át a következő tesztelési fázisba.

Második a telepítési teszt, ahol a leendő üzemeltetők megnézik, hogy a fejlesztett alkalmazást hogyan tudják a teszt környezetben telepíteni, hogyan illeszkedik a környezet már meglévő többi eleméhez vagy alkalmazásához. Elindítható és használható, vagy ezen az új környezeten meg se nyikkan. Volt már rá példa. J Ehhez a teszthez az üzemeltetők általában a szoftverrel együtt átadott telepítési leírást használják.

Harmadik a felhasználói teszt, amely több altípust is magába foglal: felület, teljes folyamat és funkció teszt. Ezeket a teszteket általában azok végzik, akik az igényt is összeállították vagy nagyon jól ismerik. Lényeges, hogy külső gyártó, fejlesztő esetén előre, a szerződésben állapodjunk meg, hogy a talált hibákat hogyan és miben fogjuk nyilvántartani (ha a vállalatnál van tesztelést támogató hibakezelő rendszer, célszerű azt használni, ha nincs, akkor jó az excel is), a javításával szemben pl. milyen határidő elvárásaink vannak (ezt hívjuk céges környezetben SLA-nak). Ez azért fontos, mert ha ezeket nem fektettük le a szerződésben, akkor most, a tesztelés során nem lesz semmi a kezünkben, amely alapján a szállítón számon kérhetnénk a silány munkát. Főleg igaz ez azokra az esetekre, amikor az igényspecifikáció is elnagyolt. Ilyenkor egy adott hibán hetekig vitázhatunk, akkor sem jutunk dűlőre, szélsőséges esetben pedig perre vihetjük a dolgot ... Ehhez a teszteléshez már sokkal több dokumentumot használunk: az igényspecifikációt, az ebből készített tesztelési esetek leírását, a tesztelési tervet, a felhasználói kézikönyvet esetleg jogszabályt stb.

Negyedik nagy csoport  az üzemeltetési tesztek, amely szintén több altípust egyesít: ezek közül fenti példánkban nagyon fontos a terheléses teszt, hiszen az igény egyik sarkalatos pillére, hogy nagyszámú felhasználót tudjon egy időben kiszolgálni. A következő – amennyiben szükséges és van létjogosultsága – a biztonsági teszt és legvégül a jogosultsági teszt. Ezekhez az igényspecifikáció üzemeltetésre vonatkozó részét (például egyszerre 25 ezer felhasználó tudja használni) és az üzemeltetési kézikönyvet vagy leírást és az architektúra dokumentációt szoktuk alapul venni.

És mindebből mit profitálhatunk akkor, ha magánemberként vágjuk fejszénket kisebb-nagyobb beruházásokba? Amely, mint tudjuk, szintén projekt. J

• Láthattuk, hogy céges tesztelés esetében az igényleírásnak, tesztelési tervnek kiemelt jelentősége van, mert ezek a sorvezetőink. Magánemberként is bátran készíthetünk ilyet, előre írjuk össze, hogy milyen esztétikai, funkcionális és műszaki szempontok lényegesek számunkra a vásárlásnál, és ezeken szép sorjában menjünk végig.
• Másrészről, a szerződésben mindig térjünk ki a hibák kezelésére és a garanciális kötelezettségre. Tegyünk próbát vásárlás előtt vagy kérjük el a tesztelésre, a garanciára vonatkozó dokumentumokat, és ha bármilyen hibát észlelünk, merjük érvényesíteni jogainkat.