تست Cross-Browser؛ از ماتریس ریسک تا شواهد انتشار

«در Chrome من درست است» نه نتیجهٔ تست مرورگرهای مختلف است و نه مجوز انتشار. یک صفحه ممکن است در Chromium دسکتاپ سبز باشد اما در Safari روی iPhone، Firefox با فونت فارسی، Edge سازمانی، صفحه‌کلید، لمس، Storage محدود یا شبکهٔ ناپایدار شکست بخورد. از طرف دیگر، تست همهٔ مرورگرها، نسخه‌ها، سیستم‌عامل‌ها و دستگاه‌ها نیز ناممکن و پرهزینه است. راه حرفه‌ای، انتخاب یک ماتریس Cross-Browser مبتنی بر ریسک و تولید شواهدی است که دقیقاً بگوید چه چیزی، کجا، با کدام نسخه و تا چه حد بررسی شده است.

این راهنما برای تیم محصول، توسعه‌دهندهٔ Front-end و QA ایرانی نوشته شده است. به‌جای رتبه‌بندی «۵ ابزار رایگان»، از Audience و Journey شروع می‌کنیم، Browser/Engine/OS/Device را از هم جدا می‌کنیم، Oracle چندلایه می‌سازیم، سهم اجرای محلی و سرویس ابری را تعیین می‌کنیم و در پایان به یک Release Evidence محدود و قابل‌ردیابی می‌رسیم. قیمت، دسترس‌پذیری منطقه‌ای و شرایط سرویس‌های ابری متغیر است؛ بنابراین هیچ پلن «رایگان دائمی» یا دسترسی تضمین‌شده‌ای فرض نمی‌شود.

خلاصهٔ اجرایی: از ادعای مبهم تا تصمیم قابل‌دفاع

• ادعا را محدود کنید: «Checkout در ترکیب‌های Tier A قابل‌استفاده است»، نه «سایت در همهٔ مرورگرها یکسان است».
• Population را از دادهٔ خودتان بسازید: Analytics رضایت‌دار، Support، فروش، کشور، دستگاه و الزام قراردادی؛ نه سهم بازار جهانی به‌تنهایی.
• ماتریس را روی Journey اجرا کنید: ورود، جست‌وجو، سبد، پرداخت، بازگشت از درگاه و بازیابی؛ نه بازکردن Home Page.
• Oracle چندلایه داشته باشید: Outcome، State، Network، Visual، Accessibility و Evidence.
• Emulation را با Device یکی نگیرید: شبیه‌سازی برای بازخورد سریع است؛ ریسک‌های منتخب روی مرورگر و دستگاه واقعی نمونه‌برداری می‌شوند.
• نتیجه سه‌حالته باشد: PASS، FAIL یا INCONCLUSIVE؛ خطای Lab و نبود شواهد، Pass نیست.

Claim: Checkout critical journey is usable on Tier-A matrix
AsOf: 2026-08-14
PopulationSource: consented product telemetry + support + contract
Outcome: PASS | FAIL | INCONCLUSIVE
EvidenceExpiry: browser release / app change / 14 days
NotClaimed: every browser, pixel identity, SEO rank, zero defects

تست Cross-Browser دقیقاً چه چیزی را می‌سنجد؟

Cross-Browser Testing مجموعه‌ای از بررسی‌های سازگاری و قابلیت استفاده است تا بفهمیم یک Capability وب در Clientهای منتخب، Outcome مورد انتظار را تولید می‌کند یا نه. موضوع فقط CSS نیست. Parsing و Rendering، APIهای JavaScript، Eventها، Form control، Cookie و Storage، Media codec، Font، Keyboard، Touch، Permission، Download، Network و سیاست‌های مرورگر می‌توانند رفتار را تغییر دهند.

«یکسان بودن» Oracle مناسبی نیست. Anti-aliasing فونت، اندازهٔ کنترل‌های بومی، Date picker یا فاصلهٔ جزئی ممکن است متفاوت اما قابل‌قبول باشد. برعکس، صفحه می‌تواند از نظر Screenshot شبیه باشد ولی دکمهٔ پرداخت با صفحه‌کلید فعال نشود یا Callback وضعیت سفارش را اصلاح نکند. قرارداد باید Invariantهای ضروری و Variationهای مجاز را جدا کند.

Browser، Engine، OS و Device را یکی نگیرید

لایه	نمونه	ریسک مستقل	Evidence لازم
Browser product	Chrome، Edge، Firefox، Safari	Policy، UI، Extension، کانال انتشار	نام برند و نسخهٔ واقعی
Rendering engine	Blink/Chromium، Gecko، WebKit	CSS، DOM، API و Event	Engine/build و Counterexample
Operating system	Windows، macOS، Android، iOS	Font، Codec، Input، permission	OS/version/locale
Device	Desktop، گوشی، تبلت	CPU، RAM، GPU، Touch، viewport	Model یا Device class
Context	RTL، شبکه، account state	Locale، latency، cache، policy	Context manifest

Playwright می‌تواند Chromium، Firefox و WebKit را اجرا کند، اما مستندات رسمی تصریح می‌کند WebKit آن Safari برندشده نیست و بعضی قابلیت‌های وابسته به Platform، مانند Codec، میان OSها فرق دارند. پس «WebKit روی Linux سبز شد» سیگنالی ارزشمند است، نه اثبات Safari روی iPhone. در مقابل، Selenium WebDriver مرورگر را محلی یا Remote کنترل می‌کند و برای Browserهای مختلف Capability اختصاصی دارد. انتخاب ابزار باید از Matrix بیاید؛ ابزار Population را تعریف نمی‌کند.

چرا «همهٔ مرورگرها» Scope معتبر نیست؟

حاصل‌ضرب Browser × Version × OS × Device × Viewport × Locale × Network × State به‌سرعت به هزاران ترکیب می‌رسد و هر روز تغییر می‌کند. راهنمای MDN نیز پیشنهاد می‌کند مهم‌ترین Browserها و Deviceها برای Audience هدف انتخاب شوند، نه آنکه پوشش مطلق وعده داده شود. Scope خوب نام، دلیل ورود، Journey، عمق تست، Owner، تاریخ و Trigger بازبینی دارد.

MatrixCell
ClientId: ios-safari-current
Reason: 18% checkout sessions + contract
Journey: cart-to-confirmation
Depth: smoke + visual checkpoints + keyboard/touch
Owner: QA-platform
ReviewTrigger: major browser release or share delta > 2pp

Audience Evidence؛ نقطهٔ شروع برای تیم ایرانی

دادهٔ عمومی سهم مرورگر، فقط Prior است. تصمیم محلی را با Analytics دارای مبنای رضایت، لاگ فنی کمینه، تیکت پشتیبانی، نرخ تبدیل، مشتری سازمانی و قرارداد ترکیب کنید. Unknown و Blocked telemetry را حذف نکنید؛ همین گروه ممکن است ناشی از Privacy setting، Ad blocker یا شکست زودهنگام JavaScript باشد. دادهٔ کاربر باید حداقل‌سازی، تجمیع، Retention و دسترسی روشن داشته باشد و نباید Fingerprinting پنهان بسازد.

• بازه و Sample size را ثبت کنید؛ درصد بدون مخرج قابل‌داوری نیست.
• Session، User و Conversion را جدا کنید؛ تعداد Session برابر تعداد مشتری نیست.
• Desktop و Mobile و In-app browser را تفکیک کنید.
• OS/Browser ناشناخته، Bot و Monitoring را برچسب بزنید.
• فصل، Campaign، اختلال اینترنت و تغییر محصول را به‌عنوان Confounder ثبت کنید.
• الزام دسترس‌پذیری یا قرارداد می‌تواند ترکیبی کم‌سهم را به Tier A ببرد.

ماتریس Client Platform را چگونه بسازیم؟

هر ردیف ماتریس باید یک Client قابل‌بازتولید باشد، نه برچسب مبهم «Mobile». الگوی عمیق‌تر Client Platform Matrix برای تست وب و موبایل، Surface، Runtime، Device و Lifecycle را جدا می‌کند. در این مقاله همان منطق را برای Browser compatibility به سه Tier تبدیل می‌کنیم.

Tier	معیار ورود	عمق پیشنهادی	Cadence	ادعای مجاز
A	Journey حیاتی، سهم/ارزش/قرارداد بالا	Critical E2E + Accessibility + Visual checkpoints + selected real device	PR smoke و pre-release کامل	Capabilityهای مشخص روی Matrix مشخص
B	سهم معنادار یا ریسک متوسط	Smoke + representative journeys	روزانه/Release	Smoke محدود
C	Long tail، نسخهٔ قدیمی یا Unsupported	Graceful degradation، analytics و Support path	نمونه‌ای/پس از Signal	Best effort یا Unsupported صریح
Unknown	داده ناکافی	Probe و Observation	Time-boxed	هیچ ادعای Compatibility

Journey مهم‌تر از شمار صفحه‌هاست

بازشدن صفحهٔ اصلی، Risk مهم را پوشش نمی‌دهد. Journey را از Trigger تا Outcome و State transition بنویسید. برای فروشگاه ایرانی، انتخاب کالا، ورود شمارهٔ موبایل، کد یک‌بارمصرف Synthetic، اعمال کد تخفیف، انتخاب روش ارسال، ایجاد Attempt، Redirect به PSP Stub، Callback و نمایش وضعیت نهایی یک زنجیره است. هر Branch مانند Cancel، Timeout، Duplicate callback و Back button باید مرز مشخص داشته باشد.

Journey: synthetic-checkout
Start: anonymous cart with FA locale
CriticalActions: login → address → create-attempt → fake-redirect → callback
Invariant: one order, at-most-one ledger effect, recoverable status
VariationsAllowed: native controls, font rasterization, minor spacing
Forbidden: real PSP, real money, real identity, Production

Oracle چندلایه؛ Screenshot کافی نیست

• Business outcome: کاربر به نتیجهٔ درست رسیده و پیام بعدی را می‌فهمد.
• State oracle: Order، Attempt و UI state با هم سازگارند.
• Interaction oracle: Click، Touch، Keyboard، Focus و Back behavior درست است.
• Network oracle: Request، status، retry و duplicate semantics معتبر است.
• Visual oracle: بخش حیاتی clipped، overlapped یا پنهان نیست؛ Variation مجاز است.
• Accessibility oracle: Name/Role/Value، ترتیب Focus، Contrast و announcement قابل‌قبول است.
• Evidence oracle: Trace، Screenshot، Console و Manifest به Run و Commit وصل‌اند.

برای طراحی Locator، Actionability، Wait و Trace به راهنمای اتوماسیون تست UI مراجعه کنید. برای Baseline، تثبیت Screenshot و Diff triage نیز راهنمای تست بصری مکمل این Matrix است.

Functional compatibility؛ فقط Happy Path نیست

Compatibility check باید رفتار کاربر و State را بسنجد: Submit با Enter، جلوگیری از Double submit، History و Back/Forward، Refresh وسط Transaction، File upload/download، Clipboard با Permission، Autofill، session expiration، Cookie policy، popup، deep link و Recoverability. هر API مرورگر باید Fallback یا Unsupported behavior روشن داشته باشد.

CheckId: XB-FUNC-017
Given: fake attempt is pending
When: callback arrives twice after browser refresh
Then: UI converges to one confirmed state
Evidence: trace + redacted network + state snapshot
Verdict: PASS | FAIL | INCONCLUSIVE

Visual compatibility؛ برابری Pixel هدف نیست

Font rasterization، scrollbar، native input و Subpixel layout می‌تواند Diff بی‌خطر بسازد. Baseline باید به Browser/OS/viewport/font/locale/commit متصل باشد و Mask فقط برای ناحیهٔ واقعاً پویا استفاده شود. Threshold عمومی مانند «۱٪ اختلاف همیشه مجاز» معنا ندارد؛ ناحیهٔ CTA یا مبلغ می‌تواند با چند Pixel شکست بحرانی داشته باشد، درحالی‌که سایهٔ تزئینی کم‌ریسک است.

Accessibility و Input modality را داخل Matrix ببرید

یک Browser سبز با Mouse ممکن است با Keyboard، Touch، Zoom یا Screen reader نامعتبر باشد. Smoke منتخب باید Tab order، Focus visible، activation با Enter/Space، Escape، label/error association، announcement، zoom/reflow و reduced motion را بررسی کند. Automation بخشی از Signal است؛ داوری قابلیت استفاده و فناوری کمکی واقعی به Sample انسانی و محیط معتبر نیاز دارد.

CSS و Web API؛ از Baseline تا Fallback

پیش از افزودن Test، Support contract را روشن کنید. دادهٔ Browser Compatibility و مفهوم Baseline در MDN کمک می‌کند Availability یک Feature را بسنجید، اما جای تست Accessibility، Usability، Performance یا Security را نمی‌گیرد. Progressive enhancement، Feature detection و Fallback معمولاً از User-agent sniffing پایدارترند.

FeatureContract
Capability: share-order-link
Preferred: Web Share API when available and permitted
Fallback: copyable canonical URL
UnsupportedMessage: none; fallback remains usable
Oracle: user can transfer the link, not API-name equality

فارسی، RTL و واقعیت پرداخت ایران

Cross-browser lab ایرانی باید ترکیب متن راست‌به‌چپ و شناسهٔ چپ‌به‌راست، ZWNJ، ی/ی، ک/ک، ارقام فارسی/عربی/لاتین، Copy/Paste، فونت fallback، صفحه‌کلید موبایل، منطقهٔ زمانی Asia/Tehran و نمایش تاریخ جلالی را پوشش دهد. مبلغ Canonical را IRR نگه دارید؛ اگر تومان نمایش می‌دهید، واحد و تبدیل ۱:۱۰ را صریح کنید. این‌ها صرفاً Test data ساختگی‌اند و هیچ تراکنش واقعی ایجاد نمی‌کنند.

• مبلغ در DOM، Accessibility name، Clipboard و رسید با واحد یکسان بررسی شود.
• شماره سفارش LTR داخل جملهٔ RTL با Bidi isolation نمایش داده شود.
• Normalization جست‌وجو با دادهٔ اصلی اشتباه گرفته نشود.
• تاریخ ذخیره‌شده UTC، Zone محاسباتی و تقویم نمایشی جدا باشند.
• IME و صفحه‌کلید عددی روی Device منتخب نمونه‌برداری شوند.

Responsive testing با Cross-Browser یکی نیست

تغییر عرض viewport برای یافتن Breakpoint، فقط یک بعد است. Orientation، dynamic viewport، safe area، virtual keyboard، zoom، high DPR، scrollbar، touch target و content expansion نیز اهمیت دارند. به‌جای چند نام Device مشهور، Boundaryهای Layout را با عرض‌های اطراف Breakpoint و سپس چند Device class واقعی بررسی کنید.

Device Mode و Emulation چه چیزی را ثابت نمی‌کنند؟

مستندات رسمی Chrome، Device Mode را «تقریب مرتبهٔ اول» می‌داند: viewport، CPU/network throttling و sensorها شبیه‌سازی می‌شوند، اما کد واقعاً روی CPU و سخت‌افزار موبایل اجرا نمی‌شود. پس DevTools برای کشف سریع Layout و سناریوهای اولیه عالی است، ولی Memory pressure، GPU، WebView، keyboard، thermal behavior و تعامل واقعی را اثبات نمی‌کند.

EmulationEvidence: layout-smoke only
RealDeviceEvidence: selected Tier-A journey
DoNotInfer: battery, thermal, native Safari, hardware codec, every touch issue
EscalateWhen: device-only defect signal or high-value journey

مرورگر و دستگاه واقعی را کجا مصرف کنیم؟

هزینهٔ Device را روی ریسک‌های غیرقابل‌شبیه‌سازی خرج کنید: Safari/iOS برای Journey درآمدی، virtual keyboard و sticky CTA، camera/file picker، WebView، Download، Permission، poor-memory و Bugی که فقط روی Device گزارش شده است. Lab باید Reservation، reset، test account synthetic، privacy screen، update policy، charging و Evidence transfer داشته باشد.

Playwright؛ سه Engine، نه اثبات همهٔ Browserها

مستندات رسمی Browserهای Playwright اجرای Chromium، Firefox و WebKit و Channelهای Chrome/Edge را توضیح می‌دهد. Projectها برای Matrix سریع مناسب‌اند؛ با هر نسخهٔ Playwright، Browser binaryهای موردنیاز هم ممکن است تغییر کنند. Version ابزار، Browser build، OS image و Dependency باید در Run manifest Pin و در مسیر Update کنترل‌شده تازه شوند.

// illustrative manifest, not a universal copy-paste config
projects: [chromium, firefox, webkit]
browserBuilds: captured-at-run
locale: fa-IR
timezone: Asia/Tehran
testData: SYN-XBROWSER-IR-01
realSafariClaim: false

اگر میان Selenium و Cypress مردد هستید، مقایسهٔ Matched Trial ابزارهای UI را اجرا کنید. برای Lifecycle کامل Check، Flake، Evidence و Retirement نیز راهنمای چرخهٔ اتوماسیون تست مناسب است.

Selenium؛ Browser واقعی و Remote Grid با هزینهٔ عملیاتی

مستندات رسمی Selenium Capabilityها و تفاوت‌های Browserهای پشتیبانی‌شده را تفکیک می‌کند. WebDriver می‌تواند Browser را روی ماشین محلی یا Remote کنترل کند؛ اما Grid به‌خودی‌خود Test خوب، Version pin، isolation، wait، Oracle یا Evidence نمی‌سازد. هزینهٔ نگهداری Node، Driver، Queue، image، امنیت و Diagnosis باید داخل TCO باشد.

Cypress و ابزارهای دیگر؛ Capability را با برند جایگزین نکنید

هر Runner مدل اجرا، Browser support، Debugging، parallelism و محدودیت خاص دارد. تصمیم را با یک PoC همسان روی همان Journey، Fault، CI، Evidence و اعضای تیم بگیرید. راهنمای انتخاب Toolchain با Hard Gate و Exit کمک می‌کند «محبوب‌ترین» را با «مناسب Context ما» اشتباه نگیرید.

سرویس ابری؛ Access، Privacy و Exit قبل از Trial

Cloud grid می‌تواند Browser/OS/Device و Parallel capacity را سریع فراهم کند، اما Trial یا قیمت امروز، Contract فردا نیست. پیش از ساخت Account، Eligibility و شرایط کشور/سازمان، روش پرداخت قانونی، Data region، subprocessors، retention و حذف Artifact، tunnel، IP allowlist، SSO/MFA، concurrency، support، export API و Exit را بررسی کنید. برای ایران، دسترسی و Billing نباید با هویت یا آدرس جعلی، Account قرضی، دورزدن کنترل منطقه‌ای یا خاموش‌کردن TLS حل شود.

• قیمت و quota را با تاریخ، Currency، Tax و overage ثبت کنید.
• ویدئو، Screenshot، DOM، Network و Secretها را Data-classify کنید.
• Retention پیش‌فرض و حذف قابل‌اثبات Artifact را بیازمایید.
• Tunnel را least-privilege و به Hostهای Test محدود کنید.
• یک Export و یک Restore/Replay بدون Vendor اجرا کنید.
• Fallback ظرفیت محلی یا Vendor دوم و Trigger خروج تعریف کنید.

Local، Emulated، VM، Grid یا Cloud؟

گزینه	بهترین مصرف	محدودیت اصلی	کنترل ضروری
Local browser	Debug سریع و PR smoke	Population کم و drift لپ‌تاپ	Version manifest و clean profile
Engine/Device emulation	بازخورد سریع Layout/API	Browser/Device واقعی نیست	Claim محدود و real-device sample
VM/Container	OS image و CI تکرارپذیر	Hardware/Input/Fidelity محدود	Image digest و resource budget
Self-hosted Grid	کنترل و ظرفیت پایدار داخلی	عملیات، Patch، Queue و امنیت	SLO، isolation، observability
Cloud service	تنوع و Device capacity	هزینه، دسترسی، privacy، vendor drift	Eligibility، DPA، export، exit

Portfolio پوشش؛ هر Check روی همهٔ Cellها اجرا نمی‌شود

• Contract/unit: سریع و مستقل از Browser برای منطق و Transform.
• Component: State و rendering محدود روی Engine نماینده.
• Critical E2E: تعداد کم، Outcomeمحور، روی Tier A.
• Visual: checkpointهای پایدار، Browser-specific baseline.
• Accessibility: static automation + keyboard + نمونهٔ assistive technology.
• Exploratory: Charter روی تغییر جدید، Device و uncertainty.
• Real-user monitoring: Signal ناشناس/تجمیعی، نه جایگزین pre-release test.

برای زمان اجرای Suite، Critical path، Sharding و Flake tax از راهنمای بهینه‌سازی رگرسیون استفاده کنید. هدف، بیشترین تعداد Browser-run نیست؛ سریع‌ترین Evidence معتبر با کمترین ریسک جاافتاده است.

CI را به Laneهای تشخیصی تقسیم کنید

PR: Tier-A smoke, one representative viewport, fail-fast diagnosis
Nightly: full Tier-A + sampled Tier-B + visual
PreRelease: current matrix + selected real devices + accessibility
PostRelease: synthetic monitor + aggregated compatibility signals
Quarantine: isolated, owner, expiry, no silent green

Parallelism بدون Isolation، نتیجه را سریع‌تر اما کم‌اعتمادتر می‌کند. Test account، Order، Port، Cache و artifact path باید per-run namespace داشته باشند. برای محیط Runner بازتولیدپذیر، قرارداد محیط تست Docker مرز Digest، Readiness، Secret و Cleanup را توضیح می‌دهد.

Version policy؛ Current فقط یک کلمه نیست

برای هر Browser، Stable/Beta/Enterprise ESR/OS support را جدا کنید. «آخرین نسخه» باید در لحظهٔ Run به Version/build دقیق Resolve شود. پشتیبانی N-۱ زمانی معتبر است که داده یا قرارداد آن را توجیه کند. Unsupported client را با پیام، fallback و Support path مدیریت کنید؛ خاموش‌کردن بی‌سروصدای Capability بدترین گزینه است.

BrowserPolicy
Channel: stable
ResolvedVersion: captured by runner
SupportWindow: evidence-based, not universal N-2
UpdateCadence: weekly canary + controlled promotion
Rollback: previous image/browser bundle
Expiry: next major release or 14 days

Flaky در یک Browser؛ Retrying راه‌حل نیست

ابتدا Failure attribution کنید: Product defect، Test defect، Environment، Data، Browser/driver mismatch یا Lab outage. Retry فقط برای تخمین ناپایداری و جمع‌آوری Evidence محدود مفید است؛ سبزشدن اجرای دوم، شکست اول را پاک نمی‌کند. Quarantine باید Owner، دلیل، اثر Coverage، Workaround، expiry و خروج داشته باشد.

FailureRecord
RunId: syn-xb-042
Cell: firefox-linux-fa
FirstFailure: focus lost after validation
Retry: 2/5 reproduced
Attribution: UNKNOWN
Verdict: INCONCLUSIVE
NextProbe: headed trace + reduced parallelism

Evidence Pack برای هر Run

• Run ID، Commit/build، Branch و زمان UTC؛
• Browser product/engine/build، OS image، viewport/DPR و locale؛
• Journey/check version، Test-data ID و environment fingerprint؛
• نتیجهٔ PASS/FAIL/INCONCLUSIVE و reason code؛
• Trace، Screenshot، video یا Network redacted فقط به‌اندازهٔ لازم؛
• Known issue، quarantine، exception و Coverage gap؛
• Retention، access، hash/size و expiry؛
• Claim و Non-claim نهایی برای Release owner.

گزارش باگ Cross-Browser باید قابل‌بازتولید باشد

Observed: CTA is hidden after virtual keyboard opens
Expected: CTA remains reachable without losing entered data
Cell: iOS / Safari / exact versions captured
Context: fa-IR, RTL, 200% text, synthetic account
Repro: 4/5 clean-profile runs
Contrast: not reproduced on Android Chrome cell
Evidence: redacted trace/screen recording
Impact: checkout blocked; no real customer or payment data

نام Browser به‌تنهایی Root cause نیست. Contrast cell، clean profile، Cache/extension state، Console/Network و Minimal reproduction به تیم کمک می‌کند تفاوت Engine را از Product state جدا کند. Bug severity از Impact Journey می‌آید، نه از شهرت Browser.

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

آزمایشگاه SYN-XBROWSER-IR-01 از اینترنت، Production، حساب واقعی، PSP، پول و دادهٔ شخصی جداست. فروشگاه، کاربر، سفارش، Callback و Browser cell همگی Fixture هستند. سه Engine در CI فقط Signal اولیه می‌سازند و یک «Device card» متنی، Evidence دستگاه واقعی را شبیه‌سازی نمی‌کند؛ هدف، تمرین طراحی Matrix و داوری محدود است.

LabId: SYN-XBROWSER-IR-01
FakeOrder: FA-۰۰۴۲ / FA-0042
CanonicalAmount: 1250000 IRR
DisplayOnly: 125000 تومان (1:10 labelled)
TextEdges: می‌رود | مي‌رود | کد | كد | RTL/LTR/Bidi
Time: UTC storage | Asia/Tehran compute | Jalali presentation only
Faults: timeout-before/after-fake-commit, duplicate/late/reordered callback
Network: disabled; Production: false; RealPayment: false

Validator مستقل چه چیزی را کنترل می‌کند؟

یک Validator آفلاین و بدون Dependency ابتدا نشان می‌دهد چطور Checklist سطحی با دیدن «همهٔ مرورگرها، Pixel-perfect، پلن رایگان و SEO بهتر» به‌اشتباه آماده‌بودن را اعلام می‌کند. سپس ۸۱۲ کنترل Group-qualified را در Scope، Population، Client identity، Journey، Oracle، RTL، Emulation، Device، Tool، Cloud، CI، Evidence، Privacy و Claim بررسی می‌کند. Fixture ناقص باید Hold شود؛ پس از Pinشدن همهٔ فیلدهای ساختگی، فقط آمادگی برای Review اعلام می‌شود.

CROSS_BROWSER_ALL_BROWSERS_PIXEL_PERFECT_FREE_CLOUD_SEO_READY
HOLD-812
NO_REAL_USER_ACCOUNT_DEVICE_VENDOR_CREDENTIAL_PAYMENT_SITE_PRODUCTION_RELEASE_OR_SEO_DECISION_PASS
READY_FOR_CROSS_BROWSER_MATRIX_REVIEW-0

این خروجی اثبات نمی‌کند Matrix نمایندهٔ کاربران است، Browser/Device سالم است، Test درست نوشته شده، سایت Accessible یا امن است، قیمت/دسترسی Vendor پابرجاست، Release آماده است یا رتبهٔ سئو بهتر می‌شود. Validator فقط کامل‌بودن Fixture قراردادی خودش را می‌سنجد.

مرز ایمنی، محرمانگی و دسترسی

• URL، Header، Cookie، Token، DOM و ویدئو ممکن است Secret/PII داشته باشند؛ Redaction پیش از Upload لازم است.
• Accountهای تست synthetic، کم‌اختیار، قابل‌انقضا و جدا از Production باشند.
• Cloud tunnel فقط Host/Port لازم را ببیند و Log/Owner/expiry داشته باشد.
• از حساب مشترک، Credential قرضی، CAPTCHA bypass و TLS disable استفاده نشود.
• تست روی سایت شخص ثالث، دستگاه شخصی یا ترافیک واقعی بدون مجوز انجام نشود.
• حذف Artifact و revoke دسترسی در Offboarding آزموده شود.

Cross-Browser و SEO؛ رابطه را اغراق نکنید

شکست Layout یا Interaction می‌تواند رضایت، تبدیل، Mobile usability و دسترسی به محتوای اصلی را خراب کند؛ بنابراین رفع آن برای کاربر مهم است. اما Google نمی‌گوید عبور از تست همهٔ Browserها مستقیماً رتبه را بالا می‌برد. راهنمای رسمی Page Experience گوگل می‌گوید سیستم‌ها چندین Signal را می‌بینند، Core Web Vitals تضمین رتبهٔ بالا نیست و محتوای مرتبط همچنان مهم است. پس KPI مقاله «Outcome سالم برای Audience» است، نه وعدهٔ SEO.

۳۰ روز Pilot؛ بدون خرید عجولانه

1. هفتهٔ ۱: یک Journey حیاتی، Audience snapshot، چهار Cell و Non-claim را ثبت کنید.
2. هفتهٔ ۲: Smoke همسان را محلی روی Engineها اجرا و Failure taxonomy بسازید.
3. هفتهٔ ۳: یک Device/Browser gap را با دسترسی مجاز نمونه‌برداری و Evidence export/delete را تمرین کنید.
4. هفتهٔ ۴: Lead time، diagnosis time، flake، defect yield، coverage gap و TCO را مرور کنید.

PilotDecision: KEEP | ADAPT | EXPAND | STOP
Inputs: risk coverage, diagnostic value, access, privacy, TCO, exit
ForbiddenInference: cheapest/free = best; more browsers = more quality
Owner: named human reviewer
ReviewDate: explicit
ResidualRisk: accepted only by authorized product/release owner

چک‌لیست Owner پیش از Release

• Claim، Journey، Tier و Non-claim نسخه‌دارند؟
• Population source، بازه، مخرج، Unknown و Privacy ثبت شده‌اند؟
• Browser/Engine/OS/Device/locale دقیق‌اند؟
• Critical State و Branchها Oracle دارند؟
• Keyboard، Touch، RTL، Zoom و Visual checkpoint انتخاب شده‌اند؟
• Emulation و real-device Evidence جدا هستند؟
• Browser/tool/image build و Update trigger ثبت شده‌اند؟
• Test data و Accountها synthetic و کم‌اختیارند؟
• Trace/Video/Network redacted و Retentionدارند؟
• FAIL و INCONCLUSIVE از PASS جدا هستند؟
• Retry و Quarantine Owner/expiry دارند؟
• Coverage gap و Unsupported path برای Support روشن است؟
• Cloud eligibility، billing، privacy، export و exit دوباره بررسی شده‌اند؟
• Old evidence پس از تغییر Browser/App منقضی می‌شود؟
• Release owner ریسک باقی‌مانده را با اختیار واقعی دیده است؟

Anti-patternهای رایج

• Chrome سبز است، پس همه‌جا سبز است؛
• WebKit برابر Safari و emulation برابر iPhone است؛
• Pixel-perfect بودن تنها Oracle است؛
• لیست Browser از حدس یا سهم جهانی می‌آید؛
• همهٔ Checkها روی همهٔ Cellها اجرا می‌شوند؛
• هر Failure با Retry سبز می‌شود؛
• نسخهٔ Browser و OS در گزارش نیست؛
• ویدئو و Network خام به Vendor آپلود می‌شود؛
• Trial رایگان، رایگان دائمی فرض می‌شود؛
• دسترسی منطقه‌ای با هویت جعلی حل می‌شود؛
• تعداد Browser به‌عنوان Coverage یا Quality گزارش می‌شود؛
• Compatibility pass به SEO rank یا Release بدون ریسک ترجمه می‌شود.

منابع رسمی و تاریخ اعتبار

این راهنما در ۲۳ مرداد ۱۴۰۵ / ۲۰۲۶-۰۸-۱۴ با منابع رسمی بازبینی شده است: راهبرد تست Browser و Device در MDN، مستندات Browserهای Playwright، Browserهای Selenium، محدودیت‌های Device Mode در Chrome DevTools، Baseline در MDN و Page Experience گوگل. نسخهٔ ابزار، Browser support، قیمت، Trial، Eligibility و Data policy سرویس‌ها پس از این تاریخ ممکن است تغییر کند و باید در زمان تصمیم دوباره کنترل شود.

سوالات متداول تست مرورگرهای مختلف

آیا Playwright روی WebKit جای تست Safari واقعی را می‌گیرد؟

خیر. WebKit سریعاً اختلاف‌های Engine را آشکار می‌کند، اما Safari برندشده، OS، Codec، Device، WebView و Input واقعی را بازنمایی کامل نمی‌کند. برای Journeyهای پرریسک، WebKit CI را با Sample هدفمند Safari/Device واقعی ترکیب کنید و دامنهٔ هر Evidence را بنویسید.

برای تست Safari روی Windows چه راه امنی داریم؟

WebKit محلی برای Signal اولیه، سپس Mac/iPhone سازمانی مجاز یا سرویس Remote واجد شرایط برای Evidence نزدیک‌تر. Safari قدیمی Windows، Browser فعلی Safari نیست. پیش از Cloud، Eligibility، حریم خصوصی، پرداخت، Tunnel و Export/Delete را کنترل کنید.

چند مرورگر و دستگاه برای شروع کافی است؟

عدد جهانی وجود ندارد. با یک Journey حیاتی و سه Engine نماینده شروع کنید، سپس Browser/OS/Deviceهای Tier A را از دادهٔ Audience، ارزش کسب‌وکار، Accessibility، Support و قرارداد اضافه کنید. Unknown را Probe کنید و Matrix را با Trigger نسخه/سهم/باگ بازبینی کنید.

آیا DevTools Responsive Mode برای تست موبایل کافی است؟

برای Layout و بازخورد سریع مفید است، اما سخت‌افزار، CPU معماری موبایل، memory pressure، صفحه‌کلید، لمس و Safari/WebView واقعی را اثبات نمی‌کند. Scope آن را «Emulation smoke» بنویسید و ریسک‌های Tier A را روی Device منتخب نمونه‌برداری کنید.

آیا Cross-Browser Testing رتبهٔ سئو را بالا می‌برد؟

تضمینی و مستقیم نیست. سازگاری می‌تواند تجربه، دسترسی به محتوا و تبدیل را بهتر کند؛ اما گوگل از چندین Signal استفاده می‌کند و حتی Core Web Vitals خوب نیز رتبهٔ بالا را تضمین نمی‌کند. موفقیت را با Outcome کاربر، خطای Journey و Conversion segment بسنجید، نه وعدهٔ رتبه.

جمع‌بندی؛ ماتریس کوچک اما صادقانه

تست مرورگرهای مختلف مسابقهٔ جمع‌آوری Logo و Device نیست. یک ماتریس خوب از Audience و ریسک شروع می‌شود، Journey و Oracle دارد، Engine را از Browser و Device جدا می‌کند، Emulation را محدود می‌فهمد، Failure را تشخیص‌پذیر می‌سازد و Evidence منقضی‌شونده تحویل می‌دهد. با یک Journey حیاتی و چهار Cell آغاز کنید؛ هر Cell تازه باید ریسک تازه‌ای را پوشش دهد، نه فقط عدد گزارش را بزرگ‌تر کند.