IKT Projektmunka I. - 1/13.C 2. csoport

Mi a szoftvertesztelés?

A szoftvertesztelés a szoftverfejlesztési folyamat önálló része, ami szorosan kíséri a fejlesztés folyamatát. A szoftvertesztelés egy rendszer vagy egy program kontrollált körülmények melletti futtatása, és az eredmények kiértékelése. Feladatai közé tartozik a fejlesztők és a döntéshozók tájékoztatása, a fejlesztés állapotának mérése és a kockázatkezelés/kockázatbecslés.

A szoftvertesztelés a szoftver jellemző tulajdonságait vizsgálja, minőségbiztosítási tevékenység. Felhasználói szemszögből:"Mennyire alkalmas a felhasználó céljára? " Tesztelői szemszögből: „Mennyire egyezik a specifikációval?” A szoftverek tesztelését megtervező, végrehajtó és az eredményeket kiértékelő szakember a szoftvertesztelő, vagy tesztmérnök.

A tesztelés, célja, emberi vonatkozásai, anyagi előnyei

A szoftverfejlesztés célja a tesztelt szoftver minőségének értékelése és jobbítása, a hibák korai felfedezése/megelőzése, és ezáltal a költségek csökkentése.

A tesztelés elsődleges célja a hibák megtalálása és dokumentálása. Minél korábban derül fény egy hibára, annál olcsóbb annak korrigálása.

Másik fontos cél a döntés-előkészítés támogatása: 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.

Elvárás/cél lehet még a szoftverminőség mérése. A minőség az a mérték, amennyire a program, a része vagy egy folyamat megfelel a követelményeknek. A tesztelés a kockázatok becslését és menedzselését is magába foglalhatja (főleg az Agile Programming esetén).

A tesztelés emberi vonatkozásai:

A hiba fogalma

Hibázás (error, mistake): hibajelenség létrehozásának, létrejöttének a folyamata.

Hiba (defect, fault, bug): konkrét, kimutatható hibajelenség.

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)

Debugging (hibakeresés, nyomkövetés): a szoftver felügyelt módban történő futtatása hibakeresés céljából a programozó által, a szoftver alkotóelemeinek ellenőrzésére. Ez nem minősül tesztelésnek. 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.

Tesztelés

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 az 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 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.

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 szimulálja. 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. Éles rendszert tesztelésre használni tilos!

Üzleti követelmény

Az üzleti követelmény (business requirement) üzleti folyamatok leírása, a megrendelő üzleti igényei alapján (pl. banki szoftver esetében ügyfél hitelkérelmének elfogadása).

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.

Teszt forgatókönyv

A teszt forgatókönyv (test scenario) az üzleti követelményekből levezetett összefoglaló leírás. 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.

Teszt eset

A teszt eset (test case) a tesztvégrehajtás során elvégzendő, logikailag összetartozó teszttevékenység. 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

Tesztlépés

A tesztlépés (test step): a teszteset egyes elemi tevékenysége, további lépésekre nem bontható. Ezáltal a hiba visszakereséséhez, javításához elegendő egyetlen lépést megvizsgálni. A tesztlépés két legfontosabb szerkezeti egysége:

• A végrehajtandó tevékenység leírása.
• Az 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, például tesztadatok megadását, további megjegyzéseket a végrehajtáshoz.

Review

Review (felülvizsgálat): az elkészített tesztesetet egy másik tesztelő leellenőrzi, hogy 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ögzített 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.

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 sorrendjét 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. Példa:

Tesztlépések megfogalmazása

• Rövid, tömör, lehetőleg egymondatos megfogalmazásokat használjunk („Kattintson a ’Befejez’ feliratú gombra! Az ablak bezáródik.”)
• Soha ne használjunk feltételes módot!
• Mindig használjunk felszólító, ill. kijelentő módot.
• Kerüljük a nem egyértelmű szavakat és kifejezéseket, pl. probléma, működik.
• Ne hivatkozzunk máshová vagy kifelé („Lásd itt és itt”)

Negatív tesztesetek

A negatív tesztesetek a hibatűrés ellenőrzésére irányul, cél a hibajelenség elérése (pl. biztonsági teszteknél)

Tesztelés fázisai

• Tervezés
• Elemzés
• Tesztdizájn
• Végrehajtás
• Kiértékelés
• Tesztjelentés elkészítése

A tesztek megtervezése

A tesztek végrehajtását gondos tervezés előzi meg. 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ést a tesztmenedzser, vagy a vezető tesztelő készít el. A tesztterv nem részletes technikai megvalósításokat taglal, hanem folyamatokat ír le, témaköröket mutat be. 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 módosítható a résztvevők javaslatai alapján. Fontos, hogy a teszttervben vegyük figyelembe a fejlesztőknek észrevételeit, módosító javaslatait.

Teszt tervezés sprintekben

Tesztek tervezésére nemcsak projektek induló fázisában, hanem sprintekben (SCRUM rendszerben) 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.

Tesztelemzés

A teszt végrehajtóinak a tesztterv céljai és végrehajtásának feltételei alapján tételesen meg kell vizsgálniuk, hogy a teszt kivitelezhető-e. Az elemzés során a teszt egyes részeinek a priorizálása is megtörténik. Fontos feltételek: tesztkörnyezet előkészítése, beszerzendő teszteszközök feltérképezése is.

Tesztdizájn, előkészítés

A tesztdizájn során a végrehajtandó tesztek tesztlépések szintjén vannak 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ő tesztelő szoftver beállítása.

Tesztvégrehajtás

A tesztek végrehajtása (lefuttatása) során eredményt kapunk. 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.

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, elvárt teszteredményeket hasonlítják össze a tényleges tesztvégrehajtás eredményeivel. A kiértékelésről egy rövid összegző jelentés készül, 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.

Tesztelést támogató tevékenységek

A tesztelés sikerességét befolyásoló fontos tényezők a tesztkörnyezet karbantartása és a tesztadatok előállítása. A tesztkörnyezet karbantartása egy kizárólag tesztelésre dedikált számítógép felügyeletét és folyamatos naprakészen tartását jelenti. A nem aktuális vagy hibás tesztadatok hibás teszteredményeket produkálnak, ami rengeteg időt vesz el (nyomozgatás) és plusz költségeket okoz.

Priorizálás

A Priorizálás egy fontossági sorrend meghatározása, ami alapján az egyes teszteket el kell végezni. Ennek egyik célja a hibák mihamarabbi felfedezése.

Statikus tesztelés

Statikus tesztelés esetén a tesztelők a rendelkezésre álló szoftverspecifikációk, tervek alapján már a tesztek végrehajtása előtt elkészítik a tesztjeik tervét, meghatározzák a tesztek elvárt eredményeit, felmérik, hogy a szoftver egyáltalán tesztelhető-e a tervezett módon, eszközökkel.

A statikus tesztelés során a szoftver forráskódjának / 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 lehethajtani. Automatizált ellenőrzésekre speciális forráskódelemző segédprogramok is használhatók.

Dinamikus tesztelés

Dinamikus tesztelés a szoftverek futtatásán alapuló tesztelés, amikor a szoftver tesztkörnyezteben fut. Nemcsak a fejlesztési fázisban, hanem annak teljes életciklusán keresztül alkalmazható.

Fekete doboz tesztelés

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:

• Értékhatárok és értéktartományok tesztelése.
• Üzleti folyamat alapú technikák.
• Logikai mátrix alapú teszt.

Fehér doboz tesztelés

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:

• Döntési ág alapú tesztek.
• Utasítás-lefedettség alapú technikák.

Szürke doboz tesztelés

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.

Felfedezéses tesztelés

A tesztelő a teszt során ismeri meg a szoftvert úgy, mint egy kezdő felhasználó. 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.

Manuális tesztelés

A tesztelő számítógépnél teszteseteket hajt végre, 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ó.

Automata tesztelés

Az automatizált tesztek emberi beavatkozás nélkül hajtódnak végre. Technikai hátterük változatos: szkriptek, programozási nyelvek, speciális segédprogramok. 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.

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

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.

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 a scrum master felel, míg az operatív irányításért a vezető fejlesztő. A csapathoz ideális esetben egy üzleti elemző is tartozik, aki az üzleti folyamatok oldaláról érti a szoftver működését. Tesztelési szempontból több csapat összehangolt tesztelői tevékenységét a tesztmenedzser végzi, aki teljes munka 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és (daily standup meeting) elsődleges célja annak tisztázása, hogy milyen feladatok lesznek az adott napon és általában hogyan halad a csapat a munkájával a terhez képest.

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.

Komponensteszt

A komponenstesztek tipikusan izoláltan is végrehajtható tesztek egyszerűbb programok, szoftvermodulok, vagy programozási egységek, például osztályok vonatkozásában. Mivel ez a tesztelési szint erősen forráskód közeli lehet, így gyakori, hogy a tesztelésben aktívan segédkezik maga a forráskód írója is. A 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.

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. Különösen nagyobb rendszereknél fontos a fokozatos, egymásra épülő tesztelés, mert átgondolatlan vagy hanyag megközelítéssel nehéz és tovább tarthat a hibák valódi okának megállapítása, ami jelentős és felesleges költségeket okozhat.

Rendszerteszt

A rendszertesztek tulajdonképpen az éles működésű rendszert hivatottak modellezni és vizsgálni ahhoz minél jobban hasonlító tesztkörnyezetben. É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 rendszer egészének a működését vizsgálják, kevésbé az egyes funkcionalitásokra.

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 feladatát az elvárt módon. Ezeket 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.

Funkcionális teszt

A funkcionális tesztek a szoftver előre meghatározott / dokumentált, konkrét funkcióit vizsgálják. Ezek a tesztek tipikusan ún. feketedoboz tesztek, amelyek a szoftver belső struktúrájának ismerete nélkül, mintegy „kívülről szemlélődve” kerülnek végrehajtásra. 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 célszerű 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.

Nem funkcionális teszt

A nem-funkcionális teszt a szűkebb-tágabb értelemben vett szoftver számszerűsíthető ismérveit vizsgálja; azt elemzi, 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.

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.