استودیوهای بازی‌های سرویس‌محور از ربات‌های هوش مصنوعی برای تست‌های رگرسیون استفاده می‌کنند، نه برای کشف آنچه بازی را لذت‌بخش می‌سازد
بازی‌های سرویس‌محور به‌صورت هفتگی یا دوهفته‌یک‌بار به‌روزرسانی محتوا منتشر می‌کنند، و هر یک از این به‌روزرسانی‌ها باید در برابر کل بازی موجود تحت تست رگرسیون قرار گیرد پیش از آنکه به‌صورت زنده منتشر شود. این حساب و کتاب، یعنی سرعت ثابت محتوا ضرب در سطح تست میراثی‌ای که در حال رشد است، چیزی است که طی دو سال گذشته استودیوها را به سمت ربات‌های آزمایش خودکار سوق داده است، نه یک آرمان کلی برای حذف آزماینده‌های انسانی. نتیجه، خط تولید تست کیفیتی است که در حال دوشاخه‌شدن است: ماشین‌ها کار تکراری رگرسیون را جذب می‌کنند، و کاهش نیرو تقریباً به‌طور کامل در همین دسته رخ می‌دهد.
ربات‌ها واقعاً چه کاری انجام می‌دهند
ابزارهای آزمایش خودکار که اکنون در تولید واقعی استودیوهای متوسط و بزرگ استفاده می‌شوند، در دو دسته کلی قرار می‌گیرند. دسته اول عامل‌های اسکریپت‌شده یا مبتنی بر یادگیری تقویتی هستند که یک نسخه ساخت را از ابتدا تا انتها بازی می‌کنند، مسیرهای شناخته‌شده را دنبال می‌کنند یا فضاهای حالت را کشف می‌کنند، و خرابی‌ها، قفل‌شدن‌های نرم، برخوردهای معیوب و کاهش نرخ فریم را بدون نیاز به اینکه یک انسان همان مرحله را برای چهلمین بار طی کند، علامت‌گذاری می‌کنند. هم ابزار Automated QA یونیتی و هم استارتاپ دانمارکی Modl.ai نسخه‌هایی از این فناوری را به استودیوهایی می‌فروشند که نمی‌خواهند آن را به‌صورت داخلی بسازند. دسته دوم، تست رگرسیون بصری است: مقایسه خودکار تصاویر صفحه‌نمایش در برابر یک مرجع شناخته‌شده و تأیید‌شده، که خرابی‌های رابط کاربری و HUD، ظاهرشدن ناگهانی بافت‌ها و خطاهای رندر را شناسایی می‌کند که یک پچ محتوا بدون آنکه کسی متوجه شود وارد کرده، تا اینکه یک بازیکن از آن در شبکه‌های اجتماعی عکس بگیرد.
استودیوهای بزرگ‌تر نسخه‌های داخلی هر دو را ساخته‌اند. اکتیویژن بلیزارد و اپیک به‌صورت علنی درباره استفاده از مجموعه‌های رگرسیون هدایت‌شده با ربات برای پوشش بخشی از تست کیفیت که کاملاً مکانیکی است صحبت کرده‌اند؛ یعنی آیا نسخه ساخت خراب می‌شود، آیا مرحله بارگذاری می‌شود، آیا اسلحه جدید برخوردها را درست ثبت می‌کند، که این‌ها شبانه روی صدها پیکربندی اجرا می‌شوند پیش از آنکه حتی یک انسان نسخه ساخت را لمس کند.
چرا این موضوع دقیقاً در یک جای خاص نیرو را کاهش می‌دهد
کاری که ربات‌های تست رگرسیون در آن خوب عمل می‌کنند دقیقاً همان کاری است که قبلاً بزرگ‌ترین نیروی تست کیفیت را می‌طلبید: اجرای همان مجموعه تست‌ها در برابر هر نسخه ساخت، هر پلتفرم، هر بومی‌سازی زبانی، بار دیگر و بار دیگر، برای شناسایی خرابی‌های مکانیکی‌ای که سرعت محتوا به همراه می‌آورد. این کاری ذاتاً تکراری است، و دقیقاً همین ویژگی آن را قابل خودکارسازی می‌کند، و دقیقاً به همین دلیل، کاهش این بخش به یک کاهش واقعی نیرو تبدیل می‌شود، نه یک داستان بهره‌وری که تعداد نیروی انسانی را تغییر نمی‌دهد.
آنچه ربات‌ها در آن خوب نیستند، و آنچه استودیوها به‌صراحت تلاشی برای خودکارسازی آن نمی‌کنند، تست‌های ذهنی و خصمانه است: اینکه آیا یک اسلحه جدید بیش‌ازحد قدرتمند احساس می‌شود، آیا تغییری در سیستم همتایابی واقعاً کیفیت مسابقه را بهبود می‌دهد، و به‌طور حیاتی، یافتن آن نقطه‌ضعفی که یک بازیکن خلاق در هفته اول کشف خواهد کرد، چیزی که هیچ مسیر ربات اسکریپت‌شده‌ای هرگز به آن برنمی‌خورد. این کار نوعی تفکر خصمانه و شهودی درباره چگونگی تلاش یک انسان برای شکستن بازی را می‌طلبد که مهارتی به‌طور واقعی متفاوت از اجرای همان گذر رگرسیون برای هزارمین بار است. استودیوهایی که تست رگرسیون خودکار را پذیرفته‌اند گزارش می‌دهند که نیروی انسانی باقی‌مانده تست کیفیت خود را جابه‌جا کرده‌اند، نه حذف کرده‌اند، دقیقاً به سمت همین کار تعادل‌سنجی و شکار نقاط ضعف.
نکته ظریفی که در تیترهای «هوش مصنوعی جای تست کیفیت را می‌گیرد» گم می‌شود
این داستانی متفاوت از عقب‌نشینی مدل کسب‌وکار بازی‌های سرویس‌محور است که امسال به‌طور گسترده پوشش داده شده، جایی که استودیوهای متوسط به‌طور کامل از بازی‌های سرویس‌محور کنار کشیده‌اند چون اقتصاد نگهداری آن‌ها کار نمی‌کرد. این موضوع به‌طور خاص درباره خط تولید تست برای استودیوهایی است که همچنان بازی‌های سرویس‌محور را اجرا می‌کنند و باید محتوا را با سرعتی ثابت عرضه کنند بدون اینکه هزینه تست رگرسیون به‌صورت خطی با هر ویژگی جدیدی که اضافه می‌کنند رشد کند. کاهش نیروی انسانی واقعی است، اما در نقش‌هایی متمرکز شده که از قبل مکانیکی‌ترین و کم‌تمایزترین بخش تست کیفیت بودند؛ نوع کاری که شاید همواره کاندیدای خودکارسازی بوده، به‌محض اینکه ابزارها به‌اندازه کافی برای اعتمادپذیری بالغ می‌شدند.
چگونه یک استودیو کوچک‌تر باید واقعاً این را به کار گیرد
اگر یک عنوان بازی سرویس‌محور را مدیریت می‌کنید و به تست خودکار فکر می‌کنید، ترتیب اجرا اهمیت بیشتری از انتخاب ابزار دارد. با ربات‌های تست دودکشی شروع کنید که خرابی‌های مخرب نسخه ساخت و شکست‌های بارگذاری را پیش از انتشار یک پچ روزانه یا هفتگی شناسایی می‌کنند؛ این بیشترین ارزش و کمترین ریسک را در خودکارسازی دارد چون شکست در آنجا انتشار را به‌طور کامل مسدود می‌کند. سپس مقایسه رگرسیون بصری را اضافه کنید، به‌طور خاص در مورد تغییرات رابط کاربری و HUD، چون این‌ها بررسی‌های پرتکرار و کم‌پیچیدگی هستند که ربات‌ها به‌طور قابل‌اعتماد از پس آن‌ها برمی‌آیند. آزماینده‌های انسانی خود را در سراسر این فرآیند روی تست تعادل و شکار نقاط ضعف متمرکز نگه دارید؛ تلاش نکنید ابتدا آن را خودکار کنید، چون ابزارهای تست ذهنی و خصمانه به هیچ‌وجه به بلوغ خودکارسازی رگرسیون نرسیده‌اند، و رفتار با آن به‌عنوان مسئله‌ای حل‌شده اجازه می‌دهد مشکلات واقعی تعادل و امنیت به دست بازیکنان برسد.
تست بومی‌سازی سزاوار ذکر جداگانه است چون بین دو دسته قرار می‌گیرد. بررسی اینکه متن ترجمه‌شده از یک کادر رابط کاربری سرریز نمی‌کند، چیدمان‌های راست‌به‌چپ درست رندر می‌شوند، و یک پچ به‌طور پنهانی یک فایل زبان را حذف نکرده، همگی بررسی‌های مکانیکی هستند که یک ربات می‌تواند در هر زبان پشتیبانی‌شده روی هر نسخه ساخت اجرا کند؛ کاری که پیش‌تر ساعات نامتناسبی از تست کیفیت را مصرف می‌کرد، دقیقاً چون هم با حجم محتوا و هم با تعداد زبان‌ها به‌طور همزمان مقیاس می‌یافت. این موضوع آن را به یکی از بهترین اهداف خودکارسازی اولیه برای یک استودیو کوچک‌تر با بودجه محدود تست کیفیت تبدیل می‌کند، چرا که آزماینده‌های انسانی را از خسته‌کننده‌ترین بخش تست بومی‌سازی آزاد می‌کند، و قضاوت دشوارتر، یعنی اینکه آیا یک ترجمه واقعاً برای یک گویشور بومی طبیعی به نظر می‌رسد یا نه، را نزد افراد نگه می‌دارد، جایی که به آن تعلق دارد.