Aki a szoftver piacon tevékenykedik, szoftverekkel foglalkozik, adott esetben programokat ír, bizonyára tudja milyen komplex és nehéz feladat a tesztelés. A tesztelésre ellenben sokszor úgy gondolnak cégek, hogy egy „szükséges rossz” dolog, amit valakinek végig kell csinálnia, végig kell kattintgatnia a rendszert és kész. A tesztelés egy nagyon fontos és felelősség teljes folyamat, ami a szoftverkészítés (ERP rendszertervezés) fontos és kiemelt eleme.

A programozó programokat ír, ezt mindenki tudja. A programozók is emberek így nyilván hibázhatnak. Természetesen a programozó alapfeladatai közé tartozik, hogy minimális tesztelésen ő maga vigye keresztül a saját programját, mielőtt egy másik munkafázisnak átadná, ez a másik munkafázis a tesztelés. A fejlesztő mindig valamilyen leírás, igényterv, specifikáció (brief) alapján dolgozik, így folyamatosan vizsgálja, figyeli, hogy az általa írt program megfelel-e az elvárásoknak. Amikor végez a fejlesztéssel, megtörténik a készre jelentés és kezdődik a tesztelési munka.

Milyen alapelveket kell figyelembe venni teszteléskor?

• A specifikáció, a brief az irányadó. Fontos, hogy a tesztelő tisztában legyen azzal, hogy mi volt az ügyfél, a megrendelő elvárása a szoftvertől.
• Meg kell találni az eltéréseket a specifikáció és a késztermék között. Ezek az eltérések lehetnek funkcionális eltérések, azaz valami nem úgy működik, ahogy meg lett rendelve, illetve tényszerű hibák, hibaüzenetek is.
• Figyelembe kell venni, hogy milyen mértékű tesztelés hajtható végre. Valószínűleg 100%-os tesztelés soha nem hajtható végre, de törekedni kell a minél nagyobb arányú lefedettség elérésére, a lehető legtöbb szcenárió tesztelésére.
• A tesztelés célja, hogy növeljük a rendszer megbízhatóságát.
• A tesztelés teljes folyamatáról dokumentációt kell készíteni, tesztnapló formájában.

Most vizsgáljuk meg, hogy mit mond az ITIL a szoftvertesztelésről. Az ITIL-ben a szoftvert tesztelés és értékelés fázis a SERVICE TRANSITION, azaz a Szolgáltatás Bevezetés szakasz rész, azon belül a Service validation and testing részben található információ róla.

Egy szolgáltatás (rendszer) tesztelésének a célja, hogy az IT szolgáltatás rendelkezésre állása a lehető legmagasabb legyen. A tesztelés célja, hogy az új vagy egy megváltoztatott (továbbfejlesztett) funckió, szolgáltatás megfeleljen a megrendelő elvárásainak (megrendelő céljainak) valamint megfeleljen a mindennapi használatnak, azaz a szolgáltatás folyamatos legyen, legyen mindig megfelelő kapacitás és biztonságos is legyen. Ezt a két tényezőt szokták "fit for purpose" és "fit for usage" néven is emlegetni. Az egész tesztelési folyamatnak a célja, hogy értéket szolgáltassunk az ügyfélnek az ő tevékenységének, üzletének ellátásához.

Ezek alapján a tesztelés tárgya, céljai:

• Az új program, szoftver (release) megfeleljen az ügyfél elvárásainak (sponsor, stakeholder).
• Fit for purpose és fit for usage.

Milyen tesztelési típusokról beszélhetünk?

• Service requirements testing: A szolgáltatás vagy termék (szoftver) igény specifikációjának történő megfelelés tesztelése, ez az ún. "fit for purpose", azaz megfelel-e az elkészült szolgáltatás vagy termék az elvárásoknak.
• Service level testing: Teszteléskor az is fontos, hogy az elkészült termék vagy szolgáltatás az elvárt szolgáltatási szintnek (SLA) megfelel-e vagy sem.
• Service assurance testing: Itt lényegében a "fit for usage" feltételnek történő megfelelés tesztelése történik.
• Usability testing: Működik-e, nincs-e hibaüzenet. Felhasználó barát-e, használható-e egyáltalán.
• Contract and regulation testing: Fontos, hogy a teszteléskor arra is figyelemmel kell lenni, hogy az elkészült szolgáltatás vagy termék megfelel-e a törvényi előírásoknak, különböző vállalt minőségbiztosítási szabványoknak (ISO).
• Service management testing: Az elkészült szolgáltatás vagy termék megfelel-e vajon a felsővezetés igényeinek, a belső szabályzatoknak?
• Operational testing: Különböző működési teszteket lehet végrehajtani, stresszteszteket (egyszerre sok felhasználót ráengedünk a szolgáltatásra vagy termékre, szerencsére ez elég könnyen modellezhető). De idetartoznak a különböző hardver, kliens és hálózati tesztelések is.
• Regression testing: Fontos, hogy egy új vagy újabb szolgáltatásnak tudnia kell a korábbi funkciókat, ezért egy korábbi verzióra futtatott teszteknek is működniük kell az új fejlesztésben.

Minden vállalkozásnak, informatikai szolgáltatást nyújtónak, terméket gyártó cégnek ki kell alakítani a saját tesztelési stratégiáját, azaz mi a tesztelés menete, célja, milyen erőforrások szükségesek ahhoz, mik az elvárt eredmények, stb. Valamint ki kell választani a stratégiának megfelelő tesztelési modellt is. Az informatikában az egyik legismertebb és legelterjettebb az ún. V-modell.

Kép forrása: Wikipedia

A V-modell lényege, hogy a szoftver tervezés, bevezetés és tesztelés folyamata egy V betűt formáz. Az idővonal balról jobbra halad, az igényfelmérés, tervezés szakasz a V betű bal oldali szára, a V betű alsó része maga a bevezetés, a V betű jobb oldali szára pedig a tesztelési, élesítési szakasz.

Befejezésül néhány szó a tesztelési dokumentáció fontosságáról, a tesztnaplóról. Nyilvánvaló, hogy a tesztelési folyamatot is dokumentálni kell. A tesztelési dokumentáció általam javasolt részei:

• Mit fogunk tesztelni.
• Hogyan fogjuk tesztelni.
• Pontosan mi történik a rendszer használata közben.
• Milyen eltéréseket tapasztalunk a specifikációhoz képest (negatív és pozitív).
• Az eltérések esetleges értékelésére is ki kell térni, a negatívumokére mindenképpen.

És egy érdekesség a legvégére. A tesztelési folyamat során észlelt első hiba (BUG) egy valódi bogár (angolul bug) miatt történt. 1947 szeptember 9.-én Grace Hopper és csapata egy bogarat talált a Mark II-es F panelének 70-es reléjében. Ez volt az első dokumentált hiba, és innen kapta a rendszerhiba a nevét, ezért hívjuk BUG-nak.

Kép forrása: Internet