نقش QA در تست A/B؛ Assignment تا Decision

داشبورد می‌گوید Variant B نرخ تبدیل را ۱۲٪ بالا برده، p<0.05 است و هیچ Bug بازی نداریم. تیم آماده است دکمه «Ship» را بزند. اما ۱۷٪ Exposureهای B به‌علت خطای JavaScript ثبت نشده، بخشی از کاربران میان موبایل و وب هر دو Variant را دیده‌اند و Query نهایی فقط Sessionهای دارای Event موفق را شمرده است. اینجا نقش QA در تست A/B یافتن یک دکمه خراب نیست؛ جلوگیری از تبدیل یک اجرای معیوب به «برنده آماری» است.

پاسخ کوتاه: QA در Online Controlled Experiment باید زنجیره Hypothesis→Treatment→Eligibility→Assignment→Exposure→Telemetry→Metric pipeline→Guardrail→Evidence را قابل‌آزمون کند. QA می‌تواند بگوید Variant، تخصیص، Exposure و داده برای تحلیل آماده‌اند یا باید Hold شوند؛ اما اثر علّی، روش آماری، برنده تجاری و مجوز Ship را به‌تنهایی تضمین نمی‌کند.

مرز مقاله: این راهنما مالک Experiment QA Record و کیفیت اجرای آزمایش آنلاین است. آموزش جامع استنباط آماری، CRO، UX Research، Feature rollout یا بهبود فرایند QA نیست. Threshold، Sample size، Estimand، روش تحلیل و Decision باید با Analyst/Statistician و صاحب اختیار همان آزمایش بسته شوند.

تست A/B دقیقاً چیست؟

A/B Testing یا Online Controlled Experiment، واحدهای واجد شرایط را با سازوکار ازپیش‌تعریف‌شده به Control و Treatment تخصیص می‌دهد، تجربه متفاوت را ارائه می‌کند و Outcomeها را برای یک سؤال تصمیم مقایسه می‌کند. حرف A و B به‌تنهایی Randomization، کنترل سوگیری یا استنباط علّی نمی‌سازد؛ Design، اجرا، داده و Assumptionها باید سالم باشند.

آزمایش می‌تواند بیش از دو Variant داشته باشد؛ A/B نام رایج خانواده است. Control لزوماً «نسخه قدیمی» و Treatment لزوماً «بهتر» نیست. Variant فقط Artifact آزموده‌شده است و تا تحلیل معتبر و Decision مجاز، Winner نامیده نمی‌شود.

تست A/B با Feature Flag و Rollout فرق دارد

Feature Flag مکانیزم کنترل مسیر کد است؛ Ramp یا Canary ریسک انتشار را مرحله‌ای می‌کند؛ A/B Experiment برای برآورد تفاوت Outcome تحت Design کنترل‌شده ساخته می‌شود. یک Flag می‌تواند زیرساخت هر سه باشد، اما روشن‌کردن ۵۰٪ Flag بدون Unit ثابت، Assignment log، Control هم‌زمان و Analysis plan الزاماً آزمایش نیست. راهنمای Shift‑Right و Testing in Production مالک rollout/Canary/Shadow/rollback است.

نقش QA کجا شروع و تمام می‌شود؟

نقش	مالکیت اصلی	QA چه می‌کند؟	QA چه ادعایی نمی‌کند؟
Product/Experiment owner	Question، Hypothesis، Option و Decision	ابهام و testability را Challenge می‌کند	جایگزین Authority کسب‌وکار نیست
Analyst/Statistician	Estimand، Power، Method، Uncertainty	پیاده‌سازی و Evidence ورودی را تست می‌کند	روش آماری را خودسرانه تعیین نمی‌کند
Data owner	Metric contract و Pipeline	Event/Join/Loss/Dedup/Lineage را راستی‌آزمایی می‌کند	Data truth را تضمین نمی‌کند
Engineer/Platform	Allocator، Flag، Exposure و Runtime	سناریوهای Assignment/Variant/Failure را اجرا می‌کند	نبود Bug را معادل Validity نمی‌گیرد
QA	Experiment QA Record و Finding	Evidence readiness و Hold را ثبت می‌کند	Winner، causality یا Ship را اعلام نمی‌کند

واحد کار: Experiment QA Record

به‌جای چک‌لیست پراکنده، یک Record نسخه‌دار بسازید که Question و Variant را به Assignment، Exposure، Telemetry، Pipeline، Run و Verdict پیوند دهد. Record باید حتی وقتی نتیجه Hold یا Invalid است قابل انتشار داخلی باشد.

ExperimentQARecord {
  record_id, version, status, owner, validity, limitations,
  question_and_hypothesis, control_treatment_artifacts,
  population, assignment, exposure, interference,
  metric_contracts, telemetry_and_pipeline,
  design_and_analysis_handoff, preflight, ramp_and_run,
  quality_checks, guardrails, findings, layered_verdicts,
  evidence_digests, decision_ref, expiry, correction_history
}

Question و Hypothesis را قابل ابطال کنید

«رنگ سبز بهتر است» Hypothesis عملیاتی نیست. Treatment mechanism، Population، Outcome، جهت مورد انتظار، بازه و Trade-off را بنویسید: «برای کاربران واجد شرایط موبایل، ساده‌سازی مرحله آدرس انتظار می‌رود Completion تعریف‌شده را بالا ببرد، بدون عبور Crash/Latency/Cancel از Guardrailهای ازپیش‌تصویب‌شده.» این جمله هنوز نتیجه نیست؛ قرارداد سؤال است.

Decision Question را از Metric جدا کنید

Metric به‌تنهایی نمی‌گوید چه تصمیمی باید گرفت. Optionها می‌توانند Ship، No-ship، Continue، Ramp، Redesign یا Investigate باشند. Decision Question باید Authority، موعد، هزینه خطا، Guardrail trade-off و Unknown قابل‌قبول را مشخص کند. بالا رفتن Click ممکن است با افت Completion یا افزایش لغو همراه باشد.

Control و Treatment را به Artifact تبدیل کنید

ControlID و TreatmentID ثابت
Release/Build/Commit و Artifact digest
Change set دقیق، نه Screenshot تنها
Feature-flag name/version و Config digest
Dependency، CSS/JS bundle و backend version
Content، Copy، Price/Offer و Remote config snapshot

اگر Treatment وسط Run عوض شود، همان ExperimentID دیگر یک Treatment واحد ندارد. Change را متوقف، نسخه تازه بسازید یا با تحلیل‌گر یک Epoch صریح تعریف کنید؛ تغییر خاموش را در میانگین نهایی پنهان نکنید.

Population و Eligibility را قبل از Assignment ببندید

PopulationID، inclusion/exclusion، locale، platform، geography، consent state، account state، employee/bot policy و new/returning status را نسخه‌دار کنید. Eligibility پس از دیدن Outcome نباید تغییر کند. تفاوت «واجد شرایط»، «Assigned»، «Exposed» و «Analyzed» را حفظ کنید.

Randomization Unit را آگاهانه انتخاب کنید

User، Device، Session، Tenant، Store یا Cluster می‌توانند Unit باشند. انتخاب به Treatment mechanism و interference بستگی دارد. پژوهش Microsoft درباره Tenant-randomized experiment نشان می‌دهد تغییر Unit روی balance، variance و power اثر دارد؛ عدد یا روش آن را نسخه جهانی نکنید.

Assignment Unit و Analysis Unit یکی نیستند

ممکن است Tenant تخصیص یابد ولی Metric در سطح User یا Session محاسبه شود. این تفاوت روی dependence و variance اثر دارد و باید در Analysis plan دیده شود. QA تطابق شناسه و Aggregation را تست می‌کند؛ انتخاب estimator مناسب با Analyst/Statistician است.

Assignment Contract چیست؟

AssignmentContract {
  assignment_id, randomization_unit, allocator_version, seed,
  expected_ratio, bucket_ranges, eligibility_version,
  stable_assignment, cluster_or_strata, mutual_exclusion,
  assigned_at, assignment_event_version, fallback_policy
}

برای یک Unit ثابت و Experiment version ثابت، Assignment باید طبق قرارداد تکرارپذیر باشد. Login transition، cookie deletion، cross-device، fallback، cache و rollout تغییرکرده می‌توانند Unit را دوباره یا به Variant دیگر تخصیص دهند.

Exposure با Assignment فرق دارد

Assigned یعنی Allocator Variant را انتخاب کرده؛ Exposed یعنی Unit طبق تعریف، Treatment را واقعاً دریافت کرده یا فرصت دریافت داشته است. Flag evaluation، render، API behavior و action می‌توانند Exposureهای متفاوت باشند. تعریف Exposure را پس از دیدن نتیجه عوض نکنید.

ExposureContract {
  exposure_id, definition, event_name_and_version,
  assignment_link, subject_key, first_exposure_time,
  repeated_exposure_policy, control_received, treatment_received,
  crossover, noncompliance, missing_exposure, digest
}

Intent-to-Treat و Triggered Analysis را مخلوط نکنید

یک تحلیل ممکن است همه Assignedها و دیگری فقط Exposedها را هدف بگیرد. هر انتخاب Estimand و Assumptionهای متفاوت دارد. QA باید Assigned/Exposed/Analyzed counts و Exclusion logic را بازتولید کند؛ اینکه کدام تحلیل مناسب سؤال است تصمیم آماری/محصولی ثبت‌شده است.

Identity drift و Cross-device را تست کنید

Anonymous cookie ممکن است پس از Login به UserID وصل شود؛ یک کاربر با Web و App دو DeviceID دارد؛ Cookie churn Unit تازه می‌سازد. Merge/dedup/collision policy و delete/consent transition را تست کنید. Assignment key نباید از Label فارسی یا داده ناپایدار ساخته شود.

Crossover و Treatment Noncompliance

Unit ممکن است به B تخصیص یابد ولی A را ببیند، هر دو را ببیند یا هیچ‌کدام را. Cache، CDN، SSR/CSR، offline app، stale config و fallback علت‌های فنی‌اند. Count و علت را به تفکیک Arm ثبت کنید؛ حذف خودکار crossoverها می‌تواند Population تحلیل را تغییر دهد.

Interference و Contamination

کاربران همیشه مستقل نیستند. اعضای یک Tenant همکاری می‌کنند، Marketplace موجودی مشترک دارد، Recommendation model از رفتار هر دو Arm یاد می‌گیرد و یک User تجربه را برای دیگری Share می‌کند. پژوهش Google درباره A/B test در شبکه همکاری نشان می‌دهد انتخاب Randomization unit می‌تواند برای کاهش contamination حیاتی باشد؛ راه‌حل وابسته به شبکه و Design است.

Concurrent Experiment و Mutual Exclusion

دو Experiment روی یک Funnel، UI، Price، Cache یا backend ممکن است Interaction بسازند. Namespace، eligibility overlap، interaction policy و concurrent experiment snapshot را ثبت کنید. «هر آزمایش جدا Random است» تضمین نمی‌کند اثر ترکیب قابل چشم‌پوشی باشد.

Metric Contract را قبل از Run نسخه‌دار کنید

MetricID/version، تعریف کسب‌وکار، numerator، denominator، unit، aggregation، جهت، window، attribution، eligibility، missing policy و Owner لازم‌اند. Query بدون Contract می‌تواند با یک Filter تازه نتیجه را عوض کند. KPI Charter و حاکمیت معیار مالک طراحی Portfolio متریک سازمانی است.

Outcome، Diagnostic، Guardrail و Data Quality

خانواده	پرسش	نمونه ساختگی	خطر تفسیر
Primary outcome	اثر موردنظر چه بود؟	Eligible completion per assigned unit	Metric محلی جای Outcome می‌نشیند
Diagnostic	Treatment چگونه عمل کرد؟	step_view یا CTA click	Proxy به هدف نهایی تبدیل می‌شود
Guardrail	چه چیزی نباید بدتر شود؟	Crash، Latency، Cancel	Trade-off پنهان می‌ماند
Data quality	داده قابل تحلیل است؟	SRM، loss، join، duplicate	آلودگی به اثر محصول تعبیر می‌شود
Invariant	چه چیزی نباید بین Armها فرق کند؟	pre-treatment attribute	Assignment/Pipeline fault دیده نمی‌شود
Long-term	اثر پس از یادگیری/تکرار چیست؟	return behavior	Short-term lift تعمیم می‌یابد

الگوهای During-experiment مایکروسافت نیز Data-quality، OEC، local/diagnostic و Guardrail را جدا می‌کند. مثال‌ها و cadence آن تجربه همان سازمان‌اند؛ Threshold یا مدت ثابت جهانی نیستند.

Telemetry Event Contract

TelemetryEvent {
  event_name, event_version, producer_build, trigger_semantics,
  event_id, subject_key, assignment_id, exposure_id,
  event_time, ingestion_time, payload_schema,
  consent_gate, retry_and_duplicate_policy
}

«Event شلیک شد» کافی نیست. Trigger ممکن است قبل از render، بعد از click، فقط پس از پاسخ موفق یا دوبار در retry باشد. DevTools تنها Client send را نشان می‌دهد؛ ingestion، transformation، join و query نهایی هم باید Evidence داشته باشند.

Event parity بین Control و Treatment

نام، Version، Trigger، payload، timestamp، consent و subject link را در هر دو Arm مقایسه کنید. Treatment نباید صرفاً به‌علت DOM/route متفاوت Event دیگری بسازد، مگر اینکه Metric contract آن را آگاهانه مدل کند. Event parity به معنای Outcome equality نیست؛ کیفیت اندازه‌گیری را می‌سنجد.

Telemetry loss و delay

پژوهش Trustworthy Experimentation Under Telemetry Loss توضیح می‌دهد که از دست‌رفتن Telemetry می‌تواند bias و conclusion غلط بسازد و اندازه‌گیری loss مطلق ساده نیست. QA باید loss/delay را به تفکیک Arm، Platform، Event version و زمان بسنجد؛ صفر فرض نکند.

Pipeline و Query بخشی از Test Object هستند

Source→Ingestion→Transform→Join→Metric query→Snapshot را با Version/digest پیوند دهید. Cutoff، late data، backfill، dedup، timezone، bot filter، eligibility join و missing policy می‌توانند Armها را نامتقارن تغییر دهند. Dashboard تنها Presentation آخر زنجیره است.

Data Snapshot قابل بازتولید

AnalysisSnapshot {
  snapshot_id, cutoff, sources_and_versions,
  assignment_exposure_event_digests,
  transform_and_query_digest, eligibility_version,
  late_backfill_dedup_policy, included_excluded_counts,
  loss_join_duplicate_report, lineage, limitations
}

Sample Ratio Mismatch یا SRM چیست؟

SRM یعنی نسبت مشاهده‌شده Unitها میان Variantها با نسبت مورد انتظار ناسازگار است. مقاله اصلی Diagnosing Sample Ratio Mismatch آن را علامت طیفی از مسائل کیفیت داده می‌داند؛ شبیه علامتی که تشخیص علت می‌خواهد، نه یک Root cause واحد.

SRM را کجا محاسبه می‌کنیم؟

Assigned count، Exposed count و Metric-specific count مخرج‌های متفاوت‌اند. ممکن است Assignment ratio سالم باشد ولی Exposure یا Event یک Metric mismatch داشته باشد. Expected ratio، Unit، Window، Threshold/policy و Multiple checks را از پیش ثبت کنید. فرمول یا عدد جادویی این مقاله جای تحلیل آماری را نمی‌گیرد.

SRM یک Finding است، نه دکمه Repair

Eligibility یا bucket configuration اشتباه
Assignment key ناپایدار یا collision
Redirect/JS failure فقط در یک Arm
Exposure logging نامتقارن
Telemetry loss، delay، join یا dedup نامتقارن
Bot/employee/consent filter متفاوت
Ramp یا Stop در زمان نامتقارن
Interaction، cache یا unknown

حذف چند ردیف تا Ratio زیبا شود Repair نیست. Finding، diagnosis، containment، corrected data/code، rerun و acceptance مستقل لازم‌اند.

A/A Test چه چیزی می‌سنجد؟

در A/A، تجربه‌های ظاهراً یکسان زیر Assignment و measurement pipeline اجرا می‌شوند تا false-positive behavior، balance، variance assumptions یا instrumentation issues دیده شوند. A/A سالم تضمین نمی‌کند Treatment آینده سالم است؛ A/A Fail نیز ممکن است Design، Platform، data یا stochastic expectation را به بررسی بفرستد.

Preflight فنی هر Variant

Functional parity خارج از Change set
Browser/Device/Locale و responsive layout
Accessibility و keyboard/screen-reader path
Performance، crash و API error
SSR/CSR، cache و deep link
Login/logout، cross-device و consent states
Exposure/Event parity و raw→dashboard trace
Rollback و Kill switch در محیط مجاز

برای Matrix دقیق Browser/Engine/OS به راهنمای تست Cross Browser رجوع کنید. Pass Preflight «هر دو Variant بدون باگ» نیست؛ فقط سناریوهای مشخص و Gapها را ثبت می‌کند.

Flicker و FOOC را مشاهده‌پذیر کنید

Flash of original content می‌تواند تجربه، Exposure و Metric را عوض کند. ویدئو/trace، render timing، flag evaluation time و variant-applied event را ثبت کنید. پنهان‌کردن کل صفحه تا Script آماده شود ممکن است Flicker را کم ولی latency/blank screen را زیاد کند؛ Guardrail لازم است.

Performance parity و Treatment cost

Bundle size، request count، render milestones، API latency، crash و resource error را به تفکیک Arm/Platform ببینید. اگر B کندتر است، این ممکن است بخشی از Treatment effect واقعی باشد، نه nuisance قابل حذف. QA Observation را ثبت می‌کند؛ Product/Analyst تصمیم می‌گیرند اثر چگونه تفسیر شود.

Accessibility و ترجمه فارسی

Variant باید focus order، accessible name، contrast، zoom، screen reader، RTL/LTR، ی/ی، ک/ک، اعداد فارسی/عربی/لاتین، نیم‌فاصله و text expansion را پوشش دهد. خراب‌شدن Accessibility را با افزایش Click معامله نکنید مگر Decision authority و Guardrail policy صریح—و الزامات لازم—وجود داشته باشند.

داده واقعی، مصنوعی و Production

Preflight را با Fixture مصنوعی و Accountهای مجاز شروع کنید؛ اجرای Online Experiment روی افراد واقعی موضوع Purpose/Consent/Privacy/Security/Policy مستقل دارد. داده تست واقعی یا مصنوعی مرزهای Masking/Synthetic/Production را عمیق‌تر می‌کند. این مقاله مجوز آزمایش روی کاربر صادر نمی‌کند.

Ramp مرحله‌ای و Health Gate

Stage، traffic percent، زمان شروع، Approver، Health/Data/Guardrail gate، Stop و Rollback را در Ramp Record ثبت کنید. تغییر درصد می‌تواند expected ratio و Window را عوض کند. هر Ramp باید Assignment stability و Exposure را دوباره بررسی کند؛ «کم‌کردن Traffic» درمان خودکار bias نیست.

Guardrail breach و Emergency stop

Harm/Incident، crash، severe latency، privacy/security signal یا irreversible action نباید منتظر پایان Sample بماند. Threshold و authority توقف، Kill switch، containment و evidence retention را قبل از Run تعریف کنید. توقف اضطراری با Winner/Loser analysis یکی نیست.

Peeking و Early stopping

دیدن Dashboard برای سلامت سیستم با تصمیم زودهنگام بر اساس نتیجه یکی نیست. اگر Sequential design ندارید، توقف هنگام اولین سبزشدن می‌تواند خطای نتیجه را تغییر دهد. QA باید access/audit، cadence و stopping-rule adherence را ثبت کند؛ روش درست را Analyst تعیین می‌کند.

Multiple metrics و Segments

صدها Metric/Segment فرصت یافتن یک «برنده» تصادفی می‌سازند. Primary، secondary، guardrail، diagnostic، family و multiplicity policy باید پیش از نتیجه مشخص باشند. Segment discovery می‌تواند Hypothesis بعدی بسازد؛ به‌سادگی Confirmatory claim نامیده نشود.

Novelty، Seasonality و Long-term effect

اثر روز اول ممکن است از تازگی، یادگیری یا مقاومت باشد؛ روزهای هفته، رویداد تجاری و تغییرات بیرونی هم Window را شکل می‌دهند. پژوهش Google درباره تفاوت اثر کوتاه‌مدت و بلندمدت هشدار می‌دهد Short-term effect همیشه Long-term را پیش‌بینی نمی‌کند. Duration را از یک نسخه ثابت کپی نکنید.

Quality Gate پیش از Analysis

ANALYSIS_READY only if:
  artifacts and population are pinned
  assignment/exposure identity is reproducible
  SRM and invariant checks follow declared policy
  telemetry/pipeline loss, delay, join, duplicate are bounded
  crossover/interference/deviations are disclosed
  snapshots and exclusions are digest-linked
  guardrail incidents are resolved or explicitly carried
  analyst accepts the QA evidence and unknowns

این Gate نمی‌گوید Result معتبر یا Treatment مؤثر است؛ فقط می‌گوید بسته Evidence برای تحلیل تحویل شده است. Analyst می‌تواند به‌علت Assumption یا Design مسئله‌دار همچنان Hold کند.

Verdict چندلایه نگه دارید

VARIANT_FUNCTIONAL_PASS
ASSIGNMENT_HOLD
EXPOSURE_FAIL
TELEMETRY_INCONCLUSIVE
PIPELINE_INVALID
SRM_DIAGNOSIS_REQUIRED
GUARDRAIL_STOP
ANALYSIS_NOT_READY
EVIDENCE_STALE
DECISION_NOT_AUTHORIZED

میانگین‌گرفتن از این وضعیت‌ها و ساختن یک Score سبز خطرناک است. Variant functional pass نمی‌تواند Assignment fail را جبران کند. نبود Evidence نیز Pass نیست.

Finding را چگونه Triage کنیم؟

FindingID، Observation، Expected difference، Classification، Impact، Arm/Metric متاثر، Owner، Due date، Containment، Correction، Retest و Status لازم‌اند. دسته‌ها می‌توانند Variant defect، allocator defect، exposure ambiguity، instrumentation، pipeline/query، design assumption، analysis issue، environment یا Unknown باشند.

Evidence Pack آزمایش

Question/Hypothesis/Decision charter
Control/Treatment/Flag/Config artifacts و digest
Population/Eligibility/Assignment/Exposure contracts
Metric/Event/Pipeline/Query versions
A/A، Preflight، Browser/Device/Locale evidence
Ramp/Run/Incident/Deviation snapshots
SRM/invariant/loss/join/duplicate/guardrail reports
Raw-to-dashboard reproducibility و exclusions
Findings، retest، analysis handoff، Decision و Correction

تحلیل و Decision را از QA Sign-off جدا کنید

QA Sign-off باید Scope و Unknown داشته باشد: «Artifact/Assignment/Exposure/Telemetry/Pipeline شواهد مشخص را پاس کرده‌اند؛ Analysis method و causal conclusion خارج از Scope است.» Analyst effect interval و limitations را ارائه می‌کند؛ Decision authority Option/Condition/Expiry را ثبت می‌کند. `p<۰.۰۵` فرمان Ship نیست.

Winner را دوباره پیاده‌سازی و تست کنید

گاهی Variant در Experiment framework اجرا شده ولی پیاده‌سازی دائمی کد دیگری است. Artifact نهایی، flag cleanup، migration، rollout stages، regression، monitoring و rollback را دوباره Evidence کنید. «برنده» بودن Experiment version به معنای سلامت Implementation جدید نیست.

Visual QA داشبورد و گزارش

Axis، scale، denominator، uncertainty، missing/invalid state، color legend، RTL، export و accessible table را تست کنید. نمودار ممکن است Query درست را گمراه‌کننده نشان دهد. Chart Contract و Visual QA مالک طراحی/ممیزی نمودار است.

Google Optimize دیگر گزینه جاری نیست

مقاله قدیمی Google Optimize را ابزار جاری معرفی می‌کرد؛ اعلام رسمی Google می‌گوید Optimize و Optimize ۳۶۰ از ۳۰ سپتامبر ۲۰۲۳ در دسترس نیستند. ابزار را بر اساس Assignment/Exposure/Data export/SRM/Guardrail/Privacy/Access/Exit و دسترسی عملی ایران PoC کنید؛ فهرست Vendor ثابت جای Design سالم را نمی‌گیرد.

حریم خصوصی، رضایت و امنیت

ExperimentID، subject key، exposure و behavior داده‌اند. Purpose، minimization، consent/applicability، access، encryption، retention، deletion، export، vendor/region و incident route را با صاحبان صلاحیت ببندید. Consent filter ممکن است selection و Metric را هم تغییر دهد؛ Privacy و validity را نه ادغام کنید و نه یکی را قربانی دیگری.

آزمایشگاه آفلاین فارسی و کاملاً ساختگی

آزمایشگاه SYN-EXPERIMENT-QA-01 هیچ شبکه، Production، کاربر، شرکت، فروشگاه، Order، Payment، PSP، بانک، Account، پول، PII، cookie، token، credential یا Experiment واقعی ندارد. تمام IDها، Variantها، Eventها و درصدها Fixture هستند. IRR صرفاً Label ساختگی و تومان فقط Presentation علامت‌خورده است.

Question: does FAKE-B improve fictional completion?
Control=A-1.0; Treatment=B-1.0; expected assignment=50/50
Dashboard labels:
  split looks balanced
  events fire
  no open bugs
  p < 0.05
  conversion lift = 12% (fictional label only)

Injected defects:
  treatment exposure event missing after one fake JS path
  anonymous/login identity merges differ by arm
  duplicate retry events survive treatment dedup
  query filters sessions without successful event
  two concurrent fictional flags contaminate B
  guardrail and long-term metric are not defined

False Winner در آزمایشگاه

Checker سطحی پنج Badge را می‌بیند و می‌گوید VALID_WINNER_READY_TO_SHIP. اما split ظاهری، Event در DevTools، نبود Bug، p-value و uplift label هیچ‌کدام Loss نامتقارن، Unit drift، contamination، Metric denominator و authority را بررسی نمی‌کنند. Result باید پیش از هر تحلیل Hold شود.

Validator قطعی ۳۵۹ کنترل

Validator مستقل و dependency-free با Node.js، کنترل‌ها را در Record/Question/Authority/Treatment/Population/Assignment/Exposure/Identity/Interference/Metric/Portfolio/Telemetry/Pipeline/Quality/Design/Statistics/Preflight/Ramp/Execution/Observation/Diagnostic/Validity/Safety/Evidence/Verdict/Finding/Analysis-handoff/Decision/Rollout/Lifecycle/Boundary یکتا کرد. Assertion اجرای واقعی دقیقاً ۳۵۹ کنترل را شمرد؛ عدد دستی نیست.

CONTROL_COUNT=359
SUPERFICIAL=VALID_WINNER_READY_TO_SHIP
AUDIT=HOLD-359
INDEPENDENT_TARGET=real-user-experiment-or-organization:false:PASS
CORRECTED=READY_FOR_EXPERIMENT_QA_REVIEW-0
BOUNDARY=offline-fictional-fixture-only; no causal effect,
statistical validity, winner, revenue lift, ship authorization,
safety, privacy, security, long-term benefit, or real-world claim

پس از Pin کردن تمام فیلدهای ساختگی، خروجی فقط READY_FOR_EXPERIMENT_QA_REVIEW-0 است. Validator صحت داده، مفروضات آماری، effect یا Winner را اثبات نمی‌کند؛ completeness ساختاری Record را می‌سنجد.

سناریوهای فارسی آزمایشگاه

شناسه‌های ۷/۷/۷ و ی/ی و ک/ک برای Label در برابر stable key.
RTL/LTR و Bidi در Variant copy و Dashboard بدون تغییر raw value.
UTC event/ingestion و Asia/Tehran display؛ جلالی presentation-only.
7000 IRR canonical و «۷۰۰ تومان» صرفاً display برای Metric unit check.
Anonymous→Login merge و Web/App cross-device crossover.
Consent state متفاوت، late event، backfill، duplicate و out-of-order.
Timeout-after-fake-commit و retry برای Event exactly-once illusion.
Concurrent flag، shared fake inventory و contamination.

دروازه تصمیم پیشنهادی

اگر Treatment/Population/Assignment/Exposure Pin نیستند، Run نشود. اگر SRM یا invariant alert حل‌نشده است، Effect تفسیر نشود. اگر Pipeline reproducible نیست، Analysis invalid/hold بماند. اگر Guardrail breach فعال است، مسیر Incident/stop مستقل اجرا شود. اگر Analyst evidence را نپذیرفته، QA «winner» نگوید. Decision فقط با Option، Scope، Condition، Evidence، Unknown، Approver و Expiry ثبت شود.

۲۰ ضدالگوی رایج

Red flagها: Flag ۵۰/۵۰ مساوی Random experiment؛ Assigned مساوی Exposed؛ Event fired مساوی Data complete؛ Control بدون ArtifactID؛ تغییر Treatment وسط Run؛ User/Device/Session قابل‌تعویض؛ حذف crossover بعد از نتیجه؛ فیلتر فقط converterها؛ Dashboard مساوی source؛ SRM مساوی باگ allocator؛ Ratio خوب مساوی no bias؛ p<۰.۰۵ مساوی Winner؛ uplift مساوی Revenue؛ Click مساوی User value؛ Guardrail پس از دیدن نتیجه؛ Peeking و توقف روی سبز؛ Segment fishing؛ Short-term مساوی Long-term؛ QA مساوی Statistician/Decision authority؛ و پیاده‌سازی دائمی بدون Retest.

چک‌لیست مالک Experiment QA

Question/Hypothesis/Treatment mechanism/Decision قابل ابطال‌اند.
Control/Treatment/Flag/Build/Config digest ثابت‌اند.
Population/Eligibility/Consent/bot/employee policy نسخه دارند.
Randomization/Assignment/Analysis unit و ratio/seed معلوم‌اند.
Assignment و Exposure با Identity/crossover جدا هستند.
Concurrent experiment/interference/contamination ثبت است.
Outcome/Diagnostic/Guardrail/Data-quality/Invariant تفکیک شده‌اند.
Metric numerator/denominator/window/attribution/missing policy دارد.
Event trigger/schema/time/subject/assignment/exposure قابل‌ردیابی است.
Pipeline/query/cutoff/late/backfill/dedup/loss lineage دارد.
A/A و Preflight فنی/مرورگر/دسترس‌پذیری/Performance اجرا شده‌اند.
SRM در Assignment/Exposure/Metric level طبق Policy سنجیده شده است.
Ramp/Health/Data/Guardrail/stop/rollback authority روشن است.
Snapshot/Exclusion/Deviation/Unknown برای Analysis handoff آماده‌اند.
QA readiness، statistical conclusion و Decision جدا ثبت می‌شوند.

پایلوت ۳۰روزه بدون کاربر واقعی

هفته اول Question/Treatment/Population/Assignment/Exposure contracts ساختگی؛ هفته دوم Metric/Event/Pipeline و A/A fixture؛ هفته سوم loss/SRM/crossover/contamination/guardrail fault injection؛ هفته چهارم reproducible snapshot، layered verdict، analysis handoff، fake Decision و Correction. معیار موفقیت تعداد Winner نیست: Time-to-detect، raw-to-metric reproducibility، SRM diagnosis، exposure parity، unknown visibility و correction completeness را بسنجید.

جمع‌بندی

نقش تستر در A/B Testing نه «ضامن برنده» است و نه اپراتور یک Dashboard. QA زنجیره‌ای می‌سازد که نشان دهد چه Treatmentی به چه Populationی تخصیص و واقعاً ارائه شده، چه Event و Metricی چگونه ساخته شده و کدام Gap/Unknown هنوز مانع تحلیل است. بهترین خروجی گاهی Pass نیست؛ یک Hold زودهنگام است که از Ship بر پایه False Winner جلوگیری می‌کند.

پرسش‌های متداول

آیا QA می‌تواند برنده تست A/B را اعلام کند؟

QA می‌تواند آمادگی Artifact/Assignment/Exposure/Telemetry/Pipeline و Findings را اعلام کند. برآورد Effect و Winner به Analysis plan و Statistician/Analyst؛ Ship به Decision authority وابسته است.

SRM یعنی آزمایش حتماً باطل است؟

SRM علامت مسئله و محرک Hold/Diagnosis است. اثر آن به سطح mismatch، علت، Metric و Design بستگی دارد؛ بدون Root cause و بازبینی صاحب‌صلاحیت نتیجه را تفسیر نکنید.

فرق Assignment و Exposure چیست؟

Assignment انتخاب Variant برای Unit است؛ Exposure دریافت واقعی تجربه طبق تعریف نسخه‌دار. Cache، خطا، fallback یا crossover می‌تواند این دو را متفاوت کند.

آیا p<۰.۰۵ برای Ship کافی است؟

خیر. Design، data quality، Effect size/interval، multiplicity، Guardrails، عملی‌بودن، Risk و Authority تصمیم نیز لازم‌اند. p-value دستور تجاری نیست.

حداقل Experiment QA Record چه دارد؟

Question/Hypothesis، Artifactهای A/B، Population، Assignment/Exposure/Identity، Metrics/Events/Pipeline، Preflight/Ramp/Run، SRM/quality/guardrail، Evidence/Findings، analysis handoff، limitations، expiry و correction history.

مدیریت تست

نقش QA در تست A/B؛ از Assignment تا Decision