مستندات تست زنده؛ از Freshness Contract تا Drift Detection

یک سناریوی Gherkin سبز است، صفحهٔ ویکی دیروز ویرایش شده و Test Case در ابزار وضعیت Active دارد؛ آیا این‌ها یعنی مستندات تست زنده هستند؟ نه لزوماً. ممکن است سناریو هنوز به API نسخهٔ ۵ وصل باشد، درحالی‌که Build روی نسخهٔ ۶ است؛ ویکی منبع غیرمرجع یک Rule را کپی کرده باشد؛ و Case روی Build قبلی PASS شده باشد. «آخرین ویرایش» و «آخرین اجرای سبز» با «برای این تصمیم، اکنون معتبر است» برابر نیستند.

این راهنما مستندسازی زنده تست را به‌صورت یک سیستم مهندسی تازگی تعریف می‌کند: Consumer/Decision → Claim → Canonical Authority → Dependency/Version → Change Trigger → Impact → Review/Acknowledgement → Published View → Evidence → Correction. هدف تولید سند بیشتر نیست؛ هدف این است که هر ادعای مصرف‌شده، منبع، مالک، دامنهٔ اعتبار، تاریخ اثر، وابستگی و مسیر اصلاح قابل ردگیری داشته باشد.

پاسخ کوتاه: مستندات تست زنده چیست؟

مستندات تست زنده مجموعه‌ای از Claimها، رابطه‌ها و Viewهای نسخه‌دار است که برای مصرف‌کننده و تصمیم مشخص، Authority و دامنهٔ اعتبار روشن دارد؛ با تغییر منابع وابسته Trigger می‌شود؛ مالک مناسب آن را بازبینی می‌کند؛ و نسخه، Evidence، Acknowledgement و Correction آن حفظ می‌شود. «زنده» یعنی تازگی قابل سنجش و اصلاح‌پذیری، نه اینکه سند حتماً در Wiki، Git، Jira یا Gherkin باشد.

نشانه	چه چیزی نشان می‌دهد؟	چه چیزی را نشان نمی‌دهد؟
ویرایش اخیر	فایل یا صفحه تغییر کرده است	Claimها با Authority فعلی هم‌معنا هستند
تست سبز	Assertionهای اجراشده روی یک Run عبور کرده‌اند	سناریو کامل، منبع درست یا Build جاری است
Active در ابزار	Lifecycle status ثبت شده است	Dependency و Review تازه‌اند
CODEOWNERS	Review تغییر فایل مسیردهی می‌شود	Reviewer صاحب معنای همه Claimهاست
Single Source of Truth	احتمالاً یک مکان مرجع معرفی شده است	همه انواع Claim یک Authority مشترک دارند
لینک به Requirement	یک رابطه وجود دارد	نسخه، معنا و اثر تغییر بررسی شده‌اند

مالکیت این مقاله و مرز با راهنماهای دیگر

این صفحه مالک عملیات تازگی مستندات تست است. آموزش نوع Artifact، BDD، برنامه تست یا اجرای Session در صفحات تخصصی خود می‌ماند تا یک واقعیت در چند مقاله با معناهای متفاوت تکرار نشود.

پرسش	مالک محتوایی	مرز این راهنما
Scenario، Case، Charter یا Script را چگونه انتخاب کنیم؟	سناریوی تست و تست‌کیس	اینجا تازگی Artifact انتخاب‌شده را اداره می‌کنیم.
BDD را با Cucumber چگونه اجرا کنیم؟	آموزش BDD با Cucumber	اینجا Executable View را از Authority و Freshness جدا می‌کنیم.
سناریوی Gherkin خوب چگونه نوشته می‌شود؟	نوشتن سناریو Gherkin	اینجا خود Formulation آموزش داده نمی‌شود.
Living Test Plan چگونه تصمیم‌محور باشد؟	برنامه تست زنده	اینجا همه Test Documentationها، نه فقط Plan، بررسی می‌شوند.
Test Basis و Requirement را چگونه تحلیل کنیم؟	تحلیل نیازمندی‌ها در STLC	اینجا Authority و تغییر Basis را ردیابی می‌کنیم.
Charter/Session چگونه طراحی و گزارش شود؟	تست اکتشافی ساختاریافته	اینجا Freshness خلاصه و Claimهای آموخته‌شده مطرح است.
Run و Result چگونه مدیریت شوند؟	چرخه اجرای تست	اینجا Evidence age و Build alignment مطرح است.
Scrum چه نقشی برای QA دارد؟	نقش QA در Scrum	اینجا فقط ادعاهای مستندسازی درباره Scrum تصحیح می‌شوند.

Agile Manifesto مستندات را حذف نکرده است

Manifesto for Agile Software Development نرم‌افزار کارا را بر مستندات جامع ارزشمندتر می‌داند و همان‌جا تصریح می‌کند عناصر سمت دیگر نیز ارزش دارند. از این متن نمی‌توان نتیجه گرفت «Agile مستند نمی‌خواهد»، «همه اسناد سنگین‌اند» یا «Waterfall همیشه پیشاپیش سند کامل می‌نویسد». مسئله، نسبت ارزش و بازخورد در زمینهٔ واقعی است.

مستند کوتاه ولی غلط هزینه‌زا است؛ مستند مفصل ولی دقیق هم ممکن است برای تصمیم فوری بیش‌ازحد باشد. Tailoring باید Consumer، تصمیم، Risk، طول عمر Claim، هزینهٔ Drift و تعهد Evidence را بسنجد.

Scrum «Test Documentation» رسمی تجویز نمی‌کند

Scrum Guide رسمی نوامبر ۲۰۲۰ Product Backlog، Sprint Backlog و Increment و Commitmentهای Product Goal، Sprint Goal و Definition of Done را تعریف می‌کند. Test Case، Gherkin، Wiki، Test Plan یا نقش مستقل QA را الزام نمی‌کند. تیم می‌تواند Test Documentation متناسب را در شیوهٔ کار و Definition of Done خود بگنجاند، اما نباید انتخاب محلی را به Scrum نسبت دهد.

«زنده» یک وضعیت دودویی نیست

بُعد تازگی	پرسش	نمونه Drift
Syntactic	فرمت قابل خواندن/پردازش است؟	YAML یا Gherkin نامعتبر
Structural	فیلد و رابطهٔ اجباری وجود دارد؟	Owner یا Basis edge مفقود
Semantic	معنا با Authority جاری سازگار است؟	Status قدیمی با نام جدید
Temporal	در Window و تاریخ اثر معتبر است؟	Review-by گذشته یا Rule آینده‌دار
Evidential	Evidence برای Build/Scope جاری است؟	Run سبز Build B16 برای B17
Operational	مصرف‌کننده واقعاً آن را می‌یابد و به‌کار می‌برد؟	لینک بدون دسترسی یا View دفن‌شده
Accessible/localized	نمایش برای مخاطب هدف هم‌معناست؟	RTL، رقم یا واحد مبهم

یک سند می‌تواند از نظر Syntax تازه و از نظر معنا منسوخ باشد. به همین دلیل Badge واحد «Living» بهتر است با وضعیت‌های قابل توضیح جایگزین شود: FRESH_AS_OF، IMPACT_PENDING، STALE، UNKNOWN یا SUPERSEDED.

واحد مدیریت را از Document به Claim تغییر دهید

صفحهٔ «پرداخت» ممکن است ده‌ها Claim با Authority و طول عمر متفاوت داشته باشد: حد مبلغ از Rules Catalog، Schema از API Contract، راه‌اندازی از Environment Manifest و Outcome یک Run از Test Management. تازه‌بودن کل صفحه با یک تاریخ، این تفاوت را پنهان می‌کند. واحد ممیزی باید Claim باشد و Document/View فقط ظرف نمایش آن.

CLAIM: SYN-CLM-RETRY-01
Statement: redelivery of the same authorized event_id creates one canonical effect
Type: expected-behaviour
Authority: CALLBACK-API@v5 + LEDGER-INVARIANT@v2
Scope: fake checkout callback; retry after synthetic commit
Effective: 2026-08-01
Consumer/decision: regression design / B17 release review
Owner: domain-rule-owner
Views: Gherkin SYN-F12; Test Case SYN-TC31; Wiki payment-flow
Status: FRESH_AS_OF 2026-08-13

Claim Registry چه چیزی نگه می‌دارد؟

فیلد	معنا	چرا مهم است؟
claim_id/type	هویت پایدار و گونهٔ ادعا	ردیابی مستقل از محل نمایش
statement/scope	آنچه ادعا می‌شود و مرزش	جلوگیری از تعمیم
authority@version	منبع مجاز معنا	تشخیص کپی قدیمی
consumer/decision	چه کسی برای چه کاری مصرف می‌کند	تعریف تناسب و SLA
owner/reviewer	پاسخ‌گویی معنا و بازبینی	رفع «مالکیت کل تیم» بدون مسئول
effective/facts-as-of	زمان اثر و Snapshot دانش	تفکیک از زمان ویرایش
dependencies	منابع و Claimهای upstream	Change Impact
views/evidence	نمایش‌ها و شواهد مرتبط	یافتن مشتق‌ها و محدودیت
status/review-by	وضعیت تازگی و موعد	صف Drift
correction history	اصلاح‌های منتشرشده	اعتماد و تاریخچه

Single Source of Truth را با Authority Map جایگزین کنید

«یک منبع واحد حقیقت» اگر به معنی یک ابزار برای همه چیز باشد، شکست می‌خورد: Code، Rule، Contract، Test Design، Run Result و Decision صاحبان و چرخه‌های متفاوت دارند. مدل دقیق‌تر این است: برای هر Claim و Scope یک Canonical Authority، و برای مصرف‌کننده‌ها Viewهای مشتق با لینک و نسخه.

Claim type	Authority نمونه	Viewهای مشتق	مالک معنا
Business rule	Rules Catalog/approved decision	AC، Gherkin، Case، Wiki	Domain/Product authority
Interface/schema	Versioned contract/schema	Integration guide، Stub، Contract test	Interface owner
Test design	Versioned Test artifact	Checklist، Suite view، Report link	Test design owner
Environment	Manifest/Infrastructure config	Setup guide، Run context	Environment owner
Execution result	Immutable Run/Attempt	Dashboard، Summary، Release memo	Run/evidence owner
Release decision	Decision record	Status page، announcement	Named decision authority

Canonical، Derived و Evidence را برچسب بزنید

کاربر باید بداند چیزی که می‌خواند منبع معناست، View مشتق است یا Evidence یک رویداد گذشته. کپی بدون برچسب به‌آرامی به Authority رقیب تبدیل می‌شود. Derived View باید source reference، transform/selection، facts-as-of و مسیر گزارش Drift داشته باشد.

VIEW: SYN-WIKI-PAYMENT-v8
Role: DERIVED_VIEW (not canonical authority)
Claims: SYN-CLM-RETRY-01, SYN-CLM-AMOUNT-02
Sources: CALLBACK-API@v5, RULES@v3
Transform: Persian narrative + decision table excerpt
Facts-as-of: 2026-08-13T00:00:00+03:30
Refresh trigger: source release/change event
Owner: docs-curator
Report drift: DOC-OPS queue / template DRIFT-REPORT-v2

Freshness Contract: قرارداد قابل کپی

FRESHNESS-CONTRACT: SYN-FC-01
Claim/View: SYN-WIKI-PAYMENT-v8
Consumers: QA, developer, release reviewer
Decision use: test design and B17 evidence interpretation
Authorities: CALLBACK-API@v5; RULES@v3
Dependencies: schema, status model, currency rule, locale contract
Triggers: semantic/API/config/flag/owner/access change
Impact SLA: triage 1 business day; no universal update SLA
Validation: link/version/semantic/evidence/access review
Reviewers: domain owner + test consumer
Acknowledgement: affected suite owners
Status vocabulary: FRESH / IMPACT_PENDING / STALE / UNKNOWN / SUPERSEDED
Review-by: 2026-09-13
Correction/retention: explicit correction; retain superseded decision snapshot

دو ساعت و یک تاریخ را جدا نگه دارید

زمان	معنا	مثال
last_edited_at	آخرین تغییر فایل/صفحه	اصلاح املا در ۱۳ مرداد
facts_as_of	تا چه Snapshotی Claimها بررسی شده‌اند	API v6 و Rule v3 تا ۱۲ مرداد
effective_from/to	بازه اثر منبع یا Claim	Rule جدید از Build B18
review_by	موعد بازبینی حتی بدون Trigger	۱۴ شهریور
detected_at	زمان کشف Drift	Webhook یا گزارش مصرف‌کننده
corrected_at	زمان انتشار اصلاح	پس از بازبینی Authority

تاریخ جلالی می‌تواند برای نمایش کاربر ایرانی باشد، اما هویت ماشین‌خوان زمان باید Instant و Zone صریح داشته باشد. Last edited تازه، Facts-as-of قدیمی را جبران نمی‌کند.

Dependency Graph قلب Change Impact است

اگر Wiki، Gherkin، Case و Script از یک API Contract مشتق شده‌اند، تغییر نسخه باید همه مصرف‌کننده‌های واقعی را پیدا کند. لینک ساده فقط وجود ارتباط را نشان می‌دهد؛ Edge باید نوع، نسخه، دامنه، وضعیت و rationale داشته باشد.

CALLBACK-API@v5 ─authority-for→ CLAIM-RETRY@v2
CLAIM-RETRY@v2 ─expressed-as→ GHERKIN-F12@v4
CLAIM-RETRY@v2 ─covered-by→ TEST-CASE-31@v7
TEST-CASE-31@v7 ─implemented-by→ SCRIPT-CB-09@sha256:...
SCRIPT-CB-09 ─executed-as→ RUN-R5 / BUILD-B17
CALLBACK-API@v6 ─supersedes→ CALLBACK-API@v5
CHANGE-17 ─impact-pending→ CLAIM-RETRY@v2 and downstream views

Change Triggerها را طبقه‌بندی کنید

نوع تغییر	نمونه	مشتق‌های محتمل	کنترل
Semantic	معنای PAID یا Retry عوض شد	AC، Gherkin، Oracle، Report	بازبینی Claim و Evidence قبلی
Interface/schema	field/enum/version جدید	Stub، Contract test، Setup	Compatibility matrix
Config/flag	Feature flag یا timeout	Scope، Procedure، Run context	Config identity
Data/rule	حد مبلغ یا واحد	Examples، Dataset، Expected	Rule version و boundary review
Environment/dependency	PSP stub، database، certificate	Manifest، Script، Evidence	Environment diff
Operational	Alert/rollback/support flow	Runbook و nonfunctional Scenario	Incident learning link
Policy/compliance	Retention یا access rule	Evidence، archive، redaction	Authorized interpretation
Locale/presentation	IRR/toman، RTL، timezone	UI Cases، fixtures، screenshots	Locale contract

Change Record باید اثر را قابل تصمیم کند

CHANGE: SYN-CHG-17
Source: CALLBACK-API v5 → v6
Effective for: Build B18 candidate
Semantic delta: retry response may be ACCEPTED_PENDING
Detected: 2026-08-13T09:10:00+03:30
Potentially impacted: 2 Claims, 1 Gherkin, 3 Cases, 2 Scripts, 1 Wiki View
Evidence invalidation: B16/B17 runs cannot support B18 status semantics
Owner: callback-domain-owner
Decisions: revise / still-valid / supersede / archive / unknown
Acknowledgement due: suite owners before B18 run scheduling

Impact Assessment را از Update جدا کنید

هر تغییر Source الزاماً متن همه اسناد را عوض نمی‌کند. ابتدا اثر را ارزیابی کنید: NOT_IMPACTED با rationale، STILL_VALID، REVISION_REQUIRED، EVIDENCE_INVALIDATED، SUPERSEDE یا UNKNOWN. سپس Update لازم را منتشر کنید. بستن خودکار Ticket فقط چون متن تغییر نکرده، Review معنایی نیست.

تصمیم اثر	شرط	رکورد لازم
NOT_IMPACTED	Claim خارج Scope تغییر است	Scope comparison + reviewer
STILL_VALID	معنا ثابت و نسخه جدید سازگار است	Compatibility rationale
REVISION_REQUIRED	Statement/View باید عوض شود	نسخه جدید + affected consumers
EVIDENCE_INVALIDATED	Run قبلی برای تصمیم جاری کافی نیست	invalidated evidence + rerun plan
SUPERSEDE/ARCHIVE	Claim یا View دیگر مصرف جاری ندارد	replacement/retention links
UNKNOWN	اطلاعات یا Authority کافی نیست	owner، deadline، safe fallback

Review، Approval، Acknowledgement و Risk Acceptance یکسان نیستند

عمل	معنا	نمونه صاحب اختیار
Viewed	صفحه باز شده؛ فهم یا توافق ثابت نیست	هر مصرف‌کننده
Acknowledged	تغییر و اثر بر کار دریافت شده است	Suite/Script owner
Reviewed	محتوا با معیار مشخص بررسی شده است	Domain/Test reviewer
Approved	انتشار/وضعیت طبق Policy مجاز است	Artifact authority
Risk accepted	Residual risk برای محدوده/زمان پذیرفته شد	Named risk/release authority
Decision recorded	گزینه، دلیل، Evidence و expiry ثبت شد	Decision owner

چرخه عمر Claim و View

Status	معنا	مصرف مجاز
Proposed	Draft بدون Authority review	کشف/بحث؛ نه تصمیم رسمی
Reviewed	Review انجام شده اما هنوز مؤثر نیست	آماده انتشار
Active/Fresh	برای Scope و Facts-as-of مشخص معتبر	تصمیم‌های نام‌برده
Impact Pending	Trigger رسیده و نتیجه نامعلوم است	با هشدار و fallback
Stale	ناسازگاری یا expiry تأیید شده	تاریخی؛ نه تصمیم جاری
Superseded	نسخه جایگزین وجود دارد	Evidence/history
Archived	مصرف عملیاتی پایان یافته	Retention مجاز
Corrected	خطای منتشرشده با Correction روشن شده	نسخه اصلاح‌شده + تاریخچه

Correction را به‌جای بازنویسی تاریخچه منتشر کنید

اگر سندی در تصمیم قبلی مصرف شده، ویرایش خاموش اعتماد و قابلیت بازسازی را از بین می‌برد. Correction باید Claim قبلی، مقدار غلط، مقدار درست، اثر بر تصمیم/Evidence، زمان کشف، مخاطبان مطلع‌شده و نسخه جایگزین را ثبت کند. اصلاح نگارشی کم‌اثر نیز Policy روشن می‌خواهد.

CORRECTION: SYN-COR-08
Affected view/version: SYN-WIKI-PAYMENT-v7
Incorrect claim: callback status TERMINAL after timeout
Correct claim: status may be UNKNOWN pending reconciliation under API-v6
Published/facts-as-of: 2026-08-10 / API-v5
Detected: 2026-08-13
Impact: B18 procedure and release memo require review; B17 history retained
Notified/acknowledged: qa-a yes; release-reviewer pending
Replacement: SYN-WIKI-PAYMENT-v8
Owner: callback-domain-owner

Executable Specification چرا خودکار زنده نمی‌ماند؟

اجرای سبز فقط می‌گوید Step Definitionها و Assertionهای موجود در Run مشخص شکست نخورده‌اند. اگر Example قدیمی، Authority غلط، Assertion ناقص، Tag خارج از CI، Stub منسوخ یا Build نادرست باشد، Gherkin می‌تواند سبز و از نظر معنا مرده باشد. مستند اجرایی باید به Rule/Claim، Automation implementation، Build، Dataset و Result وصل شود.

راهنمای رسمی Cucumber درباره Better Gherkin می‌گوید سناریوی Declarative خوانایی Living Documentation را بهتر می‌کند؛ این راهنمای نگارش، تضمین خودکار تازگی معنایی یا کفایت پوشش نیست. برای Discovery، Formulation و Automation عمیق به راهنماهای مالک BDD مراجعه کنید.

Acceptance Criteria، Test و Documentation چه فرقی دارند؟

Acceptance Criteria مرزهای پذیرش یک Item را روشن می‌کند؛ Test Design روشی برای تولید Evidence درباره Claimهاست؛ Run نتیجهٔ اجرای مشخص است؛ و View مستند به مصرف‌کننده کمک می‌کند معنا را بازیابی کند. AC می‌تواند Basis یک Test باشد، اما فهرست چهار Happy Path الزاماً Coverage یا Evidence نیست. همچنین PASS شدن Test به‌تنهایی AC را Canonical Authority نمی‌کند.

Artifact	سؤال	تازگی وابسته به	نباید جایگزین شود با
Acceptance Criterion	چه شرطی برای پذیرش Item لازم است؟	Product/Rule decision	Test inventory
Test Condition/Case	چه ادعایی چگونه آزموده شود؟	Basis/Oracle/Data/Design	Outcome اجرا
Executable Scenario	چه Example با چه implementation اجرا شود؟	Claim/Steps/Driver/Build	Specification کامل محصول
Run Result	در Attempt چه مشاهده شد؟	Build/Env/Data/Artifact version	Truth دائمی
Wiki/Guide	مصرف‌کننده چگونه معنا/عمل را می‌یابد؟	Authority/transform/access	Canonical همه Claimها

Definition of Done را به تیک‌لیست مبهم «اسناد به‌روز شد» تبدیل نکنید

عبارت «Documentation updated» قابل ممیزی نیست. بهتر است Policy بگوید کدام Change type باید Impact Record داشته باشد، چه Claim/Viewهایی بازبینی شوند، چه Statusهایی مانع Done هستند و چه Exception با Owner/Expiry مجاز است. DoD می‌تواند حداقل سازمانی را نگه دارد؛ جزئیات Artifact در Workflow یا Checkهای خودکار نسخه‌دار باشد.

DOC-FRESHNESS CHECK FOR DONE
[ ] changed authorities and semantic/config/schema deltas declared
[ ] impact query completed for dependent Claims/Views/Tests
[ ] critical IMPACT_PENDING/STALE items resolved or exception approved
[ ] new versions reviewed by meaning owner and test consumer
[ ] affected suite owners acknowledged before scheduling
[ ] correction/retention/access actions recorded
Evidence: change_id + impact_record + revision_ids

Docs-as-Code چه مسئله‌ای را حل می‌کند و چه مسئله‌ای را نه؟

قابلیت	کمک	محدودیت
Version control	Diff، history، branch/tag	معنای Diff را تعیین نمی‌کند
Pull request	Review و بحث ثبت‌شده	Reviewer مناسب را تضمین نمی‌کند
CI	Syntax/link/schema/drift checks	کفایت و صحت معنایی را نمی‌سنجد
Build/publish	Viewهای یکسان و تکرارپذیر	منبع ورودی غلط را درست نمی‌کند
CODEOWNERS	مسیردهی Review فایل	Claim ownership و Risk authority کامل نیست
Immutable tag	Snapshot قابل بازسازی	Truth یا انطباق را ثابت نمی‌کند

طبق مستند رسمی GitHub درباره CODEOWNERS، می‌توان Owner فایل را تعریف و در تنظیمات مربوط Review او را الزامی کرد. این قابلیت به GitHub و تنظیمات Repository محدود است؛ به‌تنهایی نشان نمی‌دهد فرد صاحب معنای Business Rule است، همه الگوها درست match شده‌اند یا Approval معادل Risk acceptance است.

Wiki، Issue Tracker، TMS و Repository را بر اساس Claim تقسیم کنید

سطح	مناسب برای	خطر Drift	کنترل
Issue tracker	Change/decision/AC نزدیک کار	بسته‌شدن و دفن Context	canonical link + snapshot
Wiki/portal	Navigation و Narrative پایدار	کپی چند منبع و orphan page	Authority badge + facts-as-of
Git repository	Versioned schema/spec/code-adjacent docs	Review صرفاً فنی	claim owner + CI + release tag
Test management	Design، Suite، Run و Evidence links	Active status کاذب و export محدود	Basis version + API audit
Generated portal	چند View از structured registry	generator/source defect	build manifest + correction
Chat/message	کشف و هماهنگی سریع	Authority سایه و retention نامعلوم	تصمیم را به registry منتقل کنید

Link Contract برای پیوندهای واقعاً قابل اعتماد

LINK-CONTRACT: SYN-LINK-09
From: SYN-WIKI-PAYMENT-v8 / claim block 2
To: CALLBACK-API@v6 / retry semantics anchor
Relation: derived-from
Resolution: immutable tag or content hash
Access class: internal-engineering
Availability check: daily; semantic review on release
Fallback: approved snapshot SYN-SNAP-API-v6
Retention: through decision/evidence retention window
Owner: docs-platform; meaning reviewer: callback-domain-owner

Drift Detection را لایه‌لایه طراحی کنید

Drift فقط لینک ۴۰۴ نیست. ممکن است لینک باز شود اما Anchor به متن دیگری اشاره کند؛ نسخه resolve شود اما Claim تغییر معنا داده باشد؛ Test سبز باشد اما روی Build دیگری اجرا شده باشد؛ یا سند دقیق باشد اما مخاطب دسترسی نداشته باشد. هر لایه Detector و Reviewer متفاوت می‌خواهد.

لایه	کنترل ماشینی	بازبینی انسانی	خروجی
Syntax/schema	Parser و required fields	آیا Schema مناسب است؟	INVALID/VALID
Resolution	Link، ID، version، hash	آیا مقصد درست انتخاب شده؟	BROKEN/RESOLVED
Graph	orphan، cycle، stale edge	آیا رابطه واقعی و کافی است؟	FINDING/REVIEWED
Semantic	Diff و keyword/enum alerts	معنا و Oracle تغییر کرده؟	IMPACT DECISION
Evidence	Build/env/data alignment	Evidence برای Claim کافی است؟	VALID/INVALID/UNKNOWN
Consumption	access/search/link telemetry	کاربر پاسخ درست پیدا کرد؟	USABLE/FRICTION

اتوماسیون چه چیزهایی را با اطمینان بررسی کند؟

• شناسه و نسخهٔ تکراری یا مفقود؛
• Authority/Dependency غیرقابل resolve یا نسخهٔ منسوخ اعلام‌شده؛
• Owner خالی، غیرفعال یا بدون دسترسی لازم؛
• Review-by منقضی و Impact SLA شکسته؛
• Change بدون Impact record یا Acknowledgement لازم؛
• Run با Build/Environment/Data ناسازگار با Decision scope؛
• View مشتق بدون source، facts-as-of، transform یا Correction path؛
• لینک شکسته، Anchor گمشده، دسترسی نامعتبر و Artifact یتیم؛
• Claimهای Canonical متعدد برای Scope یکسان؛
• دادهٔ ممنوع، Secret pattern یا طبقه‌بندی/retention ناقص.

FRESHNESS CI POLICY
ERROR: invalid schema, duplicate identity, broken immutable reference
HOLD: stale critical authority, missing owner, unreviewed semantic change
WARN: review-by expired, derived view not acknowledged, access degraded
INFO: historical snapshot retained, non-impact rationale recorded
HUMAN: semantic truth, evidence adequacy, risk acceptance, usefulness

Semantic Review چگونه انجام شود؟

پرسش Review	Evidence	Reviewer مناسب
Statement هنوز با Authority هم‌معناست؟	semantic diff + source sections	Domain/contract owner
Scope و Exclusion همان است؟	old/new applicability map	Product/Test analyst
Example هنوز Rule را درست نمایش می‌دهد؟	rule-to-example review	Three Amigos/Domain reviewer
Oracle مستقل و قابل تصمیم است؟	expected source/model	Test/domain specialist
Evidence قبلی برای تصمیم جدید معتبر است؟	Build/env/data/claim alignment	Run owner + decision consumer
View برای مخاطب قابل بازیابی و فهم است؟	retrieval task + access check	Representative consumer

Review صرفاً «Looks good» نیست. نتیجه باید Claimهای بررسی‌شده، اختلاف‌ها، تصمیم اثر، محدودیت، Reviewer، زمان و نسخه را ثبت کند. برای تغییرات پرریسک، Reviewer مستقل یا تفکیک Authority از Implementer می‌تواند لازم باشد؛ این تصمیم زمینه‌ای است.

Orphan، Duplicate و Contradiction را جدا کنید

Finding	تعریف	نمونه	اقدام
Orphan	Node بدون رابطه لازم	Script بدون Claim/Test Design	link، archive یا rationale
Duplicate View	دو نمایش از Claim یکسان	Wiki و Ticket کپی‌شده	canonicalize یا generate
Competing Authority	دو منبع خود را Canonical می‌دانند	Rule در Spreadsheet و API docs	decision owner resolves
Contradiction	دو Claim هم‌دامنه ناسازگارند	Retry مجاز/ممنوع	quarantine decision use
Shadow Authority	Chat/Code رفتار را بی‌تصمیم رسمی عوض کرده	پیام تیمی درباره Status	formalize or reject
Zombie	Active به نظر می‌رسد ولی مصرف/مالک ندارد	Suite قدیمی در TMS	archive with history

ریسک Drift را برای Triage عملیاتی کنید

هر Drift فوریت یکسان ندارد. Triage باید Consumer/Decision، Claim criticality، گستره مشتق‌ها، نزدیک‌بودن زمان مصرف، detectability، reversibility و fallback را ببیند. عدد واحد می‌تواند اولویت را کمک کند، اما جای قضاوت و Hard Obligation را نمی‌گیرد.

کلاس	نمونه	رفتار موقت	Authority
Stop-use	Oracle مالی/ایمنی متناقض	View قرنطینه و تصمیم متوقف	Domain/risk authority
Urgent impact	Schema جدید پیش از Candidate	IMPACT_PENDING با deadline	Change + test owners
Planned correction	راهنمای Setup کم‌اثر	هشدار و fallback معتبر	Artifact owner
Editorial	املا بدون تغییر معنا	Normal review	Docs owner
Unknown	Authority یا Scope نامعلوم	عدم ادعای Fresh؛ escalation	Named resolver

آزمایش بازتولیدپذیر: پنج Run سبز، شش Drift

برای نشان‌دادن تفاوت Availability/Green status با Freshness، Fixture آفلاین و کاملاً ساختگی SYN-LIVE-TEST-DOCS-01 را ساختیم. پنج سند مورد انتظار حاضرند و هر پنج Automated Run وضعیت Passed دارد؛ بنابراین کنترل سطحی PASS می‌دهد.

Document	Claim	ظاهر سالم	Drift پنهان
SYN-D1	Checkout retry	Run B17 passed	CHECKOUT-API@v5 به‌جای v6
SYN-D2	Amount boundary	Authority درست	Review-by در ۲۰۲۶-۰۷-۳۱ منقضی
SYN-D3	Persian RTL receipt	Run passed	Owner تخصصی مفقود
SYN-D4	Callback idempotency	Dependency موجود	Change ۱۷ acknowledged نشده
SYN-D5	Refund status	Gherkin/Run سبز	Gherkin copy Authority نیست و Run روی B16 است

{
  "runtime": "v24.18.0",
  "fixture": "SYN-LIVE-TEST-DOCS-01",
  "auditDate": "2026-08-13",
  "superficialDraft": {
    "requiredDocuments": 5,
    "documentsPresent": 5,
    "automatedChecksPassed": 5,
    "decision": "PASS"
  },
  "draftFreshness": {
    "documentsAudited": 5,
    "findings": [
      "stale-source:SYN-D1:CHECKOUT-API@v5->v6",
      "expired-review:SYN-D2:2026-07-31",
      "missing-owner:SYN-D3",
      "unacknowledged-change:SYN-D4->SYN-CHG-17",
      "noncanonical-authority:SYN-D5:gherkin-copy->status-model",
      "stale-run:SYN-R5:B16->B17"
    ],
    "decision": "HOLD"
  },
  "correctedFreshness": {
    "documentsAudited": 5,
    "findings": [],
    "decision": "READY_FOR_SEMANTIC_REVIEW"
  }
}

چرا Green Build اثبات تازگی نیست؟

• Assertion فقط چیزی را می‌سنجد که نوشته شده، نه Claimهای حذف‌شده را.
• Step/Driver ممکن است به Stub یا Contract قدیمی وصل باشد.
• Scenario ممکن است از Authority غیرمرجع کپی شده باشد.
• Tag یا Profile ممکن است Scenario را از Lane تصمیم خارج کرده باشد.
• Run سبز ممکن است Build، Config، Dataset یا Environment دیگری داشته باشد.
• یک Example سبز Coverage همه Boundaryها، Stateها یا Riskها را ثابت نمی‌کند.
• Report generator می‌تواند Result تازه را کنار Narrative قدیمی نمایش دهد.

بنابراین Freshness Gate باید identity alignment و Authority review را کنار Test Result ببیند. تست سبز Evidence مهمی است، اما نقش آن محدود و صریح است.

نسخه اصلاح‌شدهٔ Fixture چه کرد؟

• SYN-D1 را به CHECKOUT-API@v6 متصل کرد.
• Review-by سند مرزی را پس از Review واقعی تمدید کرد.
• برای رسید RTL مالک تخصصی a11y-owner-e تعیین کرد.
• Change ۱۷ را برای Owner سند Callback acknowledged کرد.
• Authority وضعیت Refund را از Gherkin copy به Status Model منتقل کرد.
• Run جدید SYN-R5-v2 را روی Build B17 ثبت کرد.

خروجی READY_FOR_SEMANTIC_REVIEW عمداً محدود است: فقط قواعد ساختاری Fixture یافته‌ای ندارند. این نتیجه صحت معنایی، کفایت Test، تازگی واقعی سازمان، ارزش مستند، کیفیت محصول، Release readiness، انطباق یا موفقیت Agile را ثابت نمی‌کند.

روش بازتولید آزمایش

اسکریپت به شبکه و کتابخانه وابسته نیست. آرایهٔ سندها و Expectationها را تعریف می‌کند؛ سپس source version، review date، owner، acknowledged change، authority و Run build را مقایسه می‌کند. Runtime، Audit date و Fixture ثابت ثبت شده‌اند. تغییر Audit date می‌تواند نتیجهٔ Expiry را عوض کند و باید بخشی از Evidence باشد.

for each document:
  compare dependency source@version with expected authority version
  compare review_by with declared audit_date
  require effective owner
  require acknowledgement for relevant change_id
  compare claim authority with canonical authority
  align run.build with decision build
decision = findings.empty ? READY_FOR_SEMANTIC_REVIEW : HOLD

همه سندها، Claimها، Buildها، Ownerها، تاریخ‌ها، قواعد و تصمیم‌ها عمداً ساختگی‌اند. آزمایش هیچ Jira، Confluence، GitHub، Cucumber، TestRail، شرکت، تیم یا محصول واقعی را ارزیابی و Benchmark نمی‌کند.

لابراتوار فارسی برای عملیات تازگی مستندات

لابراتوار SYN-DOC-FRESH-FA-01 محلی و بدون شبکه است. دامنهٔ داستانی Checkout با PSP، Ledger و Notification بدل دارد؛ هیچ حساب، مشتری، تراکنش، پول، بانک یا سرویس واقعی استفاده نمی‌شود. هدف فقط آزمون Claim/Authority/Dependency/Change mechanics است.

Fault تزریقی	Detector	Review	Safe response
Rule v3 در Wiki، Rule v4 در Catalog	version mismatch	semantic boundary diff	IMPACT_PENDING
لینک سالم به Anchor اشتباه	anchor/claim ID mismatch	meaning review	Correction
Gherkin سبز روی Build خارجی	Build identity check	evidence applicability	invalidate/rerun
تومان بدون IRR canonical	unit linter	domain rule review	quarantine amount claim
Review-by قدیمی با edit تازه	facts/review clock	actual review	do not auto-extend
Owner حذف‌شده از تیم	directory/access audit	ownership transfer	UNKNOWN until assigned
Correction بدون اطلاع مصرف‌کننده	acknowledgement query	decision impact	notify/escalate

Locale، رقم، پول و زمان بخشی از Authority هستند

ترجمهٔ فارسی صرفاً ظاهر نیست. Claim باید بداند مقدار canonical چیست و View چگونه نمایش می‌دهد. مبلغ canonical در Fixture ریال است؛ اگر تومان نمایش داده شود، تبدیل و برچسب صریح لازم است. رقم‌های فارسی «۱۲۳»، عربی «۱۲۳» و لاتین «۱۲۳» می‌توانند Viewهای یک مقدار باشند، نه سه Authority.

موضوع	Canonical	View	Drift test
Currency	280000 IRR	۲۸۰٬۰۰۰ ریال یا ۲۸٬۰۰۰ تومان صریح	unit/value parity
Digits	numeric/string semantics	Persian/Arabic/Latin glyphs	normalize without identity loss
Time	ISO instant + zone	Asia/Tehran display	instant parity/DST policy
Calendar	canonical event instant/date	Jalali presentation	round-trip and boundary
Direction	semantic token order	RTL with LTR ID/code	DOM/text/export order
Vocabulary	approved domain glossary	Persian label/English term	translation review/version

Evidence و Run Alignment را صریح کنید

EVIDENCE-APPLICABILITY: SYN-EA-14
Decision: B17 release evidence review
Claim: SYN-CLM-RETRY-01@v2
Design/implementation: SYN-TC31@v7 / SCRIPT-CB-09@sha256:...
Run/attempt: SYN-R5-v2 / A1
Build/config/schema: B17 / CFG-4 / CALLBACK-API@v6
Dataset/env: SYN-PAY-v4 / disconnected-lab-v3
Observed/facts-as-of: 2026-08-13T10:20:00+03:30
Limitations: one synthetic fixture; no real PSP/network/concurrency
Applicability decision: REVIEW_REQUIRED, not universal evidence

Run قدیمی لزوماً بی‌ارزش نیست؛ برای تاریخچه یا Regression comparison ممکن است معتبر باشد. اما نباید بی‌هشدار به تصمیم Build جدید تعمیم داده شود. برای ارائه Evidence و Decision Packet، راهنمای ارائه نتایج تست را ببینید.

دسترسی، امنیت و Privacy را با Freshness تلفیق کنید

سند درست اما غیرقابل دسترسی برای Consumer عملیاتی نیست؛ سند بیش‌ازحد عمومی نیز می‌تواند Secret، داده شخصی، معماری حساس یا ضعف امنیتی افشا کند. Availability باید role-based و هدف‌مند باشد. Broken access finding مجوز کپی محتوا به کانال عمومی نیست.

کنترل	پرسش	Failure امن
Classification	Public/Internal/Restricted چیست؟	UNKNOWN→عدم انتشار
Least privilege	چه نقش‌هایی چه Viewی می‌خواهند؟	درخواست دسترسی ثبت‌شده
Secret/PII scan	Fixture یا Evidence داده ممنوع دارد؟	quarantine و redaction review
Access test	Consumer واقعی لینک را باز می‌کند؟	fallback مجاز، نه shadow copy
Retention	Claim/View/Evidence تا چه وقت؟	archive/delete طبق Authority
Revocation	با تغییر نقش/حادثه چه می‌شود؟	invalidate links/tokens and audit

لابراتوار این مقاله نام، موبایل، ایمیل، IP، حساب، سفارش، PAN، CVV2، OTP، Cookie، Token، Secret، Screenshot و Log واقعی ندارد. هیچ توصیه حقوقی، امنیتی، حریم خصوصی، مالی یا بانکی درباره ایران ارائه نمی‌کند.

Archive و Retention را بخشی از سیستم زنده بدانید

Living به معنی حذف گذشته نیست. Decision و Evidence قبلی باید بتوانند نسخهٔ Claim/View مصرف‌شده را resolve کنند. Archive باید immutable reference، replacement، reason، retention class، access و legal/contract owner را نگه دارد. در پایان Window، حذف یا ناشناس‌سازی طبق Policy مجاز انجام می‌شود؛ لینک مرده نباید جای Record حذف را بگیرد.

مورد	Active	Superseded	Archived/Deleted
مصرف جاری	مجاز در Scope	فقط تاریخچه/تصمیم قبلی	خیر
ویرایش	نسخه جدید	Correction/superseding only	طبق retention action
Resolution	canonical URL/ID	immutable snapshot + replacement	tombstone/record مجاز
Evidence link	current decisions	past decisions	retained or explicitly disposed

AI چگونه کمک کند بدون اینکه Authority بسازد؟

AI می‌تواند Diffها را خلاصه، Dependencyهای احتمالی را پیشنهاد، Claimهای متناقض را خوشه‌بندی و Draft Correction تولید کند. خروجی آن Candidate است، نه Authority. مدل نباید Source یا Acknowledgement جعل کند، تاریخ Review را خودکار تمدید کند، Secret/PII را به سرویس تأییدنشده بفرستد یا یافتهٔ زبانی را تغییر معنایی قطعی اعلام کند.

کار AI	ورودی لازم	Review انسانی	Provenance
Semantic diff candidate	old/new immutable sources	Domain owner	model/tool/template/time
Impact candidates	typed dependency graph	Artifact owners	query + graph snapshot
Contradiction clustering	scoped Claims	Authority resolver	included/excluded set
Persian rewrite	canonical glossary/Claim	locale + domain reviewer	source/version
Correction draft	decision/evidence impact	Correction owner	before/after + reviewers

نقش‌ها و حق تصمیم

تصمیم	Responsible	Authority/Approver	مصرف‌کنندهٔ کلیدی
Canonical Authority هر Claim	Knowledge/Test architect	Domain owner	Product/Engineering/QA
ثبت Change و dependency	Change author	Source owner	Artifact owners
Impact assessment	Claim/View owner	Meaning reviewer	Suite/decision owners
Semantic approval	Domain/Test reviewer	Claim authority	Executor/release reviewer
Publish/View operation	Docs platform/curator	Artifact owner	Representative user
Evidence applicability	Run/Test owner	Decision consumer	Release authority
Correction	Correction owner	Claim/decision authority	Affected acknowledged users
Residual risk/exception	Risk analyst	Named risk authority	Product/Operations

«کل تیم مسئول است» یعنی مشارکت مشترک، نه نبود پاسخ‌گویی. توسعه‌دهنده همیشه مالک Unit Test نیست، Product Owner همیشه نویسنده AC نیست و QA همیشه تسهیل‌گر یا مالک E2E نیست؛ تقسیم کار را Context، مهارت و Decision rights تعیین می‌کند.

Metricها و Countermetricهای سلامت مستندات

Metric	کاربرد	Countermetric	بازی احتمالی
Time-to-impact	سرعت یافتن مشتق‌ها	missed impacted claims	بستن سریع بدون بررسی
Stale critical claims	Exposure جاری	claim inventory quality	کم‌کردن برچسب critical
Orphan/competing authority	Graph integrity	false link/merge rate	لینک مصنوعی
Correction latency	سرعت اصلاح انتشار	correction accuracy/recurrence	اصلاح عجولانه
Acknowledgement latency	رسیدن تغییر به مصرف‌کننده	comprehension task	کلیک بی‌مطالعه
Retrieval success/time	کارایی View	wrong-answer rate	جواب سریع ولی غلط
Freshness automation yield	ارزش Detector	false positive/negative	تنظیم برای سبزشدن
Maintenance effort	هزینه سیستم	avoided rework/decision surprise	حذف کنترل لازم

Freshness SLO را محتاطانه و زمینه‌ای تعریف کنید

به‌جای «همه اسناد همیشه به‌روز»، برای کلاس Claim هدف خدمت تعریف کنید: زمان Detection، Triage، Impact decision، Correction و Acknowledgement. SLO تضمین حقیقت نیست و درصد جهانی ندارد. Hard Obligation ممکن است اجازهٔ هیچ مصرفی در حالت Stale ندهد؛ Claim کم‌اثر می‌تواند با هشدار تا Review دوره‌ای بماند.

FRESHNESS-SLO: SYN-SLO-v1 (fictional)
Class A decision-critical: detect on source change; stop-use if unresolved
Class B run-critical: impact before next scheduled run
Class C guidance: warn immediately; triage in team-defined window
Class D editorial: batch review
Unknown authority/access/security: fail closed for decision use
Measure: population + window + exclusions + false-negative sampling
Owner: documentation operations council

Pilot سی‌روزه برای مستندات تست زنده

روز	تمرکز	خروجی	Gate
۱–۵	یک Capability و Consumer task	Claim inventory و Authority Map	Competing authorityها معلوم‌اند
۶–۱۰	Freshness Contract	Dependency/trigger/status/review policy	Owner و Correction path کامل
۱۱–۱۵	سه View موجود	Canonical/derived/evidence labels	facts-as-of و source resolve
۱۶–۲۰	Automation	schema/link/version/owner/run checks	false positives بازبینی شده‌اند
۲۱–۲۵	Change drill	semantic/config/schema fault injection	Impact و Acknowledgement کار می‌کند
۲۶–۳۰	Consumption review	retrieval task، metrics، Tailoring	continue/adjust/stop record

۳۰ Anti-pattern در مستندسازی زنده تست

1. Agile را «بدون مستند» تفسیرکردن.
2. Waterfall را همیشه سند سنگین و ثابت دانستن.
3. آخرین ویرایش را Facts-as-of گرفتن.
4. تست سبز را تازگی معنایی دانستن.
5. Gherkin را Specification کامل محصول نامیدن.
6. یک ابزار را Source of Truth همه Claimها کردن.
7. Canonical و Derived را برچسب‌نزدن.
8. کپی Rule در Wiki و Ticket و Case.
9. لینک بدون Version/Anchor/Relation.
10. Owner فایل را مالک معنای Claim فرض‌کردن.
11. «کل تیم» را به معنی هیچ فرد پاسخ‌گو گرفتن.
12. Approval را Risk acceptance دانستن.
13. View را جای Evidence گذاشتن.
14. Result قدیمی را برای Build جدید تعمیم‌دادن.
15. Status Active را Fresh فرض‌کردن.
16. Review-by را با Edit خودکار تمدیدکردن.
17. Change Ticket را بدون Impact decision بستن.
18. Silence را Acknowledgement دانستن.
19. هر Source change را به ویرایش اجباری تبدیل‌کردن.
20. NOT_IMPACTED را بدون rationale ثبت‌کردن.
21. ویرایش خاموش سند مصرف‌شده.
22. حذف نسخه قدیمی و شکستن Evidence history.
23. لینک شکسته را با Shadow copy حل‌کردن.
24. دسترسی بیشتر را همیشه بهتر دانستن.
25. Secret/PII را در Fixture یا Evidence گذاشتن.
26. ترجمه فارسی را صرفاً ظاهر دانستن.
27. IRR و تومان را بی‌Authority مخلوط‌کردن.
28. AI summary را Canonical Claim کردن.
29. Metric تازگی را با Review صوری سبزکردن.
30. READY_FOR_SEMANTIC_REVIEW را صحت/Release readiness دانستن.

چک‌لیست ۴۸ نقطه‌ای Freshness Audit

1. Consumer نام‌برده شده است.
2. Decision use مشخص است.
3. Claim ID پایدار است.
4. Claim type مشخص است.
5. Statement قابل بررسی است.
6. Scope و Exclusion روشن‌اند.
7. Canonical Authority تعیین شده است.
8. Authority version/hash ثبت شده است.
9. Competing authority حل شده است.
10. Derived View برچسب دارد.
11. Evidence از View جدا است.
12. Owner معنا مشخص است.
13. Owner عملیات View مشخص است.
14. Reviewer متناسب Claim است.
15. facts-as-of ثبت شده است.
16. effective period ثبت شده است.
17. last-edited با facts-as-of یکی نشده است.
18. review-by زمینه‌ای است.
19. Dependencyها شناسه و نسخه دارند.
20. Edgeها type و direction دارند.
21. Change triggerها تعریف شده‌اند.
22. Semantic change قابل اعلام است.
23. Config/flag change قابل اعلام است.
24. Schema/interface change قابل اعلام است.
25. Locale/rule change قابل اعلام است.
26. Impact query مشتق‌ها را می‌یابد.
27. Impact decision واژگان روشن دارد.
28. NOT_IMPACTED rationale دارد.
29. UNKNOWN صاحب و deadline دارد.
30. Evidence invalidation ثبت می‌شود.
31. Acknowledgement از Review جدا است.
32. Approval از Risk acceptance جدا است.
33. Status تازگی صریح است.
34. IMPACT_PENDING در View دیده می‌شود.
35. Stale برای Decision جاری مسدود/هشدار است.
36. Superseded replacement دارد.
37. Correction history حفظ می‌شود.
38. Run به Artifact version وصل است.
39. Run به Build/Env/Data وصل است.
40. Evidence applicability بازبینی می‌شود.
41. لینک version/anchor/fallback دارد.
42. Access با نقش Consumer تست شده است.
43. Classification و retention روشن است.
44. Secret/PII scan و review انجام شده است.
45. RTL/digit/currency/time parity آزموده شده است.
46. Automation محدودیت خود را اعلام می‌کند.
47. Metric Countermetric دارد.
48. Freshness decision و محدودیت ثبت شده‌اند.

منابع رسمی و دامنهٔ استفاده

• Agile Manifesto: برای تصحیح ادعای «Agile بدون مستند»؛ نه دستورالعمل Test Documentation یا معیار تازگی.
• Scrum Guide 2020: برای Artifactها، Commitments و Definition of Done در Scrum؛ نه الزام Test Case، Gherkin، Wiki یا QA role.
• Cucumber Better Gherkin: برای خوانایی Declarative Scenario به‌عنوان Living Documentation؛ نه تضمین Authority، Coverage یا Freshness.
• GitHub CODEOWNERS: برای مالک فایل و مسیردهی/الزام Review در تنظیمات GitHub؛ نه مالکیت معنایی یا صحت Claim.

جمع‌بندی: Living Documentation یک سامانه نگهداری Claim است

مستند تست با قرارگرفتن در Wiki، Git یا Gherkin زنده نمی‌شود. ابتدا Claim و Consumer را مشخص کنید؛ برای هر Claim یک Authority نسخه‌دار بسازید؛ Viewهای مشتق را برچسب بزنید؛ Dependency و Trigger را به Impact decision، Review، Acknowledgement، Evidence و Correction وصل کنید؛ و وضعیت تازگی را با Facts-as-of و محدودیت نمایش دهید.

برای شروع، یک Capability انتخاب کنید و فقط دو Query بسازید: «کدام Claimهای مصرف‌شده به Source قدیمی وصل‌اند؟» و «کدام Change هنوز Impact/Acknowledgement ندارد؟» اگر تیم پاسخ این دو را با Evidence بدهد، از تولید فایل به عملیات دانش قابل اعتماد نزدیک شده است.

سؤالات متداول درباره مستندات تست زنده

۱. آیا مستندات تست زنده همان تست‌های خودکار و Gherkin هستند؟

خیر. Gherkin و Automated Check می‌توانند View و Evidence تولید کنند، اما Freshness به Authority، Version، Scope، Build، Dependency، Review و Consumer وابسته است. Scenario سبز با Rule قدیمی یا Assertion ناقص هنوز می‌تواند منسوخ باشد.

۲. بهترین ابزار برای مستندسازی تست زنده چیست؟

ابزار واحدی برای همه تیم‌ها بهترین نیست. نیازهای Claim registry، Version/History، typed links، Change notification، Review، access، export/API، Run/Evidence و Correction را مشخص کنید و یک Pilot واقعی بسنجید. ابزار نباید Authority Map را با مکان ذخیره اشتباه بگیرد.

۳. چگونه بفهمیم یک سند تست منسوخ است؟

Source/version، semantic delta، review-by، owner، dependency edges، acknowledged changes، Build/Environment/Data Evidence و access را ممیزی کنید. Last edit یا Passed status به‌تنهایی کافی نیست. اگر Authority یا اثر تغییر نامعلوم است، وضعیت را UNKNOWN/IMPACT_PENDING اعلام کنید.

۴. آیا همه مستندات باید با هر تغییر فوراً به‌روزرسانی شوند؟

خیر. هر تغییر باید Trigger و Impact Assessment متناسب داشته باشد، اما نتیجه می‌تواند STILL_VALID یا NOT_IMPACTED با rationale باشد. فوریت Update به Decision، Claim criticality، زمان مصرف، fallback و Hard Obligation بستگی دارد.

۵. چه کسی مسئول به‌روز نگه‌داشتن مستندات تست است؟

مشارکت می‌تواند مشترک باشد، اما هر Claim، Source، View، Change، Evidence و Decision به Owner/Authority مشخص نیاز دارد. QA الزاماً مالک همه اسناد نیست؛ Domain، Product، Development، Operations، Security و Docs platform بسته به نوع Claim مسئولیت‌های متفاوت دارند.