داشبورد گزارش تست؛ طراحی برای تصمیم، نه تزئین

یک داشبورد می‌تواند ۹۶٪ Pass Rate نشان دهد و بااین‌حال برای تصمیم انتشار بی‌فایده باشد: شاید فقط تست‌های کم‌ریسک اجرا شده‌اند، ۱۲ سناریوی پرداخت هنوز Blocked هستند، داده دو ساعت عقب است یا نتیجه‌های Retry جای شکست اول را گرفته‌اند. رنگ سبز وقتی Scope، مخرج، تازگی و Unknown را پنهان کند، شفافیت نیست؛ اعتماد کاذب است.

داشبورد گزارش تست یا QA Dashboard باید یک رابط تصمیم باشد: مخاطب با یک نگاه بفهمد درباره کدام Build و Release صحبت می‌کنیم، چه چیزی را می‌دانیم، چه چیزی را نمی‌دانیم، ریسک کجاست، کدام آستانه رد شده و اقدام بعدی بر عهده چه کسی است. این راهنما از قرارداد داده تا انتخاب نمودار، Drill-down، TestRail، دسترس‌پذیری، امنیت و مثال پرداخت ایرانی را پوشش می‌دهد.

خلاصه اجرایی: هر داشبورد باید به یک تصمیم وصل باشد

• سؤال: مخاطب دقیقاً چه چیزی را باید بفهمد؟
• اقدام: با دیدن Signal چه کاری می‌تواند انجام دهد؟
• Scope: کدام Product، Build، Environment، Run و بازه زمانی؟
• قرارداد داده: صورت، مخرج، وضعیت‌ها، استثناها و مالک سنجه چیست؟
• تازگی: آخرین رویداد موفق و Lag منبع چقدر است؟
• ریسک: کدام هدف بحرانی پوشش ندارد یا شاهدش ضعیف است؟
• Drill-down: از عدد کل چگونه به Case، Failure و Evidence می‌رسیم؟
• مالک: چه کسی تا چه زمانی باید اقدام یا ریسک را بپذیرد؟

داشبورد، گزارش، Alert و Decision Brief چه تفاوتی دارند؟

Dashboard: مشاهده تعاملی وضعیت جاری

داشبورد برای Monitor و Explore کردن وضعیت در یک Scope مشخص است. Filter، Trend و Drill-down دارد و مرتب Refresh می‌شود. صفحه رسمی Charts and dashboards در TestRail Status، Activity، Progress، Defect و Workload را در سطح Run، Plan، Milestone و Project توضیح می‌دهد.

Report: Snapshot قابل آرشیو و توزیع

گزارش معمولاً Snapshot زمان‌دار با Scope ثابت برای بازبینی، ممیزی یا ارسال است. داشبورد امروز نباید گزارش انتشار هفته قبل را بی‌صدا بازنویسی کند. مرجع Reports overview در TestRail گزارش‌های Summary، Result، Defect، Coverage و Cross-project را از یکدیگر جدا می‌کند.

Alert: درخواست توجه با Trigger

Alert باید وضعیت غیرعادی، آستانه و مسیر اقدام را اعلام کند؛ Dashboard مقصد بررسی است، نه جای Pager. «Blockedهای پرداخت بیشتر از ۳۰ دقیقه» Alert می‌خواهد؛ نمودار شلوغی که کسی دائماً نگاه کند کنترل عملیاتی نیست.

Decision Brief: استدلال کوتاه برای Go/No-Go

تصمیم انتشار به یک Brief نیاز دارد که Benefit، Hard obligation، Evidence، Unknown، ریسک باقیمانده و پذیرنده ریسک را کنار Link داشبورد بیاورد. داشبورد به‌تنهایی نمی‌تواند قضاوت را امضا کند. راهنمای کیفیت کافی و تصمیم انتشار قالب این پرونده را ارائه می‌کند.

از مخاطب شروع نکنید؛ از تصمیم مخاطب شروع کنید

«داشبورد مدیرعامل» یا «داشبورد QA» هنوز Requirement نیست. برای هر View یک Decision Contract بنویسید:

مخاطب/تصمیم	سؤال اصلی	Signal لازم	اقدام
تیم QA / Triage روزانه	چه چیزی اجرا یا بررسی نشده؟	Blocked age، Failure جدید، Flake، ظرفیت	رفع مانع، Triage، بازتخصیص
مهندسی / تشخیص	کدام تغییر و مرز خراب است؟	Build، Test، Log، Component، First failure	Fix، Revert یا Investigation
محصول / Scope	کدام هدف کاربر هنوز شاهد ندارد؟	Risk/Requirement coverage و Unknown	کاهش Scope یا تکمیل شاهد
Release Authority	انتشار در این محدوده قابل پذیرش است؟	Hard gates، ریسک باقیمانده، Rollback readiness	Block، Review یا Permit محدود
مدیریت / Portfolio	کجا حمایت یا تصمیم سازمانی لازم است؟	روند ریسک، مانع میان‌تیمی، ظرفیت و Outcome	رفع وابستگی یا تخصیص سرمایه

مدیر ارشد به فهرست ۵۰۰ Test Case نیاز ندارد و تیم تشخیص با یک Quality Score کلی کاری نمی‌تواند انجام دهد. Viewها باید از Semantic layer مشترک بیایند، اما Grain، جزئیات و Action آن‌ها متفاوت باشد.

قرارداد یک‌صفحه‌ای پنل قبل از ساخت نمودار

• Panel ID و عنوان: عنوان باید سؤال یا وضعیت را روشن کند؛
• Decision/Action: چه تصمیمی از این پنل پشتیبانی می‌شود؟
• Scope: Product، Release، Build، Environment، Run، Configuration؛
• Metric definition: صورت، مخرج، واحد، Grain و Aggregation؛
• Status map: رفتار Passed/Failed/Blocked/Untested/Skipped/Unknown؛
• Source: سیستم رکورد، Query، Dataset/Schema version؛
• Freshness SLO: Refresh، آخرین ingest موفق و Stale threshold؛
• Threshold: حدها، مبنای آن‌ها و مالک تغییر؛
• Drill-down: Link به Run/Case/Defect/Log/Decision؛
• Owner: مالک معنای Metric و مالک عملیات پنل؛
• Known limitations: Missing source، sampling، manual lag یا exclusion؛
• Review/expiry: زمان بازبینی و شرط حذف پنل.

راهنمای رسمی Grafana dashboard best practices نیز توصیه می‌کند داشبورد یک داستان یا سؤال داشته باشد، بار شناختی را کم کند، Documentation/Owner داشته باشد، Drill-down سلسله‌مراتبی و JSON نسخه‌پذیر داشته باشد و داشبوردهای موقت حذف شوند.

معماری داده: Source تا Decision Log

1. Sources: TestRail/Test runner، Issue tracker، CI/CD، Deployment و Production telemetry؛
2. Identity: Case، execution، attempt، build، artifact، environment و timestamp یکتا؛
3. Ingestion: رویداد یا Batch با checkpoint، retry و dead-letter قابل مشاهده؛
4. Normalization: Status map، timezone، duplicate و late-event policy؛
5. Semantic layer: Metric definition مشترک و versioned؛
6. Quality checks: completeness، uniqueness، referential integrity و freshness؛
7. Views: Dashboard/Report/Alert با RBAC و Drill-down؛
8. Decision log: تصمیم، شواهد دیده‌شده، مالک و زمان بازبینی.

Dashboard نباید Join مبهم انجام دهد

اگر Case ID میان ابزارها بازاستفاده یا Resultهای Retry Overwrite شوند، نمودار می‌تواند Attempt را دوبار بشمارد. کلید Execution باید حداقل Run، Case، configuration، build و attempt را متمایز کند. نتیجه «آخرین Attempt» و «اولین Attempt» دو View متفاوت‌اند؛ یکی وضعیت فعلی و دیگری پایداری Suite را نشان می‌دهد.

Freshness را بخشی از داده بدانید

بالای Dashboard این موارد را آشکار کنید: زمان آخرین refresh صفحه، زمان آخرین ingest موفق هر منبع، جدیدترین event time و lag. اگر Jira به‌روز است ولی TestRail دو ساعت عقب، Badge کلی «Live» گمراه‌کننده است. داده Stale باید زرد/متنی شود و پس از SLO به Unknown تبدیل شود، نه اینکه آخرین عدد قدیمی سبز بماند.

Statusها را حفظ کنید؛ Unknown را به صفر تبدیل نکنید

• Passed: Oracle مورد انتظار روی Artifact/Environment مشخص تأیید شده؛
• Failed: رفتار مورد انتظار در اجرای معتبر رد شده؛
• Blocked: پیش‌شرط یا وابستگی مانع ارزیابی شده؛
• Untested/Not run: در Scope است اما اجرا نشده؛
• Skipped: طبق Rule/Filter آگاهانه اجرا نشده؛ دلیل لازم است؛
• Inconclusive: اجرا رخ داده ولی Oracle/Evidence تصمیم‌پذیر نیست؛
• Quarantined: از Gate اصلی جدا شده؛ مالک و انقضا لازم است؛
• Unknown: داده گم، stale، ناسازگار یا source unavailable است.

Blocked را Failed یا Untested نکنید؛ هرکدام Action متفاوت دارد. Unknown را نیز Passed یا صفر نکنید. اگر Status سفارشی دارید، Mapping به مدل گزارش باید versioned و با مثال تست شود.

چهار عددی که نباید با هم مخلوط شوند

Execution completion

اجراهای تعیین‌تکلیف‌شده ÷ کل اجراهای برنامه‌ریزی‌شده. باید روشن کنید Blocked و Skipped در صورت کسر هستند یا جدا نمایش داده می‌شوند. Completion درباره پیشرفت کار است، نه کیفیت محصول.

Executed pass rate

Passed ÷ (Passed + Failed) فقط میان اجراهای دارای نتیجه قطعی. Blocked/Untested/Unknown باید کنار آن با شمار و سهم دیده شوند؛ وگرنه اجرای آسان‌ترها Pass Rate را مصنوعی بالا می‌برد. این نرخ اثبات کیفیت کلی نیست.

Risk/requirement evidence coverage

نشان می‌دهد اهداف یا Riskهای مهم چه شاهد تازه و معتبری دارند. شمار Test Case با Coverage یکسان نیست. برای اولویت و پوشش، از مدل تست مبتنی بر ریسک استفاده کنید؛ Weightها باید مصوب، محدود و قابل توضیح باشند.

Residual risk / release adequacy

ترکیبی از Failure، Unknown، الزام سخت، exposure، control، reversibility و پذیرش ریسک است. آن را به میانگین سه عدد قبلی تبدیل نکنید. Decision owner باید سناریوهای ریسک و شواهد را ببیند.

برای تعریف دقیق سنجه‌ها، denominator، سوگیری و anti-gaming، مقاله معیارهای اثربخشی تست مرجع مکمل این Dashboard است.

طراحی View آمادگی انتشار

• Context strip: Release/Build/Artifact/Environment/Scope/As-of؛
• Decision state: Block، Review یا Permit within bounds و نام Authority؛
• Hard gates: امنیت، داده، مالی، دسترس‌پذیری و Rollback با Evidence Link؛
• Risk map: اهداف بحرانی با Passed/Failed/Unknown/Not covered؛
• Execution distribution: همه Statusها با count و درصد؛
• Open critical problems: Owner، age، workaround و تصمیم؛
• Unknown/limitations: Source stale، environment gap یا تست‌نشده؛
• Operating bounds: Canary، سقف تراکنش، Guardrail و Rollback trigger؛
• Actions: مورد، مالک، موعد و آخرین update.

یک کارت «۸۷٪ آماده» این روابط را پنهان می‌کند. اگر Score اجباری است، پشت آن Rule، مخرج، Confidence و Drill-down بگذارید و اجازه ندهید الزام سخت با Passهای کم‌خطر جبران شود.

View عملیاتی QA و مهندسی

QA Operations

• Throughput نتیجه به‌همراه Scope change؛
• Blocked queue بر اساس سن و Dependency؛
• Failureهای منتظر Triage و age؛
• First-attempt failure، retry و Flake؛
• Quarantine count/age/expiry؛
• محیط، داده و ظرفیت عامل تأخیر؛
• کارهای مالک‌دار امروز، نه رتبه‌بندی افراد.

Engineering Diagnosis

• Failure جدید پس از Commit/Deployment؛
• Component، service، browser/device و configuration؛
• First failing attempt و failure signature؛
• Log/trace/screenshot Redacted و Correlation ID؛
• Defect مرتبط، owner، state و آخرین update؛
• مقایسه با آخرین Build سالم.

Bug count به‌تنهایی وضعیت را نمی‌گوید. Duplicate، rejected، reopened، affected build و severity/priority معانی جدا دارند. راهنمای فرایند ردیابی باگ قرارداد Defect را توضیح می‌دهد.

DORA و Production signal را درست جای دهید

سنجه‌های DORA «نمره کیفیت محصول» نیستند. مرجع فعلی DORA metrics پنج سنجه عملکرد تحویل را معرفی و توصیه می‌کند آن‌ها را برای یک Application/Service و در Context همان تیم دنبال کنید. می‌توان Change fail rate یا Failed deployment recovery time را کنار Evidence انتشار دید، اما نباید آن‌ها را با Pass rate جمع زد.

فصل Monitoring Distributed Systems در Google SRE می‌گوید Dashboard باید سؤال‌های پایه سرویس را پاسخ دهد و معمولاً Traffic، Error، Latency و Saturation را نشان دهد. این Signalهای تولیدی حلقه Feedback را کامل می‌کنند؛ جای شاهد پیش از انتشار را نمی‌گیرند. Alert باید به Dashboard/Runbook مرتبط Link شود.

انتخاب نمودار بر اساس سؤال

سؤال	Visual مناسب	دام رایج
روند چگونه تغییر کرده؟	Line/step chart با annotation	مقایسه بازه‌های نابرابر یا محور مبهم
کدام Component بیشتر مشکل دارد؟	Bar مرتب‌شده با count و rate	Count بدون exposure/denominator
Statusها چگونه توزیع شده‌اند؟	Stacked bar + جدول اعداد	Pie شلوغ و رنگ‌های نزدیک
Blockedها چند روزه‌اند؟	Age buckets/histogram + exception table	فقط میانگین که Tail را پنهان کند
کدام Risk/Configuration شکاف دارد؟	Matrix/heatmap + جدول قابل فیلتر	اتکای صرف به رنگ
اقدام بعدی چیست؟	Table با Owner/Deadline/Link	نمودار بدون اقدام

قواعد بصری کم‌خطر

• عنوان شامل Scope/زمان یا Filter آشکار باشد؛
• واحد، denominator و as-of کنار عدد دیده شود؛
• محور Bar از صفر شروع شود؛ اگر نمی‌شود، Break را برجسته کنید؛
• Dual axis و stacking را فقط با دلیل و توضیح به‌کار ببرید؛
• Trend را با تغییر Scope یا Definition annotation کنید؛
• برای «No data»، «zero» و «not applicable» حالت‌های متمایز بسازید؛
• Threshold را از ظرفیت/ریسک بسازید، نه از رنگ پیش‌فرض ابزار؛
• هر Aggregate مسیر Drill-down داشته باشد.

Drill-down: از Signal تا Evidence

مسیر پیشنهادی برای یک Failed segment:

1. Release/Build و Filterهای فعال؛
2. Risk/Capability/Component؛
3. Run و Configuration دقیق؛
4. Case/Scenario و همه Attemptها؛
5. Expected/Actual و Evidence؛
6. Defect/incident و Owner؛
7. Decision/waiver و تاریخ انقضا.

Link باید Context را حمل کند؛ کاربر نباید دوباره Release، بازه و Component را حدس بزند. بااین‌حال URLهای دارای Filter ممکن است اطلاعات حساس افشا کنند؛ شناسه عمومی، Token یا Query حاوی PII را در Link قرار ندهید.

مثال ایرانی: داشبورد انتشار پرداخت فروشگاه

فرض کنید فروشگاه ایرانی می‌خواهد Build ۸.۴ پرداخت با دو PSP را برای ۱۰٪ کاربران فعال کند. Decision Contract چنین است: «آیا Build ۸.۴ برای Canary ده‌درصدی تا ۲۴ ساعت، با سقف سفارش ۲۰۰ میلیون ریال و Kill Switch آزموده‌شده کافی است؟»

نوار Context

Artifact digest، Android/Web version، محیط، PSP mode، Dataset version، بازه UTC و نمایش Asia/Tehran، زمان آخرین ingest و نام Decision owner را نشان می‌دهد. تاریخ جلالی برای خواننده نمایش داده می‌شود، اما Event time در Source به UTC ذخیره و timezone صریح تبدیل می‌شود.

هفت بخش تصمیم

• Hard gates: برداشت مضاعف صفر، ledger متوازن، refund/reconciliation و Secret leakage؛
• Risk evidence: Callback تکراری، Timeout، Idempotency، ریال/تومان و ارقام فارسی/لاتین؛
• Status: Passed/Failed/Blocked/Untested/Unknown با count؛
• Dependency: PSP-A سالم، PSP-B داده‌اش به‌علت قطع شبکه stale و بنابراین Unknown؛
• Open problems: severity، affected scope، owner و deadline؛
• Canary guardrails: mismatch، duplicate، timeout و queue age با Stop trigger؛
• Action table: تکمیل شاهد PSP-B، تمرین rollback و تصمیم بازبینی.

قطع اینترنت آزمایشگاه نباید «تست PSP-B Failed» شمرده شود اگر رفتار محصول اصلاً ارزیابی نشده؛ Status درست Blocked/Unknown با دلیل است. هفته کاری/تعطیلی جمعه و Cut-off تسویه نیز باید در Trend و Forecast تقویمی لحاظ شوند. مبلغ‌ها با واحد صریح ریال نمایش داده شوند و تبدیل تومان هیچ‌گاه ضمنی نباشد.

دسترس‌پذیری و RTL بخشی از صحت داشبوردند

اگر Stakeholder نتواند نمودار را با Keyboard، Screen reader یا دید رنگی متفاوت بفهمد، Dashboard اطلاعات را کامل منتقل نمی‌کند. W3C برای تصاویر پیچیده مانند Chart توضیح کوتاه و شرح بلند/داده ساختاریافته را توصیه می‌کند؛ معیار Use of Color در WCAG نیز می‌گوید رنگ تنها وسیله انتقال معنا نباشد.

• رنگ را با Icon، marker، pattern و متن Status همراه کنید؛
• Contrast، اندازه متن و Focus visible را بررسی کنید؛
• Tab order با ترتیب خواندن فارسی/RTL هم‌راستا باشد؛
• Title، axis، legend و unit واضح و قابل خواندن باشند؛
• برای هر Chart جدول داده قابل دسترس و Download امن بدهید؛
• Insight و Filter فعال در Alt/long description منعکس شود؛
• Tooltip تنها محل اطلاعات حیاتی نباشد؛
• اعداد فارسی/لاتین و Unicode در Sort/Filter/Export تست شوند.

راهنمای رسمی Power BI accessibility نیز Keyboard، Screen reader، High contrast، Alt text، Tab order، marker، جدول داده و پرهیز از رنگ‌تنها را پوشش می‌دهد. برای آزمون جامع UI، راهنمای تست دسترس‌پذیری را ببینید.

امنیت، حریم خصوصی و اشتراک‌گذاری

• RBAC بر اساس Product/Project و حداقل دسترسی؛
• Row-level security برای مشتری/واحد سازمانی در صورت نیاز؛
• Security defect و incident محرمانه خارج از View عمومی؛
• Mask/aggregate کردن موبایل، کد ملی، حساب و Payload؛
• Snapshot/PDF با Scope، as-of، طبقه‌بندی و تاریخ انقضا؛
• Audit log برای تغییر Query، threshold، permission و share؛
• Retention و deletion برای Dataset/Attachment/Export؛
• Service account جدا و Secret rotation؛
• ممنوعیت Public link یا Embed بدون Threat model و approval.

داشبورد نسخه‌بندی‌شده باید Query و Semantic model را هم در Code review داشته باشد؛ فقط JSON ظاهر کافی نیست. کیفیت مسئولیت مشترک Data owner، QA، Engineering، Security و Decision owner است؛ مقاله کیفیت به‌عنوان مسئولیت مشترک این مدل را باز می‌کند.

چگونه خود داشبورد را تست کنیم؟

تست قرارداد داده

• صفر در برابر Null/No data؛
• Result تکراری و Attempt rerun؛
• Event دیررس یا خارج از ترتیب؛
• Case حذف/غیرفعال‌شده در Scope قدیمی؛
• Status جدید یا Mapping ناشناخته؛
• Build/Environment گم یا Join orphan؛
• تغییر timezone در مرز روز/ماه/سال جلالی؛
• Filter خالی، all و چندمقداری؛
• Source stale و ingestion failure.

تست Semantic و Query

برای Dataset کوچک «Golden» نتیجه دستی محاسبه‌شده بسازید و Query/Measure را Assert کنید. Aggregate کل باید با Drill-down جمع شود؛ denominator و exclusionها در Test fixture دیده شوند. Mutation ساده—تغییر یک Failed به Blocked—باید دقیقاً پنل‌های مورد انتظار را عوض کند.

تست تجربه و تصمیم

• کاربر هدف در کمتر از زمان توافق‌شده سؤال اصلی را پاسخ می‌دهد؟
• از Signal به Evidence و Action می‌رسد؟
• Filter/Scope/As-of را بدون آموزش می‌بیند؟
• Keyboard، Screen reader، Contrast و RTL کار می‌کنند؟
• Export و لینک اشتراکی همان Scope و مجوز را حفظ می‌کنند؟
• Load time و refresh فشار نامتناسب به Source وارد نمی‌کند؟

Pipeline داده و Dashboard را مانند نرم‌افزار version، review و deploy کنید. راهنمای CI/CD تست خودکار برای اجرای Contract/Query/accessibility checks قابل استفاده است.

سنجه‌های سلامت خود داشبورد

• Freshness SLO attainment هر Source؛
• درصد Eventهای Unknown/unmapped/orphan؛
• تطابق Aggregate با Drill-down؛
• زمان Load و نرخ Query error/timeout؛
• زمان از Signal تا owner/action؛
• Alertهای بدون اقدام یا Dashboardهای بدون استفاده؛
• پنل‌های فاقد Owner/review date؛
• Quarantine/exceptionهای منقضی؛
• موارد دسترس‌پذیری و permission leak؛
• نرخ تصمیم‌هایی که Snapshot/Decision log معتبر دارند.

Page view بالا به‌تنهایی ارزش نیست؛ ممکن است کاربران برای یافتن جواب مجبور به بازدید مکرر باشند. Outcome مطلوب، تصمیم سریع‌تر و دقیق‌تر با ناشناخته‌های آشکار است، نه «تعامل بیشتر» با نمودار.

برنامه ۳۰روزه ساخت داشبورد QA

هفته اول: تصمیم و واژه‌نامه

• یک تصمیم واقعی و دو مخاطب اصلی انتخاب کنید؛
• Status map، Metric dictionary و Scope identity را تصویب کنید؛
• Source، owner، freshness و محدودیت‌ها را ثبت کنید.

هفته دوم: Semantic layer و کیفیت داده

• Golden dataset با Null/duplicate/late/retry بسازید؛
• Queryها و reconciliation aggregate/drill-down را تست کنید؛
• Freshness/unknown را First-class کنید.

هفته سوم: Visual، Action و دسترس‌پذیری

• حداکثر یک Screen برای سؤال اصلی بسازید؛
• هر Signal را به owner/deadline/evidence وصل کنید؛
• RTL، keyboard، contrast، color و data table را تست کنید.

هفته چهارم: Pilot و Governance

• در یک Release واقعی Shadow-run کنید؛
• اختلاف با گزارش دستی و تصمیم کاربران را بررسی کنید؛
• RBAC، retention، version control، owner و review cadence را فعال کنید.

ضدالگوهای داشبورد گزارش تست

• یک Dashboard یکسان برای همه مخاطبان؛
• Quality Score یا Traffic light بدون Risk/Unknown؛
• Pass rate بدون denominator، Scope و Untested؛
• تبدیل Blocked/Unknown به Failed یا صفر؛
• Overwrite کردن Failure اولیه با Retry موفق؛
• Bug count بدون severity، age، exposure و duplicate policy؛
• نمودار Pie تزئینی با Statusهای زیاد؛
• رنگ قرمز/سبز به‌عنوان تنها معنا؛
• عدد بدون trend، threshold، as-of یا owner؛
• Aggregate بدون Drill-down؛
• Data stale که آخرین مقدار سبز را حفظ می‌کند؛
• رتبه‌بندی افراد با تعداد Test/Bug؛
• Dashboard دستی و ویرایش‌پذیر بدون version/audit؛
• Public snapshot دارای PII یا security finding؛
• پنل دائمی بدون استفاده، مالک یا expiry.

چک‌لیست انتشار داشبورد QA

• سؤال، تصمیم، اقدام و مخاطب هر View روشن است.
• Build/Release/Environment/زمان همیشه قابل مشاهده‌اند.
• صورت، مخرج، exclusions و Status map مستندند.
• Unknown/Blocked/Untested/Quarantine پنهان نشده‌اند.
• Freshness هر Source و stale state دیده می‌شود.
• Threshold مبنا و مالک تغییر دارد.
• Aggregate با Drill-down و Golden dataset تطبیق دارد.
• هر Signal مهم owner، deadline و Evidence link دارد.
• RTL، keyboard، contrast، color و data table تست شده‌اند.
• PII/security data، RBAC، export و retention کنترل شده‌اند.
• Query/Semantic/Dashboard در version control و review هستند.
• Dashboard owner، review cadence و expiry تعریف شده‌اند.

پرسش‌های متداول درباره داشبورد گزارش تست

مهم‌ترین معیار داشبورد QA چیست؟

یک معیار جهانی وجود ندارد. معیار باید به تصمیم متصل باشد. برای آمادگی انتشار، Hard gate، پوشش ریسک، Unknown و ریسک باقیمانده مهم‌تر از Pass rate کلی‌اند؛ برای عملیات QA، Blocked age، triage age و Flake ممکن است Actionableتر باشند.

Pass Rate را چگونه محاسبه کنیم؟

یک تعریف رایج Passed ÷ (Passed + Failed) میان نتیجه‌های قطعی است، اما باید First/last attempt، Scope و duplicate policy را مشخص کنید. Blocked، Untested، Skipped و Unknown را کنار نرخ جدا نمایش دهید تا مخرج ناقص پنهان نشود.

برای مدیران چه چیزی در داشبورد تست نشان دهیم؟

تصمیم و مانع: Riskهای مهم، Hard gate، شکاف شاهد، trend، dependency سازمانی، owner و موعد. تعداد Case/Bug خام و جزئیات فنی فقط از طریق Drill-down لازم‌اند. «مدیریت» یک مخاطب واحد نیست؛ Release Authority و Portfolio manager تصمیم‌های متفاوت دارند.

TestRail Dashboard کافی است یا Grafana/Power BI لازم داریم؟

برای Status/Progress/Activity/Defect در Run و Milestone، قابلیت‌های داخلی TestRail ممکن است کافی باشد. وقتی چند منبع، Semantic model، Production telemetry یا View portfolio لازم است، ابزار BI/observability کمک می‌کند. ابتدا سؤال و قرارداد داده را مشخص کنید؛ ابزار جای آن‌ها را نمی‌گیرد.

هر چند وقت یک‌بار داشبورد Refresh شود؟

به سرعت تصمیم و Source بستگی دارد. Triage ممکن است چنددقیقه‌ای و گزارش Portfolio روزانه باشد. Refresh سریع‌تر از تغییر داده فقط هزینه و Load می‌سازد. Freshness SLO، آخرین ingest موفق و stale threshold را برای هر منبع تعریف و آشکار کنید.

جمع‌بندی

داشبورد گزارش تست مجموعه‌ای از نمودارهای زیبا نیست؛ یک قرارداد میان داده، ریسک، تصمیم و اقدام است. از سؤال مخاطب شروع کنید، Statusها و Unknown را حفظ کنید، Completion را از Pass rate و Risk coverage جدا نگه دارید، Freshness را First-class کنید و برای هر Aggregate مسیر Evidence بسازید.

داشبورد خوب نمی‌گوید «کیفیت سبز است». می‌گوید این Build در این Scope و زمان چه شاهدهایی دارد، کدام منبع stale است، چه ریسکی باقی مانده، چه کسی باید چه کاری انجام دهد و تصمیم تا چه زمانی معتبر است. همین شفافیت محدود و قابل ممیزی، اعتماد واقعی می‌سازد.