A tesztelési folyamat fejlődése, állomásai

Nap mint nap találkozunk olyan cégekkel, akik alkalmazásokat fejlesztenek. Mindenhol hasonló problémák merülnek fel, melyek megoldása nagyban függ a tesztcsapat fejlettségétől. A tesztelésre jellemző tulajdonságok (létszám, módszer, eszköz) szerint különböző fejlettségi szinteket állíthatunk fel. A Te csapatod melyik szinten van?

Minden szervezetnek, csapatnak megvan a saját fejlettségi szintje. Ez igaz a rendszerszervezőkre, fejlesztőkre, tesztelőkre szintúgy, mint magára az egész szervezetre. A csapatok ugyanazokat a problémákat (vagy problémaforrásokat) élik meg, ugyanazokkal a helyzetekkel szembesülnek szinte minden helyen. Ezek a problémák adódhatnak az erőforrás, az idő, az eszköz vagy akár a szakértelem hiányából.

A kialakult helyzeteket nem biztos, hogy ugyanakkor és ugyanolyan technikával kezelik, ebből is következik, hogy minden csapat más és más szintre tud elérni. Az nem definiálható előre, hogy az egyes szintek között hogyan lépünk át. Valaki teljesen más technikákkal jut el a következő fejlettségi szintre. Sőt, az sem biztos, hogy az adott projektnél fejlődni kell egyáltalán. Nagyon sok olyan cég létezik, ahol a tesztelés különböző projekteknél különböző prioritást kap. Így egyik projektben a III. szinten jár, a másikban pedig az V. szinten. Amennyiben ez az üzletnek elfogadható és nem jelent kockázatot a cég számára, akkor ez egy teljesen logikus döntés.

Nézzük meg pontosan, hogy milyen állomásai lehetnek a tesztelésnek. Ha Te is tesztelőcsapatban dolgozol, akkor a felsorolt szintek közül biztosan találsz 1-2 olyan leírást, amely nagyban jellemző a csapatodra.

I. szint: Senki sem

Ezen a szinten egyáltalán nem beszélhetünk tesztelésről. Nincs teszteszköz, amiben a teszteket vagy a hibákat nyilvántartanák. Ha véletlenül mégis létezik ilyen szoftver, akkor a csapattagok (fejlesztők-tesztelők) nem használják konzekvensen. Annyira a fejlesztésre koncentrál a cég, hogy a tesztelésre egyáltalán nem jut erőforrás.

A hibákra a fejlesztők saját kódjuk ellenőrzésénél vagy véletlenül találnak rá. Az Ügyfélhez nagyon sok hibás rész kerül ki, ezáltal az elégedettsége az átlagos alatt szokott lenni. Általában igaz, hogy nincs vagy nagyon alul van dokumentálva a projekt. Ezért az Ügyfél olyan hibákat, plusz igényeket is be tud jelenteni, amely eredetileg nem volt a projekt hatókörében.

Tesztelési csapatról, dedikált tesztelőkről nem beszélhetünk. Külön tesztkörnyezetet sem mindig alakítanak. Előre átgondolt tesztesetek, tesztadatok nem léteznek.

A fejlesztett alkalmazások felhasználói élménye (10-es skálán, ahol 10 a legnagyobb): 1

Egy jó dokumentációval, egy dedikált tesztelő bevonásával és egy hibakezelő szoftver bevezetésével nagy lépést lehet előre tenni. Ezeket a fejlesztési lehetőségeket viszont a menedzsmentnek kell látnia, így tudna a csapat jobb szoftvert készíteni.

II. szint: Szakértelem nélkül

Többéves tapasztalattal rendelkező fejlesztő cégekre igaz, hogy egy kialakult, régóta piacra dobott szoftvert a projekt elejétől benne lévő rendszerszervező, üzleti elemző vagy ügyfél kapcsolattartó teszteli. Ezeknek az embereknek nagy tapasztalata van az üzleti oldalon, így az alkalmazás folyamatait tökéletesen le tudják tesztelni. Sőt, vannak olyan helyzetek, ahol a bonyolultság miatt csakis ők tudják tesztelni a funkciókat. De jellemzően a technikai oldalra nem fordítanak figyelmet. Az alkalmazások funkcionálisan megfelelőek, viszont ettől függetlenül rengeteg egyéb hibája van a rendszernek.

Dedikált tesztcsapat általában nincs. A projektben résztvevő üzleti kollégák tesztelésére hagyatkozik a csapat. Hibakezelés általában nem dokumentált formában zajlik, vagyis e-mail és telefon az elsődleges csatorna. Néhol Excelt, vagy opensource hibakezelőt használnak, de ezeknek az eszközöknek általában nincs felelősük. Általában súlyos probléma az időhiány, ugyanis a rendszerszervezőknek, üzleti elemzőknek több feladat is nyomja a vállát, így a tesztelésre nem jut elég idejük.

A fejlesztett alkalmazások felhasználói élménye: 3

Mivel a menedzsment meg van győződve róla, hogy más nem tudná tesztelni a rendszerüket, csakis az üzleti szakértők, ezért nagyon nehéz erről a szintről továbblépni. Tovább rontja a helyzetet az időhiány, amellyel a projekttagok küszködnek. A továbblépés itt is a menedzsmenten múlik. Amennyiben kialakítanak egy dedikált tesztcsapatot, és következetesen használnak egy hibakezelő vagy tesztmenedzsment szoftvert, akkor biztosítva van a következő fejlettségi szint. A dedikált tesztcsapatban fontos, hogy ne csak üzleti oldalról legyenek benne emberek, hanem az IT oldal is képviseltesse magát.

III. szint: Egy, csak egy legény van

Létezik dedikált tesztcsapat (általában 1-2 fő), akik funkcionális, integrációs, regressziós teszteket végeznek. A tesztelés még mindig a fejlesztés mögött kullog. Nem létkérdés, hogy a tesztcsapat igényei teljes mértékben ki legyenek elégítve. Általában két probléma miatt alakul ez így ki:

• vagy a tesztcsapatnak nincs megfelelő vezetője,
• vagy pedig a fejlesztők túl nagy hatalommal rendelkeznek a projektben.

A tesztelőket kizárják a döntéshozatalból. Nem élnek a folyamatban, csak sodródnak az árral. Hibakezelés rendszerint megoldott és létezik 1-2 tesztkörnyezet is.

A fejlesztett alkalmazások felhasználói élménye: 4

A fejlődés ebből a stádiumból a legnehezebb, mivel szemléletváltás kell a technikai oldalon. Itt nem elsősorban a menedzsmentet kell meggyőzni, hanem a technikai szakembereket, leginkább a fejlesztési vezetőt. Amennyiben sikerült elérni, hogy a projekttagok is fontosnak véljék a tesztelést, akkor közös erővel könnyebb a menedzsmentréteg hozzáállását alakítani.

Vagyis el kell érni, hogy a fejlesztés és tesztelés ne alá-fölé rendelt viszony alapján működjön. Ezt általában egy olyan erős tesztvezetővel lehetséges megoldani, aki megfelelő módszertani és gyakorlati tapasztalattal rendelkezik. Valamint meg tudja győzni a projekttagokat arról, hogy a más helyeken használt tesztelési módszerek náluk is nagyobb hatékonyságot eredményezhetnek.

IV. szint: A csapat

Állandó tesztcsapat létezik, amelynek vezetője van. A tesztelésnek kialakult a folyamata, módszertana. Hibakezelő eszközt és tesztmenedzsment eszközt használnak. A teszteket megtervezik, és folyamatosan tudják, hogy melyik szoftververzióban milyen teszteket fognak futtatni. A fejlesztés elfogadja a tesztelést. A menedzsment megfelelő erőforrást biztosít a jobb tesztek kivitelezésére. A tesztvezetőnek szava van a fejlesztési megbeszéléseken. A szervezet nyitott az új tesztelési technikákra. Többféle tesztelést végeznek, nem csak funkcionálisat. Fejlesztők is írnak unit teszteket. Több tesztkörnyezet van és a verzióváltás is szabályozva van.

A fejlesztett alkalmazások felhasználói élménye: 7

Ez az a szint, amely üzleti és technikai oldalról is tud minőséget építeni az alkalmazásba. Habár úgy néz ki, minden rendben van, azért ezen az állomáson is léteznek problémák. Leginkább a projekt vége felé az időhiány (amely nagyrészt a fejlesztés csúszásából fakad) szokott határt szabni a tesztelésnek.

V. szint: Robotok

Az előző szinthez képest abban több, hogy automatizált tesztek is futnak. A tesztelés kulcsfontosságúvá válik a fejlesztési folyamatban. Az automata szkripteket a tesztelők a saját munkájuk megkönnyítésére írják. Általában a regressziós teszteknél jön elő, hogy sokszor kell bizonyos teszteket futtatni, amelyre szkripteket gyártanak. De előfordulhat, hogy adatbetöltésre vagy olyan cselekvéssorozat automatizálására használják, amely sok időt vesz el a tesztelőktől. Az automata eszközök felhasználási területe nagyon széles lehet.

A fejlesztett alkalmazások felhasználói élménye: 8

Általában az automatikus és manuális tesztelés erőforrás-elosztása szokott gond lenni, mivel sokszor ugyanaz a csapat készíti az automata szkripteket és végzi a manuális tesztelést. Lényeges, hogy csakis olyan teszteket automatizáljunk, amelyek futtatása meg is térül. Vagyis a projekt egészét nézve kevesebb időt igényel a szkript fejlesztése, ellenőrzése, karbantartása és futtatása, mintha megmaradtunk volna a manuális megoldásnál.

VI. szint: Fontos a felhasználó

Sokszor összemosódik a fejlesztői/tesztelői munkakör. Gyakran a fejlesztők írnak tesztszkripteket, teszteszközöket fejlesztenek, stb… Egymást segítve halad előre a csapat. Mindenkinek az a célja, hogy minőségi szoftvert készítsenek. Több teszteszközt is használnak. Hibakezelésre és tesztmenedzsment-feladatokra egyet, de automatizált tesztelésre akár többet is. A fejlesztésbe szervesen beépül a dokumentum review, code review, unit és modultesztek. A tesztelés manuálisan és automatikusan is zajlik. A manuális tesztek és az automata szkriptek írását külön csoport végzi, így mindkét tesztelésre jut elég idő. A fejlesztőknek és a tesztelőknek egyaránt fontos az alkalmazás használhatósága és a felhasználók elégedettsége.

A fejlesztett alkalmazások felhasználói élménye: 9

Ezen a szinten leginkább már csak időhiányban szenved a tesztelés, de egy jól megtervezett és előre átgondolt projektnél a külső erőforrás bevonása nem lehet akadály.

Végezetül

Ha a tesztelés oldaláról nézzük az alkalmazásfejlesztést, akkor természetes, hogy mindenki azt mondja, hogy szeretné, ha a csapat a VI. szinten járna. Igen ám, de az érmének nem csak egy oldala van. Azt kijelenthetjük, hogy minél magasabb szintre ér a tesztelés, annál biztosabb, hogy jobb minőségű alkalmazást adunk a felhasználónak. De hol van az a pont, ahol meg kell állnunk? Mennyire teszteljük ki a programot?

A vállalatok általában ár – érték arányban gondolkodnak. Van egy határ, amelynél már többe kerül a tesztelés, mint amennyit az javít az alkalmazás minőségén. Ez a pont mindig máshol van. Az egészségügyben vagy olyan helyeken, ahol emberi életeket is veszélyeztethet egy szoftverhiba, általában nagyon magasan van ez a határ. Kicsit alacsonyabbra szokták tenni ezt a pénzügyi szektorban, telekommunikációban. Még alacsonyabban van a vállalati szoftverekben és a nagyközönség (egyéni felhasználók) számára készített szoftverekben.
Egy vállalkozás számára az a fontos, hogy minél több megrendelője, vevője legyen. Ezt az informatikában általában minőségi szolgáltatással, szoftverekkel lehet elérni. Manapság egyre több cég jön rá arra, hogy minőséget kell a termékeibe beépíteni. Ezt pedig egy jobb, teljesebb körű teszteléssel lehetséges megtenni.

Sokak szerint az új IT trend kulcsszava a “quality”. Én csak remélni tudom, hogy igazuk lesz.

Szerző: Pongrácz János