بازنگری استراتژی اتوماسیون تست با دیدن چند نمودار قرمز شروع میشود، اما با فهرستکردن «شش نشانه» تمام نمیشود. Flaky شدن Checkها، طولانیشدن Pipeline، رشد هزینهٔ نگهداری یا بیاعتنایی تیم به Failure همگی Signal هستند؛ هیچکدام بهتنهایی ثابت نمیکند مشکل از Script، ابزار، Product، Test data، Environment، Architecture، Policy یا مالکیت است. نسخهٔ درمانی زودهنگام—افزایش Retry، خرید ابزار، Parallel کردن همهچیز یا بازنویسی Suite—ممکن است علامت را پنهان و ریسک را بیشتر کند.
این راهنما یک Automation Strategy Review & Recovery قابلممیزی میسازد: Decision و Window را مشخص میکند؛ Program، Portfolio و Evidence را نسخهدار میبیند؛ Signal را از Cause و Outcome جدا میکند؛ denominator و کیفیت داده را پیش از KPI کنترل میکند؛ و برای هر Slice یکی از تصمیمهای KEEP، ADAPT، MOVE، SPLIT، QUARANTINE، PAUSE یا RETIRE را با Evidence، مالک، Guardrail و تاریخ Rebaseline ثبت میکند. هدف تضمین کیفیت، ROI یا سرعت نیست؛ هدف ساختن تصمیمی محدود، قابلرد و قابلاصلاح است.
پاسخ کوتاه: چه زمانی استراتژی اتوماسیون تست را بازنگری کنیم؟
وقتی Context، Decision یا Evidence تغییر معنادار دارد: Product/Architecture یا Risk profile عوض شده؛ Suite دیگر در زمان تصمیم پاسخ نمیدهد؛ Failure قابلتشخیص نیست؛ هزینهٔ Change amplification یا نگهداری بالا رفته؛ Coverage ادعاشده با Riskهای جاری همراستا نیست؛ وابستگی، ابزار، نیروی مالک یا دسترسی ایران تغییر کرده؛ یا Outcome hypothesis قبلی دیگر قابلپشتیبانی نیست. بازنگری دورهای سبک نیز لازم است، اما Cadence ثابت جای Trigger واقعی را نمیگیرد.
| Signal | پرسش بازنگری | چیزی که هنوز ثابت نشده |
|---|---|---|
| Flaky یا Rerun زیاد | کدام Attempt، Subject و Failure class؟ | Script حتماً بد است |
| Pipeline کند | نتیجه برای کدام Decision دیر است؟ | Parallelism درمان درست است |
| نگهداری زیاد | کدام Change چه تعداد Check را تغییر میدهد؟ | POM یا Framework کم داریم |
| Coverage بالا/پایین | Denominator و Risk-to-Evidence چیست؟ | کیفیت بالا/پایین است |
| Failure نادیده گرفته میشود | Signal دقیق، تازه و actionable است؟ | فرهنگ یا فرد مقصر است |
| ROI نامشخص | Decision، Counterfactual، TCO و بازه چیست؟ | کل Program شکست خورده است |
مرز این مقاله با استراتژی، نجات Suite و چرخهٔ Check
راهنمای استراتژی اتوماسیون تست از Pilot تا Scale مالک طراحی برنامهٔ اولیه، Charter، انتخاب Candidate و Operating model است. راهنمای تشخیص و نجات Test Suite عیبیابی فنی Symptom و Failure mechanism در Suite ناسالم را پوشش میدهد. چرخهٔ Automated Check تا Evidence و Retirement قرارداد هر Check منفرد را میسازد. این صفحه یک لایه بالاتر است: آیا مجموعهٔ تصمیمها، Portfolio، سرمایهگذاری، Pipeline placement و Operating model هنوز با Context و Risk جاری Fit است؟
| سطح | Object | Decision نمونه | مالک محتوایی |
|---|---|---|---|
| Program | Automation strategy v7 | آیا Outcome/Scope/Model هنوز Fit است؟ | همین مقاله |
| Portfolio/Slice | Checkout API/UI/Contract checks | KEEP، MOVE، SPLIT، RETIRE؟ | همین مقاله |
| Suite diagnosis | Failure cluster | Product/Test/Data/Env/Infra علت محتمل؟ | مقالهٔ ۱۱۹۳ |
| Check lifecycle | AUTO-019 v4 | Claim/Evidence کافی؛ KEEP یا RETIRE؟ | مقالهٔ ۱۸۶۷ |
| Pipeline | Fast/Slow/Event lane | کدام Gate و Failure policy؟ | مقالهٔ Continuous Testing |
Review را با Decision شروع کنید، نه Dashboard
عبارت «آیا اتوماسیون ما خوب است؟» سؤال قابلممیزی نیست. تصمیم را محدود کنید: بودجهٔ سهماهه تمدید شود؟ Checkout UI Slice به API/Contract منتقل شود؟ Gate فعلی بماند؟ Runner داخلی جایگزین SaaS شود؟ ۴۰ Check منقضی Retire شوند؟ بدون Decision، تیم دهها Metric جمع میکند و در پایان هرکس همان برداشت اولیهٔ خود را حفظ میکند.
AutomationStrategyReview review_id: ASR-2026-Q3-07 decision: KEEP | ADAPT | MOVE | SPLIT | QUARANTINE | PAUSE | RETIRE decision_object: CHECKOUT-PORTFOLIO-v7 decision_owner: Engineering Quality Council evidence_owner: Automation Platform Owner window_utc: 2026-07-01T00:00:00Z/2026-07-31T23:59:59Z as_of_utc: 2026-08-03T09:00:00Z contexts: [repository, commit, build, pipeline, runner, environment, data] not_claimed: [no-defects, product-quality, causality, ROI, release-readiness] review_due_utc: 2026-10-01T00:00:00Z
Trigger، Cadence و Decision Window را جدا کنید
Trigger رویدادی است که بازنگری را لازم میکند؛ Cadence موعد مرور سبک؛ Window بازهای که دادهٔ قابلمقایسه از آن میآید. «هر فصل» Trigger نیست. مهاجرت Framework، تغییر معماری، جهش Runtime، افت Evidence completeness، خروج مالک کلیدی، انقضای Contract ابزار، تغییر Risk، افزایش Quarantine یا تغییر دسترسی Region میتواند Trigger باشد. Window باید Release mix، تعطیلات، Incident، تغییر Instrumentation و Freeze را ثبت کند تا دو بازهٔ نامشابه بهظاهر مقایسه نشوند.
- بازنگری Event-driven پس از Architecture/Tool/Data/Policy/Team change؛
- مرور سبک ماهانه برای Stale owner، Expired quarantine و Missing evidence؛
- بازنگری Portfolio در فصل یا Release train، مشروط به Window قابلمقایسه؛
- بازنگری فوری برای False pass بحرانی، افشای Secret، Gate bypass یا از دسترفتن Evidence؛
- Rebaseline پس از تغییر تعریف Metric، Runner، Shard، Retry یا Population.
Review Charter را نسخهدار و قابل توقف کنید
Charter باید Scope و Non-scope، سؤالها، Stakeholderها، اختیار تصمیم، منابع داده، محدودیت دسترسی، Timebox، Stop condition و Correction path داشته باشد. بازنگری نباید به ممیزی فردی یا جستوجوی مقصر تبدیل شود. اگر دادهٔ موردنیاز ناقص، دستکاریشده یا ناسازگار است، خروجی معتبر میتواند INSUFFICIENT_EVIDENCE باشد؛ اجبار به چراغ سبز/قرمز، عدمقطعیت را پنهان میکند.
ReviewCharter v3 purpose: decide portfolio disposition for the next decision window in_scope: CHECKOUT/API, CHECKOUT/UI, PSP-CONTRACT out_of_scope: individual performance, security certification, release approval questions: trust, timeliness, fitness, maintainability, evidence, economics sources: run events v4, git diff, incident links, work log, cost ranges authority: Portfolio Council; risk acceptance: Product/Risk Owner stop: population mismatch | schema drift | missing attempt history correction: supersede packet; never silently overwrite
Inventory بدون هویت، فقط شمارش فایل است
پیش از ارزیابی، Objectها را موجودیبرداری کنید: Program، Strategy version، Repository/Commit، Framework/Runner، Suite/Slice، Check ID/version، Product Risk، Question/Claim، Trigger، Lane/Gate، Environment، Data profile، Dependency، Oracle، Evidence، Owner و Lifecycle state. تعداد Test file یا Case برای فهم Coverage، ارزش یا سلامت کافی نیست؛ یک Scenario ممکن است در سه لایه تکرار شده یا صدها Data row یک Claim واحد را بررسی کند.
| Inventory field | نمونهٔ محدود | خطای رایج |
|---|---|---|
| Slice ID/version | CHECKOUT-PSP-v7 | «همهٔ تستهای E2E» |
| Claim/Risk link | RISK-PAY-04 / double charge | فقط نام Feature |
| Boundary | API+DB Stub | Unit/Integration برحسب پوشه |
| Run identity | Commit C20/Build B31/Env E4 | آخرین اجرای سبز |
| Owner/backup | Platform/Checkout | QA عمومی |
| Disposition | KEEP until 2026-10-01 | Active برای همیشه |
Baseline را پیش از دیدن نتیجه قفل کنید
Baseline فقط «ماه قبل» نیست. Population، Window، Change mix، Runner capacity، Shard count، Retry policy، Environment، Data seed، Dependency mode، Instrumentation schema، Exclusion و Missingness باید همسان یا تفاوتشان آشکار باشد. پس از دیدن عدد، جابهجا کردن آغاز Window، حذف Outlier یا تغییر denominator، Review را به داستانسازی تبدیل میکند.
BaselineContract baseline_id: BL-ASR-07-v1 population: eligible first attempts in CHECKOUT slices comparison: four matched synthetic change sets before/after exclusions: cancelled-before-start only retry_policy: preserve every attempt; no pass-only collapse runner: linux-x64/RUNNER-3; shards=4 instrumentation: run-event-schema-v4 missingness: report separately; UNKNOWN != PASS != zero confounders: framework upgrade, holiday window, environment incident
شش نشانه را Signal بدانید، نه Diagnosis
فهرست ششگانه برای Screening مفید است: Flakiness، ROI نامشخص، بیاعتمادی، نگهداری زیاد، Coverage بیمعنا و CI/CD کند. اما Review باید هر Signal را با Fact/Source/Time/Population/Denominator/Segment/Missingness/Confidence و Alternative explanation ثبت کند. «تیم اعتماد ندارد» بدون روش مشاهده ممکن است فقط نظر یک نفر باشد؛ «نگهداری زیاد» بدون Work definition شاید Feature adaptation را با Repair مخلوط کند.
SignalRecord signal_id: SIG-TRUST-04 observation: 17 of 63 first-attempt FAIL events had no triage within SLA source: run-events-v4 + triage-events-v2 window/population: fixed and denominator-preserving segments: slice, failure_class, owner, lane missing: 3 events lack correlation_id alternatives: noisy evidence | no owner | stale test | queue overload does_not_prove: team attitude, product defect, bad script, strategy failure
Lens اول: اعتماد به Signal و صحت Result
Trust با Pass rate بالا یکی نیست. باید First attempt، همهٔ Retryها، Final verdict و Failure class جدا بماند. Flaky یعنی در شرایط هویتی تعریفشده نتایج ناسازگار دیده شده؛ اما علت میتواند Race در Product، State مشترک، Dependency بیرونی، Runner pressure، Clock، Test implementation یا Oracle باشد. False pass از Flaky پنهان خطرناکتر است و با سبزشدن Dashboard دیده نمیشود؛ Mutant، Fault injection، Incident replay یا Oracle review میتواند بخشی از قدرت کشف را بررسی کند، نه اینکه صحت مطلق بسازد.
| Measure | Numerator/denominator | تقسیم لازم | Claim limit |
|---|---|---|---|
| First-attempt instability | Checkهای با Pass و Fail ناسازگار / Checkهای واجد تکرار کنترلشده | Product/Test/Data/Env/Infra/Unknown | Cause را ثابت نمیکند |
| Retry recovery | Fail→Pass / First-attempt Fail | Retry reason و Attempt | رفع مشکل نیست |
| False-fail sample | Failureهای ردشده / Failureهای adjudicated | Slice/Oracle | نمونه محدود است |
| Known escape link | Incidentهای قابلردیابی بدون Detection / Incidentهای eligible | Risk/Release | Coverage کامل یا علیت نیست |
Retry و Quarantine درمان نیستند
Retry ابزار مشاهده یا کاهش اصطکاک موقت است، مشروط به حفظ همهٔ Attemptها. Quarantine باید Scope، Risk، Alternative evidence، Owner، SLA، Expiry و شرط Re-entry داشته باشد. حذف Check از Gate بدون جبران Evidence ممکن است Pipeline را سبز و پوشش تصمیم را کمتر کند. از سوی دیگر، مسدودکردن همهٔ Changeها با Check شناختهشدهٔ غیرقابلاعتماد نیز هزینه دارد؛ تصمیم، Risk- و Evidence-specific است.
QuarantineDecision check_id/version: AUTO-019/v4 reason_class: ENVIRONMENT_COLLISION (hypothesis, not proven cause) risk_link: RISK-PAY-04 removed_from: presubmit-gate alternative_evidence: API invariant + ledger reconciliation check owner/backup: Checkout QA / Platform expires_utc: 2026-08-20T00:00:00Z reentry: 30 controlled runs; no conflicting result; evidence complete if_expired: ESCALATE, never auto-renew
Lens دوم: Timeliness در لحظهٔ تصمیم
Runtime خام نمیگوید Evidence دیر است. Queue، setup، execution، retry، artifact upload، analysis و notification را جدا کنید و از Commit/Trigger تا Decision-ready شدن بسنجید. Check دهدقیقهای شبانه ممکن است برای Release فردا بهموقع باشد؛ Check دودقیقهای که ۴۵ دقیقه در صف است برای Presubmit دیر است. P50 بدون Tail و بدون Segment، کندترین Risk-critical Slice را پنهان میکند.
| Clock | شروع | پایان | کاربرد |
|---|---|---|---|
| Queue delay | eligible | worker start | Capacity/priority |
| Execution | worker start | runner finish | Boundary/parallel/runtime |
| Evidence latency | runner finish | artifact indexed | Reporting pipeline |
| Triage latency | actionable failure | classification/owner | Operating model |
| Decision latency | code/change trigger | trusted result available | Lane fitness |
Parallelism را فقط با Isolation و Cost بسنجید
افزایش Worker میتواند Runtime را کم کند، اما Collision داده، Rate limit، Queue رقابتی، هزینهٔ Runner و Flakiness را بالا ببرد. آزمایش Shard باید همان Change set، Seed، Environment class و Retry policy را نگه دارد؛ P50/P95 Decision latency، Collision، Failure-class mix، Cost/run و Evidence completeness را همزمان ببیند. سریعترشدن با False pass یا Artifact ناقص بهبود نیست.
Lens سوم: Maintainability و Change Amplification
«ساعت نگهداری بیشتر از توسعه» تعریف پایدار ندارد. Feature adaptation، Test basis change، dependency migration، Flaky repair، Data repair، Environment repair و Framework work را جدا کنید. Change amplification بپرسد یک تغییر معتبر Product چند Check/Fixture/Selector/Mock/Golden file را بیدلیل تغییر داد و چرا. LOC یا تعداد Commit نگهداری، بهتنهایی هزینه یا ضعف معماری نیست.
MaintenanceEvent event_id: MNT-044 change_id: SYN-CHANGE-12 class: BASIS_ADAPTATION | TEST_REPAIR | DATA | ENV | FRAMEWORK | UNKNOWN files/checks/slices_touched: preserve counts and identities touch_time/queue_time/review_time: separate clocks trigger: intended behavior change vs irrelevant implementation detail recurrence: first | repeated pattern owner/action: local repair | API/testability request | redesign | retire not_claimed: individual productivity or code quality
POM، DRY و Framework نسخهٔ عمومی درمان نیستند
Page Object میتواند جزئیات UI را محصور کند، ولی Oracle ضعیف، shared state، boundary نامناسب یا Product بدون Testability را حل نمیکند. DRY افراطی یک تغییر کوچک را از زنجیرهٔ abstractionهای دور عبور میدهد؛ کپی محدود گاهی خواناتر است. Framework تازه نیز Migration، training، dual-run، artifact compatibility و Exit cost دارد. درمان باید به Failure mechanism یا Change mechanism متصل باشد، نه به محبوبیت Pattern.
Lens چهارم: Portfolio Fitness و محل مناسب Evidence
Portfolio را با «چند درصد Automated؟» نسنجید. Risk/Question را به کوچکترین Boundaryای وصل کنید که Claim لازم را با Fidelity کافی تولید میکند: Unit برای منطق محدود، Component/Contract برای تعامل کنترلشده، Integration برای مرز واقعی منتخب، System/UI برای Wiring یا Journey که پایینتر قابلاثبات نیست. Pyramid سهمیهٔ اجباری نیست؛ معماری، Risk، هزینه و قابلیت کنترل تعیینکنندهاند.
| Portfolio question | Evidence | تصمیم محتمل |
|---|---|---|
| آیا چند Check یک Claim را تکرار میکنند؟ | Claim-to-check map | KEEP نماینده؛ RETIRE duplicate |
| آیا Risk بدون Evidence است؟ | Risk-to-evidence matrix | ADD یا ACCEPT/TRANSFER risk |
| آیا Boundary بیش از نیاز گسترده است؟ | Failure localization و fidelity | MOVE/SPLIT پایینتر |
| آیا Check دیگر Decision را تغذیه نمیکند؟ | consumer/action history | ADAPT یا RETIRE |
| آیا رفتار منقضی شده؟ | Basis/Product version | RETIRE با trace |
| آیا Evidence فقط در Production ممکن است؟ | claim limit | Shift-right control، نه Check جعلی |
Coverage را با Denominator و Claim محدود تعریف کنید
Code coverage میتواند بخش اجرانشده را پیدا کند، اما کیفیت Oracle یا کفایت Risk را ثابت نمیکند. Requirement، Risk، State، Transition، Rule، Platform، Data class و Journey هرکدام denominator متفاوت دارند. راهنمای حکمرانی ادعای پوشش تست برای تعریف دقیق Denominator است؛ در Review فقط Coverageای را وارد کنید که Population، روش، نسخه، Missing و Claim limit روشن دارد.
CoverageClaim claim_id: COV-RISK-07-v2 question: which current P1/P2 payment risks have decision evidence? denominator: 12 active versioned risks in RISK-REGISTER-v9 numerator: 9 with fresh evidence satisfying minimum contract excluded: 2 accepted risks (reported separately, not removed silently) unknown: 1 missing owner result: 9/12, not “75% product quality” expires: on Risk/Register/Product/Oracle change
Lens پنجم: Evidence و Diagnosability
Failure وقتی actionable است که Subject، Commit/Build، Check version، Attempt، Runner، Environment، Data/Seed، dependency mode، Expected/Actual، timestamp، trace/log/artifact، correlation و Unknownها را داشته باشد. Screenshot تنها ممکن است وضعیت backend یا Commit را نشان ندهد؛ Log زیاد هم بدون Correlation و Redaction مفید نیست. Evidence باید تازه، قابلانتساب، integrity-aware و بهاندازهٔ Risk نگهداری شود.
| Evidence gate | PASS وقتی | HOLD وقتی |
|---|---|---|
| Identity | Subject/Build/Check/Attempt یکتا | «آخرین Run» |
| Provenance | Source/collector/version معلوم | Copy-paste بدون مبدأ |
| Completeness | Manifest و Missing آشکار | Artifact غایب=Pass |
| Freshness | TTL متناسب با Decision | شاهد Build قدیمی |
| Integrity | digest/access/history | فایل قابلویرایش بیردپا |
| Privacy | synthetic/redacted/minimized | Secret/PII در Trace |
قبل از Dashboard، Metric Contract را ممیزی کنید
Flaky rate، Pass rate، Runtime، Coverage، Maintenance cost و Defect detection بدون قرارداد قابلبازیاند. راهنمای ممیزی یکپارچگی معیارهای تست کنترل Schema/Join/Window/Population را پوشش میدهد. در Strategy Review، هر Metric باید Decision role، تعریف، واحد، numerator، denominator، window، segment، exclusion، missing/late policy، source، owner، threshold، countermetric و چیزی را که ثابت نمیکند ثبت کند.
MetricContract metric_id: M-DECISION-LATENCY-v3 decision_role: primary for PRESUBMIT lane fitness unit: minutes; distribution P50/P95/N start/end: change eligible → trusted result indexed population: eligible synthetic change runs exclusions: cancelled-before-queue; reported separately late/missing: remain in denominator; label UNKNOWN segments: slice, runner, failure class countermetrics: collision, false-result sample, cost/run, evidence completeness not_claimed: developer productivity, product quality, causality
Pass Rate، Test Count و Automation Percentage را محدود کنید
- Pass rate: Retry-collapse، Not-run، Skipped و Population change میتواند آن را سبز کند؛ Evidence of absence نیست.
- Test count: Data rows، split/merge و duplicate Claim آن را تغییر میدهد؛ ارزش یا Coverage نیست.
- Automation percentage: denominator «همهٔ تستها» پایدار نیست و فعالیتهای انسانی/غیرقابلاتوماسیون را بیارزش جلوه میدهد.
- Code coverage: reach را میسنجد، نه Assertion strength یا Risk sufficiency.
- Defects found: به Product change، Risk، usage، taxonomy و investigation وابسته است و KPI فرد نیست.
- Deployment frequency: Outcome مشترک سیستم تحویل است؛ نسبتدادن آن به Automation نیازمند طراحی ارزیابی جداست.
Lens ششم: Value، TCO و Capacity
هر Check لازم نیست ROI مستقل مثبت نشان دهد؛ بعضی Controlها برای Risk، تعهد، قابلیت تغییر یا Evidence لازماند. در سطح تصمیم مناسب، Benefit hypothesis را کنار Full lifecycle cost و Alternatives بگذارید. راهنمای ROI و TCO اتوماسیون تست سناریوی Low/Expected/Stress و Counterfactual را میسازد. «زمان اجرای دستی × تعداد اجرا» تنها یک جزء بالقوه است و نباید کشف زودتر، کیفیت یا درآمد را بدون شاهد پولی کند.
TCO(review horizon) =
build + adapt + review + run + infrastructure + data + environment
+ triage + flaky/false-result repair + evidence storage
+ security/privacy + training + vendor/currency + migration + exit
ValueHypothesis = Decision + Mechanism + Population + Measure + Window
+ Baseline/Alternative + Guardrail + ClaimLimit
هزینهها را Range بدهید، نرخ ارز/پرداخت/مالیات را با مالک Finance یا Legal محلی بررسی کنید و اعداد ساختگی را «تومان واقعی» معرفی نکنید. Sunk cost دلیل KEEP نیست؛ هزینهٔ Migration نیز دلیل ماندن همیشگی نیست. Capacity آزادشده را از قبل به Risk، Testability، exploratory work یا نگهداری تخصیص دهید، وگرنه «صرفهجویی» قابلمشاهده نمیشود.
Ownership و Authority را از Assignee جدا کنید
کسی که Script را تعمیر میکند الزاماً اختیار قبول Risk، حذف Gate، تمدید Vendor یا تخصیص بودجه ندارد. برای Program، Slice، Infrastructure، Data، Oracle/Basis، Pipeline/Gate، Evidence، Security، Cost و Decision مالک و Backup تعیین کنید. «QA مسئول Automation است» مرز عملی نمیسازد؛ Production-code Unit checks، Contract provider tests، Platform runner و Cross-system journeys میتوانند مالکهای متفاوت داشته باشند.
| Decision | Evidence provider | Authority نمونه | محدودیت |
|---|---|---|---|
| Repair Check | Test/Developer | Slice owner | Risk را قبول نمیکند |
| Remove from gate | Pipeline+Risk evidence | Gate owner | Alternative evidence لازم |
| Accept residual risk | Risk/evidence packet | Product/Risk owner | QA پیشفرض نیست |
| Buy/migrate tool | PoC/TCO/security | Budget/Procurement authority | Popularity شاهد نیست |
| Retire slice | Claim/usage/risk map | Portfolio owner | Trace و rollback لازم |
Infrastructure، Environment، Data و Product را از Test جدا کنید
شکست Runner، Environment readiness، Seed collision، expired credential، Dependency rate limit، Product race و Test bug یک Result vocabulary دوحالته را آلوده میکنند. Classification باید Product/Test/Data/Environment/Infrastructure/Dependency/Security/Unknown را حفظ کند و First divergence را دنبال کند. UNKNOWN شکست Review نیست؛ حذف آن از denominator یا تبدیلش به Test failure گزارش را تحریف میکند.
- Product: رفتار SUT با Oracle معتبر ناسازگار؛
- Test: implementation یا assertion با Basis/Contract ناسازگار؛
- Data: seed، partition، freshness یا cleanup نقض شده؛
- Environment: config، service readiness یا drift؛
- Infrastructure: runner، queue، storage، network یا artifact collector؛
- Dependency: third party/Stub contract/availability؛
- Security/Policy: access، secret، retention یا region constraint؛
- Unknown: Evidence برای تفکیک کافی نیست.
CI/CD alignment یعنی Placement و Failure Policy، نه اجرای همهچیز روی Commit
معماری Continuous Testing در CI/CD Fast/Slow/Event-driven lane و Gate contract را تفصیل میدهد. Review باید بپرسد هر Check برای کدام Decision، با چه Trigger، Budget، Selection، Failure policy، Artifact، Owner و Fallback اجرا میشود. اجرای همهٔ Suite روی هر Commit میتواند Feedback را کند و منابع را بسوزاند؛ اجرای انتخابی نیز بدون change-impact confidence و scheduled safety net ممکن است Risk را جا بیندازد.
LaneReview lane: PRESUBMIT-FAST-v5 decision: allow merge to protected branch eligible_population: changed checkout components selection: dependency map v4 + mandatory risk smoke budget: P95 decision latency, not raw runtime only failure_policy: FAIL/HOLD/INCONCLUSIVE/INFRA_ERROR distinct artifacts: manifest required; empty/missing report => HOLD fallback: manual/risk review, never silent bypass promotion: artifact identity preserved across later lanes
Tool یا Framework را فقط پس از تشخیص بازبینی کنید
Tool review باید Offering/version، Protocol/browser/device support، isolation، trace، result semantics، CI runner، data/environment control، accessibility، security/privacy، export/API، skill availability، support، Region/account/payment و Exit را روی Fixture نماینده بسنجد. Demo سبز یا برند مشهور Fitness را ثابت نمیکند. ابزار تازه ممکن است همان Oracle ضعیف و Portfolio نامناسب را سریعتر اجرا کند.
| PoC gate | Evidence نماینده | Hard stop نمونه |
|---|---|---|
| Fidelity | Risk-critical behavior روی Boundary لازم | Capability حیاتی Stub-only |
| Reliability | controlled repeats/parallel/collision | Attempt history از دست میرود |
| Diagnosability | trace/log/correlation/manifest | Build/Subject قابلانتساب نیست |
| Security | identity/secret/redaction/access | Secret در Artifact |
| Operability | runbook/owner/upgrade/rollback | بدون Export/Exit قابلآزمون |
| Iran continuity | واقعاً تستشده account/region/payment | دورزدن محدودیت بهعنوان Plan |
ملاحظات ایران را Contract کنید، حدس نزنید
دسترسی SaaS، ثبتنام، MFA، شماره، Region، IP policy، پرداخت ارزی، نرخ/صورتحساب، Registry/package/CDN، پشتیبانی و Export ممکن است تغییر کند. هر Offering را در تاریخ مشخص با حساب مجاز و روش سازمانی آزمون کنید و Fallback/Exit داشته باشید؛ VPN یا حساب قرضی برنامهٔ تداوم نیست. برای محصول فارسی، UTF-۸، RTL/LTR و Bidi، ZWNJ، ی/ی و ک/ک، رقم فارسی/عربی/لاتین، IRR در برابر نمایش برچسبدار تومان، UTC instant و Asia/Tehran را در Data/Oracle/Evidence نگه دارید. الزام حقوقی/مالی را از متخصص محلی بگیرید.
امنیت، Privacy و Supply Chain بخشی از Strategy Fitness است
- هویت سرویس نامدار، کمترین دسترسی، MFA/JIT و Joiner-Mover-Leaver؛
- Secret از code/log/trace/screenshot/report جدا و دورهای rotate؛
- دادهٔ synthetic یا minimized/redacted با retention/deletion مشخص؛
- Dependency/Action/Image/Plugin pin، provenance، update و vulnerability response؛
- Artifact access، digest، expiry و incident clock؛
- AI-generated Check فقط پس از Basis/Oracle/security/licence review؛
- Model/provider/prompt/version و False-pass risk در Evidence؛
- Export/backup/restore/rollback/exit پیش از بحران آزموده شود.
از Signal به Hypothesis بروید، نه Root Cause قطعی
Signal ممکن است چند عامل مشارکتکننده داشته باشد. Hypothesis را falsifiable بنویسید و Alternative/counterevidence حفظ کنید. Five Whys یا جلسهٔ کارشناسی دلیل قطعی نیست. Discriminating test باید پیشبینی متفاوت دو توضیح را جدا کند: اگر Queue عامل اصلی است، افزایش ظرفیت در Window کنترلشده Queue delay را کم میکند ولی Runtime ثابت میماند؛ اگر shared data عامل Flake است، partition کردن Collision را کم میکند، نه الزاماً همهٔ Failureها را.
Hypothesis H-07 signal: P95 decision latency increased in CHECKOUT-UI candidate mechanism: runner queue saturation prediction: matched runs with reserved capacity reduce queue, not execution alternative: environment readiness dominates total delay counterevidence: queue stable while readiness wait increased experiment: reversible two-window comparison on synthetic changes primary/counter/guardrail: queue P95 / execution P95 / collision+cost decision: ADAPT only if evidence quality gate passes
Experiment باید Reversible و Decision-linked باشد
تغییر Framework کامل، حذف Gate یا بازنویسی صدها Check آزمایش کوچک نیست. Pilot را روی Slice نماینده، دادهٔ synthetic، Blast radius محدود، Baseline قفلشده، Comparison مناسب، Stop/rollback و Owner اجرا کنید. Primary metric را از قبل انتخاب و Countermetric/Harm floor را ثبت کنید. نتیجه میتواند SUPPORT، CONTRADICT یا INCONCLUSIVE باشد؛ «Pilot تمام شد» Outcome نیست.
ReviewExperiment experiment_id: EXP-ASR-12-v1 hypothesis: moving duplicate UI rules to API preserves decision evidence population: 12 synthetic matched changes; not production traffic baseline/comparison: current UI slice vs candidate API+one wiring UI primary: decision latency distribution counter: known-fault detection + evidence completeness harm_floor: no loss of RISK-PAY-04 evidence stop/rollback: missing correlation | false-pass fixture | secret exposure authority: Portfolio owner; result may be INCONCLUSIVE
Decision vocabulary را از «خوب/بد» فراتر ببرید
| Disposition | معنا | Evidence/شرط |
|---|---|---|
| KEEP | در Window بعدی بدون تغییر اساسی | Claim/owner/fitness تازه |
| ADAPT | Oracle/Data/implementation/lane اصلاح شود | Mechanism و acceptance |
| MOVE | Evidence به Boundary/Lane دیگر منتقل شود | Fidelity و alternative coverage |
| SPLIT | Claimهای ناهمگن جدا شوند | هویت و مالک تازه |
| QUARANTINE | موقتاً از Gate خارج | Risk/expiry/fallback |
| PAUSE | تا رفع dependency/decision متوقف | review date و evidence gap |
| RETIRE | فعالیت پایان؛ تاریخچه حفظ | Basis/Risk check، trace، rollback |
| INSUFFICIENT | Evidence برای تصمیم کافی نیست | یافته و برنامهٔ تکمیل |
Hard Gate را با Score میانگین نگیرید
Scorecard برای مقایسه کمک میکند، اما Security breach، Missing Oracle، نبود Owner، از دسترفتن Attempt history یا فقدان Exit نباید با Runtime خوب جبران شود. ابتدا Hard gateها را اعمال کنید؛ سپس گزینههای eligible را با Weightهای نسخهدار و Sensitivity مقایسه کنید. مجموع ۸۲ از ۱۰۰ حقیقت طبیعی نیست و تفاوت Rating یکامتیازی ممکن است از عدمقطعیت کوچکتر باشد.
DecisionRecord decision_id: DEC-ASR-07-v1 object: CHECKOUT-UI-v7 status: ADAPT (not “healthy”) evidence_for/against: linked immutable packet hard_gates: oracle PASS; owner PASS; evidence HOLD resolved before rollout alternatives: KEEP | MOVE | RETIRE uncertainty/dissent: preserved with names/roles, not erased conditions/expiry: valid for next 30-day synthetic Pilot only rollback/reopen: trigger and authority specified not_claimed: faster delivery, ROI, quality improvement, real-product fitness
Recovery Portfolio را WIP-limited کنید
پنجاه Finding همزمان برنامه نیست. Itemها را با Harm/urgency، Evidence confidence، decision impact، reversibility، dependency، effort range، learning value و displaced work اولویت دهید؛ WIP limit و Owner/Backup داشته باشید. تعمیر Flaky، بهبود Testability، تقسیم Lane، پاکسازی Data، Retire کردن duplicate، مستندسازی Oracle و Tool PoC انواع متفاوت کارند و Completion criterion یکسان ندارند.
| Portfolio item | Done evidence | Guardrail | بعدی |
|---|---|---|---|
| Attempt history repair | all attempts retained/reconciled | storage/privacy | Rebaseline flake |
| Data partition Pilot | controlled collision comparison | seed cost | Scale/stop |
| UI→API move | fault fixture + one wiring UI | fidelity | retire duplicate |
| Expired quarantine | re-entry or authorized retire | risk fallback | correction |
| SaaS exit drill | export/restore/run replay | secret/access | continuity decision |
Adoption را با Login و اجبار نسنجید
اگر Failureها نادیده گرفته میشوند، اول Actionability و Interface را بررسی کنید: نتیجه به فرد درست، در زمان درست، با Context و اختیار لازم میرسد؟ Acknowledgement، time-to-classify، resolved-with-evidence، false-alert dismissal reason و feedback-to-owner مفیدتر از Login است. راهنمای مدیریت تغییر در QA Readiness، Pilot، Adoption و تصمیم را تفصیل میدهد؛ اجبار استفاده یا تعداد کلیک، پذیرش معنادار نیست.
منابع رسمی و حدود انتقال آنها
- ISTQB CT‑TAS v1.0 از گزارش و Metric برای یافتن Trend، Root-cause analysis و تغییر تمرکز نگهداری/بهبود/قابلیت استفاده میکند؛ این مقاله Schema و آستانهٔ خود را از آن نقل نمیکند.
- ISTQB CTAL‑TAE v2.0 Pilot، Maintainability، deployment risk، logging، fixtures، CI/CD، metric و continuous improvement را پوشش میدهد؛ Syllabus نسخهٔ استخدامی، تضمین موفقیت یا یک Architecture اجباری نیست.
- DORA Test Automation capability Suite سریع و قابلاعتماد در Pipeline و testing در طول lifecycle را توصیه میکند؛ یافتهٔ جمعیتی DORA KPI تیم QA یا اثبات علی محلی نیست.
- Google Testing Blog دربارهٔ Flaky tests تجربهٔ یک مقیاس و Context خاص و trade-offهای Retry/Quarantine را گزارش میکند؛ نرخهای Google Benchmark یا هدف سایت ایرانی نیست.
- Google دربارهٔ Brittle tests و expressive APIs نشان میدهد brittleness میتواند Signal کمبود API مناسب باشد؛ نسخهٔ عمومی برای هر Stack یا اثبات Cause نیست.
توصیههای ابزارمحور را فقط در Context همان ابزار منتقل کنید. Review loop، نام Stateها، گروه کنترل و Fixture این مقاله یک ترکیب مهندسی نویسنده برای تصمیمپذیری است، نه Standard، Certification، Benchmark یا الزام حقوقی.
آزمایش مستقل: شش هشدار در برابر ۵۴۰ کنترل
یک Fixture کاملاً ساختگی شش علامت Flaky/ROI نامشخص/Failure نادیدهگرفتهشده/نگهداری بالا/Coverage نمایشی/Pipeline کند را True کرد. Checker سطحی فقط وجود همان کلمات را دید و اعلام کرد Review آماده است:
SIX_WARNING_SIGNS_AUTOMATION_STRATEGY_REVIEW_READY
ممیزی مستقل دقیقاً ۵۴۰ کنترل یکتای group-qualified را در ۳۰ گروه identity، decision، window، context، boundary، charter، inventory، baseline، signal، trust، timeliness، maintainability، portfolio، coverage، value، cost، ownership، capability، infrastructure، data، evidence، diagnosis، hypothesis، experiment، option، decision_right، recovery، governance، correction و limits مطالبه کرد. Fixture شعاری هیچکدام را نداشت:
HOLD-540 NO_REAL_TARGET_PASS
Rule جداگانه تأیید کرد Fixture هیچ Organization، Product، Repository، Pipeline، Worker، User، Payment یا Outcome واقعی ندارد. پس از Pin کردن هر ۵۴۰ کنترل ساختاری، خروجی فقط آمادگی برای بازبینی انسانی بود:
READY_FOR_AUTOMATION_STRATEGY_REVIEW-0
صفر Finding ساختاری، صحت Oracle/Data/Evidence، وجود Cause واقعی، کفایت Coverage، سلامت Suite، امنیت، ROI، Product quality، رضایت تیم یا موفقیت Recovery را ثابت نمیکند. این کنترل عمداً ساختار تصمیم را میسنجد، نه واقعیت جهان را.
آزمایشگاه آفلاین فارسی: Checkout ساختگی
Lab با شناسهٔ SYN-ASR-CHECKOUT-01 شبکه و Production ندارد. Product/شرکت/کاربر/سفارش/پرداخت/بانک/PSP واقعی در آن نیست. Objectهای fake شامل Order، PaymentAttempt، PSP Stub، Callback، Ledger و Reconciliation است. مبلغ فقط IRR ساختگی است و view تومان با برچسب صریح «نمایشی» از تقسیم قراردادی تولید میشود؛ هیچ ادعای بانکی، مالیاتی، امنیتی، بازار یا انطباق ایران ندارد.
Lab matrix Unicode: ی/ي، ک/ك، ZWNJ، RTL/LTR/Bidi Digits: ۱۲۳ | ١٢٣ | 123 Money: canonical fictional IRR | labelled presentation-only toman Time: UTC instant | Asia/Tehran display | presentation-only Jalali Faults: timeout-before/after-fake-commit, duplicate/late/reordered callback Infra: queue delay, runner loss, missing artifact, shard collision Attempts: first + retry retained; PASS/FAIL/ERROR/INCONCLUSIVE distinct Boundaries: Unit/Component/API/Contract/System/UI; no network
Dashboard ساختگی ۹۶٪ Pass، ۸۷٪ Automation و ۲۲ دقیقه Runtime نشان میدهد، اما Attemptها را collapse کرده، denominator Coverage ندارد، سه Artifact گم شده و دو Quarantine منقضیاند؛ بنابراین Review آن را «موفق/ناموفق» نمینامد. ابتدا Instrumentation را HOLD میکند، Attempt history را repair و Rebaseline میکند؛ سپس روی Slice کوچک فرضیهٔ Data partition و انتقال Ruleهای تکراری UI به API را میآزماید. این نتیجه Simulation است، نه توصیه برای یک محصول واقعی.
برنامهٔ ۳۰روزهٔ بازنگری بدون محصول واقعی
| بازه | کار | خروجی | Gate |
|---|---|---|---|
| روز ۱–۵ | Decision/Charter/Inventory/identity | Review pack v1 | Scope/authority معلوم |
| روز ۶–۱۰ | Metric/data/evidence audit | Baseline + missingness | Attempt/denominator معتبر |
| روز ۱۱–۱۵ | Signal classification/hypotheses | Alternative-aware diagnosis | No premature cause |
| روز ۱۶–۲۲ | دو Experiment ساختگی محدود | Evidence packet | Guardrail/rollback |
| روز ۲۳–۲۶ | Options/hard gates/TCO ranges | Draft dispositions | Dissent/unknown preserved |
| روز ۲۷–۳۰ | Decision/recovery WIP/rebaseline | Signed Review v1 | Correction path فعال |
Pilot تنها Workflow و قابلیت Evidence را میآزماید. پیش از استفادهٔ واقعی باید Privacy/Security/Legal/Financial، نمونهگیری، دسترسی، Risk authority، Product fidelity، محیط و عملیات توسط مالکان ذیصلاح بررسی شود. تصمیم Scale فقط بعد از Pilot مستقل و Evidence تازه گرفته میشود.
۲۸ ضدالگوی بازنگری استراتژی اتوماسیون
- اتوماسیون را ضرورت یا هدف نهایی دانستن؛
- شش Signal را شش Cause قطعی خواندن؛
- Review بدون Decision و Window؛
- Scope مبهم «همهٔ تستها»؛
- موجودی برحسب فایل یا تعداد Case؛
- تغییر Baseline پس از دیدن نتیجه؛
- حذف Missing از denominator؛
- Collapse کردن Retry به Pass نهایی؛
- Flaky را همیشه Test bug دانستن؛
- Quarantine بدون Risk/owner/expiry؛
- Parallelism بدون Isolation/Cost؛
- Runtime بدون Queue/Evidence/Triage؛
- POM/DRY/Framework بهعنوان درمان عمومی؛
- نگهداری برحسب LOC یا Commit فرد؛
- Pyramid بهعنوان سهمیهٔ ثابت؛
- Coverage درصدی بدون denominator؛
- سبز بودن بهعنوان نبود Defect؛
- Screenshot یا Log زیاد بهجای Evidence manifest؛
- Pass rate/Test count/Automation% بهعنوان ارزش؛
- نسبتدادن Outcome مشترک به QA؛
- ROI با فرمول صرفهجویی دستی و بدون TCO؛
- خرید Tool قبل از Diagnosis؛
- Demo یا برند بهجای PoC نماینده؛
- VPN/حساب قرضی بهعنوان تداوم ایران؛
- AI-generated Check بدون Oracle review؛
- Score میانگین برای جبران Hard gate؛
- بازکردن دهها Recovery item بدون WIP؛
- ویرایش خاموش Decision/Metric بهجای Correction.
چکلیست مالک بازنگری: ۳۴ سؤال
- Review ID و Strategy version یکتا است؟
- Decision و صاحب اختیار معلوم است؟
- Window/as-of/timezone قفل شده؟
- Scope و Non-scope نوشته شده؟
- Product/Risk/Architecture Context نسخه دارد؟
- Program/Slice/Check identity قابلردیابی است؟
- Repository/Commit/Build/Pipeline معلوم است؟
- Runner/Environment/Data/Dependency هویت دارد؟
- Claim و Claim limit هر Slice روشن است؟
- Trigger از Cadence جداست؟
- Baseline پیش از Result قفل شده؟
- Population/denominator/exclusion معلوم است؟
- Missing/Late/Unknown policy وجود دارد؟
- Attempt history و Retry حفظ میشود؟
- Flaky از False fail/False pass جداست؟
- Failure classification شامل Unknown است؟
- Queue/Run/Evidence/Triage clocks جداست؟
- Tail/N/segment کنار میانگین آمده؟
- Change amplification و work class ثبت میشود؟
- Risk-to-evidence و duplicate map داریم؟
- Coverage claim denominator و expiry دارد؟
- Evidence identity/provenance/freshness/integrity دارد؟
- Metric contract و countermetric داریم؟
- People scoring صریحاً ممنوع است؟
- TCO Range و Alternative/Counterfactual آمده؟
- Owner/backup و authority هر تصمیم مشخص است؟
- Security/privacy/retention/secret کنترل شده؟
- Iran access/payment/export/fallback واقعاً آزموده شده؟
- هر Hypothesis Alternative و counterevidence دارد؟
- Experiment baseline/guardrail/stop/rollback دارد؟
- Hard gate پیش از Score اعمال میشود؟
- Disposition شرط، expiry و reopen دارد؟
- Recovery Portfolio WIP و displaced work دارد؟
- Rebaseline، correction و supersession برنامه دارد؟
Correction و Rebaseline را از ابتدا طراحی کنید
اگر بعداً معلوم شد Eventها duplicate بوده، Timezone اشتباه، Retry پنهان، denominator ناقص یا Oracle تغییر کرده، Packet قبلی را بیصدا ویرایش نکنید. Correction باید شناسهٔ قبلی، خطا، اثر بر Metric/Finding/Decision، دامنهٔ متاثر، نسخهٔ جایگزین، اطلاعرسانی و Reopen authority را ثبت کند. تعریف تازهٔ Metric یا Pipeline نیز Trend break میسازد و Rebaseline میخواهد.
Correction correction_id: COR-ASR-07-02 supersedes: REVIEW-ASR-07-v1 error: retry attempts were collapsed by schema-v3 adapter affected: trust metric, two quarantine decisions, dashboard unchanged: raw artifacts with verified digest action: rebuild with schema-v4; rebaseline; reopen DEC-04/05 notified: evidence/portfolio/gate/risk owners history: v1 remains readable; v2 becomes current
خروجی نهایی Review Pack چیست؟
- Review Charter و Decision/Authority map؛
- نسخهٔ Strategy/Context/Inventory و Claim map؛
- Baseline/Metric/Data-quality contracts؛
- Signal register با Alternatives و Unknownها؛
- Trust/Timeliness/Maintainability/Portfolio/Evidence/TCO findings؛
- Hypothesis و Experiment packet با Guardrail؛
- Option matrix و Hard-gate results؛
- Dispositionهای شرطدار برای هر Slice؛
- Recovery Portfolio محدود به WIP؛
- Rebaseline/Review-due/Correction/Supersession record.
Review Pack گزارش زیبای یکبارمصرف نیست؛ ورودی تصمیم و یادگیری بعدی است. نتیجهٔ درست میتواند نگهداشتن بخشی از Program، Adapt کردن بخشی دیگر و Retire کردن سرمایهگذاری قدیمی باشد. یک Label کلی «Strategy موفق/شکستخورده» ناهمگنی Portfolio را پنهان میکند.
جمعبندی
بازنگری استراتژی اتوماسیون تست با Signal آغاز میشود و به تصمیم نسخهدار ختم میشود: Decision/Window را قفل کنید، Inventory و Baseline بسازید، Trust/Timeliness/Maintainability/Portfolio/Evidence/Value را با قرارداد داده بسنجید، Cause را بهصورت Hypothesis حفظ کنید، گزینهها را با Hard gate و Experiment محدود مقایسه کنید و برای هر Slice KEEP/ADAPT/MOVE/SPLIT/QUARANTINE/PAUSE/RETIRE یا INSUFFICIENT ثبت کنید. سپس Recovery را WIP-limited، قابل rollback و قابل Correction نگه دارید.
سؤالات متداول
هر چند وقت یکبار استراتژی اتوماسیون تست را بازنگری کنیم؟
عدد جهانی ندارد. مرور سبک را با Cadence محلی انجام دهید، اما بازنگری عمیق را به Triggerهایی مانند تغییر Product/Risk/Architecture/Tool/Owner، جهش Signal، Incident، انقضای Contract یا افت Evidence quality وصل کنید. Window باید قابلمقایسه باشد و هر تغییر Metric یا Pipeline به Rebaseline منجر شود.
Flaky Test چند درصد باشد تا استراتژی را عوض کنیم؟
آستانهٔ جهانی نیست. تعریف Population/Attempt، Risk، Lane، impact بر Decision، Alternative evidence و علتهای ممکن مهماند. ابتدا Attempt history و Metric contract را معتبر کنید، سپس Slice و Failure class را جدا ببینید. یک Flake بحرانی در Gate مالی میتواند مهمتر از تعداد زیادی Check کمریسک باشد.
آیا ROI نامشخص یعنی اتوماسیون شکست خورده است؟
خیر. ممکن است Decision یا Counterfactual تعریف نشده، داده ناقص، Benefit دور و مشترک یا Control برای Risk لازم باشد. TCO، Alternative، Range، Guardrail و Claim limit را بسازید. نتیجه میتواند Keep مشروط، Adapt، جمعآوری Evidence بیشتر یا Retire یک Slice باشد؛ نه حکم یکسان برای کل Program.
آیا برای کاهش نگهداری باید Framework یا ابزار را عوض کنیم؟
فقط اگر Evidence نشان دهد Mechanism مشکل با قابلیت ابزار/Framework مرتبط است و PoC نماینده Benefit را با هزینهٔ Migration، Skill، Security، Iran continuity و Exit میسنجد. Shared data، Oracle ضعیف، Product بدون Testability یا Portfolio نامناسب با تعویض Syntax خودکار حل نمیشود.
چه کسی تصمیم Retire یا حذف Check از Gate را میگیرد؟
عنوان ثابت نیست. Evidence provider و Maintainer پیشنهاد میدهند؛ Gate owner دربارهٔ Pipeline policy و Product/Risk owner دربارهٔ Residual risk اختیار دارد. تصمیم باید Alternative evidence، شرط، Expiry، Rollback/Reopen و Dissent را ثبت کند. Assignee یا QA بهطور پیشفرض صاحب پذیرش ریسک نیست.
