«روی لپ‌تاپ من درست است» یکی از پرهزینه‌ترین جمله‌ها در روز انتشار است. همان صفحه پرداخت ممکن است در Chrome دسکتاپ بی‌نقص به نظر برسد، اما در Safari آیفون دکمه بازگشت از درگاه را پنهان کند، در یک WebView اندرویدی OTP را نپذیرد یا با فونت فارسی کاربر، مبلغ را از کادر بیرون ببرد. راه‌حل، اجرای محصول روی هر ترکیب ممکن نیست؛ چنین مجموعه‌ای عملاً پایانی ندارد.
تست سازگاری (Compatibility Testing) یعنی بررسی اینکه محصول در دامنه پشتیبانی‌شده و اعلام‌شده نتیجه‌ای معادل، قابل‌استفاده و ایمن بدهد. «معادل» الزاماً به معنی یکسان‌بودن پیکسل‌ها نیست. تیم باید ابتدا قرارداد پشتیبانی و ماتریس ریسک‌محور بسازد، سپس ترکیبی از Feature Detection، تست خودکار چندمرورگری، محیط مجازی و دستگاه واقعی را به کار بگیرد. این راهنما همین مسیر را با مثال یک فروشگاه اینترنتی ایرانی توضیح می‌دهد.
پاسخ کوتاه: تست سازگاری چیست؟
تست سازگاری ارزیابی رفتار نرم‌افزار در ترکیب‌های معنادارِ مرورگر، موتور مرورگر، سیستم‌عامل، دستگاه، اندازه و تراکم صفحه، شیوه ورودی، زبان و جهت متن، فناوری کمکی، شبکه، WebView، نسخه API و پیکربندی است. هدف آن پاسخ به سه سؤال است:
- کدام محیط‌ها رسماً پشتیبانی می‌شوند و سطح تعهد در هرکدام چیست؟
- آیا سفرهای حیاتی کاربر در آن محیط‌ها با نتیجه کسب‌وکاری و ایمنی معادل کامل می‌شوند؟
- اگر قابلیتی در دسترس نیست، آیا محصول شکست کنترل‌شده، پیام روشن یا مسیر جایگزین دارد؟
ناسازگاری ممکن است به شکل خطای عملکردی، به‌هم‌ریختگی نمایش، افت کارایی، مانع دسترس‌پذیری، خرابی نصب یا شکست یکپارچه‌سازی ظاهر شود. بنابراین برچسب‌زدن آن به‌عنوان «فقط یک تست غیرعملکردی» مفید نیست؛ نوع اثر و ریسک باگ مهم‌تر از طبقه‌بندی آن است.
هدف، رفتار معادل است؛ نه ظاهر کاملاً یکسان
مرورگرها، فونت‌ها، کنترل‌های بومی سیستم‌عامل و موتورهای رندر ممکن است تفاوت‌های جزئی و قابل‌قبول داشته باشند. اصرار بر Pixel-perfect بودن همه محیط‌ها هزینه نگهداری را بالا می‌برد و گاهی دسترس‌پذیری بومی را خراب می‌کند. معیار پذیرش بهتر چنین است:
- کاربر می‌تواند هدف اصلی، مانند جست‌وجو، ورود یا پرداخت را کامل کند؛
- قواعد دامنه، مبلغ، مجوز و Side effect در همه محیط‌های پشتیبانی‌شده یکسان‌اند؛
- اطلاعات ضروری خوانا و ترتیب تعامل قابل‌فهم است؛
- تفاوت بصری مانع عمل، درک یا اعتماد نمی‌شود؛
- امنیت، حریم خصوصی و ثبت رویداد قربانی محیط خاص نمی‌شوند؛
- قابلیت اختیاریِ پشتیبانی‌نشده، Fallback یا پیام مناسب دارد.
قرارداد خوب نمی‌گوید «در همه دستگاه‌ها بی‌نقص است». می‌گوید «در محیط‌های Tier ۱ و Tier ۲، این سفرها با این معیارهای پذیرش پشتیبانی می‌شوند».
پیش از ماتریس، قرارداد پشتیبانی بنویسید
فهرست مرورگرها بدون سطح تعهد مبهم است. یک مدل چهارسطحی ساده، تصمیم انتشار و رسیدگی به باگ را شفاف می‌کند.
| سطح | تعهد پیشنهادی | زمان اجرا | اثر شکست |
|---|---|---|---|
| Tier ۱: حیاتی | تمام سفرهای درآمدی و امنیتی؛ مانع انتشار در صورت شکست | روزانه و پیش از Release | Blocker یا تصمیم ریسک مستند |
| Tier ۲: پشتیبانی‌شده | رفتار کامل با تفاوت ظاهری قابل‌قبول | Nightly و Release | رفع زمان‌بندی‌شده بر اساس شدت |
| Tier 3: Best effort | مسیر پایه یا Graceful degradation؛ بدون تضمین همه قابلیت‌ها | Smoke دوره‌ای و هنگام تغییر حساس | بررسی موردی و اعلام محدودیت |
| خارج از پشتیبانی | تعهد تست منظم ندارد؛ نباید به‌طور گمراه‌کننده پذیرفته شود | فقط با Incident یا تصمیم تجاری | پیام یا مستند روشن، نه شکست خاموش |
قرارداد باید قابل‌نسخه‌گذاری باشد
نام «نسخه‌های اخیر» کافی نیست. سیاستی قابل اجرا تعریف کنید؛ برای مثال «نسخه Stable فعلی و یک نسخه پیشین از مرورگرهای Tier ۱، همراه با نسخه‌های سیستم‌عامل مشخص در جدول نسخه‌دار». تاریخ بازبینی، مالک و منبع داده را هم ثبت کنید. هر Release مرورگر، سیستم‌عامل یا SDK می‌تواند ماتریس را تغییر دهد.
خارج از پشتیبانی یعنی چه؟
خارج‌بودن از پشتیبانی مجوز نمایش صفحه سفید یا از دست‌دادن داده نیست. اگر تشخیص قابل‌اعتماد است، محدودیت و مسیر ارتقا را توضیح دهید. در غیر این صورت، Progressive enhancement اجازه می‌دهد قابلیت پایه کار کند. مسدودکردن صرفاً با User-Agent معمولاً شکننده و تبعیض‌آمیز است.
ابعاد واقعی یک Compatibility Matrix
ماتریس فقط «Chrome × Windows» نیست. بسته به معماری محصول، این ابعاد را بررسی کنید:
- مرورگر: Engine، Brand، Channel و نسخه؛
- سیستم‌عامل: خانواده، نسخه، Build/Patch و سیاست‌های سازمانی؛
- دستگاه: مدل نماینده، CPU/RAM، GPU، حافظه و Thermal throttling؛
- نمایش: Viewport، رزولوشن، Device Pixel Ratio، Zoom، Orientation، Safe area و اندازه فونت سیستم؛
- ورودی: Touch، Mouse، Keyboard، IME، قلم، Autofill و رمز یک‌بارمصرف؛
- زبان و منطقه: fa-IR، RTL، فونت، نیم‌فاصله، ارقام فارسی/لاتین، تقویم، منطقه زمانی و واحد پول؛
- فناوری کمکی: Screen reader، بزرگ‌نمایی، Voice control و Keyboard-only؛
- بستر اجرا: Browser tab، PWA، In-app browser، Android WebView یا iOS web view؛
- قابلیت‌های سیستم: مجوزها، دوربین، مکان، Share sheet، Push، Deep link و اجرای پس‌زمینه؛
- شبکه و پیکربندی: تأخیر، قطعی، تغییر Wi-Fi/Cellular، Proxy، VPN، Content blocker، Feature flag و CDN؛
- نسخه‌های متصل: API، Schema، فایل، Protocol، SDK و Client قدیمی/جدید.
هر بُعد برای هر محصول لازم نیست. پرسش درست این است: «کدام تفاوت محیطی می‌تواند Oracle، سفر حیاتی یا داده ما را تغییر دهد؟» سپس فقط Valueهای نماینده و قابل‌اجرا را وارد مدل کنید.
مرز تست سازگاری با تست‌های همسایه
| حوزه | سؤال اصلی | هم‌پوشانی با سازگاری |
|---|---|---|
| Responsive | چیدمان در Viewport و محتواهای مختلف چگونه تطبیق می‌یابد؟ | Viewport بخشی از ماتریس است، اما Device واقعی فقط Viewport نیست. |
| دسترس‌پذیری | کاربر با توانایی‌ها و فناوری‌های کمکی مختلف می‌تواند کار را انجام دهد؟ | ترکیب Browser × Screen reader مهم است، ولی تست سازگاری جای ارزیابی WCAG را نمی‌گیرد. |
| عملکرد | زمان پاسخ، ظرفیت و پایداری زیر بار یا محدودیت منابع چقدر است؟ | دستگاه و شبکه روی تجربه اثر دارند؛ اما Emulation شبکه جای Load test را نمی‌گیرد. |
| Interoperability | دو سیستم مستقل طبق قرارداد با هم تبادل درست دارند؟ | API/Protocol version matrix محل هم‌پوشانی است. |
| Portability | انتقال یا استقرار محصول در محیط دیگر با چه هزینه‌ای ممکن است؟ | Compatibility بیشتر رفتار زمان اجرا را می‌سنجد. |
برای جزئیات هر حوزه، از راهنمای تست دسترس‌پذیری و طراحی برنامه تست عملکرد استفاده کنید؛ گزارش نهایی باید هم‌پوشانی و Gap هر کدام را روشن کند.
چگونه ترکیب‌های ماتریس را انتخاب کنیم؟
سیگنال‌های انتخاب
ماتریس را از ترکیب داده و تعهد بسازید، نه از سلیقه تیم:
- Analytics دست‌اول با رعایت Consent و حداقل‌سازی داده؛
- قرارداد مشتریان، دستگاه سازمانی و الزامات قانونی؛
- سهم درآمد، نرخ تکمیل Journey و هزینه شکست هر Cohort؛
- تیکت‌های پشتیبانی، Incident و تاریخچه نقص‌ها؛
- تغییرات Release: CSS جدید، SDK پرداخت، WebView، Camera یا Storage؛
- تنوع Engine و OS، نه فقط محبوب‌ترین Brandها؛
- حداقل/حداکثر سخت‌افزار یا نسخه اعلام‌شده محصول؛
- دسترسی واقعی تیم به محیط و زمان بازتولید.
امتیاز ریسک ساده
برای هر ترکیب می‌توان امتیاز تقریبی زیر را در بازبینی تیمی ساخت:
Risk = Exposure × Business Impact × Change Likelihood × Detection Difficulty
اعداد حقیقت علمی نیستند؛ ابزار گفت‌وگو و اولویت‌بندی‌اند. امتیاز را با داده Incident و Production بازتنظیم کنید. یک محیط کم‌ترافیک اما قراردادی یا ایمنی‌حساس می‌تواند Tier ۱ باشد.
چرا سهم بازار به‌تنهایی کافی نیست؟
آمار عمومی ممکن است Cohort واقعی محصول شما را بازنمایی نکند، Brand را با Engine یکی بگیرد یا WebView و مرورگر درون‌برنامه‌ای را پنهان کند. از آن برای کشف فرضیه استفاده کنید، نه برای قرارداد پشتیبانی. همچنین فهرست ثابتِ «همه مرورگرهای مهم» سریعاً منقضی می‌شود.
کاهش ترکیب‌ها با Pairwise
اگر ابعاد تا حدی مستقل‌اند، ۲-way یا Mixed-strength می‌تواند پوشش Interactionها را با Row کمتر فراهم کند. اما Journey حیاتی، Incident regression، مرز عددی، حالت، توالی و ترکیب امنیتی باید Seed یا تست صریح داشته باشند. روش مدل‌سازی، Constraint و Verification در آموزش تست Pairwise و All-Pairs آمده است.
مثال: ماتریس فروشگاه اینترنتی ایرانی
فرض کنید داده محصول نشان می‌دهد بیشترین خرید از وب موبایل است و بازگشت از درگاه، ورود OTP و نمایش مبلغ نقاط پرریسک‌اند. جدول زیر نمونه است، نه نسخه آماده برای هر کسب‌وکار:
| سطح | محیط نماینده | سفر/تمرکز | تناوب |
|---|---|---|---|
| Tier 1 | Chrome Stable روی Android میانه بازار | ورود، جست‌وجو، سبد، درگاه، callback، رسید | هر Merge + دستگاه واقعی Release |
| Tier 1 | Safari روی iOS پشتیبانی‌شده | Autofill/OTP، بازگشت از درگاه، Safe area، Keyboard | روزانه + واقعی Release |
| Tier 1 | Chrome دسکتاپ روی OS اصلی کاربران | تمام Golden path و پنل مشتری | هر Merge |
| Tier 2 | Firefox و Edge در نسخه‌های قراردادی | Regression اصلی، دانلود/چاپ و ورود | Nightly + Release |
| Tier 2 | Samsung Internet یا Brand پرترافیک واقعی | پرداخت، Sticky UI، Keyboard و بازگشت | Nightly/هفتگی بر اساس ظرفیت |
| Tier 2 | WebView یا In-app browser مورد استفاده کمپین | Deep link، Cookie، SSO و بازگشت به اپ | Release و تغییر SDK |
| Cross-cutting | fa-IR، RTL، ارقام فارسی/لاتین، فونت بزرگ | مبلغ، تاریخ، آدرس، خطا و Invoice | در تمام Tierهای منتخب |
| Cross-cutting | شبکه کند، قطعی و بازیابی | Idempotency پرداخت، Retry و وضعیت نامشخص | Nightly + Exploratory |
Oracle نمونه برای بازگشت از درگاه
- Order دقیقاً یک‌بار ثبت شود، حتی با Refresh یا callback تکراری؛
- مبلغ نمایشی، درخواست درگاه و Ledger برابر باشند؛
- کاربر پس از بازگشت، وضعیت قطعی یا Pending قابل‌پیگیری ببیند؛
- Back/Forward مرورگر Side effect دوم نسازد؛
- پیام فارسی در RTL خوانا باشد و اطلاعات حساس در URL یا Console نرود؛
- همان نتیجه با Keyboard، Touch و اندازه فونت بزرگ قابل دستیابی باشد.
برای طراحی عمیق‌تر روی نصب، مجوز، وقفه، دستگاه و Store از راهنمای تست اپلیکیشن موبایل استفاده کنید.
Engine، Brand، Channel و WebView را یکی نگیرید
Engine با Brand برابر نیست
Chrome و Edge ممکن است خانواده Engine مشترکی داشته باشند، اما Channel انتشار، Feature flag، Policy سازمانی، Codec، Extension، Integration سیستم‌عامل و زمان عرضه آن‌ها متفاوت است. اجرای Chromium متن‌باز پوشش مفیدی می‌دهد، ولی اثبات نمی‌کند رفتار Brand نصب‌شده کاربر دقیقاً همان است.
Channel بخشی از ریسک است
Stable محیط پایه است؛ Beta/Preview می‌تواند هشدار زودهنگام تغییر آینده باشد. قرار نیست همه تست‌ها روی همه Channelها اجرا شوند. یک Smoke کوچک روی Channel آینده برای محصول پرترافیک، زمان اصلاح را افزایش می‌دهد.
WebView یک مرورگر معمولی نیست
نسخه Engine، میزبان اپ، Bridge بومی، Cookie policy، Navigation delegate و Lifecycle روی رفتار اثر دارند. برای In-app browser نیز Header، Deep link، بازشدن پنجره جدید و بازگشت به میزبان را جدا بسنجید. برچسب «موبایل Chrome» برای توصیف این محیط کافی نیست.
از قواعد ثابت درباره iOS پرهیز کنید
سیاست Engine و قابلیت‌های مرورگر ممکن است با نسخه سیستم‌عامل، منطقه و مقررات تغییر کند. به‌جای جمله همیشگیِ «همه مرورگرهای iOS دقیقاً یکی‌اند»، محیط واقعیِ هدف و مستندات نسخه را بررسی و در Evidence ثبت کنید.
Feature Detection و Progressive Enhancement
تشخیص قابلیت می‌پرسد «این API یا مقدار CSS در محیط فعلی قابل استفاده است؟»؛ UA sniffing می‌پرسد «نام مرورگر چیست؟» و سپس از نام آن درباره قابلیت حدس می‌زند. راهنمای رسمی MDN درباره Feature Detection استفاده از آزمون قابلیت و سازوکارهایی مانند CSS.supports() و @supports را توضیح می‌دهد و آن را از Browser sniffing جدا می‌کند.
نمونه CSS با Fallback
.product-list {
display: flex;
flex-wrap: wrap;
}
@supports (display: grid) {
.product-list {
display: grid;
grid-template-columns: repeat(auto-fit, minmax(16rem, 1fr));
}
}
نمونه JavaScript
if ("share" in navigator) {
shareButton.hidden = false;
shareButton.addEventListener("click", () => navigator.share(data));
} else {
copyLinkButton.hidden = false;
}
وجود property فقط یک سیگنال است؛ درست‌کارکردن API، Permission، رفتار خطا و Integration را ثابت نمی‌کند. Feature Detection باید با تست رفتاری در محیط‌های Tier ترکیب شود. Polyfill نیز باید از نظر امنیت، اندازه Bundle، License و نگهداری ارزیابی شود.
دستگاه واقعی، Emulator و شبیه‌سازی مرورگر
| محیط | برای چه چیزی خوب است؟ | چه چیزی را ثابت نمی‌کند؟ |
|---|---|---|
| DevTools responsive mode | Viewport، DPR تقریبی، Orientation و بازبینی سریع CSS | OS واقعی، Touch stack، فونت، GPU، باتری، Permission و WebView |
| Browser automation + device profile | Regression سریع روی Viewport، UA، Locale، Timezone و قابلیت‌های Emulation | سخت‌افزار و مرورگر Brandشده دقیق دستگاه |
| Simulator/Emulator سیستم‌عامل | پوشش نسخه‌ای، Debug، Failure injection و اجرای تکرارپذیر | همه تفاوت‌های سنسور، OEM، Thermal، Radio و عملکرد واقعی |
| دستگاه واقعی محلی/ابری | ورودی، سخت‌افزار، OS integration، Camera، Biometrics، Push و تجربه واقعی‌تر | خودبه‌خود همه شبکه‌ها، کاربران و نسخه‌ها را پوشش نمی‌دهد |
نه محیط مجازی ذاتاً «کم‌دقت» است و نه دستگاه واقعی پاسخ همه سؤال‌ها. Fidelity نسبت به سؤال تست سنجیده می‌شود. برای CSS یک Viewport مجازی شاید کافی باشد؛ برای فوکوس پس از بازشدن Keyboard، NFC، مصرف باتری یا callback اپ پرداخت، دستگاه واقعی ارزش بیشتری دارد.
مجموعه واقعی را نماینده انتخاب کنید
به‌جای خرید ده‌ها مدل مشابه، مجموعه‌ای با تنوع OS، RAM/CPU، اندازه، OEM و Cohort درآمدی بسازید. هر دستگاه باید دلیل حضور، مالک، نسخه، وضعیت باتری/فضا و برنامه به‌روزرسانی داشته باشد. دستگاه‌های رهاشده با نسخه تصادفی، ماتریس قابل اعتماد نمی‌سازند.
معماری اجرای تست در CI/CD
پیش از Commit یا در PR
- Lint و بررسی Static برای APIهای ناسازگار؛
- Component test روی Breakpointها و متن‌های بلند فارسی؛
- یک Browser/Engine سریع برای Golden path؛
- Feature Detection و Fallbackهای قابل تست؛
- Visual diff محدود و پایدار برای اجزای حساس.
پس از Merge
Regression حیاتی را روی چند Engine اجرا کنید. مستندات رسمی Playwright Projects نشان می‌دهد یک Suite را می‌توان با پیکربندی‌های مختلف Browser و Environment اجرا کرد. مستندات Emulation پلی‌رایت پارامترهایی مانند دستگاه، Locale، Timezone، Permission و Media را توضیح می‌دهد. این Profileها سریع و مفیدند، اما معادل خودکارِ همه دستگاه‌های Brandشده نیستند.
Nightly و Release candidate
- ماتریس گسترده‌تر OS/Browser و Network profile؛
- ترکیب‌های Pairwise و Regression نقص‌های گذشته؛
- تست روی Browser channel آینده برای هشدار زودهنگام؛
- دستگاه واقعی برای سفرهای Tier ۱؛
- Exploratory charter روی تغییر پرریسک؛
- نسخه Client قدیمی در برابر Backend جدید.
اجرای توزیع‌شده
Selenium Grid اجرای WebDriver را روی ماشین‌ها و محیط‌های مختلف توزیع می‌کند. Grid یا سرویس ابری ظرفیت می‌دهد، ولی انتخاب ماتریس، Isolation داده، تشخیص خطای زیرساخت و Oracle همچنان مسئولیت تیم است. ابتدا یک Pilot کوچک بسازید و هزینه Flake و Queue را اندازه بگیرید.
پس از انتشار
تست پیش از انتشار تمام تفاوت‌های Production را نمی‌بیند. Error، Core journey completion، نسخه Browser/OS در حد نیاز و با حریم خصوصی، و تیکت‌های پشتیبانی را پایش کنید. Telemetry باید سیگنال بازنگری ماتریس باشد، نه ابزار Fingerprinting بی‌ضابطه.
اتوماسیون چه چیزی را پوشش دهد؟
تست خودکار برای مسیرهای تکراری، Assertionهای دامنه‌ای و اجرای چندپیکربندی عالی است. اما هدف «هر Case روی هر ترکیب» نیست؛ این کار هزینه، زمان و Flake را ضرب می‌کند. راهبرد بهتر:
- Smoke بسیار کوچک روی همه Rowهای ماتریس؛
- Regression عمیق روی Tier ۱ و تغییرات حساس؛
- تست Component برای حالت‌های بصری و فارسی؛
- Contract test برای نسخه‌های API و Schema؛
- تست دستی/اکتشافی برای Interaction، حس کاربری و محیط جدید؛
- Real-device test محدود برای قابلیت‌های وابسته به سخت‌افزار یا OS.
هزینه انتخاب، نگهداری و سنجش بازگشت سرمایه در راهنمای اتوماسیون تست تشریح شده است.
Visual Regression بدون آلارم کاذب
Screenshot diff می‌تواند بریدگی متن، جابه‌جایی دکمه و تغییر ناخواسته CSS را پیدا کند؛ اما بدون کنترل محیط به نویز تبدیل می‌شود.
Baseline معتبر
- Browser/OS/Font و رزولوشن Baseline نسخه‌دار باشند؛
- داده، ساعت، Animation و تبلیغ پویا ثابت یا Mask شوند؛
- Threshold با نمونه واقعی Anti-aliasing تنظیم شود؛
- هر تغییر Baseline مالک و توضیح Review داشته باشد؛
- تصویر واقعی حساس پیش از Archive پاک‌سازی شود.
محدودیت Visual diff
شباهت Screenshot ثابت نمی‌کند Keyboard navigation، نام دسترس‌پذیر، رویداد پرداخت یا API درست است. Snapshot را کنار Assertion رفتاری و تست دسترس‌پذیری قرار دهید، نه به‌جای آن.
نکات ویژه وب موبایل و اپ
- بازشدن و بسته‌شدن Keyboard، تغییر Viewport و حفظ فوکوس؛
- Safe area، بریدگی صفحه، Landscape و Multi-window؛
- Permissionهای Denied/Ask every time و بازگشت از Settings؛
- Deep link و Universal/App link در حالت نصب/عدم نصب؛
- قطع و وصل شبکه، تغییر Wi-Fi به Cellular و Resume پس از Background؛
- Autofill، OTP، Password manager و IME فارسی؛
- Share، Upload، Camera، Download و بازکردن فایل؛
- به‌روزرسانی اپ با داده نسخه پیشین و Rollback پشتیبانی‌شده؛
- مصرف حافظه و رفتار Low-memory روی دستگاه ضعیف؛
- In-app browser، Cookie/SSO و بازگشت به میزبان.
سازگاری فارسی و شرایط کاربران ایران
متن و ورودی
واژه طولانی، نیم‌فاصله، ترکیب فارسی و لاتین، اعداد ۱۲۳ و ۱۲۳، ایمیل/کدملی/شماره کارت، Cursor در RTL و Copy/Paste را تست کنید. فونت Web ممکن است دیر لود شود یا در شبکه محدود در دسترس نباشد؛ Fallback باید خوانا و بدون Layout shift مخرب باشد.
تاریخ، زمان و پول
تقویم شمسی، ISO date، منطقه زمانی ایران، تغییر روز در نیمه‌شب، جداکننده هزارگان و واحد ریال/تومان را در مدل دامنه روشن کنید. نمایش «۱۰۰,۰۰۰» بدون واحد و قرارداد تبدیل، مسئله سازگاری نیست؛ مسئله محصول و داده است.
درگاه و محدودیت شبکه
Redirect، تب جدید، Cookie، callback، Back و Retry را روی مرورگرهای Tier و WebViewهای واقعی بسنجید. وابستگی خارجی ممکن است از برخی شبکه‌ها، DNSها یا IPها رفتار متفاوت داشته باشد. نتیجه را با چند مسیر کنترل‌شده بررسی کنید و اطلاعات پرداخت یا PII را در HAR، Video و Console نگه ندارید.
Backward و Forward Compatibility
سازگاری فقط UI نیست. در Rolling deployment، نسخه جدید Backend ممکن است هم‌زمان به Client قدیمی و جدید پاسخ دهد. یک جدول حداقل بسازید:
| Client | Backend | انتظار |
|---|---|---|
| قدیمیِ هنوز پشتیبانی‌شده | جدید | قرارداد قبلی حفظ یا پاسخ ارتقا روشن؛ بدون Corruption |
| جدید | قدیمی در حین Rollout | Feature negotiation/Fallback و عدم ارسال اجباری فیلد ناشناخته |
| جدید | جدید | رفتار کامل قابلیت تازه |
| قدیمی خارج از پشتیبانی | جدید | خطای نسخه‌دار، امن و قابل‌فهم طبق سیاست |
API و فایل
فیلد اختیاری، Enum تازه، ترتیب، Null، Idempotency، Content-Type و خطای نسخه را آزمایش کنید. جزئیات Contract و Negative testing در راهنمای تست API آمده است.
Schema و Migration
Expand–Migrate–Contract، خواندن داده قدیمی، Backfill قابل‌ازسرگیری و Rollback واقعی را در ترکیب نسخه‌ها بسنجید. حذف زودهنگام ستون یا Constraint جدید ممکن است Client قدیمی را فقط در بخشی از Rollout بشکند. برای الگوهای Integrity و Migration به راهنمای تست پایگاه داده مراجعه کنید.
انتخاب Device Farm یا سرویس ابری
نام ابزار به‌تنهایی راهبرد نیست. یک Proof of Concept با Journey واقعی اجرا و این معیارها را ثبت کنید:
- واقعی یا مجازی‌بودن محیط و امکان اثبات مدل/نسخه دقیق؛
- موجودی Browser/OS/Device موردنیاز و زمان انتظار؛
- Concurrency، مدت Session، Retry و قیمت نهایی با Video/Artifact؛
- Local tunnel، Proxy، IP allowlist و دسترسی به محیط آزمایش؛
- محل پردازش/نگهداری داده، Retention، حذف Session و کنترل دسترسی؛
- مدیریت Secret، Mask ورودی، Redaction و Audit log؛
- Console، Network، HAR، Video، Crash و Export شواهد؛
- پایداری اتصال و امکان پرداخت/پشتیبانی برای تیم مستقر در ایران؛
- API/CLI، Pin نسخه، Integration با CI و خروج از Vendor lock-in؛
- تفکیک شکست محصول از شکست زیرساخت و SLA سرویس.
داده Production واقعی را وارد دستگاه مشترک نکنید. حساب، کارت و شماره تماس مصنوعی بسازید و Cleanup قابل‌اثبات داشته باشید.
فرآیند ده‌مرحله‌ای تست سازگاری
- Scope محصول: Journey، Platform و ریسک خارج از محدوده را مشخص کنید.
- قرارداد پشتیبانی: Tier، نسخه، تاریخ بازبینی و مالک را بنویسید.
- جمع‌آوری شواهد: Analytics، قرارداد، Incident، معماری و تغییر Release را مرور کنید.
- مدل ابعاد: Browser/Engine/OS/Device/Locale/AT/WebView/API را فقط در حد مرتبط انتخاب کنید.
- کاهش ترکیب: Risk score، Partition، Constraint، Pairwise و Seedهای اجباری را اعمال کنید.
- تعریف Oracle: نتیجه دامنه، UI، ایمنی، Accessibility و Side effect را قابل سنجش کنید.
- انتخاب Fidelity: مشخص کنید هر سؤال به DevTools، Automation، Emulator یا دستگاه واقعی نیاز دارد.
- ساخت Laneها: PR، Merge، Nightly، Release و Production monitoring را جدا کنید.
- اجرای Pilot: یک سفر حیاتی را اجرا، Flake/هزینه/زمان بازتولید را اندازه‌گیری و ماتریس را اصلاح کنید.
- بازنگری دوره‌ای: با Releaseهای محیط، افت Usage، Incident و تغییر قرارداد، Tierها را نسخه‌گذاری کنید.
Test Case سازگاری چه اجزایی دارد؟
Case: بازگشت موفق از درگاه در iOS Safari
Environment:
- Device model / OS build
- Browser brand, channel, exact version
- App/Web build and feature flags
- Locale=fa-IR, RTL, Persian font
- Network profile
Precondition:
- سفارش مصنوعی یکتا و درگاه Sandbox
- Session تازه؛ بدون داده واقعی مشتری
Actions:
1. افزودن کالا و رفتن به پرداخت
2. ارسال یک‌باره درخواست
3. بازگشت از درگاه
4. Refresh کنترل‌شده صفحه نتیجه
Oracle:
- یک Order و یک Payment effect
- مبلغ و شناسه مرجع منطبق
- وضعیت قطعی یا Pending قابل بازیابی
- دکمه‌ها قابل لمس و متن بدون بریدگی
- Secret/PII در URL، Console و Artifact نیست
Case باید محیط را قابل بازسازی کند، نه اینکه فقط بنویسد «روی موبایل تست شد». Version و Build بخشی از ورودی تست‌اند.
گزارش باگ سازگاری و شواهد لازم
حداقل Evidence محیط
- Browser Brand، Channel، نسخه دقیق و در صورت نیاز Engine build؛
- OS version/build، Device model یا VM image؛
- Viewport، DPR، Zoom، Orientation و اندازه فونت؛
- Locale، جهت، Timezone، Keyboard/IME و فناوری کمکی؛
- App/Web/WebView build، Feature flag و Account cohort مصنوعی؛
- Network profile، Proxy/VPN و وضعیت Online→Offline؛
- مراحل حداقلی، نتیجه موردانتظار و نتیجه واقعی؛
- Screenshot/Video، Console، stack trace و HAR پاک‌سازی‌شده؛
- محیط مشابهی که Pass می‌شود برای مقایسه.
عنوان خوب
به‌جای «صفحه در آیفون خراب است» بنویسید: «[iOS ۱۸.x / Safari Stable / fa-IR] پس از بازگشت از درگاه، دکمه مشاهده سفارش زیر Keyboard باقی می‌ماند». ساختار کامل و مثال‌های قابل استفاده در راهنمای گزارش باگ حرفه‌ای آمده است.
حریم خصوصی Evidence
HAR و Video ممکن است Token، شماره تماس، آدرس و داده پرداخت داشته باشند. پیش از ضمیمه‌کردن Redact کنید، دسترسی و Retention را محدود نگه دارید و از حساب مصنوعی استفاده کنید. شواهد بیشتر همیشه بهتر نیست؛ شواهد دقیق و حداقلی بهتر است.
معیارهای سنجش اثربخشی
- درصد Cohort پشتیبانی‌شده بر اساس کاربر یا درآمد، همراه با منبع و تاریخ؛
- پوشش Journeyهای حیاتی در هر Tier، نه فقط تعداد Browserها؛
- نرخ Pass/Fail/Blocked به تفکیک Product و Infrastructure؛
- زمان بازتولید نقص سازگاری و کامل‌بودن Evidence؛
- Escape به Production بر اساس بُعد جاافتاده یا Environment gap؛
- Flake و Queue time هر Lane و هزینه اجرای هر Signal؛
- تفاوت کشف روی محیط مجازی و دستگاه واقعی؛
- Usage محیط‌های در حال Deprecation و تعداد مشتری قراردادی؛
- نقص‌های ناشی از Client/Server version skew؛
- زمان از Release مرورگر/OS تا Smoke تأییدشده.
«۱۰۰٪ ترکیب‌ها Pass شدند» اگر ترکیب‌ها کم‌ریسک، Oracle ضعیف یا Artifact ناقص باشد، معنای زیادی ندارد. KPI فردی بر اساس تعداد باگ نیز رفتار نامطلوب ایجاد می‌کند.
سیاست Deprecation محیط قدیمی
- Usage، قرارداد، هزینه نگهداری و ریسک امنیتی را مستند کنید.
- مشتریان و پشتیبانی را پیش از تصمیم نهایی درگیر کنید.
- تاریخ پایان، نسخه جایگزین و مسیر ارتقا را اعلام کنید.
- Telemetry حداقلی برای سنجش مهاجرت تعریف کنید.
- در دوره گذار، Banner یا پیام قابل دسترس نشان دهید؛ کاربر را غافلگیر نکنید.
- Fallback یا Export داده را برای Journeyهای لازم بررسی کنید.
- پس از تاریخ، Matrix، مستندات، CI و SLA پشتیبانی را هم‌زمان به‌روز کنید.
UA block خام ممکن است Browser پشتیبانی‌شده را اشتباه رد کند. Capability و خطای واقعی را ترجیح دهید و تصمیم پشتیبانی را در Backend و Frontend سازگار نگه دارید.
اشتباه‌های رایج در تست سازگاری
- وعده تجربه کاملاً یکسان یا بی‌نقص در همه محیط‌ها؛
- استفاده از فهرست ثابت مرورگر و OS بدون تاریخ و قرارداد؛
- برابرگرفتن Browser Brand با Engine متن‌باز؛
- فرض اینکه Responsive mode همان دستگاه واقعی است؛
- اصرار بر دستگاه واقعی برای هر سؤال یا حذف کامل آن از Release؛
- انتخاب فقط بر اساس سهم بازار عمومی و ندیدن مشتری قراردادی؛
- اعتماد به UA sniffing به‌جای Feature Detection و Fallback؛
- اجرای کل Regression روی تمام ترکیب‌ها و ساختن Suite کند و Flaky؛
- ندیدن WebView، Keyboard، Autofill، RTL و فونت فارسی؛
- نادیده‌گرفتن API/Schema version skew در Rolling deployment؛
- پذیرفتن Visual diff به‌عنوان اثبات رفتار یا دسترس‌پذیری؛
- گزارش «روی موبایل خراب است» بدون Version، Build و Artifact؛
- ذخیره Token و PII در Video/HAR سرویس ابری؛
- حذف محیط قدیمی بدون Notice، داده و مسیر مهاجرت؛
- شمردن تعداد ترکیب‌ها به‌جای پوشش ریسک و Journey.
چک‌لیست آمادگی انتشار
- قرارداد Tierها نسخه، تاریخ بازبینی و مالک دارد.
- ماتریس از Analytics، قرارداد، Incident و معماری تغذیه شده است.
- Engine، Brand، Channel، WebView و Device در صورت نیاز تفکیک شده‌اند.
- Journeyهای درآمدی، امنیتی و داده‌ای Seed صریح دارند.
- Pairwise/Constraintها Review و Coverage آن‌ها Verify شده است.
- Feature Detection و Fallback برای قابلیت‌های اختیاری وجود دارد.
- RTL، متن بلند، ارقام، تاریخ، Timezone، Keyboard و فونت آزمایش شده‌اند.
- Screen reader/Keyboard و Performance روی ترکیب‌های هدف جداگانه سنجیده شده‌اند.
- PR، Nightly، Release و Real-device lane هدف و SLA روشن دارند.
- Visual baseline پایدار، نسخه‌دار و دارای مالک Review است.
- Client قدیمی/جدید با Backend قدیمی/جدید در Rollout بررسی شده است.
- Evidence شامل نسخه دقیق است و Secret/PII ندارد.
- شکست زیرساخت از شکست محصول در گزارش جدا می‌شود.
- Monitoring پس از انتشار و معیار بازنگری Matrix فعال است.
- سیاست Deprecation و پیام کاربر با تیم پشتیبانی هماهنگ است.
پرسش‌های متداول
تفاوت Cross-browser Testing و Compatibility Testing چیست؟
Cross-browser زیرمجموعه‌ای از سازگاری و متمرکز بر تفاوت مرورگرها و Engineهاست. Compatibility دامنه بزرگ‌تری دارد و OS، Device، Locale، WebView، شبکه، سخت‌افزار و نسخه API/Schema را نیز در صورت ارتباط پوشش می‌دهد.
آیا باید روی همه مرورگرها و دستگاه‌ها تست کنیم؟
خیر. فضای ترکیب‌ها عملاً نامحدود است. قرارداد پشتیبانی، داده کاربران، ارزش کسب‌وکاری، تاریخچه Incident و تغییر فنی را مبنا قرار دهید؛ Tier ۱ را عمیق، Tier ۲ را دوره‌ای و بقیه را طبق سیاست روشن پوشش دهید.
Playwright WebKit همان Safari واقعی است؟
اجرای WebKit سیگنال سریع و ارزشمندی درباره یک Engine می‌دهد، اما Browser Brand، OS integration، Codec، فونت، Policy و سخت‌افزار محیط واقعی را کامل بازنمایی نمی‌کند. برای Journey حیاتی Safari، اجرای محدود روی محیط واقعی هدف لازم است.
Emulator بهتر است یا دستگاه واقعی؟
هیچ‌کدام مطلقاً بهتر نیست. Emulator برای پوشش سریع نسخه‌ها، Debug و شرایط تکرارپذیر مناسب است؛ دستگاه واقعی برای Touch، سخت‌افزار، OEM، Permission، Push، Battery و عملکرد واقعی‌تر. Fidelity را بر اساس سؤال و ریسک انتخاب کنید.
هر چند وقت Compatibility Matrix را بازبینی کنیم؟
حداقل در هر چرخه برنامه‌ریزی Release و هنگام عرضه نسخه مهم Browser/OS، تغییر SDK، Incident یا تغییر قرارداد. یک بازبینی ماهانه یا فصلی ثابت مفید است، اما Triggerهای رویدادمحور را جایگزین نمی‌کند.
جمع‌بندی
تست سازگاری مسابقه جمع‌کردن دستگاه و مرورگر نیست؛ مدیریت شفاف ریسک در یک دامنه پشتیبانی‌شده است. از قرارداد Tier شروع کنید، ماتریس را با داده واقعی و تنوع فنی بسازید، Feature Detection و Fallback را در طراحی وارد کنید و برای هر سؤال Fidelity مناسب—از Component test تا دستگاه واقعی—را برگزینید. در پایان، ارزش برنامه با تعداد ترکیب‌ها سنجیده نمی‌شود؛ با این سنجیده می‌شود که سفر حیاتی در محیط‌های متعهدشده نتیجه معادل دارد، شکست قابل تشخیص و بازتولید است و تغییرات آینده بدون غافلگیری مدیریت می‌شوند.
