گوش دادن فعال در QA؛ از Intake تا Confirmation

گوش دادن فعال برای تستر یعنی ساخت یک زنجیرهٔ قابل‌ردیابی از گفته/Artifact تا یادداشت، برداشت، سؤال روشن‌کننده و تأیید یا اصلاح Speaker؛ نه حدس‌زدن نیت از سکوت، لحن یا حالت چهره. این راهنما یک Listening Intake & Confirmation Protocol می‌سازد تا آنچه شنیده شد از آنچه Listener استنباط کرد جدا بماند.

پاسخ کوتاه: Purpose و Scope گفت‌وگو را اعلام کنید؛ رضایت و Access need را بپرسید؛ Utterance/Artifact را نسخه‌دار ثبت کنید؛ Verbatim/Paraphrase/Observation/Inference/Unknown را جدا نگه دارید؛ سؤال را با Purpose و بدون پاسخ مطلوب بسازید؛ Interpretation را با Assumption/Alternative محدود کنید؛ Speaker مشخص کند کدام بخش Confirmed/Disputed/Unanswered است؛ و فقط نسخهٔ تأییدشده را با Trace و Reopen route به Requirement/Decision بعدی تحویل دهید.

مالکیت این مقاله و مرز موضوع

این صفحه فقط مالک Listening Intake → Interpretation → Speaker Confirmation است. تحلیل نیازمندی در STLC مالک Testability/RTM/Risk، ارتباط در تست نرم‌افزار مالک Message/Decision Receipt، و بازخورد تیم QA مالک Claim/Response/Repair است.

ارتباط بین‌فرهنگی QA مالک Language/Locale/Translation، جلسه بازبینی تست مالک Facilitation، تست تجربه کاربری مالک Research Observation/Insight، و ارتباط ریسک کیفیت مالک Signal-to-Closure است. Listening جای این تصمیم‌ها را نمی‌گیرد.

Listening شنیدن کلمه یا خواندن ذهن نیست

Speaker یک پیام در Context می‌دهد؛ Listener آن را از فیلتر دانش، زبان، نقش و فرض خود می‌شنود. «درک عمیق نیت» بدون تأیید صاحب معنا ادعای ذهن‌خوانی است. Protocol فقط چیزهای مشاهده‌پذیر و پاسخ‌های قابل‌ثبت را کنترل می‌کند.

Paraphrase خوب یک فرضیهٔ محترمانه است، نه نسخهٔ رسمی گفتهٔ Speaker.

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

Listening خوب نمی‌تواند Requirement را خودبه‌خود درست، کامل یا نمایندهٔ همهٔ کاربران کند؛ باگ را پیشگیری، هزینه را کم، Trust را ایجاد، Quality را بالا یا Delivery را به‌موقع تضمین نمی‌کند. Speaker نیز ممکن است Unknown، تعارض یا اطلاعات ناقص داشته باشد. Confirmation فقط Meaning را در Scope ثبت می‌کند.

ادعای «۱۰۰ برابر هزینه» حذف می‌شود

ضریب ثابت رفع نقص به Stage، Architecture، Deploy/Recovery، Severity و Context وابسته است و دلیل عمومی برای Listening نیست. اگر یک Mismatch هزینه ساخته، Cost را با منبع/دامنهٔ همان Case ثبت کنید؛ از افسانهٔ عددی برای ارزش‌گذاری مهارت استفاده نکنید.

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

راهنمای GOV.UK برای مصاحبهٔ عمیق بر Consent، تنظیم سرعت گفت‌وگو، سؤال باز/خنثی و مثال واقعی تأکید دارد. طراحی سؤال خوب هم نشان می‌دهد سؤال بسته گاهی برای پاسخ‌پذیری بهتر است و گزینهٔ «نمی‌دانم» باید معتبر بماند. این‌ها User Research guidance هستند؛ Listening روزمرهٔ QA را به پژوهش رسمی تبدیل نمی‌کنند.

راهنمای ارتباط فراگیر GOV.UK انتخاب Channel و قالب دسترس‌پذیر را بخشی از ارتباط می‌داند. اینجا اصول رضایت، سؤال خنثی و Access اقتباس می‌شوند؛ نه ادعای انطباق حقوقی/پژوهشی یا نسخهٔ واحد برای همه.

زنجیرهٔ Listening Intake در یک نگاه

1. Intake identity، Purpose، Decision و Scope را ثبت کنید.
2. Role، Meaning Authority، Power و افراد متأثر غایب را روشن کنید.
3. Consent/Access/Language/Pace/Async route را فراهم کنید.
4. Utterance/Artifact/Revision/Context را Source بدانید.
5. Note type را Verbatim/Paraphrase/Observation/Inference/Unknown کنید.
6. Question را با Purpose/neutrality/answer options بسازید.
7. Interpretation را با Assumption/Alternative/Confidence محدود کنید.
8. Speaker بخش Confirmed/Disputed/Unanswered را تعیین کند.
9. Summary، Decision، Action و Unknown را جدا کنید.
10. Handoff، Receipt، Reopen، Repair و Review را ببندید.

Listening Intake identity

`IntakeID`، version، status، supersedes، started/review time را نگه دارید. Statusهای نمونه: `DRAFT → INTAKE_OPEN → INTERPRETATION_REVIEW → SPEAKER_CONFIRMED → HANDOFF → REPAIR_REQUIRED → SUPERSEDED → CLOSED`. تغییر Source یا Speaker correction نسخهٔ تازه می‌خواهد.

IntakeID: LSN-QA-032
Version: 1.1.0
Status: INTERPRETATION_REVIEW
Supersedes: 1.0.0
StartedAtUTC: 2026-08-13T08:00:00Z
ReviewAtUTC: 2026-08-14T08:00:00Z
NotProof: intent, requirement truth, defect prevention, product quality

Purpose، Decision، Scope و Out-of-scope

آیا Intake برای Clarify یک Statement، کشف Unknown، آماده‌سازی Requirement input یا ثبت Concern است؟ کدام Decision ممکن است متاثر شود؟ چه چیزی بررسی نمی‌شود؟ یک گفت‌وگوی «کمی بیشتر توضیح بده» ممکن است Scope را بی‌پایان و حس بازجویی بسازد.

Role و Authority را جدا کنید

Speaker صاحب گفته/تجربهٔ خود است؛ Listener مالک برداشت نیست؛ Note Owner ثبت را نگه می‌دارد؛ Meaning Authority ممکن است Speaker یا Source owner؛ Decision Authority فرد دیگری است. Speaker تأیید نمی‌کند که Requirement درست یا تصمیم نهایی است؛ فقط برداشت نسبت‌داده‌شده را Confirm/Dispute می‌کند.

افراد متأثر غایب

Speaker «صدای همهٔ کاربران» یا همهٔ تیم نیست مگر نمایندگی رسمی و حدود آن ثبت باشد. Affected-absent و Perspectiveهای موجود/غایب را بنویسید. Listening خوب یک Sample محدود را Universe نمی‌کند.

Power asymmetry

Speaker ممکن است در برابر مدیر، مشتری، ارزیاب یا متخصص ارشد نتواند آزادانه بگوید «برداشت شما غلط است». مسیر خصوصی/Async، No retaliation، Meaning review جدا از performance و امکان همراه/نماینده فراهم کنید. سؤال مؤدبانه فشار را خودکار حذف نمی‌کند.

Consent عملیاتی

این مقاله تعریف حقوقی/پزشکی Consent نمی‌دهد. در Intake، Speaker بداند Purpose، Note/Recording، Audience، Retention و Withdrawal چیست و بتواند سؤال خاص را رد کند. حضور در جلسه رضایت با نقل‌قول یا Recording نیست.

Access preference را بپرسید

Language، Interpreter، Caption، Text route، Pace، Break و Async response را خوداظهاری کنید. تماس چشمی، سرعت پاسخ، Speech یا Camera معیار Listening/Cooperation نیست. فرد ممکن است نوشتن را به صحبت ترجیح دهد یا برای پردازش زمان نیاز داشته باشد.

Channel متناسب با Intake

Sync برای Follow-up وابسته مفید است؛ Async برای فکر، ترجمه و Trace. Audio/Video بدون Caption/Text برخی افراد را حذف می‌کند؛ Chat شتاب‌زده نیز Context را خرد می‌کند. Channel را از Purpose، Access، Sensitivity و Urgency انتخاب کنید.

Source چیست؟

`UtteranceID`، Artifact refs، Timestamp، Language tag، Revision، Provenance و Source Context را ثبت کنید. حافظهٔ Listener Source رسمی نیست. اگر Transcript خودکار است، خطا و Review status را نگه دارید. جملهٔ جداشده از سؤال قبلی یا شرایط جلسه ممکن است معنای تازه بسازد.

UtteranceID: UTT-14
Source: audio segment 00:12:08..00:12:31 + chat CH-09
Language: fa-IR; Interpreter: none
Context: responding to Q-07 about retry after timeout
Revision: transcript TR-04@2 (human corrected)
QuoteStatus: VERBATIM_REVIEWED

Attention mode قابل‌مشاهده

Attention را از Eye contact یا Nodding استنتاج نکنید. Listener می‌تواند Note taking، Pause notification، اعلان حواس‌پرتی یا زمان پاسخ را توافق کند. هدف فراهم‌کردن شرایط پردازش است، نه نمایش ظاهری توجه.

Interruption policy مطلق نیست

قطع‌نکردن همیشه بهتر نیست: Caption از دست رفته، Term مبهم، Timebox/Access need یا Harm فوری ممکن است Pause لازم کند. Route محترمانه: «برای اینکه این اصطلاح را غلط ثبت نکنم، همین‌جا مکث کنیم؟» تکمیل‌کردن جملهٔ Speaker بدون دعوت ممنوع است.

Silence Policy

سکوت می‌تواند فکر، عدم فهم، عدم تمایل، مشکل فنی، فشار یا هیچ‌کدام باشد. آن را موافقت، ناراحتی یا «ابهام پنهان» ندانید. فضای پاسخ بدهید و گزینهٔ «می‌خواهم بعداً پاسخ دهم/پاسخ نمی‌دهم» را معتبر کنید.

نشانهٔ غیرکلامی Oracle نیست

حالت چهره، لحن، مکث یا نگاه ممکن است Prompt سؤال محترمانه باشد، نه Evidence نیت/دروغ/ابهام. بنویسید «در ۰۰:۱۴:۰۵ مکث ۶ثانیه‌ای ثبت شد» فقط اگر مادی و رضایت‌دار است؛ نه «نگران بود». Camera-off هیچ معنای روان‌شناختی ندارد.

مرز Note و ذهن‌خوانی

یادداشت باید Type داشته باشد. Verbatim چیزی است که دقیق گفته شد؛ Paraphrase بازگویی Listener؛ Observation رخداد قابل‌مشاهده؛ Inference توضیح ممکن؛ Unknown نبود پاسخ. مخلوط‌کردن آن‌ها «صورت‌جلسه» را به داستان Listener تبدیل می‌کند.

Note type	نمونه	حد
VERBATIM	«retry نباید خودکار باشد»	Context/quote review
PARAPHRASE	Listener: retry نیازمند تصمیم است	Speaker confirm
OBSERVATION	پاسخ به Q-۰۷ پس از 6s	نیت نیست
INFERENCE	ممکن است concern امنیتی باشد	Alternative لازم
UNKNOWN	Authority retry نامعلوم	سبز/صفر نیست

Paraphrase تکنیک تأیید است، نه تفسیر آزاد

بازگویی باید Source link، Scope و Modal را حفظ کند. مثال بد: Speaker می‌گوید «کاربر به‌راحتی ذخیره کند» و Listener فوراً «پس Wishlist همگام و دائمی می‌خواهیم» می‌سازد. این Solution inference است. بهتر: «من “به‌راحتی” و “برای بعد” شنیدم؛ Actor، مدت نگهداری و Device scope هنوز نامعلوم‌اند—درست است؟»

Question Contract

هر سؤال مهم `QuestionID`، Purpose، Type، Neutrality check، Answer options، امکان `DON’T_KNOW/DECLINE` و Follow-up basis دارد. سؤال زیاد نشانهٔ Listening بهتر نیست. چیزی را بپرسید که Decision/Meaning را تغییر می‌دهد.

QuestionID: Q-07
Purpose: clarify actor and retry authority
Type: OPEN_THEN_BOUNDED
Prompt: بعد از timeout، چه کسی و با چه نشانه‌ای درباره retry تصمیم می‌گیرد؟
ValidResponses: described / unknown / defer / decline
Avoids: «پس سیستم باید خودکار retry کند، درست است؟»
FollowupBasis: response mentions duplicate risk

سؤال باز همیشه بهتر نیست

سؤال باز Context و مثال می‌آورد؛ سؤال بسته یک Boundary را Confirm می‌کند؛ سؤال چندگزینه‌ای Cognitive load را کم می‌کند ولی گزینه‌ها را محدود می‌سازد. ترکیب پیشنهادی: باز برای کشف، Probe برای مثال، بسته برای تأیید دقیق—با `other/unknown/decline`.

سؤال هدایت‌گر و فرض پنهان

«چرا این طراحی بد باعث دوباره‌کاری شد؟» بدبودن/علت را فرض می‌کند. «چه رخدادهایی پیش از Rework ثبت شد؟ چه توضیح‌های دیگری هست؟» خنثی‌تر است. Neutrality کامل ممکن نیست؛ فرض‌ها را Review کنید و پاسخ مطلوب را در سؤال جاسازی نکنید.

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

«چه کسی، چرا، تا کی و اگر شکست خورد چه؟» چهار سؤال است و پاسخ ناقص را محتمل می‌کند. Questionها را شماره‌دار و اولویت‌دار کنید. Speaker بتواند بگوید کدام بخش را پاسخ داد یا نداد.

Probe بر اساس پاسخ، نه Script

Follow-up باید به عبارت/مثال قبلی وصل باشد: «گفتید گاهی duplicate می‌شود؛ آخرین نمونه چه Stateهایی داشت؟» Script ثابت ممکن است گفتگو را به مسیر مطلوب Listener بکشد. Probe نباید Speaker را مجبور به علت‌سازی کند.

مثال واقعی و Boundary

به‌جای «معمولاً چه می‌شود؟» بپرسید «آخرین بار چه رخ داد؟» سپس آن Example را به همهٔ موارد تعمیم ندهید. Event identity، Context و Counterexample را نگه دارید. Recall خطاپذیر است؛ Artifact/Evidence مستقل را بعداً وصل کنید.

Interpretation Contract

برداشت Listener باید Statement، Source links، Scope، Assumptions، Alternatives، Confidence و Not-claimed داشته باشد. این Contract تفسیر را Fact نمی‌کند؛ آن را برای Speaker و Owner قابل‌اصلاح می‌سازد.

InterpretationID: INT-09
Statement: retry automatic is not yet authorized after ambiguous timeout
Sources: UTT-14 + ART-REQ-22@3
Scope: synthetic Checkout timeout path only
Assumptions: “automatic” refers to client retry
Alternatives: server reconciliation may trigger recovery
Confidence: LOW_PENDING_CONFIRMATION
NotClaimed: final requirement, user intent, release blocker

Speaker Confirmation مالک معناست، نه حقیقت سیستم

درخواست Confirmation: «کدام بخش برداشت من گفتهٔ شما را درست بازتاب می‌دهد، کدام بخش نه، و چه چیزی بی‌پاسخ است؟» Speaker Response باید Confirmed/Disputed/Unanswered و Correction داشته باشد. Speaker ممکن است Authority Requirement/Release نباشد؛ Confirmation آن را ایجاد نمی‌کند.

Confirmed، Disputed و Unanswered

وضعیت	معنا	گام بعد
CONFIRMED_AS_SPOKEN	برداشت گفته را بازتاب می‌دهد	Handoff با Authority boundary
DISPUTED	Speaker برداشت را رد می‌کند	Correction/re-paraphrase
UNANSWERED	اطلاعات/اختیار کافی نیست	Unknown owner
DEFERRED	بعداً پاسخ می‌دهد	Due/route
DECLINED	پاسخ نمی‌دهد	بدون تنبیه؛ limitation

Confirmation انقضا دارد

با تغییر Context، Artifact، تصمیم یا دانش Speaker، برداشت Confirmed قدیمی می‌شود. Expiry/review trigger تعیین کنید. نقل‌قول قدیمی را برای Requirement جدید Reuse نکنید مگر Context bridge بازبینی شود.

Summary را از Decision و Action جدا کنید

Summary بازتاب گفت‌وگوست؛ Decision تعهد Authority؛ Action تعهد Owner. عبارت «پس جمع‌بندی شد که Wishlist نامحدود و اشتراک ایمیلی بسازیم—همه موافق‌اند؟» سه لایه را مخلوط می‌کند. Unknown/Dissent و موارد خارج Scope را هم نگه دارید.

Artifact	Owner	Receipt
Listening Summary	Note owner + Speaker review	meaning reflected
Requirement	Requirement authority	approved version
Decision	Decision authority	decision receipt
Action	accepted owner	scope/due/capacity

Receipt سکوت را Agreement نمی‌کند

Speaker باید Route و Window مناسب برای Review داشته باشد. عدم پاسخ ممکن است Availability/Access/Power باشد؛ Policy باید وضعیت را `UNCONFIRMED` نگه دارد، نه تأیید خودکار. Receipt دریافت را از Confirmed meaning جدا کند.

Handoff فقط نسخهٔ تأییدشده

Destination، Owner، Due، Acceptance، Trace و Reopen را ثبت کنید. Requirement Analyst ممکن است Summary را input بگیرد و با Evidence/سایر Stakeholderها بررسی کند. Listener نباید از CONFIRMED_AS_SPOKEN به APPROVED_REQUIREMENT بپرد.

Privacy، Quote و Retention

Note را حداقل کنید؛ Access/Retention و مسیر Sensitive information را تعیین کنید. Verbatim quote، نام و Recording فقط با Purpose/Consent مناسب. Paraphrase نیز می‌تواند فرد را قابل‌شناسایی کند. دادهٔ سلامت/HR/امنیت را در Summary عمومی تکثیر نکنید.

گفت‌وگوی چندزبانه

Source language، Interpreter/translator، Revision و اصطلاح‌های مادی ثبت شوند. Speaker Confirmation باید روی نسخه‌ای باشد که واقعاً فهمیده است. ترجمهٔ Listener بدون Review، گفتهٔ Speaker نیست. برای جزئیات از مالک Locale–Meaning Bridge استفاده کنید.

Remote/Hybrid listening

Caption، Chat parity، Turn route، متن Artifact و Async correction فراهم کنید. «نشانه‌های غیرکلامی کمتر است، پس سوءتفاهم حتماً بیشتر» ادعای عمومی نیست؛ Protocol باید Meaning را با Confirmation کنترل کند، نه Camera.

Repair وقتی برداشت غلط وارد Artifact شد

`MismatchID`، تفاوت مشاهده‌شده، Impact، Interpretation اصلاح‌شده، Audience reissue، Artifactهای متأثر و Review time را ثبت کنید. Requirement/Test/Decision متاثر Reopen شود. سرزنش «خوب گوش ندادی» بدون بررسی Source/Question/Power/Access کافی نیست.

MismatchID: LMR-06
ObservedDifference: “may retry” recorded as “must retry”
Impact: TC-18 assumed mandatory client retry
CorrectedInterpretation: retry is an option pending ROLE-REL-03
Reissue: AUD-11 complete
AffectedArtifacts: REQ-22@3, TC-18@2 reopened
ReviewAtUTC: 2026-08-16T08:00:00Z

Bias Probe برای Listener

• آیا Solution مطلوب خودم را داخل Paraphrase گذاشتم؟
• آیا مقام/تخصص Speaker را Truth تلقی کردم؟
• آیا سکوت/لحن/چهره را نیت خواندم؟
• آیا Example واحد را Requirement عمومی کردم؟
• آیا فقط پاسخی را یادداشت کردم که Risk فرضی من را تأیید می‌کند؟
• آیا Question اجازهٔ Unknown/Dispute/Decline می‌داد؟

Comprehension Check دوطرفه

Listener برداشت را ارائه می‌دهد؛ Speaker آن را اصلاح می‌کند؛ سپس Listener Correction را با زبان خود بازگو می‌کند. هدف رسیدن به Trace مشترک است، نه مجبورکردن Speaker به عبارت Listener. اگر اختلاف باقی است، `DISPUTED/UNKNOWN` معتبر است.

Metricهای سالم Listening

Confirmed/disputed/unanswered coverage، time-to-speaker-correction، leading-question finding، source-link coverage، handoff reopen و access incident می‌توانند Signal باشند. تماس چشمی، تکان سر، قطع‌کردن، تعداد سؤال، زمان حرف‌زدن یا «Listening score» فرد را KPI نکنید؛ `people_scoring=false`.

قالب کامل Listening Intake

[Identity] IntakeID, Version, Status, Supersedes, StartedAt, ReviewAt
[Context] Product, Artifact, Purpose, Decision, Channel, Scope, OutOfScope
[Roles] Speaker, Listener, NoteOwner, MeaningAuthority, DecisionAuthority, Absent, Power
[Consent] Participation, Recording, Withdrawal, QuestionDecline, NoRetaliation
[Access] PreferenceSource, Language, Interpreter, Caption, Text, Pace, Break, Async
[Source] UtteranceID, ArtifactRefs, Timestamp, LanguageTag, Revision, Provenance, Context
[Listening] Attention, Interruption, Silence, NoteBoundary, NonverbalBoundary, IntentUnknown
[Notes] Verbatim, Paraphrase, Observation, Inference, Unknown, Redaction
[Questions] ID, Purpose, Type, Neutrality, OneAtATime, Options, DontKnow, Refusal, Basis
[Interpretation] Statement, Sources, Scope, Assumptions, Alternatives, Confidence, NotClaimed
[Confirmation] Request, Response, Confirmed, Disputed, Unanswered, Correction, Expiry
[Summary] Items, DecisionsSeparate, ActionsSeparate, Unknowns, Dissent, Receipt
[Handoff] Destination, Owner, Due, Acceptance, Trace, Reopen
[Privacy] Minimization, Access, Retention, QuotePolicy, SensitiveRoute
[Repair] Mismatch, Difference, Impact, Corrected, Reissue, AffectedArtifacts, Review
[Review/Limits] Comprehension, Bias, Access, Audit, NoMindReading, NoBodyOracle,
people_scoring=false, NotProof

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

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

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

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

Checker تماس چشمی، تکان سر، قطع‌نکردن، Paraphrase، سؤال باز و Summary را می‌بیند و می‌گوید:

superficial: ACTIVE_LISTENING_MASTERED

این رفتارها Speaker intent، Shared meaning، Consent یا درستی Requirement را ثابت نمی‌کنند.

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

اجرای نخست Validator ۱۰۴ Finding واقعی در برابر انتظار ۱۰۶ نشان داد. شمارنده پایین نیامد؛ دو کنترل ماهوی Power asymmetry و Source context افزوده شدند. سپس برخورد نام بولی `summary` با شیء Summary Contract به `hasSummary` اصلاح شد، بدون تغییر کنترل‌ها. اجرای نهایی:

audit: HOLD-106
independentPeopleScoringRule: PASS

قاعدهٔ ۱۰۷ مستقل `people_scoring=false` است. ۱۰۶ تعداد کنترل‌های غایب همین Fixture/نسخه است؛ امتیاز مهارت Listener یا Speaker نیست.

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

corrected: READY_FOR_LISTENING_CONFIRMATION_REVIEW-0

صفر فقط آمادگی ساختاری را نشان می‌دهد؛ نه Speaker intent، Shared meaning، Requirement truth، Inclusion، Trust، جلوگیری از باگ، Product quality، Outcome یا Decision correctness.

ضدالگوهای گوش دادن فعال در QA

• Listening به‌عنوان درک قطعی نیت.
• تماس چشمی و تکان سر به‌عنوان توجه.
• Camera-off به‌عنوان بی‌علاقگی.
• لحن/چهره به‌عنوان Oracle ابهام.
• سکوت به‌عنوان Agreement.
• قطع‌نکردن به‌عنوان قانون مطلق.
• تکمیل جملهٔ Speaker.
• Paraphrase با Solution افزوده.
• تفسیر Listener به‌عنوان گفتهٔ Speaker.
• سؤال باز به‌عنوان همیشه بهترین.
• چند سؤال در یک جمله.
• Question هدایت‌گر با پاسخ مطلوب.
• Probe ثابت بی‌ارتباط با پاسخ.
• Example واحد به‌عنوان Requirement عمومی.
• Speaker به‌عنوان صدای همهٔ کاربران.
• Confirmation به‌عنوان Requirement approval.
• Summary به‌عنوان Decision.
• Action بدون Owner acceptance.
• عدم پاسخ به‌عنوان تأیید.
• Recording بدون Consent/Retention.
• Transcript خودکار به‌عنوان Verbatim قطعی.
• Quote خارج Source context.
• Unknown به‌عنوان نقص Speaker.
• قدرت/مقام به‌عنوان Truth.
• ترجمهٔ Listener به‌عنوان Source.
• Listening به‌عنوان تضمین Trust/Quality.
• ضریب ۱۰۰ برابر برای ارزش Listening.
• سرزنش فرد پس از Mismatch بدون Repair.
• امتیازدهی eye-contact/question/talk-time.
• AI summary بدون Speaker review.

چک‌لیست Listening Intake Owner

• IntakeID/version/status/review روشن‌اند.
• Purpose/Decision/Channel/Scope/Out-of-scope ثبت‌اند.
• Speaker/Listener/Note/Meaning/Decision roles جدا هستند.
• Affected-absent و Power asymmetry ثبت شده‌اند.
• Consent/Withdrawal/Decline/No retaliation عملی‌اند.
• Language/Interpreter/Caption/Text/Pace/Break/Async آماده‌اند.
• Utterance/Artifact/timestamp/revision/provenance/context قابل‌ردیابی‌اند.
• Attention/interruption/silence policy توافق شده‌اند.
• Nonverbal cue نیت تلقی نشده است.
• Verbatim/Paraphrase/Observation/Inference/Unknown جدا هستند.
• هر Question ID/purpose/type/neutrality دارد.
• یک سؤال در هر نوبت و options/dont-know/refusal معتبرند.
• Follow-up به پاسخ قبلی وصل است.
• Interpretation source/scope/assumption/alternative/confidence دارد.
• Not-claimed ذهن‌خوانی/Requirement approval را رد می‌کند.
• Speaker Confirmed/Disputed/Unanswered/Correction را تعیین کرده است.
• Confirmation expiry/review trigger دارد.
• Summary/Decision/Action/Unknown/Dissent جدا هستند.
• Receipt عدم پاسخ را Agreement نمی‌کند.
• Handoff مقصد/مالک/due/acceptance/trace/reopen دارد.
• Privacy/access/retention/quote/sensitive route روشن‌اند.
• Mismatch repair/reissue/affected artifact review دارد.
• Comprehension/Bias/Access review انجام شده‌اند.
• No mind reading/No body-language oracle صریح‌اند.
• `people_scoring=false` مستقل کنترل شده است.
• NotProof حدود نتیجه را بیان می‌کند.

Pilot سی‌روزه Listening Confirmation

1. روز ۱ تا ۵: یک Intake کم‌خطر انتخاب و Role/Consent/Access/Source را در Shadow ثبت کنید.
2. روز ۶ تا ۱۰: Note types و Question Contract را روی Transcript مصنوعی تمرین کنید.
3. روز ۱۱ تا ۱۵: Interpretation با Assumption/Alternative و Speaker Confirmation خیالی اجرا شود.
4. روز ۱۶ تا ۲۰: Summary/Decision/Action/Unknown را جدا و Handoff Trace بسازید.
5. روز ۲۱ تا ۲۵: Mismatch «may→must» را Repair، reissue و Artifact خیالی را Reopen کنید.
6. روز ۲۶ تا ۳۰: coverage/leading-question/access/reopen Signals را مرور و Continue/Adapt/Stop کنید.

Pilot، مهارت ذاتی فرد، Trust، Requirement truth، جلوگیری از باگ یا Outcome را ثابت نمی‌کند. دادهٔ واقعی حساس وارد تمرین نشود.

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

گوش دادن فعال در QA یک نمایش رفتاری نیست؛ Control loop معناست. Source را نگه دارید، Note type را جدا کنید، سؤال را خنثی و پاسخ‌پذیر بسازید، Interpretation را فرضیه بدانید، و حق Speaker برای اصلاح/رد/Unknown را واقعی کنید. فقط نسخهٔ Confirmed و محدود را تحویل دهید و Mismatch را با Repair ببندید.

پرسش‌های متداول گوش دادن فعال برای تستر

گوش دادن فعال برای تستر چیست؟

فرآیندی برای ثبت Source، جداکردن Observation/Inference، ساخت سؤال روشن‌کننده و گرفتن Confirmation/Dispute از Speaker است. هدف، برداشت قابل‌ردیابی است؛ نه ذهن‌خوانی یا تأیید خودکار Requirement.

بهترین تکنیک شروع Listening چیست؟

Paraphrase محدود: Source را با کلمات خود بازگو، چیزهای Unknown/افزوده را صریح و از Speaker بخواهید بخش درست/غلط/بی‌پاسخ را مشخص کند. Paraphrase بدون Confirmation فقط Interpretation Listener است.

آیا سؤال باز همیشه بهتر از سؤال بسته است؟

خیر. سؤال باز Context می‌آورد؛ بسته Boundary را تأیید می‌کند؛ گزینه‌ای بار پاسخ را کم می‌کند. انتخاب به Purpose/Access وابسته است و `نمی‌دانم/بعداً/پاسخ نمی‌دهم/سایر` باید در صورت اعتبار مجاز باشد.

آیا زبان بدن به کشف نیازمندی پنهان کمک می‌کند؟

ممکن است فقط Prompt یک سؤال اختیاری باشد، نه Evidence نیت یا ابهام. حالت چهره، لحن، سکوت و Camera-off معانی متعدد دارند. Meaning باید با سؤال و Confirmation Speaker بررسی شود.

چگونه Listening به Requirement تبدیل می‌شود؟

Summary تأییدشده با Source/Scope/Unknown/Trace به Requirement owner تحویل می‌شود؛ سپس Authority آن را با Evidence، سایر Stakeholderها و Testability بررسی و نسخهٔ Requirement را تصویب می‌کند. Listening Confirmation خود Approval نیست.