نقشه ذهنی در تست نرم‌افزار؛ از Idea تا Evidence

یک نقشه ذهنی با هشت برگ سبز روی صفحه دیده می‌شود. آیا هشت سناریو اجرا شده‌اند؟ آیا پوشش ۱۰۰٪ است؟ آیا همه شاخه‌ها از منبع معتبر آمده‌اند؟ شاید هیچ‌کدام. یک برگ می‌تواند سؤال، ایده، ریسک، Test Condition، مشاهده یا Action باشد؛ رنگ سبز هم ممکن است در ذهن دو نفر معنای متفاوت داشته باشد. نقشه ذهنی در تست نرم‌افزار وقتی مفید است که نقش آن به‌عنوان یک View برای کشف و گفتگو روشن باشد، نه اینکه جای Plan، Registry، Run یا Evidence بنشیند.

این راهنما یک Test Mind Map Contract می‌سازد: Purpose/Audience/Decision → Canonical Sources/Registry → Node و Edge taxonomy → Projection/Filter/Layout → Review/Actions → Export/Round-trip → Accessible text alternative → Archive/Correction. با این قرارداد، نقشه می‌تواند تفکر جمعی را سریع کند، درحالی‌که Claimهای پوشش و نتیجه فقط از شناسه، رابطه و Evidence قابل ردیابی می‌آیند.

پاسخ کوتاه: نقشه ذهنی در تست نرم‌افزار چیست؟

نقشه ذهنی تست یک نمایش شاخه‌ای از موضوع‌ها، سؤال‌ها، ریسک‌ها، شرایط تست، داده‌ها، Oracleها، مسیرهای کاوش، یافته‌ها یا Actionها برای Purpose مشخص است. این View می‌تواند برای Discovery، Planning workshop، Test Design یا Session debrief مفید باشد؛ اما به‌خودی‌خود Test Plan، Test Case، Charter، Coverage model، Run log یا Evidence نیست.

نقش نقشه	کار مناسب	ادعای نامجاز بدون Contract دیگر
Discovery View	نمایان‌کردن سؤال، فرض، مرز و وابستگی	نیازمندی‌ها کامل‌اند
Planning View	گفتگو درباره Scope/Risk/Evidence	خود نقشه Plan مصوب است
Design View	خوشه‌بندی Condition/Scenario/Data/Oracle	هر برگ یک Test Case است
Session View	ثبت مسیر، مشاهده، سؤال و follow-up	Coverage یا Execution اثبات شده است
Communication View	خلاصه بصری برای مخاطب	Source of Truth یا Decision Record است
Generated Projection	نمایش Query از Registry نسخه‌دار	Layout بخشی از معنای canonical است

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

این صفحه مالک مهندسی Mind Map به‌عنوان View نسخه‌دار، قابل تبدیل و قابل دسترس است. موضوع‌های عمیق‌تر در صفحات مالک خود می‌مانند.

پرسش	مالک محتوایی	مرز این راهنما
Charter، Session و Debrief چگونه انجام شوند؟	تست اکتشافی ساختاریافته	اینجا فقط Map View همان Session را مهندسی می‌کنیم.
Living Test Plan چگونه تصمیم‌محور باشد؟	نوشتن برنامه تست زنده	نقشه می‌تواند View Plan باشد، نه جای Contract آن.
Scenario، Case، Charter یا Script را چگونه انتخاب کنیم؟	سناریوی تست و تست‌کیس	نوع Node با نوع Test Artifact یکی نیست.
Chart و Visual QA چگونه طراحی شود؟	بصری‌سازی داده‌های تست	اینجا روابط شاخه‌ای، نه نمودار کمی، مطرح است.
Freshness و Drift سند چگونه اداره شود؟	مستندات تست زنده	اینجا source/version و map projection را اعمال می‌کنیم.
Test Basis و سؤال‌ها چگونه تحلیل شوند؟	تحلیل نیازمندی‌ها در STLC	نقشه ورودی تحلیل را نمایش می‌دهد، نه اینکه کامل‌بودن را ثابت کند.
Test Case و Techniques چگونه نوشته شوند؟	نوشتن تست‌کیس حرفه‌ای	برگ Map فقط با تبدیل/Review می‌تواند Artifact طراحی شود.
Run و Outcome چگونه ثبت شوند؟	چرخه اجرای تست	رنگ یا تیک Map جای Attempt نمی‌گیرد.
نتیجه و Evidence چگونه ارائه شوند؟	ارائه نتایج تست	نقشه می‌تواند Navigation باشد، نه Evidence Packet.

ادعای «تقلید شبکه عصبی مغز» را کنار بگذارید

برای استفاده عملی از نقشه ذهنی نیازی به داستان عصب‌شناختی نداریم. یک Outline شاخه‌ای ممکن است برای بعضی سؤال‌ها، افراد و کارگاه‌ها خواناتر از فهرست باشد و برای مسئله‌ای با روابط چندبه‌چند نامناسب‌تر. اثربخشی را با Task مشخص—مثلاً یافتن Risk بی‌مالک یا تبدیل سؤال‌ها به Action—و با مقایسهٔ خطا، زمان و فهم مخاطب بسنجید.

عبارت‌هایی مثل «خلاقیت را افزایش می‌دهد»، «باگ‌هایی پیدا می‌کند که Script هرگز نمی‌یابد» یا «کیفیت را بالا می‌برد» ادعاهای نتیجه‌ای‌اند و از شکل شعاعی نقشه نتیجه نمی‌شوند. Map ممکن است گفتگو را تسهیل کند یا برعکس، گروه را روی شاخه‌های نخست Anchor کند.

Mind Map، Outline، Concept Map و Graph چه فرقی دارند؟

نمایش	ساختار غالب	مناسب برای	محدودیت
Mind Map	مرکز و شاخه‌های درختی	Ideation، دسته‌بندی، مرور سریع	Parent واحد و روابط مبهم
Outline	سلسله‌مراتب متنی	Keyboard، export، review و alternative text	روابط عرضی کم‌رنگ
Concept Map	Node/Edge با عبارت رابطه	معنا و causal/semantic hypotheses	پیچیدگی و نیاز به Legend
Graph	روابط چندبه‌چند نوع‌دار	Traceability و query	نمای بصری سریعاً شلوغ می‌شود
Table/Matrix	ردیف/ستون و mapping دقیق	مقایسه، Coverage و reconciliation	Discovery آزاد کمتر
Flow/State model	ترتیب، transition و condition	Journey، lifecycle و recovery	برای Brainstorming عمومی مناسب نیست

اگر یک Condition به سه Risk و دو Source وصل است، قرار دادن آن زیر یک Parent ممکن است معنا را تحریف کند یا Duplicate بسازد. راه‌حل این نیست که نقشه را به Source canonical تبدیل کنید؛ Graph/Registry را canonical نگه دارید و Map را Projection آن بسازید.

Map View Contract: قرارداد پایه

TEST-MIND-MAP: SYN-MAP-CHECKOUT-v4
Purpose: discovery of checkout risks and evidence questions
Audience/decision: QA+Product workshop / Plan B17 refinement
Subject/scope: checkout API/UI/Ledger; fake PSP; excludes Production
Canonical sources: FLOW-v3, RULES-v4, API-v6, UI-v4, LEDGER-v2
Registry snapshot/cutoff: SYN-COVERAGE-v2 / 2026-08-13T09:00:00+03:30
Node taxonomy/legend: MAP-NODES-v3 / MAP-LEGEND-v2
Projection: active critical/material items + open questions
Layout/tool/export: radial / tool-neutral / OPML+JSON+SVG+HTML outline
Owner/reviewer/review-by: test-designer-a / domain-b / 2026-09-01
Status: DRAFT_DISCOVERY_VIEW; not Plan, Run, Coverage proof or Decision

Purpose و Audience قبل از مرکز نقشه می‌آیند

مرکز «Checkout» برای همه کارها بیش‌ازحد کلی است. مرکز باید با سؤال View سازگار باشد: «کدام failure mechanismهای retry برای B17 بی‌Evidence‌اند؟» یا «در Session رسید فارسی چه فرض‌ها و سؤال‌هایی داریم؟». مخاطب نیز تعیین می‌کند چه چیزهایی باید دیده یا پنهان شوند؛ نقشه مدیر، اجراکننده و Specialist یک Projection یکسان نمی‌خواهد.

Purpose	مرکز پیشنهادی	Nodeهای اصلی	خروجی
Requirement discovery	Claim/Capability	source، question، assumption، conflict	analysis actions
Risk workshop	Decision/undesired outcome	trigger، mechanism، impact، control	risk register candidates
Test design	Condition/coverage model	data، boundary، oracle، environment	artifact candidates
Exploratory session	Charter mission	tour، observation، question، finding	session notes/follow-ups
Release discussion	Residual risk/decision	evidence، gap، owner، action	decision navigation

Node taxonomy را صریح کنید

Node type	معنا	حداقل attribute	نباید با
Source	منبع versioned	source_id/version/status	View کپی‌شده
Claim/Rule	انتظار قابل ارجاع	claim_id/authority/scope	Observation
Risk	رویداد/پیامد نامطلوب	risk_id/owner/class	Defect
Condition/Coverage item	عضو مدل آزمون	coverage_id/model/source	برگ دلخواه
Question/Assumption	ابهام یا گزاره تأییدنشده	id/owner/status/due	Fact
Idea	Candidate برای بررسی	id/rationale/disposition	Case/commitment
Oracle/Data/Environment	نیاز طراحی یا اجرا	ref/version/owner	Evidence واقعی
Observation/Finding	مشاهده یا مسئله در Session	attempt/time/actor/evidence	Root cause
Action/Decision	کار یا انتخاب مجاز	owner/due/authority/status	رنگ/آیکون

هر Node شناسه و Payload ساختاریافته می‌خواهد

{
  "node_id": "N-RISK-04",
  "type": "risk",
  "label_fa": "اثر تکراری پس از Callback مجدد",
  "ref": "SYN-R4",
  "source": ["API-v6", "LEDGER-v2"],
  "status": "OPEN_FOR_DESIGN",
  "owner": "risk-owner-c",
  "links": [
    { "type": "motivates", "to": "SYN-C3" },
    { "type": "requires-evidence", "to": "EP-INVARIANT-v2" }
  ],
  "presentation": { "color": "orange", "icon": "risk" }
}

Label کوتاه برای View است؛ معنا در Type، Ref، Source و رابطه‌هاست. رنگ و Icon فقط presentation هستند. اگر Tool custom attribute را حفظ نمی‌کند، یک Sidecar JSON/CSV یا Registry بیرونی لازم است.

Edge taxonomy: Parent-child به‌تنهایی کافی نیست

Edge	از	به	معنا
derived-from	Claim/Condition	Source	منشأ، نه اثبات درستی
motivates	Risk	Condition/Idea	دلیل توجه
covers	Test artifact candidate	Coverage item	قصد طراحی، نه Run Evidence
requires	Condition	Data/Env/Oracle	Dependency اجرا/تصمیم
observed-during	Observation	Attempt/Session	provenance مشاهده
supports/contradicts	Evidence	Claim	رابطه محدود Evidence
results-in	Finding/Decision	Action	پیگیری
related-to	هر Node	هر Node	ضعیف؛ فقط با rationale

Cross-linkهای Map ممکن است در Export از بین بروند. برای روابط حیاتی، Registry را canonical کنید و پس از import/export صحت Edgeها را بشمارید.

Legend Contract: رنگ به‌تنهایی معنا نیست

MAP-LEGEND: MAP-LEGEND-v2
Node type: text prefix + icon + machine type
Freshness: FRESH / IMPACT_PENDING / STALE / UNKNOWN / SUPERSEDED
Work status: IDEA / REVIEW / COMMITTED / EXECUTED / EVIDENCE_PRESENT
Outcome: stored only on Attempt reference, not inferred from color
Priority: rationale + class; size/color are secondary cues
Unknown: explicit "? UNKNOWN" label
Color: never sole carrier; contrast and monochrome export reviewed
Language: Persian labels; stable Latin IDs; RTL/LTR behavior tested

یک Map چند نوع Status را مخلوط نکند

Status family	نمونه	مالک	خطای رایج
Idea lifecycle	Captured/Reviewed/Accepted/Rejected	workshop owner	سبز=اجراشده
Artifact lifecycle	Draft/Active/Superseded	artifact owner	Active=Passed
Freshness	Fresh/Stale/Unknown	source/view owner	تازه=درست
Execution outcome	Passed/Failed/Blocked/Inconclusive	Run/Attempt	Outcome روی Condition
Evidence state	Missing/Present/Rejected	evidence reviewer	Present=کافی
Decision/action	Pending/Approved/Done/Expired	decision/action owner	Done=Risk رفع شد

Mind Map در Test Planning: View است، Plan نیست

نقشه می‌تواند در کارگاه برنامه‌ریزی سؤال‌ها، Scope candidates، Riskها، Dependencyها و Evidence ideas را آشکار کند. پس از کارگاه، تصمیم‌ها باید به Plan Contract با Source، owner، date، constraint، exception و approval منتقل شوند. باقی‌ماندن تصمیم فقط به شکل شاخه یا رنگ، Audit و تغییر بعدی را شکننده می‌کند.

Map candidate	تبدیل به Plan	Review لازم
In-scope branch	Scope Item با code/schema/config identity	Product/Plan owner
Out-of-scope branch	reason، residual exposure، owner، revisit trigger	Risk authority
Risk branch	Risk Claim و Risk-to-evidence mapping	Domain/Test reviewer
Dependency branch	deliverable، owner، due، fallback	Dependency owner
Environment idea	versioned manifest/readiness	Environment owner
Open question	Assumption/unknown با validator/due	Meaning owner
Estimate bubble	method/range/assumptions/capacity	Work owners

Scope را با In/Out/Conditional/Unknown مدل کنید

دو رنگ In/Out، Scope مشروط و نامعلوم را حذف می‌کند. هر Scope node باید Subject identity، reason/source، risk owner، dependency و trigger داشته باشد. رنگ یا موقعیت شاخه نمی‌تواند Approval یا Risk acceptance را نشان دهد.

SCOPE-NODE: SYN-SCOPE-07
Subject: callback worker / API-v6 / flag retry_v2=on
State: CONDITIONAL
Condition: fake PSP contract v5 available by 2026-08-14
If true: run fault-recovery profile FP-04
If false: mark affected R2 evidence Not Run; no silent exclusion
Residual exposure: unknown post-commit recovery behavior
Owner/authority: plan-owner-b / release-owner-a
Map label: "△ CONDITIONAL — Callback recovery [SYN-SCOPE-07]"

هر برگ سناریو یا Test Case نیست

Leaf فقط Node بدون فرزند در Layout فعلی است؛ ماهیت تستی ندارد. یک سؤال، Note، Divider، Link یا Idea نیز می‌تواند برگ باشد. برای تبدیل به Scenario/Case/Charter باید Type، Basis، Objective، Coverage link، Oracle/Data/Environment و سطح جزئیات بررسی شود. تعداد برگ‌ها Metric طراحی نیست.

Coverage با شمارش برگ‌ها محاسبه نمی‌شود

Coverage نیازمند مدل و Registry نام‌گذاری‌شده است: Requirement، Risk، State transition، Decision rule، Boundary partition یا Coverage Item دیگر. Map فقط mapping را نمایش می‌دهد. Duplicate node نباید مخرج/صورت را دوبرابر کند و Idea یا Note نباید وارد Population شود.

Claim	صورت	مخرج	محدودیت
Mapped registry coverage	unique eligible IDs with valid map refs	eligible registry IDs	Design یا Run را ثابت نمی‌کند
Designed coverage	items with reviewed design artifacts	in-scope items	Execution/Evidence را ثابت نمی‌کند
Evidence-backed coverage	items with accepted applicable evidence	decision-scope items	کفایت مدل را ثابت نمی‌کند
Session touched	items with session observation	charter population اگر تعریف شده	عمق یا کیفیت کاوش را ثابت نمی‌کند

Coverage Node Contract

COVERAGE-NODE: N-C6
Type: coverage-item
Registry ref: SYN-C6 / COVERAGE-REGISTRY-v2
Source: LEDGER-v2
Eligibility: in Plan B17-v2
Design refs: RECON-CHECK-06@v1
Evidence refs: none
Map status text: DESIGNED / EVIDENCE_MISSING
Presentation: outline icon + amber border (secondary only)
Duplicate policy: one canonical node; aliases link to same ref
Claim: mapped/designed only—not executed or adequate

آزمایش بازتولیدپذیر: هشت برگ سبز، هشت Finding

برای آزمودن خطای «برگ سبز = Coverage»، Fixture کاملاً ساختگی و آفلاین SYN-TEST-MIND-MAP-01 را ساختیم. Registry شش Coverage Item دارد، اما Draft Map هشت برگ سبز نمایش می‌دهد. کنترل بصری فقط رنگ و تعداد برگ را می‌بیند و ۱۰۰٪/PASS اعلام می‌کند؛ Contract audit نوع Node، Ref یکتا، Source، Evidence، Build و text status را بررسی می‌کند.

Leaf	ظاهر	واقعیت ساختاری	Finding
N3 / SYN-C3	سبز و tested	Evidence ندارد	missing-evidence
N5 / SYN-C4	سبز و tested	Evidence متعلق به B16، هدف B17	foreign-build-evidence
N6	سبز	نوع Idea، نه Coverage Item	noncoverage-leaf
N7 / SYN-C99	سبز و tested	Ref در Registry وجود ندارد	unknown-coverage-ref
N8 / SYN-C5	سبز	not-tested و بدون Evidence	missing-evidence + color-status-mismatch
N2/N4 / SYN-C2	دو برگ سبز	Ref تکراری	duplicate-coverage-ref
SYN-C6	در Map دیده نمی‌شود	Registry Item بی‌Map	uncovered-registry-item

{
  "runtime": "v24.18.0",
  "fixture": "SYN-TEST-MIND-MAP-01",
  "expectedBuild": "B17",
  "superficialDraft": {
    "leaves": 8,
    "greenLeaves": 8,
    "visualCoverage": "100%",
    "decision": "PASS"
  },
  "draftContract": {
    "registryItems": 6,
    "uniqueMappedItems": 5,
    "findings": [
      "missing-evidence:SYN-C3",
      "foreign-build-evidence:SYN-C4:B16->B17",
      "noncoverage-leaf:N6:idea",
      "unknown-coverage-ref:N7->SYN-C99",
      "missing-evidence:SYN-C5",
      "color-status-mismatch:SYN-C5:green->not-tested",
      "duplicate-coverage-ref:SYN-C2:2",
      "uncovered-registry-item:SYN-C6"
    ],
    "decision": "HOLD"
  },
  "correctedContract": {
    "registryItems": 6,
    "uniqueMappedItems": 6,
    "findings": [],
    "decision": "READY_FOR_MAP_REVIEW"
  }
}

نسخه اصلاح‌شده چه چیزی را ثابت می‌کند؟

نسخه اصلاحی دقیقاً شش Node از نوع Coverage Item با Refهای یکتا C1 تا C6، Source مورد انتظار، text status و Evidence روی Build B17 دارد. نتیجه READY_FOR_MAP_REVIEW فقط نبود Finding ساختاری در این Fixture است؛ کفایت Coverage، کیفیت Exploration، کشف Defect، کیفیت محصول، انطباق Accessibility یا آمادگی Release را ثابت نمی‌کند.

همه Nodeها، Registry Itemها، Sources، Buildها، Evidenceها، رنگ‌ها، درصدها، قواعد و تصمیم‌ها عمداً ساختگی‌اند. آزمایش هیچ Tool، Map، تیم یا محصول واقعی را ارزیابی یا Benchmark نمی‌کند و هیچ Interaction، Database، UI، Network یا Test execution واقعی ندارد.

نقشه ذهنی در تست اکتشافی

در Session اکتشافی، Map می‌تواند فرض‌ها، تورها، مسیرها، سؤال‌ها و مشاهدات را کم‌اصطکاک ثبت کند؛ اما Charter باید Mission/Scope/Risks/Oracles/Data/Timebox/Evidence را نگه دارد و Session record هویت Build/Environment/Actor/Time را ثبت کند. Map بدون این Context یک تصویر جذاب اما غیرقابل بازسازی است.

قبل، حین و بعد Session را جدا کنید

مرحله	Nodeهای مجاز	خروجی	خطر
قبل	mission، risk، question، model، idea	Charter View	Idea به‌عنوان Observation
حین	path، data، observation، question، interruption	time-linked Session notes	حافظه‌نویسی بعدی
بعد	finding، evidence link، coverage note، action	Debrief View	هر Observation به Bug تبدیل شود
Review	accepted/rejected/unknown decisions	canonical artifacts/actions	نقشه خام Source of Truth شود

Observation، Question، Hypothesis و Finding را جدا کنید

SESSION-NODE: OBS-14
Type: observation
Session/attempt: SYN-SES-RTL-03 / A7
Time/actor: 2026-08-13T10:22:14+03:30 / tester-d
Observed: LTR attempt_id rendered before Persian label in narrow viewport
Expected/oracle: UI-v4 semantic-order rule
Evidence: local sanitized screenshot manifest E14
Interpretation: possible bidi isolation issue
Cause: UNKNOWN
Finding decision: pending specialist review
Map path: Receipt → RTL/LTR → narrow viewport → OBS-14

Map Session Log نیست مگر Provenance داشته باشد

جابجایی Node پس از Session می‌تواند ترتیب رخداد را پاک کند. برای بازسازی، timestamp، actor، attempt، previous parent یا event history را جدا نگه دارید. Snapshot شروع و پایان، Change log و export machine-readable کمک می‌کنند؛ خود Layout زمانی نیست.

Map finding با Bug Report برابر نیست

شاخه «مشکل Callback» برای Handoff کافی نیست. Finding باید Oracle، Build/Config/State/Data، Observation، Attempt و Evidence داشته باشد؛ سپس طبق Workflow به Report/Investigation/Question تبدیل شود. Map فقط Navigation و Context می‌دهد و لینک Canonical Defect را نگه می‌دارد.

ساختارهای کاربردی Map را بر اساس سؤال انتخاب کنید

Map type	Root	شاخه‌های اصلی	Canonical companion
Product/Capability	Capability	actors، flows، states، interfaces	domain/source registry
Risk	Decision/undesired outcome	trigger، mechanism، impact، control	risk register
Coverage	coverage model	partitions/items/status views	coverage registry
Data	entity/population	identity، boundary، state، privacy	data manifest
State/event	subject lifecycle	state، event، transition، recovery	state model/event contract
Dependency	system/decision	service، owner، deliverable، fallback	dependency registry
Session	Charter mission	path، observation، question، finding	session record
Decision	decision question	options، evidence، risk، action	decision record

قرار دادن همهٔ این‌ها در یک نقشه غول‌پیکر معمولاً Navigation را بدتر می‌کند. چند Projection کوچک با ID و Cross-link بهتر از «نقشه همه‌چیز» است.

Projection Pipeline بسازید

Canonical registries / sources
  → query by purpose, scope, status, cutoff
  → typed node/edge dataset
  → map projection and layout
  → collaborative annotations (clearly noncanonical)
  → review/disposition
  → accepted updates to canonical artifacts
  → regenerate map
  → export bundle: machine data + SVG/PNG + accessible outline + manifest

این Pipeline از دو خطا جلوگیری می‌کند: تغییر دستی View که Registry را دور می‌زند، و بازنویسی Source بر اساس Layout. Annotation خام تا زمانی که Review و disposition نشده، Candidate می‌ماند.

Round-trip Contract: Export فقط داشتن فایل نیست

مشخصات OPML ۲.۰ یک Outline را درختی از Nodeها با attributeهای رشته‌ای توصیف می‌کند و برای تبادل Outline طراحی شده است. این دامنه به معنی حفظ همهٔ semantics ابزارهای Mind Map نیست؛ Cross-link، style، attachment، icon، note و custom attribute ممکن است در تبدیل ابزارها تغییر یا حذف شوند. Spec نیز می‌گوید Processorها attribute ناشناخته را نادیده می‌گیرند؛ بنابراین Round-trip باید آزموده شود.

لایه Export	هدف	آزمون
Canonical JSON/CSV/Graph	Type/ID/Edge semantics	schema + exact counts/hash
OPML/Outline	تبادل hierarchy و متن	node IDs/text/order/attrs round-trip
SVG/PNG/PDF	View بصری/انتشار	render/RTL/font/zoom/legend
HTML/text outline	دسترس‌پذیری و search	heading/list/link equivalence
Manifest	provenance	tool/version/source/cutoff/hash

Round-trip Test قابل کپی

ROUND-TRIP: SYN-RT-OPML-04
Source map: SYN-MAP-CHECKOUT-v4 / tool A 6.2
Export: OPML 2.0 + sidecar JSON v3
Import target: tool B 4.1
Expected: 42 nodes; 39 hierarchy edges; 7 cross-links; 42 stable refs
Observed: 42 nodes; 39 hierarchy edges; 0 cross-links; 38 refs preserved
Lost: four custom ref attrs; seven cross-links
Decision: HOLD for canonical interchange; acceptable only as visual outline
Fallback: JSON registry + generated accessible HTML
Owner/correction: docs-engineer-e / MAP-EXPORT-12

دسترس‌پذیری نقشه ذهنی

نقشهٔ شاخه‌ای معمولاً یک تصویر پیچیده است. راهنمای رسمی W3C WAI برای Complex Images توضیح کوتاه برای شناسایی تصویر و توضیح بلندِ معادل اطلاعات ضروری را توصیه می‌کند. این راهنما تضمین WCAG یا درستی محتوای Map نیست؛ فقط مبنای طراحی Alternative قابل مصرف است.

Alt کوتاه، Purpose و دامنهٔ Map را بگوید؛ فهرست همه Nodeها را در Alt نچپانید.
Outline یا جدول بلندِ ساختاریافته و در دسترس کنار View قرار دهید.
نوع، Status و رابطه را با متن/ساختار منتقل کنید؛ Color تنها حامل معنا نباشد.
Zoom، reflow، contrast، فونت فارسی، RTL/LTR و چاپ تک‌رنگ را بررسی کنید.
Interactive nodeها keyboard/focus/name/role/state و مقصد روشن داشته باشند.
Collapse/expand نباید Nodeهای مهم را برای Export یا Screen reader ناپدید کند.
لینک‌های متن جایگزین باید همان مقصد و Action را داشته باشند.

Accessible Map Bundle

ACCESSIBLE-MAP-BUNDLE: SYN-AMB-v2
Short alt: "نقشه ریسک و شواهد Checkout ساختگی برای Plan B17"
Long description: structured HTML outline grouped by typed branches
Exact registry table: node ID/type/ref/status/owner/source/evidence
Interactive parity: every node link available in keyboard-readable list
Color-independent legend: prefix + text status + icon name
RTL/LTR: Persian labels; Latin IDs isolated; logical reading order verified
Exports: SVG, high-resolution PNG, tagged/text PDF if supported, HTML, JSON
Known limits: radial proximity is presentation, not semantic distance

نقشه فارسی: RTL، شناسه و Export

موضوع	Contract	Test
Label	UTF-8 Persian text	render/search/copy/paste
Stable ID	Latin LTR token جدا از Label	visual/logical order
Digits	canonical semantics + display form	Persian/Arabic/Latin normalization
Money	canonical IRR؛ تومان فقط با برچسب/تبدیل	value/unit parity
Time	ISO instant + Asia/Tehran View	cutoff/order/round-trip
Calendar	Jalali presentation-only اگر مقرر	conversion/boundary
Font	embedded/available fallback	SVG/PNG/PDF target systems
Direction	logical outline order مستقل از radial side	keyboard/screen reader/export

همکاری هم‌زمان و Conflict را اداره کنید

ویرایش هم‌زمان می‌تواند Duplicate، overwrite، شاخه بی‌مالک یا ادغام دو معنای متفاوت بسازد. Workshop باید Facilitator، Scribe، Naming/Legend، parking lot و disposition time داشته باشد. پس از جلسه، Snapshot منجمد و Change set بررسی می‌شود؛ آزادبودن Brainstorming به معنی Merge خودکار به Registry نیست.

Conflict	نمونه	Resolution
Duplicate concept	«Callback مجدد» در دو شاخه	یک Ref canonical + aliases
Competing type	یک Node هم Risk هم Finding	split typed nodes + edge
Source conflict	RULES-v3 و v4	Authority/impact review
Status overwrite	Idea سبز روی Run failed	separate status families
Layout conflict	دو Parent پیشنهادی	Graph relation + chosen projection rationale
Deletion	سؤال حل‌نشده حذف می‌شود	reject/archive with disposition

Map Debt و نشانه‌های فروپاشی

مرکز کلی و بیش از یک Purpose؛
شاخه‌های بسیار عمیق یا صدها Node بدون Projection؛
Duplicateهای ناشی از Parent واحد؛
Legendهای محلی و رنگ‌های چندمعنا؛
Node بی‌ID/Source/Owner؛
لینک/attachment شکسته یا بدون دسترسی؛
Map دستی جدا از Registry؛
Cross-linkهای ازدست‌رفته در Export؛
تصویر بدون Outline/long description؛
Session note مخلوط با Fact و Decision؛
View «Active» بدون facts-as-of/review-by؛
نقشه‌ای که هیچ‌کس برای Task واقعی مصرف نمی‌کند.

چه زمانی Mind Map انتخاب بدی است؟

نیاز غالب	View بهتر	چرا
محاسبه Coverage دقیق	Registry + matrix/table	unique IDs و denominator
مدل State/Transition	state diagram/table	guard و transition semantics
Timeline/sequence	sequence/timeline	order و concurrency
Dependency چندبه‌چند	typed graph	Parent واحد تحریف می‌کند
Run accounting	Run/Attempt records	هویت، زمان و Outcome
Quantitative trend	Chart + exact table	scale/denominator/time
Approval/audit	versioned contract/decision record	authority/history
Long procedural steps	Procedure/checklist	ترتیب و repeatability

معیار انتخاب ابزار Mind Map

نام Vendor یا محبوبیت معیار نیست. با یک Fixture واقعی PoC کنید و قابلیت‌هایی را بسنجید که Contract شما لازم دارد.

قابلیت	سؤال PoC	Failure
Stable ID/custom fields	پس از edit/export/import حفظ می‌شود؟	Label-only nodes
Cross-links	type/direction در round-trip می‌ماند؟	tree-only loss
Version/history	Snapshot و correction بازسازی می‌شود؟	latest-only
Collaboration	actor/time/conflict/disposition دارد؟	silent overwrite
API/export	JSON/OPML/SVG/HTML قابل بازسازی است؟	Vendor lock-in
Accessibility	keyboard/zoom/text alternative ممکن است؟	image-only
RTL/Unicode	Persian labels/IDs/exports سالم‌اند؟	reorder/tofu text
Security	access/classification/retention/audit چیست؟	public shadow copy
Performance	Projection بزرگ چطور عمل می‌کند؟	unusable canvas

امنیت، Privacy و Retention

Brainstorming سریع می‌تواند نام واقعی، Endpoint، Token، Screenshot، ضعف امنیتی یا داده مشتری را بی‌محافظ وارد Canvas ابری کند. Data policy، classification، least privilege، sharing/export rule، retention و incident response باید پیش از Workshop روشن باشند. برای داده حساس، محیط و Fixture مجاز یا نقشه آفلاین انتخاب کنید.

اتوماسیون Map QA

MAP QA POLICY
ERROR: duplicate node ID, invalid schema, broken canonical reference
HOLD: unknown coverage ref, missing critical source/owner, foreign-build evidence
WARN: duplicate alias, stale review, color/status mismatch, lost round-trip field
INFO: presentation-only node, archived question, accepted non-impact change
HUMAN: semantic adequacy, map usefulness, exploration quality, risk decision
Never infer: coverage adequacy, product quality, defect absence or release readiness

AI در تولید و نگهداری نقشه

کار	AI می‌تواند	Review لازم	ممنوع
Draft branches	Candidate از Sources مجاز	Domain/Test reviewer	ساخت Source یا Fact
Clustering	گروه‌بندی Nodeها	از دست نرفتن relation/meaning	Parent=causal claim
Deduplication	Similar refs پیشنهاد دهد	identity/semantic check	Merge خودکار
Map-to-outline	توضیح بلند Draft کند	information equivalence	حذف شاخه کم‌دید
Drift scan	source/version candidates	Impact owner	اعلام خودکار Fresh
Coverage suggestion	unmapped items را نشان دهد	Registry/eligibility review	ادعای Coverage کامل

Provenance خروجی AI باید model/tool version، prompt/template، source refs، scope، time و Reviewer را ثبت کند. اطلاعات حساس را به سرویس تأییدنشده نفرستید و Generated map را بدون Review به Artifact canonical تبدیل نکنید.

نقش‌ها و Decision Rights

تصمیم/کار	Responsible	Authority/Reviewer
Purpose/Audience	Map owner/facilitator	Decision consumer
Source/Registry	Analyst/data curator	Domain authority
Node/Edge taxonomy	Test information architect	Artifact owners
Workshop capture	Facilitator/scribe/contributors	Workshop owner
Disposition	Node/action owners	Meaning/decision authority
Coverage claim	Coverage analyst	Test/decision reviewer
Session Evidence	Executor/session owner	Evidence reviewer
Export/accessibility	Docs/platform owner	Representative users
Archive/correction	Map owner	Documentation governance

Metricها و Countermetricها

Metric	کاربرد	Countermetric	بازی احتمالی
Unresolved questions	ابهام قابل اقدام	question quality/age	حذف سؤال
Canonical ref rate	Traceability Nodeها	false/meaningless links	لینک مصنوعی
Duplicate/unknown refs	Map integrity	useful aliases/new discovery	ادغام بیش‌ازحد
Disposition lead time	تبدیل Workshop به Action	decision correctness/rework	بستن عجولانه
Round-trip loss	Portability	semantic importance of fields	کاهش Schema برای سبزشدن
Retrieval task success	Usability	wrong-answer rate	جواب سریع اما غلط
Accessible parity findings	View equivalence	representative-user feedback	Outline صوری
Maintenance effort	هزینه View	decision/rework benefit	حذف کنترل لازم

Pilot سی‌روزه برای Test Mind Map

روز	تمرکز	خروجی	Gate
۱–۵	یک Purpose/Capability	Map Contract و Sources	Audience/decision روشن
۶–۱۰	Taxonomy/Legend	typed nodes/edges/statuses	رنگ تنها معنا نیست
۱۱–۱۵	Workshop/Session	annotations + dispositions	Fact/Idea/Observation جدا
۱۶–۲۰	Registry mapping	projection و duplicate audit	Coverage از Registry می‌آید
۲۱–۲۵	Round-trip/accessibility	OPML/JSON/SVG/HTML bundle	loss/RTL/parity visible
۲۶–۳۰	Consumption/maintenance	tasks/metrics/Tailoring	continue/adjust/stop record

۳۰ Anti-pattern در نقشه ذهنی تست

توجیه Map با تقلید شبکه عصبی مغز.
آن را ابزار ایده‌آل جهانی دانستن.
افزایش خلاقیت/کیفیت را قطعی دانستن.
هر برگ را Scenario دانستن.
برگ سبز را Test اجراشده دانستن.
شمارش برگ را Coverage نامیدن.
Mind Map را Test Plan گرفتن.
Map را Charter یا Session Log کامل دانستن.
Map finding را Bug Report دانستن.
Parent-child را رابطه معنایی کافی گرفتن.
Duplicate را دو Coverage Item شمردن.
Idea/Question را وارد Coverage کردن.
Source/Version را حذف‌کردن.
Node بی‌ID و Owner ساختن.
نوع Node را فقط با Icon نشان‌دادن.
Status را فقط با رنگ نشان‌دادن.
سبز را هم Active، هم Passed، هم Fresh معناکردن.
Unknown را پنهان‌کردن.
چند Purpose را در نقشه همه‌چیز جمع‌کردن.
Layout را مدل دامنه دانستن.
Cross-link را در Export بررسی‌نکردن.
OPML را حفظ کامل semantics فرض‌کردن.
تصویر را بدون Outline بلند منتشرکردن.
RTL و LTR ID را تست‌نکردن.
IRR و تومان را بی‌برچسب مخلوط‌کردن.
Workshop annotation را خودکار canonical کردن.
Map را با داده/Secret واقعی روی Canvas عمومی ساختن.
AI cluster را حقیقت رابطه دانستن.
Popular tool را Best tool نامیدن.
READY_FOR_MAP_REVIEW را Coverage/Release proof دانستن.

چک‌لیست ۴۸ نقطه‌ای Map Review

Purpose یک جمله و آزمون‌پذیر است.
Audience/Decision نام‌برده شده است.
Subject/Scope روشن است.
Exclusionها روشن‌اند.
Map ID/version دارد.
Facts-as-of/cutoff دارد.
Owner/Reviewer دارد.
Review-by دارد.
Canonical Sources شناسه/نسخه دارند.
Registry snapshot ثبت شده است.
Projection query/filter روشن است.
Node taxonomy نسخه‌دار است.
Edge taxonomy نسخه‌دار است.
Legend نسخه‌دار است.
Nodeها stable ID دارند.
Node type machine-readable است.
Label از Ref جدا است.
Source links resolve می‌شوند.
Owner برای Risk/Question/Action روشن است.
Idea از Fact جدا است.
Question از Assumption جدا است.
Observation از Interpretation جدا است.
Finding از Cause جدا است.
Coverage Item از Leaf جدا است.
Duplicate refs کنترل شده‌اند.
Unknown refs بررسی شده‌اند.
Coverage denominator Registry است.
Eligibility/Scope ثبت شده است.
Design status از Outcome جدا است.
Outcome فقط به Attempt وصل است.
Evidence ID/Build/Env روشن است.
Foreign Evidence محدود/رد شده است.
Color تنها حامل معنا نیست.
Text status و prefix/icon وجود دارد.
Contrast/monochrome بررسی شده است.
Short alt Purpose را می‌گوید.
Long description معادل اطلاعات است.
Outline/table ساختاریافته وجود دارد.
Keyboard/zoom/reflow بررسی شده است.
Persian/RTL/LTR IDs بررسی شده‌اند.
Digit/money/time semantics روشن‌اند.
Round-trip expected counts دارد.
Node/edge/attribute loss گزارش شده است.
Export manifest tool/source/hash دارد.
Annotations disposition دارند.
Security/classification/retention روشن است.
Automation limits صریح‌اند.
Review result ادعای محدود دارد.

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

OPML 2.0 Specification: برای ساختار Outline درختی و محدودیت تبادل attributeها؛ نه مدل Test، Coverage standard یا تضمین round-trip ابزارها.
W3C WAI Complex Images: برای short/long text alternatives تصویر پیچیده؛ نه تضمین WCAG، صحت Map یا کفایت متن جایگزین بدون Review.
W3C WAI Accessibility Principles: برای پرهیز از Color-only meaning و اصول کلی قابل تشخیص‌بودن؛ نه ممیزی کامل Accessibility محصول یا ابزار.

جمع‌بندی: Map را View نگه دارید

نقشه ذهنی وقتی ارزش دارد که Purpose و Audience محدود، Node/Edge/Legend روشن، Source و Registry نسخه‌دار، Annotation قابل disposition، Export قابل آزمون و Alternative متنی معادل داشته باشد. شکل شاخه‌ای گفتگو را سازمان می‌دهد؛ حقیقت، Coverage و Outcome از Contractها و Evidenceهای بیرون Map می‌آیند.

برای شروع، یک نقشه موجود را انتخاب و فقط سه کار انجام دهید: به هر Node مهم Type/ID/Ref بدهید؛ رنگ‌ها را به Text Status تبدیل کنید؛ و Coverage را با Registry unique IDs دوباره محاسبه کنید. معمولاً همین سه کنترل تفاوت میان یک تصویر تزئینی و View قابل اعتماد را آشکار می‌کند.

سؤالات متداول درباره نقشه ذهنی در تست نرم‌افزار

۱. آیا نقشه ذهنی می‌تواند جایگزین Test Case یا Test Plan شود؟

نه به‌طور خودکار. Map می‌تواند View سبک یا ورودی طراحی باشد. اگر برای Context شما Artifact کافی است، باید Purpose، Basis، Scope، Risk، Oracle، owner، version و Evidence links لازم را داشته باشد. Decision/Execution semantics را فقط با رنگ و شاخه نگه ندارید.

۲. چگونه Coverage را با Mind Map محاسبه کنیم؟

ابتدا Coverage model و Registry eligible items را مستقل تعریف کنید. سپس unique node refs معتبر را به آن‌ها map کنید و Design/Evidence status را جدا حساب کنید. تعداد برگ‌ها یا برگ‌های سبز مخرج معتبر نیست و Duplicate/Idea/Note باید حذف یا طبقه‌بندی شود.

۳. برای تست اکتشافی چه چیزهایی در نقشه ثبت کنیم؟

Mission، Risk، Question و Idea پیش از Session؛ Path، Data، Observation و Interruption حین Session؛ و Finding، Evidence، Coverage note و Action پس از آن. Typeها را مخلوط نکنید و Session/Attempt/Build/Time/Actor را ثبت کنید.

۴. بهترین ابزار نقشه ذهنی برای QA چیست؟

بهترین نام جهانی وجود ندارد. Stable ID/custom fields، cross-link، version/history، collaboration، API/export، round-trip، accessibility، RTL/Unicode، security و retention را با Fixture خود PoC کنید. برای Workshop کم‌ریسک حتی کاغذ می‌تواند کافی باشد؛ برای Traceability canonical معمولاً Registry جدا لازم است.

۵. چگونه نقشه ذهنی تست را دسترس‌پذیر کنیم؟

Alt کوتاه Purpose را معرفی کند؛ Outline یا جدول بلندِ ساختاریافته اطلاعات و روابط ضروری را معادل‌سازی کند؛ رنگ تنها معنا نباشد؛ contrast، zoom، keyboard، focus و interactive parity بررسی شوند؛ و فارسی/RTL/LTR/Export با کاربران و فناوری‌های نماینده آزموده شود.

برنامه‌ریزی تست

نقشه ذهنی در تست نرم‌افزار؛ از Map Contract تا Evidence