مقدمه ای بر آزمایش بازی

مقدمه: مسلماً مهم ترین چیزی که می تواند از ارزش بازی شما به شدت بکاهد و حتی باعث دلسردی بازیباز از انجام بازی شما شود وجود خطا در بازی است. چه بسا بسیاری از بازی های بزرگ و مهم در جهان بودند که تنها به خاطر داشتن چندین خطای نرم افزاری (Bug) شکست خورده و از رونق افتاده اند. بازی سازان کشور ما متاسفانه در قسمت رفع اشکال و خطای بازی به شدت با ضعف روبرو هستند و این را می توان در بازی های تجاری ایرانی که در بازار موجود است دید. اصولاً خطاهای نرم افزاری در بازی علت های گوناگونی می تواند داشته باشد. که ما سعی می کنیم تمامی عوامل و راهکارهای کشف و از بین بردن خطاها را بررسی کنیم. بازی سازان کشور ما بدلیل مشغله های متفاوتی که دارند و مهم تر از همه کمبود عوامل و کادر فنی و تجربه کاری بعد از اتمام کار دیگر وقت زیادی برای پیدا کردن خطاهای نرم افزاری نمی گذارند و خیلی زود می خواهند بازی شان در بازار منتشر شود و این بزرگترین اشتباهی است که مرتکب می شوند.

دو قاعده برای آزمایش بازی

برای این که شما بخواهید یک آزمایش کننده را وارد گروه کرده و یا خودتان به یک آزمایش کننده حرفه ای بازی تبدیل شوید باید این دو قاعده را حتماً رعایت کنید:
1.    شجاعت
2.    اعتماد هیچ کس

شجاعت

در یک پروژه بازی وحشت چیز بسیار بدی است. یک آدم ترسو انتخابش هم همراه با ترس است. این شخص نمی تواند رویدادها را درک کند. و در وضعیت های مختلف واکنش های غیرعقلانی انجام می دهد. و این می تواند باعث رسیدن آسیب های جدی به پروژه می گردد و در اینجا مسئول اتفاقات مدیر گروه آزمایش کننده است. مدیر گروه آزمایش کننده باید هنگامی که متوجه درخواست های بی جا و نامعقول یک یا چند نفر از اعضای گروه مواجه می شود به سرعت متوجه این موضوع گردد. در این شرایط است که مدیر گروه آزمایش کننده باید بپرسد: داستان چیه؟
چند نفس عمیق بکشید و خودتان را در چیزی شبیه به این لحظه قرار دهید که چهره شما باید چگونه باشد. منابع محدود (تجهیزات و دستگاه هایی که به شما کمک می کند) ، زمان محدود (پروژه باید هر چه سریعتر به فروش برسد) ، پیروی از قواعد (فراز و نشیب قواعد) و دیگر چیزهای حیرت آور (مثل رفتن مسافرت برای بازدید از دریا) باید برای این گونه حوادث ترس آور یا نزدیک به ترس توضیحی روشن آورد. حمله های هیجان آور و ترسناک نظیر این مسائل واقعاً یک زنگ خطر و مساله کاملاً جدی و مهمی است که برای مسلط شدن به اعصاب و آرامش دادن به خود نیاز به سالها تجربه در امر آزمایش بازی دارد. اما مسلماً با اندکی تامل و فکر و اعتماد به نفس و توکل می توان بر تمامی مشکلات غلبه کرد و کار را به بهترین نحو انجام داد. در هنگام آزمایش نباید شخص به خودش این افکار وحشت آور را تلقین کند و باید به خودش بارها بگوید که مشکلی نیست، حل می شود، خداوند بزرگ است و با خودش بگوید که می تواند تمام مشکلات و عیوب بازی را رفع و تمامی پروژه را به بهترین نحو و در بهترین موقع تحویل دهد.
گاهی اوقات عمل آزمایش باعث آفرینش خطای جدید می شود. کوتاهی در اعلان یک خطا یا فرستادن توسعه دهندگان برای انجام تلاش بیهوده پیدا کردن یک خطای نرم افزاری مبهم که شاید اصلاً وجود نداشته باشد که به عنوان مثال در فلان قسمت بازی اندکی با قواعد طبیعت بشری فاصله دارد! که منجر به افزایش زمان و هزینه و حتی باعث شکست پروژه گردد.
ترس در یک پروژه برای یک آزمایش کننده بیشتر در 5 حالت زیر روی می دهد.

1.    نا آشنا بودن.
2.    آماده نبودن.
3.    تحت فشار بودن.
4.    آشفته و مضطرب و بی قرار بودن.
5.    نزدیک بین بودن.

اکنون ما به ترتیب هر 5 حالت را باز کرده و در مورد آن توضیح می دهید.

نا آشنا بودن: همچون یک عضو تیم ساخت بازی شما باید بپرسید که چه چیزی است که قبلاً آن را هرگز نداشته اید؟ شما باید هرچیزی را به غیر از اجرای آزمایش معین کنید. در میان پروژه های متفاوت بازی بیایید خودمان را به جای آخرین دقایق انجام دموی بازی توسط مشتری بگذاریم. شما باید کاری را انجام بدهید که هرگز قبل از آن انجام نداده اید. شما باید صد در صد تاسیسات آزمایش را کنترل کنید. یا باید ابزارهایی را بنویسید که زبان های بیگانه آزمایش در بازی ها را بازبینی می کنند. شاید کسی نباشد که قبل از شما این کار را انجام داده باشد. نمی توانید فوراً تسلیم شوید. نمی توانید مرتکب اشتباه شوید. و نمی توانید سعی کنید شبیه قهرمان ها شوید. اگر شما به این موقعیت آشنا نیستید شما باید بر پایه بهترین قضاوت ها قرار بگیرید. اما این هنوز درست نیست. این نیازمند به یک رادار خوب در قسمتی است که شما می خواهید کمک بخواهید. و همچنین کمی احساس فروتنی و تواضع همچنین نباید احساس کنید که شما همه چیز را می خواهید و مدام بگویید بله نیازمندم. شما نیازی به گم کردن توانایی هایتان ندارید. فقط کسی را که فکر می کنید می تواند شما را راهنمایی کند و به شما در حل مشکلات کمک کند پیدا کنید. و از کسانی که فکر می کنید ممکن است پاسخ اشتباه به شما بدهند کناره گیری کنید. شما حتی می توانید در اینترنت جستجویی بکنید و ببینید اگر کسی هست که در اطراف شما زندگی می کند و می تواند به شما در حل مشکل کمک کند با او صحبتی داشته باشید و یا کاربرانی که زندگی شان جایی است که آزمایش کنندگان حرفه ای از محل زندگی آنها دور هستند از طریق گفتگوی آنلاین سعی کنید به نتایج برسید.
البته ما تلاش می کنیم در مباحث بعدی پیرامون فرآیند آزمایش بحث کاملی را انجام داده تا کسانی که ناآشنا هستند نسبت به این مساله مهم آشنا شوند.
آماده نبودن: هیچ کس دادگاه های تفتیش عقاید و جنگ جهانی دوم را نمی توانست پیش بینی کند. همینطور هر رویداد غیرمنتظره ممکن است در پروژه اتفاق بیافتد. انتظار رویداد غیرمنتظره! قسمت های بسیاری از بازی نیاز به آزمایش ها از جهات گوناگون در چرخه زندگی بازی دارد. در پشت صحنه بسیاری از تکنولوژی های متفاوت در حال کار می باشد. گرافیک سه بعدی، صدا، واسط کاربری، طرح های منطقی و فایلهای سیستمی با نام های اندک. اگر شما برای آزمایش های گوناگون آماده نیستید و نمی توانید در زمان های حساس که گروه به شما احتیاج دارد وظیفه حساستان را انجام دهید در نزدیکی ستاره شدن سکندی می خورید.
مطالعه، تمرین و مهارت اجرایی برای یک تدارک خوب هستند. در حین دوره پروژه باید تلاش کنید پیرامون کدهای بازی دانش بیشتری را کسب نمایید. همراه صنعت باشید همچنین شما باید از تولیدات بعدی بازی ها و تکنولوژی ها باخبر باشید. درخواست ها و طرح های ویژه ای که برای قسمتهای بازی شما مسئول آزمایش آن هستید را به موقع تحویل بگیرید. و سپس به سرعت با آن بخش هایی که پیش بینی می کنید ممکن است هر لحظه با مشکل مواجه شود آشنا شوید. شما باید موقعیت و جایگاه خود را با سایر اعضا تغییر بدهید. تا در مسئولیت های بیشتر رشد کرده و پیشرفت کنید و برای رویدادهای مهم بیشتر آماده باشید.
تحت فشار بودن: فشار می تواند از سه دستورالعمل باشد.

•    برنامه زمان بندی (تقویم زمانی برای کامل کردن پروژه)
•    بودجه ( کسری پول در پروژه)
•    تعداد اعضا (تعداد اعضایی که برای کار در ساخت بازی تعیین می شوند)

اینجا هیچ پیشگیری از یک یا هر سه مشکل که در حین پروژه جمع می شوند نیست. همچون یک آزمایش کننده این فاکتورها تحت کنترل شما نیست. مسلماً این ها جزو شرایط حرفه مدیریت پروژه می باشد. در هر شرایط شما به عنوان یک آزمایش کننده تحت فشار قرار خواهید گرفت. در شکل زیر عوامل تحت فشار نشان داده شده است.




تصویر شماره 1 منابع فشار در پروژه

حرکت هر یک از این نقاط مثلث فشار می تواند یک بار سنگینی را بر پروژه تحمیل نماید. گاهی اوقات پروژه همراه با یکی از فاکتورها که خیلی کوچک هستند آغاز به کار می کند. یا ممکن است بعد از شروع پروژه یک یا چند نقطه فشار شروع به حرکت کند. برای نمونه پول می تواند کمتر شود تا کمپانی بتواند توسعه دهندگان بیشتری را برای بازی بیاورد. یا اینکه بدلیل رقابت تاریخ انتشار بازی در جدول زمان بندی را جلوتر بیاندازند. در شکل زیر عامل فشار بودجه نشان داده شده است.

تصویر شماره 2 کمبود بودجه عامل فشار بر پروژه

یکی دیگر از عواملی که باعث آمدن فشار در پروژه می شود آوردن تلاشی اضافه در برنامه پروژه است. یک تقاضای درونی همچون اضافه شدن مراحل یا شخصیت های بیشتر یا کد نویسی برای کیفیت قدیمی موتور برای بهتر شدن کیفیت که این امر بیشتر در هنگام اعلام آمدن سخت افزارهای جدید صورت می گیرد. دیگر چیزهایی که از پیش طرح ریزی نشده است ساخته شدن برخی تغییرات که از افزوده شدن  های جدید پشتیبانی کند. یا اینکه چند کاربره ای بصورت شبکه یا اینترنت به بازی افزوده گردد. ما در شکل زیر نشان می دهیم که چگونه تغییرات در برنامه زمان بندی شده می تواند بر کل پروژه و تعداد اعضا و بودجه موثر باشد.

تصویر شماره 3 فشار بودجه و تعداد اعضا به علت بزرگ شدن برنامه زمان بندی شده

هنگامی که این فشارها در پروژه وارد می شود شما می توانید انتظار داشته باشید که از آن بگذرید. برخی افراد خواستار برخی چیزها از شما می شوند. و از عباراتی همچون زیر استفاده می کنند:
•    من/ما فوراً به ... نیاز داریم.
•    من نمی توانم توجه کنم ...
•    آن بود قبلاً، این است الآن
•    شکل خارجی چگونه انجام می پذیرد.
•    بزودی این را بسازید
•    به این رسیدگی کنید
•    ما نمی توانیم از عهده ... بر بیاییم.
•    هیچ چیز دیگر امّا...
اینها جیزهایی است که احتمالاً شما در چنین مواقعی می شنوید و سپس درخواستها بیشتر و بیشتر میشود. بعضی از مردم در این مواقع کم می آورند. جدول را بازرسی نمایید. آیا کفه بودجه و تعداد اعضا با کفه برنامه زمان بندی شده میزان است. چرا شما می خواهید چیزی را که تازه به این مثلث اضافه گردیده را می خواهید به شکل عادی انجام دهید. آیا این چیزها می تواند بیشترین پیچیدگی را نسبت به گذاشتن یک ملاقات و درخواست برای دادن فضا و امکانات و بودجه بیشتر داشته باشد؟ آیا از کاری نگهداری می کنید که نمی دانید نتیجه آن چیست و آیا به زمان ممکن می رسد یا نه؟
آشفته و مضطرب و بی قرار بودن: اجرای پر طول دراز آزمایش پس از 30 ساعت کار مستقیم یا 100 ساعت کار در هفته بهترین روش برای پیدا کردن نقص ها نیست. هرچند راه خوبی برای خودنمایی می باشد. هنگامی که توسعه دهندگان به حرفه آزمایش کننده ها نگاه می کنند. امّا بدترین چیز برای یک پروژه این است که آزمایش کننده آن خودش مرتکب اشتباه شود. گزارش اشتباه هایی که قبلاً واقعاً وجود نداشته است (به عنوان مثال آزمایش کننده نمی تواند پروژه را  نماید و یا نمی تواند بصورت کامل پروژه را نصب نماید.) خوب این در حقیقت به توسعه دهندگان این مطلب را می رساند که یک ابله جنگلی زمان گرانبهای آنها را حرام کرده است. اگر شما واقعاً مراحل آزمایش را در شب یا در اواخر هفته انجام می دهید حتماً یک فهرستی از تمام کارها و چیزهایی که قبلاً داشته اید و چیزهایی که بعداً اضافه کرده اید تهیه نمایید. همچنین در زیر برخی قسمتها برخی توضیحات و اطلاعات لازم را اضافه کنید البته در صورتی که ذهنتان به شدت خسته است و به آن نمی توانید اعتماد نمایید. یک نوع دیگر هم می شود کارتان را ادامه بدهید و وقتی به جایی رسیدید که احساس می کنید اگر خسته باشید ممکن است مرتکب اشتباه و خراب شدن پروژه بشوید به رخت خواب خود رفته و شب را تا صبح استراحت نمایید.
ما در زیر تصویری از نمونه فهرستی که شب هنگام و موقعی که خسته هستید باید برای ادامه تهیه نمایید را آورده ایم البته این یک نمونه است و ممکن است با آن که شما تعیین می کنید اندکی متفاوت باشد.
آیا شما نسخه درستی از آزمایش را انتخاب نموده اید؟
نسخه آزمایش ..........
آیا از یک نسخه درست برای Build استفاده می کنید؟
نسخه Build .............
آیا شما از تنظیمات و پیکربندی درست سخت افزاری استفاده می کنید؟
توضیحات ...............
آیا شما از یک کنترلگر درست بازی و تنظیمات درست آن استفاده می کنید؟
توضیحات ...............
تنظیمات نصب را بنویسید؟
توضیحات ................
بازی در نخستین حالت درست پیش از اجرای آزمایش می باشد؟
توضیحات ................
آیا تمام قدم های آزمایش را منظم انجام داده اید؟
آیا اسناد آزمایش و اسناد نتیجه آزمایش را کامل کرده اید؟
آیا شما تمام ایراداتی را که پیدا کرده اید ثبت نموده اید؟
نزدیک بین بودن: وحشت نشانه ای است که می تواند بسیاری از نقاط نزدیک را در بربگیرد. بسیاری از پروژه بازی ها ماه ها طول می کشد. همچنین یک فاکتور اساسی برای رسیدن به هدف دانستن این موضوع است که امروز چه کاری را باید انجام بدهید؟ و چگونه باید آن را کار را انجام دهید؟ یک سوال از یک آزمایش کننده، هنگامی که او گذشته را در چهارچوب ذهنش قرار می دهد می خواهید این آخرین باری باشد که یک پروژه را آزمایش می کنید؟ مسلماً پاسخ می دهد: نه من می خواهم به بالاترین سطوح در ترفندهای پیدا کردن خطا برسم.
تیم های موفق ورزشی می دانند که چگونه از ترس دوری نمایند. هنگامی که آنها شکست می خورند به این دلگرم هستند که این بازگشت از پشت سر پیروزی بازی است زیرا موقعیت A شبیه به موقعیت B می باشد. آنها تمرینات خودشان را برای موقعیت جدید آماده می کنند و از شکست گذشته درس می گیرند. در استادیو های فیلم سازی و توسعه دهنده بازی موقعیت C یعنی استراحت و موقعیت D یعنی نبود احساس فشار برای ساخته شدن بدون واسطه نقص. تیم های شکست خورده معمولاً بارها یک یا بیشتر اجزاء شان را ثبت و ضبط می کنند.

اعتماد هیچ کس

ما اکنون یکی از قاعده های مهم برای تبدیل شدن شما به یک آزمایش کننده حرفه ای یعنی شجاعت را به صورت کامل برای شما شرح دادیم. اکنون می خواهیم به قاعده دوم یعنی اعتماد هیچ کس بپردازیم.
در حقیقت ما صنعت، فناوری و رقابت را در کنار هم داریم. سرمایه گذار پول بسیاری در این خط می گذارد و نمی خواهد پروژه اش خیلی راحت نابود بشود. فناوری ها نیازمند هستند چون بازی باید ساخته شود. به همین خاطر هم سرمایه گذار نمی تواند به هرکسی برای انجام کارهای پروژه اش اعتماد کند.
ترازوی کار: ارزیابی پایه برنامه آزمایش و تصمیمات و شهرت و نظریه های شما می تواند حواس شما را نسبت به این که چرا و چه کاری واقعاً باید انجام بدهید پرت کند. استفاده از شیوه های آزمایش و اسناد آن کار شماست و نتیجه آن باعث می گردد که شما با یک محیط کاری آزمایش بازی همکاری و کار کنید. اندازه گیری و تجزیه تحلیل نتایج آزمایش می تواند اطلاعاتی پیرامون نقاط قوت و ضعف بازی بدهد. در این حالت اعتماد شما بسیار کم می شود و در نتیجه آزمایشات شما هم بیشتر می شود.

اعتماد کمتر برابر با آزمایش بیشتر است.

امّا هنگامی که اعتماد شما به بیشترین حد می رسد در نتیجه آزمایش شما هم کمتر می شود.

اعتماد بیشتر برابر با آزمایش کمتر است.

در حقیقت شما باید تلاش کنید تا می توانید کمتر به چیزی در حین آزمایش تکیه و اعتماد کنید و به هیچ برنامه و کدی تکیه و اعتماد نکنید و به همه چیز به چشم شک نگاه کنید. شک از این که آیا درست است یا غلط. این باعث می گردد که آزمایشات شما بسیار بیشتر از قبل گردد و در نتیجه تعداد خطاها در بیشتر جاها به حداقل برسد.
آشنایی با تیم آزمایش کننده: تیم آزمایش کننده می توانند در طی انجام پروژه بازی خیلی محرک باشند. در برخی موارد خیلی کم یا در کل هیچ کاری از گروه آزمایش کننده انجام نمی گیرد. و اصل کار و بیشتر قدرت این گروه در انتهای کار انجام می گیرد. گاهی اوقات به آزمایش کننده ها، ضامن کیفیت (Quality Assurance) هم می گویند. این لقب بیشتر از سوی تولید کننده ها برای این گروه به کار می رود. زیرا آزمایش کننده ها تنها ابزار اصلی تولیدکننده ها برای اطمینان سرمایه گذاری در پروژه هستند. برخی از مردم هم اشتباهاً گروه های آزمایش کننده را مسئول کیفیت خوب یا بد بازی ها می دانند. در صورتی که این گروه فقط آزمایش می کند و کیفیت کار را بررسی می کند و این که یک بازی کیفیت خوب یا بد باشد مسئول هنرمندان، برنامه نویسان، طراح صدا و... که کارهایشان را با کیفیت خوب یا بد ارائه می کنند.
مدیر گروه آزمایش: این شخص را با القاب دیگر نظیر مدیر ضامن کیفیت یا مدیر آزمایش کنندگان بازی هم می شناسند. وظیفه این شخص همسو کردن راه با تیم توسعه می باشد. این با طرح های مدیر آزمایش و هماهنگ کردن کارهای آزمایش کنندگان متفاوت است.
مسئولبت مدیر گروه آزمایش در مدت تحویل توسعه آزمایش و اجرای نتایج آزمایش می باشد. فعالیت آزمایش و انتقالات شخصی که شناسایی شده هست و برنامه ها و تنظیمات لازم در حین اجرای پروژه از مسئولیت های مدیر گروه آزمایش می باشد.
همچنین مدیر گروه آزمایش کننده باید با روش های متعارف آزمایش آشنا باشد. این دربردارنده انتخاب درست ابزارهای آزمایش و تکنیک هایی است که برای آزمایش کدهای بازی استفاده می شوند. در برخی موارد، ابزارهای آزمایش نیاز به پشتیبانی دارند و یا باید با کدهای بازی سازگاری داشته باشند.
در طی پروژه، مدیر گروه آزمایش باید به دستیاران و اعضای تیم آزمایش دستورات تکنیکی خودش را در صورت نیاز بدهد. و باید برنامه ریزی هایش را در ملاقات هایی که با اعضای تیم می گذارد نمایش بدهد.
یک تیم توسعه بازی کوچک هم نیازمند به یک مدیر برای تیم آزمایش بازی است.
مهندسان آزمایش: در ظاهر شباهت ها و ارتباطاتی بین آزمایش کننده ها و برنامه نویس ها وجود دارد امّا در حقیقت نتیجه کار هر دو گروه کاملاً متفاوت است. مهندسان تیم آزمایش گاهی اوقات با نام های دیگری نظیر آزمایش کنندگان بازی، آزمایش کنندگان کیفیت بازی و مهندسان کیفیت بازی شناخته می شوند. نقطه تقابل بین برنامه نویسان و آزمایش کنندگان این است که آزمایش کنندگان می بینند که چه چیزی در بازی خطا است و برنامه نویسان به این نگاه می کنند که چه چیزی را درست بسازند. هر دو اینها شیوه هایی را برای کارشان با اشتیاق و حرارت دنبال می کنند. هرچند، هر دو می توانند بهتر از دیگری کارشان را انجام دهند. یک آزمایش کننده بهتر از برنامه نویس می تواند به قلب طراحی و چگونگی نوشته شدن کدها نفوذ کند. و سپس در راه آزمایش بازی بنویسند و اجرا کنند. توسعه دهندگان می توانند به بهبود کدهایشان ادامه بدهند و با یادگیری از انواع مشکلاتی که آزمایش کنندگان در کدهایشان پیدا کرده اند بهتر کد نویسی را انجام بدهند.
یک راه برای ارتباط سالم، این است که آزمایش کننده به همراه و کمک برنامه نویس آزمایش و همکاری کنند تا بتوانند مشکلات نرم افزاری (Bug) سخت را پیدا کنند.
آزمایش کنندگان بتا (Beta): آزمایش کنندگان بتا ترکیب ویژه ای در گروه آزمایش کننده بازی می باشند. آنها همچون یک لشگر جنگی برای بازی کردن بازی آماده می شوند. این افراد قبل از انتشار بازی به بررسی روند بازی می پردازند. تعداد این افراد از 12 نفر تا 100 نفر می باشد. این افراد کسانی هستند که مشکلات بازی را سخت تحمل می کنند و آن را گزارش می دهند. افراد این گروه آموزش دیده و خاص هستند و به محض دیدن مشکلی سریعاً مشکلات را گزارش می کنند. شاید یک بازی باز معمولی با چند بار باختن بر اثر مشکلات نرم افزار نتواند طاقت بیاورد ویا اگر در گوشه ای از مرحله بازی مشکلی در بافت دید بی اهمیت از کنار آن رد شود امّا یک آزمایش کننده بتا تمام مشکلات را به سرعت ثبت کرده و گزارش می دهد. مرحله آزمایش بتا یک مزیت دیری که دارد این است که می تواند برخی نواقص و مشکلات حین روند بازی را که ممکن است برای بازی باز پیش بیاید را فهمید. مسلماً این طور اشتباه ها به طراحی غلط بازی بر می گردد نه کد نویسی و در حقیقت طراحی بازی هم به نوعی آزمایش می شود.
وجود یک آزمایش کننده بازی: وجود یک آزمایش کننده بازی هنگامی شروع می شود که بازی باز باید بازی را شروع کند. این همان قسمتی است که نظر اکثر مردم به این حرفه جلب شده است. تصور کنید در مقابل بازی کردن پول می گیرد. برای بیشتر قسمت ها که نمی توانید آزمایش (بازی) کنید شما باید یک روز معین را تعیین کنید. و منتظر بمانید تا آن موقع بتوانید ادامه بدهید. امّا فقط بازی کردن بازی یک آزمایش خوب نیست. شما نیاز به داشتن حقه ها و ترفندهایی برای پیدا کردن خطا دارید. همچنین برای این که خوب کارتان را انجام بدهید به دیگر چیزها نظیر اسناد گزارش خطای نرم افزاری (Bug) ، گزارش پیشرفت آزمایش کمک گرفتن از توسعه دهندگان برای حل مشکلات نرم افزاری نیاز دارید. فکر کنید که اجزای کاری شما همچون اجرای یک پیانو می باشد.

اجرای بازی: در خانه، شما برای تفریح بازی می کنید. شما انتخاب کنید که چگونه بازی کنید. هنگام بازی و چگونگی بازی. آزمایش بازی ها هم می توانند تفریح باشند. امّا تفاوت آن این است که انتخابتان و چگونه و چه موقع بازی کردنتان محدود است. همه چیزی که شما هنگام بازی انجام می دهد با یک هدف خاص است. و در حین بازی باید تمام قواعد آزمایش را که در ابتدای مقاله گفتیم رعایت نمایید. در ابتدا کار شما اجرای یک مقدار آزمایشاتی است که در اختیارتان گذاشته اند. برخی از آزمایشات بسیار ویژه است و قدم به قدم باید راهنمایی شوید. شما باید دقت بسیاری داشته باشید و به ریز جزئیات توجه داشته باشید. آزمایش واسطه کاربری (UI) یکی از قالب های خوب برای آزمایش است. ما در اینجا یک بخش نمونه و کوچک از بازی Star Wars: Knights of the Old Republic برای کنسول Xbox می باشد.

1.    گزینه New Game را از منوی اصلی انتخاب نمایید.
•    از روشن شدن خطوط اطراف مرد بزه کار مطمئن شوید. (تصویر پایین)
•    توضیحات شخصیت بزه کار را بررسی نموده و از درست نوشته شدن آن مطمئن شوید.
2.    با استفاده از D-Pad به چپ بروید.
•    از روشن شدن خطوط اطراف مرد بزه کار مطمئن شوید.
•    توضیحات شخصیت باید تغییر کرده باشد.
3.    با استفاده از D-Pad به راست بروید.
•    از روشن شدن خطوط اطراف مرد بزه کار مطمئن شوید.
•    توضیحات شخصیت باید تغییر کرده باشد.
و به همین منوال آزمایش ادامه پیدا کرده و نتایج ثبت و ضبط می گردد.
همچون چیزی که دیدید شما باید عملیات ویژه ای را برای انجام و بررسی قدم به قدم جزئیات انجام دهید. این می تواند تا حدودی خسته کننده باشد مخصوصاً هنگامی که شما این آزمایش ها را یکی پس از دیگر و پشت سر هم انجام می دهید. امّا در عوض خیلی زیرکانه می تواند با استفاده از مراحل گذشته اشکالات را فهمیده و ریشه یابی کنید. شما باید کاملاً تمرکز داشته باشید. دیگر کارهای شما این است که دستورات بی انتها را گیر بیاندازید و آنها را بیابید. و در برگه لیست بررسی هایتان آنها را ثبت و ضبط کنید.
موفقیت شما در این است که بتوانید اجرائیات خودتان در حرکات یک بازی جنگی را در برگه لیست بررسی بنویسید. به عنوان نمونه تصویر زیر برگه لیست بررسی Tina Armstrong  آزمایش کننده بازی Dead or Alive 3 می باشد.

از آنجایی که این لیست بررسی از تمام وقایع بازی نگهداری و مراقبت می کند. طرح کلی می تواند این باشد که شما می توانید از یک محدوده وسیع نتایج بدون ترس از برداشتن قدم های دیگر تا هدف استفاده نمایید. در بازی NBA Street 2 شما توانایی بازکردن بازیکن ها با لباس های ویژه را وقتی به نتایج ویژه در طی بازی دست پیدا کنید خواهبد داشت. تصور کنید که شما باید قدم به قدم و دکمه به دکمه باید تمام این مراحل را تعریف و تعقیب نمایید تا تمام بازی کامل شود. در عین حال شما به عنوان یک آزمایش کننده نیاز به دانستن اجرای درست و قدم به قدم مراحل را دارید. و باید بازی را تا رسیدن به اهداف و گرفتن پیراهن ها بازی کنید. خوب این تا حدودی سخت است که بخواهید قدم به قدم برای این طرح نتایج را بنویسید و به جای آن باید نتیجه به شکل زیر نوشته شود.
در زیر نتایج گرفته شدن لباس ویژه برای هر بازیکن نوشته شده است.
Bill Russell : تمام تیم ها را در محدوده جنوب کوباند و بدون شکست بود.
Bill Walton : به حد نصاب امتیاز 1,000,000 رسید.
Connie Hawkins : 20 بار در بازی دفاع کرد و برنده شد.
Elgin Baylor : مانع پیروزی تیم حریف شد.
James Worthy : تمام تیم ها را در محدوده شمال کوباند و بدون شکست بود.
Jerry West : بازی را بدون دفاع در برابر حتی یک شوت برد.
Oscar Robertson : تمام تیم ها را در محدوده جنوب غربی کوباند و بدون شکست بود.
Walt Frazier : تمام تیم ها را در محدوده مرکزی کوباند و بدون شکست بود.
در اجرای این آزمایش ها همچنین شما باید نوشته های دیگر آزمایش کننده ها پیرامون اجرا را پیدا کرده و بخوانید. البته این سبک جدول بررسی که الان گفتیم بیشتر به درد بازی های با سبک RPG یا بازی هایی که ممکن است چندین راه به پایان داشته باشند و یا حتی بازی هایی که به کاربر جوایزی را مانند لباس می دهند و... می خورد. بسیاری از جدول های بررسی است که توسط خود آزمایش کننده ها و بصورت کاملاً اختصاصی نوشته می شود. که شما هم می توانید برای راحتی کار خودتان یک نوع سبک مطابق با بازی بنویسید.
شناسایی خطای نرم افزاری (Bug): آزمایش کنندگان بازی دو هدف دارند. اولین هدف پیدا کردن عیوب و نقص ها در کدهای و طراحی بازی است و دومین آن نشان دادن قسمت هایی از بازی است که درست کار می کند. هنگامی که آزمایش کننده نمی تواند یک مشکل را پیدا کند به آن قسمت برچسب (تایید) و هنگامی که در آن قسمت مشکلی پیدا کند برچسب (خطا) می زند.
دیگر نتایج احتمالی که ممکن است برای آزمایش کننده پیش بیاید برچسب (مانع) است. که این برچسب هنگامی زده می شود که مشکلی برای بازی پیش آمده که دیگر اجازه نمی دهد شما سایر قسمت های بازی را بینید و آزمایش کنید.
همچنین آزمایش کننده می تواند از یک برچسب دیگر با عنوان (در دسترس نیست) استفاده نماید. معنی این برچسب نداشتن نسخه ای از بازی برای آزمایش در دست آزمایش کننده است. زیرا توسعه دهندگان مشغول تحلیل و گرفتن کلیه عناصر بازی همچون مراحل، آیتم ها، توابع و شخصیت هایی که در مرحله آزمایش باید منتشر شود هستند.
اکنون به پایان قسمت اوّل مقاله رسیدیم در قسمت دوم مطالب مهمتری پیرامون آزمایش بازی را به شما خواهیم گفت.