BBS-INFO Kiadó, 2016.

Minden jog fenntartva! A könyv vagy annak oldalainak másolása, sokszorosítása csak a szerző írásbeli hozzájárulásával történhet.

A könyv nagyobb mennyiségben megrendelhető a kiadónál:

BBS-INFO Kiadó, 1630 Bp. Pf. 21. Tel.: 407-17-07

A könyv megírásakor a szerző és a kiadó a lehető legnagyobb gondossággal járt el. Ennek ellenére, mint minden könyvben, ebben is előfordulhatnak hibák. Az ezen hibákból eredő esetleges károkért sem a szerző, sem a kiadó semmiféle felelősséggel nem tartozik, de a kiadó szívesen fogadja, ha ezen hibákra felhívják figyelmét.

Papírkönyv: ISBN 978-615-5477-31-7

E-book: ISBN 978-615-5477-32-4

Kiadja a BBS-INFO Kft.

1630 Budapest, Pf. 21.

Felelős kiadó: a BBS-INFO Kft. ügyvezetője

Előszó

A szerzőről

A szoftvertesztelés a kenyérkereső foglalkozásom, melyet nagyon komolyan veszek. Kis-, közép- és nagyvállalati környezetben is számos projektben vettem részt mint szoftvertesztelő, idehaza és külföldön is. ISTQB oklevéllel rendelkezem, veterán szoftvertesztelőnek számítok.

Egyfajta hackernek tekintem magam, a szó eredeti értelmében: rajongok a számítástechnikáért és nagy örömmel használom a kreativitásomat új dolgok létrehozására.

Egyetemista koromban kifejlesztettem egy vizuális fejlesztőrendszert két programozási nyelvhez, később pedig megalkottam saját térinformatikai rendszeremet, a ZEUSZ-t, amellyel a NASA-ig is eljutottam. Ezen a mai napig folyamatosan dolgozok.

Szívesen készítek ingyenes és nyílt forráskódú alkalmazásokat hagyományos, asztali számítógépes környezetre és mobileszközökre is. Ennek a munkának az egyik gyümölcse az a QuickTest tesztdokumentációs rendszer is, melyet elsősorban szemléltetési célokra fejlesztettem ki és ebben a könyvben is bemutatok.

Az Adobe Flash és az AIR technológia, valamint az Android operációs rendszer lelkes híve vagyok, nagyon kedvelem a C programozási nyelvet is. Ezekről a témákról eddig három könyvem jelent meg a hazai boltokban. Munkáimról bővebben a

http://feherkrisztian.magix.net/public

weboldalon is lehet olvasni.

A könyv célja

A könyv célja egy átfogó, de nem áttekinthetetlen kép kialakítása a professzionális szoftvertesztelésről, olyan ismeretanyag átadásával, mely biztos alapot nyújthat a szoftvertesztelésben elhelyezkedő leendő és gyakorló szakembereknek a mindennapi munkájukhoz. Mindezt azonban egyszerűen szeretném elérni: gyakorlatias ember vagyok, a kreatív gondolkodást többre tartom, mint szakkifejezések bemagolását és szajkózását.

A szoftvertesztelőkön óriási felelősség nyugszik és folyamatosan elvárások kereszttüzében kell helytállniuk. Mégis, szoftvertesztelés nélkül a legtöbb szoftver el sem jutna a felhasználókig, vagy ha igen, akkor megjelenésük botrányokkal, valamint óriási anyagi és erkölcsi veszteségekkel járna együtt, a rengeteg fel nem tárt programhiba miatt. Szoftvertesztelésre és tesztelőkre ezért igenis szükség van.

Könyvemben ezt a területet szeretném megismertetni a kedves Olvasóval.

A könyv felépítése

A könyv első része a szoftvertesztelés általános bemutatásáról szól, megteremtve ezzel az alapot az alapvető szakmai fogalmak bemutatásáig.

Ezt követi a könyv döntő részét képező törzs ismeretanyag, mely részleteiben tárgyalja a szoftvertesztelést és annak helyét a fejlesztési folyamatokban.

Végezetül pedig jó adag gyakorlati ismerettel vértezhetjük fel magunkat, melynek során valódi, a tesztelést támogató alkalmazást ismerhetünk meg.

A szoftverteszteléssel most ismerkedő szakembereknek és laikusoknak kimondottan hasznos lehet ez a könyv, de fejlesztők és cégvezetők számára is tartogat hasznos információkat, melyek segítségével bevezethetik, illetve hatékonyabbá tehetik a szoftvertesztelést munkájuk során.

Kellemes és hasznos időtöltést kívánok a könyv olvasásához!

Fehér Krisztián

1. Gondolatok a szoftvertesztelésről

A professzionális szoftvertesztelés hazánkban még fiatal szakterületnek számít.

Van, aki adottságai révén lesz jó szoftvertesztelő, van, aki kemény tanulás árán válik azzá.

De miért van szükség szoftvertesztelésre? Általában ez az első kérdés, amivel szembesül az ember, amikor ezzel a témával találkozik. Mi fán terem a szoftvertesztelés? Kik a szoftvertesztelők? Hogyan dolgoznak?

A könyv első fejezetében a fenti kérdésekre keressük a választ, megtéve az első lépést a szakterület megismerése felé.

Mi a szoftvertesztelés?

Ha egy mondatban kellene megválaszolnunk a fenti kérdést, ilyen választ adhatnánk rá: a szoftvertesztelés a szoftverfejlesztési folyamatot tervezetten kísérő, azzal szorosan összefüggő, ám annak önálló része, melynek célja a tesztelt szoftver minőségének feltárása.

Itt gyorsan álljunk is meg egy szóra. Mit értünk minőség alatt? A minőség a szoftverek esetében olyan tulajdonságok összegző leírása, ill. megnevezése, melyek a szoftvert jellemzik.

Fejlesztési projetekben minőségbiztosítás alatt olyan tevékenységeket értünk, melyek a fejlesztett szoftver tervezett minőségét igyekeznek biztosítani.

A szoftvertesztelés a minőségbiztosítási tevékenységek körébe tartozik.

A szoftverek tesztelését megtervező, végrehajtó és az eredményeket kiértékelő szakembert szoftvertesztelőnek, tesztmérnőknek nevezik (ez angolul tester, ill. test engineer).

Miért van egyáltalán szükség szoftvertesztelésre?

A fenti kérdést takarékossági szempontokra hivatkozva sajnos fejlesztőcégek, sőt nagyvállalatok is komolyan fel szokták tenni.

A szoftverek szervezett és irányított, képzett szakemberekkel történő tesztelése ugyanis pénzbe kerül, mely a fejlesztési projekt büdzséjének jelentős hányadát teheti ki, ezért a leggyakoribb ellenérv a teszteléssel szemben a tesztelés anyagi vonzata szokott lenni.

Nos, hogy valóban drága-e a szoftvertesztelés és valóban megéri-e, az viszonylagos.

Képzeljünk el egy nagyon is életszerű példát! Példánkban egy neves bank meglévő banki rendszerét egy teljesen újra kívánja lecserélni. A projekt tervezett ideje 6 hónap.

Mivel az új rendszer fejlesztését is házon belül, ugyanazok a fejlesztők végzik, akik a régi rendszert is készítették, a menedzsment úgy dönt, hogy nem alkalmaznak külön tesztelőcsapatot.

Az érvek a tesztelés ellen, a menedzsment logikája szerint:

- A jelenlegi fejlesztők készítették a korábbi rendszert, így ők ismerik azt a legjobban. Külön tesztelők bevonása felesleges időhúzással és kiadásokkal járna.

- A fejlesztők maguk is végeznek teszteket, így mi szükség van külön tesztelőkre?

- A tesztelők úgyis csak nagyon egyszerű dolgokat tudnak ellenőrizni, így emiatt is felesleges külön tesztelőcsapatot fenntartani.

Elkezdődik a fejlesztés.

Az első hónap végén kiderül, hogy a fejlesztők nem rendelkeztek elegendő információkkal az új szoftvert illetően és félreértelmeztek bizonyos üzleti követelményeket.

A menedzsment kapkod, igyekeznek elbagatellizálni a hibát. Hosszas és fáradtságos megbeszélések árán sikerül tisztázni a felmerült kérdéseket.

Közben a fejlesztők is idegesek, mert emiatt valószínűleg nem fogják tudni tartani a határidőt és mindenki szeme előtt a túlórák réme lebeg.

A folyamatos csúszások közepette a projekt félidőhöz érkezik. Az üzleti elemzők a szoftver első bemutatásakor olyan hiányosságokat fednek fel, melyekre addig senki sem gondolt.

A menedzsment tombol, mert már egyértelmű, hogy 6 hónap kevés lesz befejezni az új szoftver fejlesztését.

Néhány vezetőt lecserélnek. Újabb egyeztető megbeszélések és áttervezések sora veszi kezdetét.

A fejlesztők elkötelezettségének és emberfeletti túlórázásának köszönhetően 3 hónapos csúszással ugyan, de elérkezik az (első) elfogadási teszt ideje.

A menedzsment és a vezető fejlesztők elégedetten szemlélik az új szoftver általuk késznek hitt változatát. Azaz csak szemlélnék, mert pár perc után a rendszer összeomlik, a rendszer komponensei megszűnnek kommunikálni egymással.

Újabb megbeszélések veszik kezdetüket, melyek egy válságtanácskozásban csúcsosodnak ki. Megszületik a döntés: mivel már csillagászati összegeket öltek a fejlesztésbe, ezért ha törik, ha szakad, be kell fejezni azt, kerül, amibe kerül.

Újabb 3 hónap kemény munka, folyamatos túlórázás árán a fejlesztők befejezik a munkát.

Az eredetileg hat hónaposra tervezett projekt több mint egy év után véget ér, a szoftvert bevezetik és néhány katasztrofális leállástól eltekintve az éles rendszer – döcögve ugyan, de - megkezdi működését.

Mi lett volna, ha tesztelőket is alkalmaznak?

Ehhez nézzük meg tételesen a projekt elején a tesztelés ellen felhozott érveket:

1. A jelenlegi fejlesztők készítették a korábbi rendszert, így ők ismerik azt a legjobban. Külön tesztelők bevonása felesleges időhúzással és kiadásokkal járna.

A fejlesztők a projekt elején hiányos ismeretekkel rendelkeztek az új rendszer működését illetően, de ez csak hónapokkal később derült ki. A fejlesztés kezdeti fázisai ugyanis nem érintették az ide vonatkozó kérdéseket, ezért azok kidolgozását is későbbre időzítették.

Ha tesztelőket alkalmaznak, akkor a tesztelés vezetője legkésőbb már az első hét végén félreveri a vészharangokat, pontosabb rendszerterveket, leírásokat követelve.

2. A fejlesztők maguk is végeznek teszteket, így mi szükség van külön tesztelőkre?

Kiderült, hogy a fejlesztők sok eshetőségre nem is gondoltak. „Hiszen a mi gépeinken, így és így végrehajtva a folyamatot, minden működött...”

Mivel a tesztelők az üzemeltetők és nem utolsó sorban a leendő felhasználók szemszögéből is alaposan meg szokták vizsgálni a szoftvert, idejekorán olyan hibákat is felfedtek volna, melyek később kevesebb, vagy semmilyen többletmódosítást nem igényeltek volna a szoftveren.

Természetesen a programozók által elvégzett tesztelés is fontos (ezek elsősorban az ún. egység (unit) tesztek, melyek nincsenek könyvünk fókuszában), sőt elengedhetetlen része a fejlesztésnek és tesztelésnek. Viszont arányait tekintve csak egy apró részét képezi a teszteknek. Pusztán fejlesztői tesztek általában nem elegendőek a kívánt minőség elérésére.

3. A tesztelők úgyis csak nagyon egyszerű dolgokat tudnak ellenőrizni, így emiatt is felesleges külön tesztelőcsapatot fenntartani.

Felkészült tesztelők bizony benéztek volna a „motorháztető” alá is.

A fájdalmas tanulság az, hogy a jól szervezett tesztelés nemcsak, hogy segítette volna a határidők és a költségek kordában tartását, hanem vezető szerepet játszhatott volna a projekt sikeres lebonyolításában.

Így viszont jelentős többletmunkával, pénzzel és nem utolsó sorban rengeteg bögre feleslegesen elfogyasztott kávéval kellett megfizetni az eleinte „okosnak” gondolt spórolási ötletért, miszerint nincs szükség tesztelőkre.

A fenti példa fiktív, bármilyen hasonlóság valós fejlesztési projektekkel csak a véletlen műve...

Könnyen belátható, hogy egy pénzintézet üzleti életébe mekkora lyukat üthet egy hibásan működő szoftverrendszer. De ez még lehetne rosszabb is, gondoljunk csak egy atomerőmű működtetéséért felelős szoftverrendszerre...

Tesztelő szakemberek alkalmazásának van egy sokkal prózaibb oka is. Egyetlen programozó sem képes hideg tárgyilagossággal tesztelni a saját maga által készített szoftvert. Az ember már csak ilyen: saját hibáinkat nehezebben vesszük észre, mint a máséit.

Kik a szoftvertesztelők és hogyan dolgoznak?

A szoftvertesztelés szakma és hivatás, nem pedig egy „mellékesen” végzett tevékenység. (Előbbi megjegyzéssel minden öntudatos tesztelőt vérig sérthetünk.)

A tesztelés, mint szakma, tanulható. Szépsége abban áll, hogy művelője „jogosítványt” kap arra, hogy hibákat találjon és szabad átjárása van a projektek területei között.