گذار از تست دستی به اتوماسیون؛ مسیر شایستگی و پروژه

اگر یک تستر دستی بتواند با Playwright دکمه‌ای را Click کند اما نداند چه ریسکی را می‌سنجد، Expected از کجا آمده، چرا تست سبز شده و شکست به کدام Owner می‌رسد، هنوز به اتوماسیون قابل‌اعتماد نرسیده است. برعکس، تستری که State، Data و Oracle را خوب مدل می‌کند، بخش دشوار مسیر را در اختیار دارد؛ کد فقط راه اجرای تکرارپذیر آن مدل است.

گذار از تست دستی به اتوماسیون، حذف Manual testing یا ارتقای رتبهٔ انسانی نیست. این یک مسیر شایستگی است: Role outcome → Baseline → Foundation → Candidate task → Test design/Oracle → Code → Review → Run evidence → Maintenance → Transfer. هدف این راهنما ساخت کوچک‌ترین Artifact خودکار، امن، قابل‌اجرا و قابل‌نگهداری است که برای یک تصمیم واقعی Evidence بدهد—نه تکمیل فهرست ابزار، تعداد اسکریپت یا وعدهٔ درآمد و استخدام.

تست دستی و اتوماسیون رقیب یکدیگر نیستند

«Manual» شیوهٔ اجراست، نه سطح حرفه‌ای؛ «Automated check» نیز Evidence خودکار است، نه جایگزین تفکر تست. یک انسان می‌تواند با ابزار، اکتشاف عمیق انجام دهد و یک Pipeline می‌تواند هزار Check سطحی را بی‌فایده تکرار کند. تحلیل ریسک، پرسش‌گری، طراحی مدل، شناخت Domain، انتخاب Oracle، تفسیر نتیجه و کشف ناشناخته‌ها همچنان انسانی و زمینه‌ای‌اند.

کار	Manual/Exploratory مناسب‌تر است وقتی…	Automation مناسب‌تر است وقتی…	ترکیب رایج
یادگیری قابلیت تازه	مدل و Risk هنوز ناشناخته‌اند	فرضیهٔ مشخص قابل سنجش است	Explore سپس Check پایدار
Regression	سناریو کم‌تکرار یا پرنوسان است	تکرار، Oracle و محیط کنترل‌پذیرند	Suite خودکار + Explore تغییرات
Accessibility	تجربه با فناوری کمکی و قضاوت لازم است	قاعدهٔ ماشینی قابل بررسی است	Scanner + Keyboard/screen-reader
Performance	فرضیه و مشاهدهٔ رفتار لازم است	بار، Measurement و تکرار لازم‌اند	طراحی انسانی + اجرای ابزار
پرداخت	State/Failure mode کشف می‌شود	Idempotency و Reconciliation تکرار می‌شوند	Model-based exploration + checks

برای فهم اینکه چه چیزی اصلاً Candidate مناسبی است، ابتدا راهنمای اتوماسیون تست، مزایا و هزینه را ببینید. تصمیم Portfolio و Scale سازمانی نیز موضوع استراتژی اتوماسیون تست است؛ مقالهٔ حاضر فقط مسیر شایستگی فردی را مالک است.

نیت جست‌وجو و کلمات کلیدی

کلیدواژهٔ اصلی: گذار از تست دستی به اتوماسیون. کلیدواژه‌های ثانویه و Long-tail: تبدیل تستر دستی به تستر اتوماسیون، نقشه راه اتوماسیون تست، یادگیری اتوماسیون برای تستر دستی، مسیر Automation Tester، مهارت‌های مهندس اتوماسیون تست، زبان برنامه نویسی برای تستر، Python یا JavaScript برای تست، Playwright برای مبتدی، Selenium برای تستر دستی، پروژه تمرینی اتوماسیون تست، پورتفولیو Automation QA، CI برای تست خودکار، Test Automation Engineer roadmap، چگونه تستر اتوماسیون شویم و مسیر شغلی QA Automation در ایران.

این جست‌وجو معمولاً تصمیم‌محور است: از کجا شروع کنم، چه چیزی یاد بگیرم، کدام ابزار را انتخاب کنم، چه پروژه‌ای بسازم و از کجا بفهمم آماده‌ام؟ پاسخ باید Role-specific، شواهدی و قابل‌تمرین باشد؛ نه فهرست Trendها یا بازهٔ زمانی قطعی.

گام صفر: Role Contract بنویسید

عنوان‌های QA Automation، SDET، Test Automation Engineer و Quality Engineer قرارداد جهانی ندارند. یک نقش ممکن است فقط UI suite نگه دارد؛ نقش دیگر Library، Service test، CI، Testability و ابزار توسعه بسازد. پیش از خرید دوره، پنج آگهی واقعی و Repository/فرایند تیم هدف را تحلیل کنید؛ آگهی محبوبیت صنعت را ثابت نمی‌کند، فقط Context هدف شما را نشان می‌دهد.

Target Role Contract
Product/domain and users: ______
Decisions the role supports: ______
Tasks: design | implement | review | run | triage | maintain | enable
Layers: unit/component | API | contract | UI | performance | security
Languages/repositories/runtime: ______
CI/environment/data/dependency model: ______
Evidence and artifact expectations: ______
Authority and explicit non-responsibilities: ______
Support/reviewer/mentor available: ______
Constraints: time, hardware, access, English, Iran/vendor limits
Proof of readiness and recheck date: ______

نقش هدف را به Task تبدیل کنید

Task واقعی	Knowledge	Skill	Artifact	Evidence استقلال
افزودن API check	HTTP، schema، auth، state	کد، assertion، fixture	Test + data + README	اجرا و Debug روی variant تازه
نگهداری UI check	DOM/accessibility، async	Locator، isolation، trace	PR و failure evidence	رفع تغییر واقعی بدون false green
اتصال به CI	event/job/runner/artifact	YAML، secret، exit code	Workflow و Run link	Triage failure و rerun policy
Review تست	Risk، Oracle، maintainability	Evidence-led comment	Review record	کشف ضعف معنایی نه فقط style
بهبود Testability	architecture/observability	قرارداد با developer	Hook/API/telemetry proposal	کاهش workaround با Guardrail

گام اول: Baseline واقعی بگیرید

Baseline آزمون شخصیت یا مصاحبهٔ حفظی نیست. یک Task کوچک با زمان، منابع مجاز و امکان کمک تعریف کنید و مشاهده کنید فرد چگونه سؤال می‌پرسد، مدل می‌سازد، کد را اجرا می‌کند، شکست را عیب‌یابی و نتیجه را توضیح می‌دهد. «ندیده‌شده» را Fail ننویسید.

Baseline Task: parser مبلغ پرداخت ساختگی
Test basis: IRR canonical؛ ورودی رقم فارسی/عربی/لاتین؛ صفر/حد/نامعتبر
Given assets: repository, README, one broken implementation, test runner
Observe: clarify, partitions/boundaries, oracle, code literacy, run/debug, Git diff
Allowed support: docs/search/pairing; AI only with disclosure and verification
Evidence: test cases, run output, explanation, assumptions, unresolved questions
States per skill: NOT_OBSERVED | GUIDED | INDEPENDENT | ADAPTIVE | ENABLES_OTHERS
Not used for: personality, worth, automatic hiring/promotion or fixed career label

دارایی‌های تست دستی را حفظ کنید

• مدل ذهنی Product و User journey.
• Risk identification و سؤال از Requirement.
• Equivalence partition، Boundary، State و Decision table.
• تشخیص Oracle مبهم و Evidence ناکافی.
• Exploratory testing و یادگیری از نتیجهٔ غیرمنتظره.
• Bug reproduction، Communication و Domain knowledge.
• تفکیک Severity، Priority، release risk و authority.

گذار سالم این توانایی‌ها را به کد منتقل می‌کند؛ آن‌ها را با «مثل Developer فکر کن» پاک نمی‌کند. توسعه‌دهنده، تستر، محصول و عملیات دیدگاه‌ها و مسئولیت‌های متفاوت اما همپوشان دارند.

گام دوم: Stack را از Context انتخاب کنید

Python، JavaScript/TypeScript، Java، Kotlin و C# هیچ‌کدام بهترین نقطهٔ شروع برای «اکثر مردم» نیستند. هزینهٔ Context switch، زبان محصول، Library موجود، Reviewer، Runner، بازار هدف، مستندات، پایداری Dependency و محدودیت دسترسی مهم‌اند.

Context	گزینهٔ محتمل	سؤال تعیین‌کننده	دام
Frontend/Node تیم	TypeScript/JavaScript	آیا Repo و Reviewer همین Stack را دارند؟	یادگیری UI بدون Test design
Backend JVM	Java/Kotlin	تست‌ها کنار Service اجرا می‌شوند؟	OOP/Pattern نمایشی
.NET	C#	Fixture و CI سازمان چیست؟	ساخت Framework موازی
API/Data/Script lab	Python یا Stack تیم	آیا هدف Prototype است یا asset تولیدی؟	انتخاب فقط به‌خاطر Syntax ساده
Mobile	زبان/Framework اکوسیستم	Native، cross-platform یا external driver؟	شروع با Tool پیش از architecture

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

Decision and candidate task
Product/repository/runtime fit
Team ownership and available review
Layer/protocol/browser/mobile needs
Debugging, trace and artifact support
Isolation/data/dependency controls
CI runner and operating-system support
Accessibility and documentation quality
License, update, security and supply-chain policy
Iran network/sanction/payment/mirror/exit constraints
Time-boxed spike / acceptance / rejection / fallback

Selenium در مستندات رسمی خود عامدانه از عبارت «Best Practices» مطلق فاصله می‌گیرد و تأکید می‌کند ابزار مرورگر، Suite خوش‌معماری را به‌خودی‌خود نمی‌سازد. منبع: Test Practices رسمی Selenium. این هشدار برای هر Framework معتبر است.

گام سوم: بنیادهای برنامه‌نویسی را Task-driven یاد بگیرید

فهرست Syntax را حفظ نکنید؛ هر مفهوم را در یک مسئلهٔ تست به‌کار ببرید:

بنیاد	کاربرد در تست	شاهد
Type/value/Unicode	تفکیک مقدار، نمایش و ورودی فارسی/عربی	Table-driven parser tests
Condition/loop	ساخت Data set؛ نه Logic پنهان در Test	Cases خوانا و محدود
Function/module	Fixture، helper و domain action	Interface کوچک با Unit test
Error/exception	تمایز product failure از test failure	Explicit error taxonomy
Async/time	Callback، retry و eventual consistency	Clock/polling contract
Data structure	Expected state و result mapping	Typed/schema-validated records
Dependency	Runner/library/version	Lockfile و reproducible install
Logging/debug	First divergence و triage	Sanitized trace/artifact

OOP و Pattern هدف نیستند

Class، inheritance، Page Object، Factory یا abstraction فقط وقتی مفیدند که تغییر را محلی، Intent را روشن یا تکرار پرهزینه را کم کنند. Abstraction زودهنگام می‌تواند شکست را پنهان و Debug را سخت کند. کد ساده و کمی تکرار گاهی بهتر از Framework عمومیِ بدون مصرف‌کننده است.

گام چهارم: Git، Review و Dependency را از روز اول وارد کنید

• Commit کوچک با پیام دربارهٔ Intent و Risk.
• Branch/PR مطابق فرایند تیم؛ نه Workflow حفظی.
• Diff خوانا بدون Secret، فایل تولیدی یا Formatter noise.
• README شامل Install، Run، Version، Data و Known limitation.
• Lockfile و نسخهٔ Runtime؛ Update policy و Vulnerability review.
• Code review برای Oracle، Isolation، Safety و maintainability؛ نه فقط Style.
• Issue برای بدهی، Flake و Unsupported assumption.

برای یک Review تصمیم‌محور از راهنمای بازبینی تست‌کیس و کد تست استفاده کنید. Git مهارت لازم بسیاری از تیم‌هاست، اما «الزام مطلق همهٔ نقش‌ها» نیست؛ نقش هدف و فرایند سازمان تعیین‌کننده‌اند.

گام پنجم: Candidate درست را انتخاب کنید

اولین پروژه نباید Login UI عمومی یا Framework عظیم باشد، مگر همان مسئلهٔ نقش هدف باشد. Candidate کوچک باید تکرارپذیر، Oracle‌پذیر، داده‌پذیر، کم‌خطر و قابل‌Review باشد.

Automation Learning Slice
Decision and risk: ______
Test basis/version/source: ______
Candidate and why automation helps: ______
Why manual/exploration still remains: ______
Layer/protocol and system boundary: ______
Stimulus / state / data / oracle: ______
Environment/dependency/fidelity: ______
Result/evidence/triage owner: ______
Safety/privacy/cleanup: ______
Build-review-run-maintain-transfer tasks: ______
Done, stop and rollback criteria: ______

ترتیب پیشنهادی، نه قانون جهانی

1. Pure function یا parser با Table-driven tests.
2. API/contract کوچک با state و schema روشن.
3. Integration با Test double و دادهٔ کنترل‌شده.
4. UI check کوتاه برای رفتار کاربر، اگر Risk در UI است.
5. CI execution، artifact و triage.
6. Maintenance روی تغییر واقعی.
7. Variant تازه برای سنجش Transfer.

این ترتیب Feedback و Debug را ساده می‌کند، اما اگر نقش هدف Mobile، Embedded یا Performance است باید Learning Slice تغییر کند. Test Pyramid دستور نسبت ثابت یا مسیر یادگیری جهانی نیست.

گام ششم: Test basis، Risk و Oracle را قبل از کد بنویسید

یک اسکریپت بدون منبع Expected، فقط رفتار فعلی را ثبت می‌کند. این قرارداد را پیش از Implementation کامل کنید:

Automated Check Contract
Check ID / risk / decision
Test-basis source IDs and version
Precondition / identities / initial state
Input dimensions and selected technique
Stimulus / observation boundary
Expected result and independent oracle source
Timing/eventual-consistency rule
Environment/data/dependency versions
Result states: PASS | FAIL | ERROR | INCONCLUSIVE | SKIPPED
Evidence on each state / privacy redaction
Cleanup and side-effect control
Owner / review / expiry / known blind spots

Expected را از همان کدی نسازید که می‌آزمایید. UI toast ممکن است «پرداخت ثبت شد» بگوید اما Ledger دو بار Credit شده باشد. PASS یعنی مشاهدات تعریف‌شده با Oracle همان Check سازگارند؛ کیفیت کل Product یا آمادگی Release را ثابت نمی‌کند.

گام هفتم: UI Automation را مقاوم و قابل‌عیب‌یابی کنید

در تست UI، Selector، Wait، State، Data و Evidence پنج منبع خطای رایج‌اند. مستندات رسمی Playwright Best Practices توصیه می‌کند رفتار قابل‌مشاهدهٔ کاربر، Isolation هر تست، Locatorهای کاربرمحور و Web-first assertion در اولویت باشند. این راهنما مختص Playwright است؛ قواعدش را کورکورانه به ابزار یا معماری دیگر منتقل نکنید.

ضعیف	بهتر	دلیل
CSS/XPath شکننده	Role/label/test contract یکتا	Intent و Accessibility نزدیک‌تر
sleep ثابت	شرط observable با timeout	کاهش race و انتظار اضافی
Test وابسته به Test قبلی	State/Data مستقل	بازتولید و Parallelism
Retry تا سبز	حفظ attempt و triage علت	جلوگیری از false green
Screenshot تنها	Trace/log/network/state sanitized	تشخیص first divergence
Page Object عظیم	Domain action کوچک و cohesive	کاهش coupling

گام هشتم: API، داده و پایگاه داده را با مرز درست یاد بگیرید

• HTTP method/status/header/body/schema و semantic error را تفکیک کنید.
• Authentication را با Authorization اشتباه نگیرید.
• Identity، idempotency، retry و ordering را صریح کنید.
• Fixture را نسخه‌دار، حداقلی، Synthetic و قابل Cleanup نگه دارید.
• DB را فقط اگر Oracle مجاز است Query کنید؛ Coupling داخلی می‌تواند Test را شکننده کند.
• Eventual consistency را با Deadline/Poll interval/terminal state تعریف کنید.
• Mock/Stub را Contract و Fidelity‌دار ببینید؛ پاسخ ساختگی Production را ثابت نمی‌کند.
• Secret، PAN، OTP، Token و دادهٔ مشتری را در Repo/Artifact/Log نگذارید.

گام نهم: CI فقط اجرای خودکار نیست

یک Workflow باید Trigger، Commit، Artifact، Environment، Dependency، Exit semantics، Result و Evidence را قابل‌ردیابی کند. GitHub Actions در مستندات رسمی Workflow را فرایندی YAMLمحور با Event، Job، Runner و Step تعریف می‌کند؛ منبع: GitHub Actions Workflows. این مدل محصول GitHub است و YAML آن نسخه/امنیت خاص خود را دارد.

CI Run Evidence
run_id / commit_sha / branch-or-PR / trigger / actor class
workflow and test-suite version
runner OS/image/runtime/dependency lock hash
environment/config/data/dependency identities
selected tests and selection reason
initial/final result + every attempt
duration/queue/shard and missing-result state
sanitized report/trace/log/artifact links + retention
failure owner / triage decision / rerun-quarantine policy

برای پیاده‌سازی امن‌تر در Pipeline، راهنمای تست خودکار در GitLab CI هویت Run، Artifact، Secret و Triage را عمیق‌تر پوشش می‌دهد؛ مفاهیم را تطبیق دهید، Syntax را کپی نکنید.

گام دهم: Maintenance بخشی از شایستگی است

ساختن اولین Test کمتر از مالکیت عمر آن اطلاعات می‌دهد. Candidate باید تغییر Requirement، Dependency، Locator، Data، Environment و Failure واقعی را تجربه کند. شایستگی وقتی دیده می‌شود که فرد بتواند first divergence را بیابد، Product failure را از Test/Infra failure جدا کند، Oracle را اصلاح کند و false green نسازد.

Failure class	سؤال Triage	تصمیم محتمل
Product	رفتار با Test basis معتبر ناسازگار است؟	Defect/risk route
Test code	Stimulus/Oracle/cleanup اشتباه است؟	Fix + regression for test
Data/environment	Precondition یا identity معتبر بود؟	Repair/invalid run
Dependency	Contract/Fidelity/availability تغییر کرده؟	Stub, retry bounded, escalate
Flaky/unknown	Evidence برای علت کافی است؟	Quarantine محدود یا INCONCLUSIVE
Expected change	Test basis نسخه‌اش عوض شده؟	Review و update همراه traceability

بهینه‌سازی سرعت، Parallelism و Sharding مرحلهٔ بعد از Correctness و Trusted signal است؛ راهنمای بهینه‌سازی Regression suite این مسئله را جداگانه پوشش می‌دهد.

هوش مصنوعی و Codegen: Draft، نه Evidence

Recorder، Copilot و LLM می‌توانند Skeleton، Locator، Data idea یا توضیح خطا پیشنهاد دهند؛ اما منبع Requirement، Oracle مستقل، Permission و مسئول نتیجه نیستند. کد تولیدشده را بخوانید، Dependency و License را بررسی کنید، Secret و Prompt injection را کنترل کنید، اجرا و Negative test انجام دهید و کمک AI را در Portfolio/Review افشا کنید.

• ورودی سازمانی یا دادهٔ مشتری را به ابزار تأییدنشده ندهید.
• کد پیشنهادی را با API/نسخهٔ رسمی بررسی کنید.
• Assertion را از خروجی مدل بدون Test basis نپذیرید.
• Generated test را طوری Fault-inject کنید که حداقل یک‌بار درست شکست بخورد.
• AI pass rate را معیار شایستگی یا کیفیت ندانید.

پروژهٔ عملی ایرانی: قابلیت‌اعتماد پرداخت

به‌جای Demo login، یک Lab کاملاً ساختگی بسازید که به مسئلهٔ Domain نزدیک‌تر است و هیچ PSP یا دادهٔ واقعی را افشا نمی‌کند:

• هویت: Order، Payment Attempt، PSP reference و Idempotency key.
• پول: IRR مقدار Canonical؛ تومان فقط Display با Label و تبدیل صریح.
• ورودی: رقم فارسی، عربی و لاتین؛ صفر، حد، نامعتبر و Overflow.
• State: Initiated، Pending، Paid، Failed، Unknown و Reconciled.
• Failure: timeout پیش/پس از Commit، Callback تکراری/دیررس و Retry کاربر/Client.
• Oracle: Order، Ledger، Outbox، PSP stub و Reconciler؛ نه فقط Toast.
• زمان: UTC در Event؛ Asia/Tehran و شمسی فقط Presentation.
• Evidence: Table/State model، code، lockfile، run، trace، mutation result و Caveat.
• Safety: داده/Token/Endpoint ساختگی، Side-effect sink و Cleanup idempotent.

Transfer challenge
Variant A: Callback arrives before browser return
Variant B: disconnect after PSP commit but before client response
Variant C: two retries share/don't share idempotency key
Variant D: Persian ۱۰۰۰۰ / Arabic ١٠٠٠٠ / Latin 10000
Variant E: day boundary UTC versus Asia/Tehran

For each: risk → initial state → events → expected terminal/inconclusive state
→ independent oracle → evidence → cleanup → known fidelity gap

آزمایش بازتولیدپذیر: Happy path یا Oracle تصمیم‌محور؟

یک پیاده‌سازی صحیح و شش Mutant کاملاً ساختگی با Node.js ۲۴.۱۸.۰ اجرا شدند. هر Mutant یک خطای هدفمند داشت: Credit تکراری، Failed شدن timeout-after-commit، نبود Reconciliation، تومان به‌عنوان مقدار Canonical، نپذیرفتن رقم فارسی یا هویت ناپایدار.

Suite سطحی

assert(result.ui === "پرداخت ثبت شد")

correct           PASS
duplicate_credit  PASS
timeout_failed    PASS
no_reconcile      PASS
toman_canonical   PASS
latin_only        PASS
unstable_identity PASS
HAPPY_MUTANTS_KILLED=0/6

Suite تصمیم‌محور

Suite دوم دقیقاً شش قرارداد نویسنده را بررسی کرد: Parse مبلغ ۱۰٬۰۰۰، Currency=IRR، یک Credit، state=paid پس از Commit، Reconciliation حاضر و هویت پایدار.

correct           decision=PASS
duplicate_credit  decision=FAIL
timeout_failed    decision=FAIL
no_reconcile      decision=FAIL
toman_canonical   decision=FAIL
latin_only        decision=FAIL
unstable_identity decision=FAIL
DECISION_MUTANTS_KILLED=6/6

تفسیر و محدودیت آزمایش

برای همین Program، Mutant و Oracle، Happy path هیچ Fault را آشکار نکرد و Suite دوم همه را آشکار کرد. این نتیجه عمداً ساخت نویسنده و تا حدی دایره‌ای است: Faultها با Assertionهای Suite دوم هم‌راستا طراحی شده‌اند. Mutation واقعی، پوشش Production، قابلیت فرد، کیفیت Framework، برتری Layer/Tool، احتمال Defect، ارزش اقتصادی یا آمادگی شغلی را نمی‌سنجد. Randomness هم در مسیر هویت Mutant به نتیجهٔ تصمیمی وارد نشد؛ صرفاً Flag ناپایداری بررسی شد. از عدد ۰/۶ یا ۶/۶ به‌عنوان Benchmark، Coverage target، مصاحبه یا رتبه‌بندی انسان استفاده نکنید. پیام محدود این است: سبزی یک Check تنها درباره Oracle همان Check اطلاعات می‌دهد و باید نشان دهید Test روی Fault هدفمند درست شکست می‌خورد.

برای تمرین گسترده‌تر تولید ورودی و Shrink به‌جای چند Example دست‌چین، راهنمای تست مبتنی بر ویژگی مسیر بعدی مناسبی است؛ PBT نیز Oracle و Model درست را جایگزین نمی‌کند.

نردبان شایستگی: از مشاهده تا توانمندسازی

سطح	رفتار قابل‌مشاهده	Evidence	حد اختیار
Not observed	فرصت معتبر نداشته	هیچ	نه Fail و نه مجوز
Observe/Explain	Run و اجزا را توضیح می‌دهد	Annotated run	Sandbox
Guided	با Pair یک Check را تغییر می‌دهد	PR + reflection	Review اجباری
Independent	Slice مشابه را build/run/triage می‌کند	Accepted artifact	دامنه و Risk محدود
Adapt	روی Variant تازه Model و Trade-off می‌سازد	Transfer task	Contextهای تأییدشده
Enable	دیگری را با Guardrail مستقل می‌کند	Guide/review/outcome	بدون تصاحب کار

Competency Card قابل‌کپی

Capability and target task/context/risk
Baseline state and evidence
Knowledge gaps / practice slice / support
Test basis/risk/technique/oracle quality
Code correctness/readability/debugging
Data/environment/dependency/isolation
CI result/evidence/triage
Security/privacy/license/accessibility
Review response and contribution boundaries
Maintenance incident or change handled
Transfer variant and delayed recheck
Level: NOT_OBSERVED | OBSERVE | GUIDED | INDEPENDENT | ADAPT | ENABLE
Reviewer calibration / learner reflection / next boundary
Not for personality, universal seniority or automatic employment decision

Portfolio باید فرآیند تصمیم را نشان دهد

• README با مسئله، Risk، Test basis، Run و محدودیت.
• یک Diagram یا State/Decision model.
• کد ساده، Lockfile، CI و Artifact Sanitized.
• یک Test که روی Fault عمدی Fail می‌شود.
• نمونهٔ Failure triage و Maintenance change.
• Contribution خودتان در برابر Template/AI/Pair/team.
• License، دادهٔ Synthetic، نسخه و Review date.
• بخشی با «چه چیزی را ثابت نمی‌کند».

برای تبدیل این شواهد به معرفی حرفه‌ای بدون ادعای اغراق‌آمیز، راهنمای پورتفولیو و برند شخصی QA را ببینید. Repo عمومی الزامی نیست؛ Permission و مالکیت سازمان بر نمایش مقدم‌اند.

برنامهٔ ۳۰/۶۰/۹۰ روزهٔ تطبیقی

این اعداد وعدهٔ زمان تبدیل‌شدن یا استخدام نیستند؛ فقط Cadence بازبینی‌اند. فرد می‌تواند سریع‌تر، آهسته‌تر یا با ترتیب دیگری پیش برود. عبور هر Gate بر Evidence است، نه رسیدن تقویم.

بازهٔ نمونه	تمرکز	Deliverable	Gate شواهدی
روز ۱–۱۰	Role Contract و Baseline	Task map و Gap backlog	هدف/پشتیبانی/مرز روشن
روز ۱۱–۳۰	Language/Git/runner و pure/API slice	Repo کوچک با Contract و Run	Guided build/debug/review
روز ۳۱–۴۵	Data/state/dependency و negative test	Fault-sensitive suite	Oracle از implementation مستقل
روز ۴۶–۶۰	UI یا Layer نقش هدف و CI evidence	PR + workflow + artifact	Isolation، safety و triage
روز ۶۱–۷۵	تغییر واقعی و Maintenance	Change/incident record	بدون retry-to-green/false green
روز ۷۶–۹۰	Transfer به Variant تازه	Independent slice + reflection	Review کالیبره و مرز اختیار

اگر Mentor و Review در دسترس نیست، Pair با Peer، Open-source issue کوچک یا Self-review ضبط‌شده می‌تواند کمک کند، اما جای بازخورد مستقل را کامل نمی‌گیرد. الگوی طراحی مسیر یادگیری و استقلال امن در راهنمای آنبوردینگ تستر آمده است.

سنجه‌های پیشرفت که کمتر بازی‌پذیرند

سنجه	تعریف	Countermetric	کاربرد
Accepted slice yield	Artifact پذیرفته / Slice بازبینی‌شده	Risk/complexity/edit effort	بهبود تمرین
Independent reproduction	اجرای مستقل موفق / تلاش معتبر	setup time و environment variance	README/lock repair
Fault sensitivity	Fault هدفمند آشکارشده / Fault معتبر	representativeness و equivalent mutant	تقویت Oracle
Triage accuracy sample	طبقه‌بندی بازبینی‌شده در Sample	Unknown و inter-reviewer agreement	تمرین Debug
Maintenance effort	زمان فهم/اصلاح/Review تغییر	false green و readability	Refactor یا retire
Transfer evidence	Task تازه با سطح استقلال توافقی	support/context/difficulty	گسترش مرز
Delayed retention	بازاجرا/توضیح پس از فاصله	ابزار/requirement change	بازیابی یا تمرین
Learning cost/health	زمان/پول/خستگی/دسترسی	کیفیت و پایداری زندگی	کندکردن/تغییر مسیر

تعداد Test، Line of code، Course، Certificate، Commit، Tool یا Automation percentage را برای رتبه‌بندی فرد به‌کار نبرید. دادهٔ یادگیری می‌تواند حساس باشد و باید با رضایت، دسترسی محدود، مدت نگهداری و حق اصلاح مدیریت شود.

شرایط ایران و بودجهٔ یادگیری

• دسترسی و پرداخت ابزار Cloud، Course و Browser farm را پیش از وابستگی آزمایش کنید.
• مستندات، Package و Container مجاز را Cache/Mirror کنید؛ License و امنیت را حفظ کنید.
• مسیر Local/offline با Runner کم‌هزینه و Dataset ساختگی داشته باشید.
• هزینه را با نرخ روز و واحد روشن IRR/تومان ثبت کنید؛ تبدیل را صریح کنید.
• Repo/Artifact را Export کنید و Vendor exit داشته باشید.
• Secret را برای دورزدن محدودیت در Config/Chat/Repo منتشر نکنید.
• English-only بودن را با واژه‌نامه و Pairing کاهش دهید؛ ترجمهٔ AI را تأیید کنید.
• زمان یادگیری را با کار/سلامت/مراقبت سازگار کنید؛ شب‌کاری معیار انگیزه نیست.

چه زمانی مسیر را Pause یا تغییر دهیم؟

• Role هدف اتوماسیون کدنویسی نمی‌خواهد یا مسیر دیگری ارزش بیشتری دارد.
• هیچ Testability، Environment، Data یا Review support وجود ندارد.
• ابزار انتخابی با Repository/تیم/دسترسی ایران سازگار نیست.
• تمرین فقط Tutorial را تکرار می‌کند و Transfer رخ نمی‌دهد.
• Suite دائماً سبز است اما Fault هدفمند را نمی‌بیند.
• یادگیری به سلامت، کار اصلی یا حریم خصوصی آسیب می‌زند.
• سازمان Automation را بهانهٔ حذف اکتشاف یا کاهش نیروی غیرمنصفانه کرده است.

Automation تنها مسیر رشد QA نیست. تخصص Domain، Accessibility، Performance، Security، Test analysis، Product quality، Leadership یا Testability مسیرهای معتبر دیگری‌اند. Pause شکست نیست؛ ممکن است Role Contract اشتباه بوده باشد.

چک‌لیست آمادگی برای یک Automation task مستقل

1. Decision، Risk و Scope را می‌توانم توضیح دهم.
2. Test basis و نسخهٔ آن ثبت شده است.
3. Candidate واقعاً از Automation سود می‌برد.
4. بخش Manual/Exploratory باقی‌مانده روشن است.
5. Layer و ابزار با Context نقش تناسب دارند.
6. زبان، Runner و Dependency را می‌توانم نصب و Debug کنم.
7. Git diff کوچک و Reviewable است.
8. Input technique و Boundaryها مستندند.
9. Oracle منبع مستقل و محدودیت دارد.
10. Identity، state، time و retry مدل شده‌اند.
11. Data ساختگی/مجاز و Cleanup قابل‌اعتماد است.
12. Test از Test دیگر مستقل است یا وابستگی صریح دارد.
13. Wait/timeout شرط observable دارد.
14. هر Result state Evidence مناسب دارد.
15. Secret/PII/License/Supply chain بررسی شده‌اند.
16. Check روی یک Fault هدفمند درست Fail شده است.
17. CI Run به Commit/Environment/Artifact وصل است.
18. Failure owner و Triage policy معلوم است.
19. یک تغییر یا Variant تازه را نگهداری کرده‌ام.
20. Reviewer مرز استقلال و Recheck را تأیید کرده است.

ضدالگوهای گذار به اتوماسیون

• تحقیر Manual tester یا معرفی Automation به‌عنوان ارتقای انسانی.
• وعدهٔ درآمد، امنیت شغلی یا آمادگی در ۶/۱۲ ماه.
• انتخاب Python/Java/JavaScript چون «بهترین برای همه» است.
• شروع با Framework عمومی پیش از یک Test مفید.
• Automate کردن Test case ضعیف بدون Risk و Oracle.
• تمرکز انحصاری بر UI و Login demo.
• Sleep، Selector شکننده و Testهای وابسته.
• Retry تا سبز و حذف Attempt اول.
• Expected ساخته‌شده از همان Implementation.
• Page Object/Pattern پیچیده برای نمایش مهارت.
• Mock کردن همه‌چیز و ادعای Production confidence.
• Copy-paste از AI/Recorder بدون فهم و Disclosure.
• قرار دادن Token، Screenshot یا Production data در Repo.
• سنجش با Test count، code coverage یا LOC.
• تکمیل Course بدون Review، Maintenance و Transfer.
• ساخت Pipeline بدون Artifact و Triage owner.
• اعلام PASS به‌عنوان تضمین کیفیت/Release.
• حذف اکتشاف انسانی پس از Automation.
• تبدیل هر تستر به یک نقش واحد بدون انتخاب و Accommodation.
• نادیده‌گرفتن هزینه، دسترسی، سلامت و مسیر جایگزین.

جمع‌بندی: از اجرای اسکریپت تا مالکیت Evidence

مسیر تست دستی به اتوماسیون با Tool شروع نمی‌شود؛ با Role، Task، Risk و Oracle شروع می‌شود. دانش تست را حفظ کنید، Stack را از Context انتخاب کنید، بنیاد کد را در Slice کوچک تمرین کنید، Artifact را با Git/Review/CI قابل‌ردیابی سازید، روی Fault هدفمند شکست آن را ببینید و سپس Maintenance و Transfer را تجربه کنید. عنوان جدید زمانی معنا دارد که بتوانید Evidence خودکار قابل‌اعتماد را بسازید و مسئولانه نگه دارید—نه فقط وقتی Syntax را می‌دانید.

سؤالات متداول گذار از تست دستی به اتوماسیون

بهترین زبان برنامه‌نویسی برای شروع اتوماسیون تست چیست؟

بهترین زبان جهانی وجود ندارد. زبان Repository و تیم هدف، نوع محصول، Layer تست، Reviewer، Runtime/CI، دسترسی به Dependency و مسیر شغلی خود را مقایسه کنید. TypeScript برای تیم Node، Java/Kotlin برای JVM، C# برای .NET و Python برای بعضی Lab/API/Data contextها ممکن است انتخاب خوبی باشند؛ با یک Spike کوچک تصمیم را آزمایش کنید.

تبدیل تستر دستی به Automation Engineer چقدر زمان می‌برد؟

عدد عمومی معتبری وجود ندارد. Baseline، نقش هدف، زمان، زبان، Mentor/Review، محیط تمرین و سطح استقلال موردنیاز تفاوت بزرگی می‌سازند. ۳۰/۶۰/۹۰ را فقط Cadence بازبینی بدانید؛ آمادگی را با Artifact پذیرفته‌شده، Maintenance و Transfer به Task تازه بسنجید.

آیا اتوماسیون تست جای تست دستی را می‌گیرد؟

خیر؛ دسته‌بندی نیز ساده نیست. Automation برای Check تکرارپذیر با Oracle روشن عالی است، اما کشف ناشناخته، مدل‌سازی ریسک، مشاهدهٔ تجربهٔ انسانی و تفسیر نتیجه نیازمند کار انسانی‌اند. یک Strategy سالم Automation، Exploration و Testability را بر اساس Risk ترکیب می‌کند.

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

یک مسئلهٔ کوچک اما غنی مانند parser مبلغ، state پرداخت یا API contract بهتر از Framework بزرگ بی‌مصرف است. Test basis، Risk، Data، Oracle، code، lockfile، CI run، یک Fault عمدی، Triage، Maintenance change، دادهٔ Synthetic و محدودیت‌ها را نشان دهید. سهم Template/AI/همکار را نیز افشا کنید.

از کجا بفهمم برای اولین کار اتوماسیون مستقل آماده‌ام؟

وقتی در یک دامنهٔ محدود بتوانید Risk و Oracle را توضیح دهید، Slice را بدون Copy کور بسازید، نتیجه را بازتولید و عیب‌یابی کنید، Review را اعمال کنید، Secret/Data را امن نگه دارید، یک تغییر واقعی را نگهداری و همین توانایی را روی Variant تازه منتقل کنید. استقلال همیشه Context و Risk مشخص دارد؛ مجوز جهانی نیست.