گزارش اختتامیه تست؛ قالب آماده برای تصمیم انتشار

آخرین بازبینی فنی: مرداد ۱۴۰۵

تصور کنید ۲۴۰ تست برای نسخه جدید پرداخت دارید: ۲۰۱ Pass، هشت Fail، شش Blocked و ۲۵ مورد Not Run. نوشتن «نرخ موفقیت ۹۶٪» ممکن است از نظر یک فرمول درست باشد، اما برای تصمیم انتشار گمراه‌کننده است؛ چون آن ۹۶٪ فقط میان نتیجه‌های قطعی Pass/Fail محاسبه شده و ۳۱ تست اجرا‌نشده یا مسدود را پنهان می‌کند. اگر سناریوی بازگشت وجه میان آن‌ها باشد، یک درصد زیبا به‌جای Evidence، ریسک می‌سازد.

گزارش اختتامیه تست یا اصطلاح دقیق‌تر امروزی Test Completion Report باید این ابهام را حذف کند: چه چیزی، روی کدام Build و Environment، با چه Coverage و Oracle آزموده شد؛ چه چیزی آزموده نشد؛ Exit Criteria کدام‌اند؛ چه ریسک‌هایی باقی مانده‌اند؛ و چه کسی با دانستن آن‌ها تصمیم گرفته است.

مرز این راهنما با بستن چرخه تست

راهنمای فاز ششم STLC کل فرآیند Test Completion را پوشش می‌دهد: بررسی معیار خروج، جمع‌آوری و آرشیو Testware، بازگرداندن Environment، بستن/انتقال آیتم‌های باز، Retrospective و خاتمه چرخه. مقاله حاضر مالک Intent دیگری است: چگونه خروجی آن فرآیند را به گزارش قابل‌تصمیم برای Stakeholder تبدیل کنیم؟

کلمه کلیدی اصلی «گزارش اختتامیه تست» است. عبارت‌های فرعی شامل گزارش تکمیل تست، گزارش نهایی تست، Test Completion Report، Test Summary Report، قالب گزارش تست و گزارش آمادگی انتشار هستند. هدف، ارائه یک Template عملی است؛ نه تکرار تعریف عمومی STLC.

Test Completion Report یا Test Summary Report؟

در ISTQB CTFL 4.0.1 اصطلاح جاری Test Completion Report است. منابع و تیم‌های قدیمی‌تر ممکن است Test Summary Report یا Test Closure Report بگویند. در سند خود یک نام اصلی انتخاب و Aliasها را یک‌بار ذکر کنید تا Search و آرشیو هر دو کار کنند.

تعریف عملی

Test Completion Report گزارشی است که یک Test Activity مشخص—مانند Test Level، Test Type، Cycle، Iteration یا Release—را پس از تکمیل یا توقف جمع‌بندی می‌کند. این گزارش، ارزیابی Testing و Product Quality را نسبت به Test Plan، Objective و Exit Criteria ارائه می‌دهد و Deviation، Impediment، Metric، Defect حل‌نشده، Unmitigated Risk و Lessons Learned را آشکار می‌کند.

Completion لزوماً Success نیست

چرخه ممکن است با برآورده‌شدن معیارها، پایان Timebox، لغو پروژه، تغییر Scope یا پذیرش آگاهانه ریسک تکمیل شود. عبارت «تست کامل شد» نباید به «همه چیز Pass شد» ترجمه شود. Reason for completion و Criteria status را جدا ثبت کنید.

استاندارد قالب را تحمیل نمی‌کند

صفحه رسمی سری ISO/IEC/IEEE ۲۹۱۱۹ توضیح می‌دهد Test Documentation در Part ۳ خروجی اجرای Test Processهاست. این به معنی یک فایل Word ثابت برای همه تیم‌ها نیست. سطح Formality، Approval و Detail باید با Risk، قرارداد، اندازه تیم و Audience سازگار شود.

تفاوت گزارش وضعیت، تکمیل و تصمیم انتشار

Test Completion Report ورودی مهم Release Readiness است، اما همه آن نیست. Security exception، Migration rehearsal، Backup/restore، Capacity، Monitoring، Runbook، Rollback و Business approval ممکن است خارج از مالکیت تیم تست باشند و باید به‌صورت Evidence link یا Gap دیده شوند.

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

• پایان یک Test Level مانند System یا Acceptance Testing؛
• پایان Test Type پرریسک مانند Performance یا Security؛
• پایان Sprint/Iteration، اگر Decision معناداری در پی دارد؛
• پیش از Release candidate promotion؛
• پایان پروژه، Maintenance release یا Migration rehearsal؛
• هنگام Cancel/Stop شدن Activity، با Reason و Gap صریح.

گزارش را بعد از آخرین Run قابل‌اعتماد و پیش از Decision window تولید کنید. گزارشی که سه روز بعد از Release آماده شود، بیشتر Archive است تا ابزار تصمیم.

اول هویت Evidence را قفل کنید

هر عدد بدون Context قابل سوءبرداشت است. Header گزارش باید این هویت را داشته باشد:

• report_id و version: شناسه یکتا و Revision؛
• as_of: Cut-off timestamp و Time zone؛
• product/release: نسخه محصول و Release candidate؛
• artifact identity: Git SHA، Image digest، Package checksum یا Build ID؛
• test basis: Requirement/Story/Risk/Contract version؛
• environment: Config/Dependency/Feature flag/Schema identity؛
• data: Dataset ID، Seed/refresh و Privacy class؛
• scope window: Test Level/Type، شروع و پایان؛
• evidence location: لینک Artifactهای immutable با Access policy؛
• owner/reviewer: تهیه‌کننده، Reviewer و Decision Owner.

گزارش روی «نسخه ۲.۷» کافی نیست اگر چند Build با همان Label وجود دارد. همچنین Screenshot داشبورد بدون timestamp، Query، Filter و denominator، Evidence بازتولیدپذیر نیست.

معماری پیشنهادی: یک صفحه تصمیم + پیوست فنی

لایه اول: Decision Card

مدیر محصول یا Release Owner باید در کمتر از دو دقیقه این موارد را ببیند:

1. کدام Artifact و Scope بررسی شده است؟
2. Recommendation چیست: Go، Conditional Go یا No-Go؟
3. کدام Exit Criteria Pass/Fail/Not Evaluated هستند؟
4. وضعیت Journeyها و Quality Attributeهای بحرانی چیست؟
5. سه Risk باقی‌مانده مهم، Impact و Exposure window کدام‌اند؟
6. چه شرط، Monitoring، Rollback یا Ownerی ریسک را کنترل می‌کند؟
7. Decision موردنیاز، صاحب تصمیم و Deadline چیست؟

لایه دوم: Technical Appendix

Appendix جزئیات قابل‌ممیزی را نگه می‌دارد: Test Basis traceability، Result status، Defect list، Run/Environment/Data manifest، Tool version، Raw evidence، Deviation، Formula/Query، Flaky/Retry history، Lessons و Action item. مدیر مجبور نیست آن را کامل بخواند، اما Reviewer باید بتواند هر ادعا را تا Source دنبال کند.

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

ISTQB تأکید می‌کند Audience روی محتوا و Formality گزارش اثر دارد. راه‌حل، ساخت چند حقیقت متفاوت نیست؛ یک Evidence model واحد و چند View است. Executive Summary، Engineering Appendix و Audit Export باید همان Build، Cut-off و Risk IDها را نشان دهند.

اجزای ضروری گزارش اختتامیه تست

۱. خلاصه مدیریتی

سه تا هفت Bullet کافی است: Objective، Scope، Outcome، بزرگ‌ترین Gap، Residual risk، Recommendation و Ask. به‌جای «کیفیت مطلوب است» بنویسید: «Checkout و Refund روی Build X Pass؛ PSP timeout به‌دلیل Sandbox outage Not Evaluated؛ ریسک R-۱۷ با Monitoring و Rollback شرطی باقی است.»

۲. Scope، Test Basis و Out of Scope

Feature، Journey، Platform، Browser/Device، API version، Locale، Role و Quality Attributeهای داخل Scope را مشخص کنید. Out of Scope باید Reason و Risk داشته باشد؛ عبارت «طبق برنامه» بدون لینک به Test Plan و Exit Criteria قابل‌ممیزی نیست.

۳. معیارهای ورود/خروج و وضعیت آن‌ها

Status را Met/Not Met/Not Evaluated/Not Applicable تعریف کنید. «Partial» بدون توضیح، Decision را به حدس تبدیل می‌کند.

۴. خلاصه اجرای تست با وضعیت‌های روشن

حداقل Pass، Fail، Blocked، Skipped، Not Run و Inconclusive را جدا کنید. راهنمای اجرای تست تفاوت Result، Evidence و Defect را توضیح می‌دهد. Blocked یعنی Test Object/Environment/Dependency اجازه قضاوت نداده؛ نه Pass است و نه Fail.

۵. Coverage نسبت به Risk و Test Basis

تعداد Test Case به‌تنهایی نمی‌گوید چه چیزی پوشش گرفته است. Requirement، Risk، Journey، Rule، Boundary، Platform یا Code item را به Result وصل کنید. Traceability کمک می‌کند Stakeholder ببیند کدام Business goal Evidence دارد و کدام نه.

۶. Defect و Known Issue

برای Defectهای باز، ID، Summary، Severity، Priority، affected scope، reproducibility، workaround، owner، target fix و linked risk بیاورید. Severity اثر فنی/کاربری و Priority ترتیب رسیدگی است؛ آن‌ها را یکی نکنید. جزئیات بازتولید باید در Bug Report بماند و گزارش تکمیل فقط View تصمیمی ارائه دهد. وضعیت‌هایی مانند Deferred یا Reopened نیز باید از Workflow چرخه عمر باگ خوانده شوند، نه اینکه داخل گزارش دوباره تعریف شوند.

۷. Deviation و Impediment

هر اختلاف با Plan را با علت و اثر بنویسید: Device حذف‌شده، Environment دیررس، Test data ناکافی، Tool outage، Scope change، زمان کمتر یا Retry بیش از Policy. «همه تست‌های برنامه‌ریزی‌شده اجرا شد» بدون ثبت تغییر برنامه، واقعیت تاریخی را تحریف می‌کند.

۸. ریسک باقی‌مانده

Risk صرفاً لیست Defect نیست. ممکن است هیچ Defect ثبت‌شده‌ای نداشته باشید اما یک Journey تست‌نشده، Dependency ناپایدار یا داده غیرنماینده Risk بسازد. روش تست مبتنی بر ریسک را برای Likelihood، Impact، Exposure و Residual level به کار ببرید.

۹. Recommendation و Conditions

Recommendation نظر حرفه‌ای مبتنی بر Evidence است، نه گواهی بی‌نقص‌بودن. قالب:

Recommendation = decision + scope + confidence + conditions + expiry

مثال: «Conditional Go برای rollout پنج‌درصدی Checkout روی Build sha256:…؛ مشروط به Pass شدن PSP timeout تا ساعت ۱۴، فعال‌بودن Duplicate-payment alert، Owner عملیات و rollback زیر ده دقیقه. Recommendation پس از تغییر Artifact یا Config منقضی است.»

۱۰. Decision Record

Report author و Decision owner را جدا کنید. QA می‌تواند Evidence و Recommendation بدهد؛ Product/Business/Release governance طبق RACI ریسک را می‌پذیرد. Record شامل Decision، approver، accepted risk IDs، conditions، timestamp، expiry و reason است. Sign-off نباید مسئولیت جمعی را به یک امضای صوری QA منتقل کند.

۱۱. Lessons و Action Item

هر Lesson باید به Action قابل‌پیگیری تبدیل شود: مشکل، شاهد، اقدام، Owner، due date و success measure. «هماهنگی بهتر شود» Lesson نیست. «Contract sandbox تا Sprint بعد با synthetic timeout fixture و health check مستقل شود» قابل اجراست.

۱۲. Evidence و Retention

لینک Run log، JUnit، Traceability، Performance result، Security evidence، Environment/Data manifest و Defect snapshot را اضافه کنید. Access، Retention، Classification و Hash/Version را ثبت کنید. PII، Secret، Token یا Payload حساس را داخل PDF گزارش کپی نکنید.

قالب آماده گزارش تکمیل تست

این Template را متناسب با Risk کوتاه یا رسمی کنید. Field حذف‌شده باید آگاهانه حذف شود، نه به‌دلیل نبود داده.

# Test Completion Report — [Product / Release]

Report ID / Version:
As of (timestamp + zone):
Artifact: [Git SHA / image digest / build ID]
Test basis: [versioned requirements / risks / contracts]
Environment & data: [manifest IDs]
Prepared / reviewed by:
Decision owner / deadline:

## 1) Decision card
- Objective and scope:
- Recommendation: Go | Conditional Go | No-Go
- Confidence: High | Medium | Low — because ...
- Top residual risks: [R-ID, impact, likelihood, exposure]
- Conditions / monitoring / rollback:
- Decision requested:

## 2) Exit criteria
| Criterion | Target | Actual + evidence | Status | Owner/action |

## 3) Critical journeys and quality attributes
| Journey/attribute | Risk tier | Result | Evidence | Gap/impact |

## 4) Execution accounting
| Planned | Pass | Fail | Blocked | Skipped | Not run | Inconclusive |
- Status definitions and formulas:
- Retries / flaky / quarantine:

## 5) Coverage and traceability
- Requirements / risks / rules / platforms covered:
- Explicit gaps and out-of-scope items:

## 6) Open defects and known issues
| ID | Severity | Affected scope | Workaround | Owner | Target | Risk ID |

## 7) Deviations and impediments
| Plan item | Actual | Cause | Evidence impact | Follow-up |

## 8) Residual-risk register
| Risk ID | Evidence/gap | Likelihood | Impact | Mitigation | Owner | Expiry |

## 9) Decision record
- Decision / timestamp:
- Approver(s):
- Accepted risks and conditions:
- Reason / expiry:

## 10) Lessons and actions
| Observation | Evidence | Action | Owner | Due | Success measure |

## 11) Evidence index
- Test runs / JUnit / dashboards:
- Environment & data manifests:
- Defect snapshot / security / performance:
- Retention, access and classification:

شاخص‌ها را بدون فریب مخرج گزارش کنید

جمع وضعیت‌ها باید بسته باشد

برای Snapshot تعریف کنید:

Planned = Pass + Fail + Blocked + Skipped + Not Run + Inconclusive

اگر جمع برابر نیست، Scope تغییر کرده، Duplicate دارید یا Status تعریف‌نشده‌ای گم شده است. قبل از ساخت Dashboard آن را حل کنید.

Pass Ratio دقیقاً چه می‌گوید؟

اگر تیم توافق کند:

Result Pass Ratio = Pass ÷ (Pass + Fail)

این نسبت فقط میان Resultهای قطعی است. Blocked، Not Run و Inconclusive را کنار آن نمایش دهید. Pass Ratio نه Coverage است، نه Probability نبودن Defect، نه مجوز Release.

به‌جای یک درصد، چند سیگنال مکمل بدهید

• Attempt rate: (Pass + Fail + Blocked + Inconclusive) ÷ Planned؛
• Decisive result rate: (Pass + Fail) ÷ Planned؛
• Risk coverage: Risk itemهای دارای Evidence ÷ Risk itemهای in-scope؛
• Exit criteria status: Met/Not Met/Not Evaluated، نه میانگین مبهم؛
• Open exposure: Risk level + affected journey + exposure time؛
• Freshness: فاصله آخرین Evidence تا Decision و تغییرات پس از آن.

شاخص‌های پرکاربرد اما ناکافی

• تعداد Defect خام بدون Scope، Severity، Discovery opportunity و زمان؛
• Defect density برای مقایسه تیم‌ها یا زبان‌های متفاوت؛
• Automation percentage به‌عنوان Quality outcome؛
• Code coverage بدون Assertion، Risk و behavior coverage؛
• تعداد Test Case به‌عنوان ارزش تست؛
• «صفر Defect باز» وقتی بخش مهمی Not Run است؛
• میانگین Response time به‌جای percentile، error و saturation؛
• Trend بدون ثابت‌بودن Query، Scope و denominator.

ISO/IEC 25010:2023 Product Quality را در چند Quality characteristic و subcharacteristic مدل می‌کند. این یادآوری مهمی است که یک Pass rate یا «Quality score» واحد، ابعاد کارکردی، کارایی، امنیت، قابلیت تعامل، قابلیت نگهداری و Safety را جایگزین نمی‌کند.

مثال اجرایی محاسبه و Gate

کد زیر با Node.js داخلی اجرا می‌شود. هدف آن ابزار Release کامل نیست؛ قرارداد عددی گزارش را شفاف و Testable می‌کند.

import test from "node:test";
import assert from "node:assert/strict";

const statuses = ["passed", "failed", "blocked", "skipped", "notRun", "inconclusive"];

function percent(value, total) {
  return total === 0 ? null : Number(((value / total) * 100).toFixed(1));
}

function summarize(summary) {
  for (const key of ["planned", ...statuses]) {
    if (!Number.isInteger(summary[key]) || summary[key] < 0) {
      throw new Error(`${key} must be a non-negative integer`);
    }
  }

  const accounted = statuses.reduce((total, key) => total + summary[key], 0);
  if (accounted !== summary.planned) {
    throw new Error(`status total ${accounted} does not equal planned ${summary.planned}`);
  }

  const decisive = summary.passed + summary.failed;
  const attempted = decisive + summary.blocked + summary.inconclusive;
  return {
    accounted,
    decisive,
    attempted,
    resultPassRatio: percent(summary.passed, decisive),
    decisiveResultRate: percent(decisive, summary.planned),
    attemptRate: percent(attempted, summary.planned)
  };
}

function recommend({ summary, criteria, risks }) {
  summarize(summary);
  const criticalGap = criteria.some(item =>
    item.critical && item.status !== "met"
  );
  const unacceptedHighRisk = risks.some(risk =>
    risk.level === "high" && risk.accepted !== true
  );

  if (criticalGap || unacceptedHighRisk) return "no-go";

  const nonCriticalGap = criteria.some(item => item.status !== "met");
  const acceptedRisk = risks.some(risk => risk.accepted === true);
  const unresolvedExecution = summary.blocked + summary.notRun + summary.inconclusive > 0;
  return nonCriticalGap || acceptedRisk || unresolvedExecution
    ? "conditional-go"
    : "go";
}

const report = {
  summary: {
    planned: 240,
    passed: 201,
    failed: 8,
    blocked: 6,
    skipped: 0,
    notRun: 25,
    inconclusive: 0
  },
  criteria: [
    { id: "PAY-01", critical: true, status: "met" },
    { id: "REF-01", critical: true, status: "met" },
    { id: "PERF-01", critical: false, status: "not-evaluated" }
  ],
  risks: [
    { id: "R-17", level: "medium", accepted: true, owner: "release-owner" }
  ]
};

test("all planned tests have exactly one status", () => {
  assert.equal(summarize(report.summary).accounted, 240);
});

test("pass ratio excludes blocked and not-run results", () => {
  const metrics = summarize(report.summary);
  assert.equal(metrics.decisive, 209);
  assert.equal(metrics.resultPassRatio, 96.2);
  assert.equal(metrics.decisiveResultRate, 87.1);
});

test("the example remains conditional despite a high pass ratio", () => {
  assert.equal(recommend(report), "conditional-go");
});

test("a critical evidence gap forces no-go", () => {
  const changed = structuredClone(report);
  changed.criteria[0].status = "blocked";
  assert.equal(recommend(changed), "no-go");
});

test("inconsistent status totals are rejected", () => {
  const invalid = { ...report.summary, notRun: 24 };
  assert.throws(() => summarize(invalid), /does not equal planned/);
});

در محصول واقعی، Rule تصمیم را با Governance سازمان هماهنگ کنید. کد نشان می‌دهد Rule باید صریح و قابل‌آزمون باشد؛ نه اینکه فرمول عمومی بالا جای Risk owner، Context و قضاوت حرفه‌ای را بگیرد.

Risk Register تصمیم‌پذیر بنویسید

نوشتن «ریسک متوسط پذیرفته شد» کافی نیست. Acceptance باید Actor، Scope، شرط و Expiry داشته باشد. اگر Artifact، Config، Data migration یا Dependency عوض شود، Evidence و Recommendation قبلی ممکن است نامعتبر شوند.

هر ذی‌نفع چه Viewی نیاز دارد؟

برای UAT، Result و Sign-off کسب‌وکار را با Evidence فنی یکی نکنید. راهنمای تست پذیرش کاربر Acceptance criteria، Scenario و مسئول پذیرش را جدا توضیح می‌دهد.

مثال ایرانی: انتشار Checkout پیش از کمپین

فرض کنید بازارگاه ایرانی پیش از کمپین فروش، Checkout v2.۷ را منتشر می‌کند. Decision Card خوب چنین Contextی دارد:

• Artifact: Image digest دقیق API، Frontend build و DB migration؛
• Critical journeys: پرداخت موفق، Callback تکراری، موجودی، لغو، بازگشت وجه و تحویل؛
• Locale: رقم فارسی/لاتین، ی/ی و ک/ک، نیم‌فاصله، RTL، جلالی/میلادی و timezone؛
• Money: Storage ریال، Display تومان، Round و سقف تراکنش؛
• Dependencies: PSP، پیامک، موجودی، ارسال و نقشه با نسخه/Sandbox مشخص؛
• Load: Workload کمپین، p95/p99، Error، Goodput و Saturation؛
• Operations: Duplicate-payment alert، Queue lag، Feature flag، Canary و rollback؛
• Evidence access: Artifact داخلی و پایدار، بدون وابستگی انحصاری به سرویس خارجی مسدودشدنی؛
• Privacy: گزارش بدون شماره، آدرس، Token، تصویر کارت یا Payload مشتری.

نمونه خلاصه تصمیم

Conditional Go برای Rollout پنج‌درصدی Build checkout-api@sha256:…. پرداخت موفق، Idempotency callback، Inventory و Cancel روی Environment manifest ۸۴ Pass هستند. سناریوی timeout یکی از PSPها به‌دلیل اختلال Sandbox، Not Evaluated است (R-۱۷، Medium). شرط‌ها: اجرای Fixture شبیه‌سازی timeout تا ۱۴:۰۰، Alert پرداخت تکراری فعال، Owner عملیات حاضر و Rollback کمتر از ده دقیقه. Recommendation با تغییر Image، Migration یا PSP config منقضی می‌شود.

این متن هم محدودیت را پنهان نمی‌کند و هم یک «همه چیز ریسک دارد» بی‌عمل نیست؛ Decision، Condition و Owner دارد.

Security را با عبارت کلی نبندید

برای Security section، Requirement set و نسخه را ثبت کنید. OWASP ASVS 5.0.0 شناسه نسخه‌دار برای Verification requirement پیشنهاد می‌کند؛ بنابراین Evidence را مثلاً به v5.0.0-... وصل کنید، نه «OWASP تست شد».

NIST SSDF 1.1 نیز Secure Development را مجموعه‌ای از Practiceها برای کاهش Vulnerability و Impact می‌بیند. یک Scanner سبز یا Pen test محدود، کل Security posture و Supply-chain evidence را نمایندگی نمی‌کند. Scope، Tool/config version، finding، exception، expiry و remediation owner را گزارش کنید.

در Agile و Continuous Delivery گزارش سنگین لازم است؟

Formal بودن با مفید بودن یکی نیست. برای تغییر کم‌ریسک، Decision Card می‌تواند یک Artifact خودکار در Pipeline باشد. برای Migration بانکی یا Release قراردادی، Appendix رسمی و Approval چندنقشی لازم است. حداقل invariant در هر دو یکی است: Artifact identity، Evidence، Gap، Risk، Decision و timestamp.

آیا برای هر Sprint گزارش بدهیم؟

اگر پایان Sprint Decision یا Handover معناداری ندارد، Dashboard و Retrospective کافی است. اگر Increment به Production، UAT یا مشتری می‌رود، یک Completion snapshot نسخه‌دار بسازید. Ceremony بدون مصرف‌کننده، Waste است.

چه چیزهایی خودکار شوند؟

• Artifact/Commit/Environment/Data identity؛
• Result counts و Status reconciliation؛
• Traceability و Criteria evidence link؛
• Defect snapshot با Query version؛
• JUnit/Performance/Security artifact index؛
• Report hash، timestamp و retention metadata.

Risk statement، Business impact، Recommendation، Acceptance و Lesson معمولاً به Review انسانی نیاز دارند. در راهنمای CI/CD با Jenkins و GitLab Build-once، Evidence contract و Missing-report policy آمده است.

Pipeline پیشنهادی

Collect → Validate schema/counts → Resolve immutable links → Generate views → Human review → Sign decision → Archive → Feed next plan

اگر Collector شکست خورد، وضعیت Report باید Incomplete/Unknown باشد؛ آخرین گزارش سبز را با عنوان گزارش Build جدید بازنشر نکنید.

گزارش پیش از انتشار آخرین حقیقت نیست

Test Environment با Production یکسان نیست و Coverage صددرصد وجود ندارد. Google SRE Workbook توضیح می‌دهد بعضی Defectها فقط با Traffic واقعی آشکار می‌شوند؛ Canary، Metric منتسب به Version و Rollback، Risk rollout را محدود می‌کنند. پس Report باید Monitoring hypothesis و rollback trigger را به Release plan وصل کند.

بعد از Release، Outcomeهای واقعی را به گزارش بعدی برگردانید: Incident، escaped defect، SLO breach، rollback و user impact. DORA در مدل فعلی پنج Metric برای Throughput و Instability دارد و هشدار می‌دهد Context مهم است و یک Metric نباید «حاکم همه چیز» شود. این‌ها Trend بهبود Delivery هستند، نه جایگزین Criteria همان Release.

اشتباهات رایج در گزارش نهایی تست

• نوشتن «QA Approved» بدون Scope، Artifact و Risk acceptance؛
• تبدیل Pass ratio به Quality score یا Release probability؛
• حذف Blocked/Not Run/Inconclusive از صفحه تصمیم؛
• گزارش Plan فعلی به‌جای Deviation از Plan اولیه؛
• تعداد Defect بدون Severity، Exposure، affected journey و snapshot time؛
• قرار دادن ده‌ها نمودار بدون سؤال تصمیمی؛
• مقایسه Teamها با Defect density یا تعداد Test case؛
• Sign-off صوری QA به‌جای Decision owner واقعی؛
• لینک به Dashboard mutable بدون Filter/Query/version؛
• کپی PII، Token و Payload در Report یا Screenshot؛
• Recommendation بدون Condition، expiry، monitoring یا rollback؛
• Lessons بدون Action owner و success measure؛
• Report دیرهنگام که پس از Decision منتشر می‌شود.

روش نوشتن گزارش در ۱۰ گام

1. Audience، Decision و deadline را مشخص کنید.
2. Artifact، Test Basis، Environment، Data و Cut-off را Freeze کنید.
3. Status vocabulary و denominator را Validate کنید.
4. Exit Criteria و Critical journeyها را به Evidence وصل کنید.
5. Out of Scope، Not Run، Blocked و Deviation را استخراج کنید.
6. Defect snapshot را به Residual risk تبدیل کنید؛ آن‌ها را یکی ندانید.
7. Recommendation، confidence، conditions و expiry را بنویسید.
8. Decision Card و Technical Appendix را از یک Source of Truth بسازید.
9. Ownerهای فنی/محصول/عملیات/امنیت را Review دهید.
10. Decision Record را Sign، Evidence را Archive و Actionها را Track کنید.

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

• عنوان و Report ID یک Release/Activity مشخص را نشان می‌دهد.
• Artifact، Environment، Data، Test Basis و timestamp دقیق‌اند.
• Report reason شامل Complete/Stopped/Cancelled و علت است.
• Scope و Out of Scope با Business/Risk impact روشن‌اند.
• هر Exit Criterion Target، Actual، Evidence و Status دارد.
• جمع وضعیت‌ها دقیقاً با Planned برابر است.
• Pass ratio همراه مخرج و Gapها نمایش داده می‌شود.
• Coverage به Requirement/Risk/Journey وصل است، نه فقط Test count.
• Defectهای باز affected scope، workaround، owner و linked risk دارند.
• Residual risk شامل likelihood، impact، mitigation، trigger و expiry است.
• Recommendation به Artifact و Condition محدود است.
• QA author، Reviewer و Decision owner جدا هستند.
• Canary/Monitoring/Rollback برای Riskهای پس از Release لینک شده‌اند.
• Evidence immutable، دسترس‌پذیر و فاقد Secret/PII در متن گزارش است.
• Lessonها Action، owner، due date و success measure دارند.

جمع‌بندی

گزارش اختتامیه تست یک مراسم اداری یا آلبوم نمودار نیست؛ قرارداد تصمیم است. باید Evidence را به Test Objective و Exit Criteria وصل کند، Gap را به Risk تبدیل کند و Risk را با Owner، Condition، Monitoring و Expiry به Decision برساند.

ساختار پیشنهادی را به خاطر بسپارید: Identity → Scope/Basis → Criteria → Results/Coverage → Defects/Deviations → Residual Risk → Recommendation → Decision Record → Evidence → Actions. اگر خواننده نتواند بگوید «چه می‌دانیم، چه نمی‌دانیم و اکنون چه کسی باید چه تصمیمی بگیرد»، گزارش هنوز کامل نیست.

سوالات متداول

تفاوت Test Status Report و Test Completion Report چیست؟

Status Report در طول تست و به‌صورت دوره‌ای برای کنترل برنامه، مانع، Risk و کار بعدی تولید می‌شود. Completion Report در پایان یک Activity، Level، Type یا Release یک‌بار ساخته می‌شود و نتیجه نسبت به Plan/Criteria، Gap، ریسک حل‌نشده و Lesson را جمع‌بندی می‌کند.

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

Test lead/manager یا تیم مسئول تست معمولاً Evidence و Recommendation را تهیه می‌کند. Reviewerها Context فنی/کسب‌وکار را بررسی می‌کنند و Release/Product/Business owner طبق RACI تصمیم و ریسک را می‌پذیرد. امضای QA به‌تنهایی نباید پذیرش ریسک سازمان باشد.

نرخ Pass مناسب برای انتشار چند درصد است؟

عدد جهانی وجود ندارد. ۹۹٪ می‌تواند با یک Journey بحرانی Blocked، نامناسب باشد و درصد پایین‌تر ممکن است شامل Failureهای کم‌اثر و شناخته‌شده باشد. Criteria، Risk tier، Coverage، affected scope و کنترل rollout مهم‌تر از Threshold عمومی‌اند.

آیا تیم Agile در پایان هر Sprint به گزارش رسمی نیاز دارد؟

فقط وقتی پایان Sprint Decision، Handover یا Release معناداری دارد. برای تغییر کم‌ریسک یک Artifact کوتاه خودکار کافی است؛ Release قراردادی یا پرریسک Formality بیشتری می‌خواهد. حداقل Identity، Evidence، Gap، Risk و Decision در هر دو لازم است.

آیا با Defect باز می‌توان Conditional Go داد؟

بسته به Risk و Governance ممکن است، اما باید affected journey، severity/impact، workaround، owner، monitoring، rollback trigger و expiry ثبت و Risk به‌صراحت توسط صاحب مجاز پذیرفته شود. Defect بحرانی یا Gap در Criterion حیاتی معمولاً No-Go است.

منابع رسمی و قابل بازبینی

• ISTQB CTFL 4.0.1 — Test Completion and Reporting
• ISO JTC 1/SC 7 — ISO/IEC/IEEE 29119 Series and Test Documentation
• ISO/IEC 25010:2023 — Product Quality Model
• NIST SP 800-218 — Secure Software Development Framework 1.1
• OWASP ASVS 5.0.0 — Versioned Security Verification Requirements
• Google SRE Workbook — Canarying Releases
• DORA — Current Software Delivery Performance Metrics