نقشه راه مهندس اتوماسیون تست؛ Charter تا Handoff

نقشه راه مهندس اتوماسیون تست با انتخاب Playwright، Selenium یا یک زبان شروع نمی‌شود؛ با تعریف کاری شروع می‌شود که باید به‌طور تکرارپذیر تحویل، اجرا، تشخیص، تعمیر و واگذار شود. یک Demo سبز روی لپ‌تاپ می‌تواند برای یادگیری مفید باشد، اما تا وقتی Risk، Oracle، Data، Environment، Run identity، Evidence، CI policy، Owner و Maintenance روشن نیست، شاهد آمادگی مهندسی نیست.

این راهنما یک Automation Engineering Delivery Map می‌سازد: Target Role/Task و Context را ثبت می‌کند؛ Risk را به Check و Evidence وصل می‌کند؛ Testability و Stack را با Probe می‌سنجد؛ Repository، Dependency و Supply chain را نسخه‌دار می‌کند؛ UI/API/State، Data/Isolation/Oracle و Execution را طراحی می‌کند؛ Check را وارد CI می‌کند؛ Failure را قابل‌تشخیص و Quarantine/Repair را قابل‌ممیزی می‌سازد؛ و فقط با Handoff/Operability/Readiness evidence دربارهٔ تحویل تصمیم می‌گیرد. این نقشه وعدهٔ استخدام، درآمد، Level یا زمان ثابت یادگیری نیست.

پاسخ کوتاه: برای مهندس اتوماسیون تست شدن چه باید آموخت؟

توان تحلیل Risk و Test basis، طراحی Oracle و داده، خواندن/نوشتن کد، Git و Review، HTTP/API و State، انتخاب Check مناسب، Isolation و Repeatability، اجرای محلی و CI، تولید Evidence، تشخیص Failure، نگهداشت و Handoff هستهٔ کارند. UI framework، زبان، Container، Cloud و AI بسته به Role و Product به این هسته اضافه می‌شوند. آمادگی با «دانستن نام ابزار» یا تمام‌کردن دوره سنجیده نمی‌شود؛ با اجرای مستقل یک Delivery slice و توضیح محدودیت‌های آن سنجیده می‌شود.

پرسش ضعیف	پرسش مهندسی	شاهد
کدام ابزار آینده‌دار است؟	کدام Stack برای Task/Team/Runtime قابل‌عملیات است؟	Probe + ADR
چند ماه تا Junior؟	کدام Task را با چه Support مستقل تحویل می‌دهم؟	Readiness packet
چند تست نوشتم؟	کدام Risk/Claim با چه Oracle پوشش داده شد؟	Trace
CI سبز است؟	چه چیزی اجرا/حذف/نامعلوم شد و Evidence کجاست؟	Run manifest
AI کد ساخت؟	چه کسی Oracle، Security و Maintenance را تأیید کرد؟	Review record

مرز این مقاله با سه نقشه‌راه دیگر

شروع تست خودکار از صفر مالک برنامهٔ مقدماتی هشت‌هفته‌ای است. گذار تستر دستی به اتوماسیون مالک ترجمهٔ Capability و پروژهٔ یادگیری فردی است. چرخهٔ عمر Automated Check مالک قرارداد و نگهداشت هر Check است. نقش SDET نیز مرز شغلی خودش را دارد. این صفحه مالک نقشهٔ تحویل end-to-end یک Automation engineering slice از Charter تا Handoff و Readiness است.

نقشه‌راه را با Target Role Contract آغاز کنید

Automation Engineer عنوان جهانی با مسئولیت یکسان نیست. ممکن است یک Role فقط Checkهای API را نگه دارد، Role دیگر Platform/Runner را مالک باشد و SDET روی Testability محصول کار کند. Role Charter مهندس QA را مبنا بگیرید و Task، Work product، Decision right، Support و No-authority را بنویسید. «همه‌چیز از UI تا Security و DevOps» Role نیست؛ Wish list است.

AutomationRoleContract
role_id/version: AUT-ENG-DELIVERY-v1
context: fictional web/API product; no production
critical_tasks: design, implement, run, diagnose, repair, hand off
work_products: repository + checks + pipeline + evidence + runbook
decision_rights: check readiness and evidence completeness
no_authority: product release, residual-risk acceptance, people rating
support: product/dev/platform/security owners
review_trigger: role, architecture, risk, stack or capacity change

Outcome را از Learning activity جدا کنید

دیدن ویدئو، خواندن مستندات، حل تمرین و ساخت Demo Activity هستند. Outcome مهندسی یعنی یک نفر دیگر بتواند نسخهٔ مشخص Repository را در Environment تعریف‌شده نصب کند، Checkهای انتخاب‌شده را اجرا کند، نتیجه و Missing را بفهمد، Artifact را بیابد و Failure شناخته‌شده را با Runbook تشخیص دهد. Course completion می‌تواند ورودی باشد، نه Readiness gate.

DeliveryOutcome
consumer: fictional reviewer/maintainer
trigger: candidate build B-17
action: reproduce environment; execute smoke slice; classify failure
work_product: signed-off evidence packet + repair PR
acceptance: clean setup, deterministic fixture, independent oracle
timebox: observed range, not universal speed target
non_outcomes: employment, seniority, salary, product quality guarantee

Capability Graph بسازید، نه صف خطی ابزارها

Git می‌تواند پیش‌نیاز Review باشد؛ HTTP پیش‌نیاز فهم API؛ State/Oracle پیش‌نیاز Check معتبر؛ CI پیش‌نیاز اجرای مشترک؛ Diagnosis و Maintenance پیامد هر اجرای واقعی‌اند. اما همهٔ گره‌ها خطی نیستند: می‌توان کدنویسی و طراحی تست را در یک Slice تمرین کرد یا UI را تا بعد از API به تعویق انداخت. هر Edge باید دلیل Task داشته باشد، وگرنه Trend یا ترجیح مدرس جای نیاز Role نشسته است.

گره	توان مشاهده‌پذیر	پیش‌نیاز	شاهد
Test design	Risk→Oracle→Check	basis/domain	trace card
Code	خواندن/تغییر/خطایابی	language runtime	reviewed PR
Data/state	setup/reset/identity	model	fixture replay
Execution	local/CI parity	manifest	run IDs
Diagnosis	product/check/env/unknown	evidence	triage packet
Maintenance	adapt/repair/retire	ownership	change trial

Manual و Automation رقیب صفر و یک نیستند

تست دستی «ناممکن» نشده و Automation جای Exploration، مشاهدهٔ انسانی، سؤال تازه و ارزیابی معنا را نمی‌گیرد. Automated Check برای سؤال تکرارشونده با Oracle قابل‌کدنویسی و هزینهٔ نگهداشت قابل‌قبول مناسب است. Exploration می‌تواند Check candidate بسازد؛ Check نیز زمان را برای Exploration آزاد کند. تصمیم را بر Risk، frequency، variability، observability، controllability و TCO بگذارید، نه هویت «Manual tester» و «Automation tester».

Automation Charter محدودهٔ تحویل را می‌بندد

پروژهٔ نمونه نباید «اتوماسیون Checkout» نامیده شود. Actor، Journey، State، Risk، سؤال، سطح تست، Interface، Dataset، Environment، Trigger، Budget و Exclusion را مشخص کنید. کوچک‌ترین Slice معتبر بهتر از Framework بزرگ بدون Oracle است. Charter همچنین Non-goalها را ثبت می‌کند تا یک Smoke محدود به «پوشش کامل» تبدیل نشود.

AutomationCharter
charter_id/version: CHKOUT-AUT-01/v1
risk: duplicate callback may create inconsistent visible state
question: does repeated identical event preserve one committed attempt?
level/interface: API + state projection; UI confirmation optional
fixture: synthetic order/payment/callback only
environment: disconnected deterministic stubs
budget: 2 checks; 90s; one worker
excluded: real PSP, load, security, accessibility, production readiness

Testability را پیش از Framework ارزیابی کنید

اگر State قابل مشاهده، Data قابل کنترل، زمان قابل تثبیت، Dependency قابل Stub و نتیجه دارای Oracle نیست، Framework مشکل بنیادی را حل نمی‌کند. Testability request می‌تواند endpoint وضعیت، stable identity، fake clock، seed/reset، correlation ID، semantic locator یا export evidence باشد. هزینهٔ تغییر Product و Alternativeهای Service/API/Component/UI را مقایسه کنید.

TestabilityAssessment
controllability: seed/reset/fault injection
observability: state/event/log/trace with correlation
oracleability: independent expected-state source
isolation: tenant/namespace/clock/dependency
diagnosability: step, request, response, state diff
access/security: least privilege; synthetic data
gaps: product change | harness | stub | manual observation | defer

Stack را با Probe انتخاب کنید

Playwright، Selenium، Cypress، Appium یا هر گزینهٔ دیگر فقط وقتی Fit است که با Target، تیم، Runtime، Browser/device، Language، CI، Debugging، access، licence، support و migration سازگار باشد. محبوبیت و «استاندارد جدید» Evidence محلی نیست. دو Candidate را با یک Risk slice، faultهای یکسان و Timebox مشترک مقایسه کنید؛ نتیجه می‌تواند `ADOPT`, `LIMITED`, `REJECT` یا `INCONCLUSIVE` باشد.

Probe dimension	شاهد	پرسش	ضدخطا
Fit	target run	سطح/پلتفرم پشتیبانی می‌شود؟	Demo بازاریابی
Oracle	target-fault detection	خطای واقعی Fixture دیده شد؟	فقط happy path
Diagnosis	trace/log/state	علت قابل‌تفکیک است؟	Screenshot-only
CI	clean runner	تکرارپذیر است؟	works-on-my-machine
Maintenance	change trial	تغییر محدود چه Ripple دارد؟	LOC کمتر
Exit	migration note	Lock-in چیست؟	فرض ماندگاری

زبان را از Repository و Team context انتخاب کنید

Python، Java، JavaScript/TypeScript یا C# ذاتاً بهترین نیستند. معیارها شامل زبان Product/Team، library support، type/tooling، runtime، review capacity، CI image، dependency policy و نگهداشت است. «فقط OOP و I/O کافی است» هم نسخهٔ عمومی نیست؛ باید data structure، async/error semantics، modules، package manager، test runner، logging، serialization، security basics و debugging لازم برای Task را بلد بود.

Repository Contract را پیش از کدنویسی بنویسید

Repository تحویل‌پذیر باید ownership، structure، install/run commands، runtime pin، dependency lock، config layering، secret policy، lint/type/unit/check commands، artifact paths، branch/review policy، versioning و archive/retire را روشن کند. README تبلیغ نیست؛ رابط Maintainer با پروژه است. دستور اجرا باید از clone پاک یا بستهٔ آفلاین تعریف‌شده بازتولید شود.

RepositoryContract
repo_id/version/owner/backup: explicit
runtime/package_manager: pinned
install: clean/frozen dependency path
commands: lint | type | unit | smoke | target | report
config: defaults → environment → secret reference
artifacts: manifest/results/logs/traces/checksums
review: protected branch + required reviewers
retire/archive: trigger, retention, migration owner

Dependency و Supply Chain بخشی از Automation است

Runner تست معمولاً به Packageها، Browser binary، Container image و CI action اعتماد می‌کند و ممکن است Secret داشته باشد. Version range بدون Lock، script نصب ناشناخته یا Action شناور می‌تواند Run را تغییر دهد. مستند رسمی npm ci مسیر نصب مبتنی بر Lock را توضیح می‌دهد؛ تنظیمات رسمی GitHub Actions نیز امکان الزام full-length commit SHA برای Actionها را نشان می‌دهد. این‌ها نمونه‌اند، نه الزام استفاده از npm یا GitHub.

DependencyManifest
runtime/tool/browser/image/action versions: exact
lock/digest/commit SHA: recorded where supported
source/registry/license: policy-checked
install scripts/network: bounded
vulnerability/update: owner and cadence
rollback/cache/offline fallback: tested
provenance claim: only what evidence supports
secrets: none in source/artifact/log

Architecture را از Concernها بسازید

لایه‌ها باید تغییر را محصور کنند، نه فقط پوشه بسازند. Test intent/flow، domain model، interface driver، data builder، oracle، environment adapter، evidence reporter و configuration concernهای متفاوت‌اند. Page Object می‌تواند تعامل UI را محصور کند اما محل Assertionهای business outcome یا God object نیست. راهنمای رسمی Selenium Page Object نیز جداسازی interface را تشویق می‌کند؛ نسخهٔ مقاله معماری جهانی تجویز نمی‌کند.

AutomationArchitecture
intent: risk/question/check composition
domain: identities, states, events, money/time semantics
drivers: API/UI/event/database only with authorized access
fixtures: builders, seed/reset, namespaces
oracles: independent expected relations
evidence: manifest + step observations + artifacts
adapters: environment/tool-specific boundaries
rule: no layer may silently convert UNKNOWN to PASS

Automated Check Contract را واحد تحویل بگیرید

هر Check باید Risk/Question، Preconditions، Input، Action، Oracle، Expected relation، Environment، Data, timeout، Evidence، Owner، Failure classification، cleanup و expiry داشته باشد. نام Test نباید تنها Documentation باشد. Check count Coverage نیست؛ یک Check می‌تواند چند assertion ضعیف یا یک Oracle مستقل قوی داشته باشد. Trace باید دوطرفه باشد: Risk→Check و Check→Risk.

AutomatedCheckContract
check_id/version: PAY-CALLBACK-IDEMP-01/v2
risk/question: duplicate event / one committed attempt?
preconditions/data: synthetic identities + known state
stimulus: same callback ID delivered twice
oracle: ledger/event relation independent from implementation output
expected: one transition; duplicate classified; no second ledger effect
evidence: requests, events, state diff, run manifest
cleanup/owner/expiry: explicit

Oracle را از همان منطق پیاده‌سازی کپی نکنید

اگر Expected با همان function یا query ساخته شود که Actual را تولید کرده، خطا ممکن است در هر دو تکرار شود. Oracle می‌تواند approved example، invariant، state model، reconciliation relation، independent calculation یا human-reviewed snapshot باشد. `۲۰۰ OK`, absence of exception، visible text یا Screenshot به‌تنهایی business correctness نیست. UNKNOWN باید حالت معتبر باشد، نه PASS ضمنی.

Oracle	مناسب	ریسک	کنترل
Exact expected	قاعدهٔ ثابت	duplicate logic	منبع مستقل
Invariant	State/data relation	ناکافی برای معنا	چند invariant
Model	transition/sequence	مدل غلط	review + fault
Differential	دو implementation	خطای مشترک	diversity
Snapshot	ساختار پایدار	approve-all	semantic review
Human	معنا/UX	تکرارپذیری	rubric/evidence

Data را به Fixture قابل‌بازتولید تبدیل کنید

دادهٔ Production یا «ناشناس‌شده» انتخاب پیش‌فرض نیست. Synthetic-first، lineage، generator version، seed، identity namespace، clock، setup/reset، expected state، privacy classification و checksum را ثبت کنید. دادهٔ فارسی باید ی/ی، ک/ک، ZWNJ، ارقام فارسی/عربی/لاتین، RTL/LTR/Bidi و طول/normalization را پوشش دهد؛ اما هر حالت باید به Risk و Oracle وصل باشد.

FixturePack
pack_id/generator/seed: SYN-CHECKOUT-07/gen3/4107
entities: fake order, attempt, callback, ledger, reconciliation
identities: UUID namespace per run
money: fictional IRR; labelled toman display only
time: UTC canonical; Asia/Tehran; Jalali display only
unicode: ی/ي, ک/ك, ZWNJ, ۱۲۳/١٢٣/123, bidi probes
setup/reset/checksum: deterministic
prohibited: real identity, account, token, order or payment

Isolation را با Namespace و State ownership بسازید

Parallel-by-default بدون Isolation می‌تواند Collision و Flaky بسازد. هر Run باید namespace، tenant/user/data IDs، clock، port/resource، dependency behavior و cleanup ownership داشته باشد. Shared environment باید conflict policy و lease داشته باشد. Order-dependent Check نشانهٔ Suite contract شکسته است مگر sequence خود موضوع تست باشد. Retry Isolation نیست.

IsolationContract
run_id/namespace: immutable / unique
state_owner: check | suite | shared service
resources: user/order/topic/file/port prefixes
clock/randomness: fixed or recorded
dependencies: stub behavior/version
parallel policy: allowed sets + collision probes
cleanup: verify, quarantine residue, never delete broad targets
failure: contamination → INVALID/INCONCLUSIVE, not product FAIL

API slice را فراتر از Status code طراحی کنید

برای API، Request identity، authentication/authorization scope، schema، semantic state، idempotency، pagination، concurrency، timeout-before/after-commit، retry، duplicate/late/reordered event و error contract مهم‌اند. راهنمای تست API مبانی را پوشش می‌دهد؛ در Delivery Map باید یک Risk slice را از setup تا state/evidence و cleanup بسته تحویل دهید.

UI slice را روی رفتار و قرارداد پایدار بنا کنید

راهنمای رسمی Playwright best practices رفتار قابل‌مشاهده، Isolation، locatorهای user-facing و Trace برای Failureهای CI را توصیه می‌کند. این guidance دلیل کافی برای انتخاب Playwright یا ادعای پایداری خودکار نیست. در هر Stack، semantic locator، actionability/wait، focus/dialog/navigation/download، network/state boundary و Evidence را روشن کنید. چرخهٔ Locator تا Repair جزئیات UI را دارد.

UISurfaceContract
journey/state: bounded
locator: role/name or explicit test contract; uniqueness checked
actionability: visible/enabled/stable policy
navigation/dialog/focus: expected transitions
network/dependency: controlled or classified
oracle: user-visible outcome + independent state where needed
evidence: trace/log/screenshot selective; secret-safe
repair: interface change vs product defect distinguished

Wait و Retry را ابزار پنهان‌کردن Failure نکنید

Sleep ثابت هم کند است و هم Race را حل نمی‌کند. Wait باید بر condition معنادار با timeout و Evidence باشد. Retry نتیجهٔ اولیه را حفظ و علت Retry را ثبت کند؛ Final pass نباید First-attempt failure را پاک کند. Retry می‌تواند transient infrastructure را مدیریت کند اما Product race، shared data یا Oracle ناپایدار را درمان نمی‌کند. Flaky classification به تکرار کنترل‌شده و diagnosis نیاز دارد.

Local و CI را با Environment Manifest مقایسه کنید

«روی سیستم من پاس است» تا زمانی که Build، commit، runtime، OS/image، browser، dependency، config، timezone/locale، resource و data یکسان یا Delta روشن نباشد، توضیح نیست. Environment manifest باید machine-readable و در Artifact باشد. Secret value ثبت نشود؛ فقط reference/version/availability. Clean-run، repeat-run و controlled-delta run سه شاهد متفاوت‌اند.

EnvironmentManifest
source_commit/build/artifact_digest: pinned
runner/os/image/runtime/browser: versions/digests
dependencies/lock: identity
config/feature_flags: names + safe values where permitted
locale/timezone/clock: fa-IR / Asia-Tehran / fixed UTC
cpu/memory/network/dependency modes: bounded
secret_refs: names only; availability status
manifest_checksum: attached to run

CI Trigger و Selection policy را قابل‌ممیزی کنید

«با هر Commit همهٔ تست‌ها» همیشه مناسب نیست. PR، merge، nightly، release candidate، dependency update و manual investigation هدف و Budget متفاوت دارند. Selection باید Population، include/exclude، shard، timeout، cancellation، fail-fast، retry، Missing artifact و fallback را ثبت کند. Zero selected یا skipped گسترده نباید Green شود. CI provider ابزار است؛ Policy باید مستقل از Vendor فهمیده شود.

Lane	Trigger	Population	Budget	Failure action
PR smoke	change	fast critical claims	کوتاه	diagnose/hold
merge	main update	broader integration	متوسط	owner ACK
nightly	schedule	variants/longer	بیشتر	triage window
release	candidate ID	risk-selected	decision-bound	evidence gate
diagnostic	manual case	specific fault	timebox	not release evidence

Pipeline را با Least Privilege و Provenance ببندید

Workflow می‌تواند کد ثالث اجرا و به Token/Artifact دسترسی پیدا کند. Permissionهای Job را حداقلی، Action/Dependencyها را pin، fork/untrusted input و pull-request secrets را کنترل، log/artifact را secret-scan و cache را مرزبندی کنید. Artifact attestation یا provenance فقط وقتی Claim شود که تولید و verification واقعی دارد؛ وجود CI به‌تنهایی Supply-chain security یا integrity را ثابت نمی‌کند.

PipelineSecurityContract
workflow_id/version/trigger/trust_boundary: explicit
permissions: default none; job-specific minimum
third_party_steps: allowlist + pinned identity
untrusted_inputs: never interpolated into privileged commands
secrets: scoped, masked, no fork exposure
artifacts/cache: identity, integrity, retention, access
provenance: generated/verified/claim-limited or NOT_IMPLEMENTED
incident/revoke/update owner: named

Run Manifest Evidence را قابل‌تکرار می‌کند

HTML report زیبا کافی نیست. Run باید commit/build/config/environment/data/selection/check versions، attempt history، timestamps، statuses، missing/skipped، artifacts و checksums داشته باشد. PASS یعنی Oracle تعریف‌شده در همان Run نقض نشده، نه کیفیت Product. FAIL نیز Product defect را ثابت نمی‌کند تا Attribution انجام شود. CANCELLED، NOT_RUN، INVALID و INCONCLUSIVE را به FAIL/PASS تبدیل نکنید.

RunManifest
run_id/trigger/as_of: immutable
source/build/environment/data: identities + checksums
selection: population/included/excluded/skipped/missing
checks: versions + attempts + start/end/duration
verdicts: PASS/FAIL/INVALID/INCONCLUSIVE/NOT_RUN/CANCELLED
artifacts: paths/digests/retention/access
retry/quarantine: original result preserved
claim: exact tested population and limits

Failure Diagnosis را محصول‌محور فرض نکنید

Failure ممکن است از Product، Check، Data، Environment، Infrastructure، Dependency، Configuration، Security control یا Unknown باشد. Evidence packet باید آخرین step، request/response امن، expected/actual relation، State diff، logs/traces، Environment delta و reproduction attempts را فراهم کند. Screenshot alone علت نیست. Owner و ACK/SLA diagnosis را روشن کنید.

FailurePacket
failure_id/run/check/attempt: linked
observed/expected/oracle: exact
last_known_state/stimulus: recorded
evidence: safe logs, trace, state diff, manifest
classification: PRODUCT|CHECK|DATA|ENV|INFRA|DEP|UNKNOWN
confidence/alternatives: explicit
owner/ack/next_probe: time-bounded
correction: classification may be superseded

Quarantine را با Expiry و Exit criteria اداره کنید

Quarantine حذف خاموش Failure از Dashboard نیست. Reason، first/last failure، owner، issue، impact on coverage، expiry، execution cadence، re-entry criteria و escalation لازم است. Check قرنطینه‌شده همچنان ممکن است اجرا شود اما از Gate جدا گزارش شود. Expired quarantine باید Gate را Hold کند یا تصمیم Exception تازه بخواهد؛ Retry count جای Repair نیست.

QuarantineRecord
check/reason/classification/evidence: explicit
introduced_at/owner/issue: linked
gate_effect/coverage_gap: visible
still_runs: yes/no + cadence
expiry: date or condition
reentry: target faults + repeat clean runs + review
exception_authority: named
status: OPEN|REPAIRED|RETIRED|EXPIRED_HOLD

Maintenance را با Change Trial بسنجید

کم‌بودن LOC یا استفاده از Page Object نگهداشت‌پذیری را ثابت نمی‌کند. یک تغییر نماینده—مثلاً rename semantic action، تغییر API schema یا اضافه‌شدن State—را اعمال و files touched، time، Ripple، failure quality، review effort و backward compatibility را ثبت کنید. Maintenance شامل Basis، Product interface، Data، Environment، Framework و Dependency است؛ نه فقط selector repair.

ChangeTrial
change_id: synthetic API field version + UI label change
expected_scope: adapters + contract fixtures
observed_files/checks/runs: recorded
ripple: intended vs accidental
diagnosis/review/repair effort: ranges
regression evidence: target faults retained
decision: KEEP|REFACTOR|REPLACE|DEFER
limit: one authored trial, not maintainability benchmark

Operability یعنی دیگری بتواند سامانهٔ تست را اداره کند

Automation solution یک محصول داخلی است: install, run, observe, diagnose, recover, update و retire دارد. Dashboard، alert، runbook، ownership، capacity، cost، backup، access, incident route و change window لازم‌اند. «نویسنده همیشه حاضر است» Runbook نیست. Bus factor و دسترسی ایران به Registry/Account/Payment/Support باید با mirror/cache/offline fallback قانونی بررسی شود.

AutomationRunbook
service/owner/backup/oncall-boundary: explicit
start/stop/run/select/cancel: commands
known failures: evidence → probe → route
dependency outage: cache/mirror/defer fallback
credential/access: request/revoke; no shared account
artifact retention/capacity/cost: limits
upgrade/rollback/recovery: rehearsed
retire: archive evidence and remove secrets/access

AI-generated Check را Untrusted contribution فرض کنید

AI ممکن است Test skeleton، locator یا داده بسازد، اما می‌تواند API خیالی، assertion tautological، secret leakage، licence ambiguity، flaky wait و false confidence تولید کند. Prompt/Model/vendor/version، input classification، generated diff، reviewer، target-fault run و attribution را ثبت کنید. هیچ داده یا Repository محرمانه‌ای بدون مجوز/کنترل وارد سرویس نشود. Human authority برای merge، Oracle، CI permission و Verdict باقی می‌ماند.

AICheckContribution
purpose: generate synthetic test skeleton
model/tool/version/date: recorded
input: synthetic contract only; no code/secret/user data
output_provenance: diff labelled AI-assisted
review: API truth, oracle independence, security, licence, maintainability
tests: mutation/target-fault + clean run
authority: human reviewer/owner
claim: assistance, not authorship quality or productivity proof

No-code و Record/Playback یک Option محدودند

Recorder می‌تواند Exploration یا Locator bootstrap را سریع کند، اما generated flow باید review، refactor، Oracle، data isolation، secrets control و CI evidence بگیرد. No-code ممکن است برای Task ساده و owner غیرفنی Fit باشد یا در versioning/review/debug/exit محدودیت بسازد. انتخاب باید با همان Probe/ADR انجام شود؛ «چند برابر سرعت» بدون Baseline و Maintenance window ادعا نشود.

Readiness را در چهار سطح مستقل بسنجید

سطح	سؤال	شاهد	ادعای ممنوع
Check	Oracle/fixture/run معتبر است؟	contract + target fault	Product quality
Repository	دیگری build/review می‌کند؟	clean-room handoff	Senior skill
Pipeline	selection/evidence/security عمل می‌کند؟	CI replay	secure CI
Operation	diagnose/repair/recover ممکن است؟	drill + runbook	zero maintenance
Role	Task در Context با Support انجام می‌شود؟	bounded transfer trial	job readiness universal

Clean-room Handoff آزمون تحویل است

Reviewer بدون cache شخص سازنده و بدون راهنمایی خارج از Repository، بسته را در Environment مجاز می‌گیرد، identity/checksum را تأیید، install و run می‌کند، target fault را می‌بیند، یک Failure را تشخیص و change کوچک را review می‌کند. هر prompt شفاهی به‌عنوان missing documentation ثبت می‌شود. موفقیت یک Reviewer نتیجهٔ عمومی دربارهٔ تمام کاربران یا محیط‌ها نیست.

HandoffTrial
package/version/checksum: pinned
receiver/context/support: fictional and bounded
tasks: install, smoke, target fault, diagnose, change review
allowed_docs: repository only
assistance: timestamped; changes outcome classification
artifacts: commands, manifests, findings, repair diff
result: INDEPENDENT|ASSISTED|BLOCKED|INVALID
followup: repair docs/system, then fresh replay

Portfolio را با Claim محدود منتشر کنید

Repository عمومی نباید Product/Employer code، screenshot، URL، account، token، data یا incident واقعی داشته باشد. Synthetic scenario، architecture/ADR، Check contracts، CI manifest، Evidence sample، fault injection، quarantine/repair و Handoff note نشان می‌دهد چه ساخته‌اید. Claim بگویید «در Fixture ساختگی این Failure را تشخیص داد»، نه «Framework enterprise-grade» یا «آمادهٔ Production».

زمان ثابت شش‌ماهه Readiness را تضمین نمی‌کند

زمان به Baseline، ساعت رسمی تمرین، دسترسی، زبان، سلامت، mentor/reviewer، Task complexity و فرصت Transfer وابسته است. روزی دو تا سه ساعت ممکن است برای برخی ناممکن یا ناسالم باشد. Milestone را با Evidence و Support تعریف کنید، نه ماه. Junior/Senior نیز فقط با مدت یا Repository شخصی تعیین نمی‌شود؛ Job analysis و ارزیابی منصفانه لازم است.

ماتریس Milestone بدون تقویم اجباری

Milestone	تحویل	Gate	در صورت Hold
M0 Context	Role/Charter/Risk	Scope bounded	Clarify
M1 Local	one valid Check	target-fault detected	Repair Oracle
M2 Repository	clean install/review	locked/reproducible	fix contract
M3 CI	selection/evidence	missing visible	pipeline repair
M4 Operate	diagnosis/quarantine	owner/expiry	runbook drill
M5 Handoff	receiver replay	independent/assisted labeled	repair/retry

منابع رسمی و حد استفاده

ISTQB CTAL-TAE v2.0 معماری، pilot/deployment، risk، maintainability، CI و configuration management را در Scope syllabus پوشش می‌دهد؛ مدرک، Roadmap اجباری یا آمادگی شغلی را ثابت نمی‌کند.
Playwright Best Practices رفتار کاربر، Isolation، locator و Trace/CI را برای Playwright توضیح می‌دهد؛ برتری جهانی Stack یا Flaky-free بودن را ثابت نمی‌کند.
Selenium Page Object Models نمونه‌ای برای جداسازی interaction concern است؛ معماری واحد همهٔ پروژه‌ها نیست.
npm ci clean/frozen install را در اکوسیستم npm توضیح می‌دهد؛ reproducibility کامل OS/browser/network را تضمین نمی‌کند.
GitHub Actions settings allowlist و full-SHA pinning را نشان می‌دهد؛ به‌تنهایی workflow را امن یا قابل‌اعتماد نمی‌کند.

Delivery Map، قراردادها، Levelها و Gateهای این مقاله synthesis نویسنده‌اند؛ Standard، Certification scheme، Hiring rubric عمومی، Benchmark یا تضمین Product/Role نیستند. نسخه و Context هر منبع را هنگام اجرا دوباره بررسی کنید.

لابراتوار مستقل: بلیط طلایی در برابر ۶۰۲ کنترل

Fixture قدیمی می‌گفت تست دستی ناممکن، Automation بلیط طلایی، Playwright استاندارد، شش ماه تا Junior، AI جایگزین تستر بدون AI و درآمد/امنیت بالا است. Checker سطحی وجود این شش شعار را دید و اعلام کرد:

SIX_MONTH_AUTOMATION_ENGINEER_GOLDEN_TICKET_AI_READY

ممیزی مستقل دقیقاً ۶۰۲ کنترل یکتای group-qualified را در ۴۳ گروه identity، version، decision، role، task، context، risk، charter، scope، testability، architecture، repository، language، stack، dependency، supply_chain، environment، data، oracle، check، ui، api، state، isolation، determinism، execution، ci، trigger، selection، evidence، diagnosis، quarantine، maintenance، operability، security، ai، ownership، handoff، readiness، portfolio، review، correction و limits مطالبه کرد. Fixture هیچ‌کدام را نداشت:

HOLD-602
NO_REAL_LEARNER_REPOSITORY_PIPELINE_PASS

Rule جداگانه تأیید کرد Learner، Worker، Employer، Repository، Pipeline، Product، Secret یا Outcome واقعی وجود ندارد. پس از Pin کردن همهٔ کنترل‌های خیالی، خروجی فقط آمادگی برای بازبینی انسانی بود:

READY_FOR_AUTOMATION_ENGINEERING_DELIVERY_REVIEW-0

صفر Finding ساختاری، حقیقت Risk/Oracle/Data، Coverage، تکرارپذیری محیط واقعی، امنیت Pipeline، نگهداشت‌پذیری، Capability یا Readiness فرد، کیفیت Product، استخدام، حقوق، بهره‌وری یا آیندهٔ AI را ثابت نمی‌کند. Validator فقط presence و uniqueness فیلدهای داده‌شده را کنترل می‌کند.

آزمایشگاه آفلاین فارسی: تحویل ساختگی Checkout

Lab با شناسهٔ SYN-AUTOMATION-DELIVERY-01 هیچ یادگیرنده، کارمند، کارفرما، Repository، Pipeline، Product یا پرداخت واقعی ندارد. Order، PaymentAttempt، PSP Stub، Callback، Ledger و Reconciliation همه ساختگی‌اند؛ شبکه و Production غایب است. سناریو فقط مکانیک State/Evidence/Handoff را تمرین می‌کند.

Synthetic delivery faults
Product-like: duplicate/late/reordered callback; timeout before/after fake commit
Check: copied oracle; fixed sleep; broad locator; missing await
Data: shared identity; dirty reset; Persian/Arabic digit collision
Environment: timezone delta; browser/runtime mismatch; unavailable stub
Pipeline: zero selected; missing artifact; floating dependency; expired quarantine
Locale: ی/ي، ک/ك، ZWNJ، RTL/LTR/Bidi، ۱۲۳/١٢٣/123
Money/time: fictional IRR; labelled toman; UTC/Asia-Tehran/Jalali display

یک Demo سطحی Happy path را محلی Pass می‌کند. Delivery gate آن را Hold می‌گذارد چون target fault تشخیص داده نشده، Oracle از همان helper کپی شده، Data مشترک است، CI صفر Check را سبز کرده و Handoff به cache سازنده وابسته است. پس از اصلاح Fixture ساختگی، نتیجه فقط `READY_FOR_REVIEW` است؛ نه برتری ابزار، مهارت فرد، آمادگی Production یا کیفیت محصول.

برنامهٔ ۳۰روزهٔ Delivery Lab بدون فرد واقعی

روز	کار	خروجی	Gate
۱–۴	Role/Task/Risk/Charter	contracts	Scope bounded
۵–۸	Testability/Stack Probe	ADR	reversible
۹–۱۳	Repo/Data/Oracle/Check	local slice	target fault
۱۴–۱۸	Isolation/API/UI/State	evidence	repeat run
۱۹–۲۲	CI/selection/security	run manifest	missing visible
۲۳–۲۶	diagnosis/quarantine/change	repair packet	expiry/owner
۲۷–۳۰	clean-room handoff	readiness review	claim limits

۲۸ ضدالگوی نقشه راه اتوماسیون

تست دستی ناممکن شده؛
Automation بلیط طلایی شغل است؛
یک Stack استاندارد جهانی؛
زبان بر اساس ترند؛
Title بدون Task؛
دوره برابر Capability؛
شش ماه برابر Junior؛
سال سابقه برابر Senior؛
Framework پیش از Risk/Oracle؛
Demo برابر Delivery؛
Page Object برابر Architecture؛
Check count برابر Coverage؛
Status ۲۰۰ برابر correctness؛
Oracle کپی‌شده از implementation؛
Production data پیش‌فرض؛
Sleep ثابت برای sync؛
Retry برای درمان Flaky؛
Parallelism بدون Isolation؛
لوکال سبز بدون Manifest؛
CI سبز با zero selected؛
Screenshot-only evidence؛
هر Failure یک Product bug؛
Quarantine بدون Owner/expiry؛
Dependency/Action شناور؛
Secret در log/artifact؛
AI output بدون Review/target fault؛
Portfolio با داده/کد واقعی؛
ویرایش خاموش Evidence/Readiness.

چک‌لیست ۳۸سؤالی مالک Delivery

Role/Task/Context نسخه‌دار است؟
Work product و No-authority روشن است؟
Risk/Question/Decision ثبت شده؟
Charter Scope و Exclusion دارد؟
Testability gap سنجیده شده؟
Stack با Probe انتخاب شده؟
Exit/lock-in دیده شده؟
Language با تیم/Runtime Fit است؟
Repository owner/backup دارد؟
Runtime و dependency pin شده؟
Clean install قابل‌اجراست؟
Supply-chain boundary روشن است؟
Architecture concernها جداست؟
Check به Risk trace دارد؟
Oracle مستقل و UNKNOWN دارد؟
Target fault اجرا شده؟
Data synthetic/lineage/reset دارد؟
Namespace و Isolation دارد؟
Time/random/dependency کنترل شده؟
API state/idempotency دیده شده؟
UI locator/actionability معنادار است؟
Wait condition و timeout Evidence دارد؟
First attempt پس از Retry حفظ می‌شود؟
Environment manifest ذخیره می‌شود؟
Trigger و Population روشن است؟
Excluded/skipped/missing دیده می‌شود؟
Zero selected Green نمی‌شود؟
CI permission حداقلی است؟
Secret وارد source/log/artifact نمی‌شود؟
Run manifest/checksum دارد؟
Verdictها PASS/FAIL/INVALID/UNKNOWN جداست؟
Failure alternatives و Owner دارد؟
Quarantine expiry/reentry دارد؟
Change trial نگهداشت اجرا شده؟
Runbook/recovery/retire دارد؟
AI contribution برچسب/Review شده؟
Clean-room handoff انجام شده؟
Readiness/expiry/correction تاریخچه دارد؟

Correction بخشی از مهندسی اتوماسیون است

اگر Oracle tautological، target fault مصنوعی نامعتبر، artifact ناقص، secret leaked، classification غلط، dependency compromised یا Handoff result بیش‌ازحد ادعا شد، نتیجه را بی‌صدا اصلاح نکنید. Finding/Run/Readiness قبلی را withdraw یا supersede، affected decisions را پیدا، دسترسی را مهار، Fixture را تعمیر، Replay تازه اجرا و مصرف‌کنندگان را مطلع کنید.

AutomationCorrection
correction_id: COR-AUT-07
supersedes: RUN-41 / READY-v1
error: expected state generated by production-like helper
affected: two PASS claims and readiness gate
containment: withdraw evidence; disable gate; inspect derivatives
repair: independent model + target-fault replay
notify: owner/reviewer/consumer
history: prior artifacts retained with warning; v2 current

خروجی Automation Engineering Delivery Pack

Role/Task/Outcome/Charter contracts؛
Capability graph و Milestone evidence؛
Testability assessment و Stack Probe/ADR؛
Repository/Dependency/Supply-chain manifests؛
Architecture/Data/Isolation/Check/Oracle contracts؛
Environment/CI/Selection/Run manifests؛
Failure/Quarantine/Repair/Change-trial records؛
Runbook/Ownership/Recovery/Retirement؛
Clean-room Handoff و Readiness packet؛
Portfolio/Review/Expiry/Correction history.

جمع‌بندی

نقشه راه اتوماسیون را از ابزار و تقویم به تحویل مهندسی تبدیل کنید. Role/Task/Risk را روشن، Charter را محدود، Testability و Stack را با Probe، Repository و Dependency را نسخه‌دار، Data/Isolation/Oracle را مستقل، UI/API/State را Evidenceمحور و CI را با Selection/Security/Manifest اداره کنید. Failure را تشخیص، Quarantine را منقضی، Change را تمرین، Runbook را واگذار و Readiness را با Clean-room Handoff بسنجید. هیچ Stack، دوره، AI یا مدت ثابتی استخدام، Level، درآمد یا کیفیت را تضمین نمی‌کند.

سؤالات متداول

برای شروع اتوماسیون Playwright بهتر است یا Selenium؟

پاسخ جهانی ندارد. Product/browser، زبان/تیم، CI، debugging، access، dependency policy، نگهداشت و Legacy را ثبت و یک Risk slice یکسان را با Probe مقایسه کنید. Playwright امکانات یکپارچهٔ مدرن دارد و Selenium اکوسیستم/Legacy گسترده؛ هیچ‌کدام بدون Oracle، Isolation و Evidence پروژه را معتبر نمی‌کند.

آیا برای اتوماسیون باید برنامه‌نویسی حرفه‌ای بلد باشم؟

عمق لازم از Task می‌آید. برای تحویل پایدار معمولاً خواندن/نوشتن کد، async/error، modules/package، data structures، logging، Git، review و debugging لازم است؛ معماری Platform عمق بیشتری می‌خواهد. No-code می‌تواند بعضی Taskها را پوشش دهد اما نیاز به Oracle، Versioning، Diagnosis و Ownership را حذف نمی‌کند.

چند ماه طول می‌کشد تا Automation Engineer شوم؟

عدد ثابت معتبر نیست. Baseline، Task، ساعت رسمی، دسترسی، سلامت، زبان، Reviewer و فرصت Transfer تفاوت می‌سازند. به‌جای شش ماه، Milestoneهای Charter، Check معتبر، Repository، CI، Diagnosis، Handoff و Readiness را با Evidence دنبال کنید. Title/Level را سازمان بر اساس Job analysis تعیین می‌کند.

آیا هوش مصنوعی جای تستر اتوماسیون را می‌گیرد؟

پیش‌بینی قطعی ممکن نیست. AI می‌تواند skeleton، locator یا توضیح Failure بسازد و هم‌زمان assertion غلط، secret leakage یا Flaky ایجاد کند. Taskها ممکن است تغییر کنند؛ Human authority برای Risk، Oracle، Security، Review، Merge و Decision لازم است. یک Probe محلی بهتر از شعار جایگزینی یا عدم‌جایگزینی است.

برای پورتفولیوی اتوماسیون چه چیزی منتشر کنم؟

یک Scenario کاملاً ساختگی با Charter، ADR، Repository contract، Check/Oracle/Data، CI manifest، target-fault Evidence، Failure/Repair، Runbook و Handoff note منتشر کنید. Secret، URL، داده، code یا screenshot کارفرما/Product واقعی را حذف کنید. Claim را به همان Fixture محدود نگه دارید و Demo را Production-ready ننامید.

تست خودکار