دو تیم یک جریان Checkout را خودکار میکنند. تیم Selenium آن را در ۴۵ ثانیه و تیم Cypress در ۲۸ ثانیه اجرا میکند. آیا Cypress برنده است؟ هنوز نه. اولی سه مرورگر و دو Role را اجرا کرده، دومی فقط یک مرورگر و یک Happy path؛ اولی Evidence شکست را محلی نگه داشته، دومی Run را در Cloud ضبط کرده؛ و هیچکدام Fault عمدی «Callback تکراری» را نمیگیرند. عدد زمان بدون Workload و Oracle همسان، مقایسه نیست.
این راهنما رقابت برندها یا پیشبینی حقوق نیست. یک Selenium–Cypress Matched Trial میسازد: همان Role، Journey، Browser/OS، Build، Data، State، Network profile، Fault، repetition و Change را در دو Candidate اجرا میکنید؛ سپس Fit، Setup، Diagnosis، CI، Flake، Maintenance، Handoff، TCO و محدودیت ایران را با Evidence مقایسه و تصمیم ADOPT/LIMIT/KEEP/MIGRATE/INCONCLUSIVE ثبت میکنید.
پاسخ کوتاه: Selenium بهتر است یا Cypress؟
برای همهٔ تیمها برندهٔ مطلق وجود ندارد. Selenium WebDriver وقتی زبان/اکوسیستم تیم، مرورگر/پلتفرم گسترده، کنترل چند Window یا Grid و interoperability مهم است Candidate قوی است. Cypress وقتی E2E/Component وب، JavaScript/TypeScript، feedback تعاملی، network control و debugging داخل مرورگر با Workflow تیم همخوان است Candidate جدی است. اما قابلیت روی کاغذ باید در PoC نماینده و Handoff واقعی تأیید شود.
| تصمیم اشتباه | جایگزین قابلسنجش |
|---|---|
| «Selenium شغل بیشتر دارد» | نمونهٔ تاریخدار آگهی با Role/Task/Stack/Level/شهر و dedup |
| «Cypress سریعتر است» | Workload/Browser/CI/resource/repeat همسان و distribution |
| «Selenium Flaky است» | Fault mechanism و first-attempt flake در Suite همسان |
| «Cypress آسانتر است» | زمان تا first signal، diagnosis، change و handoff برای تیم واقعی |
| «ابزار X حقوق را بالا میبرد» | Role/Level/Location/Contract/Capability/Offer؛ ابزار فقط یک attribute |
مرز این مقاله با انتخاب ابزار عمومی و مسیر یادگیری
راهنمای انتخاب ابزار تست اتوماسیون مالک shortlist و PoC میان Selenium، Cypress، Playwright، Appium و گزینههای دیگر است؛ انتخاب Framework اتوماسیون معماری و TCO فریمورک را پوشش میدهد؛ نقشهٔ شروع اتوماسیون برای یادگیری اولیه است. این صفحه فقط Trial دو Candidate Selenium/Cypress را عمیق میکند.
اول Decision Contract، بعد نصب ابزار
TOOL DECISION CONTRACT decision_id: SCMT-SYN-042 as_of: 2026-08-14 decision: choose a primary web UI automation candidate for one bounded team stakeholders: product / QA / frontend / platform / security decision_owner / reviewers: target_role / tasks / work products: product/browser/user/support matrix: top risks / evidence needs: must-haves / hard stops: trial budget / due_at: options: Selenium / Cypress / hybrid / neither not_claimed: hiring, salary, career security, total product quality
«ابزار آیندهساز» Decision نیست. شاید تصمیم واقعی حفظ Suite موجود، افزودن Cypress برای Component tests، مهاجرت یک Journey، یا رد هر دو به نفع Candidate دیگری باشد. Authority را روشن کنید؛ نویسندهٔ PoC نباید بهتنهایی خرید Cloud، مهاجرت Repository یا حذف Suite را تصویب کند.
Task و Risk را پیش از Scorecard بنویسید
ابزار برای Task انتخاب میشود: E2E وب، Component، cross-browser، SSO/cross-origin، multi-window، دانلود/آپلود، network interception، visual evidence، Grid/parallel CI یا collaboration؟ Risk نیز مشخص کند کدام Failure باید کشف شود: state غلط، unauthorized view، double submit، race، localization، browser incompatibility یا flaky signal.
TRIAL JOURNEY CONTRACT journey_id: SYN-CHECKOUT-WEB-07 actor/role: synthetic customer tenant-17 steps: login → cart → checkout → callback status → receipt critical claims: one order; one ledger effect; correct 1,250,000 IRR browsers: exact risk-based matrix origins/windows/iframes/downloads: data/state/setup/cleanup: faults: delayed render, stale locator, duplicate callback, wrong currency evidence: screenshot/DOM/network/trace/state refs forbidden: production, real PSP/card/user/account not_claimed:
Hard Gate را از امتیاز وزنی جدا کنید
| Hard Gate | مثال | قاعده |
|---|---|---|
| Browser/Platform | Safari واقعی یا browser مشخص قرارداد | نبود قابلیت با سرعت جبران نمیشود |
| Workflow | دو Browser همزمان یا cross-origin/iframe خاص | Probe نماینده؛ PASS/HOLD/STOP |
| Language/Repository | Stack مجاز و reviewable تیم | Skill/ownership باید واقعی باشد |
| Security/Data | Secret/PII/Cloud boundary | نقض policy = STOP |
| CI/Offline | Runner در شبکه و registry تیم | clean install/run اجباری |
| Evidence/Handoff | Receiver میتواند Failure را تشخیص دهد | نبود = HOLD |
بعد از پاس همهٔ Gateها میتوان criteria مانند developer experience، execution duration، diagnosis effort، maintenance effort و cost را وزن داد. میانگین امتیاز نباید یک Hard Stop را پنهان کند.
Selenium چیست؟ Claim رسمی و مرز آن
مستندات رسمی Selenium WebDriver آن را API/Protocol زبانخنثی برای کنترل Browserهای اصلی از طریق Driverهای پیادهسازیشده برای هر Browser معرفی میکند. Bindingهای زبان و اکوسیستم runner/library به تیم آزادی میدهند، اما خود Selenium معماری Test، Oracle، Report، Data، CI یا نگهداری را برای شما کامل نمیکند.
Setup سلنیوم دیگر فقط Driver دستی نیست
Selenium Manager از نسخههای مدرن مدیریت Driver و در برخی مسیرها Browser را تسهیل میکند و Bindingها وقتی Driver مناسب موجود نیست آن را فراخوانی میکنند. بنابراین «راهاندازی همیشه کابوس و Driver کاملاً دستی» ادعای منقضی است. بااینحال download/cache/proxy/mirror/version/pinning و شبکهٔ CI ایران باید در clean install آزموده شود.
Selenium خودبهخود کند یا Flaky نیست
Duration به Browser startup، Grid/network، locator، wait، App، data، screenshots، parallelism و scope بستگی دارد. مستندات رسمی Waiting Strategies race میان وضعیت App و command را علت رایج Flake میداند و دربارهٔ ترکیب implicit/explicit wait هشدار میدهد. sleep ثابت یا locator شکننده مشکل طراحی است، نه حکم ذاتی یک برند.
Cypress چیست؟ Claim رسمی و مرز آن
Cypress برای E2E و Component testing برنامههای وب طراحی شده و command log، snapshot/debugging، automatic retry-ability و network stubbing را ارائه میکند. App محلی بدون حساب Cloud قابلاستفاده است؛ Cloud recording، Test Replay، analytics و orchestration قابلیتهای جدا با Account/Plan/Data boundary هستند.
Cypress تضمین Flake-free نمیدهد
صفحهٔ بازاریابی Cypress عبارتهای بسیار قوی دربارهٔ consistency دارد، اما مستندات رسمی Retry صریحاً animation، API، test server/database، dependency و network را علت رفتار unreliable مینامد و Attemptها را ثبت میکند. Auto-wait احتمال بعضی raceها را کم میکند؛ weak Oracle، state sharing، data collision یا App race را حذف نمیکند.
Browser Matrix را با قرارداد کاربر بسازید
Selenium برای Browserهای اصلی Driver/feature اختصاصی دارد. Cypress فعلی Chrome-family شامل Edge/Electron، Firefox و WebKit آزمایشی را فهرست میکند. «همهٔ مرورگرها» یا «فقط چهار Browser» بدون نسخه و maturity دقیق نیست. Browser engine، branded browser، OS و device واقعی یکسان نیستند؛ ماتریس را از کاربران/قرارداد و ریسک بگیرید.
برای طراحی coverage بهجای لوگو، از ماتریس تست سازگاری استفاده کنید. اگر Safari/macOS Hard Gate است، اجرای واقعی همان ترکیب لازم است؛ WebKit آزمایشی روی محیط دیگر ممکن است Proxy کامل نباشد.
Cross-origin، iframe، tab و چند Browser را Probe کنید
Cypress در هر Test با Origin constraints کار میکند و برای Origin دوم cy.origin() میخواهد؛ cross-origin iframe پشتیبانی محدود دارد. Trade-offs رسمی میگوید همزمان دو Browser را کنترل نمیکند و multi-tab با plugin ممکن است، نه بهصورت همان مدل native ساده. Selenium Window handle و sessionهای مستقل دارد، اما orchestration چند Actor را باید خودتان طراحی کنید.
SSO واقعی، درگاه بیرونی، popup OAuth، iframe پرداخت یا collaboration را با Third party بدون مجوز automate نکنید. Contract را به first-party boundary، stub/simulator و verification مناسب بشکنید. قابلیت صرفاً «ممکن است» تا وقتی در Flow واقعی شما اجرا نشده، Fit نیست.
Language Fit با ترجیح شخصی فرق دارد
Selenium bindingهای چندزبان دارد؛ Cypress test code در اکوسیستم JavaScript/TypeScript است. سؤال درست این نیست که Python آسانتر یا JS پولسازتر است. Runtime و package governance، review capacity، shared libraries، frontend/backend proximity، async model، CI image، hiring/onboarding داخلی و backup owner را بسنجید.
اگر تیم Java/Python عمیق دارد، Selenium ممکن است reuse و review بهتری بدهد؛ اگر Product و تیم روی TypeScript و Component workflow هستند، Cypress ممکن است feedback نزدیکتری بدهد. اینها فرضیهاند و باید در matched change/handoff سنجیده شوند.
مخزن و Supply Chain را هم مقایسه کنید
نسخهٔ language runtime، Selenium/Cypress، Browser/Driver، test runner، assertion/report library، plugins، container/image و third-party action را lock و provenance/upgrade/rollback کنید. «npm install یک دستور است» یا «جامعه بزرگ راهحل دارد» TCO و امنیت supply chain را ثابت نمیکند.
CANDIDATE BUILD MANIFEST candidate / version / licence: language/runtime/package-manager versions: browser/driver versions and acquisition path: runner/assertion/report/plugin versions: lockfile/image/action digests: registry/proxy/cache/mirror/offline fallback: install/run commands from clean runner: secret/network permissions: upgrade and rollback owner: known limitations / source URLs / retrieved_at:
Matched Trial یعنی چه چیزهایی یکسان باشند؟
- همان Build و backend dependency versions؛
- همان Browser/OS/viewport/locale/timezone در هر Pair؛
- همان Journey، Actor/Role/Tenant و Risk؛
- همان Dataset/seed/namespace و pre-state؛
- همان Oracle و allowed evidence تا حد ممکن؛
- همان network profile، CI class و resource limits؛
- همان Fault injection و expected detection؛
- همان repetitions/warm-up/order randomization؛
- همان Change request و Receiver handoff؛
- ثبت deviation هرجا parity فنی ممکن نیست.
«همان تعداد Test» کافی نیست؛ یک Test میتواند scope متفاوت داشته باشد. Unit مقایسه را Journey/Claim/Fault قرار دهید و تفاوت معماری را بهعنوان deviation ثبت کنید، نه اینکه Candidate را مجبور کنید ضدالگوی Candidate دیگر را تقلید کند.
Trial Manifest را پیش از اجرا Freeze کنید
MATCHED TRIAL MANIFEST trial_id / version / started_at_utc: decision + candidate versions: application build + dependency digests: journeys/claims/faults + expected counts: browser/OS/viewport/locale/timezone: CI agent CPU/RAM/network/container: dataset/seed/namespace/setup/cleanup: selection/exclusion/skipped: repetitions/warm-up/order: retry policy: preserve first attempt artifacts/redaction/retention: observers / owner / not_claimed:
اول Correctness، بعد Speed
Candidateای که Fault بحرانی را نمیگیرد، بهخاطر اجرای سریع برنده نمیشود. ترتیب Gate: install/run valid → Journey/Oracle correct → target-fault detected → data/state/cleanup safe → Failure diagnosable → representative browser/CI fit → سپس duration/resource/maintenance/cost.
Target-faultهای یکسان طراحی کنید
| Fault | ظاهر گمراهکننده | Oracle لازم |
|---|---|---|
| مبلغ تومان بهجای IRR | Receipt سبز و ۲۰۰ | canonical amount/currency |
| Double submit | صفحهٔ success یکبار | one Order/Ledger/Event |
| Cross-tenant receipt | DOM schema مشابه | Actor/Object authorization |
| Late callback | eventual success | state transition/order |
| Stale selector points wrong button | Click succeeds | postcondition/side effect |
| Loading race | گاهی PASS | state-based actionability/wait |
| Error leak | expected error page | no secret/PII in UI/network |
Fault باید واقعاً mechanism را فعال کند و هر Candidate به دلیل درست FAIL شود. اگر Selenium Failure را از state probe میگیرد و Cypress از network+UI، Evidence میتواند متفاوت باشد ولی Claim باید یکی بماند.
Locator و Actionability را جدا بسنجید
هر دو Candidate میتوانند با selector بد شکننده شوند. Locator را بر semantic/test contract و uniqueness بسازید؛ Actionability و Wait را بر state واقعی. CSS/XPath نسبی یا auto-wait بهتنهایی پایداری را تضمین نمیکند. برای contract، trace و repair از راهنمای اتوماسیون UI پایدار استفاده کنید.
Wait را با Sleep یا شعار Auto-wait نسنجید
Selenium Explicit wait میتواند condition موردنظر را poll کند؛ Cypress command/query/assertion را با retry-ability اجرا میکند. هر دو در برابر شرط اشتباه، event گمشده، shared state و side effect async آسیبپذیرند. Probe کنید: delayed render، request alias، animation، detached DOM، route transition و eventual backend state.
Flake را با First-attempt تعریف کنید
هر Pair را چندبار با order randomized و state reset اجرا کنید. First-attempt PASS/FAIL، retry attempt، mechanism، environment health و final result جدا ثبت شوند. «پس از Retry سبز» Flake را حذف نمیکند. Retry ممکن است diagnostic sample بدهد؛ policy نباید شکست اول را بازنویسی کند.
RUN ATTEMPT RECORD candidate / run_id / test_id / attempt: manifest digest / source commit: started_at / duration / resource class: setup health / selected count: first result / retry result / final policy: failure classification: evidence refs / diagnosis time: cleanup status / residual state: verdict: PASS / FAIL / INCONCLUSIVE / INVALID / NOT_RUN claim_limit:
Duration را بهصورت توزیع گزارش کنید
Install، browser startup، setup، test body، artifact generation، upload و cleanup را جدا کنید. N، median، p75/p95، min/max و warm/cold را گزارش دهید؛ Queue time و Cloud upload را مشخص کنید. چند Run کوچک Benchmark عمومی Selenium/Cypress نیست؛ فقط همین Repository/CI/Workload را توصیف میکند.
Resource و Parallelism را کنار زمان ببینید
Run کوتاهتر با RAM/CPU بیشتر یا ۱۰ Agent شاید گرانتر باشد. CPU/RAM peak، container size، download/cache، browser processes، workers، shard balance، retries، artifact size و Cloud minutes را ثبت کنید. Parallel speedup بدون data isolation و stable selection ممکن است collision و false result بسازد.
Diagnosis را با Fault کور بسنجید
سه Failure را بدون گفتن علت به Maintainer بدهید. زمان تا first hypothesis، علت درست، evidence used، نیاز به rerun، امکان local reproduction و repair confidence را بسنجید. Selenium میتواند screenshot/log/trace integration داشته باشد؛ Cypress command log/screenshot/video/Test Replay دارد، اما Cloud/Plan و data boundary باید جدا لحاظ شود.
Evidence بیشتر همیشه بهتر نیست
Video، screenshot، DOM، network و console ممکن است Token، PII یا transaction data را ثبت کنند. Artifact allowlist، redaction، access، retention و deletion را برای هر Candidate یکسان اعمال کنید. Cloud recording را با local artifact از نظر تشخیص و data governance منصفانه مقایسه کنید.
Change Trial هزینهٔ نگهداری را آشکار میکند
یک تغییر نماینده اعمال کنید: component markup، route، auth boundary، API response، browser version یا parallel CI. Diff lines شاخص کافی نیست؛ زمان impact analysis، تعداد artifactهای تغییرکرده، review effort، failures unrelated، diagnosis، repair، rerun و documentation/handoff را ثبت کنید.
MATCHED CHANGE RECORD change_id / rationale / source: same product change applied to both candidates: affected journeys/contracts: predicted impact before run: files/tests/helpers/config touched: review and repair minutes: unrelated failures / retries: target-fault retained: clean CI result / evidence: receiver understanding / rollback: maintenance verdict / limits:
Handoff را به نفر دوم واگذار کنید
Receiver بدون cache و تنظیمات نویسنده باید install، run، failure diagnosis، test addition، change و cleanup را انجام دهد. Skill gap را از Tool defect جدا کنید، اما training/onboarding cost واقعی را ثبت کنید. ابزار «آسان» اگر فقط نویسنده میفهمد یا backup owner ندارد، Fit سازمانی ضعیفی دارد.
TCO را با قیمت Licence یکی نگیرید
| هزینه | اندازهگیری | دام رایج |
|---|---|---|
| Build | PoC/framework/docs/training | رایگانبودن package |
| Run | CI compute, Grid/Cloud, storage, network | فقط duration |
| Maintain | change/flake/upgrade/triage | تعداد Test |
| Operate | access, secrets, incidents, backups | نادیدهگرفتن ownership |
| Exit | export/migration/dual-run/retraining | فرض lock-in صفر |
| Opportunity | feedback delay/coverage gap | تبدیل به درآمد قطعی |
TCO را با range و assumption بنویسید. کاهش Run time بهتنهایی ROI یا درآمد بیشتر نیست؛ Counterfactual و Outcome مشترک محصول لازماند.
بازار کار ایران را چگونه بدون داستانسازی بسنجیم؟
نام اسنپ، دیجیکالا، تپسی، بانک یا «استارتاپ پولدار» را بدون آگهی/Repository/اظهار رسمی تاریخدار به ابزار نسبت ندهید. یک Market Evidence Pack با window، platform، query، location، remote، contract type، dedup rule و raw sample بسازید. Job title و keyword hit را با task requirement یکی نگیرید.
MARKET EVIDENCE RECORD snapshot_id / retrieved_at / platform: query and Persian/English variants: location / remote / contract / level: visible population / inaccessible pages: dedup by employer-role-location-date: tool mention: required / preferred / contextual / legacy maintenance co-skills: language, CI, API, SQL, architecture, cloud tasks and seniority evidence: sample size / missingness / bias: claim allowed: observed in this sample only not_claimed: total market, causal salary premium, future demand
برای دادهٔ فعلی حقوق و روش مقایسهٔ Role/Offer، راهنمای حقوق تست نرمافزار در ایران را بخوانید. آن مقاله نیز ابزار را علت حقوق نمیداند.
Keyword count مساوی فرصت شغلی نیست
یک آگهی ممکن است Selenium را در لیست طولانی ابزارها، Cypress را بهعنوان preferred، یا هر دو را در متن کپیشده بیاورد. Vacancy تکراری، Recruitment agency، تاریخ منقضی، چند شهر و نام شرکت پنهان bias میسازند. باید وظیفه، must-have، Level و stack را Coding کنید و uncertainty را نگه دارید.
حقوق را به ابزار نسبت ندهید
حقوق به Role، Level، autonomy، consequence، Location، Contract، صنعت، ساعت/on-call، زبان، architecture، CI و Offer بستگی دارد. شخصی که Cypress و frontend engineering میداند شاید Role متفاوتی با Maintainer Selenium داشته باشد؛ تفاوت pay اثر «کلمهٔ ابزار» نیست. هیچ شاهد معتبری برای دوبرابرشدن حقوق، بالاتررفتن خودکار در بازه یا امنیت شغلی وجود ندارد.
برای یادگیری فردی هم Matched Task بسازید
اگر هدف یادگیری است، دو Probe کوچک با همان Journey بسازید و زمان تا فهم/توضیح/Debug/Change را ثبت کنید. Completion tutorial شایستگی نیست. Evidence خوب شامل code review، target-fault، clean setup و انتقال به Task تازه است؛ نه تعداد ویدئو یا ابزارهای رزومه.
«با Python+Selenium شروع کن چون ورود را تضمین میکند» و «Cypress حتماً آسانتر است» نسخهٔ عمومی نیست. تجربهٔ زبان و Task شما تعیینکنندهاند. برای طراحی انتقال مهارت، مسیر شایستگی تست دستی به اتوماسیون را ببینید.
مهاجرت ابزار کمتر از دو هفته تضمین نیست
Syntax شاید سریع منتقل شود؛ معماری، async model، fixtures، network/origin، reporting، CI, plugins، debugging، data/state و team conventions زمان متفاوت دارند. Migration را با inventory، parity claims، dual run، fault detection، coverage gap، change trial و rollback بسنجید؛ calendar promise ندهید.
MIGRATION CONTRACT source / target / versions: why migrate / decision threshold: inventory by risk and business claim: KEEP / PORT / REDESIGN / RETIRE: semantic parity and known non-parity: dual-run window / first-attempt results: data/state/evidence/report mapping: skills/owners/training: rollback / stop conditions: residual coverage gap / review_at:
Hybrid ممکن است پاسخ درست باشد
ممکن است Selenium برای cross-browser/Grid و Cypress برای Component/E2E نزدیک frontend مفید باشد. Hybrid فقط وقتی سالم است که duplicate coverage، دو data model، دو CI/report/secret path و skill fragmentation مدیریت شوند. «هر دو را یاد بگیر» بدون Task و ownership هزینه را دو برابر میکند، نه Capability را.
Scorecard باید شواهد و Confidence داشته باشد
CANDIDATE SCORE RECORD criterion / weight / hard_gate: measurement definition / unit: Selenium result / evidence / confidence: Cypress result / evidence / confidence: deviation / alternative explanation: cost and risk: decision impact: owner / reviewed_at / expires_at:
امتیاز ۱ تا ۵ بدون anchor بازیپذیر است. برای Setup مثلاً ۱=clean install fail، ۳=با workaround مستند، ۵=clean install تکرارپذیر با offline fallback؛ برای Diagnosis anchor مستقل بسازید. Unknown را صفر یا میانگین نکنید.
Decision Record باید LIMIT و INCONCLUSIVE را بپذیرد
SELENIUM-CYPRESS DECISION decision_id / scope / as_of: hard-gate results: matched-trial summary and deviations: critical fault detection: diagnosis / maintenance / handoff: TCO range / assumptions: market evidence boundary: options considered: decision: ADOPT / KEEP / LIMIT / HYBRID / MIGRATE / REJECT / INCONCLUSIVE rationale / authority / dissent: pilot boundaries / stop conditions: review_at / correction triggers: not_claimed: universal winner, hiring, salary, career security
آزمایشگاه مصنوعی ایران: Benchmark نابرابر چگونه دروغ میگوید؟
SYN-SEL-CYP-MATCH-IR-01 کاملاً ساختگی و Offline است: Checkout، Order، PaymentAttempt، PSP Stub، Callback، Ledger و Reconciliation واقعی نیستند؛ هیچ learner/worker/employer/repository/product/customer/payment/secret/salary/hiring outcome وجود ندارد. پول canonical برابر IRR و تومان فقط presentation label است؛ UTC و Asia/Tehran/Jalali تفکیک شدهاند.
UNFAIR INPUT Selenium: 30 tests × Chrome+Firefox+Edge; cold Grid; screenshots all steps Cypress: 10 happy paths × Electron; warm cache; no state probes; no upload one sample: Selenium 45s, Cypress 28s market: 12 duplicated Selenium keyword hits vs 4 Cypress hits salary: invented tool premium declaration: CYPRESS_FASTER_HIGHER_PAY_FUTURE_WINNER AUDIT decision: HOLD reasons: different scope/browser/cache/evidence/oracle/N; duplicate jobs; no Role/Level/Location/Offer comparability; no target-fault or handoff
در نسخهٔ اصلاحی، هر دو Candidate همان سه Journey، Chrome نسخهٔ یکسان، Build/Data/CI/resource، ۳۰ repetition، order randomized، first-attempt، artifacts محدود، faultهای مبلغ/duplicate/tenant و Change/Handoff را اجرا میکنند. نتیجهٔ فرضی فقط برای این Fixture میتواند مثلاً Selenium=KEEP برای cross-browser lane و Cypress=LIMITED PILOT برای component/diagnosis باشد؛ هیچ «برندهٔ بازار» یا عدد درآمدی تولید نمیشود.
آزمایش تکرارپذیر: ۸۹۶ کنترل در برابر پنج شعار
یک Validator مستقل و بدون dependency نوشتیم. ممیز سطحی امنیت شغلی Selenium، دوبرابرشدن حقوق Cypress، کندی همیشگی Selenium، Flake-free بودن Cypress و مهاجرت دوهفتهای را آماده میپذیرد؛ ممیز ساختاری ۶۴ گروه را با ۱۴ کنترل یکتا بررسی میکند.
$ node selenium-cypress-matched-trial-validator.js SELENIUM_JOB_SECURITY_CYPRESS_DOUBLE_SALARY_FAST_FLAKE_FREE_TWO_WEEK_SWITCH_READY HOLD-896 NO_REAL_LEARNER_EMPLOYER_REPOSITORY_PRODUCT_SALARY_PASS READY_FOR_SELENIUM_CYPRESS_MATCHED_TRIAL_REVIEW-0
خط اول عمداً غلط است. HOLD-896 نبود قرارداد مقایسه را آشکار میکند. خط سوم نبود هر هدف واقعی را تأیید میکند. خروجی آخر فقط کاملبودن ساختاری Fixture اصلاحشده است؛ نه صحت Product، برتری ابزار، Flake rate عمومی، performance، امنیت supply chain، مهارت فرد، استخدام، درآمد یا آیندهٔ بازار.
ایران: دسترسی، Registry، Browser و Cloud را در Trial بگنجانید
npm/PyPI/Maven/NuGet، Browser/Driver download، Docker/Action image، Grid/Cloud dashboard، licence/payment/account و artifact upload ممکن است در شبکه/زمان/سیاست مشخص unavailable باشد. ادعای کلی تحریم یا دسترسی نکنید؛ تاریخ/ISP/endpoint/status و Terms را ثبت کنید. Mirror/cache/offline fallback باید مجاز، versioned و قابلبهروزرسانی باشد.
Cloud feature را اگر Candidate دیگر local است رایگان فرض نکنید؛ data residency، secret/log/video، retention، support، export و exit را بسنجید. دورزدن محدودیت سرویس موضوع مقاله نیست.
AI و Recorder برتری ابزار را ثابت نمیکنند
Recorder/Studio/AI میتواند scaffold بسازد؛ ولی locator، assertion، data، secret، target-fault و maintenance را انسان بازبینی میکند. Prompt یا Cloud نباید Source خصوصی، credential، Production DOM/PII یا Artifact بدون مجوز دریافت کند. نرخ تولید code بدون repair/change trial معیار Fit نیست.
Correction: قابلیت و بازار هر دو تغییر میکنند
Browser support، experimental feature، Cloud plan، Manager/Driver، plugin، job sample و salary source تاریخ انقضا دارند. هر Claim باید source/retrieved_at/scope/version داشته باشد. تغییر Product/Browser/CI/Team/market window Trigger بازآزمایی است؛ نتیجهٔ ۱۴۰۳ را برای ۱۴۰۵ یا آینده تکرار نکنید.
CORRECTION RECORD record_id / previous decision: changed capability/context/evidence: source/version/retrieved_at: affected hard gates/criteria/journeys: materiality: action: keep / re-trial / limit / migrate / rollback owner / due_at: supersedes / history preserved: claim_limit:
۲۸ ضدالگوی Selenium vs Cypress
- خودروی قدیمی در برابر اسپرت مدرن
- جنگ ابزار و برندهٔ جهانی
- Selenium استاندارد طلایی/پیر/کند
- Cypress جوان/همیشه سریع/قابلاعتماد
- تست خودکار ضرورت همهٔ شرکتها
- نام شرکت ایرانی بدون source
- بانک=Selenium و استارتاپ=Cypress
- keyword count بدون dedup/task
- حقوق بالاتر بهعلت Cypress
- امنیت شغلی بهعلت Selenium
- ورود تضمینی با Python+Selenium
- دوبرابرشدن حقوق با JS+Cypress
- SDET بودن صرفاً با ابزار
- Future winner بدون time-bound evidence
- همهٔ Browserها/قدیمیها بدون version
- Cypress فقط چند Browser ثابت و منقضی
- Driver setup همیشه دستی
- npm install برابر setup کامل
- Auto-wait برابر no Flake
- Retry برابر repair
- one-run duration benchmark
- Scope/Browser متفاوت در comparison
- Mock/stub متفاوت بدون deviation
- Line count برابر maintainability
- Cloud artifact بدون data cost
- Hybrid بدون duplicate/TCO control
- مهاجرت تضمینی زیر دو هفته
- امتیاز میانگین برای پوشاندن Hard Stop
چکلیست ۴۴ سؤالی Trial
- Decision و alternatives روشناند؟
- Authority و dissent ثبت شده؟
- Role/Task/Work product واقعی است؟
- User/Browser/Support contract وجود دارد؟
- Risk و Fault هدف تعیین شده؟
- Hard Gate از score جداست؟
- Candidate/version/licence پین است؟
- Official capability source تاریخدار است؟
- Language/runtime با review capacity همخوان است؟
- Browser/OS matrix دقیق است؟
- Origin/iframe/window/multi-browser probe شده؟
- Repository/lockfile/image/action pin شده؟
- Clean install در CI انجام شده؟
- Registry/proxy/cache/mirror ثبت است؟
- Build/dependency versions یکساناند؟
- Journey/Actor/Role/Tenant یکساناند؟
- Data/seed/namespace یکسان است؟
- Setup/Cleanup و residual state سنجیده میشود؟
- Browser/viewport/locale/timezone یکساناند؟
- CI CPU/RAM/network class یکسان است؟
- Selection و expected count برابر است؟
- Deviationها قبل از Result ثبت شدهاند؟
- Oracle/Claim یکی مانده؟
- Faultهای critical هر دو را میکشند؟
- Locator/actionability جدا سنجیدهاند؟
- Wait mechanism با race واقعی Probe شده؟
- Repetition/warm-up/order تعریف شده؟
- First-attempt از Retry جداست؟
- Duration components و distribution ثبت است؟
- CPU/RAM/parallelism/artifact cost ثبت است؟
- Failure blind diagnosis اجرا شده؟
- Evidence allowlist/redaction/retention یکسان است؟
- Invalid/Inconclusive از Fail جداست؟
- Matched Change trial اجرا شده؟
- Review/repair/handoff effort ثبت است؟
- Receiver clean-room run کرده؟
- TCO Build/Run/Maintain/Operate/Exit دارد؟
- Market snapshot dedup و coded است؟
- Salary از Tool causality جداست؟
- Learning evidence به Transfer وصل است؟
- Migration parity/rollback دارد؟
- Iran access/offline gap ثبت است؟
- Decision LIMIT/INCONCLUSIVE را میپذیرد؟
- Review expiry/correction فعال است؟
برنامهٔ ۳۰روزهٔ Matched Trial
روز ۱–۳: Decision/Task/Risk/Hard Gate؛ روز ۴–۶: Candidate manifests و clean install؛ روز ۷–۱۰: یک Journey و Oracle همسان؛ روز ۱۱–۱۳: Faultها و data/state؛ روز ۱۴–۱۶: Browser/origin/window probes؛ روز ۱۷–۱۹: repetitions/flake/duration/resource؛ روز ۲۰–۲۲: blind diagnosis/evidence؛ روز ۲۳–۲۵: matched change/review؛ روز ۲۶: receiver handoff؛ روز ۲۷: Iran/offline drill؛ روز ۲۸: TCO؛ روز ۲۹: market snapshot boundary؛ روز ۳۰: Decision review. این برنامه تضمین انتخاب یا مهاجرت نیست.
منابع رسمی و محدودیت استناد
- Selenium Browser docs: قابلیتهای Browser-specific فعلی؛ نه تضمین parity همهٔ Browserها.
- Selenium Manager: مدیریت رسمی Driver/Browser در نسخههای فعلی و fallback binding؛ نه reproducibility کامل supply chain/CI.
- Cypress Supported Browsers: Chrome-family/Firefox و WebKit آزمایشی در تاریخ بازیابی؛ نه پوشش user matrix شما.
- Cypress Trade-offs: مرز general-purpose، browser/origin/multi-browser و plugin؛ نه حکم ضعف یا برتری.
- Cypress Test Retries: attempt/retry و نمونه علل Flake؛ نه درمان خودکار.
- Cypress CI: اجرای CI و قابلیتهای Cloud recording در نسخهٔ فعلی؛ نه الزام Cloud یا برابری cost/data boundary.
صفحات رسمی هر Vendor قابلیت محصول خود را توصیف میکنند؛ برای Benchmark مستقل یا ادعای برتری کافی نیستند. Matched Trial این مقاله یک synthesis است، استاندارد Selenium/Cypress نیست.
جمعبندی: ابزار را با Fault و Handoff انتخاب کنید
Selenium و Cypress را با سن، هیجان، یک زمان اجرا یا شایعهٔ بازار مقایسه نکنید. Hard Gateها را تعیین، Journey/Browser/Data/Fault/CI را همسان، first-attempt و Evidence را حفظ، Diagnosis و Change و Receiver را امتحان و TCO را محدود کنید. شاید نتیجه KEEP، LIMITED PILOT، HYBRID یا INCONCLUSIVE باشد؛ تصمیم خوب لازم نیست یک برندهٔ جهانی بسازد.
سوالات متداول
برای بازار کار ایران Selenium یاد بگیرم یا Cypress؟
با یک snapshot تاریخدار آگهی و Task هدف تصمیم بگیرید، نه شمارش خام Keyword. Role/Level/Language/CI/API/architecture را Coding کنید و سپس دو Work sample کوچک بسازید. هیچ ابزار بهتنهایی استخدام یا امنیت شغلی را تضمین نمیکند.
Cypress همیشه سریعتر و کمFlakeتر است؟
خیر. معماری و auto-wait میتواند برای برخی Flowها مزیت بدهد، اما Scope، Browser، CI، Data/State، Oracle و artifact cost تعیینکنندهاند. روی Workload همسان چندبار اجرا و first-attempt Flake را جدا گزارش کنید.
آیا Selenium فقط برای سیستمهای قدیمی است؟
نه. WebDriver یک استاندارد automation برای Browserهای اصلی و اکوسیستم فعال است؛ Selenium Manager نیز setup Driver را مدرنتر کرده است. Fit آن به Task، زبان، Browser/Grid، CI، architecture و هزینه نگهداری تیم شما بستگی دارد.
آیا دانستن Cypress حقوق را دو برابر میکند؟
شاهد قابلاتکایی برای چنین رابطهای نداریم. حقوق به Role، Level، Location، Contract، autonomy، consequences، stack و Offer وابسته است. ابزار میتواند یک Skill باشد، نه علت مستقل یا تضمین مبلغ.
چه زمانی Hybrid Selenium و Cypress منطقی است؟
وقتی هرکدام یک Risk/Task جدا را با شواهد بهتر پوشش دهند و دو Repository/Data/CI/Report/Skill path هزینهٔ کنترلشده داشته باشد. duplicate coverage، ownership و Exit را ثبت کنید؛ Hybrid پیشفرض نیست.
