استراتژی اتوماسیون تست؛ قالب عملی از Pilot تا Scale

تیم ۸۰۰ تست UI خودکار دارد، Coverage اتوماسیون را ۸۰٪ اعلام می‌کند و Suite چهار ساعت طول می‌کشد؛ بااین‌حال هیچ‌کس به Failureها اعتماد ندارد و انتشار باز هم منتظر Regression دستی می‌ماند. این تیم کمبود اسکریپت ندارد؛ کمبود استراتژی، مالکیت و سیگنال قابل اعتماد دارد.

در این راهنما، استراتژی اتوماسیون تست را از فهرست ابزار و شعار «خودکارکردن همه‌چیز» جدا می‌کنیم. یک Strategy Charter می‌سازیم، Portfolio را براساس Risk و Feedback layer طراحی می‌کنیم، Candidateها را امتیاز می‌دهیم، TCO و ROI را واقع‌بینانه محاسبه می‌کنیم، RACI، Failure policy، CI lanes و Pilot قابل توقف تعریف می‌کنیم و نمونهٔ ایرانی بازپرداخت را تا تصمیم Scale پیش می‌بریم.

استراتژی اتوماسیون تست چیست؟

Test Automation Strategy مجموعه تصمیم‌ها و Guardrailهای بلندمدت برای استفاده از اتوماسیون در تحقق اهداف تست و کسب‌وکار است. این سند محدوده، اولویت، Test level، معماری، محیط، داده، ابزار، نقش، استقرار، نگهداری، گزارش و سرمایه‌گذاری را به هم وصل می‌کند.

استراتژی یک سند ثابت سالانه نیست. با تغییر Risk، معماری، محصول، تیم، Dependency و هزینه باید بازبینی شود. Roadmap زمان‌بندی اجرای تصمیم‌هاست؛ خود Strategy دلیل و Rule تصمیم را نگه می‌دارد.

نیت جست‌وجو و کلیدواژه‌ها

کلیدواژهٔ اصلی «استراتژی اتوماسیون تست» است. عبارت‌های مکمل شامل «Test Automation Strategy»، «قالب استراتژی تست خودکار»، «نقشه راه اتوماسیون تست»، «ROI اتوماسیون»، «Automation Portfolio»، «Pilot اتوماسیون»، «Flaky Test Strategy» و «اتوماسیون تست در CI/CD» هستند. مخاطب Test Lead، QA Manager، SDET، Test Automation Engineer و Engineering Manager است.

پنج سندی که نباید یکی باشند

سند	سؤال	افق
Test Strategy	برای Riskهای محصول چگونه Evidence می‌گیریم؟	محصول/برنامه
Automation Strategy	اتوماسیون کجا و چگونه به Evidence کمک می‌کند؟	تیم/محصول/سازمان
Automation Architecture	Solution از چه Component و Interface ساخته می‌شود؟	فنی
Framework/Tool decision	کدام فناوری نیازها را برآورده می‌کند؟	فنی/اقتصادی
Roadmap/Plan	چه کار، مالک و موعدی داریم؟	اجرایی

برای تعریف پایه، مزایا، محدودیت و اقتصاد یک Test خودکار به راهنمای اتوماسیون تست مراجعه کنید. این مقاله روی Operating model و Strategy portfolio تمرکز دارد.

قالب یک‌صفحه‌ای Strategy Charter

Context and constraints:
Business/test outcomes:
Non-goals:
Product risks and critical invariants:
Automation portfolio by level:
Feedback lanes and time budgets:
Architecture/testability principles:
Environment, data and dependency policy:
Tool decision status:
Roles and ownership:
Failure, rerun and quarantine policy:
Security and evidence policy:
Cost envelope and capacity:
Success/health metrics:
Pilot and scale/stop criteria:
Review cadence and decision owners:

Charter باید کوتاه و قابل تصمیم باشد. جزئیات فنی در Architecture Decision Record، Runbook و Repository می‌آید. هر بند بدون Owner یا Action صرفاً آرزو است.

از Outcome شروع کنید، نه ابزار

هدف «پیاده‌سازی Playwright» یا «۷۰٪ اتوماسیون» نیست. نمونه هدف تصمیم‌پذیر:

• p95 بازخورد Riskهای پرداخت در Pull Request از ۴۰ به ۱۲ دقیقه برسد.
• برای هر تغییر Contract، Consumer/Provider compatibility پیش از Merge بررسی شود.
• Smoke انتشار در پنج دقیقه، Invariantهای مالی را با داده ایزوله تأیید کند.
• زمان Triage یک Failure خودکار در ۹۰٪ موارد کمتر از یک روز کاری باشد.
• Regression دستی تکراری بازپرداخت از دو ساعت به ۲۰ دقیقه بررسی اکتشافی هدفمند تبدیل شود.

اعداد بالا نمونه‌اند؛ Baseline و Risk تیم شما باید Target را تعیین کند. «سرعت بیشتر» بدون تعریف Window، Percentile و تصمیم کافی نیست.

Baseline وضعیت فعلی

قبل از ساخت Test جدید، Inventory موجود را با این ستون‌ها جمع کنید:

• Risk/Requirement مرتبط؛
• Test level و Interface؛
• Owner و Consumer نتیجه؛
• Lane و Trigger؛
• p50/p95 Duration و Queue time؛
• Flake، Failure validity و MTTR/MTTD؛
• داده، محیط و Dependency؛
• هزینه اجرا و نگهداری؛
• آخرین Failure محصول معتبر؛
• وضعیت Keep/Refactor/Move/Retire.

ممکن است مشکل با حذف ۲۰۰ تست تکراری، انتقال Assertion از UI به API و اصلاح Data isolation حل شود؛ افزودن Tool تازه راه‌حل پیش‌فرض نیست.

Risk×Layer Portfolio بسازید

هر Risk را در ارزان‌ترین لایه‌ای قرار دهید که Failure mode را با Oracle کافی می‌بیند. درصد ثابت هرم تست هدف نیست.

Risk	Evidence نزدیک	لایه	چرا؟
فرمول کارمزد	مثال‌ها و مرزها	Unit	سریع و Deterministic
تراکنش و Outbox	DB/Broker واقعی موقت	Component/Integration	رفتار زیرساخت مهم است
ناسازگاری API	Consumer/Provider verification	Contract	بازخورد پیش از Integration کامل
مجوز مالک سفارش	Role×Action×Owner matrix	API/Service	UI تنها مسیر را محدود می‌کند
Journey اصلی خرید	نتیجه کسب‌وکاری محدود	E2E	ترکیب چند مرز
RTL و Focus keyboard	Rule خودکار + Manual/AT sample	UI/Accessibility	ترکیب ماشین و قضاوت
Tail latency	Workload و p95/p99	Performance	Functional runner کافی نیست

اگر یک Assertion در سه لایه تکرار شده، دلیل هر نسخه را بنویسید. E2E باید سؤال ترکیبی پاسخ دهد، نه اینکه Unit test را از مرورگر تکرار کند.

Candidateهای اتوماسیون را چگونه انتخاب کنیم؟

Gateهای قبل از امتیازدهی

• Oracle قابل اتکا وجود دارد؟
• ورودی، داده و محیط قابل کنترل‌اند؟
• اجرای تکرارشونده ارزش تصمیمی دارد؟
• Failure قابل تشخیص و مالک‌پذیر است؟
• لایه کم‌هزینه‌تری همان Risk را نمی‌بیند؟
• خودکارسازی از نظر امنیت و دسترسی مجاز است؟

اگر پاسخ حیاتی «خیر» است، ابتدا Testability را اصلاح کنید یا فعالیت را دستی/اکتشافی نگه دارید.

Scorecard نمونه، نه ماشین حقیقت

Candidate score =
3 × execution frequency
+ 3 × product risk
+ 2 × determinism
+ 2 × reuse across changes
- 3 × expected maintenance
- 2 × environment/dependency cost

هر عامل را مثلاً از صفر تا سه امتیاز دهید. این عدد فقط گفت‌وگوی اولویت را ساختار می‌دهد؛ تفاوت ۲۴ و ۲۵ دقت علمی ندارد. Risk حیاتی می‌تواند Override مستند داشته باشد.

مثال Candidateهای فروشگاه ایرانی

Candidate	تصمیم	لایه	دلیل
Callback تکراری پرداخت	Automate now	API/Integration	Risk بالا، Oracle Ledger، تکرار زیاد
نمایش مبلغ ریال/تومان	Automate core + sample UI	Unit/API/UI	منطق و Rendering هر دو مهم‌اند
تحویل واقعی SMS OTP	Virtualize در PR؛ Sandbox دوره‌ای	Component/Integration	شخص ثالث، هزینه و ناپایداری
«زیبا بودن» Checkout	Manual research	Usability	Oracle انسانی و زمینه‌ای
مرور همه ترکیب Device	Risk matrix	Compatibility	کامل‌بودن ناممکن و پرهزینه

معماری Solution باید Testability را مصرف کند

یک Test automation solution پایدار معمولاً لایه‌های زیر را جدا می‌کند:

Test intent and assertions
        ↓
Domain tasks / flows
        ↓
Page, API client, message driver
        ↓
Fixtures, builders, clocks, dependency adapters
        ↓
Runner, environment, secrets, evidence, CI infrastructure

این شکل قانون جهانی نیست. برای UI پیچیده، راهنمای Page Object Model مرز Page/Component/Flow و جایگزین‌های آن را توضیح می‌دهد.

اصول معماری

• Test به رفتار و Risk وابسته باشد، نه جزئیات پیاده‌سازی شکننده.
• Driver و Client قرارداد واضح و Typed داشته باشند.
• داده با Builder/Fixture ساخته و با Run ID جدا شود.
• Clock، Randomness و External dependency قابل کنترل باشند.
• Assertion نزدیک به لایه‌ای باشد که حقیقت را می‌داند.
• Test مستقل و قابل اجرای انفرادی باشد.
• Artifact شکست شامل Log، Trace، Screenshot و نسخه‌ها باشد.
• Library مشترک Versioning و Deprecation policy داشته باشد.
• زیرساخت اتوماسیون خودش Smoke و Health check داشته باشد.

استقلال تست و Parallelism

اجرای Parallel فقط با افزودن Worker حل نمی‌شود. State مشترک، حساب ثابت، Clock، فایل و Queue مشترک Failure تصادفی می‌سازند. راهنمای رسمی Playwright نیز استقلال هر Test را برای Reproducibility و جلوگیری از Failure cascade توصیه می‌کند.

• هر Test داده مورد نیازش را بسازد یا Fixture فقط‌خواندنی مصرف کند.
• هیچ Test به ترتیب اجرای Test دیگر متکی نباشد.
• Namespace و Output path هر Worker یکتا باشد.
• Cleanup فقط داده همان Run را حذف کند.
• Parallelism تا ظرفیت Dependency و Environment محدود شود.
• Test order randomization دوره‌ای وابستگی پنهان را آشکار کند.

استراتژی داده، محیط و Dependency

اتوماسیون بدون Data/Environment strategy به Suite نامطمئن تبدیل می‌شود. برای چرخه کامل Synthetic، Masking، Seed، Reset و Retention به راهنمای مدیریت داده تست مراجعه کنید.

Policy پیشنهادی

• داده Production خام در Test runner استفاده نشود.
• Factory و Seed versioned و idempotent باشند.
• Environment config کنار نتیجه ثبت شود.
• Dependency تحت مالکیت تیم در لایه Integration واقعی باشد.
• شخص ثالث در PR Virtualize و در Lane دوره‌ای با Sandbox واقعی بررسی شود.
• Secret از Secret manager و با Least privilege بیاید.
• Test account در Analytics/Revenue قابل تفکیک باشد.
• Clock/Timezone و Locale فارسی بخشی از Matrix باشند.
• Cleanup failure Alert و TTL پشتیبان داشته باشد.

Operating Model و مالکیت

«اتوماسیون مسئولیت همه است» بدون تقسیم کار، در عمل مسئولیت هیچ‌کس می‌شود.

فعالیت	Accountable	Contributors
Risk portfolio و اولویت	Product/Engineering owner	QA، توسعه، عملیات
Unit/Component tests	تیم توسعه سرویس	QA/SDET
Cross-service/quality tests	مالک محصول/سامانه	تیم‌های سرویس، QA
Framework/shared libraries	Automation/Enablement owner	نمایندگان تیم‌ها
Environment/execution platform	Platform/DevOps owner	Automation engineer
Test data policy	Data/Product owner	QA، Security، Dev
Failure triage	تیم مالک Change/Risk	Test owner، Platform
Metric و Strategy review	Engineering/Test leadership	همه مصرف‌کنندگان Signal

مرکز Enablement باید Pattern، Platform و Coaching بدهد؛ اگر همه Testها را خودش بنویسد، Bottleneck و فاصله دامنه ایجاد می‌کند.

Definition of Done برای تست خودکار

• Risk/Requirement و دلیل لایه ثبت شده است.
• Expected result مستقل از همان کد تولید نشده است.
• Test به‌تنهایی و Parallel اجرا می‌شود.
• داده، Clock و Dependency کنترل شده‌اند.
• Failure message علت و Evidence کافی می‌دهد.
• Positive، Negative و مرز متناسب وجود دارد.
• No secrets/PII در Log و Artifact است.
• Owner، Lane و Blocking policy مشخص‌اند.
• Code review و Static check گذشته است.
• Maintenance/retirement trigger ثبت شده است.

Failure policy: هر Red یک نوع نیست

طبقه	نشانه	اقدام
Product failure	Oracle معتبر و تکرارپذیر	Block طبق Risk؛ defect/fix
Test defect	Assertion/selector/data غلط	Owner تست اصلاح کند
Infrastructure	Runner/env/dependency outage	Platform incident؛ وضعیت Unknown
Flaky/unknown	همان Artifact، Pass و Fail	تحقیق؛ quarantine محدود
Expected change	Contract/requirement مصوب عوض شده	Test و trace هم‌زمان Update

Rerun کور ممنوع

Rerun می‌تواند Evidence تشخیصی باشد، اما Pass دوم Failure اول را پاک نمی‌کند. نتیجه باید تاریخچه Attempt و Classification را حفظ کند.

Quarantine قرارداد می‌خواهد

هر Test قرنطینه‌شده باید Issue، Owner، علت، Risk gap، تاریخ انقضا و Replacement evidence داشته باشد. Quarantine بدون Expiry قبرستان Test است. اگر Test حیاتی از Gate خارج شد، Risk acceptance لازم است.

گزارش قدیمی Google درباره Flaky tests نرخ خاص محیط خود را نشان می‌دهد، نه Benchmark جهانی؛ پیام قابل انتقال این است که Signal نامعتبر اعتماد و زمان تشخیص را تخریب می‌کند.

CI Lanes را براساس زمان تصمیم طراحی کنید

Lane	تصمیم	نمونه Evidence	Budget
Local/pre-commit	آیا تغییر پایه سالم است؟	Unit/static/component منتخب	ثانیه تا چند دقیقه
Pull Request	Merge امن است؟	Changed-risk، contract، API، UI smoke	Target p95 تیم
Main/post-merge	Artifact قابل Promotion است؟	Integration گسترده و migration	متوسط
Nightly	Matrix/Dependency drift چیست؟	Compatibility، external sandbox، long run	طولانی‌تر
Release	Candidate با Policy سازگار است؟	critical journeys، NFR، security	Risk-based
Post-deploy	Artifact مستقر سالم است؟	smoke، synthetic، canary	دقایق اول

اصول Trigger، Gate، Promotion و Failure routing در راهنمای تست مداوم آمده است.

Test selection و تغییرمحوری

اجرای هوشمند می‌تواند زمان را کم کند، اما نباید Risk نامرتبط ظاهری را حذف کند. Mapping نیاز است:

• Code/component → owned tests؛
• API/schema → consumer contracts؛
• DB migration → affected repositories/readers؛
• Feature flag → both variants؛
• Shared library → dependent services؛
• Config/IaC → environment and smoke tests.

برای Riskهای حیاتی یک Safety net ثابت نگه دارید. الگوریتم Selection باید Missها را اندازه بگیرد و امکان Override داشته باشد.

Pilot را برای یادگیری طراحی کنید

Pilot نسخه کوچک پروژه نهایی نیست؛ آزمایشی برای پاسخ به فرض‌های Strategy است. دامنه باید ارزش واقعی و شکست قابل تشخیص داشته باشد، اما به‌اندازه‌ای کوچک باشد که Stop/Change ممکن باشد.

کارت Pilot بازپرداخت

Objective:
trusted PR feedback for refund and duplicate callback risk

Scope:
API + database + event outbox; no browser E2E

Baseline:
manual regression 120 min
PR feedback p95 38 min
known flaky setup rate 6%

Hypotheses:
temporary real DB improves defect detection
API seed + unique run ID enables parallel execution
domain assertions diagnose failure without DB inspection

Success examples:
all selected high risks have executable evidence
p95 PR signal within agreed budget
flake below locally agreed threshold
failure triage within one business day
maintenance effort within capacity envelope

Stop/rethink:
testability work exceeds approved capacity
dependency cannot be controlled
signals remain untrusted after two iterations

Owner and review date:
Refund team + QA/SDET; four-week review

عددهای نمونه از Baseline فرضی می‌آیند و نسخه عمومی Target نیستند.

چه زمانی Pilot را Scale، اصلاح یا متوقف کنیم؟

تصمیم	شرط
Scale	Signal معتبر، Outcome قابل مشاهده، مالکیت و TCO پذیرفتنی
Refactor	ارزش هست اما معماری/داده/diagnosis ضعیف است
Move layer	همان Risk در لایه پایین‌تر سریع‌تر و دقیق‌تر دیده می‌شود
Keep manual	قضاوت انسانی/تغییر زیاد/تکرار کم، اقتصاد بهتر دارد
Stop	Outcome محقق نمی‌شود یا Cost/Risk از Benefit بیشتر است

متوقف‌کردن Candidate بد شکست نیست؛ جلوگیری از Sunk cost است.

TCO واقعی اتوماسیون

هزینه ساخت

• تحلیل Risk و Design؛
• Testability تغییر محصول؛
• Framework، Tool و License؛
• Environment و Pipeline؛
• Data/fixture و dependency virtualization؛
• آموزش و Pilot.

هزینه عملیات و تغییر

• Compute، Browser/device و محیط؛
• Failure triage و Flake investigation؛
• نگهداری Test پس از تغییر محصول؛
• Upgrade Tool/runtime/browser؛
• Secret، evidence storage و observability؛
• Migration، deprecation و retirement؛
• فرصت از دست‌رفته مهندسان.

Benefit قابل دفاع

• تلاش دستی واقعاً حذف یا به Exploration منتقل‌شده؛
• کاهش زمان تا Signal و Fix؛
• افزایش دفعات Evidence برای Risk حیاتی؛
• کاهش Escape در Cohort قابل مقایسه؛
• کاهش زمان Release/rollback decision؛
• استفاده مجدد از Platform بین تیم‌ها.

فرمول ROI و محدودیت آن

ROI (%) =
(Verified benefits - Total cost of ownership)
--------------------------------------------- × 100
Total cost of ownership

Payback period =
Initial investment / verified net benefit per period

«هزینه باگی که شاید رخ می‌داد» را درآمد قطعی حساب نکنید. صرفه‌جویی دستی فقط وقتی Benefit است که اجرا واقعاً جایگزین یا ظرفیت آزادشده استفاده شده باشد. برای مقایسه دقیق Manual/Automated و فرمول‌های اقتصادی، راهنمای ROI اتوماسیون را ببینید.

Metricهایی که Strategy را هدایت می‌کنند

Outcome

• p50/p95 time to trusted signal؛
• Risk escapes در Release cohort؛
• زمان تصمیم Merge/Release؛
• Manual effort واقعاً displaced؛
• تکرار Evidence برای Critical risk.

Portfolio و Health

• Risk coverage بر اساس Test level؛
• Valid product-failure rate؛
• Flake rate با تعریف همان Artifact؛
• p95 queue و execution duration؛
• Time to diagnose و repair؛
• Quarantine age و risk exposure؛
• Maintenance hours و change amplification؛
• Infrastructure failure rate؛
• Cost per trusted run/signal.

«درصد Test case خودکار» می‌تواند Inventory باشد، اما KPI اصلی نیست. یک مجموعه کوچک معتبر می‌تواند از هزار Test شکننده ارزشمندتر باشد. طراحی Metric ضدبازی در راهنمای متریک‌های تست تکمیل شده است.

Tool و Framework را پس از نیاز انتخاب کنید

Must-haveها را از Portfolio و Constraint استخراج کنید: Protocol، زبان، Browser/device، Parallelism، Evidence، Security، CI، Skill و TCO. سپس PoC همان Risk واقعی را اجرا کند. راهنمای انتخاب فریم‌ورک اتوماسیون Scorecard، معماری و Exit strategy ابزار را ارائه می‌دهد.

PoC باید چه چیزهایی را اندازه بگیرد؟

• زمان اولین Test و زمان Test دوم؛
• Failure diagnosis، نه فقط Pass؛
• Data/environment setup؛
• Parallelism و isolation؛
• CI installation و dependency cache؛
• Artifact، trace و report؛
• Upgrade و version pinning؛
• Security/secret handling؛
• Export و Vendor exit؛
• مهارت و Onboarding تیم.

امنیت Solution اتوماسیون

• Test runner حساب Admin عمومی نداشته باشد.
• Secret در Code، Screenshot، Video و Report ثبت نشود.
• Production endpoint از Default config خارج باشد.
• Destructive test به Environment allowlist و approval نیاز داشته باشد.
• Artifact شخصی و داده حساس Redact شود.
• Dependency و Browser binary منبع و نسخه کنترل‌شده داشته باشند.
• CI token کوتاه‌عمر و Least privilege باشد.
• Pull request غیرقابل اعتماد به Secret دسترسی نگیرد.
• Test data retention و deletion policy اجرا شود.

ملاحظات تیم‌های ایرانی

• دسترسی Tool SaaS، Billing و محدودیت منطقه را در PoC واقعی تست کنید.
• Package/browser/container mirror مجاز و Cache داخلی داشته باشید.
• Fallback self-hosted و Export استاندارد را پیش از خرید بررسی کنید.
• SMS و PSP را در PR شبیه‌سازی و Sandbox را دوره‌ای بررسی کنید.
• ریال/تومان، رقم فارسی/لاتین، RTL و Asia/Tehran در Matrix بیایند.
• داده موبایل/کدملی واقعی وارد Cloud خارجی نشود.
• هزینه Device farm و Traffic بین‌الملل در TCO حساب شود.
• نسخه ابزار و Browser برای دوره اختلال قابل بازیابی باشد.

نقشه رشد مهارت و تیم

Strategy فقط Technology نیست. Skill matrix باید Test design، Programming، API، data، CI، observability، security و diagnosis را بسنجد. برای فرد مبتدی، نقشه راه هشت‌هفته‌ای شروع اتوماسیون مسیر آموزشی عملی می‌دهد؛ Strategy تیم باید زمان Mentoring و Pairing را در Capacity حساب کند.

• Pair QA و Developer روی اولین Risk؛
• Code review با Checklist تست؛
• Office hour مرکز Enablement؛
• نمونه Reference کوچک و سالم؛
• Failure clinic دوره‌ای؛
• Rotation مالکیت Pipeline و Test data؛
• آموزش Retirement، نه فقط نوشتن Test.

Scale سازمانی بدون Platform bottleneck

دارایی‌های مشترک را به سه دسته تقسیم کنید:

• Organization platform: Runner image، secret/evidence، report schema، observability.
• Domain shared: API clients، event contracts، data builders یک دامنه.
• Product local: pages، flows، assertions و fixtures محصول.

تبدیل همه چیز به Library مشترک Coupling و Release bottleneck می‌سازد. معیار Share، ثبات Interface و مالکیت واقعی است، نه شباهت چند خط کد.

Review cadence و Decision log

ماهانه Health و هر فصل Strategy را مرور کنید؛ همچنین پس از تغییر معماری، Tool EOL، Incident، افزایش Flake یا تغییر Risk. Decision log کوتاه نگه دارید:

Date:
Decision:
Context and evidence:
Options considered:
Owner/approver:
Expected outcome:
Guardrails:
Review/expiry date:
Result:

این Log از تکرار بحث و ماندگاری تصمیم منقضی جلوگیری می‌کند.

ضدالگوهای رایج

• Tool-first: خرید قبل از Portfolio و PoC.
• UI-first: قرار دادن همه Riskها در گران‌ترین لایه.
• Coverage theater: درصد اتوماسیون بدون Risk و Oracle.
• QA silo: همه Testها و Failureها مالک یک تیم مرکزی.
• Happy-path factory: اسکریپت زیاد و Failure mode کم.
• Shared state: Test order و حساب مشترک.
• Blind rerun: پاک‌کردن Signal اول با Pass دوم.
• Permanent quarantine: Test بدون Owner و Expiry.
• Free maintenance: حذف زمان نگهداری از ROI.
• Framework as product: معماری پیچیده پیش از نیاز واقعی.
• No retirement: Suite فقط رشد می‌کند.
• One pipeline: همه Testها در هر Change و Feedback دیر.

برنامه ۳۰/۶۰/۹۰ روزه

۳۰ روز: Baseline و Pilot

• Outcome و Risk portfolio بسازید.
• Inventory Keep/Move/Retire تهیه کنید.
• Candidate scorecard و Pilot card تصویب کنید.
• Data/environment/failure policy حداقلی بنویسید.

۶۰ روز: Trusted pipeline

• Pilot را با Evidence و مالکیت در PR اجرا کنید.
• Flake/infra/product classification راه بیندازید.
• p95 feedback و diagnosis را اندازه بگیرید.
• Quarantine SLA و Runbook بسازید.

۹۰ روز: Scale یا تغییر مسیر

• با معیارهای Scale/Stop تصمیم بگیرید.
• Shared platform و Product-local boundary را تعریف کنید.
• Laneهای Nightly/Release را فقط براساس Risk اضافه کنید.
• TCO، Benefit و Strategy charter را بازبینی کنید.

چک‌لیست نهایی استراتژی اتوماسیون

• Outcomeها تصمیم‌پذیر و دارای Baseline هستند.
• Non-goalها از Scope creep جلوگیری می‌کنند.
• Risk×Layer portfolio وجود دارد.
• Candidateها Gate و Scorecard شفاف دارند.
• معماری، Testability و Tool تصمیم‌های جدا هستند.
• Data، Environment و Dependency policy نوشته شده‌اند.
• تست‌ها مستقل و Parallel-safe هستند.
• هر Test و Failure Owner دارد.
• Definition of Done تست خودکار تصویب شده است.
• Rerun و Quarantine Risk را پنهان نمی‌کنند.
• CI lane با زمان تصمیم هم‌راستاست.
• Pilot معیار Scale، Refactor، Move و Stop دارد.
• TCO شامل نگهداری، diagnosis و retirement است.
• Metric اصلی Trusted signal و Risk outcome است.
• Security، Secret، PII و Production guardrails وجود دارند.
• دسترسی/هزینه/RTL/PSP ایران در PoC آزموده شده‌اند.
• Decision log و Review cadence فعال‌اند.

منابع معتبر

• ISTQB CT‑TAS v1.0؛ هزینه، ریسک، نقش، Test level، Deployment، Metric، ارزش و Scale سازمانی.
• ISTQB CTAL‑TAE v2.0؛ معماری، پیاده‌سازی، نگهداری، CI، Verification زیرساخت و بهبود.
• Playwright Best Practices؛ رفتار کاربر، استقلال تست، Dependency و CI.
• Selenium Test Automation Overview؛ هزینه Browser test و انتخاب لایه سبک‌تر.
• Google Testing Blog: Flaky Tests؛ اثر Signal نامعتبر بر اعتماد و تشخیص.

جمع‌بندی

استراتژی اتوماسیون، برنامه نوشتن Script نیست؛ Operating model تولید شواهد قابل اعتماد است. از Outcome و Risk آغاز می‌شود، Candidate را در ارزان‌ترین لایه مناسب می‌گذارد، Testability و داده را فراهم می‌کند، مالکیت و Failure policy می‌سازد و فقط پس از Pilot معتبر Scale می‌کند.

Portfolio سالم ممکن است Testهای کمتری داشته باشد، اما سریع‌تر، مستقل‌تر و قابل تشخیص‌تر است. وقتی TCO کامل، Quarantine شفاف، Lane متناسب و Metricهای Outcome وجود داشته باشند، اتوماسیون از پروژه‌ای پرهزینه به قابلیت مهندسی قابل اداره تبدیل می‌شود.

سوالات متداول استراتژی اتوماسیون تست

۱. تفاوت Test Automation Strategy و Framework چیست؟

Strategy می‌گوید چرا، کجا، با چه Risk، هزینه، نقش و Metric اتوماسیون می‌کنیم. Framework ساختار فنی اجرای بخشی از آن است. یک Strategy ممکن است چند Framework در Test levelهای مختلف داشته باشد.

۲. چه درصدی از تست‌ها باید خودکار شوند؟

عدد عمومی وجود ندارد. درصد Test case به Risk، تکرار، Oracle، تغییرپذیری و هزینه وابسته است. به‌جای Target درصدی، Risk coverage، زمان تا Signal معتبر، Flake، diagnosis و TCO را بسنجید.

۳. از UI، API یا Unit شروع کنیم؟

از Risk و نزدیک‌ترین Oracle شروع کنید. منطق در Unit، سرویس و مجوز در API/Component، Contract در مرز و چند Journey ترکیبی در UI/E2E قرار می‌گیرند. UI را فقط وقتی انتخاب کنید که رفتار قابل مشاهده کاربر موضوع تست است.

۴. با Flaky Test چه کنیم؟

Failure را حفظ و طبقه‌بندی کنید، داده/زمان/Dependency را کنترل کنید و Root cause را رفع کنید. Quarantine باید Issue، Owner، Expiry و Risk acceptance داشته باشد. Rerun کور نباید Failure اول را به Pass تبدیل و پنهان کند.

۵. چه زمانی Pilot را Scale کنیم؟

وقتی Outcome قابل اندازه‌گیری، Signal معتبر، معماری و مالکیت پایدار، TCO پذیرفتنی و Capacity نگهداری وجود دارد. اگر همان Risk در لایه پایین‌تر بهتر دیده می‌شود یا نگهداری از Benefit بیشتر است، Refactor، Move یا Stop تصمیم درست‌تری است.