تست Cross Browser؛ Playwright و رفع ناسازگاری وب

صفحه پرداخت در Chrome دسکتاپ سبز است، اما کاربر Safari روی iPhone بعد از انتخاب بانک به صفحه سفید می‌رسد؛ در Firefox نیز جمع مبلغ با فونت جایگزین دو خط شده و دکمه پایین صفحه را هل می‌دهد. این‌ها یک «باگ مرورگر» واحد نیستند. ممکن است Feature پشتیبانی‌نشده، HTML نامعتبر، تفاوت Engine، Codec، Font، Permission، Viewport یا Timing باشد. تست Cross Browser باید این تفاوت را به شواهد و Fix پایدار تبدیل کند.

تست Cross Browser بررسی می‌کند Journeyهای توافق‌شدهٔ یک وب‌سایت در ترکیب‌های پشتیبانی‌شدهٔ Browser، Engine، نسخه، OS، Device و ورودی، کارکرد قابل‌قبول دارند. هدف «Pixel کاملاً یکسان در همه‌جا» یا «تست تمام مرورگرهای جهان» نیست؛ هدف اجرای یک Support contract قابل‌اندازه‌گیری و داشتن Fallback سالم برای قابلیت‌های محدود است.

تست Cross Browser چیست؟

Cross-browser testing شاخه‌ای متمرکز از Compatibility testing برای محصول وب است. Test object می‌تواند صفحه، Web app، PWA، Embedded WebView یا Journey متصل به Browser API باشد. Coverage item فقط نام Browser نیست؛ قابلیت و رفتار موردانتظار در Environment مشخص است.

برای طراحی Tierهای Supported/Best-effort/Unsupported، ابعاد Browser، OS، Device، WebView و Assistive Technology و سیاست حذف نسخه‌ها، ابتدا راهنمای استراتژی سازگاری و Browser/Device Matrix را ببینید. مقاله حاضر عمداً اجرای فنی و Debug وب را مالک است تا با آن صفحه هم‌پوشانی نکند.

تجربه سازگار، نه لزوماً یکسان

فونت، کنترل Date، Scrollbar، Focus ring یا Anti-aliasing می‌تواند میان Platformها فرق کند و همچنان قابل‌قبول باشد. قرارداد باید Invariantهای کاربر را مشخص کند:

• محتوا و Action حیاتی قابل‌دسترسی باشد؛
• معنا، ترتیب و State از بین نرود؛
• Journey بدون بن‌بست کامل شود؛
• Fallback در نبود Feature پیام روشن و مسیر جایگزین بدهد؛
• تفاوت بصری از Design tolerance عبور نکند؛
• Keyboard، Touch، Zoom و Screen reader طبق Scope کار کنند.

Support contract سه‌سطحی

سطح	تعهد	نمونه	Gate
Supported	Journeyهای حیاتی با SLA رفع و Regression خودکار/دستی	Chrome/Firefox/Safari هدف روی OSهای تعریف‌شده	Failure حیاتی Block
Graceful/Best effort	کار اصلی و Fallback حفظ شود؛ Enhancement ممکن است غایب باشد	نسخه قدیمی‌تر یا WebView کم‌سهم	شکست Core block؛ تفاوت تزئینی triage
Unsupported	تعهد تست/رفع نداریم، اما ترجیحاً پیام و Upgrade path روشن است	Browser ناامن یا خارج از Policy	عدم ادعای پشتیبانی؛ Monitor جدا

Unsupported به معنای Crash عمدی یا صفحه سفید نیست. اگر تشخیص امن ممکن است، پیام قابل‌دسترس، حداقل محتوا و مسیر ارتقا ارائه کنید. Browser block فقط با دلیل امنیتی/فنی و Policy مصوب، نه برای ساده‌کردن Test matrix.

Browser، Engine، Channel و Device را جدا کنیم

بُعد	مثال	چرا مهم است؟
Browser product	Chrome، Edge، Firefox، Safari	UI، Policy، Extension، Codec و Integration
Engine	Blink/Chromium، Gecko، WebKit	Parsing، Layout، JavaScript و API implementation
Channel/version	Stable، Beta/Preview، Enterprise-pinned	Feature rollout و Regression آینده/قدیم
Operating system	Windows، macOS، Android، iOS، Linux	Font، Media، native control، permission، graphics
Device/WebView	Phone، Tablet، Embedded browser	Viewport، DPR، memory، keyboard، lifecycle
Input	Mouse، Touch، Keyboard، Stylus	Hover، pointer events، focus و gesture
User context	fa-IR، RTL، timezone، reduced motion	Formatting، bidi، layout و accessibility
Network/policy	Proxy، extension، enterprise policy، blocked CDN	Resource load و Browser capability

Playwright WebKit همان Safari نیست

Playwright از Buildهای مشخص Chromium، Firefox و WebKit استفاده می‌کند. مستندات رسمی Playwright Browsers می‌گوید WebKit آن از شاخه اصلی WebKit مشتق می‌شود و Safari برندشده را کنترل نمی‌کند؛ برای تجربه نزدیک‌تر Safari، WebKit روی macOS توصیه می‌شود. Firefox Playwright نیز به Patchهای پروژه وابسته است و Browser برندشده Firefox را مستقیماً استفاده نمی‌کند.

نتیجه عملی: سه Project پیش‌فرض Engine diversity خوبی می‌دهند، اما برای تعهد «Safari ۱۸ روی iPhone X» باید همان Product/OS/Device یا سرویس/لابراتوار معتبر را هم تست کنید. برای Chrome و Edge برندشده، Playwright Channelهای مربوط را می‌تواند اجرا کند.

ناسازگاری مرورگرها از کجا می‌آید؟

HTML parsing و DOM

تگ بسته‌نشده، Nesting نامعتبر، ID تکراری یا Markup وابسته به Error recovery ممکن است DOM متفاوت بسازد. Inspect کردن Source کافی نیست؛ DOM نهایی را مقایسه کنید. Validator خطاهای Syntax را می‌یابد، اما صحت Journey را تضمین نمی‌کند.

CSS layout و styling

• Default style کنترل‌های Form و Focus؛
• Flex/Grid intrinsic sizing و min-width:auto؛
• Subpixel rounding و Device pixel ratio؛
• Font metric، بارگیری دیرهنگام و Fallback؛
• Logical property، Writing mode و RTL؛
• Viewport unit، Sticky، Overflow و Scrollbar؛
• Feature جدید یا Prefix/Implementation ناقص.

JavaScript و Web APIs

• Syntax یا API جدید بدون Transpile/Polyfill/Fallback؛
• Short-circuit Feature detection اشتباه؛
• Event order، Pointer/Touch/Keyboard و Focus؛
• Storage، Cookie، Privacy restriction و third-party context؛
• Clipboard، File picker، Payment، Notification و Permission؛
• Intl، Date، Timezone و Locale formatting؛
• Module loading، CSP، Worker و Service Worker lifecycle.

Media و Platform integration

Codec، Autoplay، DRM، Hardware acceleration، Camera/microphone و Download behavior می‌تواند به OS و Browser binary وابسته باشد. حتی Chromium bundled و Chrome branded ممکن است Codecهای یکسانی نداشته باشند؛ Test environment باید دقیق ثبت شود.

Timing و Performance

یک Race condition ممکن است فقط در Engine کندتر، CPU ضعیف، Font دیررس یا Network محدود ظاهر شود. آن را «Firefox bug» ننامید تا زمانی که Root cause روشن شود. تفاوت زمان‌بندی اغلب نقص همگام‌سازی خود برنامه را آشکار می‌کند.

Browser Matrix را چگونه برای Cross-browser بسازیم؟

داده‌های لازم

• Analytics واقعی به تفکیک Browser/Version/OS/Device؛
• Conversion و Failure rate، نه فقط تعداد Session؛
• Ticket پشتیبانی و گزارش Cannot Reproduce؛
• قرارداد مشتری و Enterprise/browser pinning؛
• Journey حیاتی و Browser API مورد استفاده؛
• بازار/منطقه، دسترس‌پذیری و نیاز گروه‌های متأثر؛
• Engine diversity و Risk نسخه‌های تازه/قدیمی؛
• هزینه Device lab، Parallelism و زمان Feedback.

سوگیری Analytics

مرورگری که صفحه در آن زود Crash می‌کند شاید Session کامل نسازد؛ Consent blocker و Ad blocker نیز داده را کم می‌کند. کاربر محروم از Feature ممکن است قبلاً محصول را ترک کرده باشد. Analytics را با Support، Synthetic probes، Market context و قرارداد ترکیب کنید.

چرا آستانه ۱٪ یا ۵٪ قانون نیست؟

یک Browser با سهم ۰٫۵٪ می‌تواند مشتری سازمانی بزرگ، گروه آسیب‌پذیر یا Journey مالی پرارزش باشد. برعکس سهم زیاد Browser برای صفحه Marketing الزاماً Scope تست عمیق پنل داخلی نیست. Threshold را بر Exposure و Impact تعریف کنید و دوره بازبینی داشته باشید.

Matrix مبتنی بر Journey

Journey	Tier A	Tier B	Real-device checkpoint
ورود/OTP	سه Engine در هر PR	Browserهای برندشده Nightly	Keyboard/Autofill واقعی iOS/Android
سبد و پرداخت	سه Engine + دو Viewport	OS/Channel هدف پیش از Release	Safari iPhone و Chrome Android هدف
آپلود مدرک	Desktop engines	Permission/File type matrix	Camera/File picker واقعی
گزارش داخلی	Browser سازمانی اصلی	Fallback export	فقط اگر قرارداد می‌خواهد

Browser count به‌تنهایی Coverage نیست. Journey×Capability×Environment را Version کنید و Owner حذف/افزودن ترکیب را ثبت کنید.

پیشگیری از ناسازگاری با Web standards

Baseline و Compatibility data

MDN Baseline وضعیت دسترسی Featureهای Web را در Browserهای Core خلاصه می‌کند: Newly available، Widely available یا Limited availability. Baseline جای تست محصول، نسخه قدیمی، WebView، Assistive technology، Security یا Performance نیست؛ فقط ورودی انتخاب Feature است.

Feature Detection به‌جای User-Agent sniffing

User-Agent تغییر می‌کند، قابل‌جعل است و Product را با Capability یکی می‌گیرد. قابلیت موردنیاز را مستقیماً بررسی کنید و Failure زمان اجرا را هم مدیریت کنید:

function setupPayment() {
  const standardForm = document.querySelector("#standard-checkout");
  const expressButton = document.querySelector("#express-pay");

  standardForm.hidden = false;

  if ("PaymentRequest" in window) {
    expressButton.hidden = false;
    expressButton.addEventListener("click", startExpressPayment);
  } else {
    expressButton.hidden = true;
  }
}

وجود API لزوماً Permission، Merchant support یا موفقیت Call را تضمین نمی‌کند؛ مسیر Reject/Cancel/Unavailable را تست کنید. راهنمای رسمی MDN Feature Detection استفاده از بررسی JavaScript و @supports در CSS را توضیح می‌دهد.

Progressive Enhancement در CSS

.order-grid {
  display: flex;
  flex-wrap: wrap;
  gap: 1rem;
}

@supports (display: grid) {
  .order-grid {
    display: grid;
    grid-template-columns: repeat(auto-fit, minmax(16rem, 1fr));
  }
}

.order-card {
  min-inline-size: 0;
  overflow-wrap: anywhere;
}

لایه پایه Journey را کارا نگه می‌دارد و Enhancement در Browser پشتیبان فعال می‌شود. Fallback باید طراحی و تست شود؛ صرف وجود @supports تضمین نمی‌کند خروجی بصری مطلوب است.

HTML validation چه کمکی می‌کند؟

W3C Markup Validation Service Markup validity را بررسی می‌کند و Error recovery مبهم را کم می‌کند. خود W3C تأکید می‌کند Validation نه Full quality check است و نه معادل کامل Conformance. آن را Diagnostic سریع قرار دهید، نه Gate نهایی تجربه کاربر.

از Web Platform Tests چه یاد بگیریم؟

پروژه web-platform-tests (WPT) یک مجموعه Cross-browser برای خود Web platform است. اگر رفتار Feature میان Browserها متفاوت است، نتیجه WPT/spec/bug tracker کمک می‌کند بفهمید مشکل از پیاده‌سازی Browser، فرض برنامه یا Test شماست. WPT جای تست Business journey محصول نیست.

لایه‌های پوشش Cross-browser

۱. Markup، build و feature support

• HTML/CSS validation و Lint؛
• Target browser policy در Transpiler/Prefixer؛
• Compatibility check برای Featureهای جدید؛
• Bundle/module/nomodule و CSP؛
• Font، Icon و Asset fallback.

۲. Functional journey

ورود، جست‌وجو، سبد، پرداخت، دانلود و خطا را با Oracle کسب‌وکاری بسنجید. Test نباید فقط Visible بودن دکمه را ببیند؛ State، Request، URL، پیام و Side effect را کنترل کند. اگر Failure در API مستقل از Browser است، آن را در لایه تست API پوشش دهید و Cross-browser را روی Integration مرورگر متمرکز کنید.

۳. Responsive و visual

Breakpoint، Reflow، Zoom، Font loading، Overflow، Sticky و Modal را بررسی کنید. «اسکرین‌شات شبیه» معادل رفتار درست نیست. Baseline، Mask و Diff governance در راهنمای تست رگرسیون بصری آمده است.

۴. Interaction و input

• Keyboard-only و ترتیب Focus؛
• Pointer، Touch، Hover و Gesture جایگزین؛
• IME و Keyboard فارسی؛
• Autofill، Password manager و OTP؛
• Selection، Copy/paste و Drag/drop؛
• Back/forward، Refresh و Multiple tab.

۵. Accessibility در Browser/AT pair

DOM/Accessibility tree، Name/Role/State، Focus و Live region می‌تواند در Browser و Assistive Technologyهای مختلف تفاوت داشته باشد. تست خودکار سه Engine جای NVDA/Firefox، NVDA/Chrome، VoiceOver/Safari یا Matrix مصوب شما را نمی‌گیرد. روش کامل در راهنمای تست دسترس‌پذیری WCAG ۲.۲ است.

۶. Locale، RTL و داده فارسی

• dir="rtl" و Logical CSS property؛
• فارسی/عربی/لاتین و Bidi در مبلغ، ایمیل و شناسه؛
• نیم‌فاصله، متن بلند و Font fallback؛
• رقم فارسی و لاتین در Input/Validation؛
• تاریخ، Timezone، Calendar و Intl؛
• خطای Backend که متن LTR داخل پیام RTL دارد.

۷. Browser APIs و Platform behavior

Storage/Cookie، Permission، Clipboard، File/Camera، Notification، Service Worker، PWA install، Media و Download را جداگانه Test کنید. Emulator ممکن است UI Permission یا Hardware path واقعی را بازتولید نکند.

پیاده‌سازی Cross-browser با Playwright

پیکربندی سه Engine و Context فارسی

import { defineConfig, devices } from "@playwright/test";

export default defineConfig({
  testDir: "./tests",
  fullyParallel: true,
  forbidOnly: Boolean(process.env.CI),
  retries: process.env.CI ? 1 : 0,
  reporter: [["html", { open: "never" }]],
  use: {
    baseURL: process.env.BASE_URL ?? "http://127.0.0.1:3000",
    locale: "fa-IR",
    timezoneId: "Asia/Tehran",
    trace: "retain-on-failure",
    screenshot: "only-on-failure",
    video: "retain-on-failure",
  },
  projects: [
    {
      name: "chromium-desktop-fa",
      use: { ...devices["Desktop Chrome"] },
    },
    {
      name: "firefox-desktop-fa",
      use: { ...devices["Desktop Firefox"] },
    },
    {
      name: "webkit-desktop-fa",
      use: { ...devices["Desktop Safari"] },
    },
  ],
});

Playwright version و Browser binary به هم وابسته‌اند؛ هنگام Update باید Browserها دوباره نصب شوند. Lockfile، نسخه Node، OS image و Browser cache را کنترل کنید. نام Desktop Safari در Device descriptor به معنای اجرای Safari برندشده نیست؛ Engine همان WebKit Playwright است.

تست Journey با Locator معنایی

import { test, expect } from "@playwright/test";

test("checkout keeps the rial total and reaches pending payment", async ({
  page,
}) => {
  await page.goto("/checkout?fixture=fa-ir");

  await expect(
    page.getByRole("heading", { name: "تکمیل خرید" })
  ).toBeVisible();

  await expect(
    page.getByTestId("payable-total")
  ).toHaveAttribute("data-amount-rial", "1250000");

  await page.getByLabel("کد پستی").fill("۱۴۶۷۸۱۳۵۴۱");
  await page.getByRole("button", { name: "پرداخت" }).click();

  await expect(page).toHaveURL(/\/payment\/pending/);
  await expect(page.getByRole("status")).toContainText("در انتظار پرداخت");
});

Oracle مبلغ از Attribute machine-readable می‌آید و متن محلی‌سازی‌شده هم بررسی می‌شود. در محصول واقعی، این Fixture و Attribute باید قرارداد تست امن و غیراقتصادی باشند؛ Secret یا تراکنش واقعی نسازید.

تست Fallback قابلیت

test("standard checkout remains available without PaymentRequest", async ({
  page,
}) => {
  await page.addInitScript(() => {
    Object.defineProperty(window, "PaymentRequest", {
      configurable: true,
      value: undefined,
    });
  });

  await page.goto("/checkout");

  await expect(page.locator("#standard-checkout")).toBeVisible();
  await expect(page.locator("#express-pay")).toBeHidden();
});

Mock کردن Global برای تست واحد/Browser-level Fallback مفید است، اما رفتار واقعی Payment API و Permission را ثابت نمی‌کند. یک Lane محیطی جدا برای Browser/OS واقعی لازم است.

Project-specific expectations را محدود نگه دارید

از if (browserName === "webkit") برای پنهان‌کردن Failure استفاده نکنید. تفاوت مشروع باید به Support contract یا Platform behavior مستند وصل شود. Test جدا با نام روشن بهتر از شاخه‌های فراوان داخل یک Test است.

Emulation، Browser واقعی و دستگاه واقعی

سطح	چه می‌سنجد؟	چه چیزی را کامل نمی‌سنجد؟
Responsive mode	Viewport، DPR تقریبی، orientation، touch flag	CPU/GPU، OS، keyboard، واقعی‌بودن Browser
Desktop engine emulation	DOM/layout/JS در Engine کنترل‌شده	Mobile OS integration و سخت‌افزار
Simulator/Emulator	OS/Browser نزدیک‌تر و Debug سریع	همه Sensor، GPU، thermal، network و vendor behavior
Real desktop browser	Product/channel/OS واقعی	Device-specific mobile path
Real mobile device	Touch، keyboard، permission، viewport، hardware	همه Deviceهای بازار؛ نیازمند نمونه‌برداری

مستندات Chrome DevTools Device Mode آن را تقریب مرتبهٔ اول می‌خواند و صریح می‌گوید کد روی دستگاه موبایل واقعی اجرا نمی‌شود. بنابراین Responsive check محلی را Real-device test معرفی نکنید.

چه چیزهایی Real device می‌خواهند؟

• Virtual keyboard، Autofill و OTP؛
• Camera/File picker/Share؛
• Touch gesture، Scroll و viewport پویا؛
• Media codec، Autoplay و Hardware acceleration؛
• Permission و App/PWA lifecycle؛
• Memory/CPU محدود و Network handoff؛
• Safari/iOS یا Chrome/Android که در قرارداد نام برده شده است.

گردش‌کار Debug ناسازگاری مرورگر

۱. Environment را دقیق بازتولید کنید

Browser product، Engine/build، Version/channel، OS، Device، Viewport، DPR، Locale، Timezone، input، network، extension/policy و Commit را ثبت کنید. «روی Safari خراب است» گزارش قابل‌بازتولید نیست.

۲. Failure را طبقه‌بندی کنید

• Parsing/DOM؛
• Layout/visual/font؛
• Interaction/focus/input؛
• API/permission/storage؛
• Network/CSP/resource؛
• Timing/race/performance؛
• Environment/test-data/automation.

۳. Evidence یکسان از دو Environment بگیرید

Screenshot، DOM/Computed style، Console، Network waterfall/headers، Storage، Accessibility tree، Trace و Video را جمع کنید. داده حساس، Token و اطلاعات پرداخت را Redact کنید.

۴. اختلاف را کوچک کنید

Page را به Component یا Minimal reproduction کاهش دهید. CSS Ruleها، Featureها، Extension، Cache و Service worker را مرحله‌ای حذف کنید. اگر Failure با پاک‌کردن Cache ناپدید شد، هنوز Root cause حل نشده است.

۵. Support و Spec را بررسی کنید

MDN compatibility، Baseline، Specification، WPT result و Browser release notes را ببینید. اگر رفتار Browser خلاف Spec به نظر می‌رسد، Minimal repro و نسخه دقیق برای Bug tracker بسازید؛ Workaround باید Scope و تاریخ بازبینی داشته باشد.

۶. Fix استاندارد و Fallback بسازید

HTML معتبر، Feature detection، Logical CSS، Progressive enhancement، Polyfill معتبر یا Alternative journey را انتخاب کنید. Browser-specific hack بدون Comment/Issue/expiry بدهی پنهان می‌سازد.

۷. Regression test را در پایین‌ترین لایه مؤثر اضافه کنید

اگر مشکل Pure function است Unit test؛ اگر CSS component است Component/visual؛ اگر Browser API است E2E/real-device. هر Failure را به کندترین E2E سه‌مرورگری تبدیل نکنید.

۸. Re-run را با Fix اشتباه نگیرید

اگر Failure متناوب است، Frequency، Signature و Environment را حفظ کنید. گردش‌کار Hypothesis و Evidence در راهنمای بازتولید باگ متناوب کمک می‌کند Browser-specific flake با Product race اشتباه نشود.

نمونه خطاهای فارسی و RTL

Overflow مبلغ و متن بلند

.summary-row {
  display: flex;
  gap: 0.75rem;
  align-items: baseline;
}

.summary-row__label {
  min-inline-size: 0;
  overflow-wrap: anywhere;
}

.summary-row__amount {
  flex: none;
  direction: ltr;
  unicode-bidi: isolate;
  font-variant-numeric: tabular-nums;
}

استفاده از inline-size به‌جای left/right با Writing mode سازگارتر است. unicode-bidi:isolate را با Screen reader و Copy/paste واقعی بررسی کنید؛ CSS فقط یک Fix بصری نیست.

Font loading و Layout shift

اگر CDN فونت در یک شبکه/مرورگر Block شود، Fallback metric می‌تواند دکمه را جابه‌جا کند. Font stack، font-display، Preload و Error behavior را تست کنید. Snapshot فقط پس از آماده‌شدن Font لازم می‌تواند گرفته شود، اما Timeout بی‌نهایت برای Font خراب نسازید.

عدد و Validation

Browser و Input type ممکن است رقم فارسی را متفاوت مدیریت کنند. قرارداد مشخص کند UI چه ورودی‌هایی را می‌پذیرد و Normalization کجا انجام می‌شود. Testهای «۱۲۳»، «۱۲۳»، جداکننده، فضای نامرئی، Paste و Keyboard موبایل را داشته باشید؛ پیام خطا در RTL خوانا بماند.

تاریخ و Timezone

Native date control در Productها و OSها تجربه متفاوت دارد. اگر تقویم شمسی لازم است، Requirement، accessibility، keyboard و serialization را مستقل تعریف کنید. مقدار API باید قرارداد machine-readable مشخص داشته باشد؛ ظاهر محلی نباید با Payload اشتباه شود.

Cross-browser در CI: سریع، تشخیصی و قابل‌اعتماد

Laneهای پیشنهادی

Lane	Scope	هدف
Local/Component	Browser اصلی + Componentهای تغییرکرده	بازخورد ثانیه/دقیقه
PR smoke	Journey حیاتی روی Chromium/Firefox/WebKit	Engine regression سریع
PR risk-selective	Matrix مرتبط با Feature/API/RTL تغییرکرده	عمق متناسب با Diff
Nightly	Regression گسترده، Viewport و Channel بیشتر	پوشش زمان‌بر
Release	Product/OS/Real device قراردادشده	شاهد پشتیبانی
Production synthetic	Journey بی‌خطر در Browserهای محدود	Drift و Release verification

Portfolio، Candidate gate، TCO و Scale/Stop decision باید با استراتژی اتوماسیون تست هماهنگ باشد؛ «اجرا روی سه Browser» به‌تنهایی استراتژی نیست.

Artifact contract برای هر Failure

• Test ID، Project، Browser binary/version و OS image؛
• Commit، Build، Base URL و feature flags؛
• Locale، Timezone، Viewport، DPR و Device descriptor؛
• Trace، Screenshot، Video و Step log؛
• Console error و Network request/response خلاصه‌شده؛
• Test data namespace و Correlation ID؛
• Retry/attempt history و Failure signature؛
• Redaction وضعیت Secret/PII.

Parallelism و Test data

سه Browser ضرب در چند Worker به State مشترک فشار می‌آورد. User/order مستقل، Idempotent setup، Namespace و Cleanup لازم است. الگوی Seed/Manifest و داده فارسی در راهنمای تولید داده تست آمده است.

Environment drift

Browser image، Font package، Locale، Certificate، Proxy و System dependency را Version کنید. Playwright browser و dependencyها با نسخه Framework تغییر می‌کنند. راهنمای مدیریت محیط تست Manifest، Drift و Health gate را پوشش می‌دهد.

Retry و Quarantine

Retry فقط برای اندازه‌گیری/جمع‌آوری Evidence است، نه سبزکردن. اگر یک Test در WebKit فقط بعد از Retry Pass می‌شود، وضعیت Flaky باقی است. Quarantine باید Owner، علت فرضی، Scope، Issue، Expiry و Lane جایگزین داشته باشد؛ Critical journey بدون Evidence قابل‌اعتماد نباید مخفی شود.

ابزار را چگونه انتخاب کنیم؟

Developer tools و اجرای محلی

برای Reproduce، DOM، Computed style، Network، Performance و Accessibility tree عالی‌اند. Device toolbar برای Approximation سریع است، نه مدرک Real device.

Playwright

سه Engine، Project configuration، isolation، web-first assertion، Trace و parallelism یکپارچه دارد. محدودیت Product/Engine branded و Real device را باید با Matrix تکمیل کرد.

Selenium WebDriver و Grid

برای Browserهای واقعی، Bindingهای متعدد و زیرساخت Remote گسترده مناسب است. Selenium Grid اجرای موازی روی ماشین‌های Remote، نسخه‌های مختلف Browser و Platformها را هدف می‌گیرد. هزینه عملیات، Driver/browser compatibility، Capacity و Artifact را در PoC بسنجید.

Cloud device/browser lab

پوشش Product/OS/Device را سریع می‌کند، اما انتخاب Vendor به این معیارها نیاز دارد:

• Real vs virtual و Version availability؛
• Iran access، خرید/تمدید، IP restriction و Support؛
• Concurrency، Queue، Session stability و Debug artifact؛
• Secure tunnel، data residency، retention و log redaction؛
• SSO/RBAC/Audit/API و خروج داده؛
• هزینه License + Triage + نگهداری؛
• مسیر Export/مهاجرت و جایگزین Self-hosted.

هیچ Logoای «پوشش کامل» نمی‌دهد. یک PoC با پنج Journey واقعی، یک Failure injection، RTL، Upload/Permission و Change exercise انجام دهید.

Cross-browser و SEO؛ ادعای دقیق چیست؟

خرابی Render، Navigation یا محتوای اصلی می‌تواند دسترسی کاربر و Crawler را مختل کند؛ Performance و Mobile usability هم مهم‌اند. اما از «سازگاری بیشتر مستقیماً رتبه را بالا می‌برد» یا Dwell time به‌عنوان رابطه قطعی استفاده نکنید. Technical SEO، indexability، structured data و field performance آزمون‌ها و داده‌های جدا می‌خواهند. Cross-browser ابتدا تعهد تجربه و عملکرد کاربر است.

ملاحظات تیم‌های ایرانی

دسترسی سرویس ابری

پیش از وابستگی به Browser cloud، اتصال، پرداخت، IP، Tunnel و Export artifact را در شرایط واقعی امتحان کنید. مسیر Self-hosted Grid، Runner macOS محدود و Device lab کوچک می‌تواند Contingency باشد.

CDN، Font و Registry

Font، Script، Map، CAPTCHA یا Asset خارجی ممکن است در شبکه‌ای Block یا کند شود. Critical asset را با Policy میزبانی/Cache/Fallback مشخص کنید و Failure را در سه Engine و شبکه کنترل‌شده تست کنید. دورزدن غیرمجاز یا انتقال داده حساس راه‌حل QA نیست.

پرداخت و Redirect

Popup blocker، SameSite cookie، Back/forward، Deep link، Return URL و Multiple tab را در Browserهای هدف بررسی کنید. Callback و Reconciliation backend را از Cross-browser جدا و با Contract/API test پوشش دهید.

فارسی و گروه‌های کاربری

Desktop Chrome تنها نماینده کاربران ایران نیست. داده خود محصول، مشتری سازمانی، iOS، Android WebView، نسخه‌های Enterprise و Accessibility needs را ببینید. سهم کم نباید گروه پراثر را خودکار حذف کند.

برنامه ۳۰روزه پیاده‌سازی

روزهای ۱ تا ۵: Support contract

• پنج Journey حیاتی و سه سطح پشتیبانی را تعریف کنید.
• Analytics، Support و Engine diversity را جمع کنید.
• Browser/OS/Device/Locale Manifest بسازید.

روزهای ۶ تا ۱۲: پیشگیری و Smoke

• Validation، Baseline/compatibility review و Feature detection را اضافه کنید.
• سه Project Playwright و Fixture فارسی بسازید.
• Artifact contract و Redaction را فعال کنید.

روزهای ۱۳ تا ۲۰: Debug و Real device

• دو ناسازگاری واقعی را با گردش‌کار Evidence حل کنید.
• Safari/iPhone و Chrome/Android قراردادشده را روی Device واقعی اجرا کنید.
• WebKit/Firefox/Chromium failure taxonomy بسازید.

روزهای ۲۱ تا ۲۶: CI و Governance

• PR smoke، Nightly و Release lane را جدا کنید.
• Retry/Quarantine/Exception policy با Owner و Expiry بنویسید.
• Parallelism، Data isolation و Environment health را اندازه بگیرید.

روزهای ۲۷ تا ۳۰: تصمیم Scale

• Time-to-signal، Flaky rate و Defectهای Cross-browser را مرور کنید.
• Matrix اضافی کم‌ارزش را حذف و Gap پرریسک را اضافه کنید.
• PoC Cloud/Self-host و هزینه کل را ثبت کنید.

چک‌لیست نهایی Cross-browser Testing

• Support contract و Browser matrix نسخه‌دار است.
• Journey و Capability، نه فقط نام Browser، Coverage item است.
• Browser product، Engine، Channel، OS و Device جدا ثبت می‌شوند.
• Playwright WebKit به‌عنوان Safari واقعی گزارش نشده است.
• Feature detection و Fallback برای Feature محدود داریم.
• HTML validation به‌عنوان Diagnostic، نه تضمین کیفیت، استفاده می‌شود.
• Chromium/Firefox/WebKit smoke در CI و Real-device checkpoint داریم.
• Functional، visual، interaction، accessibility و RTL از هم تفکیک شده‌اند.
• Test data و State بین Browser/Workerها ایزوله است.
• Failure artifact شامل Version/OS/Locale/Trace/Network است.
• Retry Failure را پنهان نمی‌کند و Quarantine منقضی‌شونده است.
• Analytics bias، کاربران کم‌سهم پراثر و Iran access بازبینی می‌شوند.

سوالات متداول تست Cross Browser

تست Cross Browser دقیقاً چیست؟

بررسی این است که Journeyها و قابلیت‌های توافق‌شدهٔ محصول وب در ترکیب‌های پشتیبانی‌شده Browser، Engine، Version، OS و Device رفتار قابل‌قبول داشته باشند. هدف لزوماً Pixel یکسان نیست؛ Core function، معنا، دسترس‌پذیری و Fallback باید طبق Support contract حفظ شوند.

آیا تست Chromium، Firefox و WebKit در Playwright کافی است؟

برای Engine-level smoke و بسیاری Regressionها بسیار ارزشمند است، اما همیشه کافی نیست. Playwright WebKit Safari برندشده و دستگاه iOS واقعی نیست؛ Firefox آن نیز Build وصله‌شده است. اگر قرارداد Product/OS/Device مشخصی دارد، همان Environment واقعی یا نزدیک‌ترین لابراتوار معتبر را نیز تست کنید.

کدام مرورگرها و نسخه‌ها را انتخاب کنیم؟

از Analytics، Failure/conversion، Support ticket، قرارداد مشتری، Browser API، Engine diversity، ریسک Journey و هزینه شواهد استفاده کنید. آستانه جهانی سهم بازار یا تعداد نسخه وجود ندارد. Tier و تاریخ بازبینی/حذف هر ترکیب را ثبت کنید.

تفاوت Responsive Testing و Cross-browser چیست؟

Responsive testing رفتار Layout در Viewport/Content مختلف را می‌سنجد؛ Cross-browser اختلاف Engine، API، Platform، Product و Version را نیز پوشش می‌دهد. Device mode فقط Viewport و چند ویژگی را تقریب می‌زند و جای Browser/Device واقعی را نمی‌گیرد.

چگونه مشکلات Cross-browser را سریع Debug کنیم؟

Environment دقیق را ثبت، Failure را طبقه‌بندی، Artifact یکسان از دو Browser جمع، Repro را کوچک، Support/spec/WPT را بررسی، Fix استاندارد یا Fallback بساز و Regression را در پایین‌ترین لایه مؤثر اضافه کن. پاک‌کردن Cache یا Retry بدون Root cause بسته‌شدن نیست.

جمع‌بندی: سازگاری یک قرارداد قابل‌آزمون است

Cross-browser حرفه‌ای از فهرست Logoها شروع نمی‌شود؛ از Journey، Capability و Support contract شروع می‌شود. Web standards، Baseline و Feature detection ناسازگاری را پیشگیری می‌کنند؛ سه Engine Playwright بازخورد سریع می‌دهند؛ Product/OS/Device واقعی تعهد نهایی را می‌سنجد؛ و Artifact دقیق اختلاف را قابل‌رفع می‌کند. نتیجه، تجربه‌ای قابل‌قبول و آگاهانه برای کاربران هدف است، نه وعده غیرممکن «همه‌جا کاملاً یکسان».