Vállalatirányításról közvetlenül - érthetően
Facebook
Linked In
Rss

Giller Tamás

COM_6565+800.jpg

Forrás: Computerworld

Fotó: Rózsa Zsuzsanna

Giller Tamás

Több, mint 10 éves szakmai tapasztalat informatikai szolgáltatások területén: ERP, CRM, egyéb vállalati szoftverek bevezetése, tanácsadása, üzemeltetése.

Pénzügyi, üzleti és informatikai tudás!

Projektmenedzsment tapasztalat, NAV, ITIL szakvizsga!

Több mint 5 év vezetői tapasztalat (CFO, IT/IS).

A Piac & Profit valamint a Computerworld szakértő partnere.

ERP - múlt, jelen, jövő

csak-könyv_2.png

ERP - past, present, future

angol_könyv_reklám.png

A könyvemről

Kulcsár Tibor (Kulcs-Soft alapítója):

"Gratulálok a könyvedhez Tamás, nagyon jó volt! Még nem olvastam olyan könyvet az ERP-ről, amely ennyire szakszerű és olvasható lenne egyben. Annyira tetszik, hogy szeretném tananyaggá tenni a Kulcs-Soft-ban. Szeretnék 20 példányt rendelni belőle a kollégáim részére."

Hetyei József (Certified Management Consultant):

"A könyv stílusa kellemes, olvasmányos, jól érthető. A könyvben összefoglalt tapasztalatok hasznosak lehetnek mind az ERP rendszereket bevezető kkv-k, mind a számukra ilyen rendszereket szállító, azokat (bevezetés során és az után) támogató vállalatok számára."

Hoffer István (abas Magyarország ügyvezetője):

"A könyv második része, amely az ERP kiválasztásról és a bevezetéshez kapcsolódó projektről ad információkat, abszolút hiánypótló a magyar piacon. Én nagyon vártam már egy ilyen kiadványra."

Juhász Zsolt (rEVOLUTION Software Kft. ügyvezetője):

„Érdekes, olvasmányos, sok helyen visszaköszönnek az általam is hangoztatott gondolatok. A könyv végén nekem egy picit sok lett a kiegészítő téma, ez egy picit elviszi a fő téma súlyát. De örülök, hogy a könyv az ERP kérdés teljes szélességét felvállalja.”

Támogathatsz

Ha szeretnéd támogatni az ERPBLOG működését, akkor most megteheted.

Köszönöm, hogy támogattál!

Facebook

www.erpblog.hu

A nevem Giller Tamás. 2003 óta foglalkozom Informatikai Szolgáltatásokkal (ERP és CRM rendszerekkel). 2003 év elején közgazdászként diplomáztam a Pénzügyi és Számviteli Főiskolán majd a Summit Autó Magyarország ZRt.-nél - a Summit Solutions nevű üzletágnál - kezdtem dolgozni, saját fejlesztésű vállalatirányítási rendszerekkel. Két év után 2004 év végétől kezdve közel 1 évet töltöttem Ausztráliában, ahol pénzügy menedzsmentet hallgattam. 2005-től projektvezető lettem a Summit Autó Magyarországnál. 2006-tól a Karádi Rendszerháznál dolgoztam Microsoft vállalati termékekkel (Navision, CRM). 2008 és 2015 között a DLM Solutions Kft. üzletágvezetője voltam. Azóta pedig egy mezőgazdasági informatikával foglalkozó startup (Gremon Systems Zrt.) pénzügyi igazgatója vagyok. Szeretném megosztani veletek azokat a tapasztalataimat, amelyeket az informatika ezen speciális világában töltöttem, az elmúlt több mint 10 év során. Remélem a témák érdekesek lesznek és egy jó kis szakmai műhely alakul ki!

ITIL

 

Microsoft Business Solutions Specialist

specialist.png

Elérhetőség

Ha kapcsolatba szeretnél velem lépni, mert véleményed van, meg akarsz osztani velem valamit, segítségre van szükséged, vagy van egy jó ajánlatod számomra, akkor ne habozz, írj nekem!

tamas.giller@gmail.com

Search Clear

Friss topikok

Kiemelt partnerek

PP.jpg

Computerworld.gif

Partnerek

Bridge.pngdlm_1.pngk2d.png

xapt.pngkaradi_1.pngdyntell.png

kulcs.png 

ggx.png

abas.png  

2_2.png

 

  

KRONOS.jpg

 

 

weblogo.png

  

  

uj_SAP_logo.jpg

 

SymbolTechLogoNEW_240x240.png

 

llp_logo_standardcolour_clear_background.png

 

      UNIT4_logo_VT-SOFT.png

 

ifs_logo_180.png

 

TRL_logo_cegnevvel2.png

 

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

2012.11.08. 09:51

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

Szólj hozzá!

Címkék: design informatika rendszer dokumentáció erp itil

A bejegyzés trackback címe:

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

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.