گزارش تست حرفه‌ای چیست؟ قالب Status و تصمیم انتشار

۲۴۰ تست برنامه‌ریزی شده، ۹۲٪ Pass Rate و فقط ۱۵ شکست؛ آیا نسخه آماده انتشار است؟ تا وقتی ندانیم ۴۰ تست اجرا نشده، دو سناریوی حیاتی بازگشت پول Blocked و همین ۱۵ شکست متعلق به کدام ریسک‌اند، این درصدها تصمیمی نمی‌سازند. گزارش تست حرفه‌ای باید Unknownها و ریسک باقی‌مانده را آشکار کند، نه اینکه فعالیت تیم QA را زیباتر نمایش دهد.

در این راهنما، گزارش‌دهی تست را به یک رابط تصمیم تبدیل می‌کنیم: تفاوت Test Progress Report، Test Completion Report، Dashboard و Release Readiness Memo را روشن می‌کنیم؛ فرمول‌های Pass/Fail/Blocked را با مخرج دقیق می‌نویسیم؛ قالب آماده، نمونه انتشار پرداخت ایرانی، قرارداد رنگ، Risk Acceptance و کنترل کیفیت داده را ارائه می‌دهیم.

گزارش تست چیست؟

Test Report خلاصه‌ای نسخه‌دار از شواهد تست برای پایش، کنترل، تکمیل فعالیت یا تصمیم انتشار است. این سند نباید صرفاً خروجی خودکار ابزار باشد. دادهٔ خام باید با Scope، Baseline، ریسک، محدودیت و اقدام تفسیر شود.

گزارش تست کیفیت را «اثبات» نمی‌کند؛ دامنهٔ شواهد و عدم قطعیت را قابل مشاهده می‌کند. اگر تستی برای یک ریسک طراحی یا اجرا نشده، وضعیت آن ریسک Unknown است، نه Pass.

نیت جست‌وجو و کلیدواژه‌ها

کلیدواژهٔ اصلی «گزارش تست» است. عبارت‌های مکمل شامل «Test Report»، «Test Progress Report»، «Test Completion Report»، «گزارش وضعیت تست»، «قالب گزارش تست نرم‌افزار»، «گزارش آمادگی انتشار»، «Test Summary Report»، «داشبورد QA» و «گزارش Go/No-Go» هستند. مخاطب، Test Lead، QA، Product Manager، Release Manager و مدیر فنی است.

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

۱. Test Progress Report

در طول تست و با تناوب مشخص تولید می‌شود تا Test Control ممکن شود. سؤالش این است: «از برنامه منحرف شده‌ایم؟ کدام ریسک تغییر کرده و چه اصلاحی لازم است؟» دوره گزارش، پیشرفت، مانع، متریک، ریسک تازه و کار دوره بعد اجزای اصلی‌اند.

۲. Test Completion Report

در پایان یک Test Level، Cycle، Iteration یا Release Candidate تهیه می‌شود. سؤالش این است: «در مقایسه با هدف و Exit Criteria چه انجام شد، چه باقی ماند و چه آموختیم؟» برای فرایند کامل آرشیو و درس‌آموخته‌ها، راهنمای بسته‌شدن چرخه تست را ببینید.

۳. Release Readiness Memo

یک Artifact سازمانی برای پشتیبانی از تصمیم انتشار است و الزاماً نام استاندارد Test Report نیست. شواهد تست، وضعیت عملیاتی، امنیت، Migration، Rollback و ریسک تجاری را کنار هم می‌گذارد. تیم تست می‌تواند Recommendation بدهد؛ مالک کسب‌وکار یا نقش تعریف‌شده در Release Policy تصمیم و Risk Acceptance را ثبت می‌کند.

۴. Live Dashboard

نمای جاری داده‌هاست، نه Snapshot نهایی و نه تحلیل روایی. Dashboard باید آخرین زمان به‌روزرسانی، فیلتر Build/Environment و تعریف هر Metric را نشان دهد. لینک Dashboard در گزارش می‌آید، اما گزارش تصمیم باید Snapshot تغییرناپذیر خود را حفظ کند.

Defect Report یک Artifact پنجم و جداست

گزارش عیب برای بازتولید و حل یک Anomaly است، نه خلاصه وضعیت Release. برای ساخت شواهد Expected/Actual، Log و زمینهٔ امن از قالب گزارش باگ حرفه‌ای استفاده کنید.

مبنای استاندارد Progress و Completion Report

سرفصل رسمی ISTQB CTFL v4.۰.۱ میان دو نوع گزارش تفکیک می‌کند: Progress Report برای کنترل جاری و تغییر برنامه/منابع، و Completion Report برای جمع‌بندی یک فعالیت کامل‌شده. همان منبع، دوره گزارش، انحراف، مانع، متریک، ریسک‌های جدید و کار بعدی را برای Progress و ارزیابی هدف/Exit، انحراف، ریسک رفع‌نشده و درس‌آموخته را برای Completion ذکر می‌کند.

استاندارد ISO/IEC/IEEE ۲۹۱۱۹-۳:۲۰۲۱ نیز قالب‌های مستندات تست را برای انواع چرخه‌های توسعه پوشش می‌دهد. استفاده از استاندارد نباید به تولید سند حجیم و بی‌مصرف تبدیل شود؛ Formality، تناوب و جزئیات باید با ریسک، مخاطب و الزام نظارتی تناسب داشته باشد.

اول سؤال و تصمیم، بعد متریک

هر بخش گزارش باید به یک سؤال و اقدام متصل باشد:

سؤال	شاهد	تصمیم احتمالی
آیا Scope برنامه‌ریزی‌شده آزموده شده؟	Risk/Requirement coverage و Not Run	ادامه تست یا پذیرش شکاف
آیا ریسک حیاتی کاهش یافته؟	نتیجه سناریوهای ریسک + نقص باز	Release، Mitigation یا Hold
آیا بازخورد دیر شده؟	p50/p95 زمان Pipeline و Queue	تقسیم Suite یا افزایش ظرفیت
آیا کیفیت عملیاتی کافی است؟	SLO، Error budget، Canary	Promote یا Rollback
آیا نتیجه قابل اعتماد است؟	Flake، Blocked، Environment drift	بازاجرا یا اصلاح محیط

مقاله ۱۲ متریک تست برای تصمیم کیفیت فرمول‌های Outcome، Risk، Flow و Test-system health را عمیق‌تر بررسی می‌کند. این مقاله روی چیدمان آن‌ها در گزارش تمرکز دارد.

Pass Rate را با مخرج دقیق گزارش کنید

فرض کنید Baseline فعلی ۲۴۰ تست دارد:

• Passed: 175
• Failed: 15
• Blocked: 10
• Not Run: 40

سه نسبت متفاوت

Determinate execution rate =
(Passed + Failed) / In-scope baseline
= 190 / 240 = 79.2%

Attempted rate =
(Passed + Failed + Blocked) / In-scope baseline
= 200 / 240 = 83.3%

Pass ratio among determinate results =
Passed / (Passed + Failed)
= 175 / 190 = 92.1%

عدد ۹۲٫۱٪ درست است، اما ۵۰ مورد Blocked یا Not Run را از دید پنهان می‌کند. هیچ‌کدام از این سه نسبت به‌تنهایی «آمادگی انتشار» نیست. نام، فرمول، مخرج و وضعیت‌های مستثنا باید کنار عدد بیاید.

وضعیت‌ها را متقابلاً مانعه‌الجمع تعریف کنید

وضعیت	تعریف عملیاتی	اثر در گزارش
Passed	همه Oracleهای این اجرا برآورده شده‌اند	شاهد مثبت در Scope محدود
Failed	حداقل یک Oracle برآورده نشده است	نیاز به Triage و اثر ریسک
Blocked	تست آغاز یا ادامه یافته، اما مانع خارجی نتیجه را ناممکن کرده	Unknown با مالک مانع
Not Run	در Baseline است اما هنوز اجرا نشده	شکاف شاهد
Skipped	عمداً طبق Rule اجرا نشده	دلیل و Approval لازم
Out of Scope	از Baseline مصوب حذف شده	در مخرج نیست؛ Change log لازم

در راهنمای اجرای تست در STLC قرارداد Status و جریان Triage/Retest با جزئیات بیشتری آمده است.

Baseline و Snapshot را قفل کنید

اگر در طول Cycle تست اضافه و حذف شود، نمودار Pass Rate بدون Change log قابل مقایسه نیست. هر Snapshot باید این شناسه‌ها را داشته باشد:

• Report ID و زمان تولید به UTC و زمان محلی؛
• Build/Commit/Artifact و Feature flags؛
• Environment و Config version؛
• Test suite baseline version؛
• دوره داده و Cut-off time؛
• تعداد Added/Removed/Retired از Snapshot قبلی؛
• قانون Latest result در برابر همه Runها؛
• مالک تأیید داده.

نتیجه Retest نباید تاریخچه شکست را بازنویسی کند. برای Release status می‌توان Latest valid result را نشان داد و در Trend همه Attemptها را حفظ کرد.

Coverage با Confidence یکسان نیست

Coverage می‌گوید کدام Artifact یا ساختار طبق یک معیار لمس شده است؛ Confidence یک قضاوت درباره کفایت شواهد برای یک تصمیم است. نمی‌توان ۸۵٪ Requirement Coverage، ۹۰٪ Branch Coverage و ۹۵٪ Pass را میانگین گرفت و «۹۰٪ اطمینان» ساخت.

Coverage را چندبعدی گزارش کنید

• Product risk coverage؛
• Requirement/Acceptance criterion coverage؛
• Code/Branch/Data-flow coverage؛
• Configuration/Browser/Device coverage؛
• State/Transition/Business rule coverage؛
• Quality attribute coverage؛
• Production traffic/SLO coverage.

Traceability از Risk و Requirement تا Test و Result، پایهٔ گزارش است. برای ساخت Acceptance criterion و Trace قابل آزمون، راهنمای تحلیل نیازمندی‌ها را ببینید.

Unknown را وضعیت رسمی بدانید

اگر محیط آماده نیست، داده نماینده نیست یا تست امنیت اجرا نشده، وضعیت «کیفیت خوب به نظر می‌رسد» نیست. گزارش باید بنویسد: «شاهد کافی نداریم»، اثر احتمالی و مسیر کاهش عدم قطعیت چیست.

Risk Coverage قلب گزارش انتشار است

Risk ID	پیامد	Exposure پیشین	شاهد برنامه‌ریزی‌شده	نتیجه	Residual risk	مالک
PAY-01	برداشت تکراری	Critical	Idempotency + concurrency + callback replay	Pass	Low	Payment lead
PAY-02	نامشخص‌ماندن پرداخت Timeout	High	Timeout + reconciliation + delayed callback	۲ مورد Blocked	High/Unknown	Release owner
ORD-03	فروش بیش از موجودی	High	Concurrent reservation	Fail، defect open	High	Inventory lead
UX-04	نمایش غلط مبلغ RTL	Medium	سه Device/Browser منتخب	Pass	Low	Frontend lead

نتیجه Pass یک Risk را خودکار به صفر نمی‌رساند. Exposure با احتمال، اثر، عمق شاهد، محدودیت محیط و Mitigation باقی‌مانده دوباره ارزیابی می‌شود. Risk Acceptance باید نام نقش تصمیم‌گیر و تاریخ انقضا داشته باشد.

قرارداد رنگ سبز، زرد، قرمز و خاکستری

رنگ بدون Rule فقط تزئین و زمینه بازی با گزارش است. یک قرارداد نمونه:

• سبز: Exit Criteria حیاتی محقق، هیچ ریسک Critical/High بدون Mitigation، شواهد پرریسک کامل و Telemetry در آستانه است.
• زرد: انتشار فقط با شرط مکتوب؛ Mitigation، Owner، موعد، Canary و Rollback مشخص است.
• قرمز: ریسک حیاتی رفع‌نشده، Exit Criterion اصلی نقض یا Rollback ناممکن است.
• خاکستری: داده تازه/کافی نیست؛ وضعیت کیفیت نامعلوم است.

ریسک قرمز پرداخت نباید با چند بخش سبز کم‌اهمیت میانگین گرفته شود. رنگ کل Release از Rule اولویت و Policy می‌آید، نه میانگین حسابی.

Exit Criteria را از Target جدا کنید

Exit Criterion شرط تصمیم است؛ Target هدف بهبود است. اگر «Flake کمتر از ۲٪» شرط انتشار نیست، نقض آن نباید ناگهان Release را Red کند. همه Criteria باید در Test Plan با منبع، فرمول، Owner و استثنا تعریف شوند.

Criterion	نوع	نتیجه	اثر
صفر نقص Critical باز	Mandatory	Met	اجازه ادامه ارزیابی
همه Riskهای High دارای شاهد	Mandatory	Not met	Hold یا Risk acceptance رسمی
p95 پرداخت کمتر از ۱٫۵ ثانیه	Mandatory	۱٫۸ ثانیه	Hold/Canary محدود طبق Policy
Flake کمتر از ۲٪	Improvement target	۲٫۴٪	Action item، نه Gate خودکار

نمونه گزارش وضعیت انتشار پرداخت

برای تفسیر p95، مدل بار و آستانه قابل دفاع، به راهنمای برنامه تست عملکرد مراجعه کنید.

قالب آماده Test Progress Report

Report ID / Generated at / Data cut-off:
Period:
Build + environment + suite baseline:
Decision or control needed by:

1. Progress vs plan
- Planned / passed / failed / blocked / not run
- Baseline changes since last report
- Schedule/effort deviation

2. Risk changes
- New, increased, decreased risks
- Evidence gained
- Unknown areas

3. Impediments
- Impact
- Workaround
- Owner and ETA

4. Defects requiring attention
- Defect / severity / affected risk
- State / owner / next decision

5. Next reporting period
- Tests and risks targeted
- Environment/data dependency
- Expected decision

6. Actions
- Action / owner / due date / status

Progress Report باید Control directive بسازد؛ مثلاً Reprioritize، اصلاح Environment یا تغییر برنامه. اگر هیچ اقدام یا تصمیمی از گزارش بیرون نمی‌آید، احتمالاً داده زائد است.

قالب آماده Test Completion Report

Report ID / Approvals / Final snapshot:
Test object, build, environment, data and period:
Objectives and exit criteria:
Scope tested / excluded / added / removed:

1. Executive decision summary
- Recommendation and rationale
- Residual risk and unknowns
- Decision owner and validity window

2. Results
- Status counts with formulas
- Risk and requirement coverage
- Quality-attribute evidence
- Defect disposition

3. Deviations
- Schedule, effort, environment, method
- Effect on confidence

4. Unmitigated items
- Risk / defect / gap
- Impact / mitigation / owner / expiry

5. Release controls
- Canary, monitor, rollback, support

6. Lessons and follow-up
- What changed
- Action / owner / due date

7. Evidence links
- Immutable result, logs, dashboard snapshot
- Testware/configuration versions

گزارش را برای مخاطب تنظیم کنید، حقیقت را نه

مخاطب	سؤال اصلی	نمای مناسب
Executive	پیامد و تصمیم چیست؟	یک صفحه: Risk، Recommendation، Owner
Product/Release	چه شرطی برای انتشار باقی است؟	Scope، Exit، Mitigation، Timeline
Development	کدام Failure را باید تشخیص دهم؟	Signature، Build، Evidence، Defect link
SRE/Operations	چگونه امن Rollout/Rollback کنیم؟	SLO، Canary، Alert، Runbook
Security/Compliance	Traceability و Approval کجاست؟	Control coverage، استثنا، Audit trail
QA team	کدام شکاف و Flake را اصلاح کنیم؟	Trend، Blocker، Effectiveness، Action

همه نماها باید از مدل داده مشترک بیایند. ساختن عدد متفاوت برای هر مخاطب اعتماد را از بین می‌برد.

فرهنگ‌نامه متریک بسازید

برای هر Metric این قرارداد را ثبت کنید:

Name:
Question answered:
Decision/action enabled:
Formula:
Numerator / denominator:
Statuses included/excluded:
Scope and cohort:
Time window and timezone:
Source system:
Freshness SLA:
Threshold and owner:
Known limitations:
Anti-gaming guardrail:
Change history:

اگر تعریف Severity، Suite یا Cohort تغییر کرده، Trend را با Annotation قطع کنید. مقایسه دو Release با Scope متفاوت بدون Normalization گمراه‌کننده است.

متریک‌های خطرناک و ضدالگوهای گزارش

Pass Rate بالا

با افزودن تست‌های ساده بالا می‌رود و Not Run را پنهان می‌کند. کنار Risk coverage، Blocked و Failure severity گزارش شود.

تعداد باگ

تیم جست‌وجوگر ممکن است باگ بیشتری پیدا کند. شمار خام ابزار سنجش کیفیت توسعه‌دهنده یا عملکرد QA نیست. Lifecycle و Aging را با اثر ریسک ببینید؛ چرخه عمر باگ زمینهٔ لازم را توضیح می‌دهد.

Defect Density

مخرج LOC یا Story point میان زبان‌ها و تیم‌ها قابل مقایسه نیست. فقط در Cohort همگن و با تعریف پایدار استفاده شود.

درصد Automation

Automation یک روش اجراست، نه پوشش ریسک. خودکارکردن هزار تست کم‌ارزش، Outcome ایجاد نمی‌کند.

Code Coverage

اجرای خط، صحت Assertion را ثابت نمی‌کند. Threshold می‌تواند Guardrail باشد، نه Score کیفیت.

میانگین زمان پاسخ

Tail latency را پنهان می‌کند. p95/p99، حجم، Error rate و مدل بار را کنار آن بیاورید.

رنگ بدون داده

«سبز چون تیم احساس خوبی دارد» قابل Audit نیست. Rule، Cut-off و Override approver لازم است.

معماری دادهٔ گزارش

یک Pipeline ساده و قابل اعتماد چهار لایه دارد:

1. Sources: Test management، CI، Issue tracker، Coverage، Observability.
2. Normalization: نگاشت Build، Test ID، Risk ID، Status و Timestamp.
3. Semantic layer: فرمول‌ها، Cohort، Threshold و Exclusion.
4. Presentation: Dashboard جاری و Snapshot گزارش تصمیم.

کنترل کیفیت داده

• Test ID تکراری یا بدون Risk link شناسایی شود.
• Result دیررس پس از Cut-off علامت بخورد.
• Build نامشخص وارد Release report نشود.
• Status خارج واژگان Reject شود.
• جمع وضعیت‌ها با Baseline برابر باشد.
• Defect بسته بدون Retest policy جدا دیده شود.
• Dashboard stale به رنگ خاکستری برود، نه سبز باقی بماند.
• هر تغییر دستی Audit trail داشته باشد.

انتخاب نمودار براساس رابطه

• Stacked bar: توزیع Pass/Fail/Blocked/Not Run در هر Build.
• Line chart: Trend پایدار در Cohort ثابت با Annotation تغییر.
• Heatmap: Risk یا Feature در برابر نوع شاهد و نتیجه.
• Control chart: Flake یا زمان Pipeline برای تشخیص تغییر فرایند.
• Table: ریسک‌ها، مالک و اقدام؛ اغلب از نمودار بهتر است.

Pie chart برای مقایسه دقیق ضعیف است و تعداد زیاد بخش‌ها را ناخوانا می‌کند. عنوان نمودار باید سؤال را بیان کند؛ «کدام Riskهای High هنوز شاهد ندارند؟» بهتر از «Test Coverage» است.

Release Recommendation با Release Decision فرق دارد

تستر درباره شواهد، محدودیت و ریسک Recommendation می‌دهد. تصمیم انتشار ترکیبی از کیفیت، بازار، قرارداد، عملیات و ظرفیت پشتیبانی است. اگر سازمان نقش QA را Decision owner تعریف کرده، همان Policy باید صریح باشد؛ در غیر این صورت QA نباید به‌تنهایی مالک ریسک تجاری معرفی شود.

سه Recommendation قابل دفاع

• Proceed: شواهد و Criteria مصوب برای دامنه تصمیم کافی‌اند.
• Proceed with conditions: شرط، Mitigation، Owner، Expiry، Canary و Rollback مشخص است.
• Hold: ریسک یا Unknown از آستانه Policy عبور کرده است.

عبارت «No-Go چون QA تأیید نکرد» ضعیف است. بنویسید: «PAY-۰۲ به‌علت دو تست Blocked همچنان High/Unknown است؛ Criterion R-۴ محقق نشده و Release Policy حالت Hold را الزام می‌کند.»

Operational evidence و Error Budget

برای محصول در حال سرویس، گزارش انتشار فقط Pre-release test نیست. SLO، Incident و Error budget می‌توانند ورودی تصمیم باشند. نمونه Policy رسمی Google SRE نشان می‌دهد Error budget زمانی مفید است که Rule اقدام و Owner از قبل نوشته شده باشد؛ مثلاً توقف انتشارهای غیرضروری پس از عبور از Budget.

این Policy را کورکورانه کپی نکنید. SLI، Window، استثنا، Service ownership و اقدام متناسب با کسب‌وکار خود را تعریف کنید.

امنیت و محرمانگی گزارش

Test Report ممکن است Log، URL داخلی، Vulnerability، داده مشتری یا Token را افشا کند. قواعد زیر را اعمال کنید:

• به Evidence امن Link بدهید؛ Secret را داخل گزارش Embed نکنید.
• PII و Credential را پیش از Ingestion Redact کنید.
• Dashboard و Export بر پایه Role کنترل دسترسی داشته باشد.
• گزارش امنیتی عمومی با جزئیات Exploit جدا نگه داشته شود.
• Retention و Disposal مطابق طبقه‌بندی داده باشد.
• Export ارسالی در پیام‌رسان تاریخ انقضا و Watermark داشته باشد.
• نمونه Screenshot از داده مصنوعی استفاده کند.

ملاحظات تیم‌های ایرانی

• Timestamp را هم UTC و هم Asia/Tehran نمایش دهید.
• عدد فارسی در متن مدیریتی و عدد لاتین در شناسه/فرمول را یکدست کنید.
• RTL بودن جدول و Export PDF را پیش از جلسه بررسی کنید.
• برای ابزار SaaS، Export CSV/PDF و دسترسی هنگام اختلال شبکه را آزمایش کنید.
• قیمت را با واحد ریال/تومان و Minor unit صریح گزارش کنید.
• داده PSP و شماره موبایل واقعی را در Dashboard خارجی نفرستید.
• نسخه Snapshot را در مخزن یا فضای سازمانی قابل بازیابی نگه دارید.

برنامه پیاده‌سازی چهار هفته‌ای

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

• سه تصمیم تکراری Release/Control را انتخاب کنید.
• Status، Severity، Risk و Exit را تعریف کنید.
• Metric dictionary و Owner بسازید.
• Baseline و Cut-off را استاندارد کنید.

هفته دوم: مدل داده

• Build، Test، Risk، Defect و Environment را با ID پیوند دهید.
• Check جمع Status و Freshness اضافه کنید.
• Snapshot تغییرناپذیر تولید کنید.
• PII/Secret redaction را تست کنید.

هفته سوم: دو قالب

• Progress Report کوتاه و Completion Report نهایی را اجرا کنید.
• یک Risk heatmap و یک Trend با Annotation بسازید.
• خروجی Executive و Technical را از داده واحد تولید کنید.
• بازخورد مخاطبان را ثبت کنید.

هفته چهارم: Policy و بازبینی

• قرارداد رنگ و Override approval را تصویب کنید.
• Recommendation و Decision owner را جدا کنید.
• یک Release گذشته را با قالب جدید بازسازی کنید.
• متریک‌های بدون تصمیم را حذف کنید.

چک‌لیست کیفیت گزارش تست

• تصمیم و Deadline در ابتدای گزارش آمده است.
• Build، Environment، Suite baseline و Cut-off مشخص‌اند.
• Scope tested، excluded و unknown جدا هستند.
• فرمول و مخرج هر درصد دیده می‌شود.
• Blocked و Not Run زیر Pass Rate پنهان نشده‌اند.
• Risk coverage به Requirement/code coverage تقلیل نیافته است.
• Exit Criteria و Improvement target جدا هستند.
• نقص‌ها با اثر ریسک و Owner گزارش شده‌اند.
• Residual risk، Mitigation و Expiry مشخص است.
• Recommendation از Decision و Risk acceptance جداست.
• Canary، Alert و Rollback برای انتشار مشروط وجود دارد.
• Dashboard زمان تازگی و Data quality status دارد.
• Trend تغییر Baseline و تعریف Metric را Annotation می‌کند.
• گزارش فاقد PII، Token و جزئیات آسیب‌پذیری نامجاز است.
• هر Action مالک و موعد دارد.

منابع معتبر

• ISTQB CTFL v4.0.1؛ Test monitoring، metrics، Progress/Completion report، مخاطب و روش ارتباط.
• ISO/IEC/IEEE 29119-3:2021؛ استاندارد قالب‌های مستندات تست برای چرخه‌های توسعه مختلف.
• Google SRE Error Budget Policy؛ نمونه تبدیل SLO/Error budget به Rule تصمیم و اقدام.

جمع‌بندی

گزارش‌دهی پیشرفته به معنی نمودار و ابزار بیشتر نیست. گزارش حرفه‌ای باید از شمارش فعالیت به تصمیم مبتنی بر ریسک حرکت کند: Snapshot کدام Build است، کدام شواهد کامل یا ناقص‌اند، مخرج درصد چیست، چه ریسک باقی مانده و چه کسی تا چه زمانی آن را می‌پذیرد.

Progress Report برای اصلاح مسیر جاری، Completion Report برای جمع‌بندی در برابر هدف، Dashboard برای مشاهده زنده و Release Memo برای تصمیم چندنقشی است. وقتی این چهار Artifact از یک مدل داده نسخه‌دار و یک Metric dictionary مشترک تغذیه شوند، QA مجبور نیست «ارزش خود را ثابت کند»؛ شواهد، شکاف‌ها و اقدام‌ها به‌طور شفاف ارزش تصمیمی ایجاد می‌کنند.

سوالات متداول گزارش تست

۱. تفاوت Test Progress Report و Test Completion Report چیست؟

Progress Report در طول تست و برای کنترل برنامه، ریسک و مانع تولید می‌شود؛ تناوبش معمولاً بیشتر است. Completion Report در پایان یک Cycle، Level یا فعالیت، نتیجه را در برابر هدف و Exit Criteria جمع‌بندی و ریسک رفع‌نشده و درس‌آموخته را ثبت می‌کند.

۲. آیا Pass Rate بالا یعنی نسخه آماده انتشار است؟

خیر. Pass Rate به مخرج، Scope، ریسک تست‌ها، Blocked/Not Run، شدت Failure و کیفیت Oracle وابسته است. ۹۵٪ Pass ممکن است یک سناریوی حیاتی پرداخت را پنهان کند. آمادگی انتشار باید با Risk coverage و Exit policy ارزیابی شود.

۳. چه کسی تصمیم Go/No-Go را می‌گیرد؟

نقش تصمیم‌گیر باید در Release Policy مشخص باشد و معمولاً Product/Release owner با ورودی QA، فنی، امنیت و عملیات تصمیم می‌گیرد. QA شواهد و Recommendation می‌دهد. اگر سازمان اختیار نهایی را به QA داده، همان Accountability باید صریح و رسمی باشد.

۴. مهم‌ترین متریک‌های گزارش تست کدام‌اند؟

یک فهرست ثابت وجود ندارد. متریک را از تصمیم انتخاب کنید: Risk coverage و Residual risk برای انتشار، Blocked/Not Run برای شکاف شاهد، Flake و زمان بازخورد برای سلامت سیستم تست، و SLO/Error budget برای محصول عملیاتی. هر Metric باید فرمول و اقدام داشته باشد.

۵. Dashboard بهتر است یا گزارش مکتوب؟

هر دو نقش متفاوت دارند. Dashboard وضعیت زنده و قابل فیلتر می‌دهد؛ گزارش مکتوب Snapshot، تفسیر، Recommendation، Risk acceptance و تصمیم را حفظ می‌کند. گزارش باید به Dashboard لینک دهد، اما برای Audit به دادهٔ زنده و تغییرپذیر وابسته نماند.