انتخاب ابزار تست اتوماسیون؛ مقایسه و PoC عملی

تیمی Playwright را چون «سریع و مدرن» است انتخاب می‌کند. سه ماه بعد می‌فهمد بخش مهم محصول روی اپ بومی Android است، اجرای Safari واقعی برای مشتری سازمانی لازم است، Runnerهای CI به اینترنت آزاد دسترسی ندارند و Artifactهای شکست حاوی دادهٔ مشتری‌اند. ابزار بدی انتخاب نشده؛ مسئلهٔ انتخاب ابزار تست اتوماسیون بد تعریف شده است.

هیچ ابزار جهانیِ «بهترین» وجود ندارد. انتخاب درست یعنی ابزار، سیستم تحت تست، Risk، مهارت تیم، Pipeline، محیط اجرا و اقتصاد نگهداری با هم تناسب داشته باشند. این راهنما یک روش قابل‌ممیزی می‌دهد: Must-have و Disqualifier، فهرست کوتاه، PoC واقعی، Scorecard وزنی، TCO، Decision record و Exit plan. سپس Playwright، Selenium، Cypress و Appium را بر اساس مستندات رسمی جاری مقایسه می‌کند.

مرز این مقاله: اینجا دربارهٔ انتخاب ابزار پس از روشن‌شدن هدف اتوماسیون است. اگر هنوز نمی‌دانید چه Testهایی ارزش خودکارشدن دارند، ابتدا راهنمای استراتژی اتوماسیون تست را بخوانید؛ ابزار نباید Strategy را جایگزین کند.

خلاصهٔ اجرایی انتخاب ابزار تست اتوماسیون

1. System under test و لایه را مشخص کنید: Web، Mobile، API، Contract، Desktop یا Performance.
2. پنج تا ده Must-have قابل‌آزمون و چند Disqualifier بنویسید.
3. محدودیت تیم، CI، شبکه، داده، مجوز و پشتیبانی را ثبت کنید.
4. حداکثر سه گزینه را با مستندات رسمی Shortlist کنید.
5. PoC را روی Journey پرریسک و Failureهای واقعی اجرا کنید، نه Todo demo.
6. Gateهای غیرقابل‌مذاکره را جدا از Score وزنی بسنجید.
7. TCO سه‌ساله را شامل ساخت، اجرا، نگهداری، Infra و مهاجرت محاسبه کنید.
8. Decision، فرض‌ها، نسخه، Owner، Revisit trigger و Exit plan را ثبت کنید.
9. با Pilot کوچک Scale/Refactor/Stop را بر اساس Signal تصمیم بگیرید.

نیاز غالب	Shortlist اولیه، نه حکم نهایی	هشدار
Web E2E جدید با TS/JS و Debug artifact قوی	Playwright، Cypress	Journeyهای cross-origin/multi-page و CI خود را PoC کنید
WebDriver استاندارد، اکوسیستم چندزبان یا Grid موجود	Selenium	Runner/assertion/reporting و معماری Framework را خودتان انتخاب می‌کنید
Web E2E/Component در اکوسیستم JS/TS	Cypress	Execution model و WebKit آزمایشی را با نیاز واقعی بسنجید
Native/Hybrid Android یا iOS	Appium + Driver مناسب	OS، SDK، Driver، Device و App lifecycle بخش اصلی هزینه‌اند
API یا Contract	Runner زبان تیم، API client، Contract tool	UI tool را فقط برای API انتخاب نکنید
Load/Performance	ابزار اختصاصی Performance	Functional browser runner جای Load generator نیست

این جدول فقط نقطهٔ شروع است. نسخه، قابلیت و قیمت ابزارها تغییر می‌کند؛ پیش از خرید یا Standardization، صفحهٔ رسمی Release/Compatibility و مجوز همان تاریخ را دوباره بررسی کنید.

اول اصطلاح «ابزار تست» را دقیق کنید

تیم‌ها گاهی Library، Runner، Framework، Grid، Cloud service و Test management را یک چیز می‌نامند. یک Stack ممکن است چند جزء داشته باشد:

• Automation library/driver: کنترل Browser، Device یا API؛
• Test runner: کشف، اجرا، Parallelism، Retry و Lifecycle؛
• Assertion library: مقایسهٔ Expected/Actual؛
• Fixture/data/environment layer: ساخت داده و ایزوله‌سازی؛
• Reporting/debug artifact: Log، Trace، Screenshot، Video و Result؛
• Execution infrastructure: Local، Container، Grid، Device lab یا SaaS؛
• CI orchestration: Trigger، Shard، Cache، Secret و Artifact retention؛
• Test management: Traceability، planning و result aggregation.

مثلاً Selenium WebDriver Runner یا گزارش‌ساز کامل تجویز نمی‌کند؛ Playwright Test در Node.js بخش‌های بیشتری را یکپارچه می‌آورد؛ و Appium Core بدون Driver هدف قابل‌استفاده نیست. مقایسه باید «Stack نهایی» را بسنجد، نه فقط نام Package.

گام صفر: آیا اصلاً این Test باید خودکار شود؟

ابزار مناسب، Test نامناسب را ارزشمند نمی‌کند. Candidate خوب معمولاً تکرارپذیر، دارای Oracle معتبر، ورودی/محیط کنترل‌پذیر و Feedback موردنیاز در زمان تصمیم است. Candidate ضعیف ممکن است یک‌بارمصرف، دائماً درحال‌تغییر، فاقد Expected یا ارزان‌تر از نگهداری Automation باشد.

برای هر Candidate بپرسید:

• کدام تصمیم را زودتر یا مطمئن‌تر می‌کند؟
• اگر Failure دهد، چه کسی و در چه زمانی اقدام می‌کند؟
• آیا Test در Unit/API/Contract ارزان‌تر از UI است؟
• داده و Dependency قابل‌کنترل‌اند؟
• تکرار و طول عمر آن هزینهٔ ساخت را توجیه می‌کند؟
• آیا Exploratory/manual evidence هنوز لازم است؟

گام اول: سیستم تحت تست و لایه را Inventory کنید

بعد	سوال انتخاب	نمونه Evidence
Interface	Browser، native app، API، message، desktop؟	Architecture/context diagram
Platform	OS/browser/device و نسخه‌های واقعاً پشتیبانی‌شده؟	Production analytics + support policy
Journey	Critical flow، multi-tab، popup، upload، download، OTP؟	Risk/Journey map
Integration	SSO، PSP، queue، email/SMS، third party؟	Dependency inventory
Data	Tenant، PII، seed، cleanup، parallel isolation؟	Data contract
Environment	Local/CI، proxy، air-gapped، container، device lab؟	Execution topology
Decision time	PR، merge، nightly، pre-release یا production؟	Pipeline map
Scale	تعداد Test، duration، concurrency و frequency؟	Load estimate

اگر محصول API-heavy است، پوشاندن همه‌چیز از UI کند و شکننده می‌شود. راهنمای تست API برای Contract، Schema، Authentication و Negative case کمک می‌کند؛ در معماری سرویس‌گرا نیز استراتژی تست میکروسرویس‌ها مرز Component، Contract، Integration و E2E را روشن می‌کند.

گام دوم: Must-have، Preference و Disqualifier

Must-have را قابل‌آزمون بنویسید

«Cross-browser باشد» مبهم است. نسخهٔ قابل‌آزمون:

Candidate باید Checkout را در Chrome Stable، Firefox ESR و Safari واقعیِ نسخه‌های تعریف‌شده در Support policy اجرا کند؛ Result شامل Video/Trace امن باشد؛ و ۲۰ Scenario در Runner لینوکسی CI حداکثر در Budget مصوب پایان یابد.

Must-have نمونه:

• پشتیبانی از Platform/Browser/Device دقیق؛
• اجرا در OS و Runner موجود؛
• زبان/Runtime قابل‌پشتیبانی تیم؛
• Parallel isolation و Data namespace؛
• Artifact کافی برای Triage؛
• Secret redaction و Retention کنترل‌پذیر؛
• Offline/private registry یا Proxy compatibility؛
• مجوز و استفادهٔ تجاری قابل‌قبول؛
• Fallback در صورت قطع Vendor/Cloud.

Disqualifier قبل از Demo

• عدم اجرای Browser/Device اجباری؛
• ارسال PII/Source/Artifact به Cloud غیرمجاز؛
• وابستگی به پرداخت یا سرویس غیرقابل‌دسترسی؛
• عدم امکان Pin کردن Version/Dependency؛
• نبود API/CLI قابل‌اعتماد برای CI؛
• عدم تطابق License با سیاست سازمان؛
• عدم امکان Export Test/Result و Lock-in غیرقابل‌قبول.

Gateها را با Score جمع نکنید. ابزاری که Safari واقعیِ الزامی را اجرا نمی‌کند نباید با UI زیباتر امتیاز کمبود را جبران کند.

گام سوم: محدودیت تیم و عملیات را وارد تصمیم کنید

زبان محصول با زبان Automation یکی نیست

اگر Backend با Java نوشته شده، الزاماً Selenium/Java بهترین نیست؛ Test E2E از Interface عمومی استفاده می‌کند. انتخاب زبان باید مهارت مالک واقعی Suite، Library ecosystem، Hiring، Debug و همکاری با تیم محصول را بسنجد. نزدیکی Typeها یا Componentها می‌تواند مزیت باشد، اما قانون مطلق نیست.

مالکیت

• چه کسی Framework core را نگهداری می‌کند؟
• چه کسی Test محصول می‌نویسد و Review می‌کند؟
• Failure محصول، Test، Infra و Data چگونه Route می‌شود؟
• Upgrade ابزار/Browser/Driver در چه Cadence و با چه Gate انجام می‌شود؟
• اگر متخصص فعلی برود، چند نفر توان تغییر Suite را دارند؟

زمان Feedback

ابزار باید با زمان تصمیم هماهنگ باشد. Test ده‌دقیقه‌ای ممکن است برای PR دیر و برای Nightly عالی باشد. طراحی Lane، Sharding، Retry و Quarantine را در راهنمای Continuous Testing در CI/CD ببینید.

مقایسهٔ Playwright، Selenium و Cypress برای تست Web

Playwright

مستندات رسمی زبان‌های Playwright JavaScript/TypeScript، Python، Java و .NET را پوشش می‌دهد، اما Integration اکوسیستم تست در هر زبان یکسان نیست. در Node.js، Playwright Test امکانات Runner مانند Parallelism، Screenshot assertion، HTML report و Trace را یکجا ارائه می‌کند؛ در Java/Python/.NET معمولاً Runner متناسب همان اکوسیستم انتخاب می‌شود.

برای Shortlist مناسب است وقتی:

• Browser automation جدید با Isolation و Artifact تشخیصی قوی می‌خواهید؛
• چند Context/Page، Network control، upload/download و Web flow مدرن دارید؛
• تیم از Locator و Auto-wait به‌جای Sleep استفاده می‌کند؛
• توان Pin/Install کردن Browser binary متناسب با نسخه ابزار در CI را دارید.

Playwright Actionability بررسی‌هایی مانند Visible، Stable، Receives Events و Enabled و Assertionهای auto-retrying را مستند می‌کند. این قابلیت Flakiness را جادویی حذف نمی‌کند؛ دادهٔ مشترک، Environment ناپایدار، Selector بد و Assertion مبهم همچنان Failure می‌سازند.

در PoC حتماً بسنجید: مرورگر واقعی موردنیاز در برابر Engine bundled، مصرف Container، نصب Dependency در شبکه ایران، SSO/extension، multi-domain، Trace size و سازگاری Runner زبان انتخابی. WebKit bundled را خودکار با Safari برندشده و نسخهٔ کاربر یکی ندانید.

Selenium WebDriver

Selenium WebDriver پیاده‌سازی‌ها و Language bindingهای کنترل Browser را حول استاندارد W3C WebDriver فراهم می‌کند. اکوسیستم بالغ، چندزبان، مرورگرهای برندشده و امکان Grid/Providerهای متعدد آن را برای سازمان‌هایی با زیرساخت یا Suite موجود جذاب می‌کند.

برای Shortlist مناسب است وقتی:

• پوشش مرورگر/زبان متنوع و WebDriver compatibility شرط است؛
• Grid یا Device/browser provider موجود دارید؛
• Framework سازمانی، Runner، Assertion و Reporting از قبل استاندارد شده‌اند؛
• مهاجرت تدریجی و سرمایهٔ Suite فعلی مهم است.

هزینه/ریسک قابل‌سنجش: Selenium یک Framework کامل تجویزی نیست؛ Wait، Locator، Fixture، Parallelism، Result و معماری باید درست طراحی شوند. ادعای «مدیریت ضعیف عناصر پویا» دقیق نیست؛ کیفیت synchronization و locator در Suite تعیین‌کننده است. Driver/browser compatibility، Grid operations و Artifact debugging را در PoC واقعی اندازه بگیرید.

Cypress

مستندات رسمی Browserهای Cypress در زمان این بازبینی Chrome-family، Firefox و WebKit آزمایشی را ذکر می‌کند. بنابراین عبارت قدیمی «فقط Chromium» درست نیست؛ در عین حال Experimental بودن WebKit باید در Gate لحاظ شود. Cypress برای Testهای Web در اکوسیستم JavaScript/TypeScript، UI تعاملی و E2E/Component گزینهٔ Shortlist است.

برای Shortlist مناسب است وقتی:

• تیم JS/TS است و تجربهٔ Developer-centric محلی می‌خواهد؛
• Component و E2E در یک اکوسیستم ارزش دارد؛
• Network stubbing و Command log برای Debug مهم‌اند؛
• Execution model آن با Journey محصول سازگار است.

در PoC حتماً بسنجید: cross-origin، multi-tab/window، iframe، SSO، download/upload، Browser matrix، CI parallelism، Artifact/Cloud policy و cost. Retry-ability رسمی Cypress تفاوت Query/Assertion قابل‌Retry و Action غیرقابل‌تکرار را توضیح می‌دهد؛ استفادهٔ نادرست از Chain یا Retry می‌تواند رفتار محصول را پنهان کند.

جدول تصمیم Web

معیار	Playwright	Selenium	Cypress
دامنهٔ اصلی	Browser automation/E2E	WebDriver browser automation	Web E2E/Component
زبان	JS/TS، Python، Java، .NET؛ ecosystem متفاوت	Bindingهای چندزبان	JavaScript/TypeScript
Runner	Node runner یکپارچه؛ در زبان‌های دیگر Runner اکوسیستم	Runner را تیم انتخاب می‌کند	Runner و UI خودش
Browser	Chromium/Firefox/WebKit و Channelها؛ نسخه را verify کنید	Browser/vendor driver؛ نسخه را verify کنید	Chrome-family/Firefox؛ WebKit آزمایشی در بازبینی فعلی
مزیت بالقوه	Isolation، auto-wait، trace و multi-page	استاندارد، انعطاف و سرمایهٔ اکوسیستم	Developer UX، retry model و component testing
ریسک PoC	Binary/dependency، engine≠branded browser، ecosystem زبان	Framework assembly، Grid/driver ops، debug artifacts	Execution model، browser requirement، Cloud/parallel policy

این جدول Winner اعلام نمی‌کند؛ مشخص می‌کند کدام فرض را باید با PoC رد یا تأیید کنید.

Appium برای موبایل: Driver را انتخاب می‌کنید، نه فقط نام Appium

مستندات رسمی Appium معماری را به Core، Driver، Client و Plugin تقسیم می‌کند. برای شروع باید Driver پلتفرم هدف و Client زبان را نصب کنید. UiAutomator2 برای Android و XCUITest برای iOS نمونه‌های رایج‌اند، اما نسخهٔ Driver/SDK/OS و Maintainer باید در لحظهٔ تصمیم بررسی شود.

PoC موبایل باید این موارد را روی Emulator/Simulator و حداقل Device واقعی نماینده بسنجد:

• Native، Hybrid و WebView switching؛
• Permission، notification، deep link و background/foreground؛
• Keyboard فارسی، RTL، locale و timezone؛
• Camera/file/biometric با راهکار مجاز؛
• Network change، offline/reconnect و interruption؛
• App install/reset، test data و parallel device isolation؛
• Screenshot/page source/log و Triage failure؛
• OS/SDK upgrade و زمان نگهداری Driver capability.

مرورگر دسکتاپ را Proxy خوبی برای تجربهٔ Native ندانید. راهنمای تست اپلیکیشن موبایل ماتریس Device/OS، Network، permission و lifecycle را کامل‌تر می‌کند.

برای API، Performance، Security و System Test ابزار جدا می‌خواهید

API و Contract

Runner زبان تیم با HTTP client و Schema assertion ممکن است ساده‌تر و پایدارتر از ابزار UI باشد. اگر Consumer/Provider مستقل Deploy می‌شوند، Contract testing را هم ارزیابی کنید. Tool باید Authentication، environment/secret، data setup، parallelism و machine-readable result داشته باشد.

Performance

Browser E2E برای چند Journey و RUM-like measurement مفید است، اما Load generator نیست. Model بار، workload، percentile، coordinated omission، resource metric و safe stop به ابزار اختصاصی نیاز دارد. معیار انتخاب را با برنامه تست عملکرد هماهنگ کنید.

Security

اسکنر یا DAST را «اتوماسیون امنیت کامل» ننامید. Authorization، business logic، threat model و manual investigation باقی می‌مانند. Tool باید Scope، rate limit، authentication، safe mode، evidence redaction و handling یافته‌ها را پشتیبانی کند؛ راهنمای تست امنیت نرم‌افزار مرز روش‌ها را توضیح می‌دهد.

System-level Journey

ممکن است یک Suite Web، API، message و database evidence را هماهنگ کند. ابزار UI نباید تمام Assertionها را از سطح UI انجام دهد. راهنمای System Testing برای طراحی Journey و Oracle کل سیستم مفید است.

ابزار Open-source واقعاً رایگان نیست

License fee ممکن است صفر باشد؛ Total Cost of Ownership صفر نیست. TCO را برای Horizon مشخص—مثلاً سه سال—مدل کنید:

TCO = evaluation + onboarding + framework + test authoring + CI/device/browser infra + execution + triage + maintenance + upgrades + support + security/compliance + migration/exit

هزینه	سوال Evidence
ساخت	برای اولین ۲۰ Test پایدار چند نفر-روز؟
اجرا	Runner minute، device، storage و network چقدر؟
نگهداری	در ۱۰ تغییر UI چه درصد Test و چند ساعت تغییر کرد؟
Triage	از Failure تا طبقه‌بندی Product/Test/Infra چقدر؟
Upgrade	Browser/driver/runtime update چه Failure و effort دارد؟
People	Training، hiring و bus factor چیست؟
Commercial	License، seat/concurrency، support و افزایش قیمت؟
Exit	Export، rewrite، parallel run و archive evidence؟

Record/Playback هزینهٔ Demo را کم می‌کند، اما لزوماً Design، Oracle، data isolation و نگهداری را حل نمی‌کند. در PoC یک Flow ضبط‌شده را پس از تغییر واقعی UI نگهداری کنید و effort را اندازه بگیرید.

PoC درست: Demo ابزار را با محصول خودتان جایگزین کنید

نمونهٔ PoC فروشگاه ایرانی

برای Checkout وب، ۱۰ تا ۲۰ Scenario نماینده انتخاب کنید:

• ورود، Session expiry و SSO/OTP در محیط مجاز؛
• سبد، Coupon و محاسبهٔ ریال/تومان؛
• آدرس فارسی، نیم‌فاصله، موبایل ۰۹/+۹۸ و کدپستی؛
• Redirect به Sandbox درگاه و بازگشت success/cancel/timeout؛
• Popup/multi-tab یا cross-origin واقعی؛
• File upload/download یا invoice، اگر در Scope است؛
• Network delay/failure و Retry بدون اثر تکراری؛
• Parallel کاربران با دادهٔ Namespaceدار؛
• Screenshot/Trace/Log Failure با Redaction؛
• اجرای Chrome/Firefox/Target واقعی Support policy.

سناریوی نگهداری اجباری

پس از سبزشدن، تغییر نماینده ایجاد کنید: Selector قابل‌دسترسی، API response، متن فارسی، route یا component refactor. سپس اندازه بگیرید چند Test شکست، علت چه بود و Fix چه‌قدر طول کشید. ابزار فقط در روز ساخت انتخاب نمی‌شود؛ در روز تغییر ارزش یا بدهی می‌سازد.

Failure injection

• Browser binary یا Driver ناسازگار؛
• CI runner بدون Cache/Internet؛
• Dependency timeout و API ۵۰۰؛
• Test data collision در Parallel؛
• Secret اشتباه یا Expired؛
• Artifact storage unavailable؛
• Flaky network و delayed rendering؛
• Test process kill و rerun/recovery.

اگر PoC فقط Happy path روی Laptop نویسنده باشد، Tool UX را سنجیده‌اید، نه Production readiness آن را.

Scorecard وزنی با Gate جدا

وزن‌ها را پیش از اجرای PoC و با حضور QA، Developer، Platform/SRE، Security و Product تعیین کنید. نمونه:

معیار	وزن نمونه	روش اندازه‌گیری
پوشش SUT/Platform	۲۰	Pass Must-have matrix
Stability/Isolation	۱۵	۳۰ اجرای تکراری + parallel collision
Maintainability	۱۵	Change exercise و review complexity
Debug/Triage	۱۰	زمان تشخیص Failure تزریق‌شده
CI/Scale	۱۰	duration، shard، resource، cache
Team fit	۱۰	زمان onboarding و code review
Security/Compliance	۱۰	data flow، secret، SBOM/license، retention
TCO/Exit	۱۰	مدل هزینه و migration spike

Weighted score = Σ(score 0..5 × weight) / 5. عدد فقط گفت‌وگو را منظم می‌کند. تفاوت ۸۲ و ۸۰ بدون کیفیت Evidence معنی قطعی ندارد. Sensitivity analysis انجام دهید: اگر وزن CI یا Browser coverage تغییر کند Winner عوض می‌شود؟

قانون تصمیم

• هر Disqualifier = Reject، حتی Score بالا؛
• Evidence ناقص = Unknown، نه امتیاز متوسط ساختگی؛
• اختلاف ارزیاب‌ها = بحث دربارهٔ معیار/شواهد؛
• Winner فقط پس از TCO و Exit review؛
• Approval با Owner و Revisit date.

امنیت و زنجیرهٔ تأمین ابزار تست

Automation به Credential، دادهٔ Test و گاهی Production-like environment دسترسی دارد؛ پس خود ابزار بخشی از Attack surface است:

• Package/Plugin/Container را Pin، Scan و از Registry مجاز دریافت کنید.
• Checksum/signature و provenance موجود را بررسی کنید.
• Runner را با least privilege و network policy محدود کنید.
• Secret را از Vault/CI secret بگیرید؛ در config، screenshot یا trace ننویسید.
• Artifact را Redact، رمزگذاری و با Retention محدود نگه دارید.
• PRهای Fork و اجرای کد غیرقابل‌اعتماد را از Secret جدا کنید.
• Cloud vendor data flow، region، subprocessor و deletion را بررسی کنید.
• Plugin/extension کم‌نگهداری‌شده را بدون Threat review وارد Stack نکنید.

محدودیت‌های تیم‌های ایرانی را Gate کنید

• دسترسی: نصب Browser/Driver/Package از Runner داخل ایران و پشت Proxy را واقعاً امتحان کنید.
• تحریم و Account: احتمال بسته‌شدن SaaS، Device cloud یا Payment path را با قرارداد و Plan B بسنجید.
• Self-host: مشخص کنید کدام قابلیت بدون Cloud و Login کار می‌کند.
• License/payment: خرید، تمدید، نرخ ارز و پشتیبانی را با واحد حقوقی/تدارکات تأیید کنید.
• Data residency: Screenshot، Video، Trace، Source و PII به کجا می‌روند؟
• Browser cache: Mirror/cache داخلی برای Binaryها و Dependencyهای مجاز طراحی کنید.
• Device lab: دسترسی فیزیکی/Remote، نگهداری OS و ظرفیت Parallel را هزینه کنید.
• Locale: فارسی/RTL، تقویم، ریال/تومان و فونت را در PoC بگذارید.
• Support: پاسخ Vendor/Community را از داخل شبکه و با Account سازمانی بیازمایید.

دورزدن کنترل دسترسی یا شرایط سرویس Strategy محسوب نمی‌شود. اگر دسترسی پایدار و مجاز نیست، Candidate باید Fail یا با معماری جایگزین مستند شود.

Decision record و Exit plan قابل‌کپی

Decision ID/date/owners: …
Automation outcome: …
SUT/layers/platform matrix: …
Must-have/disqualifiers: …
Candidates + versions: …
PoC repository/build/environment: …
Scorecard/evidence: …
TCO horizon/assumptions: …
Security/privacy/license review: …
Selected stack and why: …
Rejected options and why: …
Known limitations/workarounds: …
Owner/upgrade cadence: …
Exit/export/migration path: …
Revisit triggers/date: …

Revisit trigger

• Browser/OS/Platform جدید وارد Support policy شود؛
• p95 Feedback از Budget عبور کند؛
• Flake/quarantine یا maintenance effort از سقف بگذرد؛
• Vendor pricing/license/data policy تغییر کند؛
• Dependency EOL یا Security issue بدون Fix بماند؛
• مالکیت/مهارت تیم تغییر معنادار کند؛
• محدودیت دسترسی ایران یا CI عوض شود.

Revisit به معنی تعویض فوری نیست. اول Evidence را بازبینی و Scale/Refactor/Migrate/Stop را مقایسه کنید.

برنامهٔ ۳۰روزه انتخاب و Pilot

روز ۱ تا ۵: Discovery

• Outcome، SUT، Risk، platform matrix و Decision time را بنویسید.
• مالک، Budget، Must-have، Disqualifier و TCO horizon را توافق کنید.
• Stack فعلی، مهارت، CI، network و data restriction را Inventory کنید.

روز ۶ تا ۱۰: Shortlist

• مستندات رسمی، Release cadence، License و support path را بررسی کنید.
• حداکثر سه Candidate و نسخهٔ دقیق را Pin کنید.
• PoC scenarios، Failure injection و Scorecard را قبل از اجرا قفل کنید.

روز ۱۱ تا ۲۰: PoC

• Journey واقعی، parallel data، CI و target browser/device را اجرا کنید.
• زمان authoring، run، triage و change exercise را ثبت کنید.
• Security/data flow و offline/proxy/vendor fallback را بیازمایید.

روز ۲۱ تا ۲۵: تصمیم

• Gate، score، TCO و sensitivity را مرور کنید.
• Unknownها و اختلاف ارزیاب‌ها را ثبت کنید.
• Decision record، owner، limitation و exit plan را Approve کنید.

روز ۲۶ تا ۳۰: Pilot عملیاتی

• ۱۰ تا ۲۰ Test باارزش را در Lane واقعی وارد کنید.
• Failure routing، rerun، quarantine و artifact retention را فعال کنید.
• Baseline signal، duration، flake و maintenance را ثبت کنید.
• Scale/Refactor/Stop criteria و بازبینی ۳۰/۶۰/۹۰روزه تعیین کنید.

اشتباه‌های رایج در انتخاب ابزار اتوماسیون

• انتخاب با محبوبیت: مسئله و Constraint تیم حذف می‌شود.
• یک ابزار برای همهٔ لایه‌ها: UI runner به API/load/security تحمیل می‌شود.
• زبان محصول = زبان تست: مالکیت و اکوسیستم واقعی نادیده می‌ماند.
• Open-source = رایگان: Infra، نگهداری و Triage حساب نمی‌شوند.
• Demo happy path: CI، data، failure و change سنجیده نمی‌شوند.
• Score بدون Gate: کمبود اجباری با امتیاز UX جبران می‌شود.
• Feature checklist: قابلیت موجود با قابلیت پایدار/قابل‌استفاده یکی فرض می‌شود.
• Record/Playback = maintainability: Design و Oracle پنهان می‌مانند.
• Retry تا سبز: Defect محصول و Test/Infra flake مخفی می‌شود.
• WebKit = Safari دقیق: Engine bundled با Browser واقعی یکی گرفته می‌شود.
• Appium = پشتیبانی جادویی همه‌چیز: Driver و OS toolchain فراموش می‌شود.
• Vendor lock-in بدون Exit: داده، Test و Result قابل انتقال نیستند.
• نادیده‌گرفتن ایران: ابزار پس از خرید از CI یا شبکه قابل‌دسترسی نیست.
• بدون Owner: Framework پس از Champion اولیه رها می‌شود.

چک‌لیست نهایی انتخاب ابزار تست اتوماسیون

• Outcome اتوماسیون و Decision time روشن است.
• نوع SUT، لایه و Platform/version matrix ثبت شده‌اند.
• Must-have قابل‌آزمون و Disqualifier جدا هستند.
• زبان/مهارت/مالکیت/Bus factor تیم سنجیده شده‌اند.
• CI، Network، Proxy، Cache و Runner واقعی در Scope است.
• Test data، parallel isolation و cleanup طراحی شده‌اند.
• Candidateها و Version دقیق از مستندات رسمی بررسی شده‌اند.
• PoC Journey واقعی، Failure injection و Change exercise دارد.
• Browser/Device واقعی Support policy آزموده شده است.
• زمان authoring/run/triage/maintenance اندازه‌گیری شده است.
• Artifact برای Debug کافی و برای Privacy امن است.
• License، supply chain، secret و vendor data flow Review شده‌اند.
• محدودیت دسترسی/پرداخت/Cloud ایران Gate شده است.
• TCO شامل Exit و مهاجرت است.
• Scorecard وزن ازپیش‌توافق‌شده و Gate مستقل دارد.
• Decision record، Owner، limitation و Revisit trigger ثبت شده‌اند.
• Pilot معیار Scale/Refactor/Stop دارد.

سوالات متداول انتخاب ابزار تست اتوماسیون

Playwright بهتر است یا Selenium؟

به Context بستگی دارد. Playwright برای Browser automation جدید، Isolation، auto-wait و Trace یکپارچه گزینهٔ قوی Shortlist است؛ Selenium برای WebDriver استاندارد، اکوسیستم چندزبان، مرورگر/زیرساخت موجود و مهاجرت تدریجی مزیت دارد. Must-have و PoC روی Browser/CI/Journey واقعی باید تصمیم بگیرد.

Playwright بهتر است یا Cypress؟

هر دو برای Web ارزش بررسی دارند. Playwright اکوسیستم‌های زبان بیشتر و مدل مناسب multi-page/browser context دارد؛ Cypress تجربهٔ JS/TS، Component/E2E و retry model خودش را ارائه می‌کند. cross-origin، multi-tab، Browser matrix، CI، Debug artifact و Cloud policy محصول خود را PoC کنید.

برای تیم بدون تجربهٔ کدنویسی ابزار Record/Playback انتخاب کنیم؟

می‌تواند برای Prototype یا مشارکت محدود مفید باشد، اما نگهداری، data setup، Oracle، version control، review و CI را حذف نمی‌کند. یک تغییر واقعی UI را در PoC اعمال، زمان Fix را اندازه و مشخص کنید چه کسی پس از شش ماه Suite را مالک است.

آیا یک ابزار می‌تواند Web، Mobile، API و Performance را پوشش دهد؟

ممکن است یک Vendor چند Module داشته باشد، اما «وجود Feature» به معنی تناسب همهٔ لایه‌ها نیست. معمولاً Stack کوچک از ابزارهای تخصصی با Contract مشترک Result/Data پایدارتر است. پیچیدگی Integration را نیز در TCO حساب کنید.

PoC انتخاب ابزار چند Test لازم دارد؟

عدد جهانی ندارد. ۱۰ تا ۲۰ Scenario نماینده معمولاً برای یک Pilot کوچک شروع معقولی است، به شرط آنکه Happy path، Failure، Parallel data، Browser/Device اجباری، CI، Artifact و Change exercise را پوشش دهد. تنوع Risk مهم‌تر از تعداد خام است.

منابع و یادداشت بازبینی

قابلیت‌های Playwright با مستندات رسمی Languages/Actionability؛ Selenium با WebDriver و Browser documentation؛ Cypress با Launching Browsers و Retry-ability؛ و Appium با معماری Core/Driver/Client/Plugin تطبیق داده شده‌اند. آخرین بازبینی محتوایی: ۱۵ مرداد ۱۴۰۵. نسخه، Browser support، Driver، License، قیمت و محدودیت سرویس ممکن است تغییر کنند؛ پیش از Standardization یا خرید، نسخهٔ دقیق و قرارداد روز را دوباره Verify کنید.

جمع‌بندی: ابزار را از روی شهرت، Demo یا جدول Feature انتخاب نکنید. SUT و Decision را تعریف کنید، Gateهای غیرقابل‌مذاکره را بنویسید، سه Candidate را روی Journey واقعی بشکنید، هزینهٔ تغییر و Triage را بسنجید و Exit plan داشته باشید. انتخاب خوب یک نام نیست؛ یک تصمیم مستند با Evidence و امکان بازنگری است.