BDD با Cucumber؛ از Discovery تا Pilot و Exit

نوشتن چند خط Given/When/Then تیم را BDDمحور نمی‌کند. اگر Product، Domain، توسعه و QA پیش از پیاده‌سازی دربارهٔ مثال‌های واقعی گفت‌وگو نکنند، فایل‌های Gherkin فقط لایه‌ای تازه روی تست‌های قدیمی می‌شوند: طولانی، UIمحور، شکننده و نامفهوم. در جهت مقابل، یک تیم می‌تواند Discovery مبتنی بر مثال را مفید اجرا کند و اصلاً Cucumber نخرد یا همهٔ Requirementها را به Gherkin تبدیل نکند.

این راهنما به سؤال عملی‌تری پاسخ می‌دهد: آیا BDD و Cucumber برای مسئله، تیم و محصول ما مناسب‌اند و چگونه بدون قفل‌شدن به ابزار امتحانشان کنیم؟ از فرضیهٔ پذیرش و سه Practice رسمی BDD شروع می‌کنیم، مرز Gherkin و Step Definition را روشن می‌کنیم، هزینه و Drift را می‌سنجیم و با یک Pilot سی‌روزه به تصمیم KEEP، ADAPT، EXPAND یا EXIT می‌رسیم.

خلاصهٔ تصمیم برای مدیر محصول، توسعه‌دهنده و QA

• BDD را از Cucumber جدا کنید: BDD شیوهٔ کار مشارکتی است؛ Cucumber یک ابزار پشتیبان است.
• از Discovery آغاز کنید: Rule، Example و Question را پیش از Syntax روشن کنید.
• همه‌چیز را Gherkin نکنید: فقط مثال‌های پایدار و ارزشمند برای فهم مشترک و Regression انتخاب شوند.
• زبان دامنه را حفظ کنید: فارسی یا انگلیسی بر اساس گفت‌وگوی واقعی Domain، نه سلیقهٔ ابزار.
• Automation را زیر رفتار پنهان کنید: Stepها دربارهٔ Outcome باشند، نه Click و Selector.
• Living Documentation را اندازه بگیرید: سبز بودن Runner به‌تنهایی Freshness یا حقیقت کسب‌وکار نیست.
• Pilot و Exit داشته باشید: اگر فهم، Feedback یا نگهداشت بهتر نشد، Practice مفید را نگه دارید و ابزار را Retire کنید.

AdoptionClaim: BDD may improve shared understanding for one bounded workflow
PilotScope: synthetic refund rule
AsOf: 2026-08-14
Decision: KEEP | ADAPT | EXPAND | EXIT | INSUFFICIENT
NotClaimed: zero ambiguity, zero defects, automatic ROI, every story in Gherkin

BDD چیست؛ و چه چیزی نیست؟

مستندات رسمی BDD در Cucumber آن را شیوه‌ای برای نزدیک‌کردن افراد کسب‌وکار و فنی با همکاری حول مثال‌های عینی، iterationهای کوچک و مستنداتی می‌داند که با رفتار سیستم سنجیده می‌شوند. همان منبع صریح است که BDD فقط استفاده از Cucumber نیست و سه Practice روزمرهٔ آن Discovery، Formulation و Automation هستند.

BDD جایگزین کل فرآیند Agile، Product discovery، UX research، معماری، تست اکتشافی، امنیت، Performance یا تصمیم Release نیست. مثال اجرایی هم Contract حقوقی یا صدای مستقیم کاربر نیست. BDD می‌تواند فهم مشترک را تقویت کند؛ نتیجه به مسئله، مشارکت، اندازهٔ Slice، کیفیت مثال و Discipline نگهداشت وابسته است.

BDD، Cucumber، Gherkin و Test Automation را تفکیک کنید

مفهوم	نقش	خروجی	ادعایی که نمی‌سازد
BDD	Collaboration و Feedback حول مثال	فهم مشترک و رفتارهای توافق‌شده	موفقیت محصول یا نبود ابهام
Discovery	کشف Rule، Example، Question و Scope	نقشهٔ مثال/سؤال/تصمیم	Requirement نهایی یا تأیید کاربر
Gherkin	Syntax ساختاریافته برای مثال اجرایی	Feature/Rule/Scenario/Step	درستی معنا یا خوانایی
Cucumber	خواندن Specification و اتصال Stepها	Execution result و Report	اتوماسیون کامل یا Oracle درست
Automation layer	فراخوانی Domain/API/UI و Assertion	Evidence از رفتار مشاهده‌شده	حقیقت کسب‌وکار یا Release approval

معرفی رسمی Cucumber می‌گوید ابزار Specificationهای اجرایی متن ساده را می‌خواند، نرم‌افزار را با آن‌ها می‌سنجد و برای Scenarioها گزارش Success/Failure می‌سازد. واژهٔ «متن ساده» به معنی زبان طبیعی بدون Grammar نیست؛ Gherkin Syntax و Step Definition لازم‌اند.

سه Practice رسمی: Discovery، Formulation و Automation

1. Discovery: یک تغییر کوچک آینده را با مثال‌های واقعی بررسی کنید؛ Rule، Unknown و Scope را آشکار کنید.
2. Formulation: مثال منتخب را کوتاه، دقیق، Domainمحور و قابل‌بررسی مستند کنید.
3. Automation: مثال را پیش از Implementation به Check متصل کنید تا رفتار را هدایت و بعداً Regression را آشکار کند.

این سه مرحله Loop هستند، نه Waterfall تازه. اگر Formulation یک سؤال جدید آشکار کرد، به Discovery برگردید. اگر Automation نشان داد رفتار مشاهده‌پذیر نیست، Testability یا Scope را اصلاح کنید. اگر مثال دیگر ارزش ندارد، آن را Retire کنید؛ انباشت Scenario نشانهٔ بلوغ نیست.

چه مسئله‌ای Candidate مناسب BDD است؟

• Rule کسب‌وکار Branch و استثنای معنادار دارد؛
• افراد مختلف واژه یا Outcome را متفاوت می‌فهمند؛
• بازکاری ناشی از ابهام قابل‌مشاهده است؛
• مثال پیش از پیاده‌سازی می‌تواند تصمیم را تغییر دهد؛
• رفتار از Interface پایدار مانند Domain/API قابل‌مشاهده است؛
• یک Domain representative در دسترس و صاحب تأیید معناست؛
• تیم برای نگهداشت Specification و Glue code ظرفیت دارد.

چه زمانی Cucumber انتخاب ضعیفی است؟

اگر مسئله صرفاً الگوریتمی و با Unit test روشن است، UI سریعاً در حال اکتشاف است، Domain representative ندارید، Team فقط می‌خواهد Manual script را به Gherkin تبدیل کند، Step layer معماری را پیچیده‌تر می‌کند یا کسی مسئول Freshness نیست، افزودن Cucumber احتمالاً Cost بیشتری از Signal می‌سازد. Discovery کوتاه همچنان ممکن است مفید باشد؛ ابزار اجباری نیست.

HardGates
ProblemNeedsSharedExamples: true | false | unknown
DomainReviewerAvailable: true | false
ObservableBehaviourBoundary: true | false
MaintenanceOwnerAndCapacity: true | false
SafeSyntheticData: true | false
AnyFalse: do not automate with Cucumber yet

فرضیهٔ پذیرش را ابطال‌پذیر بنویسید

«BDD ارتباط را بهتر می‌کند» سنجش‌پذیر نیست. Population، Workflow، Baseline، Mechanism، Observation window و Counterevidence را ثبت کنید. هدف Pilot اثبات علاقهٔ Sponsor نیست؛ باید امکان EXIT را واقعی نگه دارد.

HypothesisId: BDD-P1
For: refund-rule changes in one squad
Mechanism: pre-code rule/example/question workshop
ExpectedSignal: fewer meaning-reopen events within 30 days
Counterevidence: cycle time rises and reopen does not fall
DecisionOwner: product + engineering + QA representatives
Expiry: 2026-09-14

«Three Amigos» عنوان شغلی یا عدد اجباری نیست

سه Perspective معمولاً Product/Domain، Development و Testing/Quality هستند؛ اما جلسه ممکن است UX، Operations، Security، Legal، Support یا Accessibility را هم نیاز داشته باشد. یک نفر می‌تواند بیش از یک Perspective بیاورد و حضور سه Job title تضمین تنوع دیدگاه نیست. Authority و سؤال موردنیاز تعیین می‌کنند چه کسی شرکت کند.

برای Interface میان QA و Product از راهنمای همکاری تستر و مالک محصول و برای Pair/Review/Handoff با توسعه از راهنمای همکاری تستر و توسعه‌دهنده استفاده کنید.

Discovery را با Question شروع کنید، نه با Feature file

یک Slice کوچک، هدف کاربر، Rule منبع‌دار و مثال‌های موافق/مرزی/مخالف را روی میز بگذارید. Conversation باید Unknown تولید کند؛ نبود سؤال می‌تواند علامت توافق باشد یا سکوت ناشی از Authority. Facilitator باید Dissent، Assumption و تصمیمِ نیازمند Source را قابل‌مشاهده کند.

DiscoveryCard
Outcome: refund eligibility shown correctly
RuleCandidate: fake capture within synthetic window
Example: before boundary → eligible
Counterexample: exactly at boundary → UNKNOWN
Question: whose clock and which timezone?
SourceOwner: fictional policy owner
Decision: HOLD until rule authority answers

Rule، Example، Question و Decision را ردیابی کنید

Example بدون Rule به فهرست Case تبدیل می‌شود؛ Rule بدون Example تفسیرپذیر می‌ماند؛ Question بدون Owner فراموش می‌شود؛ Decision بدون Source به «گفته شد» تبدیل می‌شود. راهنمای Rule، Source و Oracle دامنه مرز Authority و Drift را عمیق‌تر می‌کند.

Artifact	پرسش	Owner	Expiry/Trigger
Rule	چه محدودیتی رفتار را کنترل می‌کند؟	Domain authority	Policy/version change
Example	یک وضعیت عینی چگونه نتیجه می‌دهد؟	Joint authors	Rule or interface change
Question	چه چیزی هنوز معلوم نیست؟	Named resolver	Due date
Decision	چه انتخابی، چرا و با چه Trade-off؟	Authorized decider	Counterevidence
Scenario	کدام مثال ارزش Automation دارد؟	Delivery team	Value/freshness review

Formulation؛ مثال خوب BRIEF است، نه شرح UI

Scenario باید Business language، Rule و Outcome را نشان دهد و از جزئیات اتفاقی دور بماند. «روی دکمهٔ سبز با id=submit کلیک می‌کنم» رفتار دامنه نیست؛ «درخواست بازپرداخت ثبت می‌شود» Outcome است. یک Scenario معمولاً یک Rule برجسته دارد. Context اضافی را حذف کنید؛ اختصار نباید ابهام بسازد.

• نام Scenario نتیجه و تمایز مثال را نشان می‌دهد؛
• Given فقط Context مرتبط را می‌سازد؛
• When یک رویداد مهم را بیان می‌کند؛
• Then Outcome مشاهده‌پذیر و Domainمحور است؛
• مقادیر فقط وقتی معنا را تغییر می‌دهند در متن می‌آیند؛
• Scenario مستقل، قطعی و قابل‌مرور است؛
• Question حل‌نشده با سناریوی جعلی پنهان نمی‌شود.

Gherkin زبان طبیعی آزاد نیست

مرجع رسمی Gherkin Keywordهای Feature، Rule، Scenario/Example، Given، When، Then، And، But، Background، Scenario Outline، Examples، Data Table، Doc String و Tag را تعریف می‌کند. Colon در بعضی Keywordها لازم و در بعضی دیگر نامعتبر است. متن آزاد فقط در جای مشخص پذیرفته می‌شود؛ Structure خوانایی را تضمین نمی‌کند.

# language: fa
ویژگی: تصمیم بازپرداخت مصنوعی
  قانون: مرز زمانی از ساعت ساختگی واحد استفاده می‌کند
    سناریو: درخواست پیش از مرز ساختگی
      با فرض یک خرید کاملاً مصنوعی پیش از مرز
      هنگامی درخواست بازپرداخت ثبت می‌شود
      آنگاه وضعیت ساختگی «واجد بررسی» است

Gherkin فارسی؛ Keyword رسمی را حدس نزنید

فهرست رسمی Localization گرکین برای کد fa Keywordهایی مانند «ویژگی/قابلیت»، «قانون»، «سناریو/مثال»، «با فرض/فرض کنید/با در نظر گرفتن»، «هنگامی/وقتی»، «آنگاه/سپس/انتظار می رود»، «و» و «اما» را نشان می‌دهد. Header زبان باید خط اول Feature file باشد. ترجمهٔ دلخواهِ «فرض کن» ممکن است برای انسان خوانا اما برای Parser تعریف‌نشده باشد.

برای آموزش کامل Syntax و مثال‌های بیشتر، راهنمای نوشتن سناریوی Gherkin فارسی را ببینید. این نوشته روی تصمیم پذیرش تمرکز دارد، نه تکرار مرجع نحوی.

فارسی یا انگلیسی؟ زبان Domain تعیین‌کننده است

مستندات Cucumber توصیه می‌کند زبان Gherkin همان زبانی باشد که کاربر و Domain expert با آن دربارهٔ دامنه صحبت می‌کنند و از ترجمهٔ مداوم پرهیز شود. برای تیم ایرانی، فارسی می‌تواند Review را گسترده‌تر کند؛ اما Keyword support، فونت/IDE، جست‌وجو، گزارش CI، همکار غیر فارسی‌زبان و واژگان فنی باید در PoC سنجیده شوند.

LanguageContract
DomainLanguage: fa
CanonicalTerms: «سفارش»، «تلاش پرداخت»، «بازپرداخت»
Identifiers: stable ASCII ids when tooling requires
Normalization: presentation/search only; source text preserved
BidiRule: isolate LTR ids inside RTL text
Reviewers: domain + automation + accessibility

Scenario Outline؛ فشرده‌سازی مفید یا جدول تست پنهان؟

Scenario Outline برای نمونه‌هایی با ساختار و Rule یکسان مفید است. اگر هر ردیف علت و Outcome متفاوت دارد، جدول بزرگ معنا را پنهان می‌کند. صدها ردیف داده، مسئولیت Gherkin نیست؛ از Test data layer یا تست پارامتری پایین‌تر استفاده کنید و فقط مثال‌های توضیح‌دهندهٔ Rule را در Specification نگه دارید.

Step Definition متن را به رفتار متصل می‌کند؛ جادو نیست

مستندات رسمی Step Definition می‌گوید هر Definition یک Method با Cucumber Expression یا Regular Expression است که به Stepهای Gherkin Match می‌شود. پارامتر می‌تواند تبدیل شود، سپس کد خود تیم رفتار را اجرا می‌کند. Cucumber مفهوم «دکمه»، «حساب» یا «پرداخت» را خودکار نمی‌فهمد و Selenium/Cypress را خودبه‌خود راه نمی‌اندازد.

Step: با فرض سفارش ساختگی با وضعیت {order_status}
ParameterType: order_status → bounded enum
Calls: synthetic domain adapter
DoesNotContain: selector, sleep, credential, real PSP URL
Oracle: domain outcome returned by fake service
Owner: feature team

Keyword Given/When/Then بخشی از Match نیست

در مرجع API، Cucumber Step text را با Definitionها Match می‌کند و Keyword پیشوندی Given/When/Then برای ثبت Match معنای تفکیک‌کننده ندارد. بنابراین دو Step با متن یکسان زیر Given و Then نمی‌توانند دو Definition مبهم را توجیه کنند. عبارت را بر اساس معنای Domain یکتا کنید، نه با Regular Expressionهای بسیار عمومی.

Undefined، Pending، Failed، Skipped و Ambiguous را یکی نگیرید

مرجع رسمی Cucumber وضعیت‌های Success، Undefined، Pending، Failed، Skipped و Ambiguous را جدا می‌کند. Return کردن مقدار False لزوماً Step را Fail نمی‌کند؛ Exception/Assertion قرارداد Runner مهم است. Stepهای بعد از Failure یا Undefined ممکن است Skip شوند؛ پس تعداد سبز/قرمز خام بدون Outcome و Reason code گمراه‌کننده است.

ScenarioVerdict
Status: PASS | FAIL | INCONCLUSIVE
CucumberStatus: success | failed | undefined | pending | skipped | ambiguous
BusinessOutcomeObserved: true | false | unknown
FailureOwner: product-code | step-code | data | environment | unknown
ReleaseInference: forbidden without wider evidence

Step library را API داخلی بدانید

• واژگان محدود و Domainمحور؛
• Expression دقیق، بدون Match مبهم؛
• Parameter type اعتبارسنجی‌شده؛
• Side effect و State پنهان حداقلی؛
• هم‌نامی و duplicate step با Static check؛
• Deprecation، migration و Owner؛
• Usage count فقط Signal، نه دلیل حفظ؛
• Review هم‌زمان Feature و Glue code.

معماری Feature، Step، World/Context، Hook، Tag، Driver، Parallelism و CI در راهنمای معماری پروژه Cucumber با جزئیات پوشش داده شده است.

Scenario state، Hook و Parallelism هزینه دارند

اشتراک State میان Scenarioها ترتیب اجرا و Flake می‌سازد. Hook عمومی که Data، Login و UI را پنهانی می‌سازد، Scenario را ظاهراً کوتاه اما غیرقابل‌تشخیص می‌کند. Fixture باید per-scenario namespace، cleanup هدفمند و Evidence داشته باشد. Parallelism زمانی معتبر است که Account، Order، Port، Queue و Clock مستقل باشند.

Living Documentation خودبه‌خود زنده نمی‌ماند

Runner سبز فقط می‌گوید Implementation با Scenario فعلی سازگار است؛ ممکن است هر دو با Rule کسب‌وکار Drift کرده باشند، Scenario کم‌اهمیت باشد یا Outcome غلط Assert شود. Authority، Dependency، last-reviewed، expiry، change trigger و Correction لازم‌اند. راهنمای Freshness و Drift مستندات تست این قرارداد را کامل می‌کند.

LivingSpecRecord
RuleId: REFUND-FAKE-01
Authority: fictional policy v3
ScenarioIds: RF-01, RF-02
LastReviewed: 2026-08-14
Triggers: policy, API, wording, timezone, currency change
Expiry: 30 days
CorrectionPath: issue + owner + consumer notice

Source of Truth و Authority را جدا کنید

Feature file می‌تواند نمای اجرایی Rule باشد، اما همیشه Authority اصلی نیست. Policy، قرارداد، Regulation، Product decision یا Domain model ممکن است Source باشد. نگه‌داشتن چند نسخهٔ متن در Wiki، Ticket و Feature بدون Dependency map باعث تعارض خاموش می‌شود. Canonical source، derived artifact، Owner و correction propagation را ثبت کنید.

BDD با TDD، ATDD و تست اکتشافی چه نسبتی دارد؟

Practice	سؤال اصلی	سطح رایج	Complement
BDD	چه رفتار ارزشمندی و با چه مثال‌هایی؟	Slice/Domain behavior	Discovery + executable examples
TDD	طراحی واحد/Component چگونه با Feedback کوچک هدایت شود؟	Code/component	Fast lower-level checks
ATDD	پذیرش پیش از ساخت چگونه مشترک شود؟	Acceptance boundary	ممکن است با BDD هم‌پوشانی داشته باشد
Exploratory testing	چه ریسک و رفتار ناشناخته‌ای را می‌توان یاد گرفت؟	System/context	یافته‌ها Discovery آینده را تغذیه می‌کنند

BDD «نسخهٔ تکامل‌یافتهٔ TDD» با جایگزینی زبان برنامه‌نویسی نیست. این Practiceها می‌توانند کنار هم باشند. Gherkin نباید Unit testهای سریع، Contract test، Property-based test یا Exploration را ببلعد.

Automation boundary را پایین‌ترین سطح معتبر انتخاب کنید

Scenario دامنه را می‌توان از Domain service یا API اجرا کرد؛ عبور اجباری همهٔ مثال‌ها از UI زمان، Flake و Diagnosis را بدتر می‌کند. فقط وقتی رفتار واقعاً در UI است یا Risk end-to-end ارزش دارد، Driver مرورگر وارد شود. Tutorial فنی کامل در آموزش BDD، Gherkin و Step Definition موجود است.

AutomationLevelDecision
Behaviour: refund eligibility
PreferredBoundary: domain/API
UIProbe: one critical message and accessibility path
Reason: rule evidence without browser coupling
Countercheck: selected end-to-end scenario
DoNotInfer: full system quality

امنیت، حریم خصوصی و دادهٔ مثال

• Feature file مخزن Password، Token، شماره کارت، موبایل یا دادهٔ مشتری نیست؛
• Examples باید synthetic و از نظر معنا نماینده باشند؛
• Report، Screenshot، Doc String و Data Table طبقه‌بندی و Redact شوند؛
• Test account کم‌اختیار، per-run و منقضی باشد؛
• Hookها Secret را Log نکنند؛
• Scenario روی Production یا سرویس ثالث بدون مجوز اجرا نشود؛
• Artifact retention و حذف Owner داشته باشد.

ریسک‌های ویژهٔ تیم‌های فارسی و ایران

فارسی‌نویسی فقط ترجمهٔ Keyword نیست. ی/ی، ک/ک، ZWNJ، ارقام فارسی/عربی/لاتین، RTL/LTR/Bidi، واژهٔ انگلیسی داخل جمله، Encoding فایل، Font/terminal، Search و Diff را آزمایش کنید. مبلغ Canonical را IRR و نمایش تومان را با برچسب و نسبت ۱:۱۰ نگه دارید. UTC، Asia/Tehran و تقویم جلالیِ نمایشی را جدا کنید.

برای Package registry، SaaS reporting یا Cloud grid، دسترسی، License، Billing، تحریم/منطقه، Support، Export و Continuity را در زمان تصمیم با Owner حقوقی/امنیتی سازمان بررسی کنید. از هویت یا آدرس جعلی، Account قرضی، مخفی‌کردن Location و TLS bypass استفاده نشود. این مقاله توصیهٔ حقوقی نیست.

Toolchain را با PoC همسان انتخاب کنید

Language binding، Runtime، IDE، formatter، parallelism، report، tag filter، plugin health، release cadence، license، vulnerability، hiring/learning، migration و Exit را روی یک Example یکسان بسنجید. راهنمای انتخاب فریم‌ورک اتوماسیون با PoC و TCO کمک می‌کند محبوبیت Cucumber را با Fit تیم اشتباه نگیرید.

PoCScorecard
DiscoveryValue: observed/not_observed
ReadabilityByDomainReviewer: 1..5 + comments
FeedbackTime: measured distribution
DiagnosisTime: measured distribution
MaintenanceMinutesPerChange: measured
AccessSecurityExit: pass/hold
Decision: contextual, no universal winner

چه Metricهایی ارزش دارند؟

• Meaning questionهای کشف‌شده پیش از Code؛
• Reopen به‌علت تفاوت فهم، با taxonomy و denominator؛
• زمان Discovery/Formulation و زمان انتظار برای Authority؛
• درصد Scenarioهایی که Domain reviewer درست توضیح می‌دهد؛
• Feedback latency، Flake و median diagnosis time؛
• Maintenance minute به‌ازای Rule change؛
• Scenario age، last review، expired count و stale finding؛
• Coverage gap و Counterexampleهای جاافتاده؛
• Outcome محصول فقط با طراحی علی مستقل، نه نسبت‌دادن خودکار به BDD.

تعداد Feature، Scenario، Step، Pass rate و جلسه به‌تنهایی Value metric نیستند و برای ارزیابی فرد استفاده نشوند. تیم می‌تواند با تولید Artifact بیشتر، همان سوءتفاهم قبلی را سریع‌تر مستند کند.

آزمایشگاه مصنوعی فارسی؛ بدون Cucumber نصب‌شده

آزمایشگاه SYN-BDD-CUCUMBER-IR-01 فقط فایل و Validator آفلاین دارد؛ Runner، شبکه، Production، حساب، PSP و پول واقعی وجود ندارند. هدف مقایسهٔ «Gherkin-first» با «Discovery-first» برای Rule بازپرداخت ساختگی است، نه اثبات برتری BDD.

LabId: SYN-BDD-CUCUMBER-IR-01
FakeObjects: Order, PaymentAttempt, PSPStub, Callback, RefundDecision
CanonicalAmount: 900000 IRR
DisplayOnly: 90000 تومان (1:10 labelled)
Edges: ۹۰/٩٠/90, ی/ي, ک/ك, ZWNJ, RTL/LTR/Bidi
Time: UTC storage | Asia/Tehran compute | Jalali presentation only
Faults: timeout-before/after-fake-commit, duplicate/late/reordered callback
Network=false; Production=false; RealIdentity=false; RealMoney=false

دو مسیر Pilot را مقایسه کنید

مسیر	شروع	خطر	Observation
Gherkin-first	تبدیل Ticket به Given/When/Then	Syntax theatre و UI script	سؤال/تصمیم تازه تولید شد؟
Discovery-first	Rule/Example/Question پیش از Syntax	جلسهٔ بی‌خروجی یا Scope creep	Unknown زودتر و Slice کوچک‌تر شد؟
No-Cucumber control	مثال ساختاریافته در Artifact ساده	Drift و نبود execution	آیا Tool واقعاً ارزش افزوده دارد؟

Validator مستقل چه چیزی را می‌سنجد؟

Validator بدون Dependency ابتدا یک Checker سطحی را اجرا می‌کند که «معجزه، وضوح ۱۰۰٪، مستندات همیشه تازه، صفر باگ و ROI فوق‌العاده» را پاداش می‌دهد و به‌اشتباه Ready می‌شود. سپس ۸۶۴ کنترل Group-qualified در مسئله، نقش، Discovery، Rule، Example، Question، Formulation، Gherkin، Step، Automation، Living docs، امنیت، ایران، Metric، Pilot و Exit را بررسی می‌کند.

BDD_CUCUMBER_MAGIC_100_PERCENT_CLEAR_NEVER_STALE_ZERO_BUG_ROI_READY
HOLD-864
NO_REAL_ORGANIZATION_PRODUCT_USER_ACCOUNT_CREDENTIAL_PAYMENT_PRODUCTION_RELEASE_OR_ADOPTION_DECISION_PASS
READY_FOR_BDD_CUCUMBER_ADOPTION_REVIEW-0

خروجی نهایی فقط می‌گوید Fixture ساختگی کامل است؛ نه اینکه Shared understanding واقعاً ایجاد شده، Rule درست است، Cucumber fit دارد، Scenario خواناست، Automation معتبر است، Living documentation تازه است، Product موفق می‌شود یا ROI مثبت است.

Pilot سی‌روزهٔ قابل‌برگشت

1. هفتهٔ ۱: Baseline سوءتفاهم/زمان/نگهداشت، Workflow محدود، Rule source و Hard gateها.
2. هفتهٔ ۲: سه Discovery کوچک؛ یک Control بدون Cucumber و یک Formulation منتخب.
3. هفتهٔ ۳: Automation در پایین‌ترین Boundary، CI، Failure taxonomy و Freshness record.
4. هفتهٔ ۴: Review با Domain/Dev/QA، Counterevidence، TCO و تصمیم KEEP/ADAPT/EXPAND/EXIT.

PilotReview
BaselineComparable: yes/no
MeaningReopenDelta: value + denominator + uncertainty
FeedbackAndDiagnosis: distributions, not best run
MaintenanceAndMeetingCost: recorded
DomainReadability: reviewed with comments
SecurityAccessExit: pass/hold
DecisionAndOwner: explicit

Anti-patternهای BDD و Cucumber

• Cucumber را مساوی BDD می‌گیریم؛
• Scenario بعد از Code برای گزارش‌سازی نوشته می‌شود؛
• Product/BA تنها نویسنده و QA تنها Automation owner است؛
• Three Amigos به سه عنوان شغلی ثابت تقلیل می‌یابد؛
• Feature file نسخهٔ خوش‌خط Manual test می‌شود؛
• هر Click و Selector داخل Gherkin می‌آید؛
• یک Scenario چند Rule و Outcome را حمل می‌کند؛
• Background همهٔ State را پنهان می‌کند؛
• Expression عمومی Stepهای مبهم می‌سازد؛
• False return به‌اشتباه Failure فرض می‌شود؛
• سبزی Runner معادل Rule truth و Freshness است؛
• فارسی‌بودن Keyword معادل فهم Domain است؛
• Scenario count و Pass rate معیار فرد می‌شوند؛
• همهٔ تست‌ها از UI می‌گذرند؛
• هیچ Owner، expiry، correction یا Exit وجود ندارد.

چک‌لیست بازبینی Owner

• Problem و Adoption hypothesis محدود و ابطال‌پذیرند؟
• BDD، Gherkin، Cucumber و Automation جدا تعریف شده‌اند؟
• Hard gate و گزینهٔ no-tool وجود دارد؟
• Domain authority و Perspectives لازم حاضرند؟
• Rule، Example، Question و Decision Source/Owner دارند؟
• Scenario پیش از Code و با یک Outcome نوشته شده؟
• زبان Domain و Keywordهای رسمی بررسی شده‌اند؟
• Stepها Domainمحور، یکتا و Parameterها محدودند؟
• Automation boundary پایین و Evidence تشخیصی است؟
• State، Hook، Parallelism و Cleanup کنترل شده‌اند؟
• Status Cucumber از Business verdict جداست؟
• Living spec authority، trigger، review و expiry دارد؟
• Data synthetic و Artifactها Redact/Retain/Delete می‌شوند؟
• Metricها denominator/baseline دارند و people score نیستند؟
• TCO، Counterevidence، EXIT و correction path واقعی‌اند؟

Exit بدون دورریختن یادگیری

اگر Cucumber ارزش کافی نمی‌سازد، Discovery و مثال‌های مفید را حفظ کنید، Authority/Decisionها را Export کنید، Checkهای ارزشمند را به Boundary ساده‌تر منتقل کنید، Step library و pluginها را با Migration map Retire کنید و Report consumerها را خبر دهید. Exit شکست نیست؛ جلوگیری از هزینهٔ بی‌اثر است.

ExitRecord
Reason: insufficient value | maintenance | access | architecture change
Keep: discovery practice + canonical rule/examples
Migrate: valuable checks to domain/API tests
Retire: unused features, steps, plugins, credentials
Verify: CI/report consumers and coverage gaps
CorrectionNotice: owner + date + affected decisions

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

وضعیت این راهنما در ۲۳ مرداد ۱۴۰۵ / ۲۰۲۶-۰۸-۱۴ با شش مقصد رسمی Cucumber بازبینی شده است: Introduction، BDD، Gherkin Reference، Localization، Step Definitions و API/status. صفحات مستندات اصلی در Snapshot پژوهش تا ۲۰۲۶-۰۷-۲۹ به‌روزرسانی شده‌اند. Syntax، implementation، language translation، plugin، license و support پس از این تاریخ ممکن است تغییر کند و باید در زمان استفاده دوباره کنترل شود.

سوالات متداول BDD و Cucumber

آیا BDD همان نوشتن تست با Cucumber است؟

خیر. BDD همکاری مستمر حول مثال‌ها با سه Practice Discovery، Formulation و Automation است. Cucumber فقط ابزار Specification اجرایی است. تیم می‌تواند Discovery مفید بدون Cucumber داشته باشد یا Cucumber داشته باشد اما BDD انجام ندهد.

آیا Gherkin باید برای همهٔ Requirementها نوشته شود؟

نه. مثال‌هایی را Formulate کنید که Rule مهم را روشن می‌کنند، فهم مشترک می‌سازند و Regression value دارند. الگوریتم، جزئیات UI، دادهٔ حجیم و رفتار کم‌ریسک ممکن است در Unit/Component/Exploratory یا Artifact ساده بهتر پوشش داده شوند.

آیا Cucumber مستندات را همیشه تازه نگه می‌دارد؟

خیر. سبزی Runner فقط انطباق Implementation و Scenario فعلی را نشان می‌دهد. Rule source ممکن است تغییر کرده یا Oracle غلط باشد. Authority، dependency، last review، trigger، expiry، drift detection و correction لازم‌اند.

آیا می‌توان Gherkin را کاملاً فارسی نوشت؟

بله؛ Localization رسمی fa وجود دارد و Header زبان باید در خط اول باشد. Keywordهای رسمی را از نسخهٔ جاری بخوانید، Domain language را با Reviewerها انتخاب کنید و Unicode، ZWNJ، Bidi، IDE، Diff و گزارش CI را در PoC بیازمایید.

از کجا بفهمیم BDD/Cucumber ارزش سرمایه‌گذاری دارد؟

با Pilot محدود و Control مقایسه‌ای. Meaning reopen، سؤال پیش از Code، readability نزد Domain reviewer، feedback/diagnosis time، maintenance، meeting cost، security و Exit را با Baseline بسنجید. ROI عمومی یا «۵ مزیت» جای دادهٔ Context خودتان را نمی‌گیرد.

جمع‌بندی؛ Conversation اول، Syntax بعد

ارزش BDD از گفت‌وگوی به‌موقع دربارهٔ مثال‌های عینی می‌آید، نه از تعداد فایل Feature. Cucumber زمانی مفید است که Specification منتخب را به Feedback نگه‌داشتنی وصل کند و هزینهٔ Glue/CI/Drift کمتر از ارزش آن باشد. با یک Rule واقعی اما دادهٔ کاملاً مصنوعی شروع کنید، یک مسیر بدون ابزار را به‌عنوان Control نگه دارید و فقط وقتی Evidence محلی دارید Scope را گسترش دهید.