Szoftvertesztelés

Sokszor láttam már olyan helyzetet, hogy egy eltalált marketing akció úgy megterhelte a szervert, hogy az már nem bírta kiszolgálni a felhasználókat. Az csak jót jelent, ha a rendszerünk nagy látogatottságnak van kitéve. De hogyan lehet az ilyenkor bekövetkező összeomlást kivédeni?

Egyrészt ki kell alakítani a kommunikációt az üzlet és az IT között, másrészt az üzleti oldalt terveit is figyelembe kell venni a fejlesztések alatt. Még ha össze is ülnek az üzleti és az IT oldal képviselői, általában csak az alkalmazások funkcionalitásáról folyik a megbeszélés. Nagyon ritkán kerül előtérbe a felhasználók látogatási szokásai, illetve a látogatottság mennyiségi adatai. Ha találunk viszonyítási alapot ezekhez az adatokhoz, akkor könnyebb dolgunk van. Ha nincs, akkor tervezzünk megfelelően magas értékeket (felhasználói létszám, válaszidők, stb.), melyekre vizsgáljuk a rendszer stabilitását, működését.

Nem csak arra kell koncentrálni, hogy a rendszer funkcionálisan megfelelően dolgozik, hanem többek között arra is, hogy a tervezett felhasználói létszámot folyamatosan ugyanolyan jó minőségben tudja-e kiszolgálni.

Nézzük most a másik részét a vezetésnek, az emberek és a csapat érdekeinek képviseletét. Fontos a jó légkör a csapaton belül. A tagok akkor tudják a legjobbat kihozni magukból, ha mind csapatként, mind egyénként megfelelő motivációval rendelkeznek. Ezért vigyáznunk kell a motiváció folyamatos szinten tartásával. Ne csökkentsük azt és ne is állítsuk a tagokat lehetetlen feladatok elé. Mindkettő ugyanúgy demoralizálja a csapatot.

Mivel egy tesztcsapat vezetésekor sokszor nem jut idő a számonkérésre, nevezzünk ki helyettest, aki akkor is ügyeli a csoport munkáját, ha mi naphosszat megbeszélésen, tárgyalásokon ülünk. Így ilyen esetekben csak egy személlyel kell tartanunk a kapcsolatot. Körültekintően válasszuk ki helyettesünket, olyan személy töltse be ezt a posztot, aki képes az utasításainkat betartatni és a tesztelők is elfogadják vezetőként.

Sokan a csapatérdeket előrébb tartják az egyéni érdekeknél így magukkal a tesztelőkkel kevesebbet törődnek. Egy jó helyettes akár ilyenkor is használható. Amíg a vezető a csapatérdekekért harcol a megbeszéléseken, addig a helyettes úgy tudja szétosztani a munkát, hogy minden egyes tag megtalálja a kihívást a feladatában.

Vigyázzunk arra, nehogy abba a hibába essünk, hogy minden feladatot leosztunk a csoporttagoknak, helyetteseknek és nekünk nem marad semmi. Az ilyen személy nagyon gyorsan elveszti a csoport bizalmát. Törekedjünk arra, hogy mindenki (beleértve magunkat is) egyenlően, tudásához és munkabírásához mérten legyen leterhelve.

Két fontos részre lehet osztani a vezetés feladatait. Az egyik a munka szétosztása és számonkérése, vagyis a szakmai irányítás, a másik az emberek és a csoport érdekeinek képviselete.

Kezdjük a feladatok szétosztásával, és számonkérésével. A szétosztás általában az egyszerűbb dolog. Ha megtanuljuk az, hogy ne mindent magunk végezzünk el, akkor pofonegyszerű lesz a feladatokhoz embereket keresni. Nehezebb viszont felelősöket találni, ugyanis ez már azt jelenti, hogy a számonkérés is működik a csapatban. Nem elég csak kiosztani a feladatokat, de azokat valamilyen szinten le is kell tudnunk ellenőrizni. Ez szokott elmaradni sokszor, így a feladatoknak elvégzője, megoldója akad, de felelőse nem.

Ha meg tudjuk oldani, hogy minden feladatnak felelőse legyen, vagyis folyamatosan számon kérjük a csapattagokat, akkor félig megoldottuk a csapat szakmai irányítását. A másik felét a szakmai hozzáértésünk, módszertani ismeretünk adja ki. A kollégáink valószínűleg számos szakmai területen képzettebbek, viszont módszertanilag mindig a tesztvezetőnek kell több tudással és tapasztalattal rendelkeznie. Tesztelőként nagyszerű olyan vezetővel együtt dolgozni, aki útmutatást tud nyújtani a kritikus, problémás helyzetekben és tapasztalatából adódóan szakmai kérdésekben megfelelően képviseli a tesztelői csapatot.

Sokan abban jók, hogy a kialakult problémákat hatékonyan tudják kezelni. Lehet úgy is működtetni egy csapatot, hogy magára hagyjuk és a kialakult problémás helyzeteket kezeljük le. Ezt általában a vezetők és a tesztelők sem szeretik nagyon. Inkább törekedjünk a csapatunk folyamatos kontroll alatt tartására.

Amennyiben lehetőségünk van a projekt elején beleszólni a tesztelési csapat összetételébe, mindenképpen vegyük figyelembe, hogy milyen feladatokat kell elvégeznünk és erre mennyi erőforrás áll rendelkezésünkre.

A feladat, az idő, vagy az anyagi források miatt más-más csapatot kell összeállítani a különböző projekteken. Az automatizált tesztelésnél jó ha van egy olyan tesztelőnk, aki már dolgozott ilyen eszközzel. Rövid, szoros határidős projektnél elengedhetetlen a pontos, önálló feladatvégzés, és a csapatmunka is, vagyis inkább tapasztalt tesztelőkkel kell dolgoznunk. A feladat jellegéből adódóan megfelelő tapasztalattal rendelkező tesztelők kerüljenek be a csapatba. Adatbázis tesztelésnél jó ha van egy SQL szakértőnk, vállalatirányítási rendszereknél előny egy ilyen projektben már dolgozott munkatárs.

Ám mindezek mellett arra is figyelnünk kell, hogy kit hogyan tudunk vezetni. Sokszor kerültem jómagam is olyan helyzetbe, hogy egy-egy emberrel nem találtam meg a közös nevezőt. Lehetetlenség volt vele együtt dolgozni. Viszont más projektben más tesztvezető alatt ha nem is kimagasló, de mindenképpen megfelelő teljesítményt nyújtott. Vannak olyan emberek, akikkel egyszerűbb a közös munka ezért ha tehetjük, mindenképpen tudatosan válogassuk meg a csapattagokat.

Lehetnek helyzetek, amikor nem lehet kivédeni, hogy olyan emberekkel dolgozzunk együtt, akikkel nem akarunk. Ilyenkor különösen figyeljünk arra, hogy megfelelően kommunikáljunk az illetővel, és nem csak azt kell elvárnunk, hogy ő alkalmazkodjon hozzánk, hanem mi is próbáljunk valamennyire elfogadni és megérteni az ő nézeteit, álláspontjait, stb.

Már nem emlékszem kitől és hol hallottam magyarul ezt az előadást, de az eredeti (angol nyelvű) cikk itt található. Arról szól, hogy hogyan kell kiválasztani és irányítani az ideális tesztcsapatot.

Az úgynevezett időtálló paraméterek (workflow, jogosultság csoportok, stb.) beállítása után foglalkozzunk egy kicsit az eszközök folyamatos adminisztálásával. Ez miből állhat? 

Ideális esetben ez kimerül a projektek és felhasználók karbantartásával. Viszont amennyiben olyan eszközünk van, amelyben nem lehet tisztességesen beállítani a folyamatokat, akkor gyakran fognak kérni tőlünk különböző hibákkal, tesztesetekkel összefüggő karbantartási feladatokat. (Például XY kéri, hogy állítsuk át a hiba státuszát valami másra, mert azt ő nem tudja megtenni a jogosultságából kifolyólag.) Lehetőleg arra törekedjünk minél kevesebb ilyen feladatunk legyen.

Térjünk vissza a projektekre és felhasználókra.

Feladatunk lesz a projektek felvétele, módosítása, netán törlése(!) (természetesen szigorúan csak logikai), valamint ugyanezen munkák a felhasználói oldalon is. Általában azzal nem is szokott gond lenni, hogy létrehozzuk a projekteket és a felhasználókat, mivel ez a mi érdekünk is. (Mármint az emberek tudjanak dolgozni egy-egy projektben.) 

Viszont meg sem tudom számolni, hogy hányszor találkoztam olyannal, hogy az adott projektbe még a befejezés után évekkel is be tudott lépni a tesztelő. Vagy olyan projekttag, akinek egy időben rá kellett látni a rendszerre de utána semmi köze nem volt a projekthez. Az illető a  feladat elvégzése után is bármikor beléphetett, megnézhette, hogy mi történik a projekten.

Tudom ez már inkább biztonsági probléma (de a mi hatáskörünkben van), de ne csak a létrehozást csináljuk rutinszerűen, hanem az eltávolítást, törlést, vagy tiltást is. Mindig csak azok az emberek érhessék el a projekt tesztelési információit, akik éppen ezzel foglalkoznak, szükségük van rá.

A legdurvább, ha a cég elhagyása után is nyugodtan használhatja a rendszert, mert senki nem tiltotta le őt.

További napi feladatokat generálhat az olyan eszköz, amelybe beragadnak felhasználók ezáltal foglalva a licencek számát, vagy amelyik hektikusan, vagy furcsán működik. Lehetőségünk szerint próbáljuk kerülni ezeket a helyzeteket, ha nem tudjuk, akkor sajnos ezekkel a feladatokkal és a rájuk fordított idővel is számolnunk kell.