Néhány gondolat a szoftvertesztelésről

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.

1.pngKé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.

2.jpg

Kép forrása: Internet

A bejegyzés trackback címe:

https://erp-blog.blog.hu/api/trackback/id/tr174896620

Kommentek:

A hozzászólások a vonatkozó jogszabályok  értelmében felhasználói tartalomnak minősülnek, értük a szolgáltatás technikai  üzemeltetője semmilyen felelősséget nem vállal, azokat nem ellenőrzi. Kifogás esetén forduljon a blog szerkesztőjéhez. Részletek a  Felhasználási feltételekben és az adatvédelmi tájékoztatóban.

Nincsenek hozzászólások.
süti beállítások módosítása