اسلاید اول میگوید «Pass rate: ۷۵%» و چراغ سبز است. مدیر Release میپرسد: «پس آمادهایم؟» اما همان Snapshot شامل دو Blocked، دو Not run و سه سناریوی High-risk است که هیچکدام Pass نشدهاند. عدد غلط نیست؛ عنوان، denominator و چیزی که حذف شدهاند تصمیم را گمراه میکنند. ارائهٔ نتایج تست یعنی حفظ قابلیت حسابرسی هنگام کوتاهکردن پیام—نه زیباترکردن نتیجه یا گفتن حقیقتهای متفاوت به هر مخاطب.
جریان این راهنما چنین است: Decision → Audience task/authority → Claim → Evidence/Uncertainty → Visual و Accessible view → Discussion → Decision/Actions → Correction/Archive. همهٔ Viewها باید از یک Evidence Packet نسخهدار ساخته شوند و Drill-down به منبع داشته باشند.
پاسخ کوتاه: نتایج تست را چگونه ارائه کنیم؟
- پیش از Slide، Decision، deadline و صاحب اختیار را بنویسید.
- نوع Artifact را مشخص کنید: Progress، Completion، Release readout، Defect detail یا Experiment result.
- Snapshot identity، Test basis، Scope/Non-scope و داده/محیط را ثابت کنید.
- Claim را از Fact، Interpretation، Recommendation و Decision جدا برچسب بزنید.
- هر عدد را با numerator، denominator، status policy، window، source و freshness بیاورید.
- Fail، Blocked، Not run، Inconclusive، Missing و Unknown را پشت Pass rate پنهان نکنید.
- اثر، uncertainty و limitation را برای مدیر حذف نکنید؛ آنها را ساده و قابل Drill-down کنید.
- نمودار را بر اساس سؤال انتخاب کنید و متن/جدول معادل، contrast و ترتیب خواندن بدهید.
- توصیه را با Option، Trade-off، owner، trigger و expiry بنویسید؛ QA تصمیم دیگران را جعل نکند.
- در پایان Decision/Action/Dissent را ثبت، خطا را اصلاح و Snapshot را بایگانی کنید.
Intent جستوجو و مرز این مقاله
Intent اصلی کاربردی است: «چگونه نتایج تست نرمافزار را برای توسعهدهنده، مدیر محصول و مدیر ارشد قابلفهم و تصمیمپذیر ارائه کنیم؟» کلیدواژهٔ اصلی ارائه نتایج تست است. عبارتهای مکمل شامل گزارش نتایج تست نرمافزار، ارائه گزارش QA، Test Results Presentation، خلاصه مدیریتی تست، داشبورد QA، گزارش تست برای مدیر محصول، گزارش تست برای مدیر ارشد، نمایش Pass Rate، نمودار نتایج تست، ارائه ریسک انتشار، گزارش A/B تست، داستانسرایی داده در QA، گزارش دسترسپذیر تست و قالب Test Readout هستند.
این صفحه Template منبع گزارش را دوباره اختراع نمیکند. راهنمای گزارش تست تصمیممحور مالک Progress/Completion/Release/Dashboard truth model است و قالب گزارش اختتامیه تست Completion Report رسمی را پوشش میدهد. این مقاله مالک طراحی Readout چندلایه از همان Truth model، انتخاب View/Visual، جلسهٔ ارائه و ثبت مصرف تصمیم است.
ارائه، گزارش، داشبورد و گزارش باگ یکی نیستند
ISTQB CTFL 4.0.1 در چارچوب خود Test progress report را از Test completion report جدا میکند و محتوا را وابسته به پروژه و مخاطب میداند. این Syllabus یک قالب اجباری جهانی، استاندارد آماری یا اختیار Release ایجاد نمیکند؛ برای اصطلاح و نقطهٔ شروع مفید است.
| Artifact | سؤال اصلی | زمان | Detail مرجع | خطر جایگزینی |
|---|---|---|---|---|
| Progress report | کجا هستیم و چه مانعی داریم؟ | دورهای | Plan/snapshot/blocker | تبدیل Forecast به Promise |
| Completion report | چه شد و چه باقی ماند؟ | پایان/stop/cancel | Scope/results/deviation/risk | ادعای تضمین کیفیت |
| Release readout | برای تصمیم مشخص چه Evidence داریم؟ | پیش Decision | risk/criteria/options | QA بهجای صاحب اختیار تصمیم بگیرد |
| Dashboard | وضعیت فعلی/روند چیست؟ | پیوسته | metric dictionary/source | Snapshot/definition متغیر |
| Defect report | این مشاهده چگونه بازتولید/بررسی شود؟ | رویدادمحور | Repro/oracle/environment | جایگزین Risk/Release report شود |
| Experiment readout | Design و estimate چه میگویند؟ | طبق plan | hypothesis/unit/metrics/analysis | «برنده» بدون trust checks |
| Incident update | اثر، containment و next update چیست؟ | Urgent cadence | incident log | RCA زودرس و blame |
اگر مقصد یک Defect قابلبازتولید است، جزئیات را به گزارش باگ حرفهای لینک کنید؛ Slide نباید تنها محل log، screenshot یا evidence باشد. اگر مقصد تصمیم Release است، Readout باید Risk/Unknown/criteria و صاحب تصمیم را نشان دهد؛ فهرست باگ بهتنهایی کافی نیست.
اول Decision را بنویسید، بعد Audience را
«برای CEO» یا «برای Developer» هنوز نیاز اطلاعاتی نیست. یک فرد ممکن است امروز Debugger باشد، فردا Risk acceptor و هفتهٔ بعد Budget owner. بهجای stereotype نقش، Task و Authority را مشخص کنید: Diagnose، Prioritize، Plan، Accept risk، Fund، Audit، Operate یا Learn.
Readout Contract
Decision / decision owner / deadline / default
Audience tasks and authorities, not job-title assumptions
Artifact type and source-of-truth link
Snapshot ID / build / environment / data / window
Scope / non-scope / not evaluated
Claims / evidence / uncertainty / unknowns
Required options, thresholds and hard guardrails
View layers and drill-down path
Accessibility, language, privacy and retention needs
Discussion questions / decision-record destination
Correction owner / review / expiry| Audience task | بالای View | Drill-down لازم | چیزی که حذف نمیشود |
|---|---|---|---|
| Diagnose/fix | observed/expected + repro confidence | log/trace/build/data/oracle | privacy و affected scope |
| Prioritize | impact/population/severity evidence | risk statement + alternatives | uncertainty و counterevidence |
| Plan delivery | scope/progress/blocker/forecast range | work items/dependencies/capacity | Not run و assumption |
| Release decision | criteria/residual risk/options | evidence packet/monitor/rollback | Unknown و authority |
| Operate | guardrail/threshold/owner | dashboard/runbook/alert evidence | baseline و false signal |
| Fund | problem/options/cost range/outcome hypothesis | TCO/pilot/evidence plan | attribution/opportunity cost |
| Audit/compliance | obligation/control/evidence identity | source/version/retention/exception | applicability owner |
یک مدیر ممکن است وقت کم داشته باشد، اما وقت کم مجوز حذف denominator یا limitation نیست. Layer ۱ میتواند یک Decision Card یکدقیقهای باشد؛ Layer ۲ جدول Risk/criteria و Layer ۳ شواهد فنی. همه از یک Snapshot و تعریف میآیند.
Evidence Packet واحد؛ Viewهای متعدد
برای هر مخاطب Dataset تازه، Definition تازه یا رنگ تازه نسازید. Packet immutable یا دستکم versioned باشد و View فقط انتخاب/ترتیب/توضیح را تغییر دهد. اگر مدیر Summary را باز کند باید بتواند به همان Defect، Result، metric definition و raw evidence مجاز برسد که تیم فنی میبیند؛ دسترسی ممکن است بر اساس Privacy محدود شود، اما معنی نباید عوض شود.
Test Evidence Packet
Report ID / revision / generated-at / author-reviewer
Decision context and artifact type
Product / release / build / commit / config
Test basis and risk/requirement versions
Environment / dependencies / data / locale / time
Planned, changed, executed and excluded scope
Status taxonomy and closed accounting
Metric dictionary: formula / unit / denominator / window / source
Results / failures / blocked / not-run / inconclusive / missing
Coverage by risk/requirement, not only test count
Defects / deviations / criteria / residual risks
Uncertainty / limitations / contradictory evidence
Recommendation / options / decision authority
Evidence links / access / retention / expiry / correctionsClaim را از Fact، تفسیر و تصمیم جدا کنید
| لایه | نمونه | صاحب/مرز |
|---|---|---|
| Fact/Observation | در build 6f2، ۶ Pass، ۲ Fail، ۲ Blocked و ۲ Not run ثبت شد | source/version/oracle لازم |
| Derived metric | ۶/۸ از موارد اجراشده Pass است | formula/denominator/status policy |
| Interpretation | Evidence مسیرهای High-risk ناکافی است | reasoning و alternate explanation |
| Risk claim | در timeout-after-commit احتمال اثر مالی تکراری نامعلوم است | condition-event-impact + uncertainty |
| Recommendation | payment refactor پشت Flag بماند تا Evidence تکمیل شود | QA/analyst؛ نه Decision نهایی |
| Decision | Promotion منتشر، refactor deferred | named authority + rationale |
| Action | Backend تا ۱۶:۳۰ duplicate callback را اصلاح/بازبینی کند | owner/capacity/due/definition |
| Outcome | پس از rollout چه رخ داد؟ | monitoring؛ نه اعتبار پسینی همهٔ Claimها |
«دادهها میگویند Release نکنید» Agency و Authority را پنهان میکند. داده Observation است؛ انسان با معیار، عدمقطعیت و مسئولیت تصمیم میگیرد. برعکس، «این فقط نظر QA است» نیز Evidence را بیاعتبار نمیکند. Claim، Source و Decision role را صریح کنید.
Metric Contract: هر عدد باید شناسنامه داشته باشد
Metric name / decision use / non-use
Definition and exact formula
Numerator / denominator / excluded statuses
Unit / population / segmentation
Source / query or code version / owner
Event identity / deduplication / late-arrival policy
Window / timezone / freshness / snapshot time
Missingness / data-quality checks / revisions
Baseline / target / threshold and their authority
Uncertainty / confidence interval when valid
Countermetric / gaming risk
Drill-down / access / retention / expiryPass rate بدون denominator و Status policy قابلمقایسه نیست. Defect density بدون تعریف Defect، Size و window گمراهکننده است. Coverage ممکن است requirement، risk، code، state، browser یا executed-test coverage باشد. Red/Amber/Green بدون rule و Unknown state به رنگآمیزی نظر تبدیل میشود. برای طراحی و ضدبازیکردن معیارها از KPI تضمین کیفیت استفاده کنید.
آزمایش بازتولیدپذیر: یک Snapshot، سه Pass rate
یک Snapshot کاملاً ساختگی با ۱۲ مورد ساختم: ۶ Pass، ۲ Fail، ۲ Blocked و ۲ Not run. از همان داده، سه View با فرمول صریح محاسبه شد. هدف نشاندادن اثر denominator است؛ هیچیک بهعنوان فرمول جهانی انتخاب نشده است.
SNAPSHOT {"id":"PAY-6F2-2026-08-12T14:00+03:30","counts":{"pass":6,"fail":2,"blocked":2,"notRun":2},"highRisk":{"pass":0,"fail":1,"blocked":1,"notRun":1}}
VIEWS {"EXECUTED_ONLY":{"formula":"pass / (pass + fail)","numerator":6,"denominator":8,"value":"75.0%"},"CLOSED_OUTCOME":{"formula":"pass / (pass + fail + blocked)","numerator":6,"denominator":10,"value":"60.0%"},"PLANNED_SCOPE":{"formula":"pass / (pass + fail + blocked + notRun)","numerator":6,"denominator":12,"value":"50.0%"}}
HIGH_RISK {"pass":0,"fail":1,"blocked":1,"notRun":1}تفسیر و محدودیت سختگیرانه
هر سه درصد از حساب تعریفشدهٔ خود درستاند، اما سؤال متفاوتی جواب میدهند. عنوان «Pass rate ۷۵%» بدون `executed-only`، ۲ Blocked و ۲ Not run را نامرئی میکند؛ حتی هر سه نرخ نیز نشان نمیدهند High-risk slice صفر Pass دارد. پس عدد، formula، numerator/denominator، excluded status و risk slice باید همزمان قابلدیدن باشند.
Countها، statusها، Risk label و همهٔ فرمولها عمداً توسط نویسنده ساخته شدهاند. آزمایش Priority، severity، test quality، independence، representativeness، coverage validity، requirement correctness، defect truth، risk probability/impact، correlation/causality، uncertainty، sampling، duplicates، flaky behavior، missing telemetry، human interpretation یا Release outcome را نمیسنجد. خروجی نه معیار آمادگی انتشار، نه Benchmark و نه نمرهٔ تیم/فرد برای Performance، Hiring، Promotion یا Pay است.
Statusها و Unknown را در Summary نگه دارید
| Status | معنای پیشنهادی محلی | نباید بهجای آن گزارش شود | سؤال تصمیمی |
|---|---|---|---|
| Pass | Oracle تعریفشده برای این اجرا برقرار | «ویژگی درست/بیریسک است» | کدام scope و نسخه؟ |
| Fail | نتیجه با Oracle مغایر | Severity/Priority خودکار | اثر و disposition چیست؟ |
| Blocked | اجرا/Oracle بهعلت مانع معتبر کامل نشد | Pass یا Not run بیعلت | مانع/owner/default؟ |
| Not run | در Snapshot اجرا نشده | «فرضاً Pass» | چرا، چه Riskی و تا کی؟ |
| Inconclusive | Evidence برای verdict کافی نیست | Fail یا Pass اجباری | چه Evidence بعدی؟ |
| Skipped/Excluded | طبق rule و rationale خارج | حذف خاموش از denominator | rule/expiry/change؟ |
| Missing/Invalid | داده گم یا ناسالم | صفر یا Unknown مبهم | data-quality owner؟ |
| Unknown | سؤال تصمیمی بیEvidence کافی | ریسک صفر یا بیشینه | accept/discover/guard/defer؟ |
Uncertainty را ساده کنید، حذف نکنید
راهنمای Government Analysis Function دربارهٔ کیفیت و عدمقطعیت برای آمار رسمی نوشته شده، اما اصل قابلانتقالی دارد: اطلاعات کافی بدهید تا مصرفکننده دربارهٔ fit-for-use بودن برآورد قضاوت کند و تغییر مطلق/نسبی، کیفیت و uncertainty را شفاف ببیند. این منبع استاندارد Test reporting یا تضمین تصمیم درست نیست.
| منبع uncertainty | در View کوتاه | در Appendix |
|---|---|---|
| Scope gap | ۲ سناریوی سطح A اجرا نشده | IDs/reason/owner |
| Sampling | Estimate با interval/روش معتبر | sampling frame/assumptions |
| Measurement | telemetry loss ۴%؛ جهت اثر نامعلوم | query/quality checks |
| Environment | PSP stub رفتار late callback را مدل نمیکند | fidelity comparison |
| Flaky/non-determinism | ۲ نتیجه reproducible نیست | attempt history/quarantine |
| Model/threshold | Amber طبق policy v3، نه واقعیت طبیعی | rule/owner/calibration |
| Attribution | همزمانی تغییرها causal claim را محدود میکند | design/counterfactual |
| Freshness | Snapshot قبل از build جدید است | change diff/expiry |
عبارت «اطمینان بالا» بدون تعریف روش کافی نیست. Confidence interval دربارهٔ یک parameter تحت فرضهای مدل است؛ «احتمال درستبودن نتیجه» یا «ریسک تصمیم پایین است» را خودکار نمیگوید. اگر uncertainty کمی معتبر ندارید، منبع، جهت احتمالی، اثر بر تصمیم و Evidence موردنیاز را کیفی اما مشخص ثبت کنید.
نتایج A/B را به «برنده» و روانشناسی مشتری تقلیل ندهید
بیانیهٔ ASA دربارهٔ p-value تصریح میکند p-value احتمال درستبودن فرضیه، اندازهٔ اثر یا اهمیت نتیجه نیست و تصمیم نباید فقط به عبور از یک آستانه وابسته باشد. این سند جایگزین طراحی آزمایش یا مشاورهٔ آماری Context شما نیست.
Microsoft Research در الگوهای Experiment حین اجرا بر metricهای Data quality، هدف، feature/diagnostic و Guardrail و نیز accounting برای multiple testing و early peeking تأکید میکند. این تجربهٔ یک پلتفرم بزرگ است، نه نسخهٔ جهانی مدت هفتروزه یا threshold ثابت.
A/B Result Packet
Decision / hypothesis / pre-registration or analysis plan
Treatment/control identity and change isolation
Randomization unit / assignment / exposure / exclusions
Start-stop rule / planned duration / peeking policy
Primary, guardrail, diagnostic and data-quality metrics
Population / segments / sample sizes / missingness / SRM checks
Absolute and relative estimates + uncertainty intervals
Multiplicity / sequential method / model assumptions
Practical threshold / cost / downside / reversibility
Contradictory and null results / limitations
Decision owner / ship-hold-iterate options / follow-up| ادعای قدیمی | گزارش سالمتر |
|---|---|
| B برنده شد | Estimate اصلی + interval + guardrails + trust checks + decision rule |
| CTR بیست درصد رشد کرد | از ۵.۰% به ۶.۰%: +1pp مطلق و +۲۰% نسبی، با population/window |
| ماهانه ۵۰۰ کلیک میآورد | Projection مشروط به traffic/mix/stability؛ range و model جدا |
| کاربران پیام مستقیم را دوست دارند | این treatment در این population/window metric را جابهجا کرد؛ mechanism آزموده نشده |
| p<۰.۰۵ یعنی تصادفی نیست | ناسازگاری داده با model/null تحت فرضها؛ نه probability فرضیه/تصادف |
| جزئیات آماری مدیر را گیج میکند | اثر و uncertainty را plain-language کنید؛ appendix و analyst review را نگه دارید |
نمودار را از سؤال انتخاب کنید، نه از سلیقه
| سؤال | View محتمل | الزامات | خطر |
|---|---|---|---|
| مقایسهٔ category | bar/dot plot | baseline، sort، labels | محور قطعشده/3D |
| روند زمان | line/run chart | window، missing، release annotation | دو نقطه = trend |
| توزیع | histogram/box/ECDF | unit، bins/quantiles، outliers | میانگین تنها |
| بخش از کل | stacked bar/table | کل بسته و denominator | pie با sliceهای زیاد |
| رابطه | scatter | sample، scale، segment | correlation = causation |
| عدمقطعیت | interval/error bar/fan | تعریف interval/model | حذف interval برای ظاهر تمیز |
| Risk/criteria | table/heatmap با rule | scale، unknown، owner | رنگ بهعنوان حقیقت |
| Flow | funnel/flow | stage definitions/cohort | mixing populations |
«مغز تصویر را X برابر سریعتر پردازش میکند» و «نمودار دایرهای برای سهم همیشه مناسب است» قانون لازم این مقاله نیستند. نمودار باید سؤال، نوع داده و کار مخاطب را پشتیبانی کند. Benchmark صنعت نیز فقط با تعریف، population، geography، time، sampling و comparability معتبر است؛ میانگین ناشناس Context نمیسازد.
دسترسپذیری نمودار بخشی از صحت گزارش است
W3C WAI برای تصویرهای پیچیده مانند نمودار، توضیح کوتاه برای شناسایی و توضیح بلند/ساختاریافته برای اطلاعات ضروری را توصیه میکند؛ جدول داده یا متن میتواند Alternative باشد. صرف `alt=”نمودار نتایج”` معادل Evidence نیست. این راهنمای پیادهسازی دسترسپذیری است، نه روش تحلیل آماری.
چکلیست نمودار دسترسپذیر Government Analysis Function نیز بر حذف clutter و متن/جدول جایگزین تأکید میکند. الزامات دقیق WCAG و سیاست سازمان را جداگانه ارزیابی کنید؛ رعایت چند توصیه بهتنهایی ادعای Conformance نمیسازد.
- عنوان نمودار یک Claim محدود و زماندار باشد، نه «وضعیت کیفیت عالی است».
- Source، snapshot، unit، population، denominator و window بیرون تصویر و قابلانتخاب باشند.
- رنگ تنها حامل Pass/Fail/Risk نباشد؛ label، shape، pattern یا متن اضافه کنید.
- Contrast، اندازهٔ متن، فاصله و ترتیب خواندن را با ابزار/کاربر بررسی کنید.
- Alt کوتاه نوع/هدف را بگوید؛ long description پیام، scale، values، trend، exception و limitation را منتقل کند.
- برای دادهٔ تصمیمی، جدول خوانا و قابل Download بدهید؛ screenshot تنها منبع نباشد.
- Hover-only tooltip، animation سریع و autoplay را حذف یا جایگزین کنید.
- Zoom، keyboard، screen reader، export PDF و mobile/RTL را روی Artifact نهایی بررسی کنید.
- Legend را دور از داده پنهان نکنید؛ direct label در صورت امکان بهتر است.
- توضیح شفاهی جلسه جای Alternative ماندگار را نمیگیرد.
Chart Accessibility Packet
Decision question and chart claim
Chart type / axes / scales / units / baseline
Source / snapshot / population / window
Short alternative text
Long description: values, direction, exception, uncertainty
Equivalent data table and download
Colour-independent labels / contrast / reading order
Interactive keyboard and focus behavior
Owner / tested formats / known limitations / correction linkداستانسرایی با داده نباید Evidence را به Plot تبدیل کند
ساختار روایی میتواند ترتیب فهم بسازد: Decision context → چه بررسی شد → چه مشاهده شد → چه هنوز نمیدانیم → گزینه/اقدام بعدی. اما Conflict/Climax/Hero ممکن است تیم یا داده را برای جذابیت به داستان قطعی تبدیل کند. Result منفی نیز «موفقیت» اجباری یا اثبات جلوگیری از اتلاف نیست؛ ممکن است Design ناسالم، data quality ناکافی یا نتیجهٔ inconclusive باشد.
| روایت ناسالم | بازنویسی قابلحسابرسی |
|---|---|
| QA یک باگ پنهان را شکار و Release را نجات داد | Test T-۴۱ در build 6f2 مغایرت Ledger را آشکار کرد؛ attribution و اثر جلوگیریشده نامعلوم است |
| تست شکست خورد، اما با موفقیت مسیر غلط را حذف کردیم | نتیجه با threshold ازپیشتعریفشده سازگار نبود؛ تصمیم Stop/Iterate به cost و limitations وابسته است |
| دکمه سبز conversion را بالا برد چون جلب توجه میکند | Treatment سبز با estimate مشخص همراه بود؛ mechanism/روانشناسی سنجیده نشد |
| داشبورد ثابت میکند کیفیت بهتر شده | Metric X در window مشخص تغییر کرد؛ تعریف، mix و concurrent changes محدودیتاند |
| سه باگ اول باید رفع شوند | طبق Severity/Risk policy و authority مشخص، Option رفع این سه مورد پیشنهاد میشود |
| نتیجه برای مدیر ساده شده | Layer خلاصه شده؛ denominator، uncertainty و Drill-down حفظ شدهاند |
داستان را حول تصمیم و Evidence بچینید، نه حول قهرمان، مقصر یا نتیجهٔ ازپیشخواسته. دادهٔ ناسازگار، null result، countermetric و limitation باید جای قابلدیدن داشته باشند. اگر یک یافته پس از دیدن داده انتخاب شده، آن را exploratory بنامید؛ hypothesis ازپیشتعریفشده جا نزنید.
سه لایه از یک Truth model بسازید
| Layer | زمان مصرف | محتوا | لینک بعدی |
|---|---|---|---|
| L1 Decision Card | ۳۰–۹۰ ثانیه | decision/deadline، claim، evidence/unknown، options/recommendation، authority | L2 + source |
| L2 Decision Evidence | ۵–۱۵ دقیقه | scope، criteria، risk، denominator، chart/table، uncertainty، trade-offs | L3 artifacts |
| L3 Technical/Audit | در صورت نیاز | result IDs، defect/repro، queries، logs، config، environment، reviewer | immutable/raw evidence |
Layering به معنی «حقیقت ساده برای مدیر و حقیقت دقیق برای مهندس» نیست. Claim، snapshot و تعریف یکساناند؛ granularity و ترتیب فرق میکند. اگر L1 میگوید Green اما L2 سه Risk ناشناخته دارد، Viewها ناسازگارند. Link permission ممکن است دادهٔ حساس را محدود کند، اما Summary باید وجود محدودیت و صاحب دسترسی را نشان دهد.
One-minute Decision Card
Decision / owner / deadline / default
Current claim in one bounded sentence
Snapshot / scope / freshness
Criteria met / not met / not evaluated
Top residual risks and unknowns
Recommendation + confidence/limitations
Options and trade-offs
Required actions / owners / triggers
Links to L2/L3 / next update / expiryسناریوی ایرانی: Readout پرداخت از یک Packet واحد
سناریو ساختگی است. Marketplace ایرانی build `6f2` را برای کمپین نوروز آماده کرده است. Snapshot ساعت ۱۴:۰۰ Asia/Tehran همان ۱۲ مورد آزمایش را دارد: ۶ Pass، ۲ Fail، ۲ Blocked و ۲ Not run. سه مورد High-risk مربوط به timeout-after-commit، duplicate callback و Reconciliation هستند: صفر Pass، یک Fail، یک Blocked و یک Not run.
Packet و مرزهای Evidence
- Identity: Release ۲۰۲۶.۰۳، build/commit `6f2`، config hash و PSP-stub v4.
- Scope: Checkout/Promotion/Payment callback؛ Refund و Settlement خارج از Scope.
- Money: مبلغ مرجع `IRR`؛ تومان فقط نمایش صریح با conversion versioned.
- Transaction identity: Order، Payment Attempt، PSP Reference و idempotency key جدا.
- States: Initiated، Pending، Paid، Failed، Unknown و Reconciled.
- Variants: retry، timeout قبل/بعد commit، duplicate/late/out-of-order callback.
- Oracles: Order، append-only Ledger، Outbox/consumer و Reconciler مستقل؛ UI تنها Oracle نیست.
- Locale/time: رقم فارسی/عربی/لاتین، Unicode/RTL، UTC و Asia/Tehran؛ نمایش شمسی جدا از instant.
- Data: Synthetic؛ بدون PAN، CVV2، OTP، Token، تلفن یا log خام مشتری.
- Limitation: PSP stub رفتار latency/duplication شبکهٔ واقعی را کامل بازنمایی نمیکند.
L1: Decision Card برای Release owner
Decision: scope/conditions of 6f2 release by 17:00
Snapshot: PAY-6F2-2026-08-12T14:00+03:30
Claim: evidence for promotion path exists; high-risk payment recovery is not ready for an unguarded release
Accounting: 6 Pass / 2 Fail / 2 Blocked / 2 Not run
High-risk: 0 Pass / 1 Fail / 1 Blocked / 1 Not run
Unknown: duplicate financial effect after timeout-after-commit
Recommendation: promotion scope split; payment refactor behind tested flag
Options: 4h discovery | scope split | hold | explicit bounded acceptance
Hard gates: named authority, ledger/reconcile evidence, monitor, rollback
Decision owner: Release owner; QA is evidence/recommendation owner
Next update: 16:30; expiry on new build/configL2: جدول تصمیم برای Product، Finance-risk و Operations
| Risk/criterion | Evidence | Status | Unknown/limitation | Option/owner |
|---|---|---|---|---|
| Promotion calculation | ۱۲ boundary/rounding cases؛ ۱۲ Pass | Met در Scope | Refund خارج Scope | Release candidate / Product |
| یک اثر مالی برای هر intent | timeout-after-commit Fail | Not met | duplicate effect size نامعلوم | Flag/hold / Release owner |
| Late/duplicate callback | PSP stub Blocked | Not evaluated | fidelity محدود | fix stub + discovery / Backend |
| Reconciliation recovery | Not run | Not evaluated | backlog catch-up | timebox / Finance-risk+QA |
| Rollback | Flag tested on old path | Met conditionally | migration coupling review | Operations |
| RTL/amount/time | variant suite Pass | Met در build | PSP real UI خارج Scope | monitor / Product+QA |
L3: Drill-down فنی برای Diagnose و Retest
لایهٔ فنی به Result ID، Defect report نسخهدار، event timeline، redacted trace، state transition، Order/Ledger/Outbox/Reconcile diff، PSP-stub contract، test data seed و first-attempt evidence لینک میدهد. فایل log کامل را در Slide یا گروه عمومی نمیریزد. Reviewer میتواند Claim L1 را تا Oracle و Snapshot دنبال کند.
Decision و Action ثبتشده
نتیجهٔ فرضی جلسه: Release owner Promotion را با مسیر پرداخت قدیمی و Flag تأیید میکند؛ payment refactor منتشر نمیشود. Backend مالک PSP-stub و Retest ساعت ۱۶:۳۰ است؛ Operations monitor/rollback را نگه میدارد؛ Finance-risk معیار Reconcile را تأیید میکند. Dissent دربارهٔ هزینهٔ Scope split ثبت میشود. این Decision در Readout نویسنده جعل نشده و با build/config بعدی منقضی است.
اگر Release readiness در Context شما نیازمند Quality adequacy case است، معیار و اختیار را در چارچوب کیفیت بهاندازه کافی خوب ببندید. برای Risk analysis و treatment نیز تست مبتنی بر ریسک منبع جداگانه است.
جلسهٔ Readout را برای تصمیم طراحی کنید
Before
Pre-read + accessible alternatives + decision questions
Authority/roles + privacy/access + artifact links
During
Purpose/decision/deadline → snapshot/scope → claims/evidence
Unknowns/limitations → options/trade-offs → questions/corrections
Named decision or explicit no-decision/default
After
Decision/action/dissent record → corrections → source links
owners/dates/triggers → archive/retention/expiry → next update- Summary را پیشاپیش بفرستید تا جلسه آزمون سرعت خواندن یا زبان نباشد.
- در آغاز بگویید چه چیزی تصمیم است و چه چیزی فقط اطلاع/Review.
- Snapshot time را Freeze کنید؛ Dashboard زنده وسط گفتوگو denominator را عوض نکند.
- Fact correction را دعوت کنید؛ اختلاف Interpretation را بهعنوان خطای شخصی نبندید.
- سؤالها را بر اساس Claim/Source/Unknown/Option ثبت کنید، نه در حافظه.
- جزئیات L3 را فقط وقتی Decision به آن نیاز دارد باز کنید؛ حذف نکنید.
- Timebox را برای تصمیم بهکار ببرید، نه خاموشکردن Dissent یا Accessibility need.
- اگر Authority حاضر نیست، Recommendation را Decision اعلام نکنید.
- در پایان، owner و default را با صدای بلند/متن قابلخواندن بازگو کنید.
- Recording فقط طبق policy، consent، purpose، access و retention؛ حضور مساوی رضایت نیست.
Recommendation، Option و Decision را مرزبندی کنید
گزارش میتواند Recommendation داشته باشد، اما «تیم توسعه ابتدا این سه باگ را رفع کند» بدون Priority authority، capacity و alternatives یک فرمان بیپایه است. Recommendation باید Decision context، Evidence، options، expected mechanism، trade-offs، confidence/limitations و expiry داشته باشد. تصمیم و Risk acceptance با نقش مجاز ثبت میشوند.
Recommendation Card
Decision and deadline
Recommended option and explicit non-scope
Evidence claim / source / snapshot
Expected mechanism (not guaranteed outcome)
Alternatives including status quo
Benefits / harms / cost / schedule / reversibility
Unknowns / uncertainty / contradictory evidence
Hard guardrails / stop / rollback / monitor
Decision authority / consulted roles / dissent
Expiry and evidence that would change the recommendationاگر بحث بر سر Option/Trade-off یا توافق ادامه دارد، از راهنمای مذاکرهٔ Evidenceمحور QA استفاده کنید. Presentation ابزار متقاعدسازی پنهان نیست؛ مخاطب باید بتواند سؤال، مخالفت، Request evidence و انتخاب Alternative داشته باشد.
Production evidence را با نتایج پیش از Release مخلوط نکنید
Pass در Test environment پیشبینی کامل Production نیست؛ Canary/telemetry نیز جای Test basis را نمیگیرد. اگر Readout شامل Production observation است، Release/flag/cohort/traffic/window، guardrail، data lag، novelty/seasonality، rollback و privacy را جدا کنید. برای چارچوب ایمن به راهنمای Shift-right و Testing in Production رجوع کنید.
| Evidence lane | Claim مجاز | محدودیت قابلدیدن |
|---|---|---|
| Pre-release functional | رفتارهای اجراشده زیر Oracle/Environment | scope/fidelity/not-run |
| Performance lab | نتیجه workload/model مشخص | traffic/dependency/hardware model |
| Security assessment | روش/Scope یافتههای مشخص | false-negative/authorization/time |
| Canary | cohort/window guardrail movement | small sample/data lag/selection |
| Telemetry/RUM | observed events for instrumented population | missingness/privacy/identity |
| Incident/reconcile | recorded operational/financial discrepancy | causal attribution/late data |
Privacy، امنیت و Retention در ارائه
توصیهٔ «برای Developer log و ویدئو بفرستید» بدون Data classification خطرناک است. Log، screenshot، trace، session replay، user quote، query و فایل export میتوانند نام، تلفن، IP، Token، Cookie، PAN، OTP، قرارداد، اطلاعات سلامت یا رفتار کاربر داشته باشند. Masking ظاهری نیز ممکن است در metadata، URL یا layer پنهان شکست بخورد.
- Purpose و audience را قبل از جمعآوری/اشتراک تعیین و Data minimization کنید.
- دادهٔ Synthetic را برای demo ترجیح دهید؛ Production evidence را فقط در مرز مجاز.
- Redaction را با reviewer و search روی export نهایی بررسی کنید.
- Artifact عمومی، تیمی، محدود و قانونی/امنیتی را از هم جدا کنید.
- Share link، download، forwarding، expiry و revocation را کنترل کنید.
- Raw evidence و Summary ممکن است retention متفاوت داشته باشند؛ source link را با دسترسی معتبر نگه دارید.
- Recording/transcript را Default نسازید؛ consent، policy، jurisdiction و حذف لازم است.
- Quote کاربر/همکار را بدون زمینه، رضایت و ناشناسسازی برای «داستان» مصرف نکنید.
- دادهٔ حقوق/عملکرد/سلامت را وارد dashboard کیفیت محصول نکنید.
- Correction و deletion path را در Artifact ثبت کنید.
استفاده از AI برای Summary و Slide
AI میتواند از Packet پاکسازیشده Draft summary، عنوان نمودار، سؤال یا Alternative format بسازد؛ اما denominator، causal claim، p-value، Severity، Risk acceptance و Decision authority را نباید اختراع کند. خلاصهسازی ممکن است Fail/Unknown را حذف و نتیجه را confidentتر کند.
- Provider، retention، training use، region، access، license و deletion را طبق Policy بررسی کنید.
- Secret/PII/PAN/OTP/token/log/source code/قرارداد یا دادهٔ عملکرد فردی را بیمجوز ارسال نکنید.
- Input snapshot و metric dictionary را versioned کنید؛ خروجی بدون Source پذیرفته نشود.
- عدد و جمع را دوباره محاسبه کنید؛ Citation و URL را با منبع اصلی باز کنید.
- Prompt باید Unknown، limitation، contrary evidence و excluded status را حفظ کند.
- AI را برای sentiment/personality/emotion/deception/credibility یا رتبهبندی Presenter بهکار نبرید.
- Chart پیشنهادی را از نظر axis، denominator، accessibility و misleading encoding بازبینی کنید.
- Summary انسانی تأییدشده را versioned و اصلاحات را به مخاطبان قبلی برسانید.
Correction، Revision و Archive را طراحی کنید
Readout پس از جلسه تمام نمیشود. Data ممکن است late arrive شود، Defect disposition تغییر کند، query bug پیدا شود یا build تازه Snapshot را منقضی کند. Dashboard silently rewrite نباشد؛ revision، reason و اثر بر Claim/Decision را ثبت کنید.
Correction Record
Report/snapshot/revision affected
Detected at / detector / evidence
Original claim, number or visual
Correction and root mechanism (not person blame)
Affected decisions/actions/audiences
Immediate containment or notice
Source/query/data repair and reviewer
Whether decision must reopen
Republished links / superseded marker
Retention / prevention / closureتصحیح را به همان audience و channel برسانید؛ footer مخفی کافی نیست. اگر Decision بر دادهٔ غلط متکی بوده، صاحب اختیار تعیین کند Reopen لازم است یا نه. Outcome بد لزوماً گزارش قبلی را غلط نمیکند و Outcome خوب نیز omission/تحریف را توجیه نمیکند؛ کیفیت فرایند با Evidence موجود در زمان تصمیم بازبینی شود.
ملاحظات ایران، فارسی و تیم توزیعشده
- Timestamp را با timezone/offset ذخیره کنید؛ UTC برای identity و Asia/Tehran/شمسی برای نمایش صریح.
- ریال (`IRR`) را از تومان نمایشی جدا و نرخ/قاعدهٔ تبدیل را versioned کنید.
- رقم فارسی، عربی و لاتین، Unicode، BiDi و RTL را در label، table، PDF و CSV بررسی کنید.
- فونت embedشده، شکل رقم، minus sign، decimal/group separator و چاپ سیاهوسفید را کنترل کنید.
- تحریم/VPN/قطع اینترنت ممکن است dashboard/CDN/font/BI tool را از دسترس خارج کند؛ export accessible و fallback بدهید.
- جلسهٔ همزمان را تنها راه مصرف نکنید؛ pre-read، transcript انسانی/Caption و زمان Correction برای timezone/Caregiving.
- فارسی/انگلیسی و jargon glossary بدهید؛ accent یا سرعت بیان معیار اعتبار Evidence نیست.
- تعطیلات/نوروز و دادهٔ seasonal را در baseline/window روشن کنید؛ جهش کمپین را trend عمومی نخوانید.
- قانون/قرارداد/حریم خصوصی را با مرجع محلی جاری بررسی کنید؛ W3C/UK/US policy قانون ایران نیست.
- Exportهای حاوی دادهٔ مشتری یا PSP را در پیامرسان/لینک عمومی پخش نکنید.
معیارهای سالم برای سیستم ارائهٔ نتایج تست
| Signal | تعریف عملی | Countermetric/خطر |
|---|---|---|
| Traceability | Claimهای دارای source/snapshot/drill-down معتبر | لینک زیاد ولی شکسته/بیدسترسی |
| Metric completeness | عددهای دارای formula/denominator/window | Template completion بدون فهم |
| Unknown visibility | Unknownهای ownerدار در Decision view | افزایش مصنوعی Unknown count |
| Decision capture | readoutهای دارای authority/action/default | Decision صوری |
| Correction latency | کشف تا اعلان/اصلاح با distribution | پنهانکردن خطا برای KPI |
| Accessibility coverage | Artifactهای تستشده در formatهای هدف | checklist بدون user validation |
| Data-quality closure | missing/SRM/query issueهای resolve/accepted | بستن تیکت بدون اصلاح Claim |
| Temporary action expiry | action/waiverهای review/retireشده | تمدید خودکار |
| Readout usefulness | Taskهای تصمیمی تکمیلشده با feedback کیفی | popularity/satisfaction بهجای accuracy |
تعداد Slide، Chart، Dashboard view، مخاطب، applause، سؤال، تصمیم مثبت، Release، باگ پذیرفتهشده، «storytelling score»، sentiment، زمان ارائه یا نرخ کلیک گزارش، KPI کیفیت Presenter نیست. اینها با موضوع، قدرت، selection، accessibility و outcome دستکاری میشوند. معیارها را برای اصلاح سیستم بهکار ببرید، نه رتبهبندی فرد.
Pilot سیروزه برای Readout تصمیمآماده
| بازه | اقدام | خروجی |
|---|---|---|
| روز ۱–۵ | نمونهبرداری ۱۰ Artifact بدون person score | denominator/snapshot/authority/access gaps |
| روز ۶–۱۰ | Metric dictionary و Status taxonomy | نسخه ۰٫۱ + owners |
| روز ۱۱–۱۵ | Evidence Packet + L1/L2/L3 | یک truth model |
| روز ۱۶–۲۰ | Accessibility/privacy tabletop | alternatives/access/retention fixes |
| روز ۲۱–۲۵ | Pilot یک Decision class کمخطر | readout/decision/correction records |
| روز ۲۶–۳۰ | Review با countermetrics | Adopt/Adapt/Stop + expiry |
جلسه یا Slide تازه را Default نکنید. اگر Dashboard + Decision Card موجود نیاز را برآورده میکند، duplication نسازید. ماهانه denominator drift، broken links، data quality و corrections؛ فصلی authority، privacy، accessibility، metric gaming و retention را مرور کنید.
۲۰ ضدالگوی ارائهٔ نتایج تست
- یک «حقیقت» متفاوت برای هر عنوان شغلی.
- شروع با Chart پیش از Decision و Snapshot.
- Pass rate بدون numerator/denominator/status policy.
- حذف Blocked، Not run، Inconclusive و Missing.
- Green dashboard با High-risk Unknown پنهان.
- Bug/Test/Automation count بهعنوان کیفیت محصول.
- حذف uncertainty برای اینکه مدیر گیج نشود.
- «p<۰.۰۵ یعنی تصادفی نیست/فرضیه درست است».
- A/B winner بدون hypothesis، unit، guardrail و trust checks.
- تفسیر روانشناسی مشتری از یک metric movement.
- Projection کلیک/درآمد بهعنوان Outcome قطعی.
- نمودار دایرهای/3D/محور بریده برای جذابیت.
- رنگ بهعنوان تنها حامل Status یا Risk.
- Alt مبهم و نبود long description/جدول معادل.
- Story hero/villain و پنهانکردن counterevidence.
- QA Recommendation بهعنوان Decision نهایی.
- Slide بهعنوان تنها محل log/Defect/evidence.
- انتشار PII/Secret/log/recording برای «جزئیات فنی».
- AI summary بدون snapshot/source/human review.
- ویرایش خاموش Dashboard بدون correction/revision.
چکلیست ۲۰نقطهای قبل از ارائه
- Decision، deadline، owner و default روشناند.
- Artifact type و source of truth مشخصاند.
- Snapshot/build/config/data/timezone ثابتاند.
- Scope، non-scope و not evaluated دیده میشوند.
- Fact/metric/interpretation/risk/recommendation/decision جدا هستند.
- هر عدد formula، unit، numerator و denominator دارد.
- Status policy و excluded statuses صریحاند.
- Population/window/source/freshness ثبت شدهاند.
- Missingness/data quality/revision بررسی شدهاند.
- Uncertainty و limitation در L1 ناپدید نشدهاند.
- High-risk/critical slice جدا از aggregate است.
- Counterevidence و null/inconclusive result حفظ شدهاند.
- Chart متناسب سؤال و scale/axis سالم است.
- رنگ تنها کانال نیست و contrast بررسی شده است.
- Alt کوتاه، long description و جدول معادل وجود دارند.
- Drill-down از Claim تا evidence کار میکند.
- Privacy/access/retention/redaction رعایت شدهاند.
- Option/Trade-off/authority و Dissent ثبت میشوند.
- Action owner/due/trigger/expiry روشن است.
- Correction/reopen/archive و next update تعریف شدهاند.
جمعبندی: سادهسازی بدون حذف قابلیت حسابرسی
ارائهٔ مؤثر نتیجهٔ تست با داستان جذاب، نمودار رنگی یا کمکردن جزئیات آماری تعریف نمیشود. Readout خوب به مصرفکننده میگوید چه تصمیمی مطرح است، داده متعلق به کدام Snapshot است، چه چیزی سنجیده/نشده، عدد چگونه ساخته شده، uncertainty چیست، چه گزینههایی وجود دارد و چه کسی اختیار تصمیم دارد.
برای گزارش بعدی، فقط یک Pass rate را انتخاب و شناسنامهدار کنید: formula، denominator، statuses حذفشده، High-risk slice و Snapshot. سپس از همان Packet یک L1 یکدقیقهای و L3 قابل Drill-down بسازید. اگر دو View معنی متفاوت میدهند، مشکل مخاطب نیست؛ Truth model باید اصلاح شود.
پرسشهای متداول دربارهٔ ارائه نتایج تست
گزارش نتایج تست برای Developer و مدیر محصول چه تفاوتی دارد؟
Truth model و Snapshot نباید فرق کند. برای Task تشخیص، مشاهده/Expected، Repro، environment، trace و Oracle برجسته میشوند؛ برای Prioritization، impact، population، uncertainty، options و authority. هر دو باید به Packet واحد Drill-down داشته باشند و limitation/Unknown از View مدیر حذف نشود.
Pass rate را با چه فرمولی در گزارش QA نشان دهیم؟
فرمول جهانی وجود ندارد. سؤال تصمیمی و Status policy تعیین میکند denominator فقط Pass+Fail، نتیجههای بسته، یا کل Scope برنامهریزیشده باشد. نام، formula، numerator/denominator و Blocked/Not run/Excluded را کنار عدد بنویسید و Risk coverage را جدا نشان دهید؛ aggregate جای Critical gap را نمیگیرد.
آیا برای مدیران باید p-value و Confidence interval را حذف کنیم؟
خیر؛ اثر و uncertainty را با زبان روشن و لایهبندی ارائه کنید، نه اینکه حذف یا به «احتمال درستبودن» ترجمه کنید. Estimate مطلق/نسبی، interval و limitation در L1/L2 بمانند و روش در Appendix باشد. p-value اندازهٔ اثر، اهمیت یا احتمال درستی فرضیه نیست و بهتنهایی Decision rule کافی نیست.
بهترین نمودار برای ارائه نتایج تست چیست؟
«بهترین» عمومی وجود ندارد. برای مقایسه bar/dot، روند line، توزیع histogram/box/ECDF و uncertainty interval ممکن است مناسب باشند؛ اما data type، سؤال، scale و accessibility تعیینکنندهاند. عنوان محدود، source/denominator، رنگ غیروابسته، توضیح متنی و جدول معادل ضروریاند.
نتیجهٔ منفی یا Inconclusive را چگونه ارائه کنیم؟
آن را به موفقیت یا شکست اخلاقی تبدیل نکنید. Design، Scope، data quality، observed result، uncertainty و علت Inconclusive را جدا کنید؛ سپس گزینههای Stop، Iterate، Collect evidence یا No change را با cost/owner/expiry بدهید. ادعای «از اتلاف جلوگیری شد» فقط با Counterfactual معتبر قابلدفاع است.
