۲۵۰ بررسی خودکار در هشت دقیقه اجرا شدهاند و همه سبزند؛ آیا محصول سالم است؟ نه. این عدد فقط میگوید Runner برای ۲۵۰ رکورد، نتیجهای با برچسب سبز تولید کرده است. هنوز نمیدانیم هر Check چه پرسشی داشته، روی کدام Build اجرا شده، Oracle از کجا آمده، Retry چه چیزی را پنهان کرده، Evidence متعلق به همین Subject است یا اصلاً این مجموعه ریسک مهمی را میسنجد.
اتوماسیون تست وقتی قابل اعتماد میشود که هر Automated Check یک ادعای محدود، اجرای قابل بازتولید، Evidence قابل ردیابی و چرخهعمر روشن داشته باشد. این راهنما افسانههای رایج را به یک Automation Claim & Lifecycle Contract تبدیل میکند: Question/Claim → Subject/Trigger → State/Data → Oracle → Control → Runner/Environment → Result/Evidence → Cost/Value → Keep/Adapt/Quarantine/Retire → Correction.
این صفحه جای راهنمای عمومی اتوماسیون تست چیست، مقایسهٔ تست دستی و خودکار یا طراحی Portfolio نیست. واحد تحلیل اینجا یک Check و ادعای آن در طول عمر است: دقیقاً چه چیزی را، تحت چه شرایطی، با چه محدودیتی میتواند بگوید؟
پاسخ کوتاه: واقعیت اتوماسیون تست چیست؟
Automation جایگزین «تست انسانی» یا ماشین تولید کیفیت نیست؛ یک سازوکار اجرای تکرارپذیر برای Checkهای مشخص است. ممکن است زمان بازخورد را در یک دامنه کم کند، خطای تکرار را کاهش دهد و Evidence منظم بسازد؛ اما ارزش آن به سؤال، Test Basis، Oracle، داده، محیط، قابلیت مشاهده، هزینهٔ نگهداشت و تصمیمی وابسته است که نتیجه قرار است پشتیبانی کند.
- سبز یعنی مشاهده با Oracle تعریفشده سازگار بوده؛ نه اینکه باگی وجود ندارد.
- خودکار یعنی بخشی از اجرا/مقایسه/جمعآوری Evidence ماشینی شده؛ نه اینکه قضاوت، طراحی و مسئولیت حذف شدهاند.
- سریع فقط یک ویژگی عملیاتی است؛ Check سریعِ بیربط، اطلاعات تصمیمپذیر نمیسازد.
- پایدار باید با تکرار کنترلشده و ثبت همهٔ Attemptها سنجیده شود؛ Retry مخفی، پایداری نیست.
- ارزشمند یک فرضیهٔ قابل سنجش در متن همان Product و Risk است؛ نه نتیجهٔ قطعی تعداد اسکریپتها.
مرز این راهنما با Strategy، Framework و CI
| پرسش | مالک محتوایی مناسب | مرز این صفحه |
|---|---|---|
| چه چیزی را در کل سازمان خودکار کنیم؟ | استراتژی اتوماسیون تست | Portfolio، Pilot و Scale |
| کدام Check در کدام Lane اجرا شود؟ | Continuous Testing در CI/CD | Feedback Lane و Quality Gate |
| Run و Attempt چگونه کنترل شوند؟ | چرخه اجرای تست | Run/Attempt/Outcome/Closure |
| این Automated Check چه ادعایی دارد و چه زمانی باید بازنشسته شود؟ | همین راهنما | Claim و Lifecycle یک Check |
واژگان دقیق: Test، Check، Script، Runner و Evidence
| واژه | تعریف عملیاتی در این راهنما | چه چیزی نیست؟ |
|---|---|---|
| Test activity | فعالیت یادگیری و ارزیابی دربارهٔ Product/Risk که میتواند انسانی، ماشینی یا ترکیبی باشد | فقط اجرای اسکریپت |
| Automated Check | پرسش محدود با ورودی، Oracle و مقایسهٔ ماشینی تکرارپذیر | اثبات کلی کیفیت |
| Script/Control implementation | کد، Flow یا Modelی که Setup، Stimulus، Observe و Compare را اجرا میکند | خود Claim یا Test Basis |
| Runner | اجراکننده با نسخه، Config، زمانبندی و سیاست Attempt | Oracle |
| Oracle | قاعده و Source تشخیص Expected/Acceptable از Observed | صرفاً «پیام موفقیت دیدم» |
| Outcome | PASS/FAIL/ERROR/SKIPPED/INCONCLUSIVE یک Attempt طبق Vocabulary نسخهدار | تصمیم Release |
| Evidence | Artifact دارای Subject/Build/Attempt/time/provenance/integrity که Outcome را قابل بررسی میکند | Screenshot بیهویت |
Automation Claim & Lifecycle Contract چیست؟
این Contract یک رکورد نسخهدار است که اجرای Check را به پرسش، ریسک، Subject، Oracle، Evidence و تصمیم نگهداشت وصل میکند. هدف آن سنگینکردن هر تست کوچک نیست؛ هدف حذف ابهامهایی است که باعث سبزی کاذب، Fail بیمعنا، Flaky پنهان و Suite متروک میشوند. عمق رکورد باید متناسب با ریسک و هزینه باشد.
AutomationCheckContract
checkId / version / supersedes
product / goal / risk / testBasis snapshot
question / boundedClaim / claimLimit
immutableSubject / trigger
preconditions / initialState / dataContract / cleanup
oracle.source / oracle.rule / comparisonMethod
implementationRef / repository / commit
runner / environment / dependency versions
isolation / order / parallel / retry policy
resultVocabulary / unknownPolicy
evidenceManifest / freshness / retention / integrity
ownerCapability / triageSLA / reviewDue
costBaseline / valueHypothesis / measure / guardrail
disposition: KEEP | ADAPT | QUARANTINE | RETIRE
correctionPolicy / retirementRecordاز تصور غلط به سؤال قابل ممیزی
| جملهٔ مبهم | سؤال جایگزین | Evidence لازم |
|---|---|---|
| اتوماسیون کیفیت را بالا میبرد | کدام Decision، برای کدام Risk، نسبت به کدام Baseline اطلاعات سریعتر/معتبرتر میگیرد؟ | Baseline، Measure و Countermetric |
| این Suite صددرصد سبز است | چه تعداد Check یکتای واجد شرایط، برای همین Build، با Evidence تازه و بدون Retry پنهان PASS شدهاند؟ | Manifest و همهٔ Attemptها |
| این تست Flaky است | در مجموعهٔ اجرای کنترلشده با Input/Build/Environment ثابت، چه Variation مشاهده شده؟ | Run series و تغییرهای کنترلشده |
| این Check ارزش نگهداشت ندارد | هزینه، مصرف تصمیمی، Signal و ریسک حذف آن در بازهٔ مشخص چه بوده؟ | Cost/usage/finding history و Review |
تصور غلط ۱: اتوماسیون جای تست انسانی را میگیرد
Automated Check میتواند یک مقایسهٔ ازپیشتعریفشده را با سرعت و تکرار بالا اجرا کند. انسان پرسش را انتخاب میکند، Risk را تفسیر میکند، Oracle را نقد میکند، رفتار تازه را میکاود و دربارهٔ Unknown تصمیم میگیرد. مرز «دستی/خودکار» ثابت نیست: Setup میتواند ماشینی و Observation انسانی باشد؛ یا انسان Model را بسازد و Runner مسیرها را تولید کند.
بنابراین نه «انسان فقط خلاق است» گزارهٔ دقیقی است و نه «ماشین همهٔ تست را انجام میدهد». روش را بر اساس پرسش، قابلیت مشاهده، هزینه، تکرار، خطر و نیاز به قضاوت انتخاب کنید. برای انتخاب ترکیبی، راهنمای Manual vs Automated Testing مرجع مستقل است.
تصور غلط ۲: سبز یعنی بدون باگ و باکیفیت
PASS یک گزارهٔ محدود است: «Observed در این Attempt با Oracle این Check سازگار بود.» ممکن است Requirement ناقص، Oracle اشتباه، Data غیرنماینده، Subject قدیمی یا Observe ناکافی باشد. Check نیز فقط آنچه را کد کردهایم نمیسنجد؛ ممکن است به سبب Dependency، Selector یا Timing چیز دیگری را بسنجد.
تعداد Check، Code coverage، Requirement mapping و PASS rate هرکدام View متفاوتاند. هیچکدام بهتنهایی کفایت طراحی تست، نبود باگ، رضایت کاربر یا آمادگی انتشار را اثبات نمیکنند. تصمیم انتشار به Risk، Evidenceهای دیگر، Unknown و اختیار تصمیم نیاز دارد؛ چارچوب آن در کیفیت بهاندازه کافی خوب آمده است.
تصور غلط ۳: هرچه تعداد Check بیشتر باشد Coverage بهتر است
۱۰۰ Check تکراری میتوانند همان یک Condition را بسنجند. برای ادعای Coverage ابتدا Registry واجد شرایط و واحد پوشش را نامگذاری کنید: Risk، Requirement، State transition، API operation، Browser/locale pair یا Data partition. سپس Checkهای یکتا را به آن Registry نگاشت کنید و Missing، Duplicate، N/A، Stale و Evidence-backed را جدا نگه دارید.
هر درصد باید Population snapshot، Numerator، Denominator، Exclusion، cutoff و limitation داشته باشد. Coverage یک مدل است، نه حقیقت محصول؛ Check count را بهعنوان جایگزین آن منتشر نکنید.
تصور غلط ۴: همهٔ Checkها باید با هر Commit اجرا شوند
اجرای مکرر میتواند بازخورد را زودتر کند، اما «همهچیز در هر Commit» ممکن است صف طولانی، هزینهٔ زیرساخت، Rate limit، دادهٔ برخوردی و Noise بسازد. Trigger باید از Risk، Change impact، زمان اجرا، Isolation، هزینه، دسترسی Environment و Consequence تأخیر مشتق شود.
| Lane نمونه | Trigger | Claim محدود | محدودیت |
|---|---|---|---|
| PR-fast | تغییر در ماژول مربوط | Feedback سریع روی چند Risk نزدیک | پوشش کامل نیست |
| merge/integration | ادغام در شاخهٔ اصلی | سازگاری قراردادهای منتخب | Environment هنوز Production نیست |
| nightly/broad | زمانبندی | نمونهٔ گستردهتر در Build ثابت | بازخورد دیرتر است |
| pre-release/risk | Candidate مشخص | Evidence برای Riskهای Release policy | تصمیم را خودکار نمیکند |
تصور غلط ۵: اسکریپت پس از ساخت تقریباً رایگان است
Check یک محصول نگهداشتنی است. Basis، Product behavior، Data schema، API، Locator، Browser، Runner، Dependency، Pipeline و سیاست Evidence تغییر میکنند. بعضی تغییرها Check را واقعاً نامعتبر و بعضی فقط Implementation را شکسته میکنند؛ اگر این دو را جدا نکنیم، تیم یا Fail محصول را «خرابی تست» مینامد یا Drift تست را بهعنوان Defect محصول گزارش میکند.
هزینه فقط زمان تعمیر نیست: زمان Review، CI compute، داده و محیط، triage، نگهداری Secret، ذخیرهٔ Artifact، On-call و هزینهٔ Opportunity را نیز ثبت کنید. Freshness و Drift اسناد مرتبط باید طبق قرارداد مستندات تست زنده مدیریت شوند.
تصور غلط ۶: Recorder یا Codeless همیشه بنبست است
Record/Playback، Low-code و Codeless نامهایی برای قابلیتهای متفاوتاند. یک Flow بدون کد ممکن است Export، Version control، Review، API، Data parameterization و CI خوبی داشته باشد؛ یک Framework کدنویسیشده نیز ممکن است شکننده و غیرقابل بررسی باشد. معیار، زبان ساخت نیست؛ توانایی کنترل State/Data، تعریف Oracle، مشاهدهٔ Failure، Diff، امنیت، همکاری، نگهداشت و Exit است.
برای ارزیابی Recorder با تغییر عمدی و PoC نماینده، به راهنمای اتوماسیون بدون کد مراجعه کنید. نتیجهٔ PoC را به همهٔ محصولات و تیمها تعمیم ندهید.
تصور غلط ۷: برنامهنویسی، OOP یا Page Object برای همه اجباری است
قابلیت فنی لازم تابع Interface و مسئله است. بعضی Checkها با Query، قرارداد داده، Model، CLI یا ابزار تخصصی ساخته میشوند؛ برخی به کدنویسی عمیق نیاز دارند. Page Object یک الگوی ممکن برای کاهش تکرار و پنهانکردن جزئیات UI است، نه قانون جهانشمول و نه Oracle. Abstraction زودهنگام میتواند Intent را پنهان کند و تغییر کوچک را در کل Suite منتشر سازد.
بهجای عنوان شغلی یا گواهی، Capabilityهای observable را بسنجید: توانایی صورتبندی Question، ساخت دادهٔ ایمن، کنترل State، نوشتن Comparison درست، تشخیص Failure mode، خواندن Trace، Review تغییر و اصلاح Evidence.
تصور غلط ۸: یک ابزار یا Framework برای همه بهترین است
Web UI، Mobile، API، Contract، Component، Data pipeline، Performance و Accessibility Interfaceهای متفاوت دارند. «بهترین» بدون Constraint معنا ندارد. Candidateها را روی Browser/device support، Protocol، Debuggability، Isolation، Parallelism، Evidence، CI fit، Skills، License، Region، Security، Exit و Cost of change بسنجید.
نام ابزار تضمین معماری نیست. مستندات Selenium نیز توصیههای خود را آگاهانه «guidelines and recommendations» مینامد، چون یک رویکرد برای همهٔ موقعیتها مناسب نیست. ادعای قابلیت را با نسخه و مستند روز و سپس PoC خودتان اعتبارسنجی کنید.
تصور غلط ۹: ROI بالاخره حتماً مثبت میشود
ROI نتیجهٔ تضمینی زمان نیست. Check ممکن است پیش از رسیدن به Break-even به علت حذف Feature، تغییر Architecture یا Oracle نامعتبر بازنشسته شود. همچنین «زمان اجرای دستی × دفعات» فقط یک Counterfactual ساده است؛ همهٔ اجرای دستی حذف نمیشود و Automation هزینهٔ Build، نگهداشت، triage و زیرساخت دارد.
Value hypothesis: کاهش median زمان Feedback برای R-IDEMP-4
Baseline: 42 دقیقه در نمونهٔ قابل مقایسه
Measure: median feedback minutes per eligible run
Costs: build + review + CI + data/env + triage + maintenance
Guardrails: false-result rate, maintenance minutes, queue time
Review window: 30 روز
Claim limit: نه ROI قطعی، نه کیفیت یا Releaseاز ضریبهای ثابت مانند «هزینهٔ باگ دیرهنگام همیشه ۱۰۰ برابر است» بهعنوان واقعیت پروژه استفاده نکنید. Baseline، Assumption، بازهٔ عدم قطعیت و Countermetric محلی لازماند.
تصور غلط ۱۰: Automation متعلق به تیم QA است
مالکیت یک Silos جدید نسازید. Product/Risk owner، Developer، Tester، Platform، Security، Data و Operations میتوانند در Question، Testability، Environment، Oracle، Review و Response سهم داشته باشند. اما «همه مسئولاند» کافی نیست: هر Check به قابلیت نگهداشت، Triage SLA و Decision authority روشن نیاز دارد.
| تصمیم | پاسخگو بر اساس قابلیت | ورودیهای لازم |
|---|---|---|
| Claim/Oracle را قبول یا رد کند | Domain + test-design capability | Basis، Risk و نمونههای مرزی |
| Implementation را Merge کند | Code/flow owner با Reviewer | Diff، اجرای کنترلشده، امنیت |
| Failure را Triage کند | Response owner | همهٔ Attemptها، Trace و تغییرها |
| Quarantine یا Re-entry دهد | Reliability owner طبق Policy | Failure series، Cause evidence، expiry |
| Risk یا Release را بپذیرد | Business/Product authority | چند Evidence، Unknown و Trade-off |
مرحله ۱: Question و Claim محدود را بنویسید
Question باید یک ابهام تصمیمی را هدف بگیرد. «آیا Checkout کار میکند؟» بسیار بزرگ است. نمونهٔ محدودتر: «برای Attempt مشخص روی Build R20، آیا دریافت دوبارهٔ Callback با Event ID یکسان بیش از یک Ledger effect میسازد؟» Claim پاسخ ماشینی مورد انتظار است؛ Claim limit هم آنچه را نمیتوان نتیجه گرفت ثبت میکند.
question: duplicate callback چه اثری دارد؟
claim: برای Tenant+Attempt+Event ثابت، دقیقاً یک Ledger entry ساخته میشود
claimLimit:
- سایر Failure modeهای پرداخت پوشش داده نشدهاند
- نبود باگ یا صحت مالی Production نتیجه نمیشود
- PASS مجوز Release نیستمرحله ۲: Subject و Trigger تغییرناپذیر را پین کنید
برچسبهایی مانند latest، main، nightly یا staging کافی نیستند؛ در زمان Review به شیء دیگری اشاره میکنند. Product، Repository، Commit، Build artifact، Environment snapshot، Test Basis و Risk registry را با ID/version ثبت کنید. Trigger نیز باید بگوید Check چرا اکنون اجرا شده: Change impact، PR، زمانبندی، Pre-release یا رخداد عملیاتی.
| Identity | ضعیف | قابل ممیزی |
|---|---|---|
| کد محصول | main | repository=checkout-api، commit=C20 |
| Artifact | latest image | build=BUILD-R20، digest مشخص |
| Environment | staging | ENV-SYN-R20 + config/dependency versions |
| Basis | طبق نیازمندی | BASIS-v7:R-IDEMP-4 |
مرحله ۳: Preconditions، State، Data و Cleanup را قرارداد کنید
Check باید از State معلوم شروع شود. «یک سفارش موجود» ممکن است متعلق به Tenant دیگر، مصرفشده یا همزمان در حال تغییر باشد. Data contract باید Seed، Partition، Ownership، عمر، Format، Currency unit، locale و Cleanup را روشن کند. Randomness بدون Seed قابل بازتولید نیست؛ دادهٔ ثابت مشترک نیز برخورد میسازد.
| جزء | نمونهٔ قرارداد | Failure mode مهارشده |
|---|---|---|
| Precondition | PSP-STUB-v4 و LEDGER-STUB-v3 آماده | وابستگی مبهم |
| Initial state | ORDER_CREATED / ATTEMPT_PENDING | وابستگی به ترتیب اجرا |
| Partition | TEN-SYN-20 + Run ID | برخورد Parallel |
| Seed | seed=R20-CHK-1 | تولید غیرقابل بازتولید |
| Cleanup | حذف Namespace مصنوعی پس از ثبت Evidence | آلودگی اجرای بعد |
مرحله ۴: Oracle را از Approval و Screenshot جدا کنید
Oracle باید Source، Rule، Tolerance، Timing window و روش مقایسه داشته باشد. «صفحه موفقیت را دیدم» ممکن است فقط لایهٔ UI را بسنجد و Side effect ناموفق را نبیند. «مدیر تأیید کرد» نیز Evidence اجرای رفتار نیست. Expected value را از همان System under test کپی نکنید؛ این کار یک خطا را در هر دو طرف بازتولید میکند.
- برای State، مقدار قبل/بعد و کلید هویت را مقایسه کنید.
- برای پول، واحد canonical و سیاست rounding را صریح کنید.
- برای زمان، Clock و Window را کنترل کنید؛ Sleep ثابت Oracle نیست.
- برای Event، uniqueness، ordering و eventual-consistency window را تعریف کنید.
- برای Visual، Baseline، viewport، font، OS/browser و tolerance نسخهدار لازم است.
مرحله ۵: Control implementation را از Claim جدا نگه دارید
یک Claim ممکن است با API، UI، Component یا Model سنجیده شود. تغییر Implementation لزوماً Claim را عوض نمیکند؛ تغییر Basis ممکن است Claim را منسوخ کند حتی اگر Script هنوز سبز باشد. Contract باید implementationRef، Repository، Commit، Dependencies و Reviewer را نگه دارد تا Drift قابل تشخیص باشد.
کد Test باید مانند کد تصمیمساز Review شود: نام هدفدار، Failure message تشخیصی، Assertion مشخص، Cleanup امن، Secret-free output و حداقل Abstraction لازم. اما «Production code دقیقاً همان Test code» قانون نیست؛ Risk و Failure consequence متفاوتاند.
مرحله ۶: Runner، Environment و Dependency را قابل بازتولید کنید
Runtime، Test runner، plugin، browser/device، OS/container، locale، timezone، feature flag، Config و Stub version بر Outcome اثر دارند. فقط Version نوشتن نیز کافی نیست؛ Config و Artifact digest گاهی تعیینکنندهاند. Dependency خارجی کنترلنشده میتواند Failure آن سرویس را به Product شما نسبت دهد یا تغییر محتوای آن را Flakiness جا بزند.
راهنمای رسمی Playwright Best Practices بر رفتار قابل مشاهده، Isolation، دادهٔ کنترلشده و پرهیز از تست مستقیم سرویس ثالث تأکید میکند؛ این توصیهها مربوط به Playwright و تستهای آناند، نه اثبات جهانشمول کیفیت. برای هر Stack، مستند نسخهٔ خودش و آزمایش محلی لازم است.
مرحله ۷: Isolation، Order و Parallelism را آزمایش کنید
Check مستقل باید بتواند تنها، پس از Check دیگر، با ترتیب تصادفی و در ظرفیت Parallel تعریفشده همان ادعای محدود را ارزیابی کند. استقلال مطلق همیشه ممکن یا اقتصادی نیست؛ اگر State مشترک لازم است، Dependency و Serialization را آشکار کنید و Claim را محدود سازید.
مستند رسمی Selenium دربارهٔ پرهیز از State مشترک پیشنهاد میکند داده و Driver بین تستها مشترک نباشد و دادهٔ کهنه پاک شود. این یک توصیهٔ زمینهای برای WebDriver است؛ Contract شما باید هزینه و محدودیت واقعی سامانه را نیز ثبت کند.
مرحله ۸: Result Vocabulary را از رنگ جدا کنید
| Outcome | معنا | چه چیزی را نباید نتیجه گرفت؟ |
|---|---|---|
| PASS | Observed با Oracle همین Attempt سازگار است | بدون باگ/Release-ready |
| FAIL | مقایسهٔ معتبر ناسازگاری نشان داد | Cause حتماً Defect محصول است |
| ERROR | Check نتوانست مقایسهٔ معتبر را کامل کند | رفتار Product رد شده است |
| SKIPPED | طبق Rule اجرا نشد | PASS ضمنی |
| INCONCLUSIVE | Observation برای Verdict کافی نبود | FAIL یا PASS |
Color فقط View است. Vocabulary، Transition و Aggregation policy را نسخهدار کنید؛ ERROR و SKIPPED را در PASS rate پنهان نکنید و «آخرین Attempt سبز» را جای Outcome مجموعهٔ Retryها ننشانید.
مرحله ۹: Evidence Manifest قابل ردیابی بسازید
Evidence باید Answer reviewable بسازد، نه انبار Artifact. Manifest حداقل Check/version، Subject/Build/Commit، Run/Attempt، Runner/Environment، Started/Finished، Outcome، raw refs، digest، freshness، retention، redaction و Unknown را نگه دارد. Screenshot، log یا trace بدون این هویتها قابل نسبتدادن نیست.
{
"check": "CHK-IDEMPOTENCY-01@3",
"subject": "checkout-idempotency",
"build": "BUILD-R20",
"commit": "C20",
"run": "RUN-SYN-20",
"attempt": 1,
"outcome": "PASS",
"startedAt": "2026-08-13T06:00:00Z",
"finishedAt": "2026-08-13T06:00:03Z",
"raw": ["evidence/R20/CHK-1.ndjson"],
"digest": "sha256:fictional-r20-check-1",
"unknowns": [],
"claimLimit": "not coverage, quality, ROI, or release proof"
}برای ارائهٔ Artifact به مخاطب تصمیمگیر، قواعد Evidence تا تصمیم قابلپیگیری را جداگانه اعمال کنید.
مرحله ۱۰: Retry را Evidence کنید، نه آرایش نتیجه
Retry میتواند برای جمعآوری Signal یا تحمل Failure mode شناختهشده مفید باشد؛ اما اگر فقط آخرین Attempt نمایش داده شود، اولین Failure پاک میشود. برای هر Attempt، Input، Seed، Build، Environment، زمان، Outcome و Artifact را حفظ کنید. Summary باید PASS_FIRST_TRY، PASS_AFTER_RETRY، CONSISTENT_FAIL و MIXED را از هم جدا کند.
| الگو | برداشت مجاز | اقدام |
|---|---|---|
| PASS در Attempt اول | یک Observation سازگار | طبق Sampling ادامه |
| FAIL سپس PASS | Variation مشاهده شد | Triage؛ سبز نهایی Failure اول را حذف نمیکند |
| ERROR سپس PASS | Execution failure رخ داد | Runner/Environment را بررسی کنید |
| FAIL مداوم | ناسازگاری قابل تکرار در شرایط ثبتشده | Finding و Cause investigation |
مرحله ۱۱: Flaky، False Fail و False Pass را قاطی نکنید
Flaky یعنی Outcome در شرایطی که طبق قرارداد باید معادل باشند تغییر میکند؛ پیش از این برچسب باید Equivalence شرایط را نشان دهید. False Fail یعنی Check ناسازگاری گزارش کرده ولی Claim مورد نظر نقض نشده؛ False Pass یعنی Check PASS داده در حالی که Claim نقض شده است. مورد آخر معمولاً کمصداتر و خطرناکتر است.
Flake rate بدون Population و Attempt policy گمراهکننده است. تغییر Product، Environment، Data یا Dependency شاید Failure واقعی بیرون از Scope Check باشد، نه Flakiness. Observation، Hypothesis و confirmed Cause را جدا ثبت کنید.
مرحله ۱۲: Quarantine را با SLA و Re-entry ببندید
Quarantine حذف بیسروصدای Check از Gate نیست. رکورد باید Reason evidence، Owner، Start، Expiry، Risk impact، جایگزین موقت، Triage SLA و Re-entry rule داشته باشد. Dashboard باید Check قرنطینهشده را در Denominator مناسب نگه دارد؛ وگرنه Pass rate با حذف Failureها مصنوعی بهتر میشود.
quarantineId: Q-CHK-17
check: CHK-IDEMPOTENCY-01@3
reason: MIXED outcome across controlled series RS-20
riskImpact: automated signal for R-IDEMP-4 unavailable
temporaryControl: focused manual observation on release candidate
owner: capability:automation-reliability
expiresAt: 2026-08-20T12:00:00Z
reentry: 20 clean runs across 3 builds + confirmed-cause evidence
closureEvidence: requiredمرحله ۱۳: KEEP، ADAPT، QUARANTINE یا RETIRE
| Disposition | زمان مناسب | رکورد لازم |
|---|---|---|
| KEEP | Claim هنوز معتبر، Signal مصرفشده و هزینه قابل قبول است | reviewDue و Evidence مصرف |
| ADAPT | Claim باقی است ولی Basis/Interface/Data/Implementation تغییر کرده | impact، version و supersedes |
| QUARANTINE | Signal موقتاً غیرقابل اعتماد و Risk هنوز فعال است | expiry، owner، control جایگزین، re-entry |
| RETIRE | Risk/Feature حذف، Claim نامعتبر، Check تکراری یا هزینه از ارزش محدود بیشتر است | reason، آخرین Evidence، جایگزین و archive |
Suite سالم فقط Check اضافه نمیکند؛ با Evidence، مورد نامعتبر را اصلاح یا بازنشسته میکند. حذف فایل بدون Retirement record، تاریخچهٔ Coverage و علت تصمیم را مبهم میکند.
مرحله ۱۴: Correction و Supersession را نگه دارید
اگر بعداً معلوم شد Oracle اشتباه یا Evidence به Build دیگری متعلق بوده، نتیجه را بیصدا بازنویسی نکنید. Correction باید Record قبلی، Reason، Discoverer، corrected interpretation، affected decisions، notification و timestamp را پیوند دهد. Contract جدید با version/supersedes منتشر شود و Raw evidence طبق Retention باقی بماند.
correctionId: CORR-R20-04
corrects: OUTCOME-R20-CHK-1-A1
reason: manifest referenced BUILD-R19 evidence
oldInterpretation: PASS for BUILD-R20
newInterpretation: INVALID / no valid evidence for BUILD-R20
affectedDecision: DR-20
notifiedAt: 2026-08-13T09:15:00Z
supersedingCheck: CHK-IDEMPOTENCY-01@4مبنای استاندارد و محدودیت منابع
سرفصل رسمی ISTQB CTFL v4.۰.۱ در بخش مزایا و ریسکهای Test Automation تصریح میکند که صرف تهیهٔ ابزار موفقیت را تضمین نمیکند و معرفی، نگهداشت و آموزش effort میخواهند؛ همچنین مزایای بالقوهای مانند کاهش کار تکراری، سازگاری، دسترسی بهتر به اطلاعات و بازخورد سریعتر را برمیشمارد. واژهٔ «بالقوه» مهم است: این منبع نتیجهٔ پروژهٔ شما، ROI، ابزار مناسب، Coverage کافی یا کیفیت Product را اثبات نمیکند.
راهنماهای Playwright و Selenium نیز توصیههای Stack-specific دربارهٔ Isolation، State و Debugging هستند. آنها را به Contract محلی ترجمه کنید؛ از نام مرجع برای ساختن قانون اجباری، رتبهبندی ابزار یا ادعای تضمینی استفاده نکنید.
آزمایش بازتولیدپذیر: ۲۵۰ Check سبز در برابر ۷۱ Finding
برای اینکه بحث فقط توصیه نماند، یک Fixture مستقل و کاملاً مصنوعی با شناسهٔ SYN-AUTOMATION-CLAIM-LIFECYCLE-01 و Node.js v24.۱۸.۰ ساخته شد. هیچ شبکه، Browser، Database یا Product واقعی در آن وجود ندارد. معیار سطحی فقط سه فیلد را دید: ۲۵۰ Check، ۲۵۰ Green و هشت دقیقه؛ پس PASS داد.
{
"superficial": {
"status": "PASS",
"message": "250/250 automated checks green in 8 minutes"
},
"contractAudit": {
"status": "HOLD",
"findingCount": 71
}
}Validator دقیق ۷۱ Failure ساختاری یافت: ده Identity کهنه/متحرک؛ Check ID تکراری؛ Question/Claim/Subject/Trigger/State/Data/Oracle/Implementation/Runner/Environment/Dependency/Owner/SLA ناقص؛ State مشترک، نبود Cleanup و برخورد Order/Parallel؛ Retry-until-green و Quarantine بیمالک؛ Vocabulary دوحالته؛ Evidence خارجی و کهنه بدون Manifest/raw/time/digest/freshness/Unknown؛ Cost/Value/Guardrail نامشخص؛ نبود Review/Correction/Retention/Redaction/Disposition/Retirement؛ و سیزده ادعای مطلق دربارهٔ جایگزینی انسان، نبود باگ، Coverage، Quality، Release، ROI، ضریب ۱۰۰، Programming، Codeless، Framework، بهترین ابزار، every-commit و مالکیت QA.
نسخهٔ اصلاحشدهٔ آزمایش چه چیزی را ثابت کرد؟
نسخهٔ اصلاحشده AUTO-۱۹/SYN-CHECKOUT/PG-۱۳/BASIS-v7/checkout-tests/C20/BUILD-R20/RISK-v9/TEST-STRAT-v5/PIPE-v6 را پین کرد؛ یک Check یکتا برای idempotency ساخت؛ Question، Claim limit، Subject، Trigger، State/Data، Oracle، implementationRef، Runner/Environment/Stub، Isolation، Result vocabulary، همهٔ Attemptها، Manifest، freshness، Owner/SLA، Cost/Value/Guardrail و Lifecycle را کامل کرد. Validator صفر Finding یافت و READY_FOR_AUTOMATION_REVIEW داد.
این وضعیت عمداً PASS محصول نیست. Validator فقط کاملبودن روابط ساختاری همان Rule set را سنجید؛ حقیقت یا کفایت Oracle/Evidence، کفایت Coverage، نبود باگ، کیفیت محصول، ROI و تصمیم Release را ارزیابی نکرد.
دامنهٔ آزمایشگاه Checkout فارسی و ایرانی
سناریوی آموزشی یک Checkout کاملاً جدا از شبکه با Order، PaymentAttempt، PSP Stub جعلی، Callback، Ledger Stub و Reconciliation مصنوعی است. Failure modeها شامل timeout قبل/بعد از fake commit، Callback تکراری، دیررس و جابهجا، retry و جداسازی Tenant هستند. همهٔ IDها، مبالغ و رویدادها ساختگیاند.
| موضوع | قرارداد آزمایشگاهی | Claim limit |
|---|---|---|
| پول | مقدار canonical ساختگی بر حسب IRR؛ نمایش تومان فقط با برچسب و conversion rule | هیچ ادعای مالی/بانکی/مالیاتی ایران |
| رقم و متن | ارقام فارسی/عربی/لاتین، Unicode normalization و RTL/LTR با ID لاتین پایدار | نه پوشش کامل locale |
| زمان | ISO instant در UTC؛ View در Asia/Tehran؛ جلالی فقط presentation | نه قانون حقوقی یا تسویه |
| هویت | Tenant/Order/Attempt/Event/Ledger/Run/Build/Evidence جدا | هیچ مشتری یا تراکنش واقعی |
هیچ نام، موبایل، ایمیل، IP، حساب، PAN، CVV2، OTP، Cookie، Token، Credential، Screenshot یا Log واقعی استفاده نمیشود. این آزمایش توصیهٔ بانکی، مالی، حقوقی، مالیاتی، امنیتی، حریم خصوصی یا انطباق ایران نیست.
امنیت، حریم خصوصی و Retention در Automation
- Production data را پیشفرض Test data ندانید؛ دادهٔ مصنوعی/حداقل و مجوزدار بسازید.
- Secret را در Repository، Screenshot، Video، Trace، command line یا گزارش منتشر نکنید.
- Artifact access را با نقش، Purpose و Audit trail محدود کنید.
- Retention را بر اساس نیاز Review و حساسیت تعیین کنید؛ «برای همیشه» Policy نیست.
- Dependency و package را pin، scan و با provenance نگهداری کنید؛ خودکاربودن زنجیرهٔ تأمین را امن نمیکند.
- Cleanup فقط Namespace همان Run را هدف بگیرد و destructive command گسترده نداشته باشد.
Automation و AI: تولید کد با پذیرش Claim یکی نیست
AI میتواند Draft Test data، Scenario، Assertion، Selector، Refactor یا Failure summary پیشنهاد کند. ولی Source، Prompt/model/version، ورودی، Diff، Reviewer و نتیجهٔ Validator باید ثبت شوند. کد تولیدشده ممکن است API خیالی، Assertion ضعیف، Secret leak، Test tautology یا License risk داشته باشد.
AI نباید مستقل Oracle را حقیقت اعلام کند، Evidence را جعل/تکمیل کند، Failure را بدون Provenance به Defect نسبت دهد، Quarantine را نامحدود کند یا Release را تصویب نماید. Gateهای deterministic و Review انسانی متناسب با Risk باقی میمانند.
متریکهای مفید با Countermetric
| Measure | تعریف لازم | Countermetric/خطر بازی |
|---|---|---|
| Feedback time | از Trigger تا Evidence قابل مصرف برای Population ثابت | False-result و queue cost |
| First-attempt reliability | PASS/FAIL معتبر در Attempt اول بر eligible runs | SKIPPED/ERROR/Quarantine |
| False-result rate | False Pass/Fail تأییدشده با denominator | زمان و روش تأیید |
| Evidence freshness | Evidence معتبر در SLA برای Subject درست | هزینهٔ اجرا و Storage |
| Maintenance load | Build/review/triage/fix minutes per Check یا Risk | Signal مصرفشده و ریسک حذف |
| Quarantine age | سن Checkهای خارج Gate با Policy | Risk بدون Control جایگزین |
| Decision consumption | چند Claim واقعاً در تصمیم نامدار استفاده شد | نپاداشدادن به حذف آزمایش ضروری |
| Retire benefit | هزینه حذفشده در برابر Signal/ریسک از دسترفته | Regression escape و Unknown |
برای رتبهبندی فرد یا تیم از Test count، pass rate، coverage یا bug count استفاده نکنید؛ این کار رفتار اندازهگیری را منحرف میکند. Metric باید به بهبود System کمک کند، نه مسابقهٔ تولید Check.
Pilot سیروزه برای قرارداد یک Check
| بازه | کار | خروجی/گیت |
|---|---|---|
| روز ۱–۵ | یک Decision و Risk، Check مصرفشده و Baseline را انتخاب کنید | Question/Claim/Claim limit پذیرفتهشده |
| روز ۶–۱۰ | Subject/State/Data/Oracle/Runner/Evidence contract را کامل کنید | Dry-run و Review تناقضها |
| روز ۱۱–۱۵ | تنها، random-order، parallel و fault-injection اجرا کنید | Isolation/Failure-mode report |
| روز ۱۶–۲۰ | Retry، Result vocabulary، Manifest و Correction را آزمایش کنید | همهٔ Attemptها قابل ردیابی |
| روز ۲۱–۲۵ | Cost/Value/Guardrail و مصرف تصمیم را اندازه بگیرید | Baseline delta با limitation |
| روز ۲۶–۳۰ | KEEP/ADAPT/QUARANTINE/RETIRE و گسترش/توقف را Review کنید | Decision record، owner و reviewDue |
Pilot موفق یعنی تیم میتواند Claim محدود را با Evidence معتبر و هزینهٔ معلوم Review کند؛ نه اینکه Demo سبز، تعداد Script یا Vendor feature زیاد شده باشد.
۲۸ ضدالگو در اتوماسیون تست
- Automate everything؛ هدف تعداد Check یا Coverage خام؛ سبز=بدون باگ؛ Automation=Quality.
- جایگزینی کامل انسان؛ تقسیم ثابت Manual/Automated؛ QA-only ownership؛ یک ابزار برای همه.
- latest/main/nightly بهجای Commit/Build؛ Environment بدون Config؛ Test Basis بینسخه.
- Question کلی؛ Claim بدون limit؛ Oracle از خود SUT؛ Approval یا Screenshot بهجای Oracle.
- Data مشترک؛ وابستگی به ترتیب؛ Sleep ثابت؛ Cleanup نامحدود؛ Parallel بدون Partition.
- Retry-until-green؛ نمایش فقط آخرین Attempt؛ ERROR/SKIPPED در PASS؛ Color-only dashboard.
- Flaky بدون series کنترلشده؛ Quarantine بیExpiry؛ حذف از Denominator؛ Re-entry بیEvidence.
- Log/Trace بدون Subject/Build/Attempt؛ Artifact بدون retention؛ Secret و PII در گزارش.
- Page Object/OOP/Programming اجباری؛ Codeless=بنبست؛ Recorder demo=production readiness.
- هر Check روی هر Commit؛ ROI تضمینی؛ ضریب هزینهٔ ثابت؛ صرفهجویی بدون Counterfactual.
- عدم Review ارزش؛ Suite فقط افزایشی؛ حذف بیRetirement؛ اصلاح Outcome بیCorrection.
- AI-generated=صحیح؛ Summary بدون Provenance؛ پذیرش خودکار Risk یا Release.
چکلیست ممیزی Automated Check
- Product/Goal/Risk/Basis/Repository/Commit/Build/Pipeline پین شدهاند.
- Check ID و version یکتا و supersedes قابل پیگیری است.
- Question، bounded Claim و Claim limit نوشته شدهاند.
- Subject و Trigger تغییرناپذیرند.
- Precondition، State، Data، Seed، Partition و Cleanup معلوماند.
- Oracle دارای Source، Rule، tolerance/window و method مستقل است.
- Implementation، Runner، Environment و Dependency نسخهدارند.
- تنها/ترتیب تصادفی/Parallel و Failure injection متناسب آزموده شدهاند.
- PASS/FAIL/ERROR/SKIPPED/INCONCLUSIVE و Unknown policy روشناند.
- همهٔ Retry Attemptها حفظ و First failure پنهان نشده است.
- Flaky/False Pass/False Fail تعریف و Population دارند.
- Quarantine دارای Reason، Risk impact، owner، expiry، replacement و re-entry است.
- Manifest، raw refs، time، digest، freshness، retention و redaction کاملاند.
- Owner capability، Triage SLA، Decision authority و reviewDue مشخصاند.
- Cost baseline، Value hypothesis، Measure و Guardrail وجود دارند.
- KEEP/ADAPT/QUARANTINE/RETIRE با Evidence تصمیمگیری میشود.
- Correction/Supersession و Retirement record تعریف شدهاند.
- هیچ ادعای نبود باگ، Coverage کافی، Quality، ROI یا Release از PASS نتیجه نشده است.
جمعبندی: از اسکریپت سبز تا ادعای محدود
واقعگرایی دربارهٔ اتوماسیون یعنی کمارزش دانستن آن نیست؛ یعنی دقیقکردن ارزش آن است. Automated Check خوب سؤال محدود دارد، Subject و Build را پین میکند، State/Data را کنترل میکند، Oracle قابل نقد دارد، همهٔ Attemptها و Evidence را حفظ میکند و هزینه/Signal آن بازبینی میشود. سبزشدن فقط یک Observation است؛ Claim معتبر از Contract و Review میآید.
با یک Check مصرفشده در یک Decision واقعی شروع کنید. اگر نمیتوانید بگویید «چه چیزی را میپرسد، چه چیزی را نمیگوید و چه زمانی باید بازنشسته شود»، افزودن Check بعدی فقط ابهام را سریعتر اجرا میکند.
سوالات متداول اتوماسیون تست
آیا اتوماسیون تست میتواند جای تست دستی را بگیرد؟
نه بهصورت کلی. یک Check محدود میتواند اجرای تکراری و مقایسهٔ تعریفشده را ماشینی کند، اما انتخاب Risk، نقد Oracle، اکتشاف، تفسیر Unknown و تصمیم همچنان به قابلیت انسانی و سازمانی نیاز دارد. ترکیب دقیق بر اساس سؤال و Context تعیین میشود.
اگر همه تستهای خودکار سبز باشند، آیا محصول آماده انتشار است؟
خیر. PASS فقط سازگاری Observation با Oracle همان Check/Attempt را بیان میکند. Release به Coverage model، Risk، Evidenceهای دیگر، Defect/Unknown، Policy و اختیار تصمیم نیاز دارد؛ Check سبز نه نبود باگ را ثابت میکند و نه مجوز انتشار است.
Flaky Test را فوراً حذف کنیم یا Retry بدهیم؟
هیچکدام بهصورت خودکار. ابتدا با series کنترلشده Variation را نشان دهید و همهٔ Attemptها را نگه دارید. سپس Cause/Risk را Triage کنید؛ اگر Signal موقتاً نامعتبر است، Quarantine زماندار با Owner، Control جایگزین و Re-entry rule بسازید. Retry نباید Failure اول را پنهان کند.
آیا برای اتوماسیون تست حتماً باید برنامهنویس حرفهای بود؟
نیاز فنی به Interface، Tool و Complexity بستگی دارد. مهمتر از عنوان «برنامهنویس» توانایی تعریف Claim/Oracle، کنترل State/Data، ساخت Comparison، بررسی Failure و نگهداشت امن است. بعضی مسائل کدنویسی عمیق میخواهند و برخی با Model، Low-code یا ابزار تخصصی حل میشوند.
موفقیت اتوماسیون تست را با چه KPI بسنجیم؟
یک KPI جهانی وجود ندارد. برای Decision/Risk مشخص میتوان Feedback time، First-attempt reliability، False-result rate، Evidence freshness، Maintenance load، Quarantine age و Decision consumption را با Population و Countermetric سنجید. Test count، Pass rate و Coverage خام را برای رتبهبندی تیم استفاده نکنید.
