۱۲۰ بررسی رابط کاربری در شش دقیقه اجرا شدهاند، همه سبزند و Dashboard ادعا میکند ۱۰۰٪ مسیرهای حیاتی پوشش داده شدهاند؛ آیا کاربر میتواند با موفقیت خرید کند؟ هنوز معلوم نیست. شاید Locator روی دکمهٔ اشتباه کلیک کرده، Toast موفقیت دیده شده اما Order ساخته نشده، Retry نخستین Failure را پنهان کرده، تست فقط با Mouse و یک Viewport اجرا شده یا Evidence به Build دیگری تعلق دارد.
اتوماسیون تست رابط کاربری زمانی ارزشمند است که یک User-visible Claim را از راه Interaction و Observation قابل بازتولید بسنجد. واحد مهندسی این راهنما UI Interaction & Observation Contract است: User Task/Visible Behavior → Subject/State/Data → semantic Locator → Actionability/Interaction → Synchronization → UI و business-side-effect Oracle → Browser/Viewport/Locale → Evidence/Trace → Failure attribution → Repair/Correction.
این صفحه مالک تعداد مناسب Unit/Integration/E2E نیست؛ آن تصمیم در راهنمای عملی هرم تست بررسی میشود. اینجا میپرسیم: وقتی UI سطح درست Observation است، چگونه Checkی بسازیم که واقعاً همان رفتار مورد نظر را ببیند و Failure آن قابل توضیح باشد؟
پاسخ کوتاه: UI Automation خوب چه ویژگی دارد؟
Check خوب از Task و رفتار قابل مشاهدهٔ کاربر شروع میشود، نه از DOM. هدف را با Locator معنایی و یکتا پیدا میکند؛ پیش از Action، State و Actionability را بررسی میکند؛ بهجای Sleep ثابت منتظر Condition مرتبط میماند؛ هم Feedback رابط و هم Side effect مهم را با Oracle نسخهدار میسنجد؛ Config مرورگر/نمایش/Locale را پین میکند؛ و برای هر Attempt، Trace و Evidence قابل نسبت میسازد.
- Click succeeded به معنای Task succeeded نیست.
- Element visible به معنای قابلاستفاده یا درستنامگذاریشده نیست.
- Toast success به معنای ایجاد اثر کسبوکاری نیست.
- Screenshot equal به معنای رفتار یا دسترسپذیری درست نیست.
- UI PASS به معنای نبود باگ، Coverage کافی یا آمادگی انتشار نیست.
مرز این راهنما با اتوماسیون عمومی، Framework و Pyramid
| پرسش | مالک محتوایی | مرز این صفحه |
|---|---|---|
| اصلاً چه چیزی را خودکار کنیم؟ | راهنمای اتوماسیون تست | کاندیدا، معماری، هزینه و Pilot عمومی |
| هر Automated Check چه Claim و lifecycle دارد؟ | Automation Claim & Lifecycle | Oracle/Evidence/Quarantine/Retirement مستقل از Interface |
| Framework را چگونه انتخاب کنیم؟ | انتخاب فریمورک اتوماسیون | Criteria، Architecture و PoC ابزار |
| Unit/Integration/E2E چه نسبتی داشته باشند؟ | هرم تست در عمل | Risk portfolio و layer placement |
| Interaction و Observation در UI چگونه معتبر شوند؟ | همین راهنما | Locator، actionability، wait، config، evidence و repair |
UI Check، E2E، Browser Test و Visual Test یکی نیستند
| نوع | Subject/Observation | ادعای مجاز نمونه |
|---|---|---|
| Component UI | Component render + interaction در Harness | State/props مشخص رفتار قابل مشاهدهٔ تعریفشده میسازند |
| Browser integration | UI با چند جزء/سرویس کنترلشده | Interaction در Config مشخص به Effect منتخب متصل است |
| System UI | سامانهٔ مستقر با Dependencyهای تعریفشده | Journey محدود در Build/Environment مشخص کامل میشود |
| E2E | زنجیرهٔ واقعیتر بین Boundaryهای متعدد | چند جزء برای Task نامدار همکاری میکنند |
| Visual regression | رندر پیکسلی/ساختاری در Baseline مشخص | Diff از Tolerance تعریفشده عبور نکرده است |
| Accessibility check | Rule/interaction/AT observation | Rule یا معیار محدود در Config آزموده شده است |
UI بودن، E2E بودن را تضمین نمیکند؛ E2E بودن نیز به معنای واقعیبودن همهٔ Dependencyها نیست. نام Test باید Boundary و Fidelity را نشان دهد، نه ارزش یا جامعیت آن را.
UI Interaction & Observation Contract چیست؟
این Contract رابطهٔ بین قصد کاربر، Target رابط، Action ماشینی، State/زمان و Observation را نسخهدار میکند. هدف تحمیل قالب سنگین به هر Check نیست؛ هدف آشکارکردن فرضهایی است که در «کلیک کن و منتظر Toast بمان» پنهان میشوند.
UIInteractionObservationContract
checkId / version / portfolio / risk / basis
userTask / visibleBehavior / boundedClaim / claimLimit
UIContract / immutableSubject / preconditions / initialState
data / namespace / cleanup / dependency
locator.semantics / contract / strictness / ambiguity
interaction.intent / actionability / focus / keyboard / pointer
scroll / overlay / dialog / upload-download
readiness / condition / timeoutBudget / asyncBoundary / clock
oracle.source / uiRule / sideEffectRule / tolerance / window
browser / version / OS / viewport / scale / locale / timezone
font / colorScheme / reducedMotion / zoom / network
isolation / parallelPartition / resultVocabulary / retry
evidenceManifest / trace / DOM / network / console / digest
failureClass / observation / hypothesis / causeEvidence
repairTrigger / affectedScope / verification / correction
owner / triageSLA / reviewDue / cost / measure / guardrailچه زمانی UI سطح درست Observation است؟
UI را وقتی انتخاب کنید که Risk به Interaction، rendering، focus، browser behavior، integration از مسیر واقعی کاربر یا feedback قابل مشاهده وابسته است. اگر Question فقط منطق محاسبه، schema validation یا API contract است، UI ممکن است Setup و Noise غیرضروری اضافه کند. اما «همیشه به لایهٔ پایینتر منتقل کن» نیز غلط است؛ حذف UI میتواند Integration و User-agent behavior را نامرئی کند.
| پرسش | Observation point محتمل | چرا؟ |
|---|---|---|
| فرمول تخفیف درست است؟ | Unit/domain | UI Interface مرتبط نیست |
| API خطای duplicate را برمیگرداند؟ | API/contract | پاسخ Protocol مستقیمتر است |
| کاربر با Keyboard فرم را Submit میکند؟ | Browser UI | Focus/order/semantics لازماند |
| پس از Submit، effect و feedback هماهنگاند؟ | UI + side-effect observation | مرز نمایش و سیستم باید متصل شود |
| Layout در فونت فارسی نمیشکند؟ | Visual/browser matrix | رندر واقعی لازم است |
| Journey در PSP واقعی موفق است؟ | کنترل چندسطحی/محدود | UI تنها Cause/Boundary را جدا نمیکند |
مرحله ۱: User Task را به Claim محدود تبدیل کنید
از «Checkout را تست کن» شروع نکنید. Actor capability، هدف، نقطهٔ شروع، Interaction mode، Expected visible behavior و Effect مهم را بنویسید. Claim باید Subject و Config را محدود کند. Claim limit نیز چیزهایی مانند UX quality، همهٔ Browserها، دسترسپذیری کامل و financial correctness را خارج نگه دارد.
userTask: ثبت سفارش با صفحهکلید
visibleBehavior:
- هنگام pending دکمه قابل submit دوباره نیست
- یک status confirmation قابل مشاهده/اعلام است
boundedClaim:
BUILD-R22 در Chromium/config مشخص، برای Order مصنوعی
دقیقاً یک confirmation و یک Ledger effect میسازد
claimLimit:
نه UX، WCAG conformance، coverage، absence of defects یا releaseمرحله ۲: UI Contract را از DOM فعلی جدا کنید
DOM یک Implementation snapshot است؛ UI Contract معنای مورد اتکای کاربر/آزمون را ثبت میکند: Role/name، label-control relation، state، status semantics، Test ID قراردادی یا Domain component interface. تغییر Class ممکن است Contract را عوض نکند؛ تغییر Accessible name یا Action semantics ممکن است بدون Diff ظاهری Contract را بشکند.
Contract باید Owner، version، consumerها و change policy داشته باشد. Test-specific attribute همیشه بد یا خوب نیست: اگر معنای پایدار و governance دارد مفید است؛ اگر برای دورزدن Interface یا انتخاب عنصر مبهم ساخته شود، Test به چیزی غیر از تجربهٔ کاربر متصل میشود.
مرحله ۳: Locator معنایی و یکتا بسازید
Locator باید Target مورد قصد را در لحظهٔ Action پیدا کند. Role/name، label، text، alt یا Test ID نسخهدار گزینهاند؛ هیچ اولویت مطلقی برای همهٔ UIها وجود ندارد. Contract را بر معنایی بنا کنید که تغییر آن واقعاً باید Review تست را برانگیزد.
| Locator | Signal تغییر | خطر |
|---|---|---|
| role + accessible name | معنا/نام قابل درک تغییر کرده | ترجمه یا نام تکراری نیاز به Scope دارد |
| label | رابط label-control تغییر کرده | label ناقص خودش Defect محتمل است |
| visible text | متن مصرفی تغییر کرده | locale/copy variation |
| test id قراردادی | Automation interface تغییر کرده | ممکن است semantics کاربر را نسنجد |
| CSS/XPath ساختاری | DOM implementation تغییر کرده | False Fail ناشی از Refactor بیمعنا |
Strictness مهم است: اگر دو Target match شدند، انتخاب first() یا index ثابت شاید Test را سبز ولی Intent را مبهم کند. Ambiguity باید Failure قابلطبقهبندی بسازد، نه انتخاب تصادفی.
مرحله ۴: Actionability را صریح کنید
وجود Element در DOM برای Click کافی نیست. Target ممکن است hidden، disabled، moving، covered، خارج Viewport یا detached باشد. Frameworkها مجموعهای از Actionability check دارند، اما semantics Product را نمیدانند؛ Element فنی قابل کلیک ممکن است طبق Rule کسبوکار هنوز نباید قابل استفاده باشد.
- Visible، stable، enabled و capable of receiving event را از state کسبوکاری جدا کنید.
- Overlay، sticky header، animation و re-render را در Failure evidence نگه دارید.
- Force click را فقط با دلیل و Claim محدود استفاده کنید؛ این گزینه میتواند رفتار واقعی کاربر را دور بزند.
- Hover، touch، long-press و drag هرکدام Input semantics و Config متفاوت دارند.
مرحله ۵: Mouse، Keyboard، Touch و Assistive مسیرهای متفاوتاند
Click ماشینی جای مسیر Keyboard یا Touch را نمیگیرد. Focus order، focus visibility، keyboard activation، touch target، pointer capture، IME و Screen reader interaction Failure modeهای جدا دارند. برای Risk مهم، Interaction mode را در Population و Claim بنویسید.
یک Check با element.click() ممکن است event را مستقیم فراخوانی کند و scrolling/actionability واقعی را نبیند. انتخاب API سطح پایین یا بالا باید آگاهانه باشد و در Contract ثبت شود.
مرحله ۶: Focus را بهعنوان State قابل مشاهده ببینید
Focus فقط جزئیات دسترسپذیری نیست؛ تعیین میکند input بعدی کجا میرود، dialog چگونه بسته میشود و کاربر پس از Validation error چه میبیند. Initial focus، tab order، focus trap، restoration و visible indicator را در UI Contract بنویسید. Assertion باید Target و زمان مناسب را بسنجد.
اجرای خودکار Keyboard میتواند بخشی از رفتار را بسنجد، اما Conformance یا usability کاربران دارای معلولیت را ثابت نمیکند. راهنمای کامل در تست دسترسپذیری WCAG ۲.۲ قرار دارد.
مرحله ۷: Synchronization را بر Condition مرتبط بنا کنید
sleep(5000) نه میداند چه چیزی باید آماده شود و نه پس از پنج ثانیه چه وضعی معتبر است. اگر سیستم سریع باشد زمان هدر میرود؛ اگر کند باشد Test هنوز میشکند. Readiness باید از state قابل مشاهده مشتق شود: Role ظاهر شده، response نامدار تکمیل، spinner حذف، state transition رخ داده یا side effect در window تعریفشده مشاهده شده است.
| انتظار ضعیف | Condition بهتر | محدودیت |
|---|---|---|
| Sleep 5s | status به state نهایی نامدار برسد | Status شاید side effect را نبیند |
| network idle | response/operation مشخص + UI state | Background traffic ممکن است دائمی باشد |
| element exists | element معنایی actionability و state درست دارد | Business readiness جداست |
| spinner gone | Outcome/Effect مشخص در window | Spinner implementation detail است |
| retry assertion forever | bounded polling با diagnostic observation | Timeout باید consequence-based باشد |
مرحله ۸: Timeout بودجه است، نه درمان Flakiness
افزایش Timeout میتواند Failure را دیرتر نشان دهد یا variation واقعی را مخفی کند. بودجه را بین Navigation، readiness، interaction و eventual side effect تقسیم کنید؛ مقدار را با SLO/Environment baseline و Consequence تعیین کنید. در Timeout evidence بنویسید آخرین State چه بود، نه فقط «timed out».
Clock، animation، debounce، token expiry و scheduled job باید کنترل یا ثبت شوند. Timezone و DST نیز بخشی از Config هستند. Fake clock فقط بخش تحت کنترل را deterministic میکند و رفتار real-time dependency را تضمین نمیکند.
مرحله ۹: UI Oracle را از پیام موفقیت فراتر ببرید
UI Oracle میتواند visible state، role/status، field error، route یا DOM semantics را بسنجد. برای Taskهایی که effect مهم دارند، Oracle دوم لازم است: API query، event، database projection، stub record یا audit entry کنترلشده. این Observation باید از مسیر مستقل و با key هویتی همان Subject باشد.
oracle.source:
BASIS-v9:R-IDEMP-6 + UI-CONTRACT-v5
uiRule:
exactly one role=status confirmation for Order identity
sideEffectRule:
exactly one Ledger effect by tenant+order+event
window:
UI 5s; effect within 10s synthetic window
claimLimit:
no inference about other PSP modes, UX, finance or releaseمرحله ۱۰: State و Data را برای UI ایزوله کنید
Shared account، موجودی مشترک، سبد باقیمانده و Order تصادفی از Database باعث collision و order dependence میشوند. هر Check باید Namespace، Seed، Tenant/actor، initial state و cleanup محدود داشته باشد. Login state reuse میتواند سرعت بدهد، اما باید Scope، freshness، privilege و mutation contract داشته باشد.
Isolation به معنای ساخت کامل دنیا برای هر Check نیست. Dependencyهای گران میتوانند shared اما read-only یا partitioned باشند؛ Trade-off را صریح کنید و Parallel capacity را آزمایش کنید.
مرحله ۱۱: Browser Context و Session را کنترل کنید
Cookie، local/session storage، cache، permission، service worker، IndexedDB و feature flag State رابطاند. Context تازه بسیاری از leakageها را کم میکند، ولی اگر هدف persistence یا upgrade است باید همان State را عمدی بسازید. Check independent بودن را با اجرای تنها، ترتیب تصادفی و parallel آزمایش کنید.
مستند رسمی Selenium دربارهٔ پرهیز از State مشترک دادهٔ مستقل، پاکسازی دادهٔ کهنه و Driver تازه را توصیه میکند. خود Selenium این مطالب را guideline وابسته به Context مینامد؛ آن را با محدودیت سامانهٔ خود تطبیق دهید.
مرحله ۱۲: Config مرورگر و نمایش را هویت بدهید
نام Chrome کافی نیست. Browser build، engine/channel، OS/image، viewport، device scale، input device، locale، timezone، font، zoom، color scheme، reduced motion، contrast preference، permission و network profile بر رفتار و رندر اثر دارند. Project config را به Evidence Manifest پیوند دهید.
| Config | Failure mode | نمونه Evidence |
|---|---|---|
| Viewport/zoom | responsive layout، overlap، target offscreen | dimensions + screenshot + DOM |
| Locale/font | text expansion، glyph، number/date parsing | locale/font digest |
| Timezone/clock | cutoff، expiry، relative time | ISO instant + timezone |
| Reduced motion | animation path/transition timing | media setting + trace |
| Network profile | late response، retry، offline/partial state | HAR/network events |
| Browser version | engine/API/permission behavior | binary/version/image digest |
مرحله ۱۳: Browser Matrix را از Risk مشتق کنید
«همهٔ Browserها» Population تعریفشده نیست. Analytics معتبر، Supported platform policy، Contract، Risk، capability و change profile را ترکیب کنید. Smoke گسترده و Journey عمیق میتوانند Matrix متفاوت داشته باشند. نتیجهٔ Chromium را به Safari/WebKit، Mobile viewport یا Screen reader تعمیم ندهید.
برای انتخاب Browser/OS/Device و روش Sampling از راهنمای Cross-browser Testing استفاده کنید؛ این صفحه فقط Contract هر اجرای UI را پوشش میدهد.
مرحله ۱۴: Dependency خارجی را به Product خود نسبت ندهید
سرویس ثالث، CAPTCHA، OTP، Payment gateway، Email و CDN خارج کنترل ممکن است Test را کند، غیرقطعی یا خطرناک کنند. در بیشتر CIها Stub/virtual service با Contract روشن Signal تشخیصیتر میدهد؛ تعداد کمی Probe کنترلشده میتواند Integration واقعی را جدا بسنجد. شکست Third party را از Product/Testware/Environment جدا طبقهبندی کنید.
Mock همهچیز را درست نمیکند: اگر Model کهنه یا بیشازحد خوشبین باشد، UI سبز و Production ناسازگار میشود. Contract test، version، scenario parity و confirmation point لازم است.
مرحله ۱۵: Result Vocabulary تشخیصی بسازید
| Result | معنا | اقدام |
|---|---|---|
| PASS | Observation با Oracle همین Subject/Config سازگار بود | Claim محدود؛ نه Release |
| FAIL_PRODUCT | ناسازگاری معتبر با evidence منتسب به Product | Finding/Defect triage |
| FAIL_TESTWARE | Contract/Locator/Oracle/Implementation تست مشکل دارد | Repair با Review |
| ERROR_ENV | Browser/grid/deploy/config اجرای معتبر را نگذاشت | Environment response |
| ERROR_DATA | Seed/state/partition معتبر نبود | Data response |
| ERROR_DEPENDENCY | Dependency خارج مرز شکست | Dependency policy |
| SKIPPED | طبق Rule اجرا نشد | Denominator/Reason |
| INCONCLUSIVE | Evidence برای Attribution کافی نیست | Unknown + next observation |
این Classification خودکار ممکن است Candidate باشد، نه حقیقت Cause. Observation، Hypothesis و confirmed cause را جدا نگه دارید.
مرحله ۱۶: Trace را به Screenshot تقلیل ندهید
Screenshot آخرین Frame را نشان میدهد، نه مسیر Interaction، DOM پیشین، request/response، console یا timing. Evidence bundle متناسب میتواند Trace، DOM/accessibility snapshot، Screenshot failure-only، network events، console، video محدود، raw result و Manifest هویت را نگه دارد. همهٔ Artifactها را همیشه ضبط نکنید؛ هزینه و حریم خصوصی دارند.
UIEvidenceManifest
check: UI-CHECKOUT-IDEMP-22@5
subject: BUILD-R22 / DEPLOY-R22
config: Chromium fictional-140 / Linux R22 / fa-IR / 1280x720
run / attempt / startedAt / finishedAt / outcome
trace / screenshot / DOM / network / console / raw
dataNamespace / dependency versions
digest / redaction / retention / unknowns
claimLimit: no UX, conformance, coverage, quality or release proofPlaywright Best Practices برای failureهای CI استفاده از Trace Viewer را توصیه میکند و timeline، DOM snapshot و network را در دسترس میگذارد. این قابلیت ابزار، Cause را خودکار اثبات نمیکند؛ Evidence باید به Claim و Subject شما متصل شود.
مرحله ۱۷: Retry نخستین Failure را پاک نکند
FAIL سپس PASS یک PASS ساده نیست؛ Variation مشاهده شده است. همهٔ Attemptها، Config/Seed/time و Artifact را حفظ کنید. Summary میان PASS_FIRST_TRY، PASS_AFTER_RETRY، CONSISTENT_FAIL، MIXED و ERROR_AFTER_RETRY تمایز بگذارد. Retry policy باید هدف داشته باشد: جمعآوری Evidence، تحمل transient تعریفشده یا تأیید Variation.
Retry-until-green و حذف Attempt اول، pass rate را آرایش میکند. Quarantine نیز باید Owner، expiry، Risk impact، Control جایگزین و re-entry داشته باشد؛ وگرنه Suite با حذف Signalهای بد ظاهراً پایدار میشود.
مرحله ۱۸: Flaky، Brittle، False Fail و False Pass را جدا کنید
| برچسب | تعریف قابل آزمون | Evidence لازم |
|---|---|---|
| Flaky | Outcome بین اجراهای معادل طبق Contract تغییر میکند | controlled series + equivalence proof |
| Brittle | تغییر غیرمرتبط با Claim، Testware را با repair پرهزینه میشکند | representative change experiment |
| False Fail | Check Fail میدهد ولی Claim نقض نشده | independent observation/cause |
| False Pass | Check PASS میدهد ولی Claim نقض شده | injected fault/independent oracle |
| Slow | Latency از budget/decision need عبور میکند | distribution + queue/run split |
UI Test ذاتاً Flaky یا Brittle نیست؛ Boundary بیشتر و browser state، failure opportunity را افزایش میدهد. معماری Product، Testability، Contract، Data و Environment تعیینکنندهاند. Unit Test نیز میتواند کند، شکننده و بیارزش باشد.
مرحله ۱۹: Failure Attribution را پیش از Repair انجام دهید
«Element not found» Cause نیست؛ Observation ابزار است. Candidateها شامل تغییر UI Contract، locator scope، render failure، auth redirect، data state، overlay، network، browser crash یا wrong Buildاند. Triage packet باید Fact، Hypothesis و cause evidence را جدا کند.
FailureAttribution
observation: submit locator matched zero elements at 08:00:04Z
facts: route=/checkout; status API=200; form role absent
hypotheses:
H1 auth redirect race
H2 feature flag disabled form
H3 UI contract intentionally changed
evidenceNeeded: trace step, DOM before action, flag snapshot, C22 diff
cause: UNKNOWN until evidence confirms
prohibited: auto-update locator merely to make the test greenمرحله ۲۰: Repair Contract و blast radius بسازید
Repair باید Trigger، confirmed cause، change type، affected consumers، Reviewer و Verification داشته باشد. تغییر central Page/Component abstraction میتواند صدها Check را تغییر دهد؛ Blast radius و representative fixtures را اجرا کنید. Auto-heal بدون Review ممکن است Target مشابه اما غلط را انتخاب و False Pass بسازد.
Page Object یک الگوی ممکن برای پنهانکردن UI details و ارائهٔ service interface است؛ اجباری یا تضمینکننده نیست. Abstraction بسیار بزرگ Intent و Failure location را پنهان میکند. الگو را با rate of change و team review fit انتخاب کنید.
مرحله ۲۱: Visual Regression را مستقل مهندسی کنید
Screenshot comparison به Baseline، viewport، OS/browser، font، animation/clock، content masking، color profile، threshold و Diff triage نیاز دارد. برابر بودن Screenshot رفتار صحیح را ثابت نمیکند؛ متفاوتبودن نیز لزوماً Defect نیست. Visual output باید یک Oracle محدود با approved change history باشد.
طراحی کامل Baseline، mask، tolerance و Diff review در راهنمای Visual Regression Testing آمده است. UI functional Check را با VRT مخلوط نکنید مگر Claim ترکیبی روشن باشد.
مرحله ۲۲: Accessibility Automation را محدود گزارش کنید
Rule engine میتواند برخی violationهای قابل محاسبه را بیابد؛ Keyboard sequence، semantic assertion و accessibility tree نیز Observationهای مفیدند. اما اسکن سبز، Conformance WCAG یا usability کاربران دارای معلولیت را ثابت نمیکند. Population page/state/component و Rule set/version را ثبت کنید.
W3C در راهنمای Understanding Techniques صریحاً میگوید آزمون Techniqueها بهتنهایی آزمون Conformance کل WCAG نیست و ارزیابی باید فراتر برود. User agent و assistive technology support نیز با زمان تغییر میکند.
مرحله ۲۳: Layer placement را با Observation gap تصمیم بگیرید
برای هر UI Check بپرسید کدام بخش Claim را میتوان در Component/API/Contract سریعتر و تشخیصیتر سنجید و کدام بخش فقط در UI دیده میشود. ممکن است یک Journey به چند Check کوچکتر و یک UI seam check تبدیل شود. اما تعداد کم/زیاد بهتنهایی هدف نیست؛ Risk و Observation gap مهماند.
Test Pyramid یک heuristic است، نه نسبت ثابت. عبارت «UI باید کوچکترین لایه باشد» ممکن است برای Productهای UI-heavy، legacy یا thin-client نیاز به تفسیر داشته باشد. Portfolio را با latency، diagnostic value، fidelity، cost و blind spot بازبینی کنید.
مرحله ۲۴: Pipeline placement را از Suite design جدا کنید
یک UI Check خوب الزاماً در PR اجرا نمیشود. Smoke سریع ممکن است pre-merge، Matrix گسترده nightly و system/canary check پس از deploy باشد. Trigger را با Change impact، Environment availability، execution cost، signal latency و consequence تنظیم کنید. Queue time و provisioning را از test duration جدا بسنجید.
Parallelism فقط تعداد Worker نیست؛ Data partition، rate limit، dependency capacity و artifact collision لازماند. Sharding نادرست ممکن است Setup را چند برابر و Environment را اشباع کند.
راهنمای رسمی Playwright چه میگوید و چه نمیگوید؟
مستند رسمی Playwright توصیه میکند رفتار قابل مشاهدهٔ کاربر آزموده شود، Locatorهای user-facing/explicit contract ترجیح داده شوند، Checkها تا حد ممکن isolated باشند، از web-first assertion استفاده شود و Trace برای Debug در CI به کار رود. Locatorها strictness و auto-waiting دارند و generated locator قابل ویرایش است.
این توصیهها تضمین Resilience، Coverage، UX، Accessibility یا Product quality نیستند. Auto-waiting business readiness را نمیفهمد، Locator generator Intent دامنه را نمیداند و Trace Cause را خودکار ثابت نمیکند. Version و Context ابزار را در تصمیم محلی نگه دارید.
Selenium چرا از عبارت Best Practice پرهیز میکند؟
Selenium Encouraged Behaviors عمداً میگوید هیچ رویکردی برای همهٔ موقعیتها مناسب نیست و مطالب را guideline/recommendation مینامد. همچنین روشن میکند Selenium تعامل Browser را ممکن میسازد، اما Suite خوشمعماری را برای شما طراحی نمیکند.
بنابراین Page Object، fresh browser، locator style یا mock service را قانون ثابت تلقی نکنید. Failure mode، Team skill، Product architecture و Evidence need را بسنجید.
آزمایش بازتولیدپذیر: ۱۲۰ Check سبز در برابر ۱۱۵ Failure
Fixture کاملاً مصنوعی و آفلاین SYN-UI-INTERACTION-OBSERVATION-01 با Node.js v24.۱۸.۰ ساخته شد؛ Browser، شبکه، Database یا Product واقعی ندارد. Dashboard سطحی فقط ۱۲۰/۱۲۰ Green، «۱۰۰٪ مسیر حیاتی» و شش دقیقه را دید و PASS داد.
{
"ruleCount": 115,
"superficial": {
"status": "PASS",
"message": "120/120 UI checks green; 100% critical journeys; 6 minutes"
},
"contractAudit": {
"status": "HOLD",
"findingCount": 115
}
}ممیزی همهٔ ۱۱۵ Rule را Fail کرد: دوازده Portfolio/Product/Goal/Risk/Basis/Repository/Commit/Build/Deployment/UI Contract/Environment/Data identity کهنه؛ Check ID تکراری و Question/Claim/Task/State/Data ناقص؛ DOM locator غیرsemantic و مبهم؛ نبود Actionability و همهٔ Interaction modeها؛ Sleep ثابت و نبود readiness/timeout/async/clock؛ Toast-only Oracle؛ فقدان browser/render/locale/network Config؛ نبود isolation/dependency/vocabulary؛ Evidence/Trace/DOM/network/console/raw/time/digest/Unknown/redaction/retention؛ Retry پنهان؛ Attribution و Repair بیمدرک؛ Owner/cost/measure؛ و ۲۲ ادعای مطلق دربارهٔ User success، Coverage/Release، ذات UI/Unit، نسبت Pyramid، Screenshot، Accessibility، Automation، Tool/Pattern/Locator و Green confidence.
نسخهٔ اصلاحشدهٔ آزمایش چه کرد؟
نسخهٔ اصلاحشده UI-PORT-۲۲/SYN-CHECKOUT/PG-۱۵/RISK-v11/BASIS-v9/checkout-ui-tests/C22/BUILD-R22/DEPLOY-R22/UI-CONTRACT-v5/ENV-UI-R22/DATA-SYN-۲۲ را پین کرد. Check یکتا Task صفحهکلید، visible behavior، semantic strict Locator، actionability/focus/keyboard/pointer، condition-based wait، UI+Ledger Oracle، Chromium/OS/viewport/locale/font/motion/network Config، isolation، Result vocabulary و Evidence کامل ساخت.
Retry همهٔ Attemptها را حفظ کرد؛ Failure attribution و Repair/Correction contract، Owner/SLA/Review، Cost/Measure/Guardrail کامل شد و ادعاهای مطلق حذف شدند. Validator با صفر Finding وضعیت READY_FOR_UI_REVIEW داد؛ عمداً نه حقیقت/کفایت Oracle/Evidence، Coverage، موفقیت کاربر، Accessibility conformance، نبود باگ، Product quality یا Release را ثابت کرد.
آزمایشگاه Checkout فارسی و ایرانی
Lab یک Checkout جدا از شبکه با Order، PaymentAttempt، PSP Stub جعلی، Callback، Ledger Stub و Reconciliation مصنوعی است. Scenarioها شامل submit تکراری، timeout قبل/بعد از fake commit، duplicate/late/reordered Callback، خطای Validation، pending state، reload و Tenant isolation هستند.
| بعد | قرارداد Fixture | محدودیت |
|---|---|---|
| پول | مقدار canonical ساختگی بر حسب IRR؛ تومان فقط view برچسبدار | نه ادعای مالی/بانکی ایران |
| متن/رقم | ارقام فارسی/عربی/لاتین، Unicode normalization، RTL/LTR و stable Latin ID | نه پوشش همهٔ Localeها |
| زمان | ISO instant/UTC؛ view در Asia/Tehran؛ جلالی فقط presentation | نه قاعدهٔ حقوقی/تسویه |
| UI Config | فونت Fixture، ۱۲۸۰×۷۲۰، reduced motion، zoom ۱۰۰% | نه Browser/device matrix کامل |
| هویت | Tenant/Order/Attempt/Event/Ledger/Run/Build/Deploy/Evidence جدا | نه مشتری یا تراکنش واقعی |
هیچ Network، Production، شرکت، کاربر، پرداخت، بانک، PSP، نام، موبایل، ایمیل، IP، حساب، PAN، CVV2، OTP، Cookie، Token، Credential، Screenshot یا Log واقعی استفاده نمیشود. Lab توصیهٔ بانکی، مالی، حقوقی، مالیاتی، امنیتی، حریم خصوصی یا Compliance ایران نیست.
امنیت و حریم خصوصی Evidence رابط کاربری
- Screenshot/Video/Trace/DOM/HAR ممکن است PII، Token و محتوای حساس داشته باشند؛ Redaction را آزمون کنید.
- Credential را در Source، command line، report، query string یا attachment ذخیره نکنید.
- Test account کماختیار، synthetic data و Namespace محدود داشته باشد.
- Artifact access، encryption، retention و deletion evidence را Policy کنید.
- Download/upload Fixture از Production یا فایل واقعی استفاده نکند.
- Cleanup فقط Resourceهای دارای Run identity را حذف کند.
AI و Self-healing در UI Automation
AI میتواند Locator candidate، Test draft، Failure cluster یا Repair diff پیشنهاد کند. Model/version، input Artifact، confidence، alternatives و Reviewer را ثبت کنید. Self-heal نباید Target را بیصدا عوض و Outcome قبلی را سبز کند؛ semantic distance و affected Claim باید Review شوند.
Visual AI، screenshot diff یا agentic browser بهتنهایی Oracle نیست. Prompt injection در page content، destructive action، credential exposure، nondeterministic plan و unverifiable summary Failure modeهای اضافیاند. Action allowlist، synthetic environment، deterministic assertion و human gate لازم است.
متریکهای UI Automation با Countermetric
| Measure | تعریف لازم | Countermetric |
|---|---|---|
| First-attempt valid signal | Outcome معتبر در Attempt اول بر eligible checks | SKIPPED/ERROR/Quarantine |
| False-result rate | False Pass/Fail تأییدشده با independent evidence | verification opportunity |
| Feedback latency | Trigger تا Evidence قابل مصرف؛ queue و run جدا | signal quality/cost |
| Repair time | از confirmed testware cause تا verified repair | blast radius و recurrence |
| Contract churn | UI Contract changeهای واقعی بر consumerها | Product change rate |
| Isolation failure | Order/parallel/shared-state collision در series | capacity و setup cost |
| Evidence diagnostic yield | Triageهایی که bundle علت را سریعتر محدود کرد | storage/privacy overhead |
| Observation gap | Riskهای UI-dependent بدون Control نماینده | duplicate low-level checks |
Test count، Pass rate، UI درصد Portfolio یا Automation coverage را برای رتبهبندی افراد استفاده نکنید. این Incentive به Testهای کوتاه، assertion ضعیف، Retry پنهان و حذف Checkهای دشوار منجر میشود.
Pilot سیروزهٔ یک UI Interaction Contract
| بازه | کار | خروجی/گیت |
|---|---|---|
| روز ۱–۵ | یک User Task/Risk مصرفشده و Baseline false signal/repair/latency را انتخاب کنید | Question/Claim/Non-goals |
| روز ۶–۱۰ | UI Contract، Locator semantics، State/Data و Oracle دوگانه را طراحی کنید | Design review و injected fault |
| روز ۱۱–۱۵ | Actionability، keyboard/pointer، synchronization و Config را اجرا کنید | controlled wait/input experiments |
| روز ۱۶–۲۰ | isolation/random-order/parallel/network/failure modes را آزمون کنید | series و classification report |
| روز ۲۱–۲۵ | Trace/Evidence/Retry/Attribution/Repair/Correction را تمرین کنید | Triage game day |
| روز ۲۶–۳۰ | Signal/latency/cost/privacy/observation gap را Review کنید | Keep/Adapt/Move/Retire/Scale decision |
Pilot موفق با Demo سبز یا Test بیشتر تعریف نمیشود؛ باید یک تغییر نماینده و یک Fault تزریقشده را با Verdict درست، Evidence تشخیصی و Repair قابل Review مدیریت کند.
۳۲ ضدالگوی UI Automation
- Checkout works بهعنوان Claim؛ Click=Success؛ Toast=Effect؛ UI PASS=Release؛ ۱۰۰٪ Journey=Coverage.
- CSS/XPath ساختاری پیشفرض؛ nth-child/first برای ambiguity؛ test-id همیشه بهترین؛ auto-heal بیReview.
- Sleep ثابت؛ Timeout نامحدود؛ network-idle جهانی؛ force click؛ bypass Actionability.
- فقط Mouse؛ focus نادیده؛ Keyboard/Touch/IME یکسان؛ scanner=WCAG؛ screenshot=Visual correctness.
- latest/nightly/staging؛ Browser بدون version؛ Viewport بدون scale/zoom؛ فونت/Locale/Timezone فراموش.
- Shared account/order؛ cleanup گسترده؛ وابستگی به ترتیب؛ parallel بدون partition؛ state reuse بیFreshness.
- Third party واقعی در هر PR؛ Mock بدون parity؛ CAPTCHA bypass مخفی؛ Dependency FAIL=Product bug.
- سبز/قرمز دوحالته؛ ERROR/SKIPPED در PASS؛ Retry-until-green؛ Attempt اول حذف؛ Quarantine بیExpiry.
- Screenshot-only evidence؛ Trace حاوی Secret؛ Artifact همیشه روشن؛ Retention همیشگی؛ DOM/HAR عمومی.
- Element not found=Cause؛ هر Failure=Defect؛ هر UI change=Test repair؛ Repair مرکزی بدون blast-radius.
- UI ذاتاً کند/شکننده؛ Unit همیشه سریع/ارزان؛ Pyramid نسبت ثابت؛ UI همیشه کوچکترین و happy-path-only.
- Page Object اجباری؛ Tool=Architecture؛ Green build=Confidence؛ AI-generated/healed=Correct.
چکلیست ۲۶ نقطهای ممیزی UI Check
- Portfolio/Product/Goal/Risk/Basis/Repository/Commit/Build/Deploy پین شدهاند.
- UI Contract/Environment/Data Pack نسخه و Owner دارند.
- Check ID/version، User Task، Question، bounded Claim و Claim limit روشناند.
- Visible behavior و Side effect مورد انتظار جدا تعریف شدهاند.
- Precondition/initial State/Data/Namespace/Cleanup معلوماند.
- Locator به semantic/explicit contract متصل است.
- Strictness/uniqueness و ambiguity failure policy اعمال میشوند.
- Interaction intent و Actionability ثبت شدهاند.
- Focus/Keyboard/Pointer/Scroll/Dialog/File mode متناسب پوشش دارند.
- Readiness و condition جای Sleep ثابت را گرفتهاند.
- Timeout budget/async boundary/clock کنترل شدهاند.
- Oracle دارای Source/UI rule/side-effect rule/tolerance/window است.
- Browser/version/OS/viewport/scale/locale/timezone/font مشخصاند.
- Color scheme/reduced motion/zoom/network profile ثبت شدهاند.
- Context/State/Data isolation و parallel partition آزموده شدهاند.
- Dependency/Stub version و parity/confirmation معلوماند.
- Vocabulary Product/Testware/Env/Data/Dependency/Skipped/Unknown را جدا میکند.
- Manifest/Trace/Screenshot/DOM/network/console/raw/time/digest کاملاند.
- Redaction/Access/Retention و Secret/PII policy اعمال میشوند.
- همهٔ Retry Attemptها حفظ شده و Failure اول پنهان نیست.
- Observation/Hypothesis/Cause evidence جدا هستند.
- Repair trigger/type/reviewer/affected scope/verification تعریف شدهاند.
- Correction/Supersession برای Outcome نامعتبر وجود دارد.
- Owner/Triage SLA/Review due/Cost/Measure/Guardrail مشخصاند.
- Visual و Accessibility claim محدود گزارش میشوند.
- PASS به User success، Coverage، Conformance، Quality یا Release تعمیم نمییابد.
جمعبندی: UI را مثل Interface مشاهدهپذیر مهندسی کنید
مشکل UI Automation «بالای هرم بودن» یا نام ابزار نیست. شکست زمانی رخ میدهد که Interaction با Intent، Wait با State، UI feedback با Side effect و Artifact با Subject پیوند ندارد. Check خوب مسیر کاربر را تقلید صرف نمیکند؛ یک Claim محدود را در Config مشخص با Evidence قابل نقد میسنجد.
با یک User Task پرریسک شروع کنید. Faultی تزریق کنید که Toast میآید اما Effect ساخته نمیشود، Locator را مبهم کنید، Network را کند و Config فارسی را تغییر دهید. اگر Suite Verdict درست و علت قابل بررسی نساخت، قبل از افزودن Check بعدی Contract مشاهده را اصلاح کنید.
سوالات متداول اتوماسیون تست رابط کاربری
اتوماسیون تست UI دقیقاً چه چیزی را میسنجد؟
به Contract بستگی دارد. معمولاً Interaction با رابط و رفتار قابل مشاهده در Browser/Config مشخص را میسنجد و میتواند یک Side effect نامدار را هم بررسی کند. UI Check بهخودیخود UX، همهٔ لایهها، همهٔ Browserها، نبود باگ یا موفقیت کاربر را اثبات نمیکند.
بهترین Locator برای تست رابط کاربری چیست؟
Locator جهانشمولی وجود ندارد. Role/name، label، text یا Test ID قراردادی را بر اساس معنایی انتخاب کنید که تغییر آن باید Review تست را فعال کند. Locator باید scoped، یکتا و strict باشد؛ ambiguity نباید با first/index پنهان شود. CSS/XPath ساختاری برای Intent کاربر معمولاً ضعیفتر است.
چگونه Flaky Test رابط کاربری را کم کنیم؟
ابتدا با series کنترلشده Flakiness را اثبات کنید. سپس State/Data/Context را ایزوله، Sleep را با Condition مرتبط جایگزین، Browser/Environment را پین، Dependency را کنترل و همهٔ Attemptها/Trace را حفظ کنید. Retry نهایی راهحل نیست؛ Variation باید Owner، Cause investigation و re-entry evidence داشته باشد.
آیا باید تعداد تستهای UI همیشه کم باشد؟
نه بهعنوان قانون عددی. هر Check باید Risk و Observation gap منحصربهفرد، Signal مصرفشده و هزینهٔ پذیرفتنی داشته باشد. بخشی از Claim را میتوان به سطح تشخیصیتر منتقل کرد، اما رفتار واقعاً وابسته به UI باید در UI بماند. Portfolio را با Evidence، latency، cost و blind spot بازبینی کنید.
آیا تست خودکار UI برای دسترسپذیری و Visual کافی است؟
خیر. Rule scan، semantic assertion، Keyboard Check و Screenshot diff فقط Claimهای محدود خود را پشتیبانی میکنند. WCAG conformance به ارزیابی معیارها، Context، user agent/assistive technology و قضاوت انسانی نیاز دارد؛ Visual equality نیز رفتار یا usability درست را ثابت نمیکند.
