دانش دامنه در تست؛ از Rule تا Oracle

دانستن اینکه «در فروشگاه اینترنتی تخفیف داریم» دانش دامنه کافی برای تست نیست. تستر باید بداند تخفیف روی کدام Offer، برای کدام مشتری، در چه بازه و timezone، با چه ترتیب ترکیب، روی چه مبنای پولی و مالیاتی، با کدام استثنا و تحت اختیار چه منبعی اعمال می‌شود. مهم‌تر اینکه باید بتواند این فهم را به Oracle و Evidence تبدیل کند و وقتی دو منبع اختلاف دارند، حدس خود را به‌جای Rule جا نزند.

این راهنما دانش دامنه در تست نرم‌افزار را از یک صفت مبهم فردی به یک Domain Knowledge Evidence Map تبدیل می‌کند: Context و Boundary → Vocabulary/Concept → Actor/Goal/Workflow → Rule/Example/Exception → Source/Authority → Model/Assumption/Conflict → Test/Oracle/Evidence → Freshness/Drift/Correction. هدف، «تبدیل تستر به خبره صنعت» یا تضمین کشف باگ بحرانی نیست؛ هدف، کاهش خطای معنایی و قابل‌بررسی‌کردن مبنای تست است.

خلاصه عملی: دانش دامنه وقتی به تست کمک می‌کند که قابل ردیابی باشد

• دامنه و مرز context را پیش از جمع‌کردن واژه‌ها مشخص کنید.
• Fact، Rule، Example، Interpretation، Assumption و Heuristic را جدا نگه دارید.
• برای هر گزاره Source، Authority، Scope، Effective date و Owner ثبت کنید.
• هم‌نام‌ها، چندمعناها، ترجمه‌ها و تفاوت Bounded Contextها را آشکار کنید.
• Rule را با ورودی، شرط، خروجی، استثنا، اولویت و سناریوی مرزی بنویسید.
• Rule/Model را به Test Condition، Oracle و Evidence نسخه‌دار وصل کنید.
• اختلاف و Unknown را Hold کنید؛ رأی اکثریت یا مقام سازمانی حقیقت تولید نمی‌کند.
• تغییر محصول، سیاست، قرارداد، منبع یا رفتار عملیاتی باید Drift review ایجاد کند.

دانش دامنه در تست نرم‌افزار چیست؟

دانش دامنه، فهم نسخه‌دار و زمینه‌مند از پدیده‌های مرتبط با سیستم است: واژگان، اشخاص و نقش‌ها، اشیا و روابط، رویدادها و stateها، هدف‌ها و outcomeها، workflowها، قواعد و محاسبات، exceptionها، داده و زمان، محدودیت‌ها، آسیب‌ها و سازوکارهای عملیات. این فهم ممکن است در ذهن افراد، اسناد، مدل‌ها، قراردادها، کد، داده و رفتار واقعی پراکنده و حتی متناقض باشد.

واژه‌نامه رسمی CPRE/IREB Application Domain را بخش‌هایی از دنیای واقعی می‌داند که برای تعیین context سیستم مرتبط‌اند و Domain Model را مدلی از پدیده‌های آن دامنه معرفی می‌کند. دو محدودیت مهم از همین تعریف بیرون می‌آید: «مرتبط‌بودن» به سیستم و تصمیم وابسته است، و Model نمایش انتزاعی با هدف مشخص است؛ نه کپی کامل واقعیت و نه تضمین درستی.

دامنه با صنعت، محصول یا شرکت یکی نیست

«بانکداری»، «سلامت» یا «خرده‌فروشی» بیش از حد وسیع‌اند. برای تست یک قابلیت، دامنه مرتبط شاید «قیمت‌گذاری و تسویه سفارش چندفروشنده در یک بازارگاه»، «زمان‌بندی نوبت» یا «مدیریت حق دسترسی پرونده» باشد. مرز باید مشخص کند چه پدیده‌ای داخل، خارج یا مجاور است و کدام سامانه/تیم فقط dependency محسوب می‌شود.

DomainContextID | Name | Purpose/Decision | System/Product/Version
InScope phenomena | OutOfScope | Neighbor contexts/interfaces
Actors/affected parties | Geography/channel/time horizon
Authority boundaries | Assumptions | Owner | ValidFrom/ReviewDate

دانش دامنه در برابر دانش محصول، فنی و سازمانی

نوع فهم	پرسش نمونه	خطر اختلاط
Domain	«سفارش»، «رزرو» و «لغو» در این context چه معنایی دارند؟	رفتار فعلی محصول به قانون دامنه تبدیل شود
Product	نسخه ۴ این workflow را چگونه پیاده کرده است؟	پیاده‌سازی موجود Oracle نهایی فرض شود
Technical	queue، cache و retry چگونه کار می‌کنند؟	جزئیات زیرساخت به نیاز کسب‌وکار نسبت داده شود
Organizational	چه کسی تصمیم یا پاسخ را در این شرکت مالک است؟	عادت یک تیم، قاعده جهانی صنعت نامیده شود
Regulatory/contractual	کدام متن نافذ چه تعهدی را برای چه موجودیتی ایجاد می‌کند؟	شنیده یا checklist عمومی، نظر حقوقی تلقی شود

این دسته‌ها با هم تعامل دارند، اما مرزشان برای تشخیص منبع و Oracle مهم است. کد می‌تواند شاهد رفتار فعلی باشد؛ از آن نمی‌توان به‌تنهایی فهمید رفتار مطلوب یا مجاز چیست. SME ممکن است فرایند عملی را بداند؛ از گفته او نمی‌توان خودکار نتیجه گرفت متن قرارداد یا قانون همان را الزام کرده است.

دانش دامنه جای مهارت تست را نمی‌گیرد

شناخت Rule بدون توان طراحی Oracle، sampling، boundary، state، concurrency و evidence می‌تواند فقط confidence کاذب بسازد. از طرف دیگر، تکنیک تست بدون معنای دامنه ممکن است روی ورودی‌های کم‌اهمیت عمیق شود. «چه چیزی/چرا» و «چگونه» تفکیک آموزشی مفیدی است، اما در عمل به هم بازخورد می‌دهند: مدل فنی failure ممکن است استثنای دامنه را آشکار کند و مثال دامنه تکنیک مناسب را تغییر دهد.

تستر بدون دانش عمیق دامنه لزوماً ضعیف نیست

تازه‌وارد می‌تواند ابهام‌ها و فرض‌هایی را ببیند که برای افراد قدیمی نامرئی شده‌اند. خبره نیز می‌تواند گرفتار حافظه قدیمی، context متفاوت یا overconfidence شود. کیفیت کار به ترکیب نقش‌ها، دسترسی به منابع، استقلال پرسش، توان مدل‌سازی و سازوکار تصحیح وابسته است؛ نه دوگانه «تستر عادی» و «تستر عالی».

Domain Knowledge Evidence Map چه چیزی را نگه می‌دارد؟

• Vocabulary: Term، تعریف، synonym، homonym، forbidden wording و ترجمه؛
• Concept: Entity/value/object، attribute، identity و رابطه؛
• Actor/Goal: نقش، اختیار، هدف، burden و affected party؛
• Workflow/State: trigger، precondition، transition، invariant و terminal؛
• Rule: calculation، eligibility، permission، obligation، prohibition و policy؛
• Example/Exception: حالت مثبت، منفی، مرزی، نادر و خلاف‌قاعده؛
• Source/Authority: منشأ، اعتبار، قلمرو، تاریخ و مالک؛
• Test Translation: Test Condition، technique، Oracle، fixture و evidence؛
• Lifecycle: freshness، change signal، conflict، correction و retirement.

واژگان مشترک را به‌عنوان Contract بسازید

واژه‌نامه صرفاً «کلمه = ترجمه» نیست. باید مشخص کند اصطلاح در کدام context، از دید کدام actor و با چه مرزی استفاده می‌شود. «مشتری» می‌تواند خریدار، دارنده حساب، سازمان طرف قرارداد یا دریافت‌کننده خدمت باشد. «ثبت‌شده» می‌تواند persist شدن، accepted شدن یا نهایی‌شدن را برساند. یک واژه مشترک با معنای متفاوت از دو واژه متفاوت خطرناک‌تر است.

TermID | PreferredTerm[FA/EN] | ContextID | Definition
Synonyms/Acronyms | Homonyms | Examples/Counterexamples
RelatedTerms | Data/API/UI labels | Source/Authority
Owner | EffectiveFrom/To | Status | Change/Correction log

Ubiquitous Language محلی است، نه یک فرهنگ لغت جهانی

مرجع Domain-Driven Design از Eric Evans خلاصه الگوهای DDD از جمله زبان مدل و مرز context را ارائه می‌کند. از این ایده برای هم‌راستا کردن گفت‌وگو، مدل، test و code در context محدود استفاده کنید؛ نه برای مجبورکردن کل سازمان به یک معنای جهانی. این صفحه رسمی در مرورگر قابل خواندن بود اما درخواست مستقیم curl را با HTTP ۴۰۳ ضدبات پاسخ داد.

در فارسی، ترجمه بخشی از مدل است

«تسویه»، «واریز»، «برداشت»، «پرداخت»، «بازگشت وجه» و «Refund» جایگزین‌های آزاد هم نیستند. متن فارسی UI، اصطلاح انگلیسی API و واژه قراردادی ممکن است سه نمای یک مفهوم یا سه مفهوم مستقل باشند. ی/ی، ک/ک، نیم‌فاصله، رقم فارسی/عربی/لاتین، جمع، پسوند و Bidi روی lookup، validation، sorting و match اثر دارند. شکل canonical و قواعد normalization را صریح کنید.

مفهوم، نمونه و داده را جدا کنید

«سفارش» یک Concept، سفارش شماره X یک Instance و row دیتابیس یک Representation است. حذف row لزوماً مفهوم کسب‌وکاری را حذف نمی‌کند و دو row لزوماً دو سفارش نیستند. برای Entityها identity، lifecycle، ownership، cardinality، واحد، optionality و روابط را مدل کنید. نمونه‌ها برای فهم مدل‌اند؛ مجموعه نمونه‌ها Universe را تعریف نمی‌کند.

Context Diagram و Domain Model را هدف‌دار نگه دارید

IREB تأکید می‌کند Model برای هدفی در context ساخته می‌شود. روی نقشه بنویسید قرار است کدام پرسش تست را پاسخ دهد: مرز داده، actorها، stateها، handoffها یا محاسبه؟ مدل همه‌منظوره خیلی زود به پوستر منقضی تبدیل می‌شود. System boundary، actor خارجی، interface، trust/authority boundary و چیزهای عمداً حذف‌شده را مشخص کنید.

Source Register: هر ادعا از کجا آمده است؟

Source می‌تواند متن قانون/قرارداد، policy مصوب، specification، تصمیم ثبت‌شده، گفت‌وگوی SME، مشاهده workflow، support ticket، incident، telemetry، code یا فرض تیم باشد. این‌ها هم‌ارز نیستند و حتی «منبع رسمی» ممکن است برای entity، تاریخ یا سناریوی شما نافذ نباشد.

SourceID | Type | Issuer/Author | Title/Version/Section
Published/Effective/Accessed dates | Scope/Jurisdiction/Entity
Normative/Informative/Observed/Derived/Assumed | Authority basis
Integrity/location/access | Confidentiality | Owner
Supersedes/SupersededBy | Review trigger | Limitations

Authority با seniority یکی نیست

کارشناس باسابقه ممکن است بهترین شاهد workflow عملی باشد، اما اختیار تغییر Contract، سیاست امنیت یا تعریف مالی را نداشته باشد. Product Owner هم لزوماً مرجع تفسیر قانون نیست. برای هر موضوع Decision Right و Escalation Route تعیین کنید: چه کسی توضیح می‌دهد، چه کسی تأیید می‌کند، چه کسی اختلاف را حل می‌کند و چه کسی فقط consulted است.

مصاحبه با SME را به حافظه‌برداری تبدیل نکنید

به‌جای «فرآیند را توضیح دهید»، یک case مشخص، آخرین استثنا، handoff، ورودی نامعتبر و نتیجه مورد اختلاف را بپرسید. یادداشت باید Fact/Quote، Interpretation و Open Question را جدا کند و برای تأیید معنا به گوینده برگردد. راهنمای گوش‌دادن فعال در QA این Intake تا Confirmation را پوشش می‌دهد.

SMEInputID | PersonRole/Context (minimum necessary identity)
Topic/Prompt | StatedFact | Example | Exception | Interpretation
Confidence/Memory horizon | SupportingSource | Disagreement
SpeakerConfirmedAt | PermittedAudience | Retention | FollowUp

دانش ضمنی را با چند روش استخراج کنید

• مشاهده کار واقعی یا sandbox مجاز با ثبت variation و workaround؛
• Walkthrough یک case از trigger تا outcome و reconciliation؛
• Example mapping: Rule، Example و Question؛
• Event/State mapping برای ترتیب، تأخیر و handoff؛
• بررسی incident، support و correction با مجوز و کمینه‌سازی داده؛
• مقایسه specification، UI، API، data و رفتار مشاهده‌شده؛
• Teach-back توسط تستر و تصحیح توسط صاحب معنا؛
• Counterexample: «چه زمانی این جمله درست نیست؟»

مشاهده یک کاربر یا یک روز، رفتار معمول کل جمعیت را ثابت نمی‌کند. Workaround ممکن است نیاز معتبر، بدهی سیستم یا حتی عمل غیرمجاز باشد. مشاهده را Evidence وضعیت موجود ثبت کنید، نه Rule مطلوب.

Fact، Rule، Example و Assumption را مخلوط نکنید

نوع گزاره	نمونه ساختگی	رفتار تست
Observed fact	در Run-۱۷ callback دوبار رسید	Evidence محدود به Run/نسخه
Normative rule	هر EventID فقط یک اثر ثبت می‌کند	منبع اختیار و Oracle لازم
Example	Callback A، A دوباره، سپس B	یک نمونه، نه تعریف کامل Rule
Interpretation	تکرار احتمالاً ناشی از retry است	نیازمند evidence و alternative
Assumption	ساعت producer و consumer هم‌تراز است	اعتبارسنجی یا محدودیت
Heuristic	ابتدا مرزهای مبلغ را بررسی کن	راهنمای کشف، نه expected result

قواعد کسب‌وکار را دقیق اما قابل‌فهم ثبت کنید

مشخصات OMG SBVR برای صورت‌بندی واژگان و قواعد کسب‌وکار یک مرجع رسمی است؛ استفاده از آن الزامی یا تضمین‌کننده صحت نیست، اما یادآوری می‌کند vocabulary، fact و rule را می‌توان از implementation جدا و دقیق کرد. برای تیم کوچک لازم نیست notation کامل را اجرا کنید؛ contract حداقلی و بدون ابهام بسازید.

RuleID/Version | Context | RuleType | Statement
Inputs[meaning,unit,source] | Preconditions | Decision/Calculation
Output/Action | Invariants | Exceptions | Priority/Conflict rule
Examples/Counterexamples | EffectiveFrom/To | Source/Authority
Owner | TestCondition/Oracle refs | Evidence | Status/Unknowns

نوع Rule را مشخص کنید

• Definition: معنای term یا دسته؛
• Derivation: محاسبه یا نتیجه استنتاج‌شده؛
• Eligibility: شرایط ورود/خروج؛
• Permission/Prohibition/Obligation: چه کاری مجاز، ممنوع یا لازم است؛
• State/Transition: رویداد مجاز و invariant؛
• Validation: شکل و دامنه ورودی قابل قبول؛
• Priority/Conflict: وقتی دو Rule اعمال می‌شوند کدام مقدم است؛
• Operational policy: timeout، retry، limit، queue یا manual review.

نوع Rule منشأ اختیار را تعیین نمی‌کند. یک validation در UI ممکن است صرفاً تصمیم محصول باشد، در حالی که یک prohibition می‌تواند قراردادی یا قانونی باشد. برای تبدیل الزام قانونی/قراردادی به کنترل و تست از راهنمای Obligation تا Evidence استفاده کنید؛ QA نباید بر پایه دانش عمومی یا مقاله وب، Compliance verdict بدهد.

Example بدون Counterexample خطرناک است

اگر SME می‌گوید «سفارش پرداخت‌شده ارسال می‌شود»، بپرسید: لغوشده، بخشی، مشکوک، مرجوعی، موجودی ناقص، split shipment، پرداخت دیررس یا reconciliation نامعلوم چه می‌شود؟ مثال مثبت مسیر اصلی را نشان می‌دهد؛ counterexample مرز معنایی و exception را آشکار می‌کند. هر مثال باید RuleID و داده ساختگی داشته باشد.

قواعد محاسباتی به واحد، precision و زمان نیاز دارند

فرمول بدون تعریف input ناقص است. واحد پول، minor unit، precision، rounding mode و ترتیب rounding؛ timezone، calendar، cut-off و inclusive/exclusive بودن مرز؛ tax/discount base؛ null/unknown؛ version نرخ و زمان اثر را ثبت کنید. در ایران، «۱۰٬۰۰۰ تومان» و «۱۰٬۰۰۰ ریال» یکسان نیستند و تبدیل presentation نباید مقدار ذخیره‌شده را تغییر دهد.

State و Event را با snapshot اشتباه نگیرید

نمایش «پرداخت موفق» ممکن است state UI، نتیجه PSP، وضعیت ledger یا outcome reconciliation باشد. Event زمان و identity دارد؛ State حاصل توالی و قواعد است. transitionهای مجاز/نامجاز، duplicate، late، reordered، missing event، retry و correction را مدل کنید. State machine مفروض را با history واقعی و صاحب دامنه بازبینی کنید.

دانش دامنه را به Risk و Harm وصل کنید

دانستن واژه‌ها خودبه‌خود اولویت تست نمی‌دهد. مشخص کنید failure هر Rule برای کدام actor چه اثر، شدت، احتمال، duration، reversibility و detectability دارد. سپس Risk را به شرط تست و evidence وصل کنید. راهنمای تست مبتنی بر ریسک مالک تحلیل Risk→Test→Residual Evidence است.

از Rule به Test Condition و Oracle برسید

• Definition → classification، synonym/homonym و serialization checks؛
• Eligibility → decision table و partition؛
• Amount/time boundary → Boundary Value Analysis؛
• State/transition → state transition و model-based paths؛
• Calculation → worked examples، property/metamorphic relation و independent calculator؛
• Permission → role/action/resource/context matrix و deny-by-default paths؛
• Workflow → scenario، handoff، concurrency و recovery؛
• Invariant → property check روی sequence و dataset؛
• Exception → negative/rare cases و conflict resolution.

TranslationID | Rule/ModelVersion | Risk/HarmRef | TestCondition
Technique | Partitions/Boundaries/State paths | Fixture/Generator
OracleSource/Algorithm/Version | Expected/Allowed/Forbidden
Coverage/Exclusions | Environment | Evidence | Limitations | Owner

برای تولید مسیر از مدل، adapter و Oracle به راهنمای تست مبتنی بر مدل رجوع کنید. Model coverage با domain coverage یا correctness یکی نیست؛ فقط عناصر تعریف‌شده همان مدل و criterion را می‌سنجد.

Oracle را مستقل و نسخه‌دار کنید

مقایسه خروجی API با UI وقتی هر دو از یک service نتیجه می‌گیرند، Oracle مستقل نیست. بازاجرای همان تابع Production در test هم می‌تواند همان defect را تکرار کند. برای تصمیم‌های مهم از worked example تأییدشده، مدل ساده مستقل، property، reconciliation یا outcome معتبر استفاده کنید و استقلال/وابستگی را صریح بنویسید.

رفتار فعلی محصول Expected Result نیست

Golden master و characterization test تغییر را آشکار می‌کنند، اما مطلوب‌بودن baseline را ثابت نمی‌کنند. اگر Specification و Product اختلاف دارند، یک Finding بسازید: observed behavior، expected-source candidates، affected scope، evidence، owner و disposition. تا حل اختلاف، نتیجه می‌تواند Inconclusive/Blocked باشد؛ نه Pass بر اساس عادت.

اختلاف منبع را پنهان نکنید

Contract، policy، BRD، SME، UI و code ممکن است پاسخ‌های متفاوت بدهند. conflict را با source/version/section، نوع اختلاف، دامنه اثر، گزینه‌های تفسیر و صاحب تصمیم ثبت کنید. newest همیشه authoritative نیست؛ متن جدید ممکن است هنوز effective نشده یا برای entity دیگری باشد. رأی اکثریت و میانگین‌گیری از Ruleها معتبر نیست.

ConflictID | Topic/Context | SourceA/Claim | SourceB/Claim
ConflictType[term,scope,rule,time,authority,implementation]
AffectedTests/Product/Users | Interim handling | DecisionOwner
Decision/Evidence | EffectiveAt | Revalidation | Correction links

Unknown یک خروجی سالم است

اگر نوع rounding، صاحب Rule یا رفتار callback نامعلوم است، آن را Unknown با impact و due date ثبت کنید. سؤال خوب می‌تواند قبل از اجرای صد تست اشتباه، تصمیم طراحی بسازد. Unknown را با default پیاده‌سازی یا چیزی که «در صنعت معمول است» پر نکنید؛ اگر fallback موقت لازم است، authority، exposure، monitoring و expiry داشته باشد.

Requirements منبع مهم‌اند، اما تنها منبع نیستند

صفحه رسمی ISO/IEC/IEEE 29148:2018 فرایندها و اقلام اطلاعاتی Requirements Engineering را در چرخه عمر پوشش می‌دهد و نسخه ۲۰۱۸ را منتشرشده اما در مسیر بازنگری نشان می‌دهد. این استاندارد خود Requirement پروژه شما را تأیید نمی‌کند. Requirement باید از نظر scope، ضرورت، feasibility، consistency، verifiability، traceability و change بررسی شود و با domain evidence تعامل داشته باشد. صفحه در مرورگر قابل‌خواندن بود اما curl مستقیم HTTP ۴۰۳ ضدبات داد.

مقررات را با نام استاندارد حدس نزنید

ذکر GDPR، HIPAA، PCI یا «قوانین بانک مرکزی» بدون تعیین متن، نسخه، قلمرو، موجودیت، نقش، محصول، داده و تاریخ اثر، domain knowledge نیست. Applicability و interpretation کار تخصصی است. QA می‌تواند سؤال و trace بسازد، اما صلاحیت حقوقی/پزشکی/مالی را از دوره عمومی یا تجربه محصول به دست نمی‌آورد. در موضوع پرپیامد، SME واجد صلاحیت و review مستقل لازم است.

رقیب، مرجع حقیقت محصول شما نیست

بررسی عمومی و مجاز محصولات مشابه می‌تواند سؤال یا hypothesis تولید کند؛ نمی‌تواند Rule، permission یا expectation کاربران شما را ثابت کند. شرایط قرارداد، segment، architecture و سیاست رقیب متفاوت است. آزمایش فعال، ساخت حساب، scraping، دورزدن کنترل یا جمع‌آوری داده روی سامانه ثالث به authorization جدا نیاز دارد.

داده و Telemetry می‌گویند چه رخ داده، نه الزاماً چه باید رخ دهد

Log و analytics می‌توانند frequency، sequence و exception دیده‌شده را نشان دهند، مشروط به coverage، sampling، semantics و کیفیت داده. نبود event شاید نبود رفتار، instrumentation ناقص یا loss باشد. رفتار پرتکرار کاربر نیز لزوماً نیاز، رضایت یا رفتار مجاز نیست. هدف و مجوز استفاده از داده، حریم خصوصی و retention را رعایت کنید.

نقشه دانش باید به تصمیم محصول وصل باشد

دانش بدون consumer به دانشنامه متروک تبدیل می‌شود. مشخص کنید هر Rule/Model کدام Backlog item، design review، test plan، support route، release gate یا operating control را تغذیه می‌کند. مرز تعامل QA و Product Owner در Bet تا Decision توضیح داده شده است؛ QA evidence می‌سازد و سؤال را روشن می‌کند، اما اختیار محصول را تصاحب نمی‌کند.

بازبینی طراحی جای خوبی برای کشف شکاف دامنه است

در design review، Quality Claim را به Rule، Model، assumption و failure path وصل کنید. آیا اصطلاح‌های diagram و API با glossary هم‌معنا هستند؟ state حذف‌شده، actor بی‌نماینده یا exception بدون owner داریم؟ راهنمای نقش تستر در بازبینی طراحی ساخت Review Finding و Closure را پوشش می‌دهد.

تازگی دانش دامنه را مهندسی کنید

Rule با تغییر قرارداد، محصول، نرخ، policy، داده، actor، vendor یا عملیات منقضی می‌شود. برای هر item ValidFrom/To، LastVerifiedAt، ReviewCadence و trigger تعریف کنید. dependency graph نشان دهد تغییر Source کدام Rule، Test، Oracle و Report را stale می‌کند. راهنمای مستندات تست زنده مالک Freshness Contract و Drift Detection است.

سیگنال‌های Drift را تعریف کنید

• نسخه یا تاریخ اثر Source تغییر کند؛
• Term/API/UI label یا schema تغییر کند؛
• workflow، state یا actor جدید اضافه شود؛
• incident/support case با Model ناسازگار باشد؛
• SME/Owner/decision right تغییر کند؛
• test مرتباً exception ناشناخته پیدا کند؛
• implementation با Rule مصوب واگرا شود؛
• تفاوت locale، currency، calendar یا channel آشکار شود؛
• permission، contract یا applicability نامعتبر شود.

اصلاح فقط ویرایش Wiki نیست

وقتی Rule غلط یا منقضی شد، اثر گذشته را بررسی کنید: کدام test expected اشتباه داشته، چه defectی بسته شده، چه release claimی صادر شده و آیا data/product correction لازم است؟ نسخه قدیم را برای audit نگه دارید، status و supersession را روشن کنید و مصرف‌کنندگان را مطلع سازید. Silent edit می‌تواند Evidence تاریخی را نامفهوم کند.

آموزش دامنه را با حفظیات نسنجید

تمام‌کردن دوره، تعداد جلسه یا امتیاز quiz نشان نمی‌دهد فرد می‌تواند Rule را در context تازه به Test و Oracle تبدیل کند. یک exercise ساختگی بدهید: واژه مبهم، دو source متناقض، یک استثنا و history نامرتب. خروجی را با traceability، سؤال‌های درست، حفظ Unknown، مدل، test selection و اصلاح پس از feedback بسنجید.

نقشه قابلیت دامنه، رتبه‌بندی شخصیت نیست

به‌جای «دانش دامنه: ۸ از ۱۰»، Capability را به کار قابل مشاهده بشکنید: تعریف اصطلاح در context، ساخت example/counterexample، ردیابی Rule به source، طراحی state model، تشخیص conflict، ساخت Oracle و نگهداری freshness. سطح را برای Assignment و mentoring استفاده کنید، نه ادعای کلی «خبره» یا ابزار ارزیابی استخدامی بدون rubric.

کاهش Bus Factor بدون ساختن Wiki عظیم

• ۱۰ Term و Rule پرریسک Journey را ابتدا ثبت کنید؛
• برای هرکدام owner، backup و consumer تعیین کنید؛
• session را record نکنید مگر با ضرورت، رضایت، دسترسی و retention روشن؛
• teach-back و pair modeling را با نمونه ساختگی اجرا کنید؛
• Domain Decision Log و Conflict queue داشته باشید؛
• Rule-to-Test trace را داخل workflow تغییر قرار دهید؛
• به‌جای copy، یک authoritative record با viewهای سبک بسازید.

آزمایشگاه فارسی کاملاً ساختگی

آزمایش SYN-DOMAIN-MAP-01 یک Checkout آفلاین با Order، Offer، PaymentAttempt، PSP Stub، Callback، Ledger و Reconciliation جعلی است. هیچ شبکه، Production، شرکت، مشتری، کاربر، سفارش، پرداخت، PSP، بانک، حساب، کارت، credential، داده شخصی یا پول واقعی ندارد. هیچ Rule آن بازنمای قانون، قرارداد یا رویه واقعی ایران نیست.

Ruleهای داستانی نسخه ۱.۰ می‌گویند amount ذخیره‌شده IRR است و تومان فقط نمایش برچسب‌دار؛ EventID تکراری نباید اثر جعلی دوم بسازد؛ callback دیرهنگام state را فقط طبق جدول انتقال تغییر می‌دهد؛ Unknown نتیجه معتبر ممیزی است. Fixture رقم فارسی/عربی/لاتین، ی/ی و ک/ک، ZWNJ/RTL-LTR/Bidi، UTC/Asia-Tehran و جلالی صرفاً نمایشی، timeout پیش/پس از fake commit، retry، duplicate، late و reordered event دارد.

Domain Knowledge Record نمونه

KnowledgeItemID/Version | Context/Boundary | Type
Term/Concept/Rule/Model statement | Source(s)/Authority/Scope
Fact vs Interpretation vs Assumption | Examples/Exceptions
Conflict/Unknown | Risk/Harm | TestCondition/Oracle/Evidence refs
Owner/Backup | ValidFrom/To | LastVerified | DriftTrigger
Status[Draft,Confirmed,Disputed,Stale,Retired] | CorrectionLog

Validator ساختگی: Glossary و جلسه SME کافی نیست

برای این مقاله یک validator مستقل از شبکه با Node.js ساخته شد. checker سطحی دید: واژه‌نامه ۱۰۰ اصطلاحی، دو جلسه SME، ۱۲۰ business rule، دوره دامنه و test suite سبز؛ سپس به‌اشتباه DOMAIN_EXPERT_TESTING_READY داد. ممیزی ساختاری دقیقاً ۳۸۹ کنترل یکتا در گروه‌های Identity، Context، Boundary، Vocabulary، Concept، Actor، Workflow، State، Rule، Example، Source، Authority، Elicitation، Assumption، Conflict، Risk، Translation، Oracle، Evidence، Freshness، Correction و Limits پیدا کرد و HOLD-389 داد.

یک قاعده مستقل تأیید کرد هیچ شرکت، خبره، کاربر، سامانه، Rule، قرارداد، قانون یا تصمیم انتشار واقعی در fixture وجود ندارد. پس از pin شدن تمام کنترل‌های fictional، نتیجه فقط READY_FOR_DOMAIN_KNOWLEDGE_EVIDENCE_REVIEW-0 بود؛ نه اثبات خبرگی، صحت Rule، کامل‌بودن دامنه، انطباق، ایمنی، absence of defect، آمادگی Production یا موفقیت کسب‌وکار.

۲۴ ضدالگوی دانش دامنه در تست

• دامنه را با نام کل صنعت تعریف‌کردن؛
• تستر را آخرین سنگر یا تنها مدافع کاربر دانستن؛
• خبره را منبع حقیقت بی‌خطا گرفتن؛
• seniority را با authority یکی‌کردن؛
• رفتار فعلی code را Rule مطلوب نامیدن؛
• BRD قدیمی را بدون version و scope Oracle گرفتن؛
• مثال مثبت را تعریف کامل Rule دانستن؛
• واژه‌نامه بدون context و homonym ساختن؛
• ترجمه آزاد اصطلاح‌های مالی/عملیاتی؛
• مدل را خود واقعیت فرض‌کردن؛
• Rule بدون exception، priority و effective date؛
• Formula بدون واحد، precision، rounding و timezone؛
• Log را دلیل رفتار مطلوب دانستن؛
• رفتار رقیب را expectation محصول خود دانستن؛
• نام استاندارد را Applicability و Compliance تلقی‌کردن؛
• گفته یک کاربر را نیاز کل population نامیدن؛
• اختلاف منبع را با رأی اکثریت بستن؛
• Unknown را default کم‌ریسک تبدیل‌کردن؛
• Test expected را از همان implementation ساختن؛
• تعداد Term/Rule را KPI کیفیت دانستن؛
• Quiz را evidence انتقال یادگیری گرفتن؛
• Wiki بدون consumer و owner ساختن؛
• ویرایش بی‌نسخه Rule و شکستن Evidence تاریخی؛
• دانش دامنه را تضمین کشف باگ، کیفیت یا موفقیت دانستن.

چک‌لیست ۲۶ مرحله‌ای تیم QA

• Decision و DomainContextID مشخص است.
• مرز داخل/خارج و contextهای مجاور ثبت شده‌اند.
• Domain/Product/Technical/Organizational تفکیک شده‌اند.
• Termها تعریف، synonym و homonym دارند.
• ترجمه FA/EN و normalization مشخص است.
• Concept، instance و representation جدا هستند.
• Actor، goal، authority و affected party آمده‌اند.
• Workflow، state، event و handoff مدل شده‌اند.
• Rule type و statement بدون ابهام است.
• input، unit، condition و output تعریف شده‌اند.
• exception، priority و conflict rule آمده‌اند.
• worked example و counterexample وجود دارد.
• Source/version/section قابل بازیابی است.
• Scope، jurisdiction/entity و effective date بررسی شده‌اند.
• Normative/observed/derived/assumed برچسب خورده است.
• Authority و decision right روشن‌اند.
• SME statement از interpretation جداست.
• Speaker confirmation و محدودیت حافظه ثبت شده‌اند.
• conflict و Unknown به owner و موعد وصل‌اند.
• Risk/Harm هر Rule مهم مشخص است.
• Rule به Test Condition و technique وصل است.
• Oracle source/version و استقلالش روشن است.
• coverage/exclusion/limitation ثبت شده‌اند.
• Rule/Model/Test/Evidence نسخه‌های سازگار دارند.
• freshness، dependency و drift trigger تعریف شده‌اند.
• اصلاح، revalidation، اطلاع‌رسانی و retirement مسیر دارند.

پایلوت ۳۰روزه برای یک Journey ساختگی

روز ۱ تا ۵: یک تصمیم، context و boundary برای Checkout fictional تعیین کنید. روز ۶ تا ۱۰: ۱۵ Term/Concept و actorها را با example/counterexample بسازید. روز ۱۱ تا ۱۵: workflow، state و ۱۰ Rule پرریسک را version کنید. روز ۱۶ تا ۲۰: Source/Authorityهای داستانی، دو conflict و سه Unknown طراحی کنید. روز ۲۱ تا ۲۵: Ruleها را به Test Condition، Oracle مستقل و evidence نگاشت کنید. روز ۲۶ تا ۳۰: یک Rule را تغییر دهید و Drift، impact، revalidation و correction را تا انتها اجرا کنید.

معیار پایلوت تعداد صفحه یا اصطلاح نیست. بسنجید آیا فردی خارج از جلسه می‌تواند منشأ expected result را پیدا کند، اختلاف را بدون حدس Hold کند، test را در نسخه صحیح اجرا کند و پس از تغییر Rule همه مصرف‌کنندگان را شناسایی و اصلاح کند.

جمع‌بندی: دانش دامنه یک حافظه شخصی نیست؛ یک زنجیره Evidence است

دانش دامنه زمانی کیفیت تست را بالا می‌برد که boundary، واژگان، مدل، Rule، Source، Authority، exception، conflict و Unknown آن دیده شوند و به Test/Oracle/Evidence نسخه‌دار برسند. مطالعه سند و گفت‌وگو با SME شروع خوبی است، اما بدون تأیید معنا، traceability، استقلال Oracle و freshness می‌تواند خطای قدیمی را رسمی‌تر کند. تیم بالغ نمی‌گوید «ما دامنه را می‌دانیم»؛ نشان می‌دهد کدام گزاره را، برای چه context و زمانی، بر چه مبنایی می‌داند و چگونه آن را تصحیح می‌کند.

سؤالات متداول دانش دامنه در تست نرم‌افزار

دانش دامنه برای تستر دقیقاً شامل چه چیزهایی است؟

به context بستگی دارد، اما معمولاً واژگان و مفاهیم، actor/goal، workflow/state/event، قواعد و محاسبات، exception، داده/زمان/واحد، source/authority، risk/harm و تغییرات را شامل می‌شود. نام صنعت یا فهرست اصطلاح‌ها به‌تنهایی کافی نیست.

آیا تستر باید قبل از شروع کار متخصص کامل صنعت باشد؟

خیر. عمق لازم به ریسک، نقش و تصمیم بستگی دارد. تستر باید شکاف‌ها را آشکار، سؤال درست طرح و از SME/منبع معتبر استفاده کند. در حوزه پرپیامد، نبود تخصص واجد صلاحیت را با اعتمادبه‌نفس یا جست‌وجوی عمومی جایگزین نکنید.

بهترین منبع یادگیری دانش دامنه در پروژه جدید چیست؟

یک منبع جهانی «بهترین» نیست. ترکیبی از sourceهای نافذ، تصمیم‌های نسخه‌دار، SMEهای دارای context، مشاهده مجاز، example/exception، incident/support و رفتار سیستم لازم است. نوع، اعتبار، قلمرو، تاریخ و تعارض هر منبع را ثبت کنید.

وقتی SME و نیازمندی یا رفتار سیستم اختلاف دارند چه کنیم؟

Conflict record بسازید، source و scope هر ادعا را نگه دارید، اثر روی test/release را روشن کنید و به صاحب اختیار درست ارجاع دهید. تا تصمیم معتبر، expected result را حدس نزنید؛ نتیجه مرتبط می‌تواند Blocked یا Inconclusive باشد.

چگونه بفهمیم دانش دامنه واقعاً به تست منتقل شده است؟

با work sample: فرد باید از Rule نسخه‌دار Test Condition و Oracle بسازد، example/counterexample و Unknown را مدیریت کند، evidence را تفسیر و پس از تغییر Source اثرها را اصلاح کند. تعداد جلسه، مدرک دوره یا نمره حفظیات کافی نیست.