| Bemutatkozás | Projekt terv | Vízió | SRS | Szótár | AnalizisModell | Rendszer tervezés | Teszt tervezés |
|---|
Mint minden terméknél is, így a WorkNet végpéldányánál is elengedhetetlen lépés a tesztelés. A tesztelés különböző szempontok szerint történhet, melyek más-más célokra vonatkoznak. A fejlesztői teszt legfőbb célja, hogy a lehető legtöbb meghibásodást felszínre hozza. Ezzel az esetleges szoftverhibákat felismerjük és javíjuk. Bizonyos esetekben a tesztelés fő célja a szoftver minőségének elemzése. Gyakran arra vonatkozó teszteket végezünk, hogy a változtatások során nem kerültek-e be újabb hibák a rendszerbe. A teszt fő célja a rendszer olyan jellemzőinek elemzése lehet, mint például a megbízhatóság vagy rendelkezésre állás. A hibakeresés és a tesztelés két különböző fogalom. A teszt kimutathatja a programhibák által okozott meghibásodásokat, a hibakeresés pedig egy fejlesztői tevékenység, mely során felderítjük a hibák okát, kijavítjuk a kódot és ellenőrizzük, hogy a hibát megfelelően orvosoltuk-e. Ezt követően egy újrateszteléssel bizonyosodunk meg arról, hogy a javítás eredményes volt-e.
A tesztelés nem egy egyszeri, és nem egy egylépcsős folyamat, hiszen hibátlan program nincs, csak fel nem fedezett hiba. A tesztelés hét alapelvének megfelelően az alábbiakra kell ügyelnünk a folyamat során:
Bár a tesztelés kimutathatja a hibák jelenlétét, nem képes igazolni, hogy nincsenek hibák. A teszteléssel csökken annak az esélye, hogy a szoftverbe felfedezetlen hibák maradnak, de ha nem találnak hibát, az nem annak a bizonyítéka, hogy a rendszer tökéletes.
Kimerítő teszt – azaz mindenre (a bemenetek és előfeltételek minden kombinációjára) kiterjedő tesztelés nem lehetséges. A kimerítő teszt helyett kockázatelemzést és prioritásokat kell alkalmazni, ezáltal növelve a teszttevékenységek összpontosításának hatékonyságát.
A tesztelést a lehető legkorábban el kell kezdeni. Ez számunkra kiváltképp fontos, ugyanis a későbbiekben csökkenthetjük a tesztelésre szánt időt. Elképzeléseink szerint minden egyes programrészen két tagunk fog dolgozni: egy aki fejleszti és egy aki vele párhuzamosan teszteli azt.. Ezen a ponton több szempont szerint is lehet tesztelni, de a fejlesztésnek ezen stádiumában a programkód helyességének ellenőrzése a legfontosabb.
A tesztelést a feltételezett, illetve a megtalált hibák eloszlásának megfelelően kell koncentrálni. A kiadást megelőző tesztelés során a megtalált hibák többsége néhány modulban van, vagy legalábbis ezen modulok felelősek a működési hibák többségéért.
Ha mindig ugyanazokat a teszteket hajtjuk végre, akkor az azonos a tesztkészlet egy idő után nem fog új hibákat találni. A „féregirtó paradoxon” megjelenése ellen a teszteseteket rendszeresen felül kell vizsgálnunk, és új, eltérő teszteseteket kell írnunk annak érdekében, hogy a szoftver vagy a rendszer különböző részei kerüljenek futtatásra, és ezáltal további programhibákat találhassaunk.
A tesztelést különböző körülmények esetén különbözőképpen kell végrehajtsuk. Itt a legrelevánsabb példa a rendszerkövetelmény tesztek illetve a különböző stressz-tesztek végrehajtásának menete. Különböző szituációkban a program másképpen reagálhat és ellenőrizni kell, hogy ezekben az állapotokban mennyire megbízható a futás és megőrzi-e a stabilitást. Minden ilyen helyzetben más-más kimeneti eredményekkel fog végződni a teszt folyamat.
A hibák megtalálása és javítása hasztalan, ha a kifejlesztett rendszer használhatatlan, és nem felel meg a felhasználók igényeinek, elvárásainak. Ezalatt az elvi helyesség, illetve a megfeleléso helyesség ellenőrzését értjük. Ha a program nem azt csinálja amire igény van, akkor hiába fut hibamentesen, attól még elvi hibás.
Bementei/kimeneti hibák
Logikai hibák
Számítási hiba
Interface hiba
Adathiba
Ahogyan a bevezetésben már taglaltuk, a tesztelés nem elhagyható, nem lehet egyszeri és nem feltételezhetjük programunkról sosem azt, hogy hibátlan. A szoftverfejlesztés menetének és dokumentációjának kihagyhatatlan eleme ez. A kezdeti költségmegszorítások és határidők szem előtt tartásával kell ezen folyamatot is deklarálnunk: Fontos, hogy a lehető legeffektívebben a lehető legkevesebb iterációval hajtódjon le a folyamat, mindemellett a lehető legnagyobb pontossággal. Továbbá arra is figyelnünk kell, hogy szoftverünk nem egy egy verziós program, hanem iteratív, tehát minden kiadott változtatás után az új modulok és funkciók valamint azok a rendszer egészére gyakorolt hatásait is ellenőriznünk kell. A tesztelés időigényes és a munkálatoknak jól behatároltnak és a lehető legtöbb esetre kitérőnek kell lennie. Törekednünk kell a transzparenciára és az alapelvek szem előtt tartására, mindemellett a viszonylagos gyorsaságra is.
Korábbiakban említettük, hogy a fenti szigorú kritériumok mindegyikének megfelelni esetünkben úgy a legegyszerűbb, ha több szintre bontjuk a tesztelést:
A tesztelés ezen kezdeti stádiumában a program tervezett felépítésének helyességét kell tesztelni. Végig kell venni milyen funkciókat kell képes legyen a szoftver végrehajtani és milyen környezeti egységben fog funkcionálni majd. Az elkészült rendszertervet és dokumentációt (révén hogy a fejlesztési arculatunk többlépcsős, így először annak kell megszületnie) ezekkel az igényekkel összevetve ellenőrizni kell, hogy azok megfelelőek-e valamint a terv nem tartalmaz ellentmondásokat és logikátlan pontokat. Megfelelő elképzelés vagy hibás tervezés esetén maga a végeredmény sem lesz működőképes, így ez kiemelten fontos.
Az itt elhangzottak a későbbi iteratív fejlesztésben is fontosak: a kiadott verzió utáni elégedettségfelmérés során javasolt bővítéseket be kell gyűjteni és elbírálni azokat.
A kódhelyesség tesztelés a tesztelés második folyamati eleme. A dokumentációk elkészülte és ellenőrzése után következik a feladatkiosztás a fejlesztői csapatban. Fejlesztési arculatunkhoz híven minden egyes fejlesztő egyszerre egy modulon dolgozik, megfelelve a modulra megszabott kritériumoknak. Az ezen elgondolásnak köszönhetően fejlesztőink figyelme jobban összpontosul egy feladat legyőzésére és a munka jobban elosztott a csapatban (ám fontos a koordináció). A fejlesztők a modul írása közben jobban észreveszik saját hibáikat is, így mondhatni ez az első tesztelési és javítási szint. Mindegy egyes fejlesztő munkáját párhuzamosan ellenőrzi egy tesztelő kollega is, és a modulban észlelt hibákat dokumentálja és közvetíti a hibát a fejlesztő felé, hogy az javításra kerüljön. Ez a folyamat egy modul teljes elkészüléséig folyamatosan ismétlődik. A tesztelés ezen pontjában a kód elvi helyességét valamint a nyelvtani helyességét vagyunk képesek kiszűrni.
Az elkészült és tesztelt modulok ezután beépítésre kerülnek a program fő szálába, ahol egy adott küszöb limit után a tesztelő csapat ellenőrzi a modulok közti kollaboráció fennállását, a kollaboráció helyeségét valamint az esetleges modulhibákat és hiányosságokat. Az érzékelt hibákat dokumentálják, majd a felelős fejlesztőt értesítik a hiba javításáról. Ezen a szinten az elkészült alegységek utóhelyesség ellenőrzését tudjuk elvégezni, valamint az alegységek egymással való kapcsolatának létrejöttét és működését lehet remekül ellenőrizni kód- és elvi helyesség szintjén.
A folyamatot bezárólag, ha minden modul elkészült és beépítésre került itt esik sor az első fontosabb verzió dokumentálásra és az adott verzió a fentiekben leírt tesztelésének is. Ha hiba van addig folytatódik a folyamat amíg már nem találnak újabbat. Itt fontos megemlíteni azt is, hogy ugyanez a procedúra érvényes a későbbi fejlesztések beiktatásánál is, melyről részletesebb említést az Iteratív tesztelés alpontban olvashat. Továbbá, ha olyan modulról van szó, ami a többi modul kiszolgálója vagy rendszer alegység, és a tesztelési folyamat már lezajlott rajta, akkor az ezen kategóriába eső egységeket a fejlesztés gyorsítása érdekében továbbítani lehet a következő alállomásra, ahol a funkcionális és stabilitási mutatókat elemezzük ki rajtuk.
Ezen a szinten a bizonyos rendszer alegységek vagy komplett program verziók - amelyek átestek a második tesztelési ponton - folytatólagosan további, a tesztelési követelményekben megszabott esteknek megfelelő tesztjei zajlanak. A dokumentációkban leírt kritériumoknak a szoftvernek meg kell felelnie és ezen a ponton történik a szoftver alávetése ezen kritériumoknak. Itt történik a funkciók összesített ellenőrzése, hogy azok helyesen valamint hibamentesen működnek-e. Továbbá itt ellenőrizzük a szoftver környezeti és egyéb elvárási feltételeknek való megfelelését különböző stressz tesztek alkalmazásával. Mi esetünkben az alábbi feltételek és azokon értelmezett tesztelési esetek kerülhetnek szóba:
A dokumentációban megadott hardverspecifikáció limiteken való ellenőrzés, hogy azokon a szoftver megfelelően és stabilan képes-e futni. Ezen felül az alul és felül haladási esetei ezen limiteknek. Ha itt hiba lép fel, akkor dokumentáció után jelezni kell a fejlesztő csapatnak, hogy további optimalizálásra van szükség a megfelelő futás eléréséhez.
Meg kell vizsgálni, hogy a rendszer egészében mekkora felhasználó számmal képes megbirkózni egyszerre. Itt gondolni kell az ugrásszerű vagy az exponenciális felhasználószám növelésre való reagálásra: Ellenőrizni kell, hogy a program hogyan reagál a bizonyos esetekre, dokumentálni kell a lehető legnagyobb részletességgel, és ha esetleges hiba lép fel azt jelezni kell a fejlesztő csapatnak. Itt lehet azt is ellenőrizni, hogy a rendszer az ígért felhasználó mennyiséget képes-e eltűrni, vagy ha nem akkor további optimalizálásra vagy hardvererősségre van szükség.
Szoftverünk egyik kulcsfontosságú eleme az adatbázis rendszer. Nem csupán az ipari szabványoknak, de ugyanakkor a gyorsasági és adathelyességi elvárásoknak is meg kell felelnie. Itt ellenőrzendő a helyesség, stabilitás és gyorsaság. Ha ezekkel valamilyen probléma van dokumentáció után jelezni kell a felelős fejlesztőknek, hogy optimalizálják, vagy javítsák kódjaikat.
Az adatok megfelelő titkosítását és rejtését biztosítani kell, valamint fontos a szabványok betartása. Itt ezeket szükséges ellenőrizni és réseket keresni a rendszeren. Ha ilyet találunk, azt dokumentáció után továbbítani kell azonnali javításra a felelős fejlesztőknek.
Fontos az érthető és logikus használat biztosítása a szoftvercsomagnak és itt ezt fontos ellenőrizni, hogy az adott-e a programban. A használati leírásokat az itt tapasztaltak és látottak alapján lehet megírni. Biztosítani kell a transzparenciát a végső felhasználok számára is.
Természetesen az itt felsoroltak azok a teljesség hiányában, csak támpontként szolgálnak, ugyanis a tesztelés ezen szakasza esetünkben talán a legbonyolultabb. Rengeteg dokumentációs lépés és optimalizálási folyamaton megy keresztül szoftverünk, mire eléri azt a szintet, hogy megfeleljen a ráeső szabványoknak valamint a megrendelői kívánalmaknak. Fontos itt is megemlíteni, hogy minden egyes fejlesztési folyamatnál elengedhetetlen ellenőrizni az itt felsoroltakat minimum, hogy a szoftver funkcionalitása és stabilitása garantált legyen. Erről további említés az Iteratív tesztelés alpontban olvasható.
Mivel a szoftver funkciói változhatnak, valamint a jövőben bővülhetnek, így ehhez a folyamathoz a tesztelés menetének is alkalmazkodnia kell: Nem adhatunk ki olyan funkciót, ami a tesztelés minden részén nem haladt át! Minden egyes verzió kiadása után elégedettségi felmérést folytat a WorkNet csapata, melyben kitérést tesz az esetleges új funkciók igényének felmérésére. A begyűjtött információkat priorizálás után a fejlesztői csapat elé vetjük. Az új funkciók tervei az új kiegészítő dokumentumokkal megszületnek, és ezek fejlesztése valamint tesztelése is az eddigiekben leírtak szerint párhuzamosan végrehajtásra is kerül. Ha már nem érzékelhető hiba, és minden helyesen - a kívánalmaknak és szabványoknak megfelelően - működik csakis akkor kerülhet a szoftver a következő stádiumba.
Ez a legvégső pont egy adott verzió kiadása előtt. Úgymond az eddigi dokumentációk és teszteredmények összesítése zajlik itt, ahol ellenőrizzük a saját munkánk helyességét, tesztelések mértékének helyességét, valamint, hogy minden funkció együtt megfelelően működik-e. Ha egy adott fajta tesztelés és annak eredményei nem kielégítőnek véltek, akkor további kutatásra visszakerül a szoftver. A végső áttekintésben a már a felhasználó kezébe kerülő szoftvert és az ahhoz járó dokumentumokat (Felhasználói kézikönyvek, alapadatok stb.) ellenőrizzük valamint a legvégső teszteket végezzük el azokon. Ha itt bármilyen nemű probléma lépne fel, akkor ezen a pontom már szükséges hibakezelő új verziókiadást kiadni, hogy a dokumentumok átláthatóak legyenek. Értelem szerűen a kritériumok az alap funkciókon kívül már bővülnek az említett hibák kezelésével és a fő tekintet is erre terjed. Amennyiben az elkészült, úgy ismételten a szoftvernek keresztül kell mennie a tesztelési cikluson, természetesen új teszt esetekkel.
