Menü Bezárás

A játékok tapasztalatainak alkalmazása a szoftvertesztelésben

A sokszereplős online szerepjátékok világában különböző technikákat lehet megismerni. Ha szeretnénk, akkor ezeket a technikákat akár a tesztelésben is nyugodtan használhatjuk. Tegyük változatossá az unalommá ismétlődő feladatok végzését. A különböző „játék” módszerek bevezetésével javíthatjuk a tesztcsapat hatékonyságát és a munka minőségét.

Elhatároztam, hogy megvizsgálom a “quest” játék jellegzetességet – kereső, kutató, gyűjtögető játékok -, azon belül is a MMORPG-t (Massively Multiplayer Online Role-Playing Game – nagyon sokszereplős online szerepjáték), ami tipikusan a videójátékokban használt technika. A játék nézőpontjai használhatók a strukturált tesztelési folyamatokban is. Jane McGonigal “Reality is Broken” című könyve adott egy tiszta áttekintést a kutató játékokról, arról, hogyan alkalmazhatóak a játék ajánlásai a normál életben. Az ő példáját felhasználva, kialakítottam egy alapszintű tesztkutatási folyamatot:

  • Sikerkritérium meghatározása. Mi az, amit el akarunk érni a teszteléssel.
  • Az a bizonyos sikerkritérium miért fontos? Miért tesztelünk?
  • Merre kell elindulni az alkalmazás tesztelésekor? Milyen technikát, vagy módszertant használjunk?
  • Útmutatás, nem konkrét lépésekkel, de azért elegendő segítség legyen. Videó vagy egyéb on-line média használata plusz pont.
  • Az eredmény jele, vagyis honnan fogjuk tudni, hogy végeztünk a feladattal.

A „kutatás” bonyolultabb, mint egyszerű tesztelési ajánlás (vagy teszteset), de egyszerűbb, mint egy tesztterv. Ez egy út, hogyan ütemezzük a tesztelési feladatokat, hogy eredményes munkát végezzünk, de néhány területe felfedező képességet és kreativitást igényel. Pontosan úgy, mint egy számítógépes játékban, számtalan módon el lehet jutni a küldetések végére. Egyszer, amikor sikerül véghezvinni a küldetést, ami lehet, hogy órák vagy napok kérdése attól függően, hogyan lett a játék kialakítva, mehetünk és választhatjuk a következő kihívást.

Egy másik módja az erőforrások szervezésének a játékok sikeres tervezésében szerzett tapasztalatok hasznosítása. A modern technológiák rengeteg együttműködést tesznek lehetővé a különböző országokban élő felhasználók között, hogy különböző technológiák együttes használatával érjék el a közös célt. Ezért ezeket az újításokat a tesztelési munkában is alkalmazni kell.

Egy mobil alkalmazás tesztelésekor, amely valós idejű kommunikációt és együttműködést kíván az egész világgal, egy tesztelő egyedül nem igazán tud használható tesztelési eredményt produkálni.

Az MMO (Massively Multiplayer Online – nagyon sokszereplős online) technika egy olyan együttműködést valósít meg a felhasználók között a virtuális világban, ahol a részvevők keményen, felügyelet alatt dolgoznak és még élvezik is. Arra jutottam, hogy ezt alkalmazom a tesztelésben is!

Hol jöhet szóba a „kutatás”? Azt gondolom, hogy az aktivitások hierarchiájának a tervezésében:

  • teszt stratégia és -terv
  • tesztelési kockázat csökkentése
  • különböző modellek a kockázat csökkentésére
  • tesztkutatás
  • munkafázisok, feladatok
  • jelentések és riportok

Egy jó tesztelési szemlélet egynél több lefedettségi modellt használ (nézd meg itt: http://www.kohl.ca/articles/ISLICEDUPFUN.pdf) és minden lefedettségi modell több kutatási irányt is tartalmaz. Néha a kutatás lépései ismétlődnek, amikor a regresszió megkívánja.Miért használjuk ezt a rendszert? Vetődik fel a kérdés.

Azon a területen ahol éveken át dolgoztam, használnak olyan rendszert és útmutatást, ami elősegíti a felfedező szemléletű tesztelést. A múltban a tesztmenedzsment eszközök biztosítottak lehetőséget a lefedettségek mérésére, de ezek nem voltak elegendők a tesztelők számára. A tesztelők belefáradtak a tesztek újbóli és újbóli lefuttatásába, de a vezetőség szerette volna látni a méréseket. Az eszközökkel pedig hihetetlenül egyszerű volt csalni, amit a tesztelők ki is használtak.

Később a tesztelők részéről elvárás lett, hogy a teszteszköz kialakításában ők is részt akartak venni, hogy könnyen és egyszerűen használható eszközök álljanak rendelkezésükre. Régen az volt az érzése a tesztelőnek, hogyha lefuttatott x számú tesztesetet akkor kész a feladat, elérte a célját.

A felfedező szemléletű tesztelésben azonban más a helyzet. Az ember úgy érzi, hogy a tesztelés sokkal hatékonyabb és a munka sokkal magasabb színvonalú, bár a mérése nehézkesebb az előbbihez viszonyítva és útmutatás nélkül nehezebb bizonyos területekre irányítani a tesztelők figyelmét.

Rengeteg ajánlás született, hogyan lehet rendszerbe szervezni a felfedező tesztelést. A „kutatás” egy újabb ajánlás a struktúrába szervezésre, hogy egyensúlyt találjunk a felfedező szemléletű, hibafeltáró és szkripttel támogatott tesztelés között. Ez egy ötlet a jó egyveleg megtalálásához.

Többen hallottak vitatkozni évekkel ezelőtt arról,hogy a tesztesetek és a tesztmenedzsment eszközök egy formája az útmutatásnak és további típusok is léteznek. A felfedező tesztelési közösségnek lefedettségi vázlatok, ellenőrzőlisták, gondolati térképek és természetesen a média, mint videók, hangfelvételek és további lehetőségek állnak rendelkezésre.

Amikor a „kutatás” tesztelési feladatot kell irányítani, az első, amivel kezdünk, az a munkafázis alapú tesztelés irányítás. Ez a módszer segít fókuszálni a tesztelés bizonyos területeire és áttekinthető eredményeket hoz, amitől a megrendelők általában nagyon elégedettek lesznek. Sokat használtam ezt a módszert az elmúlt években.

Volt dolgom továbbá a Bach-féle “Általános funkcionalitás és stabilitás” módszerével is, amely szintén a felfedező tesztelés rendszerezésére szolgál. A tapasztalataimra alapozva az egyedi projektek és tartalmak esetén, ahol úgy gondoltam, hogy működőképes lehet, ott elhagytam az ortodox megközelítést. Amikor a megpróbáltam kitalálni miért tetszik a csapatomnak a tesztelés, a munkafázis alapú tesztelés és az “Általános funkcionalitás és stabilitás” módszere volt a válasz.

Sokszor használok különböző verziókat a munkafázis lapú tesztelésből és az emberek értékelik, elfogadják ezt a módszert. Az “Általános funkcionalitás és stabilitás” egy nagyszerű útmutató az analizáláshoz, a felfedezéshez és rengeteg jó dologhoz melyek a tesztelők segítségére lehetnek.

Gyakran humorral és játékkal oldottuk a munkát és a technológiai nehézségeket. Beceneveket találtunk ki egymásnak, csapatokra osztottuk a tesztelőket, hogy meglássuk ki milyen ötlettel jön elő. Kinek van a legcélravezetőbb javaslata a megoldásra? Ki találta meg a legkomolyabb hibát a múlt héten? Ki rögzítette a legviccesebb hiba-videót? Melyik csapat talál a legtöbb kulturális kapcsolódást a csapat és a feladat között?

A tesztelés tele volt humorral, izgalommal és ezekből sokat tanultunk. A kommunikációnk során a technológiára támaszkodtunk, ami segített fenntartani a sebességünket. Sokszor más csapatokból is be akartak szállni. Gyakran nehéz a programozót programozásra kérni, az alkalmazásgazdától információt szerezni az alkalmazásról, vagy a menedzsertől azt elvárni, hogy irányítson. Ennek a vidám és inspiráló környezetnek a közepén pedig egy hihetetlenül értékes tesztelés állt. A megrendelők elégedettek voltak a teszteléssel, azzal a rengeteg hasznos információval, amit kapnak, a megtalált hibákkal és a részletes hiba leírásokkal, a státuszriportokkal valamint a projekt minőségével.

Amíg a hangulat jó és a környezet inspiráló, addig a munka megy. Megtanultam Jan McGonigaltól, hogy ez miért van így.

A „Reality is Broken” című könyvében McGonigal ír a „kiterjesztett valóság játékok”-ról (Augmented Reality Games – ARG). Ezek az igazi életből vett tapasztalatok, melyek a játékba vannak illesztve. Szintén ír a “Chore Wars”-ról, mint egy jó példa arra, hogyan lehet az életből vett tapasztalatokat átültetni a játékokba, hogyan lehet ezeket szórakoztató módon felhasználni.

McGonigal azt mondja, míg a játékban a fürdőszoba kitakarítása egy igen magas értékű feladat, neki és a férjének nagyon sokat kell azon dolgozni, hogy senki se végezze el előttük. Elmondja, hogy amíg ott a választás lehetősége és van valamiféle jelentőség rendelve az egyes feladatokhoz, a játékosok e szerint a mechanizmus szerint fogják a számukra legkedvezőbb döntést meghozni.

Vannak olyan feladatok, amelyek kellemetlenek, unalmasak és senki sem akarja megcsinálni, de mihelyst a játék keretrendszerébe illesztjük keresettek, népszerűek lesznek. Pontokat kapsz a feladatok elvégzésért, fejlődik a karaktered, jutalmakat szerzel és nem mellesleg tiszta lesz a fürdőszoba. Szenzációs!

Ha ezeket az ARG által ajánlott módszereket a tesztelésben is szeretnénk használni, például a regressziós teszteknél, a tesztadatok létrehozásánál, vagy egyéb karbantartási feladatoknál amelyeket nem nagy lelkesedéssel végzünk, hogyan csináljuk?

Egyik útja, ha a tesztelési feladatokban alkalmazzuk őket, mint például csak akkor mondható késznek egy részmunka, ha legnehezebbnek definiált feladatok közül is elvégeztünk egyet.

A „Reality is Broken” című könyvben McGonigal a játékot négy szempont szerint definiálja: célok, szabályok, visszajelzések és az önkéntes részvétel. A kutatás módszer szerinti tesztelésben a legtöbb feladat amit elvégzünk, az önkéntes, mert a tesztelő szabadon dönthet, hogy merre indul el a tesztelési folyamatban.

Ezért választhatunk tehát különböző lefedettségi modelleket a cél elérése érdekében.

Vegyünk egy üzleti alkalmazásokat tesztelő csapatot, akik már teljesen beleuntak a rendszer motorjának tesztelésébe, mert mindig ugyanazt a funkcionális teszteket kell futtatniuk. Hogy hatékonyabbá tegyem a munkájukat, mutatok nekik egy új lefedettségi modellt (pl.: felhasználói forgatókönyvek) a rendszer motorjának tesztelésére. A teszt csapat elfogadja az új modellt, érdeklődéssel használják és segítségével megtalálnak olyan hibákat is, amelyeket ezelőtt nem. Ezután segítek nekik új lefedettségi modelleket kialakítani, amikben majd azt látják, hogy megváltoztathatják az elképzeléseiket, a módszereiket úgy, hogy a feladat az elvárásoknak megfelelően legyen elvégezve, de mégis élvezettel dolgozzanak.

Emberek vagyunk, kell, hogy variáljuk a dolgokat. Eddig nem volt választásuk, a feladat az volt, hogy futtassák a teszteket és rögzítsék a hibákat a tesztmenedzsment rendszerben és kész.

Bevonhatunk még tesztelő párokat vagy triókat a tesztelésbe, hogy még több ötletet hozzanak a csapatnak. Ez nem azt jelenti, hogy duplikáljuk a tesztelést, sokkal inkább az agykapacitások és az erőfeszítések megduplázása.

A szabályok a tesztelésben gyakran a kapott feladattól függenek. Attól, hogy mit kapunk a vezetőktől és a programozóktól. Rémisztő számomra, hogy mennyi Agile programozó követel nem Agile módon tesztelési munkát a tesztelőktől. Elvárják a tesztterveket, teszteseteket és a tesztmenedzsment rendszer használatát. Amikor megkérdezem a programozót, hogy ő szeretne-e ilyen módon dolgozni, mindig nem a válasz. Nos, akkor képzelje csak el, hogy senki a világon nem szeretne ilyen módon dolgozni. Inkább azt javaslom, hogy alakítsunk ki szabályokat a megközelítések köré.

Azonosítottunk kockázatokat és definiáltunk lefedettségi modelleket, hogy csökkentsük ezeket a veszélyeket. Valamint az eszközöket, az embereket és az automatákat arra használtuk, hogy segítsenek elérni a céljainkat. Ahelyett, hogy a teszteseteket és a hibákat számolnánk, minősítsük a csapatot a minél eredményesebb munkavégzés érdekében. Ezáltal pontosabb és használhatóbb információkat fogunk adni a megrendelőknek, akik minőség alapú döntéseket tudnak majd meghozni.

Végezetül pedig, a cél a tesztelésben szükségszerűen a projekttől függ. Ha el akarod véteni a célt, nyugodtan ismételd meg amit a legutóbb tesztelési projektedben csináltál. Az a probléma ezzel, hogy fogalmad sem lesz az új kockázatokról, csak vakon fogsz tapogatózni. Minden projektnek van célja és találhatunk hozzá egy módot ahogy mérni tudjuk, hogy jó irányt követtünk-e, jó lépéseket tettünk-e meg megfelelő sorrendben a cél elérése érdekében. A „regressziós teszteket futtatunk, automatizálunk belőlük annyit amennyit bírunk és ha még van időnk tesztelünk valami mást is” művelet helyett inkább végezzünk valami egyedit, olyat ami megszabadít a sok unalmas munkától és értéket ad a projekthez.

A „kutatás”-ban is megvannak ezek az elemek: Célok, szabályok, paraméterek a tesztelésre vonatkozóan, valamint vállalkozó szellem. Ha a tesztelési feladatok definiáltak, teljesen mindegy ki hajtja végre azokat.

Kiderült, hogy a munkafázis alapú tesztelés, az “Általános funkcionalitás és stabilitás” módszere és néhány bolondság, ami segít a szocializációban és az információk összegyűjtésében egy újabb módszer, amit használhatunk ebben a “játékos” munkában. A „játékos megközelítés” egy ajánlás, amit remélem mások is használnak majd, akik a tesztelésüket hatékonyabbá és a munkahelyi légkört vidámabbá akarják tenni.

A „kutatás” egy opció. Használjunk avatarokat, vicces neveket és minden olyat, ami a csapatot hatékonyabbá teszi. Jutalmakkal ismerjük el a jól teljesítőket, mint ingyen ebéd, csapat előtti dicséret, vagy extra szabadidő. Légy kreatív és használj annyit a videójátékok világából, amennyit jónak látsz!A kutató teszteléssel kitűzött céljaim közül néhány:

  • Kielégítő módszer, amely segít a tesztelőnek a fókuszálásban.
  • A nem elég jó módszer rontja a hatékonyságot és a kreativitást.
  • Az útmutatás és a módszer együtt egyszerűsíti a feladatot és nem terheli az erőforrásokat (mint például az automatikus regressziós teszt).
  • A tesztelőknek látniuk kell a célt, tisztában kell lenniük a munkájuk jelentőségével, és a feladataik teljesítésével el kell végezniük a kutatást.
  • Válasszunk megfelelő eszközöket (automati- zált tesztek, szimulátorok, ellenőrzés és riportálás) amelyek segítenek felpörgetni a tesztelőket.
  • Segítsük elő az együttműködést és osszuk meg az információt egymás között. Nagyon hasznos a tesztelő véleménye másik tesztelő kollégája munkájának minőségéről, vagy akár a saját munkájáról, de ugyanúgy érték egy másik csapattag véleménye a projekt minőségéről is.
  • Ösztönözzük a csapatot, hogy különféle modelleket használjanak (perspektívaváltás, vagy különböző tesztelési modellek és eszközök használata) a projektben, ahelyett, hogy mindig ugyanazt az egy módszert használnák.
  • Vezessünk be a játékokból már ismert módszereket, hogy motiváljuk a csapatot a fárasztó tesztelési feladatokban.

Én a tesztfuttatásoknál használom ezt a módszert, hogy könnyedebbé és hatékonyabbá tegyem a munkát.

Annyi elemet használj fel a videójátékok világából, amennyit jónak látsz. Kapcsold össze a személyiségi vonásokkal valamint a csapatban lévő egyéni célokkal, vagy figyeld őket és gondolkodj azon, hogyan tudod a saját és csapatod munkáját megkönnyíteni! A rendszer, amit használsz, megkönnyíti az emberek munkáját és javítja a csapatban a morált? Jönnek a sikerek? Ha nem, akkor nézd meg, hogy mások, akik sikeresek a játékiparban, hogyan csinálják!

Jó játékot kívánok!

Szerző: Jonathan Kohl

A szerző

Jonathan Kohl
Szoftvertesztelési és vezetési tanácsadó a Kohl Concepts-nél, melynek székhelye Calgary (Alberta, Kanada). Jonathant neves szakemberként tartják számon a tesztelői közös- ségekben. Népszerű szerző és előadó, aki hiszi, hogy a tesztelés kihívás, intellektuális mesterség. Gyakori és népszerű írója a szoftverfejlesztési és tesztelési kiadványoknak. Az utóbbi időben Jonathan mobil alkalmazás fejlesztési projektek különböző változatain dolgozik. A munkájáról bővebben a www.kohl.ca oldalon olvas- hatsz.Kapcsolat: jonathan@kohl.ca
Vissza