2004.10.06. - KwishDevelopment Diary #9 - Tesztelés<2004.10.06.> Ebben a fejlesztői naplóban Adrian Kastorf vezető tesztelő beszél arról, hogy mi is történik a játékkal, most, hogy közelít az aranylemez... Mikor ezeket a sorokat olvassátok, a TF fejlesztés már az utolsó stádiumába érkezett. Ezt az jelenti, hogy most folyik a tesztelés, és már megkezdtük a következő projectünkre való felkészülést. Szóval, hogyan is folyik a tesztelés és hogyan is dolgozhat több mint 30 ember egyetlen terméken? Ha minden grafikus, programozó és scriptelő a saját verzióját készíti, akkor ezeket a komponenseket manuálisan kellene összeilleszteni. Bár ez nem teljesen lehetetlen feladat, nagyon sok munkára lenne szükség. ÉS ha mégis menne a dolog, akkor is szembekerülnénk az ún. rendszer effektussal, amit olyan problémák okoznak, amelyek még nem voltak jelen a szeparált verziókban. A megoldás erre az ún. CVS - Concurrent Versions System / Egyidejű Verziók Rendszere. Ha már valaha részt vettetek nagyobb szoftver projektben, bizonyára találkoztatok ezzel. Ha még nem, gondoljatok valami olyan eszközre, amely támogatja a szoftver termékek fejlesztésének kezelését, s különösen azokban az esetekben használható, mikor csapat munkáról van szó. A szerveren a játék egy központi verziója található, és mindenki rendelkezik a szükséges hozzáféréssel. Ha új vagy a csapatban, hozzá kell csatlakoztatnod a PCdet a rendszerhez, megkapod a CVS klienst és futtatnod kell egy update-et, hogy az aktuális verzió neked is meglegyen. Ha már egyszer ott van a gépeden a dolog szabadon módosíthatod a dolgokat és kísérletezhetsz, ahogy csak neked tetszik. Minden egyes változtatást helyileg (a saját PCden) végezhetsz el és ez nem befolyásolja a fő fejlesztést. Ha befejezted az implementálását annak, amivel foglalkozol, letesztelted és stabilnak tűnik a dolog és benyújthatod a saját kis dolgodat. Ekkor a fő fejlesztés frissítésre kerül, s minden változás hozzáférhető lesz a többi fejlesztő számára is. Persze előfordulhat, hogy az új verzió valaki másnak problémát okoz (pl. összeakad valamilyen másik tartalommal). És ekkor jön jól a CVS egy másik sajátossága, hogy mentésre kerül az egyes verziók közötti különbség (minden egyes alkalommal, mikor update történik a szerveren). Csak egy egyszerű parancsba kerül hogy visszatérhess az általad választott korábbi verzióhoz. Körülbelül hat vagy hét hónappal ezelőtt kezdünk el ilyesféle teszteket futtatni. No persze abban az időben nem tesztelhettük az egész játékot, mert még nem volt kész. A korábbi szakaszban csak az egyes komponensek teszteléséről volt szó. Néhány ellenőrzés automatikusan történik, míg másokat manuálisan kell elvégezni, de különleges eszközökre van hozzájuk szükség. Például a szövegek ellenőrzéséhez nem feltétlenül van szükség a játékra. Így írtunk egy programot, amellyel a játéktól függetlenül futtatható az összes párbeszéd, így sokkal könnyebb végignézni, hogy minden egyes lehetőség megfelelően működik-e. Nem kellett akkor sem mindig elindítani a játékot, mikor a harcot akartuk megnézni. Az ehhez írott program egyszerűen megjeleníti a számokat és statisztikákat ahelyett, hogy grafikusan megjelenítené a harcot. Ez nem csak arra volt jó, hogy leellenőrizzük tényleg működik-e valami, hanem ezeket az információkat gyűjtöttük össze a szabályok és a tárgyak kiegyensúlyozásának megkezdéséhez is. Ezeket a teszteket házon belül végeztük el. De együtt dolgoztunk egy olyan másik társasággal is, amely a tesztelésre specializálódott. Sok más egyéb mellett ők tesztelték a játék stabilitását és teljesítményét mindenféle konfiguráció és rendszer esetén. Ha az alapösszetevők elkészültek, összerakták őket és egy nagyobb rész teljesen játszhatóvá vált már külső tesztelőkkel is együtt dolgoztunk .Néhányan közülük rendszeresen játszottak a játékkal, néhány a közösségünk tagja, aki lehetőséget kapott arra, hogy hétvégén próbálja ki a játékot. Egyik esetben sem arra kértük őket, hogy direkte a hibákat próbálják meg felderíteni. Arra kértük őket, hogy egyszerűem csak játszanak és koncentráljanak a játékra. A tőlük érkezett észrevételek felbecsülhetetlenül értékesnek bizonyultak, mivel olyan ötletekkel és megközelítési javaslatokkal álltak elő, melyre a fejlesztők nem gondoltak, vagy nem láttak előre. Vagy olyan hőstettet hajtottak végre, amely tönkretette a küldetést. Ha valamilyen hibára bukkantak (vagy csak egyszerűen egy gépelési hibára valamelyik párbeszédben) leírták egy darab papírra. Természetesen kíváncsiak voltunk a játékkal kapcsolatos általános véleményükre is, s megkértük őket hogy minősítsék a játék egyes elemeit, mint például a küldetéseket, a párbeszédeket, karaktereket és az általános benyomást. Minden egyes csoport esetében egy fejlesztő felügyelte a folyamatot, aki kész volt segítséget, vagy tanácsot adni, ha arra volt szükség. Ő volt az is, aki értékelte a visszajelzéseket és összeállította a végső bug-riportot. De hova volt ez benyújtva és ki foglalkozott a problémával? Ha egy ilyen nagy csapatban dolgozol, akkor a kézzel írott kommunikáció és menedzsment meglehetősen hamar elveszíti hatékonyságát. Éppen ezért a legtöbb társaság valamilyen hiba követő programot használ - s így tettünk mi is. Mi egy népszerű eszközt, a Bugzillát használjuk, amelyet eredetileg a Netscape fejlesztett ki, majd később nyilvánossá tette a kódját. Ha van valahol egy hiba (melyet a levelező személy nem igazán tud egyedül megoldani) a fejlesztő leírja a bug-riportban és benyújtja a dolgot a központi szervernek. Az ilyesféle jelentésnek a lehető legrészletesebbnek kell lennie. Mi is történt pontosan? Mikor, hol és hogyan? Mit csináltak ezt megelőzően a tesztelők? Milyenek voltak az általános körülmények? Megismételhető volt-e a dolog? Ha a jelentés bekerült a rendszerbe, Sebastian, a technikai igazgatónk a felelős hogy besorolja a problémát és megállapítsa a prioritását, és hogy kijelöljön valakit, aki majd helyrehozza. Például ha egy pályán valamilyen scriptelési problémát találnak, akkor az adott terület scripteléséért felelős programozó kap egy értesítést. Ha a problémát megoldotta, akkor megjelölheti a hibát, mint javított hiba. A hiba követő program nem csak könnyebbé teszi a tesztelési feladatok megszervezését, hanem lehetővé teszi a hibák státuszának azonnali ellenőrzését is. Felsorolja az összes hibát, amelyet még ki kell "utalni", megmutatja, mely hibák javítása van épp folyamatban, vagy épp már melyiket hozták helyre, vagy melyek azok, melyek túlságosan pontatlanul kerültek megfogalmazásra Sebastian szerint. Mint már mondtam, minden egyes hiba rendelkezik egy adott prioritással, értelemszerűen sokkal fontosabb egy kifagyást eredményező hiba kijavítása, mintsem egy kisebb grafikai szépséghiba helyrehozása.
Az egyszerű hibák esetében gyakran elég egyetlen nekifutás kijavításra. A fenti képen egy doktor épp egy beteget kezel. Nos, egy hiba miatt a beteg nem a megfelelő pozícióban van a tábori ágyon, és ettől egy kissé furán néz ki a kép. Ugyanazt lehet elmondani az épp eszméletét vesztő harcosról a bal oldali képen, aki mintha elsüllyedne a talajban, ahelyett hogy összeesne. És nem számít mennyire jó a karaktered zsebmetszés, vagy osonás készsége, sohasem lesz annyira láthatatlan a karakter, mint ahogy az jobb oldali képen (nem) látszik.
Mégis, időnként az is előfordul, hogy egy kis problémából komolyabb kihívás kerekedik. Van egy olyan átvezető anim, ahol a karakter egy helikopterrel emelkedik fel. A tesztelés során kiderült, hogy ez nem néz ki elég jól. Roger, az egyik script kódolónk megpróbálta helyrehozni a dolgot, de mindig mikor helyrehozott egy hibát, egy másik jelentkezett. Néha a helikopter magától repült, és otthagyta a karaktert. Máskor csak a rotor lapátok repültek el, vagy épp ellenkezőleg (csak a helikopter törzs). Még azt is sikerült elérnie valami nagy varázslattal, hogy a karakter valami csoda folytán elrepült, míg a helikopter a földön maradt. Mindent összevetve körülbelül egy hétbe került, mire minden úgy működött, ahogy kellett volna. Azt hiszem, ezt Roger nem fogja egyhamar elfelejteni. Adrian Kastorf Vezető tesztelő, SSE Forrás (szöveg és képek): IGN RPGVault (Vissza) Korábbi kapcsolódó cikkek: 2004.09.08. - Development Diary #8 - Modolás 2004.08.19. - Development Diary #7 - Hangok, szinkronizálás 2004.07.28. - Development Diary #6 - Pályatervezés 2004.07.09. - Development Diary #5 - Küldetések 2004.06.09. - Development Diary #4 - Grafika Az összes kapcsolódó cikk felsorolása |
