tanulas_manualis_szoftvertesztelesi_alapismeretek
Fehér Krisztián: Manuális szoftvertesztelési alapismeretek
Tartalomjegyzék
1. Gondolatok a szoftvertesztelésről
1.1. Mi a szoftvertesztelés?
1.2. Miért van egyáltalán szükség szoftvertesztelésre?
1.3. Kik a szoftvertesztelők és hogyan dolgoznak?
1.4. A tesztelés célja
1.5. A tesztelés emberi vonatkozásai
1.6. A tesztelés anyagi előnyei
2. A tesztelés alapfogalmai
2.1. A hiba fogalma
2.2. Teszt
2.3. Tesztkörnyezet
2.4. Üzleti követelmény (business requirement)
2.5. Felhasználási folyamatleírások (user story)
2.6. Teszt szcenárió (test scenario)
2.7. Teszteset (test case)
2.8. Tesztlépés (test step)
2.9. Felülvizsgálat, review
2.10. Teszt státusz
2.11. Tesztlépések megfogalmazása
2.12. Negatív tesztesetek
2.13. A tesztelési folyamat főbb állomásai
2.13.1. A tesztek megtervezése
2.13.2. Teszt tervezés sprintekben
2.13.3. A tesztelemzés
2.13.4. Tesztdizájn, előkészítés
2.13.5. Tesztvégrehajtás
2.13.6. Tesztkiértékelés
2.13.7. Tesztelést támogató tevékenységek
3. Tesztelési technikák
3.1. Statikus tesztelési technikák
3.2. Dinamikus tesztelési technikák
3.2.1. Fekete doboz tesztelés
3.2.2. Fehér doboz tesztelés
3.2.3. Szürke-doboz tesztelés
3.2.4. Felfedezéses tesztelés
3.3. Tesztvégrehajtás fajtái
3.3.1. Manuális tesztelés
3.3.2. Automata tesztelés
4. Tesztek osztályozása
4.1. Fejlesztési modellek
4.1.1. A V-modell
4.1.2. Agilis fejlesztés
4.1.3. A SCRUM
4.2. Tesztszintek
4.2.1. Komponensteszt
4.2.2. Integrációs teszt
4.2.3. Rendszerteszt
4.2.4. Elfogadási teszt
4.3. Teszttípusok
4.3.1. Funkcionális teszt
4.3.2. Nem-funkcionális teszt
4.3.3. Regressziós teszt
5. Tesztprojektek
5.1. A tesztprojekt szerepkörei
5.1.1. Tesztmenedzser
5.1.2. Projektkoordinátor
5.1.3. Üzleti elemző
5.1.4. Tesztkoordinátor, tesztvezető
5.1.5. Tesztelő
5.2. A tesztprojekt fázisai
5.2.1. Tervezés, becslés
5.2.2. Projektindító (kick-off) meeting
5.2.3. Teszt dizájn
5.2.4. Tesztvégrehajtás
5.2.5. Ellenőrzés, monitorozás
5.2.6. Jelentéskészítés
6. Tesztkiértékelés
6.1. Hibák dokumentálása
6.1.1. A hiba elnevezése
6.1.2. Hibaleírás
6.1.3. Fontosság (prioritás) és súlyosság
6.1.4. Érvényesség
6.1.5. Hozzárendelés meghatározása
6.1.6. Egyéb tulajdonságok
6.2. Teszteredmények kiértékelése
7. Tesztelés a gyakorlatban
7.1. A szoftvertesztelés napi gyakorlata
7.2. Hogyan teszteljünk például porszívót?
7.3. Gyakorlati példa: webes felhasználói azonosítás tesztelése
7.3.1. A feladat
7.3.2. A tervezés
7.3.3. Jóváhagyás
7.3.4. Kivitelezés
7.3.5. A tesztek „utóélete”
7.3.6. A kreatív tesztesetekről
7.4. Szoftvertesztelés Magyarországon és a nagyvilágban
7.5. Tesztelés különböző platformokon
7.5.1. Tesztelés asztali számítógépeken
7.5.2. Tesztelés nagygépes környezetben
7.5.3. Tesztelés mobileszközökön
7.6. Pár szó az XML formátumról
7.7. Tesztelést támogató szoftverek a gyakorlatban
7.7.1. Tesztelés a Quickteszt segítségével
7.7.2. SOAP UI
7.7.3. SOAP UI projekt létrehozása
7.7.4. A projekt finomhangolása
7.7.5. Teszthívás létrehozása a projektben
7.7.6. Teszteset létrehozása és végrehajtása
7.7.7. Teszt futtatása
7.7.8. Hívások kézi módosítása
7.7.9. Teszeteredmények kiértékelése
7.7.10. JIRA
7.7.11. További szoftverek
7.8. Dokumentációs minták
7.8.1. Tesztesetek megfogalmazása
7.8.2. Teszteredmények dokumentálása
8. Minőségbiztosítási receptek
8.1. A tesztelés hiánya
8.2. A teszt tervezésének elmaradása
8.3. Tesztelés és fejlesztés különválasztása
8.4. Tesztmenedzsment hiánya
8.5. Tesztcélok hiánya
8.6. Dedikált tesztkörnyezet hiánya
8.7. Tesztadatok hiánya
8.8. Dokumentáció hiánya
8.9. Fejlesztések dokumentálásának hiánya
8.10. Manuális és funkcionális tesztelés különválasztása
8.11. Tesztesetek nem megfelelő dokumentálása
8.12. Teszteredmények dokumentálásának hiánya
8.13. Teszteredmények kiértékelése hiányzik
8.14. Feladatok delegálása
9. Tesztelői kisszótár
1 Előszó
Ez a leírás egy régebbi írásom alapján lett elkészítve, időközben sokat változott a világ, elsősorban a teszteszközök fejlődését emelném ki. Ennek megfelelően tessék olvasni!
A leírás célja
A leírás 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.
Leírásomban ezt a területet szeretném megismertet-ni a kedves Olvasóval.
A leírás felépítése
A leírás első része a szoftvertesztelés általános be-mutatásáról szól, megteremtve ezzel az alapot az alap-vető szakmai fogalmak bemutatásáig.
Ezt követi a leírás 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 leírás , 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 leírás olvasásához!
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 leírás 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é.
1.1. 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 projektekben 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).
1.2. 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 szak-emberekkel 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 rend-szert, így ők ismerik azt a legjobban. Külön tesz-telő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ál-ni 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 rend-szert, í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öve-telve.
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 a leírás fókuszában), sőt el-engedhetetlen 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 tesz-telő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.
1.3. 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.
A közhiedelemmel ellentétben a tesztelési folyamat nem ad hoc jellegű, hasraütés-szerűen kitalált tevékenységek végrehajtását jelenti. A szoftvertesztelés egy jól irányított, tervezett, dokumentált, ezáltal követhető és kiértékelhető folyamat, mely számadatokkal alátámasztva képes kijelentéseket megfogalmazni egy szoftver minőségéről.
A tesztelés tervezett végrehajtása megkerülhetetlen elvárás bizonyos típusú rendszerekkel szemben.
A tesztek végrehajtása sok esetben a szoftverek futtatásával kapcsolatos, de ez nem a kizárólagos módja a tesztelésnek.
A tesztelés - ideális esetben - valójában már akkor elkezdődik, mielőtt a programozók az első sor programkódot megírták volna. A tesztelőknek a rendelkezésre álló dokumentumok (szoftverspecifikációk, tervek) alapján már jóval a tesztek végrehajtása előtt el kell készíteniük a tesztjeik tervét, meg kell határozniuk a tesztek elvárt eredményeit, fel kell tudniuk mérni, hogy a szoftver egyáltalán tesztelhető-e a tervezett módon, eszközökkel, stb.
A fenti tesztelést ún. statikus tesztelésnek nevezzük. Statikus teszteléssel már azelőtt ki lehet iktatni egy potenciális hibát, mielőtt az egyáltalán megjelenne a szoftverben.
A szoftverek futtatásán alapuló tesztelést nevezzük dinamikus tesztelésnek.
A tesztelés a szoftver elkészültével sem ér véget, hanem végigkíséri annak teljes életciklusát. A teszt eredményeit későbbi, hasonló tesztek végrehajtásához hasznos és ajánlott felhasználni, az alkalmazott folyamatokat pedig mindig finomítani kell.
1.4. A tesztelés célja
A szoftvertesztelés egyik célja a hibák bekövetkeztének csökkentése, vagy kiküszöbölése.
Másik célja olyan információk előállítása, melyek alapján kijelentéseket lehet megfogalmazni a szoftver minőségéről és döntéseket lehet hozni.
Ennek a célnak az elérése sok tényezőtől függ, melyek a megrendelő igényeitől kezdve a rendelkezésre álló büdzséig terjedhetnek.
Képes-e a tesztelés megállapítani, hogy hibák nem fordulnak elő a szoftverben? A válasz: nem. Egy sikeres teszt nem jelenti automatikusan (valójában sohasem jelenti) azt, hogy a teszt tárgya, a szoftver, hibamentes. A teszteléssel mindössze a hibák előfordulásának a valószínűségéről tudunk kijelentéseket tenni.
Ennek egyenes következménye, hogy száz százalékos tesztelés nem létezik. Gondoljunk csak bele: lehetséges lenne-e például egy szövegszerkesztő alkalmazást minden elképzelhető felhasználási módot figyelembe véve letesztelni? Aligha...
Ha ez így van, akkor mi értelme egyáltalán az egésznek? Nos, azért ne essünk át a ló túloldalára sem! A tesztelő kezében van egy csodafegyver, amit priorizálásnak, azaz fontossági sorrend meghatározásának neveznek.
Igenis jól körülhatárolható ugyanis azon tesztek, ill. tesztfeltételek köre, melyek végrehajtásával a hibák előfordulásának esélyéről nagyságrendekkel biztosabb kijelentéseket tudunk megfogalmazni, mint nélkülük.
A priorizálás egyik veszélye, hogy rutinszerű, elcsépelt tesztvégrehajtások ismétlődéséhez vezethet, melyek idővel már nem képesek olyan, új hibákat felfedni, melyek idő közben alattomosan elburjánzottak a szoftverben és köszönik szépen, jól vannak.
Időről-időre ezért bizonyos mértékű változtatásokat kell eszközölni a teszteken.
1.5. A tesztelés emberi vonatkozásai
A szoftvertesztelők alapvetően türelmes, kíváncsi természetű, jó tanulási képeséggel és empátiával rendelkező emberek.
Mivel a tesztelés nem öncélú dolog, hanem kooperatív tevékenység, ezért egy tesztelőnek kiváló kommunikációs képességekkel kell rendelkeznie. Világosan tudnia kell kommunikálnia tevékenysége szakmai célját is, na és persze azt, hogy mit akar.
A tárgyilagos, szakmai érveket felvonultató tesztelőket mindenhol szeretik, a kukacosakat nem.
Induló projektekben, ahol a szereplők nem ismerik korábbról egymást, a tesztelők tevékenységét általában bizalmatlanság lengi körül a fejlesztők részéről, ami a projekt végére közvetlen, gördülékenyen működő közös munkává alakulhat.
1.6. A tesztelés anyagi előnyei
A tesztelést sok cégvezető felesleges, járulékos költségként fogja fel, amivel a minőséget csak kis mértékben lehet növelni. Ennek oka lehet szakmai hozzánemértés, a tesztelés nem szakszerű alkalmazása, vagy mindkettő.
A teszteléssel valójában jelentős költségeket lehet megtakarítani. Ennek egyik feltétele, hogy a tesztelést a projekt minél korábbi fázisában alkalmazzák, lehetőleg már a projekt előzetes tervezésekor. A tesztmenedzser például olyan tényezőkre világíthat rá, melyek felett egyébként elsiklana a projekt résztvevőinek figyelme és csak később, jelentős költségek árán lehetne korrigálni azt. Ez nem elmélet, hanem – sajnos – a mindennapok tapasztalata. A legtöbb cég ugyanis tesztelők nélkül indítja el a fejlesztési munkákat és már csak akkor kezd el(!) tesztelőket alkalmazni (és persze csodát várni ettől), amikor már nagy baj van a szoftverminőséggel.
Ilyenkor középtávon is már csak tompítani lehet a károkat és csak jelentős befektetésekkel, valamint időráfordítással lehet kihúzni egy terméket a hibák mocsarából.
Van egy elmélet, amely szerint a minőség, idő és a költségek egymással szoros összefüggésben állnak. Ezt egy háromszöggel szokták ábrázolni és gyakran a suszter cégérének példájaként emlegetik:
„Mi jól, olcsón és gyorsan dolgozunk. Ön ezekből kettőt választhat.”
Az elmélet kimondja, hogy egyszerre csak két dolgot lehet megvalósítani a háromból.
Háromféle variáció lehetséges:
1. Gyorsan jó minőséget csak drágán lehet előállítani.
2. Jó minőséget olcsón csak sok idő alatt lehet elérni.
3. Gyors és olcsó munkával csak rossz minőségű eredményt lehet elérni.
Ezek a törvényszerűségek tökéletesen igazak a szoftvertesztelésre is. Nagy kár, hogy kevesen alkalmazzák…
Ez a leírás azonban ennek ellenkezőjére bátorít mindenkit. Legyünk szemfülesek és ne hagyjuk félrevezetni magunkat! Bontsuk ki hát a szakma zászlaját!
Előtte azonban nem árt megismerkedni néhány alapfogalommal.
2. A tesztelés alapfogalmai
A szoftvertesztelés alapfogalmai alapvetően angol fogalmak, így magyarításuk nehezen, vagy nem lehetséges.
Ennek figyelembevételével ismertetjük a szoftvertesztelés alapvető fogalmait.
2.1. A hiba fogalma
Miért tartalmazhatnak a szoftverek hibákat? A válasz egyszerű: mert emberek készítik őket. Az ember pedig esendő és semmiképpen sem tévedhetetlen. (Valójában a számítógépek sem azok, de szeretjük azt hinni, hogy tévedhetetlenek.)
Ismerjük meg a hibák különböző fogalmait!
Hibázás (error, mistake): ez a hibafogalom egy hibajelenség létrehozásának, létrejöttének a folyamatát takarja.
Hiba (defect, fault, bug): konkrét, kimutatható hibajelenség. A tesztelés elsődleges célja a hibák megtalálása és dokumentálása.
Hibás működés (failure): a hibajelenségből eredő, az elvárttól eltérő működés, melyet nem emberi tényezők is okozhatnak (például, amikor áramszünet miatt leállnak szerverek).
Az ún. debugging során a programozó felügyelt módban képes futtatni a szoftverét és képes a szoftver alkotóelemeinek ellenőrzésére. Tesztelésnek számít-e ez a fajta hibakeresés? A válasz egyértelműen: nem. A debugging a fejlesztési munkafolyamat fontos része, mely a forráskód megírását és a futtatható szoftver létrehozását, valamint javítását segíti. A tesztelő azonban nem így dolgozik.
2.2. Teszt
A tesztelés az a tevékenység, melynek során - előre meghatározott feltételek teljesülése esetén - a teszt tárgyát képező szoftver adott tulajdonságát szintén előre meghatározott ismérvek és feltételrendszerek alapján megvizsgáljuk, elemezzük, dokumentáljuk és összefoglaljuk. A teszttevékenység végrehajtását tesztvégrehajtásnak, tesztfuttatásnak (test run) nevezzük.
2.3. Tesztkörnyezet
A tesztkörnyezet egy olyan informatikai infrastruktúra, mely a leendő, vagy már meglévő éles rendszerinfrastruktúrát modellezi, ill. a felhasználás körülményeit képes szimulálni.
Tesztkörnyezet állhat egyetlen számítógépből, de akár több kontinensen szétszórt, hatalmas számítógépközpontokból is.
Ideális esetben a tesztkörnyezet tulajdonságai megegyeznek az éles környezetével. A költségek kímélése végett a valóságban az éles rendszer paramétereihez közeli tesztkörnyezeteket szoktak létrehozni. Ez általában elegendő is szokott lenni.
Éles rendszert tesztelésre használni az esetek túlnyomó részében tilos!
2.4. Üzleti követelmény (business requirement)
Az üzleti követelményeket nem a tesztelők állítják fel, hanem az üzleti részleg felelősei. Egy tesztprojektben kell lennie egy üzleti elemzőnek, akinek az is feladata, hogy az üzleti oldal igényeit ún. üzleti folyamatokra bontsa.
Ilyen üzleti folyamat lehet egy banki szoftver esetében például egy ügyfél hitelkérelmének elfogadása.
Az üzleti követelmények soha nem technikai leírások, hanem folyamatleírások.
2.5. Felhasználási folyamatleírások (user story)
Ezen leírások részletessége változó, de gyakran hasonlóak a tesztesetek tesztlépéseinek leírásához (lásd lentebb).
Megfogalmaznak feltételeket, tevékenységeket és ún. elvárt eredményeket.
2.6. Teszt szcenárió (test scenario)
A teszt szcenáriók az üzleti követelményekből levezetett összefoglaló leírások.
Itt jegyezzük meg, hogy a teszt szcenárió, felhasználási eset és üzleti követelmény a gyakorlatban nem feltétlenül különálló leírásokat jelent. Erre egységesen alkalmazott rendszer a gyakorlatban nincsen, projektenként változhat a megvalósításuk.
2.7. Teszteset (test case)
A tesztesetek a tesztvégrehajtás során elvégzendő, logikailag összetartozó teszttevékenységek összességét jelentik.
A teszteseteket különböző névkonvenciók alapján nevekkel szokás ellátni, melyek utalnak a teszt tárgyára.
Például: Test_#1_Új_ügyfél_felvétele
2.8. Tesztlépés (test step)
A tesztesetek egyes elemi tevékenységeit tesztlépésnek nevezzük.
Nagyon fontos, hogy a tesztlépés valóban elemi tevékenységek leírása legyen, azaz további lépésekre ne legyen bontható.
Ennek nagyon egyszerű oka van. Ha az adott tesztlépés több elemi lépést is tartalmazna és hibát találunk, a hiba visszakeresését és visszakövethetőségét nagymértékben rontaná, ha nem egyetlen elemi lépést, hanem lépések halmazát kellene ismét megvizsgálnia a tesztelőnek, vagy a hiba javítását végző fejlesztőnek.
Az elemi tesztlépések belső szerkezetüket tekintve további egységekre bonthatóak, melyek maguk is leírások.
A két legfontosabb egység:
• Magának a végrehajtandó tevékenységnek a leírása.
• Az ún. elvárt eredmény megfogalmazása. Az elvárt eredmény annak a leírása, hogy mi történik akkor, ha a tesztlépés végrehajtása sikeres volt, tehát nem lépett fel hiba.
A tesztlépések tartalmazhatnak további információkat is:
• Tesztadatok megadása.
• További megjegyzések a teszt végrehajtásához.
Fontos tudni, hogy egyes projektekben a folyamatok hangsúlyosabbak, másokban a tesztadatok, ill. a konkrét teszteredmények állnak középpontban.
2.9. Felülvizsgálat, review
A review angol szakkifejezés és felülvizsgálatot jelent. A programozás során is használt módszer segítségével növelhető a tesztesetek minősége.
A review során a tesztelő az általa elkészített tesztesetet átadja egy társának, aki leellenőrzi, hogy a teszteset valóban megfelel-e minden követelménynek és minden szükséges információt tartalmaz-e.
A módszer hatékonyan alkalmazható hasonló és eltérő tapasztalattal rendelkező tesztelőknél is. A gyakorlati kivitelezése lehet informális, de akár erősen formalizált, írásban rögíztett is.
A felülvizsgálat végén a teszteset eredeti készítője megkapja mindazon hiányosságok listáját, melyeket még be kell építenie a tesztesetbe.
Egy teszteset elviekben csak review után használható éles tesztelésre.
2.10. Teszt státusz
A tesztek státusza egy fogalom, elnevezés, mely röviden összefoglalja és megadja az adott tesztesethez tartozó teszt aktuális állapotát.
Néhány példa tesztek státuszaira:
• Előkészületben (In preparation)
• Végrehajtható (Ready)
• Folyamatban (In Progress)
• Blokkolt (Blocked)
• Hibás tesztfuttatás (Failed)
• Sikeres tesztfuttatás (Passed)
• Nem végrehajtható (Not executable)
• Nem alkalmazható (Not applicable)
A státuszok száma és elnevezése erősen projektfüggő. A státuszok sorrendjét szokás és ajánlatos előre meghatározni is, ez segíthet nagyszámú hibajelentés feldolgozásában. Folyamatábrával áttekinthető, hogy egyik státusz után milyen másik következik.
Íme egy példa egy ilyen folyamatábrára.
2.11. Tesztlépések megfogalmazása
A tesztlépések megfogalmazása több szempontból is fontos.
A tesztlépéseket nagy valószínűséggel a szoftver megrendelője és a fejlesztők is megtekinthetik.
Másrészt előfordulhat, hogy a tesztet nem csak hivatásos tesztelők, hanem más részlegek képviselői, menedzserek, vagy akár laikusok fogják végrehajtani.
Éppen ezért a következő ökölszabályokat kell figyelembe venni tesztlépések megfogalmazásakor (hibaleírásokra ez egyébként ugyanúgy érvényes, de erre még visszatérünk):
• Rövid, tömör, lehetőleg egymondatos megfogalmazásokat használjunk! A tesztlépés nem kisregény. Adott esetben több száz teszteset több ezer tesztlépését végre kell hajtani, ezért törekedjünk a lényeg leírására.
Például:
„Kattintson a ’Befejez’ feliratú gombra!”
• Soha ne használjunk feltételes módot! Helytelen az alábbi megfogalmazás:
„A ’Befejez’ feliratú gombra kellene kattintani.”
Ugyanez fokozottan igaz az elvárt eredmények megfogalmazásakor is. Negatív példa:
„Az ablaknak be kellene záródnia”.
A feltételes mód nem csupán elbizonytalanítja a leírás végrehajtását, hanem egyesen a leírás ellenkezőjét sugallja! Helyesen ez így hangzik:
„Az ablak bezáródik.”
Sőt akár múlt időben is: „Az ablak bezáródott.”
Mindig használjunk tehát felszólító, ill. kijelentő módot!
• Kerüljük a „veszélyes” szavakat és kifejezéseket. Ezek olyan kifejezések, melyek bizonytalan érzést keltenek és technikailag, szakmailag is pontatlanok. Ilyen szavak és kifejezések lehetnek:
o „Probléma”: Probléma az, ha valaki lekési a buszt, vagy gorombáskodik. A tesztelő nem problémákat keres, hanem hibákat! Soha ne használjuk a „probléma” szót tesztlépésekben, hibaleírásokban! Sőt, lehetőleg sehol sem…
o Valami „működik”: Nem elég egyértelmű, mert nem lehet kihámozni belőle, hogy mi, hogyan működik. Nincsenek részletek, támpontok.
o Valami „nem működik”: Ugyanaz, mint fentebb. Mi nem működik és hogyan?
o „Lásd itt és itt”: Ritka kivételektől eltekintve ne hivatkozzunk a tesztesetből „kifelé”! Az ilyen hivatkozások keresgélése feleslegesen lassíthatja a tesztelés menetét és a hivatkozások elévülésének a veszélye is fennáll.
o „Akárcsak itt és itt”: A fentihez hasonló áthivatkozási hiba, akár egy teszteseten belül is, mondjuk egy másik tesztlépésre.
2.12. Negatív tesztesetek
Átfogó tesztelés során nem csupán valaminek a sikerességét kell ellenőrizni, hanem a szoftver hibatűrését is.
Ilyenkor a tesztelő kifejezetten „kiprovokálja” a szoftver reakcióját a hibára.
Ezeket a teszteseteket nevezzük negatív célzatú teszteseteknek. Tipikusan ilyen tesztek a biztonsági tesztek, melyeket kifejezetten erre szakosodott tesztelők végeznek.
Úgy is mondhatnánk, hogy a negatív teszteseteknél az a hiba, ha nincs hiba.
2.13. A tesztelési folyamat főbb állomásai
Ideális esetben a tesztelés legalább a következő, alapvető fázisokból áll:
• Tervezés
• Elemzés
• Tesztdizájn
• Végrehajtás
• Kiértékelés
• Tesztjelentés elkészítése
A fázisok ugyan átfedésbe kerülhetnek és ismétlődhetnek is, ám egyfajta logikai hierarchia mégis fennáll közöttük. Ily módon egy fázis gondatlan, vagy hanyag előkészítése negatívan befolyásolhatja az összes többi fázis hatékonyságát is.
2.13.1. A tesztek megtervezése
A tesztek végrehajtását gondos tervezés kell, hogy megelőzze. A tervezés során meghatározzák a teszt célját, a teszt tárgyát, a teszttevékenységek végrehajtásának feltételeit, módját és a kiértékelés kritériumait.
A tervezés kimenete általában egy vagy több dokumentum, melyet a tesztmenedzser, vagy a vezető tesz¬telő készít el, vagy éppen mindketten.
A tesztterv nem részletes technikai megvalósításokat taglal, hanem folyamatokat ír le, témaköröket mutat be.
A tervezés nem csak a tesztelők, hanem a fejlesztők és a szoftver megrendelője számára is készül. A fejlesztők megtudhatják belőle, hogyan és mire alapozva fognak hibajelentéseket kapni a tesztelőktől, a megrendelő pedig megbizonyosodhat afelől, hogy a szoftvert minden, általa fontosnak ítélt szempont szerint le fogják tesztelni.
A tesztterv nem egy „kőbe vésett” dokumentum, hanem alakítható a résztvevők javaslatai alapján.
Súlyos szakmai hiba, ha a tesztterv elkészítője nem veszi figyelembe például a fejlesztőknek a tesztelés üte¬mezésére vonatkozó észrevételeit, módosító javaslatait.
2.13.2. Teszt tervezés sprintekben
Tesztek tervezésére nem csak projektek induló fázisában, hanem sprintekben (SCRUM rendszerben, lásd később) is szükség van. Ez egy kevésbé formalizált tervezés, inkább egy kötetlen szakmai beszélgetés például az üzleti elemző, a projekt menedzser, a fejlesztők és természetesen a tesztelők között.
A tesztelők felelőssége, hogy ilyenkor minden kérdést tisztázzanak, amely a tesztelés végrehajtását veszélyeztetheti. Ennek során általában olyan kérdések is felmerülnek, melyek a fejlesztők számára is létfontosságúak, tehát az eljárással minden résztvevő jól jár.
Ha ez a megbeszélés elmarad, az sprint közben többnyire megakasztja a tesztelés és nem ritkán a fejlesztés lendületét is. A tesztelők információk híján nem tudják pontosan ellátni feladatukat, menet közben kell tisztázni részleteket. Emiatt rengeteg idő elmehet, ami végeredményben többletköltséget eredményez.
2.13.3. A tesztelemzés
A teszt végrehajtóinak a tesztterv magas szinten megfogalmazott céljait és végrehajtásának feltételeit tételesen meg kell vizsgálniuk és számba kell venniük, hogy a rendelkezésre álló információk alapján a teszt kivitelezhető-e.
Az elemzés során a teszt egyes részeinek a priorizálása is megtörténik.
Sajnos a gyakorlatban elhanyagolt mozzanat szokott lenni a tesztkörnyezet előkészítése, illetve az esetlegesen beszerzendő teszteszközök feltérképezése is. A folyamat végén ad absurdum a tesztkörnyezet létrehozása is megkérdőjeleződhet, ami az egész fejlesztési projektet ahhoz teszi hasonlóvá, amit „orosz rulett” néven ismernek az emberek.
Az elemzési fázis nem öncélú dolog, hiszen képes részletekbe menően felfedni az adott szoftver tesztelhetőségét.
Ez szélsőséges esetben azt is jelentheti, hogy az elemzés azt tárja fel, hogy a célként megfogalmazott tesztelés az előzetesen megállapított feltételekkel nem hajtható végre.
2.13.4. Tesztdizájn, előkészítés
A tesztdizájn során a végrehajtandó tesztek a végrehajtandó tesztlépések szintjén lesznek megfogalmazva.
Ezek már nem magasszintű megfogalmazások, hanem konkrét tesztlépések szintjén leírt tevékenységek. Lényegében ekkor jönnek létre „fizikailag” is a tesztesetek.
Fontos az esetlegesen szükséges tesztadatok meghatározása és előállítása, automatizált tesztek esetében a teszt szkriptek megírása, ill. az automatizálást segítő szoftver beállítása.
2.13.5. Tesztvégrehajtás
A tesztek végrehajtása (lefuttatása) természetesen mindig „az igazság pillanata”.
Minden tesztvégrehajtásnak van eredménye. Még az is eredmény, ha a teszt maga nem hajtható végre.
A végrehajtás végén mindig a kiértékelés és az eredmények dokumentálása is megtörténik.
2.13.6. Tesztkiértékelés
A kiértékelés során a dizájn fázisban megfogalmazott feltételek és a szintén akkor megfogalmazott, ún. elvárt teszteredmények összehasonlítása történik meg, a tényleges tesztvégrehajtás eredményeivel.
A kiértékelés egy rövid összegző jelentés formájában is testet ölt, melyet teszt riportnak is neveznek.
A tesztriport egyik változata a záró teszt riport (test exit report) mely a tesztelés egészét értékeli ki, annak teljes végrehajtása után és prezentálja a teszteredményeket is.
2.13.7. Tesztelést támogató tevékenységek
A tesztelés menedzselése során gyakran elfeledkeznek a tesztkörnyezetek karbantartásáról és a tesztadatok előállításáról, pedig mindkét tevékenység alapjaiban befolyásolhatja a tesztelés sikerességét.
A tesztkörnyezet karbantartása kisebb cégek esetében egy-egy számítógép felügyeletét és folyamatos naprakészen tartását jelenti. Különösen fontos, hogy dedikált tesztelői számítógépeket használjanak. Ez azt jelenti, hogy ezeket a gépeket kizárólag tesztelésre szabad használni. Nagyvállalati környezetben a tesztkörnyezetek menedzselése komoyl kihívást jelent, amit jól jellemez az is, hogy egész szakember gárdákat alkalmaznak kizárólag a gépek üzemeltetésére és a szoftvertelepítések koordinálására.
A tesztadatok előállítása első hallásra banálisnak tűnhet. Miért kellene folyamatosan a teszteléshez használt adatokat karbantartani? A szoftverek fejlődése sajnos ezt kikényszeríti. Ahol erre nem figyelnek oda, ott a tesztelőknek sanyarú sorsa van, ugyanis utólagosan szembesülnek azzal, hogy korábban használt tesztadataik hibás teszteredményeket produkálnak. Az utólagos időráfordítás, nyomozgatás természetesen rengeteg időt vesz el és plusz költségeket okoz.
3. Tesztelési technikák
Ebben a fejezetben a tesztek végrehajtásának különböző módjaival ismerkedünk meg, a teljesség igénye nélkül.
3.1. Statikus tesztelési technikák
Statikus tesztelés során a teszt tárgyát képező szoftver nem fut. Ehelyett a szoftver forráskódjának ill. dokumentációjának az ellenőrzésére kerül sor, különböző szempontok alapján.
A fentiekből következik az is, hogy szigorúan véve ilyenkor nem hibákat, hanem potenciális hibaforrásokat keresünk.
Ezeket a teszteket manuálisan és automatizáltan is végre lehet hajtani. Automatizált ellenőrzésekre például léteznek speciális forráskódelemző segédprogramok.
3.2. Dinamikus tesztelési technikák
A dinamikus tesztelés során mindig egy működő szoftvert tesztelünk, mely egy e célból létrehozott ún. tesztkörnyezeten fut.
3.2.1. Fekete doboz tesztelés
A fekete doboz tesztelés esetén a tesztelő nem rendelkezik információval a szoftver belső struktúrájáról. Ez a tesztelés hasonlít leginkább a végfelhasználói viselkedésre.
Néhány példa ilyen tesztekre:
• Értékhatárok és értéktartományok tesztelése.
• Üzleti folyamat alapú technikák.
• Logikai mátrix alapú teszt.
3.2.2. Fehér doboz tesztelés
A fehér doboz technika a fekete dobozzal ellentétben erősen technikai oldalról közelít a szoftverhez és a konkrét programkód is fókuszban van a munka során.
A tesztelőnek pontosan ismernie kell a szoftver belső szerkezetét, működését és ehhez szabva tervezi meg és hajtja végre a teszteket. A fehér doboz teszteket szokás strukturális teszteknek is nevezni.
Néhány példa ilyen tesztekre:
• Döntési ág alapú tesztek.
• Utasítás-lefedettség alapú technikák.
3.2.3. Szürke-doboz tesztelés
Mint az elnevezésből sejteni lehet, a szürke doboz tesztelés a fekete és a fehér keveréke, abból a szempontból, hogy a tesztelő korlátozott ismeretekkel rendelkezik a tesztelendő szoftver belső szerkezetéről is, de ez lehet technikai adat is, például a szoftver által kezelt adatstruktúrákról.
3.2.4. Felfedezéses tesztelés
Ezen tesztelés során a tesztelés egy többé-kevésbé laikus szemüvegén keresztül zajlik. A teszt során mintegy ”ismerkedünk” a szoftverrel, véletlenszerű módon igyekszünk használni. Ez nagyban hasonlít egy kezdő felhasználó viselkedéséhez.
A módszer előnye, hogy nem rögzített munkafolyamatok mentén zajlik a tesztelés, hanem műveletek véletlenszerű kombinációjával. Így olyan rejtett hibákat is lehet találni, melyek csak sokkal később derülnének ki, a felhasználói oldalon.
3.3. Tesztvégrehajtás fajtái
A teszteket végrehajtásuk alapján is megkülönböztetjük: manuális és automata tesztelésről beszélhetünk. Az automata tesztek a közhiedelemmel ellentétben nem a manuális tesztek kiváltására valók, hanem speciális tesztigények kielégítésére. Tehát a kétféle tesztelés kiegészíti egymást, nem pedig helyettesíti.
3.3.1. Manuális tesztelés
A kézi tesztvégrehajtást emberek végzik. Ez többnyire azt jelenti, hogy a tesztelő leül egy számítógép elé és végrehajt teszteseteket, az azokban megfogalmazott lépéseket követve.
A manuális tesztelés óriási előnye a rugalmasság, hiszen bármely pontján módosítani lehet a teszt végrehajtását. Ráadásul az emberi intuíció is teljes mértékben kiaknázható, amire egy gép nem képes.
Hátránya a magas költsége, illetve az, hogy nagy mennyiségű, vagy komplexitású tesztekre nem alkalmazható. Az már az automata tesztelés területe.
3.3.2. Automata tesztelés
Az automatizált tesztek emberi beavatkozás nélkül hajtódnak végre. Technikai hátterük változatos: szkripteket, programozási nyelveket, de akár speciális segédprogramokat is lehet használni erre a célra.
Az automata tesztek gyorsan, nagy mennyiségű tesztet és tesztadatot képesek kezelni, így olyan feladatokra is alkalmasak, melyekre a manuális tesztek nem.
Hátrányuk, hogy speciális technikai ismereteket igényelnek és a karbantartásuk is időigényesebb.
4. Tesztek osztályozása
4.1. Fejlesztési modellek
A szoftvertesztelés a szoftverfejlesztési folyamat szerves része. Alapvető fontosságú ezért a tesztelőknek is megismerni néhány fejlesztési modellt ill. néhány, ehhez a területhez kapcsolódó fogalmat.
4.1.1. A V-modell
A V-modell egyfajta lineáris fejlesztési folyamat, melynek főbb állomásai:
• komponensfejlesztés
• integrációs fejlesztés
• rendszerfejlesztés
• átadás, elfogadás.
A V-modell egyes folyamatai lineárisan, egymás után következnek.
4.1.2. Agilis fejlesztés
A fejlesztésben résztvevő csapatok szorosan együtt tudnak működni egymással és önszerveződőek. A folyamatok körkörös ciklusokban zajlanak (tervezés, implementálás, tesztelés, kiértékelés), ami nagyfokú rugalmasságot kölcsönöz a fejlesztési projektnek.
4.1.3. A SCRUM
A SCRUM alighanem az egyik legelterjedtebb és legdivatosabb fejlesztési módszer, mely az agilis módszertanokhoz tartozik. Kis létszámú, 6-8 fős fejlesztői csapatokra épít, melyekben jellemzően 2-2 tesztelő van. A munka előrehaladásáért és a csapat összetartásáért az ún. scrum master felel, míg az operatív irányítást a vezető fejlesztő tartja kézben. A csapatokhoz ideális esetben egy üzleti elemző is tartozik, aki az üzleti folyamatok oldaláról érti a szoftver működését és képes azt a fejlesztők és tesztelők számára érthetővé tenni.
Tesztelési szempontból több csapat összehangolt tesztelői tevékenységét a tesztmenedzser végzi, aki nem a részletekre koncentrál, hanem a munkák folyamatos előrehaladása felett őrködik.
A SCRUM a munkákat általában hetekre és napokra bontja. A heti bontást sprintnek nevezik. Megjegyezzük, hogy egy sprint időtartama lehet több is egy hétnél. A napi bontás alatt a napokat indító megbeszéléseket kell érteni, mely elsősorban a csapat tagjainak szól és csak másodsorban a vezetőségnek.
A napi megbeszélések (ezeket az angol szakzsargon daily standup meetingnek nevezi) megtartásával kapcsolatban gyakori hiba a túlzott formalizáltság és az öncélúság. Ezen megbeszélések elsődleges célja az kell, hogy legyen, hogy a csapat tagjai tudják és értsék, hogy milyen feladataik lesznek az adott napon és általában hogyan halad a csapat a munkájával, a tervezetthez képest.
Felmerülhet a kérdés, hogy van-e a heti ritmuson felüli egység. Van, de ez erősen projektfüggő. A negyedéves, féléves, esetleg éves szoftverkiadások adhatják meg a munkák tágabb kereteit. Ilyenkor általában a projekten dolgozó összes csapat összegyűlik és a vezetők kiértékelik az elért célokat. Ezek a megbeszélések egyben fel is vezetik az újabb fejlesztési ciklust, ami így végeredményben egyenes folytatása az előzőnek.
Természetesen jóval több szerepkör létezik egy-egy projekten belül, mint például a product owner, vagy a projektmenedzser stb., ám ezek tesztelői szempontból kevésbé érdekesek.
4.2. Tesztszintek
4.2.1. Komponensteszt
A komponenstesztek tipikusan izoláltan is végrehajtható tesztek.
Fókuszukban egyszerűbb programok, szoftvermodulok, vagy programozási egységek, például osztályok állnak.
Mivel ez a tesztelési szint erősen forráskódközeli lehet, így gyakori, hogy a tesztelésben aktívan segédkezik maga a forráskód írója is.
Az ún. teszt-vezérelt fejlesztés során a forráskód eleve úgy van megírva, hogy (lehetőleg automatizáltan) komponensteszteket lehessen végrehajtani rajtuk.
4.2.2. Integrációs teszt
Az integrációs tesztek a komponensek egymás közötti, vagy az operációs rendszerrel, csatolófelületekkel stb. történő sikeres együttműködésének a vizsgálatát célozzák.
Az integrációs tesztelés veszélyes üzem: minél nagyobb és bonyolultabb a rendszer, annál nagyobb költségeket emészthet fel a tesztelés, annál tovább tarthat és annál nehezebb a hibák egyértelmű okának az azonosítása. (Nem utolsó sorban pedig annál könnyebb nehezen helyrehozható károkat okozni hanyagul előkészített és végrehajtott tesztekkel...)
A fentiek miatt erősen ajánlott integrációs teszteknél az óvatos, fokozatos megközelítés, melynek során a tesztek is egymásra épülnek.
4.2.3. Rendszerteszt
A rendszertesztek tulajdonképpen az éles működésű rendszert hivatottak modellezni és vizsgálni, ezért rendkívül fontos egy olyan tesztkörnyezet megléte, mely az éles rendszerhez a lehető legjobban hasonlít.
Éles rendszeren végzett átfogó rendszerintegrációs tesztelés (például egy új rendszer bevezetése) szóba sem jöhet!
A rendszertesztek a szoftverrendszer egészének a működését vizsgálják, kevésbé az egyes funkcionalitásokra, sokkal inkább a rendszer egészének a működésére koncentrálnak.
4.2.4. Elfogadási teszt
A rendszertesztek után többféle, ún. elfogadási teszt végrehajtására is sor kerül. Ezen tesztek célja annak megállapítása, hogy a szoftver(rendszer) valóban képes ellátni a neki szánt feladatot, méghozzá az elvárt módon.
Elfogadási teszteket hivatásos tesztelők, külső hivatásos tesztelők, vagy maguk a megrendelők, esetleg végfelhasználók végzik.
Az elfogadási tesztek típusai:
• Felhasználói elfogadási teszt: ún. üzleti felhasználók végzik.
• Üzemeltetési elfogadási teszt: a szoftver üzemeltetése során tipikusan felmerülő folyamatok tesztelése (pl. visszaállíthatóság).
• Szerződésalapú elfogadási teszt: ezen teszt alapja a fejlesztési projektet megelőzően kötött szerződés, melyben bizonyos szabályozásokat, elvárásokat fogalmaztak meg. Ilyenkor ezek ellenőrzését végzik el.
• Alfa teszt: a potenciális végfelhasználók (teljesen hétköznapi felhasználók, nem hivatásos tesztelők) fejlesztőközpontban végrehajtott tesztjei.
• Béta teszt: szintén végfelhasználók által végrehajtott tesztek, melyet általában mindenki a saját otthonában, ill. saját eszközein végezhet.
4.3. Teszttípusok
4.3.1. Funkcionális teszt
Amikor tesztelésről esik szó, a legtöbb ember valójában a tesztelés egyik típusára, a funkcionális tesztekre gondol.
A funkcionális tesztek a szoftver előre meghatározott (dokumentumokban előre meghatározott), konkrét funkcióit veszik górcső alá.
Ezek a tesztek tipikusan ún. feketedoboz tesztek, azaz a tesztelő a szoftver belső struktúrájának ismerete nélkül, mintegy „kívülről szemlélődve” hajtja végre őket.
A funkcionális teszt azt vizsgálja, AMIT a szoftver csinál.
A funkcionális tesztek alapja mindig egy dokumentum. Ez legrosszabb esetben egy felhasználói kézikönyv, ám erre a célra külön dokumentumokat, ún. funkcionális specifikációkat illik készíteni. Ezek a leírások ugyanis olyan technikai információkat, illetve folyamatleírásokat is tartalmaznak, melyekre egy átlagos végfelhasználónak ugyan nincsen szüksége, ám a tesztelés szempontjából életbe vágó lehet.
Egy ügyfélnyilvántartó szoftver esetében külön leírás szólhat például egy új ügyfél felvételéhez szükséges lépésekről, de akár arról is, hogy a folyamat során az adatok mely rendszereken mennek keresztül, hol és hogyan tárolódnak stb.
Egy kellő részletességű leírás alapján elkészíthetőek a tesztesetek, tesztlépések.
Funkcionális teszteket bármely tesztszinten végre lehet hajtani.
4.3.2. Nem-funkcionális teszt
A nem-funkcionális tesztek a szűkebb-tágabb értelemben vett szoftver számszerűsíthető ismérveit vizsgálják, magyarul azt, hogy az adott szoftver valamit HOGYAN csinál, vagy valamilyen feltételnek milyen mértékben felel meg.
Tipikus nem-funkcionális tesztek: teljesítményteszt, terheléses teszt, használhatósági teszt, megbízhatósági-, hordozhatósági teszt stb.
Nem-funkcionális teszteket bármely tesztszinten végre lehet hajtani.
4.3.3. Regressziós teszt
A regressziós teszt egy már letesztelt szoftver ismételt tesztelését jelenti. Ezen teszt elsődleges célja az, hogy ellenőrizze a korábban már sikeresen tesztelt szoftvertulajdonságok helyes működését.
Egy hiba kijavítását szintén regressziós teszteléssel szokás ellenőrizni. Előfordulhat, hogy a hiba csak részben, vagy egyáltalán nem tűnt el, sőt, a hibajavítás akár más helyen is (újabb) hibát vált ki.
5. Tesztprojektek
5.1. A tesztprojekt szerepkörei
Ebben a fejezetben áttekintjük azokat a szerepköröket, melyek egy fejlesztési projektben mindenképpen jelen kell(ene) lenniük és tesztelői szempontból elengedhetetlenek. (Egy projekt jóval több szereplővel rendelkezik és az itt tárgyaltakhoz is jóval több feladat tartozik.) Mi a tesztelés szempontjából tárgyaljuk őket.
A legfontosabb szerepkörök tehát:
• Tesztmenedzser
• Projektkoordinátor
• Tesztkoordinátor, tesztvezető
• Üzleti elemző
• Tesztelő
5.1.1. Tesztmenedzser
A tesztmenedzser a tesztelés igavonója. Legfontosabb feladata a tesztelés szinkronban tartása a fejlesztéssel, a tesztelői csapatok munkájának monitorozása és a tesztelők folyamatos informálása.
Ha ezek közül bármelyik rész biceg, a tesztelési tevékenység egy párhuzamos dimenzióba kerül, mely köszönő viszonyban sincsen az eredeti valósággal.
A tesztelésnek a fejlesztéssel történő szinkronban tartása adja az alapját maguknak a teszteknek, elvégre csak annak a tesztnek van értelme, amely a legaktuálisabb fejlesztésekből indul ki.
A tesztek előrehaladásáról és a teszteredményekről a menedzsernek mindig friss információkkal kell rendelkeznie, mivel a tesztmenedzser tud végleges és átfogó képet adni a tesztprojekt aktuális eredményeiről.
Fontos feladata továbbá, hogy a tesztelőket mindig ellássa a munkájukhoz szükséges információkkal és eszközökkel. Ez ugyanis NEM a tesztelő feladata, hanem a menedzseré.
A menedzseri munkából kifolyólag elengedhetetlen az empátia és a humánus, emberközeli hozzáállás is. Mindig szem előtt kell tartania, hogy különböző habitusú emberekkel dolgozik. A gyakorlatban ez általában valóban így is van.
A tesztmenedzser elsősorban vezető, nem pedig tesztelő. Ennek megfelelően nem feladata a tesztelés mikromenedzselése.
5.1.2. Projektkoordinátor
A projektkoordinátor bizonyos értelemben a tesztelést is felügyeli, de nem szólhat bele a tesztelésbe. Feladata a tesztelés szempontjából az, hogy kiszolgálja a tesztelés igényeit, gyakorlatban megteremtse annak feltételeit és tisztában legyen azzal, hogy a projektnek honnan hová kell eljutnia.
5.1.3. Üzleti elemző
Az üzleti elemzők mind a fejlesztők, mind a tesztelők munkáját segítik. Feladatuk a folyamatok és a kitűzött célok gyakorlati megvalósulásának megértése, ennek emészthető (írásos) formában történő rögzítése és a felmerülő akadályokról, ellentmondásokról visszajelzések adása a projekt felsőbb vezetése felé.
Az üzleti elemzők gyakran az adott szoftvertípus professzionális, korábbi felhasználói közül kerülnek ki.
Az üzleti elemzők feladata annak támogatása is, hogy a tesztelők rendelkezésére álljanak mindazon információk és leírások, mely alapján a tesztelés elvégezhető.
5.1.4. Tesztkoordinátor, tesztvezető
A tesztkoordinátorok szerepe hasonló a tesztmenedzserekéhez, azzal a különbséggel, hogy kisebb tesztelői csapatok munkáját egyengetik. Lényegében a tesztmenedzser „helyi megbízottjai”. A tesztkoordinátorok általában maguk is tesztelők, akik tapasztalatuk révén képesek átlátni egy projekt kihívásait és feladatait, valamint ezt kommunikálni is tudják, elsősorban a tesztmenedzser és a többi tesztelő felé is.
5.1.5. Tesztelő
A tesztelő a gyakorlatban végrehajtandó tesztek megtervezéséért, dokumentálásáért, végrehajtásáért és kiértékeléséért felel.
A tesztelőkre gyakorta igen nagy nyomás nehezedik, mivel a projekt számos résztvevője megpróbálja érdekeit rajtuk keresztül érvényre juttatni. Ilyen esetekben a professzionális tesztelői hozzáállás az objektivitás megőrzése, ami a rugalmas hozzáállás mellett bizonyos fokú keménységet és persze rutint is igényel a nyomás elhárítására.
5.2. A tesztprojekt fázisai
A tesztelés fázisai nagyban hasonlítanak a fejlesztés fázisaihoz, már csak azon egyszerű oknál fogva is, hogy a projekt legelső fázisától a legutolsóig végig be kell vonni a tesztelést is a munkába.
Bár a fázis mint fogalom egymás utániságot sugall, a valóságban körkörös, visszatérő folyamatokról van szó. Egy folyamat tehát akár „menet közben” is változhat, annak ellenére is, hogy korábban már ki lettek dolgozva.
Ez egyáltalán nem baj, feltéve, hogy a változtatásokkal együtt a többi érintett folyamat is módosításra kerül és azt minden döntéshozó elfogadja. Egy-egy apróbb változtatásnak komoly pénzügyi vonzata is lehet, ezért ez a kérdés nem triviális, bár sokszor sokan elkövetik azt a hibát, hogy nem vesznek tudomást róla.
A legfontosabb fázisok:
• Tervezés, becslés
• Projektindító (kick-off) meeting
• Teszt dizájn
• Tesztvégrehajtás
• Ellenőrzés, monitorozás
• Jelentéskészítés
5.2.1. Tervezés, becslés
A tervezés a projekt előkészítő fázisában történik, amikor még egyetlen sor programot sem írtak meg a fejlesztők.
A tervezés során tisztázni kell, hogy mit és milyen szempontból kell majd tesztelni. Ez nem csak azért fontos, mert egy szoftvert teljes mértékben nem lehet soha letesztelni, hanem azért is, mert minél többféle típusú tesztet hajtunk végre, a tesztelés annál drágább lesz.
A tervezés során a tesztmenedzser, a tesztelők véleményét is figyelembe véve meg is becsüli, hogy mely teszttípusokkal, hány tesztelővel stb. milyen eredmények elérésére van lehetőség.
A tesztstratégia tartalmazza a tesztek kivitelezésének többé-kevésbé pontos technikai részleteit és a tesztelés céljait is.
5.2.2. Projektindító (kick-off) meeting
A kick-off legtöbbször egy informális megbeszélés, melyet a projekt indulásakor szoktak megtartani.
Legfontosabb célja a projekt szereplőinek bemutatása, a szerepkörök és felelősségi körök, valamint annak tisztázása, hogy a tesztelés elkezdésének nincsenek-e személyi-, ill. technikai akadályai.
Tesztelői szempontból fontos annak tisztázása, hogy felmerülő kérdések esetén kihez lehet fordulni, ill. az is, hogy kiknek és milyen formában kell tájékoztatást adni a munkákról.
5.2.3. Teszt dizájn
A konkrét tesztek megtervezése a tesztelők felelőssége és feladatköre.
Ez többnyire konkrét tesztesetek megírását, előkészítését jelenti, a projekt számára meghatározott szoftveres eszközök segítségével.
5.2.4. Tesztvégrehajtás
A tesztek végrehajtására azok előkészítése után kerülhet sor, abban a formában, ahogyan az a tesztesetben meg van fogalmazva.
A végrehajtás a kiértékeléssel ér véget, ami valamilyen dokumentum, jelentés formájában ölt testet.
5.2.5. Ellenőrzés, monitorozás
A tesztek végrehajtását napi szinten érdemes és szükséges is nyomon követni. Így azonnal kiderül, ha a tesztelés üteme elmarad a korábban tervezettől és az is, ha a szoftver minőségével kapcsolatban komoly aggályok merülnek fel.
A monitorozást a tesztmenedzser a tesztkoordinátor segítségével szokta végezni.
5.2.6. Jelentéskészítés
Egy-egy nagyobb tesztfázis közben és végén is külön jelentések, összefoglalók készülhetnek, melyek elsősorban a menedzsment számára hordoznak információkat a projekt előrehaladásával, a szoftver minőségével kapcsolatban.
6. Tesztkiértékelés
A tesztek kiértékelése a teszt során elvégzett munka dokumentuma, írott formában. Elsődleges célja a feltárt hibák rögzítése. Ehhez hozzátartozik a hiba rögzítésének körülménye is.
A tesztelő feladata mindig az, hogy a meglévő keretek között maximális pontossággal és részletességgel, de terjengősség nélkül rögzítse a hibákat. Minden hiányzó részlet utólagos megkeresése ugyanis a későbbiekben plusz erőforrásokat, elsősorban időt igényel a résztvevőktől, ez pedig bizony drága mulatság lehet a projekt szemszögéből.
6.1. Hibák dokumentálása
A hibák rögzítése előtt a hibát reprodukálni kell. Egy egyszer előforduló hiba némi túlzással olyan, mintha meg sem történt volna. E nélkül a programozóknak ugyanis szinte esélyük sem lesz arra, hogy a hiba valódi okát feltárják.
Ez alól az ökölszabály alól csak egy kivétel van: amikor olyan súlyos hiba következik be, ami üzleti szempontból aggályos és nagy valószínűséggel a tesztelt szoftver okoz.
6.1.1. A hiba elnevezése
A hiba részletes leírását egy rövid, tömör elnevezés kell, hogy megelőzze. Ez általában egy rövid, mondatnyi szöveg. A modern hibarögzítő rendszerekben a leírás, vagy összegzés egyfajta címként is felfogható. Célja, hogy már ránézésre is tudni lehessen, milyen jellegű hibáról van szó, a hiba javításakor pedig azonnal azonosítani lehet a hibát és annak aktuális feldolgozási állapotát.
6.1.2. Hibaleírás
A hiba részletes leírása már egy jóval nagyobb lélegzetvételű leírás, ám itt sem kisregényt kell írni.
A hibaleírások legfontosabb elemei szoftverek esetében:
• A szoftver, vagy modul neve.
• Verziószám, mely lehetőleg tartalmazza a főverzió, a release és a hotfix számát is.
• Operációs rendszer neve és verziószáma, amelyen a tesztelés történt.
• Speciális rendszerek esetén a tesztrendszer, tesztkörnyezet néhány főbb konfigurációs paramétere (pl. RAM, CPU stb.)
• A hiba 1-2 mondatos leírása.
• A teszt eredetileg elvárt, pozitív eredménye.
• Az aktuális, hibás eredmény.
• Amennyiben van hibaüzenet és az nem túl hosszú, a konkrét hibaüzenet szövege.
• A hiba reprodukálásához szükséges lépések leírása. Itt törekedni kell az egyszerű, pár szavas leírásokra lépésenként. A lépések számában viszont értelemszerűen nem lehet korlátozás.
• A hiba kihatása, ill. súlyossága.
• A hiba elkerülésének lehetséges módjai, ha léteznek ilyenek.
• Csatolmányok. Szoftverek esetében nincs értelme hosszú naplófájlokat közvetlenül bemásolni a hibaleírás szövegébe. Viszont általában lehetőség van arra, hogy csatolmányokat adjunk a hiba leírásához. Ezek lehetnek képernyőképek is, melyek hiánya miatt a programozók sokszor ölni tudnának.
6.1.3. Fontosság (prioritás) és súlyosság
A prioritás és súlyosság két, gyakran összekevert fogalom, melyek bár összefüggenek, mégis két különböző dolgot takarnak.
A prioritás mindig a hiba kijavításának a sürgősségét jelenti, azaz mennyire sürgős egy hiba kijavítása.
A hiba súlyossága (severity) azt fejezi ki, hogy mekkora mértékű a hiba kihatása.
A két fogalom összekeverésére az ad okot, hogy laikus szemmel nézve azt gondolnánk, hogy a súlyos hibát minél hamarabb ki is kell javítani. Ezt diktálja a józan paraszti ész. A valóságban ez nem ilyen egyszerű. Valójában a prioritás és súlyosság minden kombinációja elképzelhető. Ez a hiba körülményeitől függ.
Egy rendkívül súlyos hiba fellépéséhez például lehet, hogy csak igen kivételes helyzet vezethet, mely, bár valóban a hiba bekövetkeztét vonja maga után, mégis kevésbé valószínű. Például egy szökőár nyilvánvalóan katasztrofális hatással lehet egy szerverparkra, ám ennek a kockázata egy hegyvidéki országban minimális.
Elképzelhető az is, hogy egy minimális kihatású hibát mégis kiemelt prioritással kell kezelni és javítani. Például, ha egy webes alkalmazás nyitóoldalára a céges logó helyett a szórakozott programozó csak egy vázlatot tesz ki, az ugyan nem befolyásolja a szoftver helyes működését, tehát alacsony súlyosságú, mégis gyorsan javítani kell, tehát kiemelt fontosságú.
6.1.4. Érvényesség
A hiba érvényességét nem feltétlenül a tesztelő dönti el, ugyanis érvényesség alatt azt is érthetjük, hogy a hiba kijavítása egyáltalán, valaha is meg fog-e történni.
Elképzelhető olyan hiba is, mely a való életben soha nem fordulhat elő, bár mesterségesen előidézhető, reprodukálható.
Most biztosan sokan felhördülnek, mondván: „A hiba az hiba, akár tetszik, akár nem!” Nos, ez így is van. Ennek ellenére születhet olyan üzleti döntés, mely a hiba kijavítását elutasítja. Ennek üzleti oka is lehet, ám többnyire egészen egyszerűen pénzügyi okok vezetnek egy hiba kijavításának a lemondásához. Magyarul: nincs rá idő és pénz.
6.1.5. Hozzárendelés meghatározása
Egy hibát annál hamarabb kijavítanak, minél hamarabb kerül a megfelelő személyhez, csapathoz stb. Elsősorban nagyobb vállalatoknál, ahol sok csapat dolgozik egy projekten, a felelősségi körök élesebben meg vannak szabva.
Ezért nem árt tudni, hogy ki a kompetens egy adott hiba esetén. Ez projektenként más és más. Tapasztalat, rákérdezés útján, vagy közvetlen instrukciók (pl. tesztstratégia dokumentuma) alapján lehet eldönteni egy-egy hiba felelősségi körét.
Kisebb cégeknél a hibákat képletesen egy nagy kalapba dobálják, ahonnan minden fejlesztő kaphat javítási munkát.
6.1.6. Egyéb tulajdonságok
A hibák rögzítésének, kezelésének kultúrája cégenként, sőt projektenként is változó. Valahol még ennél is több, valahol még ennél is kevesebb információ az, amit megkövetelnek a hibák dokumentálásában.
6.2. Teszteredmények kiértékelése
A tesztek eredményeit többféleképpen kiértékelhetjük. A kiértékelések számának csak a fantázia (és a rendelkezésre álló idő és pénz) szabhat határt.
Alább leírunk néhány tipikus kiértékelési szempontot:
• Hibás teszteredmények száma.
• Létrehozott hibajelentések száma.
• Hibák csoportosítása, számossága súlyosság szerint.
• Sikertelen újrafuttatott tesztek (hibajavítások ellenőrzésekor) száma.
• Tesztek futási idejének kimutatása.
7. Tesztelés a gyakorlatban
7.1. A szoftvertesztelés napi gyakorlata
A teszteléssel csak most ismerkedők joggal tehetik fel a következő kérdések bármelyikét: Hogyan telik egy szoftvertesztelő napja? Milyen arányban végzi a tevékenységeit és milyen szoftvereket használ?
Általános válaszokat ezekre a kérdésekre lehet is adni, meg nem is. A cégek saját, belső üzletmenete, kultúrája ugyanis kivétel nélkül más és más munkamenetet ró az alkalmazottakra, az alkalmazott szoftverekről nem is beszélve.
A SCRUM-ot alapul véve azért néhány dolgot mindenképpen elmondhatunk a tesztelés napi rutinjáról.
A tesztelők napi tevékenységei között az alábbiak szoktak szerepelni:
• tesztesetek előkészítése, megírása
• tesztvégrehajtás előkészítése
• tesztfuttatás
• tesztkiértékelés, jelentéskészítés
• hibák rögzítése
• hibajavítások ellenőrzése.
A projektek egyedi ritmusának megfelelően, bizonyos időszakokban a tesztesetek tervezése és elkészítése kaphat hangsúlyt, míg máskor a tesztek végrehajtása, vagy éppen a korábban felvett hibák ellenőrzése. Nem ritka, hogy ezek a tevékenységek sokszor átfedésben vannak.
Jó és hasznos, ha minden nap vannak legalább csapaton belüli megbeszélések, akár informálisak is. Ez segít minden résztvevőnek abban, hogy ne maradjanak le a többiektől információk tekintetében.
Minden munkafázist átsző a kommunikáció. A tesztelők nem csupán természetüknél fogva kiváncsi emberek: életbevágó, hogy minél hamarabb hozzájussanak a munkájukhoz szükséges információkhoz, ill. hogy támogatást szerezzenek hozzá. Ez pedig csak kommunikációval lehetséges. A tesztelő kommunikál a programozókkal, a menedzserrel, ritkább esetben az ügyfelekkel is.
A tesztek továbbfejlesztése nagyon fontos, sajnos erre kevesebb idő szokott jutni a kelleténél, ennek kivitelezése sokszor a tesztelő leleményességétől is függ.
Természetesen információkat a tesztelőnek is szolgáltatnia kell a munkájáról. Ennek módja is projektfüggő. Van, ahol napi szintű jelentések kötelezőek, valahol a heti egy alkalom is bőven elég. Az ún. riportolás egy kevésbé kedvelt tevékenység, ám helye van a tesztelési tevékenységek között.
Az alkalmazott szoftvereszközök cégenként, sőt projektenként is szinte mindig mások. Ezek használatáról legtöbbször vezető fejlesztők és menedzserek döntenek, ritkábban egy sok tapasztalattal rendelkező tesztelő is beleszólhat ebbe.
7.2. Hogyan teszteljünk például porszívót?
Állásinterjúkon könnyen a fentihez hasonló kérdést szegezhetik a leendő tesztelő munkatársaknak. A kezdők ilyenkor zavarba jönnek, mert általában informatikai vonatkozású kérdéseket várnak.
Pedig egy ilyen kérdés valójában teljesen jogos és várható. A tesztelési tevékenységhez ugyanis pontosan olyan hozzáállás kell, mint egy ilyen kérdéshez. Az adott válaszokból és a jelölt kérdéseiből nagy pontossággal meg lehet állapítani, hogy mennyi tapasztalata van és milyen a rátermettsége.
Hogyan tesztelnénk tehát egy porszívót? Kezdjük az elején!
Mit kell tudnunk a minél pontosabb válaszhoz?
Példák:
• Rendelkezésre áll-e használati útmutató (funkcionális specifikáció, felhasználói kézikönyv) a porszívóhoz?
• Milyen szőnyegen, felületen kell használnunk a porszívót (tesztkörnyezet)?
• Milyen szennyeződést kell felszívnia a porszívónak (tesztadatok)?
• Mi a tesztelés célja, mit akarunk a teszteléssel ellenőrizni?
• Mikor számít sikeresnek a teszt?
Ha a fenti kérdéseket tesszük fel, már jó nyomon járunk. Az kapott válaszoktól függően az alábbi válaszokat is adhatnánk az eredeti kérdésre:
1. Győződjünk meg arról, hogy a porszívó használatra kész állapotban van-e!
2. Ha igen, dugjuk be a csatlakozóját a konnektorba!
3. Vigyük a porszívót a tisztítandó felülethez!
4. Állítsuk be a porszívás fokozatát!
5. Indítsuk el a porszívót!
6. Mozgassuk a porszívófejet a szennyezett felületen!
7. Ha felszívtunk minden szennyeződést (a tesztcél teljesül), kapcsoljuk ki a porszívót!
A fenti példa játékossága ellenére jól szemlélteti, hogy mi az, amit egy tesztelőtől elvárnak a gyakorlati munka során.
A feladatot először is értelmezni kell. Mindig. Minden olyan információt be kell gyűjtenünk, ami nélkül a tesztelés megtervezése és biztonságos kivitelezése nem lehetséges.
A hétköznapokban talán bele sem gondolunk abba, hogy egy szimpla porszívózás mennyi elemi lépésből áll. A tesztek tervezése során minden feladatot elemi lépések sorozatára kell bontanunk, figyelembe véve azok esetleges egymásra utaltságát.
A porszívós példán keresztül valójában minden tesztfeladat modellezhető.
Hogy csak két példát említsünk. Negatív teszt lehet annak megkísérlése, hogy egy maroknyi golyóstollat fel tud-e szívni a porszívó és közben mi történik. Terhelésses teszt lehet az, ha a porszívót 24 órán keresztül üzemeltetjük.
A játékos példákat folytathatnánk, helyette azonban konkrét, valósabb példákat elemzünk ki.
7.3. Gyakorlati példa: webes felhasználói azonosítás tesztelése
7.3.1. A feladat
A tesztelési feladat a következő. Adott egy webes alkalmazás (weboldal), mely felhasználói profilokat is támogat, azaz külön be lehet jelentkezni felhasználói adatokkal.
A bejelentkezés a weboldal kezdőoldalán található „Bejelentkezés” linkre történő kattintással kezdeményezhető. Ezután egy dialógus ablak jelenik meg, ahol meg lehet adni felhasználói nevet, jelszót, majd a „Belépés” nyomógombra történő kattintással lehet ténylegesen bejelentkezni.
A tesztelés célja, hogy manuális teszteléssel ellenőrizzük, hogy a regisztrált felhasználók be tudnak-e jelentkezni a weboldalra, felhasználói azonosítójuk ÉS jelszavuk megadásával. Ilyenkor az „Üdvözöljük, kedves felhasználónk!” üzenet jelenik meg.
Ellenben nem regisztrált felhasználók ezt ne tehessék meg, nem regisztrált felhasználói név, vagy jelszó használata esetén egy hibaüzenetnek kell megjelennie: „A megadott felhasználó nincs regisztrálva!”
Amennyiben a felhasználói név, vagy jelészó bármelyike nincsen megadva, „A felhasználói név, vagy jelszó nincsen megadva!” üzenetnek kell megjelennie.
A tesztelés a weboldal felületén történik. Mozilla Firefox böngészővel történő tesztelés elegendő.
7.3.2. A tervezés
A feladat leírását megnézve látszik, hogy alapvetően kétféle eredmény elérésére törekszünk: a sikeres és a sikertelen bejelentkezés működését kell vizsgálnunk, a megadott leírásnak megfelelően. Ehhez ún. pozitív és negatív tesztesetekre lesz szükségünk.
Pozitív teszt szcenárió:
• Bejelentkezés érvényes felhasználói név és jelszó párossal.
Negatív teszteseteknél, ahol több lehetséges kombinációt kell kipróbálnunk, ún. döntési mátrixot is készíthetünk. Ez valójában nem más, mint egy táblázat, ami segít átlátni a lehetséges kombinációkat. Ezek segítségével már sokkal könnyebb is megírni teszteseteket.
A mátrix soraival azt jelöljük, hogy mely adatot adunk meg a teszt során. De jelölhetjük vele azt is, hogy érvényes/érvénytelen bejelentkezési adatokat adunk-e meg.
Felhasználói név | Jelszó |
X | |
X | |
X | X |
A mátrix alapján legalább 6 féle negatív szcenáriót állíthatunk fel (hogy miért nem nyolcat, mindjárt elmagyarázzuk):
1. Bejelentkezés érvényes felhasználói név megadásával, jelszó megadása nélkül.
2. Bejelentkezés érvényes jelszóval, felhasználói név megadása nélkül.
3. Bejelentkezés érvényes felhasználói név és jelszó megadása nélkül.
A negyedik esetet valójában a fentebb megfogalmazott pozitív tesztesettel már lefedtük, ezért sem kell ismét szerepeltetnük (no és persze az nem is negatív esetet írna le), hasonlóan a következő szcenáriócsoportokhoz.
4. Bejelentkezés érvénytelen felhasználói névvel és érvényes jelszóval.
5. Bejelentkezés érvényes felhasználói névvel és érvénytelen jelszóval.
6. Bejelentkezés érvénytelen felhasználói névvel és érvénytelen jelszóval.
7.3.3. Jóváhagyás
Miután megterveztük a teszteseteinket, azokat jóvá kell hagyatnunk.
Az ellenőrzést végezhetik más tesztelők, de akár a tesztmenedzser is, az üzleti elemző, esetleg az ügyfél bevonásával.
Észrevételek esetén módosítani kell a terveket, majd ismét jóváhagyatni az átdolgozottakat.
Ha mindenki elégedett, akkor elkezdődhet a tesztesetek kidolgozása.
7.3.4. Kivitelezés
Kivitelezés alatt itt a tesztesetek megírását és a tesztek végrehajtását értjük. Ezek a gyakorlatban időben általában elkülönülő fázisok, itt az egyszerűség kedvéért összevonjuk őket egy lépésbe.
A végrehajtáshoz elengedhetetlen, hogy legalább egy érvényes felhasználói név / jelszó párossal rendelkezzünk (tesztadatok fontossága), mivel bizonyos tesztekhez ez kell, mint láttuk. Erre figyelnünk kell. Ha nem rendelkezünk ilyenekkel, jelezni kell, például a tesztmenedzsernek.
A fenti tesztszcenáriók közül a negatívokat össze is vonhatjuk egyetlen tesztesetté, ez átláthatóbbá teszi a tesztek majdani végrehajtását.
Az alábbiakban ismertetjük a két (egy pozitív és egy negatív) teszteset kidolgozott lépéseit.
Teszteset neve: Felhasználói bejelentkezés, pozitív
Lépés sorszáma | Tesztlépés leírása | Elvárt eredmény. |
1. | A Mozilla Firefox böngészőben nyissuk meg a weboldalt! | A weboldal betöltődik. |
2. | Kattintsunk a „Bejelentkezés” linkre! | Megjelenik a bejelentkezéshez használható dialógusdoboz. |
3. | Adjunk meg érvényes felhasználói nevet és jelszót, majd kattintsunk a „Belépés” nyomógombra! | Megjelenik az „Üdvözöljük, kedves felhasználónk!” felirat. |
Lássuk a negatív teszteset kidolgozott lépéseit:
Teszteset neve: Felhasználói bejelentkezés, negatív
Lépés sorszáma | Tesztlépés leírása | Elvárt eredmény |
1. | A Mozilla Firefox böngészőben nyissuk meg a weboldalt! | A weboldal betöltődik. |
2. | Kattintsunk a „Bejelentkezés” linkre! | Megjelenik a bejelentkezéshez használható dialógusdoboz. |
3. | Adjunk meg érvényes felhasználói nevet, jelszó nélkül, majd kattintsunk a „Belépés” nyomógombra! | Megjelenik a „A felhasználói név, vagy jelszó nincsen megadva!” üzenet. |
4. | Adjunk meg érvényes jelszót, felhasználói név nélkül, majd kattintsunk a „Belépés” nyomógombra! | Megjelenik a „A felhasználói név, vagy jelszó nincsen megadva!” üzenet. |
5. | Felhasználói név és jelszó megadása nélkül kattintsunk a „Belépés” nyomógombra! | Megjelenik a „A felhasználói név, vagy jelszó nincsen megadva!” üzenet. |
6. | Adjunk meg érvényes felhasználói nevet, érvénytelen jelszóval, majd kattintsunk a „Belépés” nyomógombra! | Megjelenik a „A megadott felhasználó nincs regisztrálva!” üzenet. |
7. | Adjunk meg érvénytelen felhasználói nevet, érvényes jelszóval, majd kattintsunk a „Belépés” nyomógombra! | Megjelenik a „A megadott felhasználó nincs regisztrálva!” üzenet. |
8. | Adjunk meg érvénytelen felhasználói nevet, érvénytelen jelszóval, majd kattintsunk a „Belépés” nyomógombra! | Megjelenik a „A megadott felhasználó nincs regisztrálva!” üzenet. |
A tesztlépéseket egyből beírhatjuk egy tesztelést támogató alkalmazásba (erre a 7.7 fejezetben látunk majd példát).
A kidolgozott tesztesetek készen állnak a végrehajtásra, ezt általában valamilyen státusszal jelzik egy tesztelést támogató alkalmazásban (lásd szintén a 7.7. fejezetet).
A tesztek végrehajtása a lépések pontos, a leírt sorrendben történő végrehajtását jelenti.
Példánkban a sorrend talán nem tűnik fontosnak, a valóságban azonban ez is számíthat. Ez elsősorban a hibák reprodukálása szempontjából fontos. Könnyen elképzelhető, hogy bizonyos rejtett hibák csak műveletek bizonyos sorrendjében hozhatók elő. Előnyös, ha erre az esetleges hibák leírásában külön felhívjuk a figyelmet. Ezért is fontos a következetes végrehajtás, másrészt azért, hogy a tesztelés maga ugyanúgy végrehajtható legyen bárki által. Ha mindenki a megfogalmazott sorrendhez tartja magát, maga a tesztelés is hordozhatóbbá válik.
A tesztlépések „Elvárt eredmény” oszlopához nem írtuk külön, redundánsan mindenhová oda, hogy az adott művelet közben fellépő bármely hiba tolerálható-e vagy sem. Általában nem. Egy adott hiba ugyanis jó eséllyel befolyásolhatja akár a bejelentkezés sikerességét is.
Az ehhez hasonló esetekben vagy a tapasztalat, vagy egy tapasztaltabb kolléga tanácsa segíthet. Ha például a weboldal kezdőképernyőjén az egyik statikus szöveg el van csúszva a képernyőn, az nyilván hiba, de nem befolyásolja a felhasználói bejelenkezés sikerességét.
Ha viszont a „Bejelentkezés” link annyira el van csúszva, hogy nem is lehet rákattintani a böngészőben, az már egyenesen lehetetlenné teszi a bejelentkezést és a tesztvégrehajtás befejezését. Ebben az esetben a hibát dokumentálni kell (lásd 6.1. fejezetet is) és a teszt blokkolt státuszba kerül: mindaddig nem folytatódhat a tesztvégrehajtás, amíg ez a hiba ki nem lesz javítva.
Bármely más esetben, amikor a bejelentkezéssel kapcsolatos elvárt eredmény nem teljesül, természetesen szintén dokumentálnunk kell a hibát. Amennyiben a teszteset fő célja nem teljesül, maga a teljes teszt is hibásnak minősül.
Érdemes-e letérni a meghatározott tesztelési ösvényekről? Igen, de az már egy másfajta tesztelés, az ún. felfedezéses tesztelés. Ez példánk kereteit már átlépi, ezért itt csak utalunk rá. Sok hiba úgy hozható elő, ha nem az előre elvárt sorrendben hajtanak végre művelteket, hanem véletlenszerű sorrendben. Ez egy kötetlenebb tesztelési forma, mely ad hoc cselekvéseken alapul, ezért nem feltétlenül lehet rá előre teszteseteket sem írni.
7.3.5. A tesztek „utóélete”
Egy teszt végrehajtása nem jelenti a tesztelési tevékenység végét, még akkor sem, ha a teszt hibátlanul végrehajtható volt. Ilyenkor is egy rövid, formális, vagy kevésbé formális (projektfüggő) összefoglalót kell írni a tesztről, melyet röviden, a tényekre alapozva fogalmazunk meg.
Amennyiben hibákat találunk, nagyon röviden ezekre is érdemes kitérni a jelentésekben. Amennyiben a hibát a programozóknak sikerült kijavítaniuk, a javítást ismét ellenőriznünk kell, a korábban a hiba által érintett teszt ismételt végrehajtásával.
7.3.6. A kreatív tesztesetekről
Olvasóink között biztosan vannak, akikben példánkkal összefüggésben felmerülnek más tesztek lehetőségei. Fontos kérdés, hogy milyen mértékben van szabad keze a tesztelőnek a tesztesetek számát illetően.
Elsőre talán azt gondolnánk, hogy a minőség érde-kében minden lehetséges tesztet érdemes végrehajtani. Lehetséges lenne-e ez a gyakorlatban? Nagy valószínűséggel: nem.
A tesztelőt a valóságban kötik azok a keretek, melyeket a tesztelés számára szerződésben is külön rögzíteni szoktak. A megrendelő azt szeretné kapni, amiért fizet. A kivitelező pedig legtöbbször csak azt a munkát hajlandó elvégezni, amivel megbízták. Az ok inkább a hibák potenciális bonyolultságában keresendő, melyek javítása jelentős többletköltségekkel és ráfordított idővel járhat mind a megrendelő, mind a kivitelező oldalán.
Mégis, mi a helyes magatartás hasonló esetben? Az, ha riportjainkban, beszámolóinkban felhívjuk a figyelmet az esetlegesen szükséges további tesztek fontosságára, azaz javaslatokat teszünk. Tapasztaltabb tesztelőktől ezt el is várják. Ebben az esetben tesztelőként a lehető legmesszebb elmegyünk, a döntés meghozatala azonban már a menedzserek, ill. az ügyfél kezében lesz. Minél nagyobb egy projekt, egy tesztelőnek annál kevesebb ráhatása van az üzleti döntésekre és sajnos annál nehezebb hallatnia a hangját is.
7.4. Szoftvertesztelés Magyarországon és a nagyvilágban
A szoftvertesztelés elmélete nagyon szép és dicséretes irányelveket ad a kezdő tesztelő kezébe, ám a gyakorlat sok tekintetben eltér ettől.
A kezdő tesztelőket általában sokkolja és felháborítja ez a tény. Az első és legfontosabb tanulság, amit az évek során megtanultam, hogy minden cég a saját folyamatainak keretei közé igyekszik beszuszakolni a fejlesztési és tesztelési módszertanokat. Közben bizonyos aspektusokra nagyobb, másokra, nos, mondjuk úgy, kevesebb hangsúlyt fektetnek. Egy biztos: nincs két ugyanúgy alkalmazott tesztelési gyakorlat.
Magyarországon a szoftvertesztelés már túllépett az első lépcsőfokon, a cégek ugyanis elismerik a tesztelés fontosságát.
Jelenleg a manuális tesztelésről az automatizált tesztelésre történő átállás a divat. Ez részben természetes és indokolt is, részben viszont a trendek sokszor ész nélküli követésével találkozhatunk. Jó példa erre, hogy sok cég egyenesen a manuális tesztelés automatizált teszteléssel történő kiváltását hangoztatja, ami nyilvánvalóan butaság, hiszen a két teszt nem konkurálhat egymással, lévén két egymást kiegészítő teszttípusról van szó. Nem azért kell manuális, vagy automatizált szoftvertesztelést alkalmazni, mert mindenki ezt szajkózza, hanem azért, mert mindkettőre szükség van.
A hazai helyzet még ennél is bonyolultabb, ugyanis a tesztelés szükségességének a felismerésétől az automatizált tesztek bevezetéséig terjedő skála minden szintjén találhatóak informatikai cégek. Egy-egy tesztelési program bevezetése gyakran egy vég nélküli, rosszul menedzselt bukdácsolás, mintsem professzionális szakmai tevékenység. (Rosszabb esetben a vezetők szerint a fejlesztőknek eleve tökéletes munkát kell végezniük.)
Igen, ez azt is jelenti, hogy vannak cégek, ahol a tesztelés szükségességét még bizonygatni kell a vezetőség előtt a lelkes alkalmazottaknak. Ilyen esetekben nem ritka, hogy torz munkaköröket hoznak létre, mint például a „fejlesztő-tesztelő”, ami szakmai abszurdum.
Ki kell mondani: a tesztelői munka teljes embert kívánó feladat!
Hasonlóan gyakori és súlyos hiba a tesztelési folyamatok szervezetlensége. A „történjen valami” nem terv, de tesztelés semmiképpen sem.
Külföldön egy kicsit jobb a helyzet, de akár Nyugat-Európában is gyakran találkozhatunk a fentiekhez hasonló bizonytalanságokkal. A különbség talán annyi, hogy tőlünk nyugatabbra egyre inkább professzionális, autonóm szakterületté kezd fejlődni a tesztelés, ahol a képzések és a gyakorlat egyaránt nagy súllyal esnek a latba és természetesebbek.
Hazánkban a tesztelésre többnyire még mint „lear-ning by doing” módon, menet közben elsajátítható ismeretekre építő, egyszerű betanított munkára tekintenek, mintsem hivatásra.
7.5. Tesztelés különböző platformokon
7.5.1. Tesztelés asztali számítógépeken
Az asztali számítógépes környezetben végzett tesztelés a leginkább elterjedt, mivel ilyen számítógépekkel nagyon sokan rendelkeznek otthon is. Ezek készség szintű használata, ismerete ezért nem okoz gondot egy átlagos tesztelőnek sem.
A kihívást itt elsősorban a fejlesztéshez használt technológiák dömpingjében történő eligazodás jelenti.
A trend egyértelműen a böngészős alkalmazások terjedése, a lokálisan telepített, ún. standalone alkalmazások száma csökken, bár eltűnni nem fognak, hanem egyre inkább speciálisabb területeken használják őket.
7.5.2. Tesztelés nagygépes környezetben
A legtöbb nagyvállalat szerverparkokat, szuperszámítógépeket üzemeltet, ahol speciális, szerverekhez kifejlesztett operációs rendszerek is üzemelnek, mint például a Microsoft Windows Server, a UNIX-alapú AIX, Solaris, Linux és társaik.
Ezen rendszerek, továbbá különféle adatbázisrendszerek alapvető ismerete mindenképpen szükséges egy tesztelő számára.
Ezek egyébként tipikusan multinacionális munkakörnyezetek, ezért az informatikai tudás mellett az idegen nyelvek ismerete is kiemelten fontos. Nem ritka, hogy más országokban dolgozó, más nyelvet beszélő kollégákkal kell együttműködni a tesztelés sikeres lebonyolítása érdekében. (A magyarországi tesztelők ezen a területen igen jóknak számítanak, nemzetközi viszonylatban is.)
7.5.3. Tesztelés mobileszközökön
A mobilfejlesztés felfutott üzletág lett ugyan, ám a mobiltesztelés mint olyan korántsem nevezhető egységes, elfogadott gyakorlatnak.
Mobilalkalmazásokat tesztelni nem egyenlő pusztán azzal, hogy az ember kézbe vesz egy okostelefont, vagy tabletet és elkezdi nyomkodni.
A mobilvilág nagyon heterogén, a kompatibilitás, egységesség biztosítása pedig állandó kihívás a fejlesztők számára. Ráadásul egy üzleti alkalmazás nem önmagában fut, hanem aktív kommunikációt folytat más rendszerekkel is. Egy mobilalkalmazás tesztelése ezért komplex integratív szemléletű feladat. Ebbe a kategóriába sorolhatjuk a weboldalak, webes alkalmazások mobileszközökre optimalizált változatait is.
Mobilalkalmazásokat valódi mobileszközökön, vagy asztali számítógépes szimulátor alkalmazásokkal is lehet tesztelni. A tesztmenedzser feladata (és felelőssége) eldönteni, hogy melyiket és milyen mértékben alkalmazzák a tesztelés során.
A tesztelést nem elegendő egyetlen típusú eszközön elvégezni, hanem több, különböző teljesítményű és tulajdonságú eszközre (vagy konfigurált szimulátorra) van szükség. A különbözőségeknek elsősorban a képernyők mérete, felbontása, az eszköz processzorának és háttértárolójának a kapacitása tekintetében van jelentőségük.
Megemlítjük, hogy a korszerű mobileszközökön szintén fontos kérdés a weboldalak, webes alkalmazások különböző elérhető mobilos böngészőkkel történő tesztelése.
7.6. Pár szó az XML formátumról
Az XML formátummal számos esetben találkozhatunk az informatikában, leírásával egész könyvek foglalkoznak.
Aki látta már a HTML oldalak forráskódját, annak jó kiindulási alap lehet az XML megértésében a HTML tag-ek szerkezete.
Az XML egy szöveges formátum, mely az adatokat szimbolikus nevek hierarchikus szerkezetébe ágyazva tartalmazza.
Vegyünk egy egyszerű példát! Példánkban térinformatikai adatok tárolását mutatjuk be. A tárolandó adat legyen egy buszmegálló, melynek pontos földrajzi koordinátája van, például ez: 19.05 és 47.23.
Ez XML-ben így is kinézhetne:
<object type=”bus stop”>
<coordinates>
<longitude> 19.05 </longitude>
<latitude> 47.23 </latitude>
</ coordinates >
</object>
A koordinátákat a longitude és latitude blokkokban adjuk meg, melyek egyértelműen jelzik, hogy mely koordináták a hosszúsági és melyek a szélességi koordináták. Mindkét koordináta egy nagyobb egység része, a coordinates blokké, ami egy másik blokkba, az objektum blokkba tartozik.
Az XML tagek rendelkezhetnek tulajdonságokkal (csakúgy, mint a HTML-ben), példánkban az objektum típusát adjuk meg („bus stop”).
Az objektumokat szintén nagyobb egységek alá rendelhetjük, például települések, megyék, országok stb. blokkokba. Egy adott szinten pedig több ugyanolyan elem is állhat.
<country>Hungary
<county>Borsod
<settlement>Kisváros
<object type=”bus stop”>
<coordinates>
<longitude> 19.05 </longitude>
<latitude> 47.23 </latitude>
</ coordinates >
</object>
<object type=”supermarket”>
<coordinates>
<longitude> 19.15 </longitude>
<latitude> 47.24 </latitude>
</ coordinates >
</object>
</settlement>
</county>
</country>
A fenti példában Magyarország Borsod megyéjén belül, „Kisváros” településen egy buszmegálló és egy szupermarket koordinátáit írjuk le.
Ez persze csak egy egyszerű példa. A lényeg az, hogy a <> blokkok között értékeket adhatunk meg, melyekhez további tulajdonságokat rendelhetünk.
Az XML egyszerű szerkezetével igen bonyolult össze¬függéseket írhatunk le és mindezt szöveges formában, azaz virtuálisan platformfüggetlen módon.
XML formátumban fájlokat is szokás tárolni, de ebben a formátumban adatok is utazhatnak hálózaton keresztül. Erre rengeteg kereskedelmi szolgáltatás épít.
Az XML formátumot legalább ilyen szinten illik ismernie minden tesztelőnek.
7.7. Tesztelést támogató szoftverek a gyakorlatban
A manuális és automatizált tesztelést támogató szoftvereknek se szeri, se száma. Szinte mindenre van egy szoftveres megoldás.
Pár szót ejtünk két igen elterjedt szoftverről, a SOAP UI és a JIRA alkalmazásokról. A példák önkényesek, hiszen még számos más, hasonló tudású szoftvert használnak szerte a világon.
7.7.1. Általános tesztdokumentációs rendszer
7.7.1.1. Bevezetés
Készítettem egy tanulásra és demonstrációs célokra használható tesztdokumentációs minirendszert, mely egyelőre böngészőből érhető el, a weboldalamon keresztül. A nyílt forráskódú Flex keretrendszerben készült, böngészős futtatásához Flash player szükséges. A saját készítésű rendszer teljesen ingyenesen hozzáférhető. Mivel működő rendszerről van szó, testreszabott formában akár éles projekteknél is használható. A nyilvános változat néhány egyszerű megkötést tartalmaz, például ki vannak kapcsolva a törlési műveletek.
Előnye az ingyenesség mellett egyszerűsége: nagyon könnyen megérthető vele a tesztrendszerek működése, még laikusok számára is. Technikai hátterét Apache webszerver és MySQL adatbázis adja, melyet PHP szkriptek segítségével ér el a rendszer.
Példánkban bemutató jelleggel fogjuk használni a rendszert, logikusan haladva projektet hozunk létre, majd csapattagokat a fejlesztői csapat számára. Ezeket tesztesetekhez, ill. hibajegyekhez is rendelhetjük majd.
Az alkalmazás kezdőképernyőjén érhetjük el a főbb funkciókat.
7.7.1.2. Projektek kezelése
Az alkalmazás kezdőképernyőjén válasszuk ki a 'Manage Projects' lehetőséget! Ekkor a projektek adminisztrációs felületére jutunk, ahol projektjeink listája látható. Kezdetben ez üres. Lehetőségünk van létrehozni, módosítani és törölni projekteket.
Az egyszerűség kedvéért a projektek egyetlen tulajdonsággal rendelkeznek, ez a nevük. Kattintsunk a 'Create' gombra egy új projekt létrehozásához!
A 'New Project' oldalon adjunk meg egy nevet, első projektünk neve legyen „Project A”! Kattintsunk a 'Create' gombra! Ekkor visszakerülünk a projektek listáját tartalmazó oldalra. A lista immár tartalmazza új projektünket is.
Hozzunk létre egy másik projektet is, „Project B” néven! Most már két projekttel rendelkezünk.
A projektek neveit egyszerűen frissíthetjük. Ehhez először ki kell választanunk a projektet a listánkból, majd az 'Edit' gombra kell kattintanunk. Ekkor frissíthetjük a projekt nevét, amit az 'Update' gombra történő kattintással nyugtázhatunk.
Nevezzük át a „Project A” projektet „Project 1”-re, és a „Project B”-t „Project 2”-re!
Ha mindent jól csináltunk, projektjeink már az új névvel szerepelnek a listában.
Térjünk vissza a főképernyőre a 'Cancel' gombra történő kattintással!
7.7.1.3. Csapattagok kezelése
Az alkalmazás kezdőképernyőjén válasszuk ki a 'Manage Team' lehetőséget! A csapat adminisztrációs felülete teljesen megegyezik a projektek kezelésével.
A projekteknél megismert módon hozzunk létre két tagot. Példánkban ez legyen a „Tester 1” és „Tester 2”!
Ha elkészültünk, térjünk ismét vissza a kezdőképernyőre!
7.7.1.4. Tesztesetek létrehozása
Most már van két projektünk és két tesztelőnk is. Ezek segítségével már létrehozhatunk teszteseteket és hibajegyeket is. Az előbbivel kezdjük. Ehhez az alkalmazás kezdőképernyőjén válasszuk ki a 'Manage Test Cases' lehetőséget!
Mint látjuk, a tesztesetek kezelőfelülete nagyban hasonlít a projektek és a csapattagok adminisztrációs felületéhez.
Azonban három új elemet is találunk itt:
1. Tesztesetekhez tesztlépéseket adhatunk.
2. Projektekre szűrhetünk tesztesetet.
3. Teszteseteket csapattag-hozzárendelések szerint szűrhetünk.
Az utolsó két lehetőséggel villámgyorsan szűréseket hajthatunk létre teszteseteinken, így mindig csak azokat látjuk, amelyek érdekelnek minket. Erre az ad lehetőséget, hogy minden tesztesethez projektet és egy csapattagot kell rendelnünk.
A két szűrőlista tartalma mindig dinamikusan frissül, azaz csak olyan csapattagok és projektek nevei választhatóak ki, melyek garantáltan léteznek.
Erről egyszerűen megbizonyosodhatunk, ha például lenyitjuk az 'Assignee' listát. A lista a „Tester 1” és „Tester 2” elemeket tartalmazza, ezeket hoztuk létre korábban. Mindkét szűrőlista tartalmaz egy „All” elemet is, ez az alapbeállítás is egyébként. Kiválasztva az alkalmazás a lista összes elemét figyelembe veszi a tesztesetek kilistázásánál.
A 'Test Steps' gomb csak akkor működik, ha már létrehoztunk legalább egy tesztesetet és ki is választjuk azt a listából. Ezt fogjuk tenni most. Kattintsunk a 'Create' gombra! A megjelenő ablakban meg kell adnunk tesztesetünk nevét, azt, hogy mely projekthez tartozik, melyik csapattaghoz rendeljük és mi a teszteset státusza.
A fenti példában a „Teszteset 1” tesztesetet a „Project 1” projekthez rendeltük, az egyes tesztelőhöz. A teszteset státusza „New”, azaz „Új” lesz.
A beállítható státuszok:
• New: Újonnan létrehozott teszteset.
• In Preparation: A teszteset előkészítése, kidolgozása folyamatban van.
• Ready: A teszteset készen áll a végrehajtásra.
• In Progress: A tesztvégrehajtás folyamatban van.
• Passed: A tesztvégrehajtás sikeres volt.
• Failed: A tesztvégrehajtás sikertelen volt.
• Blocked: A tesztvégrehajtás akadályozva, blokkolva van.
• Not applicable: A teszt nem hajtható végre. Ennek többnyire valamilyen külső oka lehet.
7.7.1.5. Tesztlépések kezelése
Ha már létrehoztunk legalább egy tesztesetet, azokhoz tesztlépéseket hozhatunk létre, melyek pontosan leírják, hogy az adott tesztet hogyan kell végrehajtani. Az alábbi képen már két tesztlépést hozzáadtunk tesztesetünkhöz és éppen a harmadikat is készülünk hozzáadni.
Új tesztlépést az 'Add' feliratú gombbal tudunk hozzáadni a tesztesetünkhöz, de ehhez meg kell adnunk a tesztlépés számát ('Step Number') és a lépés leírását.
A már létrehozott tesztesetek az „All test steps” listában találhatóak. A tesztesetek sorrendje a lépések számozásától függ. Egy lépést így át tudunk helyezni pusztán a lépés számának frissítésével is.
Egy tesztlépés módosításához előbb ki kell választanunk a listából. Ezután frissíthetjük az 'Update' gombbal, vagy akár törölhetjük is a 'Remove' gombra kattintva.
Tesztlépést másolni úgy tudunk, hogy kiválasztjuk, majd az 'Add' gombra kattintunk. Érdemes mindig növekvő számozást alkalmazni a tesztlépésekhez. Jó gyakorlat, ha például eleve tízesével tesszük ezt, így a későbbiekben könnyű beszúrni újabb lépéseket is.
Vegyük észre, hogy minden tesztlépéshez egy státuszt rendelhetünk. Ezeket a 'Set status' felirat alatti listában találhatjuk. Egyszerűen csak ki kell választanunk a kívánt státuszt. Az alapértelmezett érték az „In Preparation”.
A tesztlépések lehetséges értékei:
• In Preparation: A tesztlépés kidolgozása folyamatban van.
• Ready: A tesztlépés elkészült.
• Test in Progress: A tesztlépés éles tesztvégrehajtás alatt van.
• Passed: A tesztlépés végrehajtása sikeres volt.
• Failed: A tesztlépés végrehajtása sikertelen volt.
• Blocked: A tesztlépés végrehajtása akadályozva, blokkolva van.
• Not applicable: A tesztlépés nem alkalmazható az adott teszt során, valamilyen külső okból.
Első ránézésre feleslegesnek tűnhet az a lehetőség, hogy mind teljes tesztesetekhez, mind egyes tesztlépésekhez külön is beállíthassunk státuszokat.
A gyakorlatban ez a lehetőség nagyon is indokolt. Bonyolult tesztek végrehajtása ugyanis sokszor napokig, extrém esetben akár hetekig eltarthat. Ilyenkor bizonyos tesztlépések már kiértékelhetőek, mások viszont még végre sincsenek hajtva. A státuszok segítségével gyorsan képet lehet kapni egy teszteset végrehajtásának állapotáról.
Gyakorlásképpen hozzunk létre egy újabb tesztesetet, hozzá tartozót tesztlépésekkel!
7.7.1.6. Hibajegyek létrehozása
Amint azt a korábbi fejezetekben már megismertük, a hibajegyek segítségével a tesztelés során talált hibákat szokás rögzíteni. A hibajegyek létrehozásához és kezeléséhez az alkalmazás kezdőképernyőjén válasszuk ki a 'Manage Tickets' lehetőséget!
A megjelenő ablak két fő részre osztható. A bal oldalon a hibajegyek listája található. A lista tartalmazza a hibák státuszát, az utolsó módosításuk dátumát és a jegyek címét. Többféle szűrőt is találunk itt, melyekkel a jegyhez rendelt személy, a projekt, a prioritás és a státusz alapján is szűrhetjük a jegyek listáját.
Ha kiválasztunk egy jegyet a listából, a jobb oldalon jelennek meg a beállításai. Legfelül a jegy címe, azaz rövid leírása található, alatta pedig a részletes hibaleírás. A jegy projektje, a hozzárendelt személy neve, a prioritás és a státusz is automatikusan beállí-tódik. A kiválasztott hibajegyet az 'Update' gombbal frissíthetjük, illetve a 'Delete' gombbal törölhetjük.
Szintén a jobb oldali beállítások segítségével új hibajegyet is készíthetünk a 'Create' gomb segítségével.
A hibajegyekhez az alábbi prioritásokat rendelhetjük:
• LOW: alacsony fontosságú hiba.
• NORMAL: átlagos fontosságú hiba.
• HIGH: kiemelt fontosságú hiba.
A lehetséges státuszok:
• Open: Új hibajegy, melynek a feldolgozása még nem kezdődött meg.
• Assigned: Személyhez rendelt jegy, melynek a feldolgozása folyamatban van, vagy a hiba kijavítása után tesztelésre vár.
• Testing: A hibajavítás tesztelése folyamatban van.
• Closed: A hibajavítás tesztelése sikeresen befejeződött.
7.7.1.7. Riportkészítés
Az alkalmazás kezdőképernyőjén a 'Show Reports' lehetőséget kiválasztva különféle adatok jeleníthetőek meg, melyek a tesztesetekről és a hibajegyekről mutatnak számszerűsített információkat.
Egy komplex jelentéskészítés ennél többet szokott jelenteni, jellemzően, gyakoriak a grafikonok és sok más összefüggés kimutatása is.
7.7.1.8. Megjegyzések
A fenti eszközökkel igen jól menedzselhető munkafolyamatokat alakíthatunk ki és hatékonyan támogathatjuk a tesztelést. A bemutatott alkalmazás egy, a teszteléssel történő ismerkedésre használható eszköz, de éles munkára is átalakítható.
A következőkben megismerkedünk két kereskedelmi szoftverrel, melyeket éles tesztelésnél előszeretettel használnak.
A webes alkalmazás megismerése nem öncélú volt. Számos módszer vissza fog köszönni ezeknél a szoftvereknél is, ezeket most már sokkal könnyebben értelmezni tudjuk.
7.7.2. SOAP UI
7.7.2.1. Letöltés és telepítés
A SOAP UI ingyenes és kereskedelmi verzióban is elérhető, számos teszt típust és többféle technológiát támogat. A kereskedelmi verzió segítségével egyebek mellett könnyebben állíthatunk össze teszteket, de az ingyenes verzió is tökéletesen alkalmas tesztelésre.
A szoftvert az alábbi oldalról érhetjük el és tölthetjük le: http://www.soapui.org/downloads/soapui/open-source.html
A telepítés egy varázsló segítségével bonyolítható le. A telepítő első oldalán kattintsunk a Next feliratú gombra!
Ezután a felhasználási feltételek elfogadása és a telepítés helyének kiválasztása következik.
Többféle telepíthető komponenst kiválaszthatunk. Az alapértelmezett beállítások általában megfelelőek a legtöbb feladatra.
A szoftver oktatóanyagokat is telepít a számítógépre, ezek helyét szintén megadhatjuk.
A telepítés záró lépései megegyeznek a legtöbb windows alkalmazás telepítésével.
A folyamat végén még hírlevélre történő felirat-kozási lehetőséggel is találkozthatunk, ez természetesen nem kötelező.
7.7.2.2. Online tananyagok
A webes oktatóleckéket az alkalmazás Help – Getting Started menüpontjával is megnyithatjuk.
7.7.2.3. Ismerkedés a SOAP UI-al
Az alkalmazás első indításakor a főképernyőt láthatjuk. Ennek két legfontosabb része a bal oldali navigációs terület, ahol projektjeink szerkezetében lépkedhetünk.
Az ablak nagy részét a különböző szerkesztő-ablakok foglalják el a jobb oldalon. Itt módosíthatunk beállításokat és szerkeszthetjük tesztjeink adatait.
A File – Pre¬fe¬rences me¬nü¬pont se¬gítsé¬gé¬vel fontos be¬állításokat esz¬közölhetünk. Ezek közül a há¬lózati beállí¬tá¬sok a kiemelten fontosak.
7.7.3. SOAP UI projekt létrehozása
A SOAP UI-ban projekteket hozhatunk létre, melyek számos tesztfeladatot egy egységbe fognak össze. Ebben a leírásban webszolgáltatások használatán keresztül mutatjuk be a SOAP UI projektek létrehozását és alapszintű használatát.
Először is indítsuk el az alkalmazást, majd válasszuk ki a ‘File’ menü ‘New SOAP Project’ menüpontját!
Ezt követően egy párbeszédablak jelenik meg, melyben nevet adhatunk a projektnek és itt adhatjuk meg a WSDL elérhetőségét is. A projekt neve tetszőleges név lehet.
A WSDL esetünkben ez lesz: http://wsf.cdyne.com/WeatherWS/Weather.asmx?WSDL
Példánkban időjárási adatokkal kapcsolatos web-szolgáltatást fogunk meghívni.
Kattintsunk az OK gombra!
A SOAP UI ekkor hosszabb-rövidebb ideig elemzi a szolgáltatás leíróját.
Ezen információk alapján a projekthez automatikusan hozzáadódnak a rendelkezésre álló szolgáltatások teszthívásai. Esetünkben ezek a GetCityForecastByZIP, GetCityWeatherByZIP és a GetWeatherInformation lesznek.
Megjegyezzük, hogy WSDL-t nem kötelező megadni projekt létrehozásakor. Ezt bármikor pótolhatjuk az ’Add WSDL’ menüponttal, melyet a projekt nevére történő jobb kattintással felhívott helyi menüből választhatunk ki.
Ezzel sikeresen létrehoztuk első SOAP UI projektünket!
7.7.4. A projekt finomhangolása
Újdonsült projektünk nevére duplán rákattintva a projekt legfontosabb beállításait megjelenítő ablak jelenik meg.
Ehhez hasonlóan, a projekthez tartozó szolgáltatás nevére történő dupla kattintással az adott szolgáltatás beállításait tekinthetjük meg.
7.7.5. Teszthívás létrehozása a projektben
A navigátor ablakban a ConversionRate melletti + jelre kattintva megjelenik egy ’Request1’ listaelem, ami egy automatikusan létrehozott teszthívás.
Ilyen teszthívásokat mi magunk is készíthetünk, ehhez kattintsunk a jobb egérgombbal a szolgáltatás nevére, majd válasszuk ki a ’New Request’ lehetőséget!
Szintén a teszthívások nevére a jobb egérgombbal kattintva többféle műveletet hajthatunk végre ezeken, például át is nevezhetjük azt.
7.7.6. Teszteset létrehozása és végrehajtása
Az előzőekben létrehozott projektünkkel fogunk tovább dolgozni. Kattintsunk duplán az előzőekben létrehozott ’Request1’ teszthívásunkra!
A megnyíló ablakban már közvetlenül szerkeszt-hetjük a teszthívásunkat, ami XML formátumú. Mielőtt azonban ezt megtennénk, létrehozunk egy tesztesetet. Ehhez kattintsunk a ‘Hívás hozzáadása tesztesethez’ gombra (angolul: ‘Add this request to a TestCase’) !
A megjelenő párbeszédablakban a létrehozandó tesztesetünket tároló tesztgyűjteménynek (‘TestSuite’) kell nevet adnunk, ez példánkban “Tesztcsomag” lesz.
Az OK-ra kattintva a teszteset nevét is meg kell adnunk, legyen például “Teszteset1”!
Az OK-ra kattintva tesztesetünk első tesztlépését hozhatjuk létre. Ez esetünkben egyetlen lépés lesz, melynek a „Teszthívás” nevet adjuk most.
Ha mindent megadtunk, a SOAP UI felületén ehhez hasonló képet kell kapnunk:
Látható, hogy projektünk szerkezetében egy új logikai egység jött létre, ’Tesztcsomag’ néven, mely tartalmazza a ’Teszteset1’ tesztesetünket és a ’Teszthívás’ nevű tesztlépést is.
A tesztesetünk részleteivel a jobb oldalon egy újabb ablak is megnyílt.
7.7.7. Teszt futtatása
Egy meglévő tesztesetet a 
gombra történő kattintással tudunk lefuttatni. Ezt akár azonnal meg is tehetjük. Pár másodperc után a teszt lefut.
gombra történő kattintással tudunk lefuttatni. Ezt akár azonnal meg is tehetjük. Pár másodperc után a teszt lefut.A ’FINISHED’, azaz „végrehajtva” felirat zöld lesz, azaz sikeres a végrehajtás. Ez nem is csoda, hiszen nem is adtunk meg teszteredményre vonatkozó feltételt, így mindenképpen sikeres tesztről beszélhetünk. A feltételek megadásának módját hamarosan megismerjük, de előbb nézzük meg, mi történt a háttérben!
Kattintsunk duplán a Teszthívás-ra a bal oldali navigációs ablakban! Így megjelenik a SOAP UI által a webszolgáltatást futtató szerverre küldött üzenet és a válasz is, mert a teszt futtatásával ez is automatikusan megtörténik. A jobb oldali mezőben látható a szerver válasza.
Ezt a kérést küldtük el a szervernek:
<soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/" xmlns:weat="http://ws.cdyne.com/WeatherWS/">
<soapenv:Header/>
<soapenv:Body>
<weat:GetWeatherInformation/>
</soapenv:Body>
</soapenv:Envelope>
A válasz pedig ez lett (a kapott XML formátumú üzenetet rövidítve közöljük):
<soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xsd="http://www.w3.org/2001/XMLSchema">
<soap:Body>
<GetWeatherInformationResponse xmlns="http://ws.cdyne.com/WeatherWS/">
<GetWeatherInformationResult>
<WeatherDescription>
<WeatherID>1</WeatherID>
<Description>Thunder Storms</Description>
<PictureURL>http://ws.cdyne.com/Weat-herWS/Images/thunderstorms.gif</PictureURL>
</WeatherDescription>
<WeatherDescription>
<WeatherID>2</WeatherID>
<Description>Partly Cloudy</Description>
<PictureURL>http://ws.cdyne.com/Weat-herWS/Images/partlycloudy.gif</PictureURL>
</WeatherDescription>
…
…
<WeatherDescription>
<WeatherID>37</WeatherID>
<Description>AM CLOUDS</Description>
<PictureURL>http://ws.cdyne.com/Weat¬herWS/Ima-ges/partlycloudy.gif</PictureURL>
</WeatherDescription>
</GetWeatherInformationResult>
</GetWeatherInformationResponse>
</soap:Body>
</soap:Envelope>
A válasz időjárási információkat tartalmaz, szolgáltatáshívásunkkal hívásunkkal ezt kértük le. A szolgáltatás a GetWeatherInformation volt.
7.7.8. Hívások kézi módosítása
Az előző példában a szolgáltatás hívása egy alapértelmezett XML kérésen keresztül történt. A valóságban számos paraméter is szerepelhet az XML-ben.
Következő példánkban a GetCityWeatherByZIP hívást fogjuk kézzel módosítani. A SOAP UI bal oldali navigációs sávjában keressük meg ezt a szolgáltatást, majd dupla kattintással nyissuk meg a szolgáltatáshívás (request) szerkesztőablakát!
Az XML kérés ehhez hasonló lesz:
<soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/" xmlns:weat="http://ws.cdyne.com/WeatherWS/">
<soapenv:Header/>
<soapenv:Body>
<weat:GetCityWeatherByZIP>
<!--Optional:-->
<weat:ZIP>?</weat:ZIP>
</weat:GetCityWeatherByZIP>
</soapenv:Body>
</soapenv:Envelope>
A szolgáltatást így meghívva az alábbi választ kapjuk.
<soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xsd="http://www.w3.org/2001/XMLSchema">
<soap:Body>
<GetCityWeatherByZIPResponse xmlns="http://ws.cdyne.com/WeatherWS/">
<GetCityWeatherByZIPResult>
<Success>false</Success>
<ResponseText>Invalid ZIP</ResponseText>
<State/>
<City/>
<WeatherStationCity/>
<WeatherID>-1</WeatherID>
<Description/>
<Temperature/>
<RelativeHumidity/>
<Wind/>
<Pressure/>
<Visibility/>
<WindChill/>
<Remarks/>
</GetCityWeatherByZIPResult>
</GetCityWeatherByZIPResponse>
</soap:Body>
</soap:Envelope>
A válasz SUCCES node-jának értéke FALSE. Ez azt jelenti, hogy a hívás nem volt sikeres. A hiba szöveges formában is meg van adva: „Invalid ZIP”, azaz érvénytelen irányítószámot adtunk meg. Ez igaz is, hiszen a kérésünkben ennek értéke „?” volt.
Megjegyezzük, hogy a hibákat más XML szerkezetekben is visszakaphatjuk, például „faultID”, „faultstring” node-ok közé zárva.
Most megismételjük a hívást, de ezúttal érvényes irányítószámot adunk meg. Ez 10007 lesz, ami New York-hoz tartozik.
Tehát:
<soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/" xmlns:weat="http://ws.cdyne.com/WeatherWS/">
<soapenv:Header/>
<soapenv:Body>
<weat:GetCityWeatherByZIP>
<!--Optional:-->
<weat:ZIP>10007</weat:ZIP>
</weat:GetCityWeatherByZIP>
</soapenv:Body>
</soapenv:Envelope>
A kérésre adott válasz ezúttal eredményes lesz, számos, New Yorkkal kapcsolatos időjárási adatot kapunk vissza a válaszban:
<soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xsd="http://www.w3.org/2001/XMLSchema">
<soap:Body>
<GetCityWeatherByZIPResponse xmlns="http://ws.cdyne.com/WeatherWS/">
<GetCityWeatherByZIPResult>
<Success>true</Success>
<ResponseText>City Found</ResponseText>
<State>NY</State>
<City>New York</City>
<WeatherStationCity>White Plains</WeatherStationCity>
<WeatherID>15</WeatherID>
<Description>N/A</Description>
<Temperature>63</Temperature>
<RelativeHumidity>87</RelativeHumidity>
<Wind>E7</Wind>
<Pressure>29.97S</Pressure>
<Visibility/>
<WindChill/>
<Remarks/>
</GetCityWeatherByZIPResult>
</GetCityWeatherByZIPResponse>
</soap:Body>
</soap:Envelope>
7.7.9. Teszeteredmények kiértékelése
A tesztek futása nem csak sikeres-sikertelen eredmények megállapításával végződhet. A SOAP UI lehetőséget kínál arra, hogy a válaszokat különböző szempontok alapján kiértékeljük. Ez lehet tartalmi, vagy formai kiértékelés is.
Utóbbi lehet például a válaszidő elemzése. Erre mutatunk be egy utolsó példát.
A navigációs sávban keressük meg a tesztlépések között a „Teszthívás”-t és dupla kattintással nyissuk meg!
A kérés indítására használható gomb mellett kattintsunk a „Feltétel hozzáadása” gombra, ami egy zöld plusz jel. A feltétel a SOAP UI terminológiájában az ún. assertion.
Megjelenik egy párbeszédablak, melyben különböző feltételeket adhatunk meg.
Válasszuk ki az ‘SLA’-t, majd a a jobb oldalon a ’Response SLA’ elemet! Ezt követően a párbeszédablakban kattintsunk az ’Add’ gombra!
Ezután meg kell adnunk a válaszidő felső határát, ami esetünkben legyen 500 ezredmásodperc, azaz fél másodperc!
Nyissuk meg tesztesetünket, majd futtassuk le azt! A teszt ezúttal sikertelen lesz, mert ahogyan a lenti képen is látható, a válasz 1347 ezredmásodpercig tartott, ami jóval több, mint a megadott 500 ezredmásodperc.
Vegyük észre, hogy a „Teszthívás” elemünk színe szintén pirosra változott! Válasszuk ki ezt az elemet, majd nyissuk meg!
A kérés ablakának alsó részén azt olvashatjuk, hogy a szerver válasza valid, azaz érvényes volt, ám a teszt feltétele nem teljesült.
Kattintsunk duplán a „Response SLA - FAILED” sorra és adjunk meg egy nagyobb értéket, mondjuk 1500 másodpercet!
A sor egyből zöld színű lesz, de a teszt újrafuttatásával is meggyőződhetünk a teszt sikerességéről.
Természetesen a teszt feltételének módosítása éles teszt során nem változtatna semmit azon a tényen, hogy a szerver válasza alacsonyabb az elvártnál. Példáinkban csupán a SOAP UI alapszintű megismertetése volt a cél.
7.7.10. JIRA
A JIRA napjaink egyik legelterjedtebb folyamatmenedzselő rendszere. Támogatja fejlesztési, tesztelési folyamatok tervezését, nyomonkövetését és kiértékelését is.
A rendszer támogatja továbbá a felhasználói profilokat is, így egy projekt minden szintjének résztvevője testreszabott módon férhet hozzá a projekttel kapcsolatos adataihoz.
Az alkalmazás nagymértékben testreszabható, így minden projekt a saját szájíze szerint alakíthatja a működését és bizonyos keretek között a megjelenését is. A JIRA bővíthető is, számos beépülő modult fejlesztenek hozzá.
Mindezek mellett általános jegykezelő és tesztmenedzsment rendszerként is használható. Hazánkban sok nagyvállalat és kisebb vállalkozás is előszeretettel használja, ezért nagy valószínűséggel találkozhatnak vele a magyarországi tesztelők is.
7.7.10.1. Elérhetőség
A JIRA egy online, alapvetően webes felületre optimalizált alkalmazás. Egy fizetős szoftverről van szó, ám a rendszer alapfunkcióit bárki kipróbálhatja, ugyanis magának a JIRA-nak a fejlesztését is JIRA-val támogatják, sőt hibákat is egy e célból létrehozott nyilvános rendszeren keresztül lehet bejelenteni.
Ennek az elérhetősége: https://jira.atlassian.com
7.7.10.2. Ismerkedés a kezelőfelülettel
A rendszer nyitóképernyője a Dashboard, mely gyakran tartalmaz aktuális információkat az aktuális, futó projektről.
A nyitóoldal tartalma is testreszabható egyébként, előszeretettel jelenítik meg itt a felhasználók legutóbbi aktivitásait is, amit a felületre bejelentkezve mindenki láthat.
A JIRA rendelkezik egy főmenüvel, melynek legfontosabb elemei a bal felső sarokban találhatóak:
A három legfontosabb, mindennap használatos menüpont a következő.
A Dashboards menüponttal különféle összefoglaló, áttekintő oldalakra juthatunk. Ez projektfüggő.
A Projects alatt több projekt is szerepelhet, attól függően, hogy a felhasználó milyen más projektekhez van még hozzárendelve.
Az Issues menüpont a hibajegyek kezeléséhez enged hozzáférést. Itt kereshetünk és hozhatunk létre hibajegyeket is.
A Projects egyik menüpontjára kattintva megjelenik egy vertikális szimbólumsor is a bal oldalon. Ezzel további, általános oldalra juthatunk, például a projektriportokhoz.
A Reports szimbólumot kiválasztva különböző, a projekt adataiból kinyert grafikont, összefoglalót tekinthetünk meg.
A riportok tartalma természetesen testreszabható.
7.7.10.3. Jegykezelés
Talán a jegyek kezelése az a vezérfonal, ami köré a JIRA többi folyamata is felépül, ezért a jegyek kezelése alapfontosságú készségnek számít. A jegyek nem csak hibajegyek lehetnek, hanem bizonyos feladatokat is leírhatnak. A lényeg minden esetben az, hogy egy bizonyos munka minden munkafázisban végigkövethető legyen.
Az ‘Issues’ – ‘Search for issues’ menüpontot kiválasztva az aktuális projekt összes jegyének listája megjelenik.
A lista tulajdonképpen nem más, mint a JIRA adatbázisának a megjelenítése. A lista oszlopainak fejlécei vannak, melyekre rákattintva rendezéseket kezdeményezhetünk a listában.
Az oszlopok láthatósága testreszabható és meg-lehetősen sok van belőlük.
A lista nézet kiváló, ha gyors áttekintésre van szükségünk a feldolgozásra váró jegyekről, ám rész-letek itt nem jelennek meg.
A jegyek lista nézetét az ablak jobb felső részében elhelyezkedő beállítás szimbólumra kattintva válthatjuk át részlet nézetre.
Ebben az elrendezésben jóval több minden látszik. Bal oldalon a hibajegyek azonosítója, címe látható egy listában, a jobb oldalon pedig minden adat elolvasható, amit a hiba bejelentője megadott.
Ha a felhasználó jogosultsága megengedi, a jegyek tartalma azonnal módosítható is. Fejlesztők, illetve tesztelők álatlában rendelkeznek ilyen jogosultsággal.
7.7.10.4. Keresések
Az egyszerű kulcsszavas keresések mellett nagyon fontos, hogy a projekt résztvevői (így a tesztelők is), komplexebb kereséseket is végre tudjanak hajtani a JIRA-ban rögzített elemeken.
A legegyszerűbb keresés a kulcsszavas keresés. A keresett kulcsszót a „Contains text” szövegmezőbe írhatjuk be.
A nagyító ikonra kattintva a keresés már így is elindítható, de a ’More’ gombra kattintva megadhatjuk azt is, hogy mely mezőkre hajtódjon végre a keresés.
Az ‘Advanced’ linkre kattintva még összetettebb kereséseket hajthatunk végre. Ilyenkor egy hosszabb szöveges beviteli mező jelenik meg, ahová mezőneveket és logikai kifejezéseket is megadhatunk.
A beviteli mező gépelés közben intelligens javaslatokat tesz a még gyorsabb bevitel érdekében. Egy kifejezés megadása MEZŐNÉV EGYEZŐSÉGJEL ÉRTÉK hármassal történik, például: Name = Lajos
A kifejezések között kapcsolatokat is megadhatunk, ez általában ÉS szokott lenni (AND). Íly módon több kifejezést is összekapcsolhatunk.
Az alábbi példában a Documentation típusú je-gyeket keressük, de csak azokat, melyek egy bizonyos prio¬rítással rendel¬kez¬nek. Ehhez az AND kulcsszót használjuk.
A JIRA lehetőséget kínál arra, hogy kereséseinket névvel ellátva, profilunk adataként eltároljuk. Ehhez természetesen előbb be kell jelentkeznünk.
A keresések találati listája ugyanolyan felépítésű, mint a fentebb tárgyalt listák. Ugyanarról a listáról van szó, csak ez keresésünk eredményeit tartalmazza.
7.7.11. További szoftverek
Bár a korábbi kedvcsinálóval a konkrét szoftverek bemutatásának végére értünk, óriási mennyiségű, ingyenes és kereskedelmi szoftver hozzáférhető manapság, melyekkel a szoftvertesztelés teljes munkafolyamata lefedhető.
Azt, hogy ezek közül melyiket használják egy cégnél, az részben szakmai, részben üzleti-pénzügyi döntés. Ez utóbbinak köszönhetően szinte mindenhol a kész megoldásokat preferálják, egyedi fejlesztésekkel is lehet találkozni, de ezek igen ritkák.
7.8. Dokumentációs minták
Az alábbiakban tesztesetek és tesztkiértékelésekre mutatunk lehetséges mintákat, melyeket éles munkák során sablonként is használhatunk.
Ezek a példák erősen gyakorlatias szempontokat követnek és azonnal alkalmazhatóak.
7.8.1. Tesztesetek megfogalmazása
Példánkban egy egyszerű dokumentumkezelő alkalmazás egyik elképzelt tesztjének pár lépését mutatjuk be, minta jelleggel.
Különösen kezdő tesztelők számára nagyon fontos, hogy legyen egy kézzelfogható minta, ami vezérfonal a munkájukhoz.
A tesztesetek neve utaljon a teszt tárgyára! Ha komplexebb tesztekről van szó, érdemes a teszteket nevükben is csoportosítani, mint például: Navigáció, Beolvasás, Nyomtatás stb.
Példa: Teszteset_Navigáció_#1
Maguk a tesztlépések több logikai egységből is állhatnak. A Leírás tartalmazza a tesztelő által végrehajtandó tevékenységet.
Használunk egy Megjegyzés oszlopot is, mely elsősorban a tesztelő számára szolgál hasznos kiegészítő információkkal a tesztvégrehajtáshoz.
Az elvárt eredmény leírásának félreérthetetlenül egyértelműen tartalmaznia kell annak a leírását, hogy mikor számít sikeresnek a teszt.
Példánkban számozva szerepel mindegyik tesztlépés.
Tesztlépés | Leírás | Megjegyzés | Elvárt eredmény |
1. | Az alkalmazás elindítása, a parancsikonjára történő dupla kattintással. | Győződjünk meg arról, hogy az alkalmazás működéséhez van-e elegendő háttértár kapacitás! | Az alkalmazás hiba nélkül elindult. |
2. | Az alkalmazás főablakában válasszuk ki a Fájl menüpont Megnyitás menüpontját. | Megjelenik a Do-kumentum megnyitása dialógusablak. | |
3. | A Fájl megnyitása dialógusablak segítségével vá-lasszunk ki egy dokumentumot, majd kattintsunk a dialógusablak Megnyitás nyomógombjára. | Használjuk a teszt.doc tesztdokumentumot! | A dokumentum betöltődött és tartalma megjelent az alkalmazás ablakában. |
7.8.2. Teszteredmények dokumentálása
A teszteredmények dokumentálását mindig adott projektre kell szabni. Éppen ezért csak gondolatébresztőként mutatunk be egy egyszerű táblázatos szerkezetet, mely jó kiindulási alap lehet teszteredmények rögzítésére.
Ha e célból rendelkezésre áll külön szoftver, akkor mindenképpen azt kell használni.
Egy dolgot nem tehetünk meg: a teszteredményeket nem dokumentálni.
Szoftver | Verzió | Teszt neve | Teszt végrehajtási ideje | Teszteredmény |
Webshop | 1.0.0 | Bejelentkezési_teszt | 2 perc | Sikeres |
Webshop adatbázis | 0.9.1 | Termék_hozzáadása_kosárhoz | 1 perc | Hibás |
8. Minőségbiztosítási receptek
Egy jó tesztelő nem csupán végrehajtja a rá bízott feladatokat, hanem képes javaslatokat is tenni a szoftver minőségének növelésére, konkrét folyamatok javítására. Itt elsősorban a minőségbiztosítási folyamatokra kell gondolni.
Az alábbiakban összeállítottunk egy javaslat-, vagy sokkal inkább receptcsomagot, melyet számos vállalkozás, cég használhat a tesztelés és a minőségbiztosítás javítására. Minden esetben egy hibás, vagy alacsony hatékonyságú kiindulási helyzetet veszünk alapul, majd javaslatot is megfogalmazunk a helyzet javítására.
A leírások között sok tesztelő, esetleg fejlesztő a saját munkahelyén tapasztalható hiányosságokat is találhat. Ez a fejezet bátorítani is kívánja őket abban, hogy javítsanak a munkahelyükön a minőségbiztosítási folyamatokon.
8.1. A tesztelés hiánya
Elsősorban kisebb cégeknél közkedvelt megoldás fejlesztőkre bízni a tesztelést. Ez a gyakorlat a fejlesztők idejét pazarolja, másrészt pedig igen kis hatékonyságú tesztelést tesz csak lehetővé, részben az időhiány, részben pedig a szakmai képzettség, gyakorlat hiányából fakadóan.
Javaslat
Lehetőleg minél hamarabb hivatásos, de mindenképpen elfogulatlan, főállású tesztelőket kell alkalmazni. Minél tovább elodázódik ez a döntés, annál költségesebb és lassabb lesz a szoftver minőségét elfogadható szintre hozni.
8.2. A teszt tervezésének elmaradása
A tesztek tervezésére nincsen idő elkülönítve, a tesztelőknek azonnal el kell kezdeniük az új funkciók tesztelését. Ezt gyakran a tesztelők már meglévő tapasztalatával indokolják.
Javaslat
A tervezési fázis nem csupán az ismert funkciók teszteléséről, hanem a nem-funkcionális és járulékos előfeltételekről, kockázatokról is lerántja a leplet. A teszteket a fejlesztési munkák megkezdése előtt el kell kezdeni tervezni, a tesztelőket, vagy legalább a tesztmenedzsert be kell vonni a kapcsolódó megbeszélésekbe.
8.3. Tesztelés és fejlesztés különválasztása
A fejlesztői oldal már létszámában is többségben van. Gyakorta előfordul, hogy a programozók, vagy a fejlesztések vezetője egyik másik tesztnek nagyobb fontosságot tulajdonít, míg mások végrehajtását igyekszik gátolni, esetleg a talált hibák „elkendőzésére” tesz kísérletet.
Javaslat
A tesztelés a fejlesztés része, de autonóm tevékenység kell, hogy legyen. Mindenféle befolyásolás súlyosan veszélyeztetheti a szoftver minőségét. Ennek a veszélynek az elhárítását legtöbbször a tesztmenedzser hivatott biztosítani. Hiányában a tesztelők igen kiszolgáltatott helyzetbe kerülhetnek.
8.4. Tesztmenedzsment hiánya
Azon cégek, melyek már alkalmaznak tesztelőket, gyakran igyekeznek „házon belül”, szakember nélkül megoldani a tesztelés koordinálását. Nem ritka, hogy egy tapasztalt fejlesztőre bízzák ezt. Ez legjobb esetben is hiányos eredményekhez vezet.
Javaslat
A tesztelés menedzselt tevékenység kell, hogy legyen. Erre külön tesztmenedzsereket, esetleg ún. SCRUM mastereket alkalmaznak, akik elkötelezettek a tesztelés iránt és tesztelői oldalról közelítenek a projektekhez.
8.5. Tesztcélok hiánya
A tesztelők a feladataikról csak annyi információt kapnak, hogy „tesztelni kell az új verziót”.
Javaslat
Teljes körűen egyetlen szoftvert sem lehet soha letesztelni, ezért fontos, hogy a tesztelés célja és tárgya definiálva legyen. Ez ideális esetben írásban is rendelkezésre áll. A tesztcélok meghatározása a tesztmenedzser feladata.
8.6. Dedikált tesztkörnyezet hiánya
A kizárólag tesztre használt számítógépek gondolatát tapasztalatlan vezetők általában kétkedéssel kezelik. Nem ritkák az ehhez hasonló reakciók: „Miért nem jó egy kiszuperált gép?”, „Használjátok az egyik fejlesztői számítógépet, ha éppen nincsen használatban!”, „Ez túl drága mulatság nekünk, nem engedhetjük meg magunknak!”
Javaslat
Egy tesztelésre nem felkészített számítógép nem megfelelő teszteredményeket fog szolgáltatni. Valójában egy rossz tesztkörnyezet az igazi pénzpocsékolás, ami ráadásul be is csap mindenkit, így egy dedikált tesztgéppel valójában pénzt lehet spórolni.
8.7. Tesztadatok hiánya
Tapasztalt tesztelők ódákat (vagy inkább drámai hőskölteményeket) tudnának zengeni arról, mennyire komolytalanul kezelik egyik-másik fejlesztési projektben a tesztadatokat és ez mekkora többletmunkát tud utólag eredményezni. Némi fanyar iróniával úgy is mondhatnánk, hogy a tesztelőknek gyakran bűvészmutatványokat kell bemutatniuk: szinte a semmiből valamilyen eredményt kell kicsiholniuk.
Javaslat
Egy lelkiismeretes tesztelőt már azzal is boldoggá lehet tenni, ha pontosan leírják, hogy milyen adatokat kell használnia. Még jobb, ha minták is rendelkezésre állnak. A legjobb azonban, ha mindig naprakész elvárások és leírások állnak rendelkezésre a tesztadatokat illetően. Ezek elkészítésében természetesen a tesztelők maguk is nagy örömmel részt vesznek. Nem hisszük? Próbáljuk ki!
8.8. Dokumentáció hiánya
A fejlesztett szoftver kézikönyve, specifikációja hiányos, elavult, vagy ad absurdum nem létezik.
Javaslat
A tesztelés végrehajtása során egy elvárt eredményt hasonlítunk össze aktuális eredményekkel. Fontos tehát, hogy egyértelműen rögzítsük az elvárt eredményeket (hogy hogyan kell működnie az alkalmazásnak), különben a tesztelés nem több puszta erőlködésnél és színjátéknál.
8.9. Fejlesztések dokumentálásának hiánya
A fejlesztések tervei és az megvalósításai időben nem visszakereshetőek.
Javaslat
Egy-egy hiba keresésénél rendkívül fontossá válhat annak ismerete, hogy egy adott fejlesztés mikor került bele a szoftverbe. Ezt valamilyen formában, visszakereshető módon dokumentálni kell.
8.10. Manuális és funkcionális tesztelés különválasztása
A manuális tesztelést és az automata tesztek karbantartását, végrehajtását ugyanarra a tesztelőre bízzák.
Javaslat
A manuális tesztelés közvetlen céljai és feltételei merőben különbözőek lehetnek és mindkettő teljes embert kíván. A legrosszabb kombináció az 50-50 százalékos felosztás, ebben az esetben ugyanis a tesztelőnek esélye sincsen arra, hogy bármelyik területtel mélyebben foglalkozzon.
8.11. Tesztesetek nem megfelelő dokumentálása
Jelentős költségmegtakarító tényezőnek tartják a tesztelést támogató szoftverek „kispórolását” a projektekből. A különböző táblázatkezelők csak kisszámú feladat dokumentálására alkalmazhatóak és korlátozottan. Mégis gyakran használják komplex feladatok, például tesztesetek tárolására is. Ez a gyakorlatban nem ér többet, mint egy halom papírfecni, amire félmondatokat firkálunk.
Egy középvállalat vezető tesztelője egyszer azt mondta nekem: „A szöveges táblázat mindent elbír”. Sajnos ez súlyos tévedés.
Javaslat
A tesztesetek létrehozására célszoftvert kell alkalmazni minden tesztelés esetén. Ez az újrafelhasználást és a kiértékeléseket is lehetővé teszi, ill. elősegíti a hosszú távú, „újrahasznosítható” tesztelési munkát.
8.12. Teszteredmények dokumentálásának hiánya
A tesztek eredményeiről gyakorta legfeljebb e-maile-ket szokás írni, de ezek további rögzítése elmarad. Sok információ „szájhagyomány” útján terjed.
Javaslat
A tesztek eredményei nem csak egy adott fejlesztési periódusban értékesek, hanem később is. Számos esetben a teszteredmények csak hosszabb távon mutatnak ki bizonyos hibákat a szoftverekben.
8.13. Teszteredmények kiértékelése hiányzik
A teszteredmények kiértékelésével nem foglalkozik senki, összefüggéseket senki nem von le, emiatt (is) gyakori, hogy bizonyos típusú hibák mindig visszatérnek a szoftver tesztelése során.
Javaslat
A tesztek eredményei összefüggnek, számszerűsíthetőek és időben ábrázolva további, mélyebb következtetések levonására adnak lehetőséget. Minden lehetséges eszközzel, de inkább célszoftverrel érdemes elemezni a teszteredményeket. Egy ilyen rendszer többnyire megegyezik a tesztek rögzítésére használt szoftverrel.
8.14. Feladatok delegálása
Hirtelen felmerülő határidők, ismeretlen funkciók tesztelésének azonnali igénye, „tegnapi” határidős feladatok felbukkanása.
Javaslat
Nemcsak a tesztelés során, hanem általában is megvan a módja a feladatok kiosztásának. A vezetőknek tisztában kell lenniük legalább 5 alapfeltétellel, melyek a számonkérés alapját képezhetik. Ezek: ki, mit, milyen eszközökkel, hogyan, milyen határidővel végez el. Számonkérésnek csak abban az esetben van értelme, ha ezeket a kérdéseket tisztáztuk és megbeszéltük a feladat végrehajtásával megbízott munkatárssal, esetünkben a tesztelőkkel.
A tesztelő felelőssége, hogy megfelelő információk hiányában ne vállaljon el hiányosan megfogalmazott feladatokat.
9. Tesztelői kisszótár
Agilis fejlesztés: a projektben dolgozó csapatok együttműködésére építő fejlesztési módszertan.
Átadási teszt: általában ügyféloldalon végrehajtott teszt, melynek célja, hogy az ügyfél megbizonyosodjon arról, hogy azt kapja, amit megrendelt.
Debugging: a szoftver felügyelt módban történő futtatása, részletes elemzési lehetőségekkel. Fejlesztőeszközökben elérhető lehetőség.
Dinamikus tesztelés (dynamic testing): a szoftver futásidejű tesztelése.
Elfogadási teszt: a szoftver átadását megelőző átfogó teszt, melynek során a szoftverrel szemben támasztott kritériumok kerülnek tesztelésre.
Elvárt eredményeket (expected result): a teszt sikeres kimenetelének leírása.
Fehér doboz tesztelés (white box testing): a szoftver kódját figyelembe vevő, vagy egyenesen azt célzó tesztelés.
Fekete doboz tesztelés (black box testing): egy adott szoftver belső szerkezetét nem figyelembe vevő tesztelés.
Felfedezéses tesztelés (exploratory testing): ad hoc jellegű, nem folyamat központú tesztelés.
Felhasználási folyamatleírások (user story): egy adott üzleti folyamat felhasználói szemszögből történő leírása.
Funkcionális specifikáció: a szoftver egyes funkcióinak részletes leírása, beleértve a működés feltételeinek megadását is.
Funkcionális teszt: egyes szoftverfunkciók működésének tesztje.
Komponensteszt: szoftverkomponensek tesztje.
Hiba (bug, fault, defect): konkrét, kimutatható hibajelenség.
Hiba érvényessége: a hiba mivoltának meghatározása.
Hibajelentés (bug report): teszt során talált hiba technikai leírása.
Hibás működés (failure): hibajelenségből eredő, az elvárttól eltérő működés.
Hibázás (error, mistake): a hiba létrehozásának folyamata.
Hotfix: gyorsjavítás száma.
Integrációs teszt: szoftverkomponensek együttműködésének tesztje.
Kick-off meeting: projektindításkor, teszt fázis indításakor megtartott megbeszélés.
Minőség: egy adott (szoftver) termék tulajdonságainak összessége, mely azt jellemzi.
Minőségbiztosítás (quality assurance, QA): olyan tevékenységek összessége, melyek a fejlesztett szoftver tervezett minőségét hivatottak biztosítani.
Negatív teszteset (negative test case): szoftverek hibakezelésének, hibatűrésének tesztelésére összeállított teszteset.
Nem-funkcionális teszt: a szoftver járulékos, nem egyes funkciókhoz köthető tulajdonságainak tesztje.
Prioritás: fontosági sorrend.
Priorizálás: fontossági sorrend felállítása.
Product owner („terméktulajdonos”): vezető a projektben, aki egy adott megoldás (program modul, vagy teljes szoftver) kifejlesztéséért felel.
Projektkoordinátor: a projekt résztvevői közötti információáramlásért, a felmerülő általános igények jelzéséért felelős személy.
Projektmenedzser: a projekt sikeres lebonyolításáért felelős vezető.
Regressziós teszt: annak tesztje, hogy új funkció nem okozott-e hibát már korábban is elérhető funkciókban.
Release: szoftverkiadás száma.
Rendszerteszt: egy rendszer (hardver és szoftver) teljes funkcionalitását célzó teszt.
Review: felülvizsgálat, melynek során programozók, vagy tesztelők egymás munkáját ellenőrzik.
SCRUM: az agilis módszertanokhoz tartozó fejlesztési mód, mely erősen csapatközpontú.
Scrum master: a SCRUM csapat működéséért felelő szervező, aki a fejlesztők és a tesztelők munkáját is támogatja.
Sprint: fejlesztési ciklus a SCRUM-on belül, tipikusan egy hetet ölel fel.
Statikus tesztelés (static testing): olyan tesztelési technika, melynek során a tesztelt szoftver nem fut (forráskódelemzés, dokumentáció ellenőrzése stb.).
Strukturális teszt: lásd fehérdoboz tesztelés.
Súlyosság: hiba kihatásának jelzésére szolgál.
Szürke-doboz tesztelés (grey box testing): egy adott szoftver belső szerkezetét figyelembe vevő tesztelés.
Teszt dizájn (test design): konkrét teszt, teszteset előkészítését célzó tevékenység.
Teszteset (test case): logikailag összetartozó tesztlépések összessége, egysége.
Tesztfuttatás (test execution): logikailag összetartozó tesztlépések végrehajtása.
Tesztkiértékelés (test evaluation): teszt végeredményének meghatározása.
Tesztkoordinátor, tesztvezető: a tesztelés napi szintű, operatív végrehajtásáért felelős személy, egy, esetleg több csapaton belül.
Tesztkörnyezet (test environment): valós rendszert szimuláló infrastruktúra.
Tesztlépés (test step): a teszteset elemi végrehajtási egysége, mely tartalmazza az elvárt eredmény leírását is.
Tesztmenedzser: a tesztelés zökkenőmentes lebonyolításáért felelős vezető.
Tesztriport (test report): teszt kimenetlének összefoglalása, számszerűsített adatokkal alátámasztva.
Teszt szcenárió (test scenario): üzleti követelményekből levezetett összefoglaló leírások.
Teszt státusz (test status): a teszt végkimenetelének, eredményének megnevezése.
Tesztstratégia: a teszt céljait, módszereit, feltételeit, a felelősségköröket meghatározó dokumentum.
Teszt terv (test plan): teszt végrehajtásának írásos vázlata.
Teszt-vezérelt fejlesztés: olyan programozási módszer, melynek során a programkódot eleve a későbbi tesztelhetőség szempontjait figyelembe véve készítik el.
Teszt záró riport (test exit report): általában több teszt eredményeit összefoglaló és kiértékelő, nagyobb lélegzetvételű dokumentum.
Üzleti elemző (business analyst): üzleti folyamatok technikai szintre történő lefordítását segítő szakember.
Üzleti folyamat (business process): egy adott üzleti cél eléréséhez szükséges tevékenységsorozat.
Üzleti követelmény (business requirement): üzleti folyamatok alkalmazásához, végrehajtásához szükséges előfeltételek.
V-modell: fejlesztési modell, melynek egyes fázisai lineárisan, szekvenciálisan követik egymást.
Verzió: egy szoftver időben különböző változatainak jelzésére szolgáló szám.
Vezető fejlesztő: egy csapaton, vagy projekten belül a legtöbb tapasztalattal rendelkező programozó.
Vezető tesztelő (test lead): nagy tesztelői- és projekt tapasztalattal rendelkező tesztelő, aki aktívan részt vesz a mindenkori tesztstratégia kialakításában és a tesztek levezénylésében.