«۹۰٪ تستها پاس شدهاند، سه ریسک مهم داریم و با اطمینان ۹۵٪ پیشنهاد میکنیم انتشار ۴۸ ساعت عقب بیفتد.» این جمله کوتاه و مدیریتی بهنظر میرسد، اما شاید خطرناکتر از گزارش فنی طولانی باشد: ۹۰٪ از چه مخرجی؟ سه ریسک برای کدام Build و Cohort؟ عدد ۹۵٪ از کدام روش آمده؟ تأخیر چه Optionهای دیگری دارد؟ چه کسی Risk را میپذیرد و اگر Evidence دیررس رسید، نتیجه چگونه اصلاح میشود؟
این راهنما برای «گزارش معیارهای تست به ذینفعان»، «گزارش QA برای مدیران»، «ترجمه متریک تست به زبان کسبوکار» و «Executive QA Report» نوشته شده است. خروجی آن یک Dashboard یا گزارش اختتامیه نیست؛ یک Quality Decision Brief یکصفحهای و traceable است که Decision، Claim، Evidence، Unknown، Risk، Option و Authority را بدون قطعیتسازی کاذب منتقل میکند.
پاسخ کوتاه: عدد را ترجمه نکنید؛ تصمیم را طراحی کنید
- مخاطب را با Decision role و سؤالش تعریف کنید، نه برچسب «غیرفنی».
- Artifact/Build/Scope/Window/Cohort را بالای Brief تثبیت کنید.
- هر جملهٔ مهم را به Claim محدود، Evidence reference و Unknown وصل کنید.
- Risk را با Scenario/Exposure/Consequence/Control/Residual/Owner بیان کنید؛ عدد خسارت نسازید.
- حداقل دو Option واقعی را با Benefit، Harm، Evidence need، Trigger و Reversibility مقایسه کنید.
- Recommendation را از Decision و Risk acceptance جدا نگه دارید.
- Plain language، متن جایگزین و progressive disclosure را بدون حذف معنای فنی بهکار ببرید.
- Expiry، review trigger و Correction/Supersession داشته باشید.
این مقاله دقیقاً مالک کدام مسئله است؟
راهنمای Dashboard تست مالک رابط دادهٔ همیشهبهروز است؛ گزارش اختتامیه تست مالک سند رسمی Test Completion و پیوست فنی است؛ و راهنمای کیفیت کافی و انتشار مالک Risk-based Release decision است. مقالهٔ حاضر فقط مالک لایهٔ ارتباطی یک Decision است: چگونه Brief کوتاه بسازیم که به منبع فنی trace شود، Unknown را پنهان نکند و اختیار تصمیم را جابهجا نکند.
«ذینفع غیرفنی» برچسب مفیدی نیست
مدیر مالی ممکن است Risk range را بهتر از Engineer بفهمد؛ Product owner به Cohort و Outcome نیاز دارد؛ حقوقی به Claim boundary و obligation؛ عملیات به Detection/rollback؛ مدیرعامل به Options و authority. مسئله کمبود توان فنی نیست، تفاوت Decision و زمان است. Audience را با role، decision rights، سؤال، deadline، prior knowledge، format و accessibility need تعریف کنید.
Audience–Decision Contract بنویسید
AudienceDecision brief_id: QDB-042-v1 decision: RELEASE | LIMIT | DELAY | STOP | INVESTIGATE decision_deadline: 2026-08-14T09:00:00Z primary_reader_role: product director decision_authority: release owner risk_authorities: payments owner / security owner questions: user exposure, residual harm, reversible options prior_context: Decision D-041 and Risk Register v7 format/accessibility: HTML, RTL, keyboard/table/text alternative feedback_channel: decision-room thread expiry: 2026-08-15T00:00:00Z
Quality Decision Brief Loop
Decision need + Authority → immutable Artifact / Scope / Window → bounded Quality Claims → Evidence + Freshness + Unknowns → Risk / Residual Risk → Options + Trade-offs + Reversibility → Recommendation + Conditions + Confidence basis → Plain-language Brief + Technical Trace → Decision Record + Actions → Verification + Correction / Supersession
این Loop و Contractها سنتز عملی همین مقالهاند، نه استاندارد رسمی GOV.UK، Aqua Book، W3C، ISTQB یا قالب اجباری کسبوکار. عبارت READY_FOR_DECISION_BRIEF_REVIEW در آزمایش فقط آمادگی ساختاری Brief را نشان میدهد.
Brief، Dashboard، Report و Alert یکی نیستند
| Artifact | کار اصلی | زمان | مالک متمایز |
|---|---|---|---|
| Dashboard | وضعیت/Trend/Drill-down | پیوسته | Semantic/data owner |
| Alert | جلب توجه به Signal/threshold | رویدادمحور | Response owner |
| Technical report | Evidence و Method کامل | Milestone/closure | Report author |
| Decision Brief | Options برای یک تصمیم | تا deadline/expiry | Brief owner |
| Decision Record | انتخاب، Authority و تعهد | پس از تصمیم | Decision authority |
یک صفحه یعنی یک لایه، نه یک منبع حقیقت
Brief باید Snapshot مختصر باشد و به Technical report، Risk register، Evidence manifest و Dashboard drill-down لینک دهد. Copy/paste عدد بدون source/version/freshness یک منبع حقیقت دوم میسازد. Brief را از دادهٔ pinned تولید کنید و Trace را حفظ کنید.
Progressive Disclosure بهجای حذف جزئیات
| لایه | محتوا | خواننده |
|---|---|---|
| ۱. Decision strip | سؤال، deadline، Options، authority | همه |
| ۲. Claim/Risk | Evidence، Unknown، residual risk | تصمیمگیر |
| ۳. Option table | Trade-off، condition، reversibility | مالکان |
| ۴. Technical trace | Metric contract، Runs، logs، method | بازبین تخصصی |
| ۵. Decision history | record، actions، correction | ممیزی/یادگیری |
Plain language با Plain meaning فرق دارد
Plain language یعنی جملهٔ کوتاه، فعل فعال، اصطلاح تعریفشده و ساختار scan-friendly؛ نه تبدیل Evidence به وعده. راهنمای رسمی GOV.UK دربارهٔ زبان روشن میگوید حتی مخاطب متخصص نیز باید سریع موضوع را بفهمد. این guidance برای محتوای GOV.UK است؛ این مقاله اصول clarity را اقتباس میکند، نه Style guide سازمان شما یا گواهی accessibility.
ترجمهٔ خوب، معنای فنی را حفظ میکند
| عبارت ضعیف | چرا خطرناک است؟ | عبارت traceable |
|---|---|---|
| ۹۰٪ Pass؛ محصول پایدار است | مخرج/Scope/Unknown غایب | ۹۰ از ۱۰۰ Check واجدشرایط در Build b42 Pass؛ Risk R7 بررسینشده است |
| Coverage ۸۵٪؛ مطمئنیم | Coverage=Confidence فرض شده | ۸۵٪ Branch در component X لمس شد؛ Oracle/field behavior ادعا نمیشود |
| پنج درصد کاربران خطا میبینند | Population/روش نامعلوم | در Cohort مصنوعی ۵/۱۰۰ Attempt failure؛ تعمیم به کاربر واقعی مجاز نیست |
| میلیونها تومان خسارت | عدد ساختگی/false precision | Impact مالی UNKNOWN؛ exposure و range به دادهٔ مالی نیاز دارد |
Technical term را حذف نکنید؛ تعریف کنید
Retry، Cohort، Residual risk یا Inconclusive ممکن است برای تصمیم ضروری باشند. بار اول اصطلاح و معنای عملی را کنار هم بنویسید: «Cohort (گروه واحدهایی که واقعاً در معرض Change بودند)». Glossary کوتاه بهتر از جایگزینی اصطلاح با استعارهٔ گمراهکننده است.
Build، Scope و Window را در Header ثابت کنید
BriefIdentity id/version/as_of: QDB-042-v1 / 2026-08-13T08:00Z product/service: SYN-CHECKOUT / payment-callback artifact: build b42 / commit C42 / deployment none scope: duplicate and late callback decisions out_of_scope: PSP availability, security, accessibility, production traffic population/cohort: synthetic staging attempts / RUN-IRR-042 evidence_window: 2026-08-12T00:00Z..2026-08-13T07:30Z supersedes: QDB-041-v2 owner: quality-evidence lead
Status را از Recommendation جدا کنید
Status توصیف Evidence است؛ Recommendation نظر مشروط Author؛ Decision انتخاب Authority. «سه تست Fail» Status است. «Limit rollout به Cohort داخلی» Recommendation است. «Rollout پنجدرصدی تصویب شد» Decision Record است. ادغام آنها QA را ناخواسته Risk acceptor میکند.
Quality Claim Contract بسازید
QualityClaim id: QC-042 statement: duplicate callbacks do not duplicate ledger entries subject: build b42 / PaymentAttempt state model v7 conditions: staging, stub v3, canonical IRR, 1–8 duplicates population: 120 synthetic attempts measure/threshold: duplicate ledger entry count = 0 evidence_refs: RUN-042 / MANIFEST-042 / ORACLE-17 observed: 0 in 120 eligible attempts unknowns: late callback after reconciliation >24h claim_limit: no production, PSP, security, revenue or all-user claim freshness/expiry: 2026-08-13T07:30Z / build change
Evidence را با Verdict یکی نگیرید
Evidence میگوید چه چیزی تحت چه شرایطی مشاهده شد. Verdict بر Basis/Oracle/threshold تکیه دارد. Claim فراتر از هر دو، دامنهٔ قابلگفتن را تعیین میکند. «۱۲۰ Attempt بدون duplicate» Evidence است؛ «در شرایط Staging تعریفشده QC-۰۴۲ پشتیبانی شد» Verdict محدود؛ «پرداخت امن و پایدار است» ادعای نامعتبر.
Unknown را یک بخش اصلی Brief کنید
| Unknown | چرا نامعلوم است؟ | اثر بر تصمیم | Evidence/Owner/Due |
|---|---|---|---|
| Callback پس از ۲۴ ساعت | Window بسته نشده | Scale محدود | soak run / QA / فردا |
| PSP واقعی | Stub-only | Production claim ممنوع | canary / operations |
| Impact مالی | Exposure/finance data غایب | Range ارائه نمیشود | finance analyst |
| Accessibility | در Scope نبود | Sign-off جدا | specialist review |
Unknown با Failure فرق دارد و نباید صفر، Pass یا «ریسک کم» شود. Not tested، Not applicable، Inconclusive، Data stale و Out of scope وضعیتهای مستقلاند.
Uncertainty را پنهان نکنید
Aqua Book دولت بریتانیا تأکید میکند uncertainty در تحلیل و تصمیم واقعی ذاتی است، best estimate معمولاً کافی نیست و دامنه/علت uncertainty باید به تصمیمگیر منتقل شود. این منبع برای تحلیل دولتی است؛ ما اصل شفافیت uncertainty را اقتباس میکنیم، نه روش رسمی ارزیابی یا تضمین تصمیم نرمافزاری.
عدد Confidence را بدون Method نسازید
«اطمینان ۹۵٪ محصول پایدار است» ممکن است Confidence interval، test pass ratio، نظر Expert یا عدد تزئینی باشد. اگر Method آماری معتبر ندارید، درصد ندهید. Confidence کیفی نیز Basis میخواهد: coverage scope، evidence consistency، data quality، unknowns، alternatives و dissent. Confidence دربارهٔ Claim است، نه کل Product.
Range، Scenario و Assumption را کنار هم بنویسید
| نوع | مثال | باید همراه باشد |
|---|---|---|
| Observed range | ۴۰–۷۰ ms در Lab | population/window/device |
| Estimate range | ۲–۵ ساعت repair | method/assumptions/owner |
| Scenario range | low/base/high exposure | trigger/probability caveat |
| Unknown | Impact مالی نامعلوم | evidence plan/deadline |
Risk را از Defect count استخراج نکنید
DecisionRisk id: R-042 scenario: late success callback after reconciliation exposed_asset/journey: ledger accuracy / refund handling population/exposure: UNKNOWN outside 24h synthetic window consequence: duplicate or missing financial state evidence: F-17 design gap; no field evidence existing_controls: idempotency key / reconciliation job control_limitations: late-window behavior unverified likelihood: not estimated impact_range: domain review required; no monetary claim residual_risk: OPEN owner/authority: payments owner next_evidence/due: 48h soak / 2026-08-15
Severity/Priority/Count با Risk برابر نیست. Scenario، exposure، consequence، controls، residual و authority لازم است. «اعتبار برند آسیب میبیند» یا «میلیونها تومان ضرر» بدون Evidence فقط rhetoric است.
Risk زبان مشترک است، اما نباید ساختگی شود
ترجمهٔ technical concern به business consequence مفید است اگر chain روشن باشد: Condition→Failure mode→User/business consequence→Evidence→Uncertainty. اگر Link ناشناخته است، همان را بگویید. داستان خوب جای مدل Exposure و Domain review را نمیگیرد.
Options را پیش از Recommendation بنویسید
| Option | Benefit | Risk/Harm | Evidence need | Reversibility |
|---|---|---|---|---|
| Delay 48h | soak window کامل | campaign/cost نامعلوم | RUN-SOAK-43 | بالا |
| Internal only | field-like observation | exposure محدود | monitor/stop rule | بالا |
| 5% canary | real cohort evidence | real-user harm ممکن | authority/rollback | متوسط |
| Full release | deadline حفظ | R-۰۴۲ باز | risk acceptance | وابسته به state |
| Stop feature | risk حذف | outcome از دست میرود | fallback verification | متوسط |
Option Contract قابلکپی
Option id: OPT-INTERNAL-ONLY action/scope: enable for internal cohort, build b42 intended_benefit: obtain late-callback evidence without customer exposure known_risks: internal ledger cleanup; evidence may not generalize unknowns: PSP/traffic/user behavior prerequisites: monitor, owner, rollback rehearsal stop_trigger: duplicate ledger entry or reconciliation mismatch rollback/state: flag off + reconcile synthetic records evidence_after: 48h soak manifest cost/range: owner estimate pending authority: release owner + payments owner expiry: 2026-08-15T09:00Z
Recommendation باید مشروط و منقضیشونده باشد
«پیشنهاد: Internal-only تا تکمیل ۴۸h soak، مشروط به monitor/rollback و با بازبینی فردا» بهتر از «عرضه را عقب بیندازید» است. Basis، considered options، conditions، guardrails، expiry، dissent و author را ثبت کنید. Recommendation اختیار Risk owner را تصاحب نمیکند.
Decision Record حلقه را میبندد
DecisionRecord id: D-042 brief/version: QDB-042-v1 selected_option: OPT-INTERNAL-ONLY rejected_options/reasons: full release—R-042 open; delay—deadline cost unknown accepted_residual_risks: internal synthetic cleanup only authorities: release owner / payments owner conditions: monitor + rollback rehearsal + 48h soak actions/owners/due: enable / platform / 09:30Z verification: evidence manifest MAN-043 review/expiry: 2026-08-15T09:00Z dissent: security scope not reviewed; no security sign-off implied correction_ref: pending
QA Author با Risk Acceptor یکی نیست
| Role | اختیار | نباید |
|---|---|---|
| Brief author | Claim/Evidence/Unknown را خلاصه کند | Risk را بپذیرد |
| Metric steward | Definition/lineage/freshness | Outcome را تضمین کند |
| Domain owner | Consequence/control را ارزیابی کند | Evidence را بازنویسی کند |
| Release owner | Option را انتخاب کند | Specialist sign-off جعل کند |
| Specialist authority | امنیت/حریم/دسترسپذیری/ایمنی | خارج از scope تضمین دهد |
Dissent و Minority View را حفظ کنید
Consensus اجباری Unknown را پنهان میکند. اگر Security reviewer میگوید Evidence کافی نیست یا Finance range را تأیید نمیکند، view، basis، scope و effect on decision را ثبت کنید. Dissent با veto یا conflict شخصی یکی نیست؛ یک Evidence artifact است.
ادعای «آماده برای انتشار» را درصدی نکنید
Release readiness یک درصد طبیعی مثل ۷۸٪ نیست مگر مدل، اجزا، وزنها و validation داشته باشد؛ حتی آنگاه جمع امتیاز میتواند Harm critical را پنهان کند. Criteria را Met/Not met/Not evaluated، Riskها را جدا و Optionها را مشروط نشان دهید. Decision نهایی در مقالهٔ کیفیت کافی تعریف میشود.
Pass Rate را به Confidence تبدیل نکنید
۹۰٪ Pass ممکن است ۱۰ Failure critical یا ۱۰ Check کماهمیت باشد؛ Retry/Skipped/Blocked/Untested را نیز پنهان کند. Pass ratio فقط با Metric contract، risk/requirement trace و Unknown معنا دارد. راهنمای متریکهای تست فرمول و guardrailها را پوشش میدهد.
Trend را به داستان دلخواه تبدیل نکنید
کاهش Bug count ممکن است Scope کمتر یا Detection ضعیفتر باشد. قبل از Brief، Signal/Data-quality/Control-limit semantics را در تحلیل روند معیارهای تست بررسی کنید. Brief باید نتیجهٔ Analysis را با limitation منتقل کند، نه arrow سبز را به Improvement تبدیل کند.
Outcome کسبوکار را به QA نسبت ندهید
Conversion، Revenue، Churn، NPS و Brand outcomeهای مشترک و پرعاملاند. اگر Brief دربارهٔ contribution یک Intervention است، Theory/alternatives/confidence را از QA Contribution Evaluation بیاورید. «تست باعث افزایش فروش شد» بدون design معتبر حذف شود.
داستانسرایی باید Synthetic بودن را فریاد بزند
Case study ساختگی را با «نمونهٔ فرضی» برچسب بزنید و Company/percentage/loss/Outcome واقعی جعل نکنید. Story باید Claim boundary را روشن کند، نه با جزئیات سینمایی جای Evidence را بگیرد. مقالهٔ قدیمیِ «فینتک، ۳۰٪ کاربر و میلیونها تومان خسارت» منبع نداشت و حذف شد.
«راهحلمحور» به معنی سانسور خبر بد نیست
گاهی Evidence فقط میگوید Stop/Investigate و هنوز راهحل تأییدشده نداریم. افزودن Solution ساختگی برای «وحشتنکردن مدیریت» خطرناک است. خبر بد را زود، مستقیم، با Scope/Unknown/Owner و Optionهای واقعی بگویید؛ tone آرام جای Severity و urgency را تغییر ندهد.
Urgency و Severity را جدا کنید
| Dimension | پرسش | مثال |
|---|---|---|
| Severity/Consequence | اگر رخ دهد چه میشود؟ | ledger mismatch |
| Exposure | چه جمعیتی در معرض است؟ | internal only/unknown |
| Urgency | تا چه زمانی تصمیم لازم است؟ | campaign cutoff |
| Detectability | چقدر سریع میفهمیم؟ | reconciliation alert |
| Reversibility | بازگشت code/state چقدر ممکن است؟ | flag + cleanup |
| Confidence | Evidence چقدر Claim را پشتیبانی میکند؟ | moderate, scoped |
Visual را برای سؤال انتخاب کنید
| سؤال | View مناسب | هشدار |
|---|---|---|
| چه Optionهایی داریم؟ | comparison table | وزن پنهان نکنید |
| چه چیزی در زمان عوض شد؟ | time series + annotations | دو نقطه/dual axis |
| ریسک کجاست؟ | ranked scenario table | رنگ تنها/heatmap false precision |
| چه چیزی unknown است؟ | explicit gap table | blank=zero |
| Evidence چگونه trace میشود؟ | table/link/tree | infographic بدون text alt |
رنگ تنها حامل معنا نیست
تکنیک رسمی W3C WAI دربارهٔ رنگ و Pattern میگوید وقتی تفاوت رنگ معنا میرساند، Pattern یا نشانهٔ دیگری نیز لازم است. در Brief، GREEN/RED را با متن status، icon/shape، label و جدول داده همراه کنید. این یک technique مرتبط با WCAG است؛ انطباق کامل accessibility به بررسی همهٔ معیارهای قابلاعمال نیاز دارد.
Chart باید Text Alternative و Data Table داشته باشد
Alt کوتاه purpose/insight را میگوید؛ long description یا جدول، values/relationships لازم را میدهد. Screenshot از Dashboard بدون heading، table و source برای screen reader و چاپ مناسب نیست. RTL، tab order، contrast، Persian digits، copy/paste و mobile zoom را آزمایش کنید.
عدد فارسی و انگلیسی را با Stable ID همراه کنید
نمایش ۱۲۳/۱۲۳، ممیز فارسی/لاتین، درصد، IRR/تومان و تاریخ جلالی/میلادی میتواند ambiguity بسازد. Storage را canonical نگه دارید؛ label واحد را بنویسید؛ timestamp UTC و timezone نمایشی را مشخص کنید؛ Risk/Claim/Option ID را لاتین و copy-safe نگه دارید.
Cadence را با Decision و Freshness تنظیم کنید
پایان Sprint، هفتگی یا ماهانه نسخهٔ جهانی نیست. Brief وقتی تولید میشود که Decision need، material signal یا expiry وجود دارد. Dashboard cadence جداست. هر Brief `as_of`، evidence freshness، decision deadline و next review دارد؛ نسخهٔ stale باید علامت واضح و suppression policy داشته باشد.
Pre-read، جلسه و Async را تفکیک کنید
| کانال | کار | نباید |
|---|---|---|
| Pre-read | Claim/Evidence/Options و سؤالها | Decision پنهان در ۴۰ اسلاید |
| Async thread | clarification/dissent/source links | Risk acceptance مبهم |
| Decision meeting | trade-off و انتخاب authority | خواندن Dashboard |
| Decision record | option/conditions/actions/expiry | صورتجلسهٔ بدون owner |
| Update | verification/correction | silent edit |
Question Log از جلسهٔ نمایشی جلوگیری میکند
هر سؤال Decision-relevant با asker role، claim/risk ref، answer/evidence، status، owner و due ثبت شود. «بعداً بررسی میکنیم» بدون owner یک Unknown حلنشده است. Question log همچنین نشان میدهد Brief برای مخاطب قابلفهم بوده یا واژه/ساختار باید اصلاح شود.
Comprehension را تست کنید
- خواننده Decision، Options و Authority را درست بازگو میکند؟
- Claim limit و Unknown را با «No issue» اشتباه نمیگیرد؟
- Risk scenario را بدون اغراق مالی/اعتباری میفهمد؟
- Recommendation را Decision نهایی تلقی نمیکند؟
- با keyboard/screen reader/mobile/print به Trace میرسد؟
Brief Quality Metrics خودِ ارتباط را میسنجند
| Measure | تعریف | Countermetric |
|---|---|---|
| Decision latency | ready brief→recorded decision | premature decision |
| Clarification rate | material questions/brief | silent misunderstanding |
| Trace success | sample claims resolved to evidence | link overload |
| Unknown closure | due unknowns closed/corrected | rushed false closure |
| Correction rate | material corrected briefs | hidden non-correction |
| Comprehension | task-based reader test | memorization only |
Trust هدف مستقیم Brief نیست
شفافیت ممکن است Trust را حفظ یا حتی موقتاً کاهش دهد؛ Trust به history، competence، integrity، outcome و Context وابسته است. Brief خوب وعدهٔ اعتماد، همکاری، موفقیت پروژه یا جلوگیری از غافلگیری نمیدهد. راهنمای تست و اعتماد مشتری این Attribution chain را جدا بررسی میکند.
Security، Privacy و Need-to-know
Executive Brief ممکن است vulnerability، incident، customer cohort، financial exposure یا employee data را گستردهتر از Technical report پخش کند. Classification، audience access، redaction، secure link، expiry، download/export audit و retention لازم است. «ساده و مدیریتی» مجوز disclosure نیست.
AI در Brief: Draft، نه Authority
AI میتواند plain-language draft، glossary، option-table skeleton، consistency check و text alternative پیشنهاد دهد. Source refs، prompt/model/version، sensitive-data control و human verification لازم است. مدل نباید Confidence percentage، financial impact، Risk acceptance، Recommendation یا Decision را خودکار بسازد؛ hallucinated certainty در Summary خطرناکتر از متن فنی است.
Correction و Supersession برای Brief
BriefCorrection id: COR-QDB-042 brief/decision: QDB-042-v1 / D-042 trigger: late callback evidence changed Risk R-042 old/new: residual OPEN / CONTROL_FAILED affected_claims/options: QC-042 / OPT-INTERNAL-ONLY decision_effect: suspend option and investigate corrected_by/at: evidence lead / 2026-08-14T07:00Z notified: release owner / payments owner / operations supersedes: QDB-042-v1; raw evidence retained verification: new decision D-043 required
عدد یا جمله را silently عوض نکنید. Correction باید Evidence جدید، Claim/Risk/Option/Decision متاثر، notification و نسخهٔ جایگزین را ثبت کند. اگر Decision قبلی دیگر معتبر نیست، Authority باید Record تازه بسازد.
آزمایش تکرارپذیر: Brief کوتاه، قرارداد خالی
Fixture مصنوعی زیر ۹۰٪ Pass، سه Risk، Confidence ۹۵% و Delay 48h دارد و EXECUTIVE_READY اعلام میکند. Auditor زیبایی Summary را نمیسنجد؛ Identity، Decision، Claim، Evidence، Unknown، Risk، Options، Authority و Correction را بررسی میکند.
{
"brief_id": "",
"identity": {"product": "", "build": "", "scope": "", "window": "", "as_of": "", "expiry": ""},
"audience": {"decision": "", "deadline": "", "primary_role": "", "accessibility": ""},
"claims": [{"id": "QC1", "statement": "", "conditions": "", "measure": "", "threshold": "", "evidence_refs": [], "claim_limit": ""}],
"evidence": {"manifest": "", "freshness": "", "data_quality": ""},
"unknowns": [],
"risks": [{"id": "R1", "scenario": "", "exposure": "", "consequence": "", "controls": "", "residual": "", "owner": ""}],
"options": [{"id": "O1", "action": "delay 48h", "benefit": "", "risks": "", "conditions": "", "stop": "", "rollback": ""}],
"recommendation": {"option_ref": "O1", "basis": [], "conditions": [], "expiry": "", "author": ""},
"authorities": {"decision_owner": "", "risk_owner": ""},
"decision_record": {"status": "", "selected_option": "", "actions": [], "review": ""},
"correction": {"trigger": "", "method": ""},
"dashboard": {"pass_percent": 90, "risk_count": 3, "confidence_percent": 95, "suggested_delay_hours": 48},
"declared": "EXECUTIVE_READY"
}
const fs = require('node:fs');
const r = JSON.parse(fs.readFileSync(process.argv[2], 'utf8'));
const f = [];
const need = (ok, rule, path) => { if (!ok) f.push({ rule, path }); };
need(r.brief_id, 'IDENTITY', 'brief_id');
for (const key of ['product', 'build', 'scope', 'window', 'as_of', 'expiry'])
need(r.identity?.[key], 'ARTIFACT_SCOPE', `identity.${key}`);
for (const key of ['decision', 'deadline', 'primary_role', 'accessibility'])
need(r.audience?.[key], 'AUDIENCE_DECISION', `audience.${key}`);
for (const [i, c] of (r.claims || []).entries())
for (const key of ['statement', 'conditions', 'measure', 'threshold', 'claim_limit'])
need(c[key], 'CLAIM_CONTRACT', `claims[${i}].${key}`);
for (const [i, c] of (r.claims || []).entries())
need((c.evidence_refs || []).length, 'CLAIM_EVIDENCE', `claims[${i}].evidence_refs`);
for (const key of ['manifest', 'freshness', 'data_quality'])
need(r.evidence?.[key], 'EVIDENCE', `evidence.${key}`);
need((r.unknowns || []).length, 'UNKNOWN', 'unknowns');
for (const [i, x] of (r.risks || []).entries())
for (const key of ['scenario', 'exposure', 'consequence', 'controls', 'residual', 'owner'])
need(x[key], 'RISK_CONTRACT', `risks[${i}].${key}`);
for (const [i, o] of (r.options || []).entries())
for (const key of ['benefit', 'risks', 'conditions', 'stop', 'rollback'])
need(o[key], 'OPTION_CONTRACT', `options[${i}].${key}`);
need((r.options || []).length >= 2, 'OPTION_SET', 'options');
need(r.recommendation?.option_ref, 'RECOMMENDATION', 'recommendation.option_ref');
need((r.recommendation?.basis || []).length, 'RECOMMENDATION', 'recommendation.basis');
need((r.recommendation?.conditions || []).length, 'RECOMMENDATION', 'recommendation.conditions');
for (const key of ['expiry', 'author'])
need(r.recommendation?.[key], 'RECOMMENDATION', `recommendation.${key}`);
for (const key of ['decision_owner', 'risk_owner'])
need(r.authorities?.[key], 'AUTHORITY', `authorities.${key}`);
for (const key of ['status', 'selected_option', 'review'])
need(r.decision_record?.[key], 'DECISION_RECORD', `decision_record.${key}`);
need((r.decision_record?.actions || []).length, 'DECISION_RECORD', 'decision_record.actions');
for (const key of ['trigger', 'method'])
need(r.correction?.[key], 'CORRECTION', `correction.${key}`);
const computed = f.length ? 'HOLD' : 'READY_FOR_DECISION_BRIEF_REVIEW';
if (r.declared !== computed) f.push({ rule: 'DECISION_MISMATCH', path: 'declared' });
console.log(JSON.stringify({ computed, count: f.length, findings: f }, null, 2));
process.exitCode = f.length ? 2 : 0;
نسخهٔ ناقص باید HOLD و ۴۶ Finding بدهد: Brief ID، شش Identity، چهار Audience/decision، شش Claim/evidence، سه Evidence، Unknown، شش Risk، پنج Option و کمبود Option دوم، چهار Recommendation، دو Authority، چهار Decision record، دو Correction و Decision mismatch. درصدها هیچ Finding را نمیبندند.
پس از تکمیل دو Option، Claim/Evidence/Unknown/Risk، Recommendation مشروط، Authority، Decision Record و Correction، اجرای دوباره باید count=۰ و READY_FOR_DECISION_BRIEF_REVIEW بدهد. این فقط کاملبودن ساختار را میسنجد؛ Truth داده، کفایت Evidence، Risk، Confidence، Release readiness یا درستی Decision را اثبات نمیکند.
نمونهٔ فارسی و آفلاین: Brief ساختگی Checkout
Brief آموزشی را برای SYN-CHECKOUT بسازید: Order، PaymentAttempt، PSP Stub، Callback، Ledger و Reconciliation همگی fake؛ Build b42؛ duplicate/late/out-of-order Callback؛ Timeout پیش/پس از commit و Rollback. IRR را canonical و تومان را فقط presentation label نگه دارید. Range یا درصد فقط از Dataset مصنوعی و با برچسب روشن بیاید.
رقم فارسی/عربی/لاتین، ی/ی، ک/ک، RTL/LTR، UTC canonical، Asia/Tehran display و جلالی صرفاً نمایشی را تست کنید. هیچ Network، Production، شرکت/کاربر/سفارش/پرداخت/PSP/بانک واقعی، نام، موبایل، ایمیل، IP، account، PAN/CVV2/OTP، Cookie، Token، Credential، Log یا Screenshot استفاده نشود. نمونه ادعای بانکی، مالی، قانونی، امنیتی، بازار ایران یا خسارت واقعی ندارد.
Pilot سیروزهٔ Quality Decision Brief
| روز | کار | خروجی | Stop/Review |
|---|---|---|---|
| ۱–۳ | Decision/audience/authority | Audience contract | بدون owner توقف |
| ۴–۷ | Identity/scope/trace | Brief skeleton | Source مبهم |
| ۸–۱۲ | Claim/evidence/unknown | bounded claims | confidence ساختگی |
| ۱۳–۱۶ | Risk/options | trade-off table | فقط یک Option |
| ۱۷–۲۰ | Plain language/accessibility | HTML pre-read | color-only/meaning loss |
| ۲۱–۲۴ | Comprehension test | reader findings | Recommendation=Decision confusion |
| ۲۵–۲۷ | Shadow decision | record/actions | authority bypass |
| ۲۸–۳۰ | Verification/correction | adopt/adapt/stop | silent update |
Anti-patternهای ارتباط معیار تست
| Anti-pattern | خطر | اصلاح |
|---|---|---|
| ۹۵٪ confidence ساختگی | false precision | method/basis/unknown |
| RAG=ready | risk پنهان | text/criteria/options |
| Pass=stable | scope/oracle gap | claim contract |
| خسارت خیالی | رعب/اعتماد کاذب | UNKNOWN/range owner |
| Case study بیمنبع | اطلاعات جعلی | synthetic label |
| «غیرفنی»=سادهلوح | نیاز تصمیم نادیده | role/question contract |
| یک Option | Recommendation تحمیلی | real alternatives |
| راهحلمحوری اجباری | خبر بد سانسور | honest unknown/next step |
| QA=Risk acceptor | authority drift | role separation |
| Brief بدون Correction | تصمیم stale | expiry/supersession |
چکلیست Brief owner
- Brief ID/version/as-of/expiry و owner ثبت شده است.
- Decision، deadline، authority و reader roles روشناند.
- Build/commit/scope/out-of-scope/window/cohort pinned است.
- Status، Recommendation و Decision جدا هستند.
- هر Claim شرایط، Measure، Threshold و limit دارد.
- Evidence refs، freshness، data quality و manifest موجود است.
- Unknown/Not evaluated/Inconclusive صریحاند.
- Confidence درصدی بدون Method حذف شده است.
- Risk scenario/exposure/consequence/control/residual/owner دارد.
- حداقل دو Option واقعی با trade-off مقایسه شدهاند.
- Stop/rollback/reversibility و evidence-after تعریف شده است.
- Recommendation Basis/condition/expiry/dissent دارد.
- Risk acceptance فقط توسط Authority ثبت میشود.
- Plain language معنای فنی را حذف نکرده است.
- رنگ تنها حامل status نیست و text/table جایگزین وجود دارد.
- RTL/digits/unit/timezone/accessibility تست شدهاند.
- Synthetic example بهوضوح برچسب خورده است.
- Sensitive data با need-to-know و retention کنترل شده است.
- Decision/actions/owners/due/verification ثبت شدهاند.
- Correction/supersession/notification مسیر دارد.
جمعبندی: سادگی بدون قطع معنا
گزارش خوب برای مدیران، گزارش کمجزئیات یا پررنگ نیست. Brief خوب یک Decision artifact است: Scope ثابت، Claim محدود، Evidence قابلردیابی، Unknown آشکار، Risk بدون اغراق، Optionهای واقعی، Recommendation مشروط و Authority روشن. کوتاهی از ساختار و layering میآید، نه حذف uncertainty.
عدد فنی را به وعدهٔ کسبوکار ترجمه نکنید. نشان دهید عدد دقیقاً چه میگوید، چه نمیگوید، کدام Optionها را پشتیبانی میکند و چه Evidence بعدی لازم است. سپس Decision را ثبت، Action را verify و Brief stale را correct کنید.
پرسشهای متداول درباره گزارش QA به مدیران
مدیران به کدام معیار تست اهمیت میدهند؟
پاسخ به role و Decision بستگی دارد، نه عنوان «مدیر». Release owner به residual risk و Options، Product به cohort/outcome، Finance به range/assumption و Operations به detection/rollback نیاز دارد. از Decision Question شروع و فقط Metricهای لازم را با Contract ارائه کنید.
آیا باید جزئیات فنی را از گزارش مدیریتی حذف کنیم؟
خیر؛ آنها را لایهبندی کنید. Brief یکصفحهای Claim/Evidence/Unknown/Options را دارد و Technical trace جزئیات Build، Metric، Run و Method را نگه میدارد. هر جملهٔ تصمیمساز باید به منبع فنی قابلدسترسی برای بازبین مجاز وصل باشد.
چگونه نتایج نگرانکننده را بدون ایجاد وحشت منتقل کنیم؟
زود، مستقیم و محدود به Evidence بگویید: Scenario، Scope، Exposure/Unknown، Consequence، Controls، Options، owner و deadline. Severity را نرم نکنید و راهحل ساختگی نسازید. Tone آرام، Plain language و Action روشن با سانسور خبر بد فرق دارد.
آیا RAG و درصد Release Readiness کافی است؟
خیر. رنگ بهتنهایی accessible یا معنایی نیست و درصد readiness میتواند Risk critical را پشت وزنها پنهان کند. Criteria status، Unknown، residual risk، Options و Authority را متنی نشان دهید؛ اگر Score دارید، مدل/وزن/validation/limit آن را نیز افشا کنید.
هر چند وقت یکبار گزارش معیارهای تست ارائه شود؟
Cadence ثابت Sprint/هفتگی/ماهانه پاسخ عمومی نیست. Brief را برای Decision need، material signal، milestone یا expiry تولید کنید؛ Dashboard وضعیت پیوسته را میدهد. `as_of`، freshness، deadline و review trigger مشخص میکند نسخه تا چه زمانی معتبر است.
