گزارش خلاصه تست نباید با یک درصد Pass و چراغ سبز، نبود شواهد را پنهان کند. اگر Retry و Duplicate دو بار شمرده شوند، نتیجهٔ Build قبلی وارد گزارش شود یا Not Run از مخرج حذف گردد، عدد ممکن است درست محاسبه شده باشد اما دربارهٔ محصول اشتباه بگوید. Test Summary Report خوب یک Snapshot بستهشده و قابل بازسازی از Scope، Evidence، Gap و Exposure باقیمانده در یک نقطهٔ تصمیم است.
این راهنما مالک «گزارش خلاصه تست بهعنوان Closure Contract» است: Report Identity → Population/Outcome normalization → Risk/Evidence coverage → Findings/Deviations → Residual exposure → Decision/Actions → Archive/Correction. برای طراحی اسلاید، نمودار و ارائهٔ چندلایه به راهنمای ارائه نتایج تست، برای تعریف Strategy/Plan/Summary به راهنمای سه سند تست و برای ساخت Plan زنده به راهنمای نوشتن Test Plan مراجعه کنید.
پاسخ کوتاه: گزارش خلاصه تست چیست؟
Artifact نسخهداری است که در یک Cutoff مشخص، فعالیت و نتایج تست را برای Release/Build و Scope معلوم جمعبندی میکند، انحراف از Plan را نشان میدهد، Evidence موجود و ناموجود را به Riskها وصل میکند، Findings باز و Exposure باقیمانده را ثبت میکند و تصمیمها و اقدامهای Closure را قابل پیگیری نگه میدارد.
| پرسش | پاسخ گزارش | شاهد |
|---|---|---|
| چه چیزی جمعبندی شد؟ | Release/Build/Scope/Plan version | Report Identity |
| چه چیزی اجرا شد؟ | Population و Outcomeهای نرمالشده | Execution Snapshot |
| چه چیزی فهمیدیم؟ | Risk evidence، findings و uncertainty | Risk Closure Map |
| چه چیزی نفهمیدیم؟ | Not run/blocked/invalid/stale/out-of-scope | Gap Register |
| چه تصمیمی شد؟ | Go/Conditional/Hold/Defer با مالک | Decision Record |
| بعد چه میشود؟ | Fix/retest/monitor/rollback/archive | Closure Actions |
Test Summary با Status Report و Dashboard فرق دارد
| Artifact | زمان | پرسش | قابلیت تغییر |
|---|---|---|---|
| Dashboard | زنده | اکنون چه سیگنالی داریم؟ | پیوسته |
| Status report | دورهای | پیشرفت، مانع و Forecast چیست؟ | هر چرخه |
| Incident report | پس از رخداد | چه اتفاقی افتاد و پاسخ چیست؟ | با تحقیق |
| Test Summary | Cutoff/Closure | برای Scope هدف چه Evidence و Gapی باقی است؟ | Frozen + correction |
| Release Memo | نقطه تصمیم | چه گزینهای با چه ریسکی پذیرفته شد؟ | Decision record |
گزارش Summary میتواند در پایان یک Level، Cycle، Sprint، Release candidate یا پروژه ساخته شود؛ فرکانس ثابت «هر دو هفته» ندارد. Trigger باید در Plan و Governance تعریف شود. اطلاعرسانی زندهٔ مانع و پیشرفت در راهنمای ارتباط وضعیت تست مالک جدا دارد.
Snapshot یعنی Facts as of یک Cutoff
Dashboard امروز ممکن است فردا تغییر کند. Summary باید بگوید داده تا چه لحظهای پذیرفته شده، Query/Rule چه بوده و چه Resultهایی بعد از Cutoff وارد نشدهاند. بدون Snapshot، مخاطبان ممکن است از یک URL مشترک دو حقیقت متفاوت ببینند.
Test Summary Identity report_id / version / status: draft | reviewed | frozen | corrected | superseded product / release / target_build / plan_id_version scope_baseline / test_basis_versions execution_window / evidence_cutoff / facts_as_of data_sources / query_or_export_hash author / reviewers / report_owner / decision_owner created_at / frozen_at / supersedes / archive_uri
مرجع استاندارد را نسخهدار و محدود استفاده کنید
ISO/IEC/IEEE 29119-1:2022 مفاهیم عمومی مجموعه را معرفی میکند؛ 29119-2:2021 فرایندهای عمومی تست را و 29119-3:2021 قالبهای مستندات خروجی آن فرایندها را توصیف میکند. صفحات عمومی ISO متن کامل استاندارد نیستند و این مقاله ادعای انطباق یا بازتولید قالب استاندارد ندارد؛ ساختار گزارش باید با Context، Policy و تعهد قراردادی Tailor شود.
Report Identity پیش از Executive Summary میآید
اگر خواننده نداند گزارش دربارهٔ کدام Build، Config، Schema، Flag و Rule set است، Executive Summary قابل استفاده نیست. عنوان «Release ۱۲» ممکن است چند Candidate یا Hotfix داشته باشد. Identity باید به Manifest دقیق و Plan فعال وصل شود.
| Identity | نمونهٔ لازم |
|---|---|
| Code | commit/image/package |
| Database | schema/migration/data baseline |
| Config | environment/config hash |
| Flags | flag set و audience |
| Rules/content | pricing/policy/template/locale versions |
| Dependencies | provider/stub/API contract |
| Test assets | suite/case/charter/model versions |
| Evidence | run/export/query/cutoff identity |
Population را پیش از درصد تعریف کنید
«۱۲۰۰ تست» میتواند Planned cases، Eligible tests، Result events، Attempts یا آخرین Outcome هر Test باشد. هر کدام مخرج دیگری میسازند. Summary باید Population unit، Inclusion/exclusion rule، Deduplication، Retry treatment و Snapshot را روشن کند.
Execution Population Contract population_id / unit: test | scenario | check | assertion | journey planned_set_version / eligible_rule / scope_filter target_build / environment / configuration execution_window / cutoff attempt_identity / retry_policy / final_outcome_rule duplicate_rule / invalidation_rule / foreign_build_rule outcome_vocabulary / denominator_definitions source_query / export_hash / owner
Attempt، Result Event و Final Outcome را جدا کنید
| واحد | معنا | خطای گزارش |
|---|---|---|
| Test definition | آزمون برنامهریزیشده | چند اجرا را چند تست میشماریم |
| Attempt | یک اجرای Test | Retry را Success مستقل میشماریم |
| Result event | پیام/رکورد ابزار | Duplicate delivery وارد مخرج میشود |
| Final outcome | حالت معتبر طبق Rule | آخرین Arrival را بدون Build/attempt میپذیریم |
| Evidence item | Artifact پشتیبان | وجود Log را مساوی Pass میگیریم |
Outcome Vocabulary را قراردادی کنید
| Outcome | تعریف نمونه | در مخرج اجراشده؟ |
|---|---|---|
| Passed | Oracle در Build هدف برآورده شد | بله |
| Failed | Oracle نقض شد | بله |
| Blocked | پیششرط/Dependency مانع نتیجه شد | معمولاً جدا |
| Not run | هیچ Attempt معتبر ندارد | خیر؛ در planned میماند |
| Inconclusive | Evidence نتیجه قطعی نمیدهد | جدا |
| Invalid | Setup/Build/Data نتیجه را نامعتبر کرد | خیر؛ Gap ثبت میشود |
| Waived/Removed | با Authority از Population تغییر کرده | فقط با Trace |
Blocked و Not Run شکست محصول نیستند، اما Evidence موفق هم نیستند. حذف آنها از planned population میتواند Coverage gap را پنهان کند. Summary باید هم توزیع Outcome و هم دلیل Block/عدم اجرا را گزارش کند.
Pass Rate را با مخرج روی عنوان بنویسید
pass_rate_of_executed = passed / (passed + failed) pass_rate_of_valid_attempted = passed / (passed + failed + inconclusive) pass_rate_of_planned = passed / planned_population Always report counts, formula, cutoff, target build and exclusions. Never label different denominators with the same title “Pass Rate”.
هیچکدام از این نسبتها بهتنهایی آمادگی Release یا کیفیت محصول را ثابت نمیکنند. اهمیت Risk، نمایندگی Population، Oracle، Gap و Exposure لازماند. راهنمای ۱۶۷۸ مالک طراحی درست نمودار و Denominator در ارائه است.
Scope Planned، Executed و Reported را reconcile کنید
| Scope class | پرسش |
|---|---|
| Planned | Plan active چه چیزی را متعهد شده بود؟ |
| Added | چه چیزی پس از Plan اضافه و چرا؟ |
| Removed | چه چیزی با چه Authority حذف شد؟ |
| Executed | چه چیزی Attempt معتبر دارد؟ |
| Invalidated | کدام Evidence با Build/Setup دیگر نامعتبر شد؟ |
| Not run/blocked | چه چیزی شاهد ندارد و اثر چیست؟ |
| Reported | کدام Population در Summary آمده؟ |
| Residual | کدام Risk/Variant هنوز نامعلوم است؟ |
Deviation از Plan را بخش اصلی گزارش کنید
Test Plan Deviation deviation_id / plan_item / detected_at planned / actual / reason affected_scope / risks / evidence / schedule decision_owner / approved_by / effective_at compensation / residual_exposure retest_or_monitoring / expiry / status
Summary نباید Plan را طوری بازنویسی کند که انحراف ناپدید شود. تغییر Scope، روش، Environment، Data، Tool، Threshold یا Cutoff باید با دلیل و اثر نشان داده شود. این اطلاعات برای بهبود Planning و ارزیابی Confidence ضروری است.
Risk Closure بهجای Test Count
| فیلد | پرسش Closure |
|---|---|
| risk_id/claim | Failure مورد نگرانی چه بود؟ |
| planned evidence | Plan چه چیزی میخواست؟ |
| valid evidence | برای Build هدف چه چیزی داریم؟ |
| contrary findings | چه شاهد مخالفی وجود دارد؟ |
| coverage boundary | کدام state/variant خارج ماند؟ |
| confidence/uncertainty | چرا و تا چه حد باور داریم؟ |
| residual exposure | چه پیامدی هنوز ممکن است؟ |
| owner/control | چه کسی و با چه اقدام/monitoring؟ |
Risk Closure Map risk_id / claim / priority_rationale plan_version / evidence_required evidence_refs / build / environment / cutoff outcomes / findings / limitations coverage: sufficient | partial | absent | invalid residual_exposure / uncertainty owner / mitigation / monitoring / expiry decision_ref
Defect Count معیار کیفیت محصول نیست
تعداد Defect به Scope، شدت تست، گزارشدهی، Duplicate policy، عمر محصول و طبقهبندی وابسته است. تعداد بالاتر نه خودکار نشانهٔ «عملکرد خوب تیم تست» است و نه کیفیت پایینتر محصول. Defect Density نیز بدون مخرج معنادار، اندازه/پیچیدگی و رفتار کشف قابل تفسیر نیست؛ راهنمای چگالی نقص دامهای آن را جدا بررسی میکند.
| Defect view | اطلاعات لازم | ادعای ممنوع |
|---|---|---|
| Open by impact | user outcome/workaround/owner | هر Critical برابر یکسان |
| Age | created/triage/last evidence | قدیمی یعنی کماهمیت |
| Cluster | scope/test intensity/root cause | ماژول با تعداد بیشتر بدتر است |
| Trend | population/cadence/policy changes | شیب نزولی یعنی آماده انتشار |
| Reopen/escape | definition/build/verification | نسبت واحد علت را ثابت میکند |
Severity، Priority و Business Impact را جدا کنید
| بعد | پرسش | مالک نمونه |
|---|---|---|
| Severity | شدت اثر فنی/کاربری چیست؟ | triage team |
| Priority | چه زمانی باید اقدام شود؟ | product/release owner |
| Probability/Exposure | در چه شرایطی و چه جمعیتی؟ | risk owner |
| Recoverability | کاربر/عملیات چگونه بازیابی میکند؟ | product/operations |
| Detectability | پیش از آسیب دیده میشود؟ | engineering/operations |
| Acceptance | چه کسی حق پذیرش دارد؟ | named authority |
Known Issue را با Risk Acceptance یکی نگیرید
شناختهشدن فقط Discovery را نشان میدهد. پذیرش ریسک به Scope، Impact، Workaround، کنترل، مالک دارای اختیار، شرایط، Monitoring و Expiry نیاز دارد. Summary باید Known issues را به تصمیم واقعی وصل کند؛ فهرست لینکها جای تحلیل Exposure نیست.
Residual Risk Record risk_or_finding_id / affected_outcome / audience trigger / scope / exposure / uncertainty workaround / limitations / support_path preventive_or_detective_controls risk_owner / acceptor / accepted_at conditions / monitoring / rollback_trigger fix_plan / retest / expiry / disclosure
Blocked، Invalid و Not Run را علتیابی کنید
| Gap cause | اثر | اقدام |
|---|---|---|
| Environment unavailable | Evidence absent | owner/recovery/replan |
| Test data missing | state/variant uncovered | fixture action |
| Requirement unresolved | Oracle absent | decision/escalation |
| Build churn | Evidence stale | freeze/retest |
| Dependency failure | end-to-end blocked | contract/stub + limitation |
| Capacity trade-off | Scope reduced | risk acceptance |
| Invalid setup | result unusable | invalidate and rerun |
Non-functional Evidence را به یک وضعیت سبز تبدیل نکنید
| حوزه | Context لازم | Gap نمونه |
|---|---|---|
| Performance | workload/profile/environment/percentile | Production topology متفاوت |
| Security | scope/threat/build/tool/manual review | out-of-scope boundary |
| Accessibility | standard/version/level/AT/browser/process | manual/user evidence absent |
| Reliability | failure model/duration/recovery invariant | rare state untested |
| Compatibility | platform/version/device/data | matrix sampling |
| Privacy | data flow/purpose/retention/role | third-party uncertainty |
اگر حوزهٔ تخصصی Report جدا دارد، Summary نتیجه، Scope و limitation آن را نسخهدار لینک میکند؛ عدد یا رنگ را بدون Context کپی نمیکند.
Environment و Data Limitations بخشی از نتیجهاند
Evidence در محیطی با Stub، حجم کم، Clock متفاوت یا Feature flag محدود، فقط همان Context را پشتیبانی میکند. Summary باید تفاوتهای مهم با Production و اثرشان بر Confidence را ثبت کند. «همه تستها Pass شدند» بدون Environment manifest ادعای ناقص است.
Evidence Limitation limitation_id / evidence_refs environment_or_data_difference affected_risks / claims_not_supported direction_of_bias_if_known compensating_evidence / monitoring owner / disclosure / revisit_trigger
Trend را با Comparable Snapshot بسازید
مقایسه دو Cycle فقط وقتی معتبر است که Population، Rule، Outcome vocabulary، Build scope و Cutoff قابل مقایسه باشند. افزایش کشف و کاهش رفع میتواند ناشی از Scope، triage lag یا تغییر policy باشد. راهنمای شاخصهای پیشرو و پسرو مالک تفسیر زمانی معیارهاست.
| Comparison contract | کنترل |
|---|---|
| Population | same unit/scope or normalized disclosure |
| Definition | same outcome/severity/status rules |
| Window | same cadence/cutoff logic |
| Build/change | release delta explained |
| Tool/query | version/hash stable |
| Missing data | explicit, not zero-filled silently |
| Inference | alternative explanations retained |
Executive Summary باید Claim و Limitation را کنار هم بیاورد
| بخش | محتوا |
|---|---|
| Identity | Release/Build/Scope/Cutoff |
| Decision context | سؤال و Decision owner |
| Supported claims | Outcomeهای دارای Evidence |
| Critical gaps | blocked/not-run/invalid/stale/out-of-scope |
| Residual exposure | اثر، owner، control |
| Recommendation | گزینهها و conditions، نه حکم QA |
| Actions | owner/due/monitor/retest |
| Trace | Report version و Evidence links |
Summary نباید «کیفیت محصول در سطح مطلوب است» بنویسد مگر مطلوببودن به معیار و Scope قابل ردیابی وصل باشد. همچنین نباید برای جلوگیری از نگرانی، خبر مثبت را برجسته و Gap را دفن کند. گزارش وظیفهٔ آرامکردن مخاطب ندارد؛ وظیفهٔ آن پشتیبانی از تصمیم آگاهانه است.
Recommendation با Decision فرق دارد
| Artifact | صاحب | محتوا |
|---|---|---|
| Evidence statement | QA/evaluator | چه شواهد و محدودیتی داریم |
| Recommendation | domain owners | گزینه و دلیل بر پایه Evidence |
| Risk acceptance | authorized owner | Exposure و conditions |
| Release decision | release authority | Go/Conditional/Hold/Defer |
| Operational continuation | operations/product | canary/expand/rollback |
QA میتواند توصیه دهد، اما تصمیم تجاری/عملیاتی و پذیرش ریسک باید به فرد دارای اختیار برسد. گزارش باید Dissent و شرطهای حلنشده را نیز ثبت کند.
Decision Record قابل کپی
Test Closure Decision Record decision_id / report_id_version / decided_at question / options_considered decision: go | conditional | hold | defer decision_owner / participants / dissent evidence_cutoff / supported_claims critical_gaps / residual_risks / uncertainties accepted_risks / conditions / controls actions / owners / due_dates monitoring / rollback_triggers review_or_expiry / correction_policy
Conditional Release باید شرط آزمونپذیر داشته باشد
- Audience یا درصد rollout دقیق؛
- Feature flag/configuration هدف؛
- Monitoring signal و threshold با Context؛
- مالک مشاهده و بازهٔ پاسخ؛
- Rollback/disable trigger؛
- Known limitation و Support path؛
- Fix/retest milestone؛
- شرط گسترش rollout؛
- Expiry تصمیم.
Action Log گزارش را به Closure وصل میکند
| Action type | نمونه | Closure evidence |
|---|---|---|
| Fix | resolve finding | target build + review |
| Retest | risk/state rerun | new outcome |
| Monitor | runtime signal | alert/dashboard snapshot |
| Support | known issue path | runbook/dry run |
| Rollback | operational control | rehearsal |
| Plan/process | repair source/coverage | updated template/strategy |
| Data retention | archive/delete evidence | retention record |
Closure با آمادگی عملیاتی پایان میگیرد
Test completion بهتنهایی Deployment readiness نیست. Runbook، Support، Observability، Rollback، Capacity، Data migration و ownership در راهنمای آمادگی عملیاتی مالک مستقل دارند. Summary باید Evidence مربوط را لینک و Gap آن را در Decision آشکار کند.
Archive باید گزارش را بازسازیپذیر نگه دارد
- Frozen Report و Plan version؛
- Release/Build/Environment/Data manifests؛
- Population export و Query/hash؛
- Outcome normalization و exclusions؛
- Risk Closure، Findings و Deviations؛
- Decision/Risk acceptance/Dissent؛
- Actions، Monitoring و Correctionها؛
- Retention، access classification و deletion؛
- Superseding report و لینک دوطرفه.
Correction را بدون بازنویسی تاریخ منتشر کنید
اگر بعداً Duplicate، Query bug یا Build mismatch کشف شد، گزارش frozen را بیردپا ویرایش نکنید. Correction باید Claim قبلی، خطا، اثر بر تصمیم، مقدار درست، Action و Review را بیان کند. اگر نتیجهٔ اصلی عوض میشود، Decision owner و مصرفکنندگان باید اعلان قابل اثبات دریافت کنند.
Test Summary Correction correction_id / report_id_version / issued_at incorrect_claim_or_value / cause affected_sections / decisions / consumers corrected_value / evidence_ref decision_impact / action / owner notified_at / acknowledgements superseding_report / prevention
Automation باید Snapshot را بسازد، نه داستان دلخواه را
اتوماسیون میتواند Export، Deduplication، Build filter، Outcome normalization، Denominator، Link و Reconciliation را پایدار کند. ابزار نمیتواند خودکار تصمیم بگیرد کدام Exposure پذیرفتنی است یا یک Risk claim چقدر مهم است. Dashboard vendor نیز با چند کلیک «دقت را بهشدت» تضمین نمیکند؛ Rule و Source باید ممیزی شوند.
| Control | ماشینی | انسانی |
|---|---|---|
| Build filter/dedup | قوی | Rule approval |
| Population reconciliation | قوی | Scope meaning |
| Pass-rate formula | قوی | relevance |
| Risk mapping completeness | قابل بررسی | evidence sufficiency |
| Residual exposure | ضعیف | domain judgment |
| Recommendation/decision | نامناسب | authorized review |
آزمایش بازتولیدپذیر: Event GO در برابر Snapshot HOLD
Fixture کاملاً ساختگی SYN-TEST-SUMMARY-01 ده Test برنامهریزیشده و یازده Result event دارد. شمارش خام هر Eventِ Passed را مستقل میگیرد. Closure Snapshot فقط Build هدف را میپذیرد، Attempt تکراری را حذف میکند و آخرین Outcome معتبر هر Test را روی Planned population مینشاند.
$ node .post-1827-experiment.js runtime: Node.js v24.18.0 fixture: SYN-TEST-SUMMARY-01 target: SYN-REL-12+build.88 naive result events = 11 naive passed events = 9 naive pass rate = 81.8% naive decision = GO planned population = 10 final outcomes: passed=7, failed=0, blocked=1, not-run=2 pass rate of planned = 70% excluded: one duplicate attempt + one result from build.87 critical gaps: SYN-T04 blocked + SYN-T05 not-run for SYN-R2 residual risk SYN-R2 owner = missing findings: critical-risk-without-passing-evidence + residual-risk-without-owner closureSnapshot.decision = HOLD
۸۱٫۸٪ و ۷۰٪ هر دو از فرمولهای تعریفشدهٔ Fixture بهدست میآیند؛ اختلاف از Population و Rule است. هیچکدام آستانهٔ عمومی نیستند. HOLD به دو Gap بحرانی و مالک مفقود قراردادی وابسته است، نه صرفاً درصد.
حدود اعتبار آزمایش مصنوعی
- همهٔ Testها، Riskها، Buildها، Eventها و Outcomeها ساختگیاند.
- هیچ Runner، محصول، API، Database، کاربر یا محیط واقعی اجرا نشده است.
- ده Test، یازده Event، ۸۱٫۸٪ و ۷۰٪ Benchmark یا Threshold نیستند.
- مدل «آخرین Attempt» برای همهٔ Suiteها یا Retest policyها نسخهٔ عمومی نیست.
- GO/HOLD گواه کیفیت، احتمال شکست یا الگوریتم Release نیست.
- آزمایش فقط حسابداری Population و Contract نوشتهشده را نشان میدهد.
آزمایشگاه فارسی کاملاً ساختگی
در محیط محلی بدون اینترنت، Release خیالی SYN-REL-FA-01 با ۱۲ Test خیالی بسازید. Outcomeهای Passed/Failed/Blocked/Not Run، Retry، Duplicate، Build قدیمی، Scope change و Risk owner را Seed کنید. هیچ نام، شرکت، کاربر، حساب، پرداخت، Token، Secret، Ticket یا دادهٔ Production وارد نشود.
| Fault | کنترل Summary | Evidence |
|---|---|---|
| Duplicate result | attempt identity | exclusion log |
| Build قدیمی | target-build filter | foreign result list |
| Not Run حذفشده | planned reconciliation | gap register |
| Scope تغییرکرده | deviation record | approval |
| Risk بیمالک | closure validator | HOLD/action |
| Query خراب | export hash/correction | superseding report |
| اعداد فارسی/لاتین | canonical numeric data | format parity |
| لینک Evidence شکسته | link/access check | archive repair |
این Lab تمرین Snapshot، Traceability و Correction است؛ دربارهٔ صنعت ایران، کیفیت محصول، نرخ Defect یا تصمیم واقعی ادعایی ندارد.
قالب Test Summary Report یکصفحهای
[Report ID/version/status] [Release/Build] [Cutoff] Decision question / decision owner / decision time Scope: planned / added / removed / executed / not-evidenced Outcome population: counts + denominator + rule Critical Risk Closure: supported / partial / absent / invalid Open findings and residual exposure: impact / owner / control Plan deviations and evidence limitations Recommendation options and explicit uncertainty Decision / conditions / dissent Actions: fix / retest / monitor / rollback / due Links: full report / frozen exports / evidence / plan / decision log
قالب Full Test Summary Report
| بخش | محتوای حداقلی |
|---|---|
| Identity | report/release/build/plan/scope/cutoff/source |
| Executive summary | claims/gaps/exposure/recommendation |
| Test context | objective/basis/environment/data |
| Scope reconciliation | planned/changed/executed/invalid/not-run |
| Activity | methods/levels/effort فقط در حد تصمیم |
| Outcome accounting | population/rules/counts/denominators |
| Risk closure | evidence/findings/coverage/uncertainty |
| Defects/findings | impact/status/owner/retest—not raw count alone |
| Deviations/limitations | Plan/environment/data/tool/gap |
| Residual risks | exposure/control/acceptance/expiry |
| Decision | option/authority/conditions/dissent |
| Actions | fix/retest/monitor/support/rollback |
| Archive | evidence/export/hash/retention/correction |
چه چیزی را از Summary حذف کنیم؟
- تمام Logها و Screenshotها؛ لینک نسخهدار کافی است.
- فهرست کامل Test Caseها؛ Population manifest را ارجاع دهید.
- تکرار Requirement؛ Scope/source version را بدهید.
- Tool marketing و Screenshot Dashboard؛ Rule/query را ثبت کنید.
- داستانسرایی بدون Evidence یا نقلقول تزئینی؛
- Metricهایی که به Decision یا یادگیری وصل نیستند؛
- اطلاعات شخصی، Secret و دادهٔ حساس؛
- علتهای قطعی بدون RCA یا Evidence کافی.
مخاطبهای مختلف، Claimهای متفاوت نه
CEO، Product و Engineering میتوانند Viewهای متفاوتی از یک Evidence Packet داشته باشند، اما Fact، denominator و Risk نباید تغییر کند. مدیر اجرایی به Exposure و گزینه، توسعهدهنده به Trace و Root cause، عملیات به Control و rollback نیاز دارد. سادهسازی یعنی حذف جزئیات نامرتبط، نه نرمکردن حقیقت.
نمودار را فقط وقتی استفاده کنید که رابطه را روشن کند
| رابطه | نمای مناسب | پرهیز |
|---|---|---|
| Outcome distribution | bar + counts | pie با بخشهای نزدیک/بدون مخرج |
| Trend comparable | line با event/definition notes | دو محور گمراهکننده |
| Risk × evidence | matrix/table | heatmap بدون legend |
| Age/status | stacked bar/table | میانگین تنها |
| Scope flow | funnel/reconciliation table | Pass rate تنها |
همیشه دادهٔ متنی/جدولی دسترسپذیر، Label، واحد، منبع، Cutoff و تعریف فراهم کنید. طراحی بصری عمیقتر در صفحهٔ ۱۶۷۸ میماند.
شاخص کیفیت گزارش Summary
| شاخص | پرسش | دام |
|---|---|---|
| Reproducibility | از Export/Rule همان اعداد ساخته میشوند؟ | فایل دستی |
| Trace completeness | Claim تا Build/Evidence میرسد؟ | لینک بدون identity |
| Population reconciliation | planned تا reported حساب میشود؟ | حذف silent |
| Critical-risk gap visibility | Gap بالای صفحه دیده میشود؟ | دفن در ضمیمه |
| Decision/action closure | owner/due/expiry دارد؟ | recommendation بیمالک |
| Correction latency | خطای گزارش چه زمان اصلاح میشود؟ | ویرایش بیردپا |
| Consumer comprehension | مخاطب denominator/limitation را درست میفهمد؟ | View count |
برنامهٔ Pilot سیروزه
| بازه | کار | خروجی |
|---|---|---|
| روز ۱–۳ | انتخاب یک Cycle و Decision | Summary scope |
| روز ۴–۶ | Identity/Source/Cutoff registry | Report contract |
| روز ۷–۱۰ | Population و Outcome rules | reconciliation query |
| روز ۱۱–۱۳ | Risk Closure mapping | closure matrix |
| روز ۱۴–۱۶ | Defect/Gap/Deviation normalization | registers |
| روز ۱۷–۱۹ | Residual risk/Action templates | decision-ready draft |
| روز ۲۰–۲۲ | Automation/export/hash checks | reproducible snapshot |
| روز ۲۳–۲۵ | Audience review/accessibility | one-page + full views |
| روز ۲۶–۲۷ | Freeze/Decision dry run | frozen report |
| روز ۲۸–۳۰ | Correction/Archive retrospective | process improvements |
ضدالگوهای گزارش خلاصه تست
- گزارش زنده و متغیر بدون Cutoff؛
- عنوان Release بدون Build/Config identity؛
- شمارش Event بهجای Final Outcome؛
- شمارش Retry و Duplicate بهعنوان Test مستقل؛
- ترکیب نتیجهٔ Buildهای مختلف؛
- Pass rate بدون denominator و counts؛
- حذف Blocked/Not Run از Planned population؛
- تبدیل Invalid به Passed پس از Rerun بدون history؛
- Scope reported بدون reconcile با Plan؛
- پنهانکردن Deviation؛
- Test count بهعنوان Risk coverage؛
- Defect count بهعنوان کیفیت یا ارزش QA؛
- Defect Density بهعنوان حکم کیفیت پایین؛
- Trend با تعریف/Population متفاوت؛
- رنگ سبز برای حوزهٔ بدون Evidence؛
- Known issue بهعنوان Risk acceptance؛
- Severity بهجای Business impact؛
- Report تخصصی بدون Scope/limitations؛
- «کیفیت مطلوب» بدون معیار؛
- برجستهکردن نکات مثبت برای آرامکردن مدیر؛
- داستانسرایی بهجای Evidence؛
- توصیه QA بهعنوان تصمیم Release؛
- Risk بیمالک یا پذیرش بدون اختیار؛
- Conditional Go بدون threshold/rollback/expiry؛
- Action بدون owner/due؛
- Dashboard tool بهعنوان Source قطعی؛
- فایل خروجی بدون Query/hash؛
- ویرایش گزارش frozen بدون Correction؛
- Viewهای مخاطب با Factهای متفاوت؛
- Archive بدون retention و supersession.
چکلیست گزارش خلاصه تست معنادار
- Report ID، version و status داریم.
- Release/Build/Config/Flag identity کامل است.
- Plan و Scope baseline نسخهدارند.
- Execution window و Cutoff روشناند.
- Data source، Query و Export hash ثبتاند.
- Population unit تعریف شده است.
- Planned/eligible/executed/report populations جدا هستند.
- Attempt identity و Retry policy داریم.
- Duplicate rule تعریف شده است.
- Foreign-build results حذف/افشا شدهاند.
- Final outcome rule روشن است.
- Passed/Failed/Blocked/Not Run/Inconclusive/Invalid تعریفاند.
- Counts کنار درصد هستند.
- Denominator در عنوان Metric آمده است.
- Blocked و Not Run پنهان نشدهاند.
- Scope با Plan reconcile شده است.
- Added/Removed/Invalidated ثبتاند.
- Deviation دلیل و Authority دارد.
- هر Risk به Evidence معتبر وصل است.
- Critical gap در Executive Summary دیده میشود.
- Coverage boundary و uncertainty ثبت است.
- Defect count حکم کیفیت نیست.
- Severity/Priority/Exposure جدا هستند.
- Known issue پذیرش ریسک فرض نشده است.
- Residual risk owner و acceptor دارد.
- Workaround limitation و Support path دارد.
- Non-functional result Context دارد.
- Environment/Data limitation افشا شده است.
- Trend فقط روی Snapshot comparable است.
- Executive claims به Evidence drill-down دارند.
- Recommendation از Decision جداست.
- Decision owner اختیار لازم دارد.
- Dissent و alternatives ثبت میشوند.
- Conditional release controls آزمونپذیرند.
- Rollback trigger و Monitoring مشخصاند.
- Actionها owner/due/closure evidence دارند.
- Operational readiness لینک/Gap دارد.
- Report frozen بازنویسی نمیشود.
- Correction مسیر رسمی و notification دارد.
- Archive شامل exports/rules/evidence است.
- Retention و access classification داریم.
- Viewهای مخاطب از Fact مشترک میآیند.
- نمودار Label/unit/source/cutoff دارد.
- نمای متنی دسترسپذیر موجود است.
- اطلاعات شخصی و Secret حذف شدهاند.
- Report quality با trace/reconcile/action سنجیده میشود.
- پنج FAQ و Meta قبل انتشار کنترل شدهاند.
جمعبندی: Summary باید Evidence را منجمد کند، نه ابهام را
گزارش خلاصه تست معنادار از اعداد خام به Snapshot قابل ممیزی میرود: Identity و Cutoff را قفل میکند، Population و Outcome را نرمال میکند، Scope را با Plan reconcile میکند، Risk را به Evidence و Gap وصل میکند، Exposure را بیمالک نمیگذارد و Decision/Action/Correction را حفظ میکند. کوتاهی خوب از Drill-down میآید، نه حذف Denominator و محدودیت.
سؤالات متداول گزارش خلاصه تست
تفاوت Test Summary Report با Status Report چیست؟
Status Report در طول کار، پیشرفت، مانع و Forecast را دورهای میگوید. Test Summary در Cutoff مشخص، Scope و Evidence یک Cycle/Level/Release را جمعبندی و برای Closure/Decision منجمد میکند. Dashboard زنده میتواند منبع باشد، اما جای Snapshot نسخهدار را نمیگیرد.
Pass Rate را چگونه در گزارش بنویسیم؟
Counts، Population، فرمول، Build، Cutoff و رفتار Blocked/Not Run/Inconclusive را کنار نسبت بنویسید. «Pass rate of executed» با «Pass rate of planned» متفاوت است. هیچ درصدی بهتنهایی آمادگی Release یا پوشش Risk را ثابت نمیکند.
آیا گزارش خلاصه تست باید Go یا No-Go اعلام کند؟
گزارش باید Evidence، Gap، Exposure، گزینهها و توصیهٔ مستدل را ارائه کند. تصمیم Go/Conditional/Hold/Defer و پذیرش ریسک باید توسط Owner دارای اختیار ثبت شود. QA ممکن است Recommendation بدهد، اما بهطور پیشفرض مالک همهٔ ریسک یا تصمیم Release نیست.
هر چند وقت یکبار Test Summary تهیه کنیم؟
فرکانس ثابت ندارد. Trigger میتواند پایان Test Level/Cycle، Release candidate، Gate قراردادی، Sprint یا Closure پروژه باشد. برای ارتباط روزانه/هفتگی از Status و Dashboard استفاده کنید؛ Summary را زمانی Freeze کنید که یک Snapshot برای تصمیم یا بایگانی لازم است.
آیا ابزار مدیریت تست میتواند گزارش را خودکار بسازد؟
میتواند Export، counts، Deduplication، Build filter و View را خودکار کند، اما Population rule، کفایت Risk evidence، Exposure، Recommendation و تصمیم به قرارداد و قضاوت انسانی نیاز دارند. Tool/version/query/hash و Correction policy را ثبت کنید و Dashboard را حقیقت بدون زمینه ندانید.
