Sziasztok,

Közhelyszerű, hogy régen mindenfajta tesztelés, review és kontroll nélkül árasztották el a piacot a cégek szerepjátékos anyagokkal. Egész biztos, hogy nagyobb részben nem tesztelték az anyagokat, vagy nem kaptak olyan figyelmet, mint manapság. Alapvetően a teszt azt jelentette, hogy végigjátszották egy-két alkalommal az anyagot és ha úgy érezték, akkor módosítottak rajta. Nem tudom, hogy végeztek kimerítő teszteket, vagy csak ad hoc lejátszották a modult és szubjektív megítélés alá helyezték. Ilyen részletekről nem találtam forrást.

Viszont ráakadtam az alábbi cikkre: Quagmire!

Ebben az írásban a cikkíró kifejti részletesen, hogy a TSR-nál a 80-as években már komoly munka folyt a fejlesztés során. Kezdve a pitch-től a modul megírásáig, a design kialakításán keresztül a fejlesztés időrendjének meghatározásáig minden szelete szabályozva volt. Különösen nagy hangsúlyt fektettek arra, hogy a kifejezések, a modulban található rendszerelemek (szörnyek, tárgyak, kiegészítő szabályok pl.) szabványosak legyenek, valamint illeszkedjenek a koncepcióba.
Ami azért érdekes, mert egyes pletykák szerint a TSR-ban nem volt semmilyen tesztelés és ad hoc íródtak a kalandok. A linkelt cikk alapján ezzel szemben több fázison átment egy modul, mire megjelent. Pitch, Marketing review, általános review és a projekt időbeosztásából látszik, hogy a heti tesztdélután mindig megvolt.

Kicsit körbekérdeztem az akkori fejlesztők körében és eddig annyit sikerült kiderítenem a tesztelésről, hogy jellemzően a munkatársak egymás között teszteltek. Valaki vállalta a DM szerepét, gondolom a modul gazdája és mesélt a többieknek. Ennek az volt az előnye, hogy olyanok teszteltek, akik a rendszert ismerték, könnyebben megtalálták a hibákat, azokat az obskurus dolgokat, amik borítják a kalandot, vagyis könnyen felismerik, ha broken valami a kalandban. Teszteltek a különböző con-ok keretében is, meg csak úgy külsősöknek is meséltek, de az azért volt kevésbé hatékony, mert ezeken a session-ökön általában a fun volt előtérben és kevésbé figyeltek a rendszerbeli problémákra.
Egyik forrásom mesélte, hogy egyszer a Top Secret nevű kémes rpg-ben használt üzenetek kiszivárogtak a rendőrségen keresztül az FBI-hoz, ők meg komolyan vették és nyomoztak az ügyben, de végül a TSR kimagyarázta, hogy ez nem valós kémtevékenység, hanem csak játék. Hiába legendás idők voltak.
Illetve kiderült a sztorizás közben, hogy azért csütörtök délután történtek a tesztjátékok, mert az alkalmazottak jelentős része péntek délután mentek haza a távol élő családjukhoz. Ugyanis egy jó részük távol élt családjától és csak hétvégén ment haza.
Tény, hogy ha megfigyeljük a kalandokat és a varázslatokat elég sok konkrétumot kapunk arról, hogy mi hat mire és mi az ami elllen véd, vagy ellenkezőleg ártalmas tud lenni. Vagy szinthez kötötték a hatás engedélyezését. Közvetett módon szoktak úgy is korlátozni, hogy bizonyos alacsony szintű varázslatok nem működtek az adott esetben, de magasabb szintű hasonló mágiák már igen, ezzel korlátozva, hogy csak egy adott szint felett lehessen egy adott problémát megoldani mágiával. Például az érzékelőmágia területén, vagy tipikusan a mágikus zárak.
Akkoriban még nem forrott ki az a fajta logika, ami a modern szerepjátékokat, amiben a hatásokat egy cimke alá rendezik és a hatás erőssége/szintje számít amellett, hogy milyen ellenhatás vagy védelem párosul hozzá?

A tesztelésről

Mint láttuk a régi időkben nem volt módszeres tesztelés, csak kipróbálták a játékokat és az alapján mondtak ítéletet. Jó lenne ha kialakulna egy tesztelői attitűd, vagyis minden rossz szándék nélkül a jobbítás érdekében kritizáljuk mások termékeit. Ehhez az kell, hogy a terméket magát vizsgáljuk objektív módon és nem az alkotót mögötte.

Szoftverteszteléssel foglalkozom és gondoltam pár elvet át lehetne ültetni a szerepjátékok világába, hogy hatékonyabb legyen a folyamat. Nagyjából négy szintet különböztetünk meg a tesztelés során:

1. Review
2. Modulteszt
3. Funkcionális teszt
4. Performance teszt

Illetve van az Acceptance teszt, ami arról szól, hogy a fogyasztók hogyan fogadják a terméket, vagyis küllem, tartalom és egyéb szubjektív szempontokból milyen a termék.
A Review-t gyakaran használjuk, újságok, blogok vannak tele olyan írásokkal, amik elolvasás után mondanak véleményt egy-egy rpg termékről tapasztalt mesélők. Ez nagyon hasznos módszer, de csak a belépő szintje a tesztelésnek. Néhány probléma már ekkor kijöhet. Például igen könnyű észrevenni a csőkalandokat olyan jelek alapján, mint a kalandba elhelyezett egykapus megoldásokról. Például ha a csapat be akar jutni egy városba, ahol az egyik őrség beépített és jelszó ellenében engedik be őket és minden más bejutási lehetőség szinte lehetetlen. Vagy a jelentős események egymás után következnek és az összekötő hálózat gimmick, vagyis bármerre indulsz el úgyis a mesélő által kijelölt célba jutsz el. Különösen tipikus, amikor látszólag több út van, de egyiken se történik a történetet befolyásoló esemény.
Aztán tipikus hiba például, hogy a fontos informátor NPC-t elzárod a következő szint mögé, pl. a lezárt város egy pontjára rakod, vagyis ahhoz megtudj minden fontos dolgot az adott területről be kell hatolnod. No de ha már bent vagy nem tudsz változtatni. Aztán láttam olyat is, hogy a kommandós akcióhoz JK-k mellé adott kísérők teljes lovagi felszerelésben indulnak el. Hm, ügyes! :) Biztos nem lesz lebukás így.

A Modulteszt alatt általában a program egy apró funkciójának önálló tesztelését értjük. Például ha írunk egy szerepjátékot és írunk bele egy kockadobó modult, aminek hagyományos dobáskóddal meg lehet mondani a kívánt dobást és ezt külön teszteljük. Szerepjátékban például lehet egy ilyen teszt mondjuk egy újfajta próba tesztelése, de én idesorolnám azolyan white room teszteket is, amelyek során 1-1 karaktert kiállítunk egy üres szobába és párbajoztatjuk őket. Itt egy-egy karakterosztály, vagy szörny, esetleg varázslat működését tudjuk tesztelni, főleg akkor érdekes, ha több random tényező is szerepet játszik az adott játékelemben.

Funkcionális teszt során már egész rendszereket szoktunk futtatni, de csak egyetlen funkcióra koncentrálunk. Szkenáriókat hozunk létre és azokat különböző tesztekkel kipróbálunk. Szerepjátékban úgy képzelem, hogy egy előre kitalált szituációt próbálunk ki különböző karakterekkel. Itt már egy komplex szituációt kell megoldani, esetlegesen változó feltételekkel. Például egy fogoly kiszöktetése egy börtönépületből 1-2 karakterrel, miközben a városörség egy nyílvános kivégzésre koncentrál. (Meglepetés, lopakodás, orvtámadás tesztelése)
Kisebb kalandokat, helyszíneket érdemes tesztelni így. Ha szétszeded a kalandodat és az egyes találkozásokat lemeséled különböző embereknek, akkor sokat lehet belőle tanulni, anélkül, hogy hosszan játszatok. Gondoljunk csak bele egy normál asztali játék rengeteg olyan sallangot tartalmaz, ami a tesztelés szempontjából feleslegesek. (Ismerkedés, tervezés, nyomozás, stb.) Természetesen ezek is fontosak, de ha a rendszert próbálod ki, akkor csak hátráltatnak benne. Miután kimunkáltad a jeleneteket összerakva tesztelhető lesz a teljes kaland az összekötő elemekkel is és szerintem egy készre csiszolt találkozásokkal mindenképp érdekesebb lesz a meséd is. Házi mesélésnél túl sokk effort talán a slice-olás, de piacra szánt modulnál szerintem érdemes kipróbálni.

Performance teszt az, amikor egy rendszer tűrőképpességét vizsgáljuk, például egy wow szerver kapacitása, esetlegesen hibaesemények kezelése terhelés alatt. Ilyenre szerintem nincs esély asztali szerepjáték esetén, maximum egy kaland mesélése több alkalommal, több csapatnak, vagy több mesélővel és mindezt teljesítményre, időre, vagy elért célokban mérve. Bár kicsi az esélye, hogy egy házi modult több helyen lejátszák, de ki tudja lehet a jövőben ez is változik.

Ennyit akartam elmondani a tesztelésről. Jó lenne ha esetleg valaki kipróbálná ezeket a módszereket és véleményt mondana róla. Még jobb lenne, ha már lenne olyan mesélő, aki hasonló módon tesztel.