ارتباط نوشتاری QA؛ از Purpose تا Action

ارتباط نوشتاری در QA یعنی تولید Artifact نسخه‌داری که Purpose، منبع، وضعیت، درخواست، مخاطب و مسیر پاسخ آن روشن باشد و گیرنده بتواند بدون حدس آن را پیدا، بفهمد و به اقدام/تصمیم درست وصل کند. غلط‌گیری، لحن حرفه‌ای و اختصار مفیدند؛ اما Writing quality را ثابت نمی‌کنند. این راهنما یک QA Written Artifact Contract می‌سازد.

پاسخ کوتاه: Artifact type و Owner را ثبت کنید؛ Purpose/Audience/Decision/Channel را تعیین کنید؛ Speech Act و پاسخ موردنیاز را در ابتدا بیاورید؛ Fact/Observation/Inference/Unknown را به Source Snapshot وصل کنید؛ Heading/Paragraph/List/Table را معنایی بسازید؛ Actor/Action/Owner/Due را صریح کنید؛ Link/Attachment/Alt/Caption/RTL-LTR و Secret scan را بررسی کنید؛ Audience و Actionability review بگیرید؛ Source of Record/Receipt را معلوم کنید؛ و Change/Correction/Expiry را بدون ویرایش خاموش مدیریت کنید.

مالکیت این مقاله و مرز با Artifactهای تخصصی

این صفحه فقط مالک Quality Contract مشترک برای نوشته‌های QA است. قالب و Evidence گزارش نقص در گزارش باگ قابل‌بازتولید، Status/Forecast/Blocker در گزارش پیشرفت تست، و Risk/Scope/Gate در Test Plan زنده مالک مستقل دارند.

انتخاب Test Scenario/Case/Procedure در سناریوی تست و تست‌کیس، Closure snapshot در گزارش خلاصه تست، Message/Receipt در ارتباط در تست نرم‌افزار، Freshness/Drift در مستندات تست زنده و زبان/Locale/Translation در Locale–Meaning Bridge توضیح داده شده‌اند. ۱۹۴۴ این موضوع‌ها را بازنویسی نمی‌کند.

نوشتن خوب یعنی قابل‌استفاده، نه «بی‌نقص»

متن می‌تواند بدون غلط، کوتاه و مؤدب باشد اما Source، Scope، Due یا Unknown نداشته باشد. برعکس، Artifact فنی ممکن است اصطلاح تخصصی لازم داشته باشد ولی برای Audience هدف دقیق و Actionable باشد. Quality به Purpose و Use وابسته است؛ «Flawless» وضعیت قابل‌اثباتی نیست.

معیار: گیرنده چه باید بداند یا انجام دهد، با اتکا به کدام Source و تا چه زمانی؟

پشتوانهٔ منابع و حد ادعا

راهنمای W3C WAI برای نوشتن دسترس‌پذیر عنوان یکتا، Heading معنایی، Link قابل‌فهم، جایگزین تصویر، Caption/Transcript، دستور روشن و متن واضح را پیشنهاد می‌کند. آموزش Headingهای W3C نیز سلسله‌مراتب معنایی را برای Navigateکردن محتوا توضیح می‌دهد.

ISO 24495-1:2023 Plain Language در چکیدهٔ عمومی خود اصول/راهنمای سند متنی قابل‌فهم را معرفی می‌کند. این مقاله ادعای دسترسی به متن کامل پولی، انطباق ISO یا WCAG certification ندارد؛ از آن‌ها فقط Purpose، Audience، Findability، Understandability و Usability را به Contract QA تطبیق می‌دهد.

چرخهٔ QA Written Artifact

1. Artifact identity/type/version/owner را ثبت کنید.
2. Purpose/Audience/Decision/Channel/Sensitivity را مشخص کنید.
3. Speech Act و requested response را صریح کنید.
4. Source Snapshot و Fact/Observation/Inference/Unknown را ببندید.
5. Front matter و ساختار معنایی بسازید.
6. زبان، Term، Modal، Uncertainty و Action را دقیق کنید.
7. Link/Attachment/Accessibility/Locale/Security را بررسی کنید.
8. Fact/Domain/Audience/Action/Access/Security review بگیرید.
9. Source of Record، Receipt و response route را منتشر کنید.
10. Change/Diff/Correction/Reissue/Expiry/Archive را ببندید.

Artifact identity و Type

`ArtifactID`، type، version، status، supersedes، effective/review time و Owner را نگه دارید. Type می‌تواند `BUG_EVIDENCE`، `STATUS_UPDATE`، `INFORMATION_REQUEST`، `DECISION_NOTE`، `TEST_PLAN`، `TEST_CASE` یا `SUMMARY` باشد؛ هر Type Contract تخصصی خود را هم دارد.

ArtifactID: WRT-QA-044
Type: INFORMATION_REQUEST
Version: 1.2.0
Status: ACTIVE
Supersedes: 1.1.0
Owner: ROLE-QA-07
EffectiveAtUTC: 2026-08-13T08:00:00Z
ReviewAtUTC: 2026-08-20T08:00:00Z

Context Contract

Product/Service، Scope، Purpose، Audience، Decision، Decision Authority، Channel و Sensitivity را ثبت کنید. متن مدیرعامل و Tech Lead لزوماً Fact متفاوت ندارد؛ ممکن است Layer/Detail متفاوت باشد. یک حقیقت در همهٔ Viewها همان حقیقت بماند.

Audience را از عنوان شغلی حدس نزنید

Information need، prior knowledge، Decision role، access need، language و available time را بپرسید. «مدیر فقط خلاصه می‌خواهد» یا «Developer جزئیات را خودش می‌فهمد» کلیشه است. Layered detail بسازید تا مخاطب عمق مناسب را انتخاب کند.

Speech Act را اول متن بیاورید

متن `INFORM`، `REQUEST`، `QUESTION`، `RECOMMENDATION`، `RISK_CLAIM`، `DECISION` یا `COMMITMENT` است؟ Normative strength، requested response، Due و Not-claimed را صریح کنید. «FYI» که در پایان Approval می‌خواهد، Artifact صادقانه نیست.

SpeechAct: REQUEST_FOR_INFORMATION
Request: provide authoritative retry-state contract revision
ResponseType: LINK / UNKNOWN / REDIRECT_TO_OWNER
DueInstant: 2026-08-14T10:00:00Z
NormativeStrength: SHOULD_RESPOND_OR_REDIRECT
NotClaimed: defect, blocker, approval, fault

Source Snapshot و Fact boundary

Authority، Snapshot، `as_of`، Provenance و Fact refs را نگه دارید. Observation، Inference، Unknown و Counterevidence را جدا کنید. «فکر می‌کنم DB است» را حذف نکنید؛ `HYPOTHESIS` با Confidence و Alternative بنامید. Log line نیز بدون Query/Context علت را ثابت نمی‌کند.

Front matter؛ هفت پاسخ در ابتدا

• عنوان یکتا با اطلاعات متمایز در ابتدا.
• Purpose: چرا این Artifact وجود دارد؟
• Takeaway محدود: چه چیزی اکنون می‌دانیم؟
• Action/response: چه می‌خواهیم؟
• `as_of`: اطلاعات متعلق به چه زمان است؟
• Status/version: Draft/Active/Superseded؟
• Owner/contact: سؤال/Correction کجا برود؟

عنوان یکتا و اطلاعات متمایز در ابتدا

«گزارش وضعیت پروژه X – هفته چهارم» برای Search/Decision ضعیف است. مثال بهتر: «Checkout B-۱۷ — Evidence متوقف به‌دلیل Oracle ناسازگار — پاسخ تا ۱۴ اوت». عنوان Claim قطعی نسازد و ID/Scope/State مادی را Front-load کند.

Heading معنایی، نه متن درشت

Heading باید Outline واقعی بسازد و Topic/Purpose بخش را توصیف کند. Style بزرگ جای <h2>/<h3> نیست. رتبه‌ها را منطقی Nest کنید؛ H2→H4 بدون H3 می‌تواند Navigation را مبهم کند. «جزئیات بیشتر» Heading مفیدی نیست.

یک Purpose در هر Section

Background، Evidence، Unknown، Decision و Action را در یک پاراگراف مخلوط نکنید. هر Section سؤال مشخصی پاسخ دهد. Paragraph یک Focus، جملهٔ Topic و پیوند منطقی داشته باشد. کوتاهی به‌خودی‌خود هدف نیست.

List و Table معنایی

Ordered list برای ترتیب، Unordered برای مجموعه و Table برای مقایسهٔ ردیف/ستون. فاصله و خط تیرهٔ دستی ساختار برنامه‌پذیر نیست. Table headers، Caption و متن جایگزین برای View پیچیده لازم‌اند.

Progressive disclosure

لایهٔ ۱: Purpose/Action/State؛ لایهٔ ۲: Fact/Unknown/Options؛ لایهٔ ۳: Evidence details؛ لایهٔ ۴: Raw/reproducible artifacts. خلاصه نباید محدودیت را حذف کند و Detail نباید Action را دفن کند.

Plain language برای Audience واقعی

Plain یعنی مخاطب هدف بتواند اطلاعات لازم را پیدا، بفهمد و استفاده کند؛ نه حذف Term دقیق یا کوتاه‌سازی افراطی. Actor/Action/Object/Condition را صریح، Acronym را بار نخست باز و Term را به Glossary نسخه‌دار وصل کنید.

Modal policy و قطعیت

`must/should/may` و «باید/بهتر است/ممکن است» قدرت متفاوت دارند. Author/Authority و Policy را روشن کنید. «سیستم باید خطا دهد» Expected source می‌خواهد؛ سلیقهٔ نویسنده Oracle نیست. Uncertainty با `UNKNOWN/ESTIMATE/HYPOTHESIS` همان‌جا بیاید.

No idiom، No sarcasm، No blame

«این کد ترکیده»، «ASAP»، «واضح است» و کنایه برای تیم چندزبانه/Async ابهام می‌سازند. رفتار/Artifact/Build را بنویسید، نه شخصیت. No blame به معنی حذف Owner/Decision right یا مسئلهٔ رفتاری مادی نیست.

Actionability Contract

Request، accepted Owner، Due instant، IANA zone، response options، acceptance، dependencies، escalation و expiry را ثبت کنید. «لطفاً بررسی شود» Action نیست. `UNKNOWN/REDIRECT/DECLINE_WITH_REASON` می‌تواند Response معتبر باشد.

فیلد	خوب	مبهم
Request	Oracle revision را لینک/Unknown کنید	بررسی کنید
Owner	ROLE-REQ-۰۳ پذیرفت	تیم Dev
Due	UTC instant + Asia/Tehran View	ASAP/EOD
Done	authoritative link receipt	حل شد

Link text باید مقصد را توضیح دهد

«اینجا کلیک کنید» در فهرست لینک‌ها بی‌معناست. نام Artifact/Action را در Link text بیاورید؛ مقصد مستقیم، status، access class و در صورت نیاز version pin/fallback را بررسی کنید. Redirect chain و صفحهٔ نیازمند دسترسی را پنهان نکنید.

Attachment Manifest

Screenshot/Video/Log «همیشه» لازم نیستند. Purpose، Provenance، timestamp، Build/State/Data، Redaction، text alternative/Caption و expiry را ثبت کنید. پیوست اضافی می‌تواند PII/Secret را نشت دهد و Signal را دفن کند.

تصویر گویاتر از هزار کلمه نیست

تصویر بدون State/Sequence/Expected/Actual و Alt قابل‌بازتولید نیست. کادر قرمز ممکن است Context خارج کادر را پنهان کند. متن بگوید تصویر چه Claimی را پشتیبانی می‌کند و چه چیزی را نشان نمی‌دهد.

Caption، Transcript و Text alternative

ویدئو Caption/Transcript و توضیح Action/State داشته باشد؛ تصویر functional/text alternative؛ Chart جدول یا Summary داده. Auto-caption Review نشده می‌تواند ID/Term فارسی را تغییر دهد. Color/فلش تنها حامل معنا نباشد.

Reading order، Keyboard و Plain-text fallback

ترتیب DOM/Heading/Table/Link باید با ترتیب معنی سازگار باشد. Accordion/Attachment با Keyboard قابل‌دسترسی و fallback متنی داشته باشد. Email HTML پیچیده ممکن است در Client دیگر خراب شود؛ نسخهٔ Plain text برای Action اصلی مفید است.

RTL/LTR و Language tag

زبان سند و Segment را اعلام کنید. شناسه، URL، کد، Timestamp و عدد LTR در متن فارسی RTL isolate شوند. ی/ی، ک/ک، ZWNJ و Normalization policy برای Search/ID matching آزمون شوند. ظاهر درست در Editor، تضمین Copy/paste نیست.

عدد، پول، تاریخ و Zone

Canonical number، Currency/unit، Date format، UTC instant، IANA zone و Calendar label را جدا کنید. `10m`، `۱,۲۳۴`، «تومان»، `۰۳/۰۴/۲۶` و `EOD Friday` مبهم‌اند. IRR/تومان یا میلادی/جلالی بدون Label تبدیل نشوند.

Credential نمونهٔ قدیمی چرا خطرناک بود؟

نوشتن `testuser/password123` رفتار کپی‌کردنی می‌سازد و ممکن است Secret واقعی تلقی شود. از placeholder آشکار مثل `SYNTHETIC_CREDENTIAL_REF` و Provisioning امن استفاده کنید. Password/token/PAN/CVV2/OTP/PII را در Doc/Video/Log قرار ندهید.

Security review و Secret scan

No credentials، no Production secrets، PII minimization، safe examples، Access control، Retention و Secret scan را کنترل کنید. Scanner همه‌چیز را نمی‌بیند؛ Human review و Data owner لازم است. Redaction باید برگشت‌ناپذیر و نسخهٔ خام محدود باشد.

Severity/Priority مالک ثابت ندارند

تستر همیشه Severity را تعیین و PO همیشه Priority را تعیین نمی‌کند. Policy و Decision rights تیم مشخص کنند چه کسی پیشنهاد، Challenge و Disposition می‌دهد. Artifact باید Contract و Authority را لینک کند، نه نقش عمومی را فرض بگیرد.

Cadence ثابت گزارش وجود ندارد

روزانه/هفتگی/دو‌هفته‌ای از Methodology به‌تنهایی نتیجه نمی‌شود. Cadence باید از Decision need، Volatility، Consequence، SLO، recipient load و event trigger بیاید. وقتی State مادی تغییر نکرده، Update ممکن است فقط Receipt بار بسازد.

Template حداقل است، نه کیفیت

Template omission را کم می‌کند ولی فیلدهای پرشده می‌توانند غلط/کهنه/نامربوط باشند. TemplateID/version، Applicability، optional/required logic، owner، change log و Retirement لازم است. متن را برای Case واقعی Adapt کنید.

Spellcheck، Grammar و Lint چه نمی‌فهمند؟

ابزار می‌تواند Typo، جملهٔ بلند یا Style را علامت بزند؛ Source truth، Authority، Missing Unknown، Action feasibility، Bias، Secret یا فهم Audience را ثابت نمی‌کند. Lint boundary را ثبت و خروجی AI را Human review کنید.

هشت Review مستقل

Review	پرسش
Fact	Claim به Source می‌رسد؟
Domain	Term/Boundary درست است؟
Audience	مخاطب Purpose را پیدا/می‌فهمد؟
Actionability	Owner/Due/response قابل‌عمل است؟
Accessibility	Structure/alternative/navigation کار می‌کند؟
Security/privacy	Secret/PII/access/retention کنترل شده؟
Lint	Typo/style anomaly هست؟
Approval	Authority نسخه را منتشر می‌کند؟

Audience test و Actionability test

از نمونهٔ مخاطب بپرسید Purpose، State، Unknown، Action، Owner و Due چیست؛ نه «متن خوب بود؟». سپس یک Dry-run بدون دانش نویسنده انجام دهید. Misinterpretation و سؤال اضافه Finding سند هستند، نه ضعف خواننده.

Source of Record و Notification

Email/Chat می‌تواند اعلان باشد، اما Canonical Artifact یک محل نسخه‌دار داشته باشد. Recipient scope، Notification، Receipt، Interpretation check و Response route را مشخص کنید. Attachment کپی‌شده ممکن است از Source جدا و کهنه شود.

Receipt موافقت نیست

Delivered/Read/Ack/Interpreted/Agreed/Acted وضعیت‌های جدا هستند. Read receipt انسانی را ثابت نمی‌کند و Ack حقیقت محتوا را تأیید نمی‌کند. برای Artifact تصمیم‌ساز، برداشت و Authority response ثبت شود.

Change Log و Diff مادی

چه چیزی، چرا، توسط چه کسی، با کدام Impact و از چه زمان تغییر کرد؟ Diff صرفاً کاراکتری ممکن است تغییر معنی Modal/number/Scope را پنهان کند. Affected artifacts و Recipients را به Revision تازه وصل کنید.

Correction و Reissue

ویرایش خاموش ایمیل/Doc قدیمی ممنوع. نسخهٔ غلط حفظ، Correction مشخص، Audience قبلی reissue و Decision/Action متاثر Reopen شود. «Typo بود» فقط وقتی معتبر است که Meaning/Action تغییر نکرده باشد.

Expiry و Archive

Artifact بدون Expiry می‌تواند سال‌ها Reuse شود. Review trigger، superseding link و Archive status را نمایش دهید. Archive برای Audit است، نه Source جاری. Search result باید نسخهٔ Active را برجسته کند.

Writing Quality را به شخصیت نویسنده وصل نکنید

Typo، زبان دوم، Dyslexia یا Style، ارزش/دقت فنی فرد را ثابت نمی‌کند. Artifact review برای محصول کار است؛ آموزش/Access فراهم شود. تعداد غلط، زمان نوشتن، Readability score یا لحن برای Performance ranking افراد استفاده نشود؛ `people_scoring=false`.

قالب QA Written Artifact Contract

[Identity] ArtifactID, Type, Version, Status, Supersedes, Effective/Review, Owner
[Context] Product, Scope, Purpose, Audience, Decision/Authority, Channel, Sensitivity
[SpeechAct] Type, NormativeStrength, RequestedResponse, Due, NotClaimed
[Source] Authority, Snapshot, AsOf, Provenance, Facts, Observations, Inferences,
Unknowns, Counterevidence
[FrontMatter] Title, UniqueFirst, Purpose, Takeaway, Action, AsOf, Status
[Structure] Outline, SemanticHeadings/Order, Section/Paragraph focus, Lists/Tables, Layers
[Language] LangTag, AudienceTerms, Acronyms, Glossary, Actor/Action, Modal, NoIdiom/
Sarcasm/Blame, Uncertainty
[Action] Request, Owner, DueInstant/Zone, Options, Acceptance, Dependency, Escalation, Expiry
[Links] MeaningfulText, Checked/Direct, AccessClass, VersionPin, Fallback
[Attachments] Manifest, Purpose, Provenance, Redaction, Alt/Caption, Expiry
[Access] HeadingTree, ReadingOrder, LinkPurpose, Alt, Headers, Transcript, Color,
Keyboard, RTL-LTR, PlainText
[Locale] Number, Currency/Unit, Date, UTC/IANA, Calendar, Normalization, Bidi
[Security] NoCredentials/Secrets, PII, SafeExamples, Access, Retention, Scan, HumanReview
[Review] Fact, Domain, Audience, Actionability, Access, Security, LintBoundary, Approval
[Delivery] SourceOfRecord, Recipients, Notification, Receipt, Interpretation, ResponseRoute
[Lifecycle] ChangeLog, Diff, Affected, Correction, Reissue, Expiry, Archive, TemplateVersion
[Limits] NoArtifactCannibalization, people_scoring=false, NotProof

آزمایشگاه آفلاین Checkout ایرانی

Fixture خیالی `SYN-QA-WRITING-ARTIFACT-۰۱` یک Checkout کاملاً جدا از شبکه/Production دارد: Order/PaymentAttempt جعلی، PSP Stub، Callback، Ledger، Reconciliation و اعلان ساختگی. Timeout پیش/پس از Fake Commit، Retry، duplicate/late/reordered Callback و State مبهم در Artifactهای مصنوعی بازپخش می‌شوند.

شناسه‌های Tenant/Order/Attempt/Event/Run/Build/Data/Source/Artifact/Attachment/Review/Decision پایدارند. IRR خیالی Canonical و تومان فقط View برچسب‌خورده است. ارقام فارسی/عربی/لاتین، ی/ی، ک/ک، ZWNJ، RTL/LTR/Bidi، UTC، Asia/Tehran و جلالی نمایشی پوشش داده می‌شوند. هیچ شبکه، سازمان، شخص، کاربر، سفارش، پرداخت، PSP، بانک، پول، PII، نام، موبایل، ایمیل، IP، حساب، PAN، CVV2، OTP، Cookie، Token، Credential، Log یا Screenshot واقعی و هیچ توصیهٔ مالی/بانکی/حقوقی/امنیتی/حریم خصوصی/HR وجود ندارد.

Checker سطحی چه می‌بیند؟

Checker Spellcheck، Grammar، اختصار، لحن حرفه‌ای، Template، Screenshot و Proofread را می‌بیند و می‌گوید:

superficial: WRITING_FLAWLESS

این علائم Fact truth، Purpose، Actionability، Access، Security یا Receipt را ثابت نمی‌کنند.

ممیزی ساختاری چه یافت؟

انتظار اولیه ۱۲۴ Finding بود، اما اجرای Validator ۱۲۷ نشان داد. فهرست مستقل شمارش شد: ۱۲۸ کنترل کاملاً یکتا، بدون Duplicate؛ یکی (`people_scoring=false`) در Fixture پاس بود، پس ۱۲۷ Finding واقعی درست است. هیچ کنترل معتبری برای رسیدن به عدد کمتر حذف نشد:

audit: HOLD-127
independentPeopleScoringRule: PASS

قاعدهٔ ۱۲۸ مستقل امتیازدهی افراد را منع می‌کند. ۱۲۷ تعداد نقص‌های ساختاری همین Fixture/نسخه است؛ امتیاز Writing یا نویسنده نیست.

نسخهٔ اصلاح‌شده چه می‌گوید؟

corrected: READY_FOR_WRITTEN_ARTIFACT_REVIEW-0

صفر فقط آمادگی ساختاری را نشان می‌دهد؛ نه Fact truth، Audience comprehension، Accessibility conformance، Security، Action completion، Product quality، Outcome یا Decision correctness.

ضدالگوهای ارتباط نوشتاری QA

• غلط‌گیر/Grammar به‌عنوان Quality proof.
• «بی‌نقص» یا «توسعه‌دهنده عاشقش می‌شود».
• نوشتن برای اعتبار شخصی نویسنده.
• Hero/quality champion framing.
• Template پرشده به‌عنوان درستی.
• Title عمومی بدون State/Scope.
• Purpose/Action دفن‌شده در پایان.
• FYI که Approval می‌خواهد.
• Fact/Inference/Unknown مخلوط.
• Expected بدون Oracle source.
• Heading بصری بدون semantics.
• H2→H4 بی‌دلیل.
• Paragraph چندمنظوره.
• اختصار با حذف محدودیت.
• Idiom/Sarcasm/ASAP/EOD.
• «بررسی شود» بدون Owner/Due.
• Click here و Redirect chain.
• Screenshot/Video همیشه اجباری.
• تصویر بدون Alt/Context.
• Color/فلش تنها حامل معنا.
• Credential نمونه مثل password123.
• Log/Video دارای PII/Secret.
• Severity همیشه Tester، Priority همیشه PO.
• Cadence روزانه/هفتگی از روی Methodology.
• Read receipt به‌عنوان Agreement.
• Email attachment به‌عنوان Source of Record.
• Lint/AI به‌عنوان Fact/Security review.
• Correction خاموش.
• Artifact بدون Expiry/Archive state.
• Readability/Typo برای امتیازدهی فرد.
• ادعای مستقیم سرعت/اعتماد/کیفیت.

چک‌لیست Artifact Owner

• ArtifactID/type/version/status/owner روشن‌اند.
• Purpose/Audience/Decision/Authority/Channel/Sensitivity ثبت‌اند.
• Speech Act/strength/response/due/not-claimed در ابتدا هستند.
• Source snapshot/as-of/provenance و Fact refs قابل‌ردیابی‌اند.
• Observation/Inference/Unknown/Counterevidence جدا هستند.
• Title یکتا و Purpose/Takeaway/Action front-loaded است.
• Outline/Heading order/section purpose/paragraph focus معنایی‌اند.
• List/Table semantics و progressive layers درست‌اند.
• Language tag/audience terms/acronym/glossary روشن‌اند.
• Actor/Action/Modal/Uncertainty دقیق و بدون blame/idiom است.
• Request/accepted owner/due zone/options/dependencies/escalation کامل‌اند.
• Link text/destination/access/version/fallback بررسی شده‌اند.
• Attachment purpose/provenance/redaction/alt/caption/expiry دارد.
• Heading tree/reading order/table/keyboard/plain-text آزمون شده‌اند.
• RTL/LTR/number/currency/date/zone/calendar/Unicode کنترل شده‌اند.
• No credential/secret/PII، access/retention/scan/human review پاس‌اند.
• Fact/Domain/Audience/Action/Access/Security reviews انجام شده‌اند.
• Lint boundary و Approval ثبت شده‌اند.
• Source of Record/recipient/notification/receipt/response route روشن‌اند.
• Interpretation check برای Artifact مادی انجام شده است.
• ChangeLog/Diff/Affected/Correction/Reissue بسته‌اند.
• Expiry/Archive/Template version روشن‌اند.
• Artifact تخصصی به مالک خودش لینک شده است.
• `people_scoring=false` مستقل کنترل شده است.
• NotProof حدود نتیجه را بیان می‌کند.

Pilot سی‌روزه Written Artifact

1. روز ۱ تا ۵: یک Information Request کم‌خطر را انتخاب و Identity/Context/Speech Act را در Shadow ثبت کنید.
2. روز ۶ تا ۱۰: Source/Front matter/Outline/Language و Action contract را بسازید.
3. روز ۱۱ تا ۱۵: Link/Attachment/Access/RTL-LTR/Locale و Secret scan را Dry-run کنید.
4. روز ۱۶ تا ۲۰: Audience و Actionability test بدون توضیح نویسنده اجرا شود.
5. روز ۲۱ تا ۲۵: Source of Record/Receipt/Response و یک Correction/Reissue مصنوعی بسته شود.
6. روز ۲۶ تا ۳۰: Misinterpretation/correction/access/response Signals مرور و Continue/Adapt/Stop شود.

Pilot، Writing skill فرد، Security، Accessibility conformance، کیفیت محصول یا Outcome را ثابت نمی‌کند و نباید دادهٔ حساس واقعی داشته باشد.

جمع‌بندی اجرایی

ارتباط نوشتاری QA از Grammar فراتر است: Purpose/Source/State/Action را Front-load کنید؛ Fact و Unknown را جدا نگه دارید؛ ساختار معنایی و دسترس‌پذیر بسازید؛ Link/Attachment/Locale/Secret را QA کنید؛ Audience و Actionability را بیازمایید؛ Source of Record و Receipt را روشن کنید؛ و هر تغییر را با Diff/Correction/Expiry مدیریت کنید. ابزار و Template کمک‌اند، نه Authority.

پرسش‌های متداول ارتباط نوشتاری برای تستر

ارتباط نوشتاری خوب در QA چیست؟

Artifact نسخه‌داری که Purpose، Audience، Source، State، Unknown، Action، Owner و Due آن روشن و برای مخاطب هدف قابل‌یافتن/فهم/استفاده باشد. نبود غلط کافی نیست؛ Trace، Access، Security و lifecycle هم لازم‌اند.

برای نوشتن گزارش باگ از چه قالبی استفاده کنیم؟

از Reproduction Contract تخصصی استفاده کنید: Build/State/Data/Attempt، Oracle، Expected/Actual، Evidence امن، Handoff و Verification. این مقاله فقط Quality Contract مشترک Writing را می‌دهد و Bug Report را دوباره تعریف نمی‌کند.

آیا Screenshot یا Video همیشه لازم است؟

خیر. فقط وقتی Claim را با Signal لازم پشتیبانی می‌کند و Provenance/Context/Redaction/Alt یا Caption دارد. برای State/Sequence ممکن است Trace یا Structured data بهتر باشد. پیوست نباید PII/Secret را نشت دهد.

گزارش وضعیت تست را هر چند وقت ارسال کنیم؟

Cadence ثابت روزانه/هفتگی وجود ندارد. Decision need، تغییرپذیری State، پیامد تأخیر، SLO، بار مخاطب و Event trigger را Contract کنید. Update بی‌تغییر ممکن است Noise باشد؛ تغییر مادی ممکن است ارسال فوری بخواهد.

آیا ابزار AI یا غلط‌گیر کیفیت نوشته را تضمین می‌کند؟

خیر. ابزار می‌تواند Draft/Typo/Style را کمک کند اما Fact، Authority، Unknown، Action feasibility، Access یا Secret را نمی‌فهمد. Tool/version و تغییر مادی ثبت و Human Fact/Domain/Audience/Security review انجام شود.