تست بازی نه «چند ساعت بازیکردن» است و نه تلاش برای تبدیل Fun به یک عدد جادویی. بازی یک سامانهٔ stateful، real-time، content-heavy و اغلب چندپلتفرمی است؛ بنابراین باید Build، Input، State، Save، Economy، Network، Rendering، Audio، Accessibility و تجربهٔ بازیکن را با Claimهای جدا آزمود. Playtest نیز پژوهشی محدود برای پاسخ به یک سؤال طراحی است، نه رأیگیری دربارهٔ خوب یا بد بودن کل بازی.
این راهنما مسیر عملی را میسازد: Game Quality Charter → Build/Platform Identity → State/Mechanic Oracle → Technical Matrix → Playtest Question → Participant/Task/Protocol → Observation/Telemetry/Interview → Evidence/Triage → Release Gate. هدف، وعدهٔ موفقیت تجاری یا «تضمین سرگرمی» نیست؛ هدف آن است که تیم بداند کدام Claim فنی یا تجربی، در چه شرایطی و با چه محدودیتی پشتیبانی میشود.
خلاصهٔ اجرایی تست بازی
- Player، Platform، Mode، Session و Quality claim را مشخص کنید.
- هر نتیجه را به Build/branch/commit/content/config/device/input/save/network وصل کنید.
- Game state و Mechanic را با Invariant، Transition و Oracle مستقل تست کنید.
- Smoke، Functional، Content، Compatibility، Performance، Network، Save و Accessibility را جدا طراحی کنید.
- Automation را برای تکرارپذیری و State coverage به کار ببرید، نه اثبات Fun.
- برای Playtest فقط یک سؤال تصمیمساز و Participant criteria مرتبط انتخاب کنید.
- Task success، path، error، moderator rescue، telemetry و گفتهٔ Participant را تفکیک کنید.
- میانگین Rating را جای Observation، Support، Slice و Counterexample نگذارید.
- Issue فنی، usability barrier، design hypothesis و preference را با workflow جدا ثبت کنید.
- Release gate را بر Evidence، ریسک، Platform requirement و محدودیت آزمون بنا کنید.
تست بازی چه Intentهایی دارد؟
| Intent | پرسش | Evidence |
|---|---|---|
| Functional/State | Rule و Transition درست است؟ | assertion/state trace |
| Content | Map/asset/quest/item قابلبارگذاری و متصل است؟ | content scan/traversal |
| Compatibility | روی Platform/Device/Input matrix چه میشود؟ | build-device run |
| Performance/Stability | frame/load/memory/crash در workload چیست؟ | trace/profile/crash dump |
| Network/Multiplayer | authority/sync/reconnect/migration درست است؟ | multi-client/server trace |
| Accessibility | Player با نیاز/تنظیم معین به Task دسترسی دارد؟ | guideline + player test |
| Usability/Onboarding | Player هدف میتواند Goal را بفهمد و انجام دهد؟ | observed task study |
| Experience/Design | کدام لحظه چرا tension/confusion/delight ساخت؟ | observation + interview + telemetry |
| Platform/Store readiness | Requirement و packaging/release flow آماده است؟ | platform-specific evidence |
مرز این صفحه با مقالات تخصصی سایت
این صفحه مالک orchestration تست بازی است. روش عمومی مطالعهٔ کاربر در راهنمای Usability Testing و Metricهایی مانند Task Success و SUS در معیارهای تست کاربردپذیری تشریح شدهاند. برای Workload و p95/p99 به برنامه تست عملکرد و برای Device matrix به تست سازگاری بروید.
| موضوع | مالک داخلی | اتصال بازی |
|---|---|---|
| Accessibility عمومی | تست دسترسپذیری | Input/caption/motion/difficulty/player barriers |
| Exploration | تست اکتشافی ساختاریافته | Game charter/session/debrief |
| Non-determinism | تست سیستمهای غیرقطعی | seed/replay/repeated trial |
| فارسی/RTL | تست i18n/L10n فارسی | subtitle/HUD/input/save/font |
Game Quality Charter
game_quality_charter:
player/audience: declared, not “everyone”
platform/mode: PC single-player / controller+keyboard
build/content/config: exact identities
core_promise: what meaningful experience/action is intended?
critical_paths: boot → menu → new game → tutorial → save/load
quality_claims:
- state correctness
- input responsiveness
- readable feedback
- recoverable save
- accessible alternatives
- target-player task comprehension
prohibited_harms/dark_patterns: declared
known_limits: content/mode/platform/language
evidence_owner / decision_owner / review_date
Charter واژههایی مثل «Fun»، «fair difficulty» یا «immersive» را به سؤال قابلبررسی تبدیل میکند. مثلاً «بازیکن تازهوارد در Build B42 بدون کمک Moderator میتواند Dodge را یاد بگیرد و Encounter اول را تمام کند؟» بهتر از «Tutorial سرگرمکننده است؟» است. پاسخ نیز فقط برای Participant/Task/Build/Session آزمودهشده اعتبار دارد.
هویت Build؛ شرط بازتولید هر باگ
| Identity | نمونه | چرا لازم است؟ |
|---|---|---|
| Build | build ID + branch + commit | تفکیک binary دقیق |
| Content | asset bundle/map/localization version | کد یکسان/محتوای متفاوت |
| Config/Feature flag | config hash | difficulty/economy/experiment |
| Platform | OS/console/store/region | API/package/requirement |
| Hardware | CPU/GPU/RAM/storage/display | performance/render/device |
| Input | controller/keyboard/layout/firmware | mapping/dead zone/haptics |
| Account/Profile | synthetic entitlement/progression | unlock/cloud/profile state |
| Save | schema/checkpoint/digest | reproduction and migration |
| Network | client/server/region/protocol/NAT profile | authority/sync/reconnect |
| Run/Session | run ID + seed + attempt | trace/replay/evidence |
مستند Steamworks دربارهٔ Branchهای Beta نشان میدهد Branchها Buildهای مشخصی هستند که میتوان برای تست توزیع کرد و تغییر Build فعال نیازمند اقدام روشن است. این فقط یک نمونهٔ Platform workflow است؛ Steam requirement یا راه انتشار همهٔ بازیها نیست.
Build Manifest و Test Session Contract
game_test_session: session_id / purpose / owner build/branch/commit/content/config digests platform/device/input/display/audio/network language/locale/timezone account/profile/entitlements/save snapshot mode/map/quest/checkpoint/difficulty random seed / server / clients / attempt test charter/tasks/oracles capture: video + input + logs + metrics + crash dump privacy/consent/retention if human playtest cleanup/reset and side-effect sink verdict/limits/follow-up
State Model؛ ستون تست Gameplay
Boot → Title → Profile → MainMenu → Loading → Playing Playing → Paused → Playing Playing → Checkpoint → SaveCommitted Playing → Death → Respawn/Reload Playing → Disconnect → Reconnect/Offline/Fallback Playing → Quit → Save/Discard confirmation Each transition needs: event + guard + state delta + feedback + persistence + recovery
Bugهای بازی اغلب از ترکیب Stateها میآیند: Pause هنگام cutscene، Load در transition، controller disconnect وسط QTE، fast travel با quest flag ناسازگار، respawn بعد از inventory commit یا reconnect پس از authority change. پوشش Screen کافی نیست؛ World، Player، Quest، Inventory، Economy، AI، Network و Save state باید به هم Trace شوند.
Mechanic Contract و Oracle
mechanic: dodge input: button press / remapped alternatives preconditions: playing, stamina≥cost, not stunned timing: input buffer + startup + invulnerability + recovery windows state_delta: stamina, animation, position, collision flags feedback: visual + audio + haptic + accessible alternative interruptions: pause, hit, terrain, device disconnect, network correction invariants: stamina never below declared minimum one input produces at most one accepted action invulnerability matches frame/state contract save/load cannot persist transient invulnerability oracle: event/state trace + frame capture + collision/debug data known nondeterminism/tolerance: declared
تست Functional و Content را جدا اما متصل کنید
| سطح | نمونه | Oracle |
|---|---|---|
| Pure rule | damage/cooldown/economy formula | independent calculation/property |
| Component | inventory/equipment/quest state | state snapshot/invariant |
| Feature | craft/purchase/save/reload | cross-system trace |
| Level | spawn/nav/collision/trigger | content validation/traversal |
| Asset | missing texture/audio/animation/localization | reference/dependency scan |
| Packaged build | boot/input/platform API | real artifact run |
| E2E path | new profile→tutorial→save→resume | player-visible + internal state evidence |
Automation در تست بازی چه چیزی را خوب پوشش میدهد؟
مستند Automation Test Framework در Unreal Engine Unit، Feature، Content Stress و Screenshot Comparison را از هم تفکیک میکند و توصیه میکند تست به state یا ترتیب اجرا وابسته نباشد و محیط را پاک تحویل دهد. این یک نمونهٔ Engine-specific است، نه توصیهٔ انتخاب Unreal یا پوشش خودکار تمام Gameplay.
| مناسب Automation | نیازمند Human/ترکیبی | چرا؟ |
|---|---|---|
| formula/invariant/state transition | control feel | بدن/دستگاه/expectation |
| map/asset/reference scan | comprehension/onboarding | mental model |
| boot/smoke/path replay | tension/pacing/boredom | experience/context |
| save/load/migration fixture | social dynamics | human interaction |
| multiclient protocol assertions | meaningful choice | design interpretation |
| performance capture/screenshots | accessibility with players | barrier lived experience |
Determinism، Seed و Replay
Seed ثابت میتواند بخشی از random generation یا AI را تکرارپذیر کند، اما physics، frame timing، thread scheduling، network order و external service ممکن است هنوز تغییر کنند. Replay ورودی نیز همیشه replay state نیست. Build/seed/input stream/initial state/tick rate و tolerance را ثبت کنید و نتیجهٔ یک run را قانون قطعی دربارهٔ احتمال Failure ننامید.
| Evidence | میتواند نشان دهد | نمیتواند بهتنهایی نشان دهد |
|---|---|---|
| Input replay | همان command sequence | همان physics/network state |
| Fixed seed | همان PRNG stream در Scope | تمام nondeterminism |
| Video | player-visible symptom | internal cause/state |
| State log | declared transitions | perception/feel |
| Crash dump | failure context | reproduction probability |
Platform و Device Matrix را از Risk بسازید
| بُعد | نمونه Cell | ریسک |
|---|---|---|
| Platform/OS | PC/console/handheld + version | API/package/lifecycle |
| CPU/GPU/RAM | min/target/high + driver | frame/memory/render |
| Storage | HDD/SSD/free-space pressure | load/stream/install/update |
| Display | resolution/aspect/HDR/refresh | UI/crop/frame pacing |
| Input | keyboard/controller/touch/remap | focus/glyph/dead-zone |
| Audio | stereo/surround/headphone/no-audio | cue/mix/fallback |
| Locale | fa-IR/RTL/digits/fonts/subtitle | layout/readability/save |
| Network | latency/loss/NAT/disconnect | sync/authority/rejoin |
| Lifecycle | suspend/resume/background/controller loss | state/save/resource |
همهٔ ترکیبها را brute-force نکنید. Platform requirement، telemetry، audience، min/target spec، feature risk و change surface را وزن دهید؛ Cellها و Exclusionها را نسخهدار کنید. Emulator یا Editor run، Hardware/packaged-build evidence را جایگزین نمیکند.
Performance بازی: FPS متوسط کافی نیست
| Claim | Metric | Workload/Oracle |
|---|---|---|
| Frame delivery | frame-time distribution/hitches | scene/path/camera/effect density |
| Loading | cold/warm load and streaming stall | storage/cache/build identity |
| Memory | working set/VRAM/growth/peak | long traversal/reload cycle |
| CPU/GPU | thread/GPU timings/saturation | target device/settings |
| Thermal/power | clock/temp/battery where available | handheld/mobile sustained session |
| Stability | crash/hang/ANR/soak duration | population and censoring |
| Network | RTT/jitter/loss/snapshot age | declared topology/fault profile |
Profile داخل Editor ممکن است با packaged build فرق کند. Scene، path، camera، settings، resolution، driver، warm-up، background load، capture overhead و run count را ثبت کنید. «۶۰ FPS» بدون frame-time distribution، target hardware و quality settings یک Claim کامل نیست.
Multiplayer و Network Testing
| ریسک | Fault/Scenario | Oracle |
|---|---|---|
| Authority | client conflicting action | server state wins per contract |
| Ordering/Duplicate | reorder/redelivery | one valid state transition |
| Loss/Jitter | profiled packet impairment | bounded prediction/correction |
| Disconnect/Rejoin | drop at combat/trade/checkpoint | identity/state/recovery |
| Host migration | host leaves | ownership/timer/score continuity |
| Matchmaking | region/party/skill/input pool | declared constraints/fallback |
| Cheat/abuse | unauthorized client claim | validation/audit/rate policy |
| Voice/chat | block/mute/report/reconnect | safety/privacy/accessibility |
Network simulation باید محل Injection و مدل Fault را روشن کند؛ latency اضافهشده در Client با congestion واقعی یا server overload یکی نیست. Multiplayer Playtest نیز رفتار اجتماعی، moderation و consent را وارد Scope میکند و صرفاً Functional session چند Client نیست.
Save، Progression و Economy
| ناحیه | تست | Invariant |
|---|---|---|
| Save atomicity | interrupt before/during/after commit | old or new valid state، نه half-state |
| Migration | old schema→new build | declared data/progression preservation |
| Cloud conflict | two devices/offline/late sync | visible conflict policy/no silent loss |
| Checkpoint | death/quit/crash/reload | world/player/quest consistency |
| Inventory | grant/spend/drop/trade/retry | no negative/duplicate effect |
| Economy | price/reward/currency transaction | ledger conservation per design |
| Entitlement | offline/revoke/restore/region | no unauthorized loss/access |
save_test: build/from_schema/to_schema initial_save_digest + profile/account action sequence + checkpoint fault moment: before/write/fsync/rename/cloud-sync/after expected state alternatives forbidden partial states local/cloud/conflict evidence recovery/rollback/manual support path cleanup: synthetic profile only
Accessibility بخشی از Playability است
Xbox Accessibility Guidelines مجموعهٔ Best practiceهایی برای Text، Contrast، Captions، Audio، Input، Difficulty، UI، Time limits، Motion، Photosensitivity، Communication و Support ارائه میدهد و صریحاً میگوید XAG چکلیست انطباق حقوقی نیست. از آن بهعنوان منبع ایده/Guardrail و Test design استفاده کنید، نه Certification.
| Barrier | Claim/Test | Evidence |
|---|---|---|
| Input | remap/single-stick/hold-toggle/timing | device/player task |
| Visual | text/contrast/color-independent cue/scale | inspection + player use |
| Audio | caption/non-speech cue/volume channels | content coverage/timing |
| Motion | camera shake/FOV/blur/flashes settings | config persistence + player feedback |
| Cognitive | objective clarity/pause/repeat/tutorial pace | observed task |
| Difficulty | assist choices preserve declared goal | mechanic/state tests |
| Communication | text/voice alternatives/block/report | multiplayer workflow |
تستر بدون معلولیت نباید نقش «بازیکن دارای معلولیت» را بازی کند و نتیجه را نماینده بداند. ابزار/inspection با مشارکت افراد دارای تجربهٔ زیسته و accommodationهای امن کامل میشود. Disability، skill و preference سه مفهوم یکسان نیستند.
Localization فارسی، RTL و محتوای بازی
- Font fallback، shaping، نیمفاصله و ترکیب فارسی/لاتین/عدد.
- RTL در Menu، HUD، inventory grid، tooltip و subtitle.
- Persian/Arabic/Latin digits و key glyphهای پلتفرم.
- Subtitle timing، speaker، non-speech caption و line length.
- Variable/plural/gender/context و متنهای dynamic.
- نام Save/Profile/Server با Unicode و normalization.
- Cutscene، texture-baked text، voice-over و lip-sync coverage.
- Time/date/timezone و نمایش شمسی در صورت Claim محصول.
Playtest با QA Execution یکی نیست
| فعالیت | Participant | هدف |
|---|---|---|
| QA functional run | تستر آشنا با Build | Contract/defect/reproduction |
| Expert review | Designer/UX/Accessibility expert | heuristic/design critique |
| Internal playtest | همکار با exposure ثبتشده | early hypothesis/counterexample |
| Target-player study | افراد مطابق recruitment criteria | task/comprehension/experience |
| Accessibility playtest | players with relevant lived experience | barrier/assistive setup |
| Beta/field test | broader opted-in participants | environment/device/content signals |
QA میتواند فرضیهٔ Design بسازد و Evidence دقیق گزارش کند، اما سلیقهٔ یک تستر نمایندهٔ Audience نیست. «خود را جای تازهکار گذاشتن» جای Recruiting بازیکن تازهوارد را نمیگیرد. Internal expert feedback و Target-player evidence هر دو ارزش دارند، به شرط آنکه منبعشان در Report مخلوط نشود.
Playtest Question Contract
playtest_question: decision: keep/change tutorial prompt sequence research_question: can first-time target players complete Dodge task? build/platform/input/language: pinned participant_criteria: relevant prior experience/exclusions task/start_state/end_condition/timebox: declared moderator_script/rescue_rule: fixed observations: path, hesitation, error, retry, rescue, completion telemetry: event dictionary/version; no hidden inference interview: neutral prompts after task measures: counts + support + quotes/context consent/privacy/recording/compensation/withdrawal: explicit stop/safety/accessibility conditions analysis plan/slices/decision rule: predeclared known_limits: sample/context/novelty/order effects
Participant Recruitment و اخلاق Playtest
- Target audience را با رفتار/تجربهٔ مرتبط تعریف کنید، نه stereotype.
- Employee، fan، expert، first-time و accessibility participant را مخلوط و ناشناس گزارش نکنید.
- سن، رضایت سرپرست/قانون محلی و حمایت از کودک را در صورت حضور minor بررسی کنید.
- هدف، مدت، recording/telemetry، incentive، confidentiality و حق توقف/حذف را روشن کنید.
- Motion sickness، flashing، audio، horror، violence، chat/harassment و physical setup را در safety screen بگنجانید.
- Accommodation و break را بدون تنبیه Metric فراهم کنید.
- NDA مانع گزارش harm، abuse یا حق قانونی Participant نشود؛ مشاورهٔ حقوقی محلی لازم است.
Task، Moderator و Rescue Rule
| جزء | تعریف | خطای رایج |
|---|---|---|
| Start state | save/profile/inventory/tutorial exposure | Participantها از state متفاوت |
| Task prompt | Goal بدون لو دادن مسیر | leading instruction |
| End condition | observable completion/failure/withdrawal | moderator judgement مبهم |
| Timebox | برای safety/protocol، نه سرعت اجباری | frustration مصنوعی |
| Rescue | چه زمانی/چقدر کمک؟ | help پنهان و success جعلی |
| Think-aloud | اختیاری/آموزش/اثر روش | رفتار طبیعی فرضکردن |
| Order | counterbalance/randomize where relevant | learning/fatigue confound |
| Moderator | script/neutrality/debrief | دفاع از Design |
Observation، Telemetry و Self-report سه شاهد متفاوتاند
| شاهد | نمونه | نمیگوید |
|---|---|---|
| Observation | hesitation/path/error/rescue | علت درونی قطعی |
| Telemetry | event/time/state sequence | احساس یا نیت |
| Self-report | گفته/برداشت/Rating | رفتار/علت عینی قطعی |
| Game state trace | flag/inventory/AI/network | فهم Player |
| Video/Input capture | visible context and command | کاملبودن internal state |
| Moderator note | context/intervention | unbiased truth |
Telemetry Contract؛ Event name بهتنهایی کافی نیست
playtest_event: event_id / session_id / participant_pseudonym build/content/config/platform/input event_name + schema_version game_time / wall_time / sequence map/state/task/attempt action/result/reason if known moderator_rescue flag consent/purpose/retention/access no raw secret/chat/voice/identifier by default quality checks: missing/duplicate/order/clock
اگر Tutorial-complete event fire نشود، Failure میتواند instrumentation باشد؛ اگر دو بار fire شود، Completion rate تحریف میشود. Event taxonomy، schema، ordering، drop/duplicate و Build mapping را خودتان تست کنید. Telemetry بیشتر همیشه بهتر نیست؛ Purpose و minimization و امکان انصراف مهماند.
«Fun Factor» را به یک Score ذاتی تبدیل نکنید
Fun یک خاصیت واحد و مستقل از Player/Genre/Context نیست. بعضی بازیکنان Mastery، بعضی Exploration، Story، Expression، Social connection، Competition، Discovery یا Relaxation میخواهند. Frustration نیز همیشه Defect نیست و Difficulty همیشه Barrier نیست. Design intent، Target player و لحظه/Task را ثبت کنید و بهجای «Fun=۸/۱۰» الگوهای Evidence را تحلیل کنید.
| Claim تجربی | Evidence ممکن | Alternative explanation |
|---|---|---|
| Goal understood | correct paraphrase/path/action | prior genre knowledge |
| Control felt responsive | timing complaint + trace + retry | display/input latency |
| Challenge legible | failure reason understood | lucky success |
| Choice meaningful | tradeoff articulated/path difference | novelty or obvious dominant option |
| Pacing dragged | observed idle/repetition + quote | fatigue/session order |
| Discovery worked | unprompted exploration/recall | streamer/external exposure |
| Social loop supported | coordination/communication pattern | pre-existing friendship |
Rating میتواند یک Self-report مفید باشد، اما Scale anchor، سؤال، زمان پرسش، ترتیب، Support و Distribution لازم است. میانگین روی مقیاس ordinal را با احتیاط تفسیر کنید و از آن برای ادعای ترشح Dopamine، روانشناسی همگانی، Retention یا فروش استفاده نکنید. Participant quote نیز شاهد تجربهٔ همان فرد است، نه حقیقت Population.
آزمایش قطعی: میانگین خوب، Tutorial شکستخورده
یک Fixture مستقل Node.js ۲۴.۱۸.۰ با هشت Session کاملاً ساختگی ساختیم: شش Returning و دو First-time. سؤال از پیش مشخص بود: «آیا Player تازهوارد، Task آموزشی اعلامشده را بدون نجات Moderator تمام میکند؟» Cohort، event، Rating و Gateها پیش از تنها Aggregation قفل شدند.
ALL FICTIONAL SESSIONS overall support=8 overall tutorial completion=0.75 mean arbitrary rating=7.25 first-time slice support=2 tutorial completion=0.00 mean arbitrary rating=6.50 failed sessions=S07,S08 NAIVE AGGREGATE GATE: overall completion≥0.75 AND mean rating≥7 → PASS TASK/SLICE GATE: overall completion≥0.70 AND first-time completion≥0.80 → HOLD
Aggregate مطلوب، Failure کامل Slice ازپیشتعریفشده را پنهان کرد. اما این Fixture بسیار کوچک، عمدی و غیرنماینده است؛ Ratingها فقط Labelهای ordinal ساختگیاند و Scale معتبر Fun، Satisfaction یا Psychometric نیستند. هیچ انسان، Gameplay، Build، Telemetry، Observation، Interview یا نتیجهٔ تجاری سنجیده نشده است. Accessibility، Difficulty، Retention، Learning، Immersion، Balance، Performance، Defect یا Harm پوشش ندارد. این Benchmark، قانون حجم نمونه، Threshold عمومی، پیشبینی بازار، Release algorithm یا اثبات اینکه Task completion برابر Fun است نیست.
تحلیل Playtest؛ Aggregation با Context
| Measurement | باید همراه باشد با | هشدار |
|---|---|---|
| Task success | support/start/end/rescue/withdrawal | success با کمک جدا |
| Time on task | completion status/distribution | سریعتر همیشه بهتر نیست |
| Error/retry | taxonomy/severity/recovery | exploration را error ننامید |
| Path | goal/context/map state | dominant path لزوماً مطلوب نیست |
| Rating | question/anchor/distribution/support | ordinal/response bias |
| Quote | participant/task/time/observation | cherry-picking |
| Drop/quit | reason/technical/safety/consent | همه را churn ننامید |
Sliceها را قبل از Analysis بر اساس سؤال تعریف کنید: first-time/returning، input type، platform، accessibility need، language، genre familiarity یا exposure. Slice کوچک را با درصد قطعی گزارش نکنید؛ Count، Support و `INCONCLUSIVE` لازماند. اگر پس از دیدن داده Slice تازه کشف شد، آن را Hypothesis برای مطالعهٔ بعد بنامید.
Playtest Finding با Bug Report فرق دارد
playtest_finding: finding_id / question_id / build / sessions observation: what happened, not inferred motive evidence: timestamps/video/events/state/quotes support/slices/counterexamples interpretation + alternative explanations affected design claim/player/task severity: barrier/harm/goal impact confidence: bounded by method/sample recommendation: option/hypothesis, not command owner/decision/status validation plan for changed build privacy-safe attachments/retention
| Record | نمونه | Workflow |
|---|---|---|
| Technical defect | save corrupts after interrupt | reproduce/fix/retest |
| Accessibility barrier | critical audio cue no alternative | barrier/owner/player validation |
| Usability problem | goal misunderstood in task | design change/study |
| Balance observation | one option dominates fixture | telemetry/simulation/playtest |
| Preference | Participant likes art style B | context، نه defect |
| Design hypothesis | prompt order may cause miss | next experiment |
| Safety/abuse incident | harassment/photosensitivity event | immediate safety process |
Triage و تصمیم طراحی
- Observation را از Interpretation و Recommendation جدا کنید.
- Build و Participant/Task context را پیش از Severity ببینید.
- Counterexample و evidence خلاف فرضیه را نگه دارید.
- Design intent را سپر ردکردن تجربهٔ Player نکنید.
- Preference فردی را به Bug یا «بازیکنان میخواهند» تبدیل نکنید.
- تغییر Design را نسخهدار و روی Build جدید دوباره بررسی کنید.
- اگر چند تغییر همزمان شد، Attribution را محدود گزارش کنید.
- Release decision را از Test/Research verdict جدا نگه دارید.
Beta و Field Playtest
Beta دامنهٔ Device/Network/Player context را گسترش میدهد، اما کنترل کمتر، self-selection بیشتر، Label مبهمتر و خطر Leak/harassment/privacy بالاتر دارد. Branch/Build، opt-in، eligibility، NDA، feedback channel، crash/telemetry consent، moderation، support، rollback و stop rule را تعریف کنید. تعداد ساعت بازیشده یا Concurrent player بهتنهایی Fun، Quality یا Market success نیست.
Release Gate بازی
| Gate | PASS | HOLD/Exception |
|---|---|---|
| Build identity | artifact/content/config/platform pinned | evidence on wrong build |
| Critical path/state | contracts/invariants/recovery pass | corruption/blocker/unknown |
| Platform matrix | risk cells and requirements evidenced | critical unsupported cell |
| Performance/stability | target workload/budget supported | hitch/crash/memory risk |
| Save/network/economy | duplicate/loss/conflict/recovery controlled | irreversible state/value risk |
| Accessibility | declared barriers addressed/evidenced | critical inaccessible path |
| Playtest claim | question-specific evidence supported | failure/insufficient support |
| Safety/privacy | consent/data/moderation controls ready | uncontained harm/data issue |
| Evidence | limits/unknowns/exceptions visible | green summary without trace |
Exception باید Build/Platform/Mode/Player impact، Workaround، owner، telemetry/support، expiry و retest داشته باشد. QA یا Research team Verdict شواهد را میدهد؛ Product/Design/Platform/Risk owner دربارهٔ Tradeoff تصمیم میگیرد. «Fun کم» یک Severity خودکار نیست و «بدون crash» نیز مجوز انتشار خودکار نیست.
Game Test Evidence Pack
game_test_evidence_pack: game quality charter + claims build/branch/commit/content/config manifests platform/device/input/locale/network matrix state/mechanic/save/network contracts automation/content/performance/crash evidence accessibility scope/guideline/player evidence playtest question/protocol/participants/tasks observation/telemetry/self-report with support technical defects + experiential findings privacy/consent/safety/moderation records limits/unknowns/exceptions/expiry test/research verdict + separate release decision
سناریوی ایرانی ساختگی: بازی موبایلی آفلاین
یک بازی Puzzle کاملاً فرضی با Build اندروید B42، زبان فارسی/RTL و حالت آفلاین طراحی کنید. هیچ Player، Account، فروشگاه، پرداخت، Advertisement یا Analytics واقعی وجود ندارد. Profileها و Sessionها ساختگیاند، Notification/Leaderboard/Cloud Save به Sink جعلی میروند و هیچ نام، موبایل، ایمیل، Advertising ID، Device ID، IP، Voice/Chat، تصویر یا Credential واقعی ثبت نمیشود.
| Claim | Fixture | Oracle |
|---|---|---|
| Install/update | local signed lab artifacts | version/data preserved |
| Offline first | network loss at boot/save/result | playable/reconcile no duplicate |
| Input | touch/RTL/back gesture | mapping/focus/no destructive surprise |
| Persian UI | font/half-space/digits/long text | readable/no clipping |
| Time | UTC state + Tehran/Jalali display | daily reward no clock abuse claim beyond lab |
| Economy | fictional coins only | grant/spend/retry invariant |
| Tutorial | synthetic session events | task/rescue/slice evidence |
| Access continuity | package/cache/mirror/offline docs | rebuild/restore checksums |
اگر بعداً IAP یا Ad وارد Scope شد، از Sandbox/محصول جعلی و مبلغ canonical IRR با نمایش صریح تومان استفاده کنید؛ هیچ کارت، PAN، CVV2، OTP، Token، Wallet یا پول واقعی وارد Playtest نشود. محدودیت Store/region/payment/sanction/connectivity باید جداگانه و با متخصص مربوط بررسی شود. این مثال مشاورهٔ حقوقی، مالی، فروشگاهی، ردهبندی سنی یا تحریم نیست.
نقشها و حق تصمیم
| نقش | مسئولیت | تصمیم |
|---|---|---|
| QA/Game tester | technical charter/execution/evidence/defects | test verdict |
| UX researcher | playtest protocol/recruitment/analysis | research finding confidence |
| Accessibility specialist/community | barrier guidance/lived-experience evidence | accessibility recommendation |
| Designer | mechanic/loop/balance intent/options | design change |
| Engineer/Tech art/content | implementation/instrumentation/fix | technical remediation |
| Platform/Release | artifact/requirement/branch/rollout | platform readiness |
| Safety/Privacy/Community | participant/data/chat/moderation | authorization/containment |
| Product owner | audience/scope/tradeoff | ship/hold/restrict |
متریکهای تصمیمساز و Countermetric
| Metric | تعریف لازم | Countermetric |
|---|---|---|
| Critical-path completion | build/state/platform/support/rescue | unknown/unattempted cells |
| Crash-free session | session population/duration/build | hang/data loss/telemetry gaps |
| Frame-time budget | workload/device/settings/distribution | visual quality/power/thermal |
| Save recovery | fault points/valid alternatives | silent progression loss later |
| Task success | participant/task/end/rescue/support | comprehension/frustration/access |
| Barrier count | scope/severity/player impact | coverage/community evidence |
| Finding follow-through | decision/change/retest | quality/severity of findings |
| Evidence freshness | current build/claim coverage | test debt/unknowns |
Bug count، ساعت بازی، Cases/day، Rating متوسط یا Finding count را برای رتبهبندی فردی تستر/Participant/Designer استفاده نکنید. این رفتار، Duplicate issue، ساعتپرکنی، feedback نمایشی و پنهانکردن Unknown را تشویق میکند. Metric باید Claim و تصمیم تیم را روشن کند.
برنامهٔ ۳۰روزهٔ Game Test Pilot
| بازه | کار | خروجی |
|---|---|---|
| روز ۱–۵ | Charter/critical path/build identity | scope + manifest |
| روز ۶–۱۰ | State/mechanic/save contracts | oracles + fixtures |
| روز ۱۱–۱۵ | Automation/content/platform/performance cells | technical evidence |
| روز ۱۶–۲۰ | Accessibility/localization/fault runs | barriers + recovery |
| روز ۲۱–۲۵ | یک Playtest question/protocol/session | observation/telemetry/self-report |
| روز ۲۶–۳۰ | Triage/change/retest/Evidence Pack | verdict + next risks |
ضدالگوهای رایج تست بازی
- تست بازی را بازیکردن بیهدف دانستن.
- نبود Build/Content/Config identity.
- Report بدون Save/State/Input/Network context.
- Editor run بهعنوان packaged/platform evidence.
- FPS متوسط بدون frame-time/workload.
- Replay ورودی بهعنوان Replay کامل state.
- Seed ثابت بهعنوان حذف همهٔ nondeterminism.
- Automation بهعنوان اثبات Fun.
- QA tester بهعنوان نمایندهٔ همهٔ بازیکنان.
- نقشبازیکردن تازهکار یا معلولیت.
- Playtest بدون سؤال تصمیمساز.
- Task با prompt راهحلگو.
- Moderator rescue پنهان.
- Telemetry بدون schema/consent/quality test.
- Rating میانگین بهعنوان Fun score.
- Quote cherry-picking.
- تبدیل Preference به Bug.
- Beta hours/CCU بهعنوان Quality proof.
- استفاده از بازی واقعی مشهور بهجای Evidence خود Build.
- وعدهٔ موفقیت تجاری یا ماندگاری با QA.
چکلیست انتشار بازی
- ☐ Player/Platform/Mode/Promise و known limits روشناند.
- ☐ Build/branch/commit/content/config هویت دارند.
- ☐ Device/Input/Display/Audio/Locale/Network matrix نسخهدار است.
- ☐ Profile/Entitlement/Save/Seed/Session بازتولیدپذیرند.
- ☐ Critical state/transition/mechanic invariants آزموده شدهاند.
- ☐ Map/asset/quest/localization content scan دارد.
- ☐ packaged build و lifecycle واقعی پوشش دارد.
- ☐ frame time/load/memory/crash با workload ثبت شدهاند.
- ☐ multiplayer authority/reconnect/reorder پوشش دارد.
- ☐ save atomicity/migration/cloud conflict آزموده شده است.
- ☐ accessibility claim و player evidence متناسب است.
- ☐ فارسی/RTL/font/subtitle/input glyph بررسی شده است.
- ☐ Playtest question و decision از پیش نوشته شدهاند.
- ☐ Participant criteria/consent/safety/accommodation روشن است.
- ☐ Task/start/end/timebox/rescue/moderator ثابتاند.
- ☐ Observation/Telemetry/Self-report جدا ثبت میشوند.
- ☐ Support/Slice/Unknown/Counterexample گزارش میشوند.
- ☐ Bug/Barrier/Hypothesis/Preference workflow جداست.
- ☐ Exception owner/workaround/monitor/expiry دارد.
- ☐ Test/Research verdict از Release decision جداست.
جمعبندی
تست بازی از binary و state تا بدن، دستگاه، شبکه و تجربه امتداد دارد. Technical evidence میگوید Mechanic طبق Contract کار کرده؛ Playtest evidence میگوید Participant مشخص در Task مشخص چه کرد و چه گفت. هیچکدام بهتنهایی Fun، Fairness، Market fit یا موفقیت را تضمین نمیکنند. ارزش حرفهای تیم در هویت دقیق Build، سؤال خوب، Oracle روشن، مشاهدهٔ صادقانه، Counterexample و تصمیم قابلردیابی است.
پرسشهای متداول تست بازی
۱. تفاوت Game QA و Playtest چیست؟
Game QA معمولاً Contract فنی، State، Content، Platform، Performance و Defect را بررسی میکند. Playtest یک سؤال طراحی/تجربه را با Participant، Task و Protocol مشخص مطالعه میکند. QA expert feedback و Target-player evidence میتوانند مکمل باشند، اما منبع و اعتبار تعمیمشان فرق دارد.
۲. آیا میتوان Fun Factor را با عدد اندازهگیری کرد؟
Rating میتواند Self-report محدودی باشد، اما Fun یک خاصیت واحد و جهانی نیست. سؤال، Scale anchor، Participant، Genre/Context، زمان، Distribution و Observation لازماند. یک میانگین بهتنهایی علت، Retention، فروش یا تجربهٔ همهٔ Playerها را ثابت نمیکند.
۳. چه بخشهایی از تست بازی را خودکار کنیم؟
Rule/Invariant، State transition، Asset/Map scan، Smoke path، Save fixture، Multi-client assertion، Performance capture و Screenshot comparison کاندیداهای خوبیاند. Control feel، comprehension، pacing، social dynamics و lived accessibility به Human evidence نیاز دارند.
۴. برای گزارش باگ بازی چه اطلاعاتی ضروری است؟
Build/branch/commit/content/config، Platform/hardware/input، Profile/Save/checkpoint، Mode/map/quest، Network، Seed/session/attempt، مراحل، Actual/Expected، ویدئو/Input/log/state/crash evidence و نرخ بازتولید. بدون State اولیه، ویدئو بهتنهایی کافی نیست.
۵. تیم کوچک تست بازی را از کجا شروع کند؟
یک Build و Critical path را قفل کند؛ State/Save/Mechanic contract بنویسد، چند Smoke/Content/Performance cell بسازد و فقط یک Playtest question با Task و Rescue rule روشن اجرا کند. Evidence محدود اما قابلبازتولید بهتر از ساعتها بازی بیCharter است.
