مدیریت نقص نرم‌افزار؛ از Triage تا SLA و یادگیری

ساعت ۱۰ صبح، QA یک باگ «برداشت تکراری» ثبت می‌کند. نیم ساعت بعد Support همان علامت را با متن دیگری می‌فرستد و Monitoring هم Alert سوم را می‌سازد. Dashboard عدد ۳ Critical را نشان می‌دهد؛ تیم سه Ticket را به سه نفر می‌دهد، در حالی که هر سه از یک Failure mechanism آمده‌اند. هم‌زمان یک نقص واقعاً بحرانیِ تسویه در Backlog جدید پنهان می‌ماند. مشکل کمبود ابزار نیست؛ مشکل نبود سیستم مدیریت نقص است.

مدیریت نقص نرم‌افزار فقط حرکت یک Bug از New به Closed نیست. این یک سیستم عملیاتی برای تبدیل Reportهای چندمنبعی به Defectهای Canonical، تصمیم مشترک Triage، تخصیص ظرفیت بر اساس Risk و Age، کنترل SLA، اثبات Fix، پیوند به Release و تبدیل الگوهای تکراری به اقدام پیشگیرانه است.

مرز این راهنما: Lifecycle یک Ticket یا مدیریت Portfolio؟

اگر می‌خواهید وضعیت‌های New، Assigned، In Progress، Resolved، Ready for Test، Reopened و Closed را طراحی کنید، راهنمای چرخه عمر باگ و Bug Workflow مرجع آن موضوع است. اگر می‌خواهید Report کامل با Steps، Expected/Actual و Evidence بنویسید، از قالب گزارش باگ حرفه‌ای استفاده کنید.

موضوع این مقاله یک سطح بالاتر است: سازمان با صدها Report، چند تیم، Support، Monitoring، Security و Releaseهای هم‌زمان چگونه یک Defect Portfolio قابل‌تصمیم می‌سازد؟

Defect management چه چیزی نیست؟

• انبار Ticket یا Dashboard شمارش باگ نیست.
• مالکیت انحصاری QA یا Test Manager نیست؛ تصمیم Cross-functional است.
• Severity مساوی Priority یا Deadline نیست.
• SLA به معنی «همهٔ Criticalها در چهار ساعت Fix شوند» بدون Context نیست.
• بستن Ticket به معنی حذف Risk یا اثبات نبود Regression نیست.
• Duplicate و Invalid را نباید برای تنبیه Reporter به صفر رساند.
• RCA برای هر Typo نیست؛ Trigger و عمق باید با پیامد/تکرار متناسب باشد.
• Security vulnerability و Production incident را نباید بی‌ملاحظه در Workflow عمومی افشا کرد.

سرفصل جاری ISTQB CTAL Test Management 3.0 Defect Lifecycle، مدیریت Cross-functional، تفاوت Contextهای Agile/Hybrid، اطلاعات Defect report و استفاده از داده برای Process improvement را کنار هم می‌گذارد. استاندارد ISO/IEC/IEEE 29119-3:2021 نیز Templateهای Test documentation را برای مدل‌های مختلف Lifecycle قابل‌Tailor می‌داند؛ قالب باید تصمیم را پشتیبانی کند، نه اینکه همهٔ تیم‌ها را به فرم یکسان و سنگین مجبور کند.

مدل عملیاتی از Signal تا Prevention

Test / Support / Monitoring / Security / Customer signal
        ↓
Report intake + source identity + privacy screening
        ↓
Validation + canonical defect + duplicate cluster
        ↓
Cross-functional triage and disposition
        ↓
Class of service + owner + target + capacity
        ↓
Fix / mitigate / accept / defer / reject
        ↓
Verification + regression + release linkage
        ↓
Production observation + recurrence cluster
        ↓
RCA / prevention action / process learning
        ↺

هر فلش یک Hand-off قابل‌شکست است. Report کامل بدون Owner می‌پوسد؛ Fix بدون Build identity قابل‌تأیید نیست؛ Closed بدون Production link یادگیری را قطع می‌کند؛ RCA بدون Action item فقط روایت است.

شش Artifact حداقلی

1. Defect Management Policy: Scope، Intake trigger، Vocabulary، Authority، SLA و Exception.
2. Canonical Defect Record: هویت واحد Failure، همهٔ symptom/reportها و رابطه‌ها.
3. Triage Decision Log: Evidence، تغییر فیلد، تصمیم، شرکت‌کنندگان و دلیل.
4. Portfolio Board: Class of Service، WIP، Age، Blocker، Target release و Exposure.
5. Verification Pack: Fix identity، Test evidence، Regression، limitation و residual risk.
6. Learning Register: Cluster، RCA trigger، Prevention action، Owner، Due date و outcome.

گام اول: ورودی‌های چندمنبعی را یکپارچه کنید

Defect فقط از Test execution نمی‌آید. Intake می‌تواند از این منابع باشد:

• Manual/automated testing و Static analysis؛
• Support ticket، تماس مشتری و User research؛
• Monitoring، Alert، Log و SLO violation؛
• Security scan، Pentest و disclosure پژوهشگر؛
• Finance/Reconciliation، Data quality و Audit؛
• Vendor/PSP/Carrier status یا Contract violation؛
• Incident/Postmortem action.

یک Ticket برای هر Signal نسازید

Report یک مشاهده از منبع است؛ Canonical Defect هویت فرضی/تأییدشدهٔ نقص محصول یا Work product؛ و Incident اختلال عملیاتی دارای Impact/Response است. چند Report می‌توانند به یک Defect وصل شوند و یک Incident ممکن است چند Defect و Control gap داشته باشد.

report_id: SUP-8821
source: support
observed_at: 2026-08-12T07:31:00Z
customer_impact: "two debit SMS; one order"
evidence: redacted receipt + PSP reference hash
privacy: restricted-financial

canonical_defect: PAY-D07
relation: symptom-of
duplicate_confidence: high
incident: INC-204
other_reports: [QA-431, MON-776]

Canonicalization باعث می‌شود Volume را دوبار نشمارید، اما Symptomهای مستقل را حذف نکنید؛ آن‌ها Reach، Frequency، Segment و Reproduction evidence می‌دهند.

دادهٔ حساس را پیش از گردش عمومی جدا کنید

• Token، Cookie، Password، API key و OTP را هرگز ضمیمه نکنید.
• کد ملی، موبایل، شماره کارت، PSP reference و Log را Mask/Hash و Access-control کنید.
• Security report را تا تعیین Scope/Embargo در Queue محدود نگه دارید.
• Customer communication را از Technical defect record جدا اما Link کنید.
• Retention و deletion برای Evidence تعریف کنید.

گام دوم: قرارداد Canonical Defect بسازید

فیلد زیاد مساوی دادهٔ خوب نیست. Record باید حداقل برای Triage، Resolution، Verification و Learning کافی باشد.

Schema پیشنهادی

defect_id: PAY-D07
title: retry after PSP timeout can create a second charge
status: triaged
disposition: confirmed-product-defect
first_seen / last_seen: timestamps
sources: QA-431, SUP-8821, MON-776
affected: checkout-api 5.14.2; PSP-B; retry-policy v3
scope: payment retry; tenant=marketplace; region=IR
condition_event_impact: "timeout after commit → retry → duplicate debit"
severity: critical
severity_basis: direct financial harm + repeated charge
priority: expedite
exposure: 27 impacted attempts / 18,420 in cohort
confidence: high
risk_ids: PAY-R01, PAY-R04
owner: payments-engineering-lead
target / service_class: emergency-hotfix / expedite
relationships: caused-incident INC-204; blocks REL-981
resolution: open
verification_contract: concurrency + timeout fault + ledger/PSP invariant
exception / acceptance: none
audit: field changes with actor, timestamp, reason

فیلدهای Core و Context-specific

Title، detailed anomaly، Evidence/context، Priority و Lifecycle data برای مدیریت لازم‌اند؛ Component، Root cause category، Regulatory code یا Environment detail بر اساس Context اضافه می‌شوند. در Agile، defectی که همان لحظه در Pairing Fix می‌شود شاید Ticket جدا نخواهد، اما این موارد باید Record پایدار داشته باشند:

• در همان روز/Iteration حل نمی‌شود؛
• فعالیت جاری را Block می‌کند؛
• چند تیم یا Supplier درگیرند؛
• Risk/Compliance/Customer commitment دارد؛
• برای Verification، Release note، RCA یا Trend evidence لازم است؛
• به‌صراحت Record درخواست شده است.

گام سوم: Taxonomy قابل‌تصمیم تعریف کنید

Bug، environment failure و expected behavior را یکی نکنید

Duplicate، Reopen و Recurrence را جدا کنید

• Duplicate: دو Report هم‌زمان/متفاوت، یک Canonical defect.
• Reopened: همان defect پس از Resolution، Verification را پاس نکرده است.
• Regression: قابلیت قبلاً سالم، پس از Change دوباره خراب شده است.
• Recurrence: Failure mechanism مشابه پس از بسته‌شدن یا در Component دیگر تکرار شده است.

این تمایز برای Fix quality و Prevention مهم است. Reopen rate خام بدون بررسی Resolution type و Verification contract، KPI سالمی نیست.

گام چهارم: Triage را به جلسهٔ تصمیم تبدیل کنید

Triage محل بازخوانی همهٔ Ticketها نیست. ورودی باید Pre-triaged باشد؛ افراد مناسب دربارهٔ موارد جدید، تغییرکرده، Blocked، SLA-risk و Aging تصمیم می‌گیرند.

نقش‌ها و Authority

برای تفکیک مشارکت همگانی از مسئولیت نام‌دار، مدل مالکیت مشترک کیفیت را ببینید.

ورودی آمادهٔ Triage

• Canonical/duplicate check انجام شده؛
• Version/Environment/Source مشخص؛
• Observed impact و Sample/cohort موجود؛
• Severity proposal با Basis، نه Label؛
• Unknown و Confidence صریح؛
• Workaround/containment و active incident روشن؛
• Dependency/blocker و تصمیم موردنیاز مشخص.

خروجی هر مورد

decision: expedite-fix | schedule | investigate | mitigate | accept | defer | reject | duplicate
canonical_id / relationship
severity + basis
priority / class_of_service
owner + collaborators
target response / containment / resolution / verification
release / incident / risk linkage
required evidence
exception owner + expiry
next review trigger

Cadence بر اساس Flow

• Critical/incident: event-driven؛ منتظر جلسه نماند.
• Active release: روزانه یا چند بار در هفته.
• Product backlog: Refinement هفتگی با Product planning.
• Aging/debt: مرور ماهانه/فصلی Portfolio و cluster.

در Agile، همهٔ Defectها را به Queue جدا از Product work تبعید نکنید. Scrum Guide 2020 Product Backlog را فهرست emergent و ordered از کار لازم برای بهبود محصول می‌داند؛ Bug fix می‌تواند با Feature، Risk reduction و Debt در یک تصمیم Product ordering دیده شود. Scrum هیچ SLA یا Bug workflow مشخصی تجویز نمی‌کند.

Severity، Priority، Exposure و Confidence را جدا نگه دارید

Severity

شدت پیامد Failure در شرایط تعریف‌شده است: مالی، امنیتی، ایمنی، حقوقی، دسترس‌پذیری، داده، عملیات یا تجربهٔ مشتری. Severity نباید با سختی Fix، مقام Reporter یا صدای بلند Customer تغییر کند.

Priority

ترتیب/فوریت اقدام در Context جاری است: Release date، Active exploitation، Reach، workaround، dependency، customer commitment، fix cost و opportunity cost روی آن اثر دارند.

Exposure

چه‌قدر از Scope در معرض است؟ عدد خام Report کافی نیست. Cohort، denominator، frequency، duration و segment بدهید: «۲۷ attempt از ۱۸٬۴۲۰ در PSP-B و retry-policy v3» بهتر از «زیاد رخ داده» است.

Confidence/Uncertainty

وقتی Evidence ناقص است، Severity را بی‌دلیل Low نکنید. Confidence را جدا ثبت و Discovery task/telemetry/containment تعیین کنید.

مثال‌هایی که Severity و Priority برابر نیستند

در Security، CVSS base یا Scanner label را Priority نهایی ندانید. CISA KEV Catalog evidence بهره‌برداری واقعی را یک ورودی مهم Prioritization می‌داند؛ applicability، asset criticality، exposure و controlهای خودتان نیز لازم‌اند.

Class of Service و SLA طراحی کنید

SLA یک ساعت واحد از Open تا Closed نیست. دست‌کم این Clockها را تفکیک کنید:

• Acknowledge: Signal دیده و مالک اولیه تعیین شد.
• Triage: Canonicalization، Severity/Exposure و Decision انجام شد.
• Contain/Mitigate: Blast radius یا Customer harm محدود شد.
• Resolve: Fix/Configuration/rollback آماده شد.
• Verify: Evidence مستقل Fix و Regression آماده شد.
• Communicate: ذی‌نفع/مشتری/Reporter به‌روزرسانی شد.

نمونهٔ Policy—نه عدد جهانی

این اعداد فقط Templateاند. ساعت کاری، تعطیلات رسمی ایران، On-call، Supplier timezone، severity definition، contractual obligation و Support coverage را در Calendar محاسباتی تعریف کنید.

Pause clock را محدود کنید

Waiting for reporter یا vendor نباید راه پنهان سبزکردن SLA باشد. Pause فقط با Reason code، Start/End، Owner، next action و maximum pause. Customer-facing elapsed time را نیز جدا نگه دارید.

Breach policy

• هشدار پیش از Breach، نه پس از آن؛
• Escalation به Role، نه فرد ثابت؛
• Containment alternative و communication؛
• Exception نام‌دار با Expiry؛
• Review علت Breach و ظرفیت/Policy؛
• عدم تنبیه Team بر اساس درصد SLA خام.

Capacity، WIP و Aging را مدیریت کنید

Backlog بی‌نهایت با Priorityهای ۱ تا ۱۰۰ مدیریت نمی‌شود. ظرفیت را میان New development، Expedite، Fixed-date، Standard و Debt/Prevention آشکار کنید. WIP limit، Swarming و Pull policy مانع می‌شوند ده Fix نیمه‌کاره تولید شود.

Age، Idle age و Flow time

• Age: زمان از First valid report تا اکنون/Closure.
• Idle age: زمان از آخرین اقدام معنی‌دار.
• Queue time: انتظار پیش از شروع کار.
• Active time: زمان کار واقعی؛ اگر قابل‌اعتماد ثبت می‌شود.
• Verification delay: Fix آماده است اما Evidence/Environment منتظر.

میانگین Age کافی نیست؛ Median، P85/P95 و Bucketهای ۰–۷، ۸–۳۰، ۳۱–۹۰ و بیشتر از ۹۰ روز را بر Severity/Class/Team ببینید. یک Critical تازه‌ثبت‌شده نباید پشت FIFO بماند؛ یک Low قدیمی هم نباید برای همیشه Starve شود.

قواعد ضد Starvation

• Hard constraint برای Critical/active harm؛
• حداقل ظرفیت ماهانه برای Aged/maintenance؛
• Age threshold که Review را Trigger می‌کند، نه Priority خودکار؛
• Defer فقط با دلیل، next review و expiry؛
• Close-as-obsolete با Evidence محصول/Version، نه پاک‌کردن Dashboard؛
• Cluster fix برای Root cause مشترک به‌جای سوزاندن Ticketهای علامتی.

آزمایش بازتولیدپذیر: Report count و FIFO چگونه گمراه می‌کنند؟

یک دادهٔ کاملاً ساختگی ساختیم: ۱۸ Report از QA، Support، Monitoring و عملیات؛ ۱۳ Canonical defect با Effort/Exposure فرضی؛ ظرفیت ۱۵ امتیاز. اعداد Benchmark صنعت یا فرمول پیشنهادی عمومی نیستند.

مرحلهٔ هویت: ۱۸ Report چند Defect است؟

D07 سه Report و D09 دو Report داشتند. اگر Dashboard Raw report را به‌عنوان Defect count نشان دهد، Critical inventory را دوبرابر جلوه می‌دهد و Recurrence/Reach واقعی هم معلوم نمی‌شود.

مرحلهٔ ظرفیت: Oldest-first در برابر Portfolio constraint

روش دوم سه قید داشت: هر Canonical Critical defect انتخاب شود، دست‌کم یک مورد با Age بیشتر از ۴۰ روز برای Guardrail ضد Starvation بیاید و Effort از ۱۵ بیشتر نشود. سپس همهٔ subsetها را بررسی کرد و بیشترین Risk-unit را انتخاب کرد.

این خروجی اثبات نمی‌کند «امتیاز ۱۰۳» از ۷۵ در دنیای واقعی بهتر است؛ Weight/Effort ساختگی و uncertainty حذف شده‌اند. درس معتبرتر این است که:

• پیش از شمارش، Report را به Canonical identity تبدیل کنید؛
• Critical rule را بیرون از score نگه دارید؛
• Aging را Guardrail کنید تا Lowها برای همیشه نمانند؛
• اگر قیدها با Capacity ناسازگارند، خروجی باید Infeasible/Escalate باشد.

raw reports: 18
canonical valid defects: 13
duplicates: 3
invalid: 2
raw critical reports: 6
canonical critical defects: 3

budget: 15 effort points
FIFO: risk 75; critical selected [D08]; missed [D07,D09]
Constrained: risk 103; critical [D07,D08,D09]; missed []
aging guardrail: selected D01 (45 days)

Fix، Mitigate، Defer، Accept و Reject را قرارداد کنید

Resolution با Status فرق دارد

Risk acceptance را QA انجام نمی‌دهد

acceptance_id: ACC-PAY-31
defect: PAY-D13
residual_risk: refund status may remain pending up to 20 minutes
scope: PSP-A callbacks only; 2% rollout
rationale: fix risks settlement regression before campaign
compensating_controls: reconciliation every 5 min; support playbook; alert
owner: Payments Product Director
approved_by: Release Decision Owner
expires: 2026-08-20T18:00:00Z
rollback_trigger: pending ratio > 0.5% or any duplicate debit
review: after campaign or first incident

Severity را برای توجیه Defer پایین نیاورید. Severity history و Decision history immutable بماند؛ Priority/Disposition می‌تواند با Context تغییر کند.

Verification یعنی اثبات Claim اصلاح

Developer می‌گوید چه چیزی تغییر کرده؛ Verifier می‌سنجد آیا Defect در Build هدف و شرایط معتبر دیگر رخ نمی‌دهد و آیا Side effect قابل‌انتظار ایجاد نشده است. Verification لزوماً توسط QA انجام نمی‌شود، اما Independence باید با Risk متناسب باشد.

Verification contract

defect: PAY-D07
fix_identity: PR-882 / commit abc123 / image sha256:...
target_build: checkout-api 5.14.3
environment_manifest: ENV-2041
data_seed: PAY-D07-v2
reproduce_before: valid-failed on 5.14.2
retest_after: 20 concurrent retries; timeout-before/after-commit
oracles: API result + PSP charge count + ledger invariant + outbox event
regression_scope: pay, retry, refund, reconciliation
result: valid-passed | failed | blocked | invalid
limitations: PSP-B production routing not exercised
artifacts: trace/log/db snapshot (PII-redacted)
verifier / timestamp: named identity

Closed gate

• Resolution و Fix identity مشخص؛
• Target branch/release/deployment روشن؛
• Evidence معتبر و Result semantics حفظ؛
• Regression scope بر اساس Failure mechanism؛
• Documentation/monitoring/customer action در صورت نیاز؛
• Residual limitation و Risk owner؛
• Reporter/incident/release links به‌روز؛
• RCA/Prevention action اگر Trigger شده.

Retest یک Defect و مدیریت کل Test Run دو سطح متفاوت‌اند؛ برای Run identity، result state و Closure evidence از راهنمای مدیریت چرخه اجرای تست استفاده کنید.

Defect را به Release و Production وصل کنید

Release manifest

• Defectهای Fixed و Verified در Build؛
• Open Critical/High impacted؛
• Accepted/Deferred با Expiry؛
• Known limitation و workaround؛
• Feature flag/Canary/rollback؛
• Monitoring و support communication؛
• Decision owner و timestamp.

Defect count یا Pass rate به‌تنهایی Release recommendation نمی‌سازد. نتیجه را با Risk/Evidence و Unknown در قالب گزارش تست و تصمیم انتشار ارائه کنید.

Production recurrence

پس از Deployment، Signalهای مرتبط را به Defect وصل کنید: آیا Failure واقعاً متوقف شد؟ Mitigation Blast radius را کم کرد؟ Alert زودتر دید؟ Customer report ادامه دارد؟ Monitoring absence به‌تنهایی اثبات Fix نیست مگر Detection coverage معتبر باشد.

از Defect data به RCA و Prevention برسید

RCA را برای همهٔ موارد اجرا نکنید؛ Trigger کنید وقتی:

• Critical/High impact یا Incident جدی؛
• Recurrence یا cluster چندتیمی؛
• Fix شکست‌خورده/Reopen متعدد؛
• SLA breach سیستماتیک؛
• Invalid/duplicate spike نشان‌دهندهٔ Contract/Environment gap؛
• Security/privacy/compliance obligation؛
• Near miss با پیامد بالقوه بالا.

مقالهٔ تحلیل علت ریشه‌ای نقص روش RCA را عمیق‌تر پوشش می‌دهد. اینجا قرارداد Hand-off مهم است:

cluster: duplicate-or-delayed-PSP-callback
linked_defects: [PAY-D07, PAY-D21, PAY-D34]
incidents: [INC-204]
trigger: critical recurrence across 2 releases
owner: payments-architecture-lead
reviewers: QA, SRE, Product, Finance Ops
due: 5 working days
actions:
  - prevent: database uniqueness + idempotency state machine
  - detect: ledger/PSP reconciliation alert
  - mitigate: circuit breaker + retry policy
  - learn: update risk/test strategy and sandbox fault model
success_evidence: no duplicate in fault campaign + production cohort trend

Google SRE Postmortem guidance Action item مؤثر را دارای Owner، Tracking ID، Priority و پایان قابل‌تأیید می‌داند و روی تغییر سیستم به‌جای سرزنش فرد تأکید دارد. «بیشتر دقت کنید» Prevention action قابل‌اعتماد نیست.

متریک‌های سالم Defect Portfolio

Little’s Law را با احتیاط استفاده کنید

Average WIP ≈ Average throughput × Average flow time

این رابطه برای سیستم تقریباً پایدار، Unit یکسان و Window سازگار معنا دارد. Critical expedite، batch closure، reopen و Scope تغییر می‌توانند آن را مخدوش کنند. از آن برای پرسش ظرفیت استفاده کنید، نه ارزیابی فرد.

Defect Removal Efficiency و Escape

برای تعریف cohort، Severity و denominator به راهنمای متریک‌های تست رجوع کنید. Escape را صرفاً «شکست QA» ننامید؛ Requirement، Architecture، Code، Review، Test، Release و Monitoring همگی می‌توانند سهم داشته باشند.

Tool و Automation چه نقشی دارند؟

Jira، GitHub Issues، Azure DevOps، YouTrack، TestRail یا ابزار داخلی می‌توانند Record و Workflow را اجرا کنند؛ مدل عملیاتی را اختراع نمی‌کنند. PoC را با Scenarioهای واقعی بسنجید:

• Canonical duplicate/link و حفظ Report sources؛
• Custom field با Vocabulary/validation؛
• Cross-project dependency و supplier sync؛
• Role/RBAC، restricted Security issue و audit trail؛
• SLA calendar/pause/escalation؛
• WIP/Aging/percentile و data export؛
• PR/build/deploy/test/incident/release linkage؛
• API/Webhook idempotency، retry و reconciliation؛
• Data residency، backup، retention و exit/export؛
• Persian/RTL، جست‌وجوی ی/ی و ک/ک، رقم فارسی/لاتین و timezone.

GitHub Issues documentation نمونه‌ای از Metadata، dependency، link به PR و Projects است؛ وجود قابلیت به معنی طراحی درست Policy نیست.

Automationهای مفید

• Prefill Version/Build/Environment از Run؛
• Candidate duplicate search با Human confirmation؛
• Missing-field lint بر اساس Class؛
• SLA/age alert و escalation؛
• Auto-link Commit/PR/Build/Deployment با validation؛
• Reopen on verification failure؛
• Expired acceptance/defer review؛
• Cluster suggestion بر Component/Mechanism.

AI guardrails

AI می‌تواند Summary، Similarity و label پیشنهاد کند؛ نباید Critical report را خودکار Invalid/Duplicate ببندد، Severity را بدون Basis تغییر دهد یا PII را به Vendor بیرونی بفرستد. Model/version، confidence، inputs، human override و sampled false-negative audit لازم است.

مثال کامل ایرانی: پرداخت و تسویه Marketplace

Signalها

• QA: بعد از Timeout، Retry دوم دو PSP reference می‌سازد.
• Support: مشتری دو پیامک برداشت گرفته است.
• Monitoring: نسبت callback تکراری PSP-B بالا رفته است.
• Finance Ops: Ledger و Settlement یک Merchant اختلاف دارد.

Canonicalization

سه Signal اول به PAY-D07 وصل می‌شوند؛ Finance finding ابتدا Relationship «possibly-related» می‌گیرد تا Evidence cause مشخص شود. Raw count برابر چهار است، اما Defect inventory هنوز یک مورد تأییدشده و یک Investigation است.

Triage

• Severity Critical به‌دلیل Financial harm و double debit؛
• Exposure: PSP-B، retry-policy v3، ۲۷ از ۱۸٬۴۲۰ attempt؛
• Confidence High برای Duplicate charge، Medium برای Settlement relation؛
• Class Expedite، Incident linked، Risk owner Product Director؛
• Containment: Retry flag off برای PSP-B و Reconciliation پنج‌دقیقه‌ای؛
• Customer/Finance communication با Evidence Masked.

Fix و Verification

• Idempotency state machine و DB uniqueness؛
• Fault injection برای timeout-before/after-commit؛
• Oracle مستقل روی API، PSP charge، Ledger و Outbox؛
• مقدار canonical بر حسب ریال؛ تومان فقط Presentation؛
• اعداد فارسی/عربی/لاتین در ورودی؛
• UTC برای ذخیره و Asia/Tehran برای cutoff/نمایش؛
• Canary ۲٪، Duplicate alert و rollback trigger.

Closure و Learning

PAY-D07 فقط پس از Verification Pack و Rollout evidence Closed می‌شود. INC-۲۰۴ و cluster callback، RCA جدا Trigger می‌کنند؛ actionها Sandbox fault model، architecture invariant و monitoring را تغییر می‌دهند. اگر Settlement defect علت جدا داشت، Canonical record مستقل باقی می‌ماند؛ شباهت زمانی دلیل Merge نیست.

برنامهٔ ۳۰روزهٔ استقرار

روزهای ۱ تا ۵: Baseline و Policy

• Scope، Sources، Privacy و Vocabulary را ثبت کنید.
• Raw report و Canonical defect را جدا کنید.
• Severity/Priority/Disposition/Resolution تعریف و نمونه‌گذاری کنید.
• چهار هفته Arrival، WIP، Age، Invalid، Duplicate و Verification delay بگیرید.

روزهای ۶ تا ۱۰: Triage و Authority

• نقش‌ها، quorum، decision rights و event trigger؛
• Pre-triage checklist و decision log؛
• Security/Privacy restricted path؛
• Agile same-day fix threshold و multi-team rule.

روزهای ۱۱ تا ۱۵: Service و Capacity

• Class of Service، Clock و Calendar؛
• Critical hard constraint و escalation؛
• WIP limit و ظرفیت Aged/Prevention؛
• Defer/acceptance expiry.

روزهای ۱۶ تا ۲۰: Verification و Linkage

• Fix/Build/Environment identity؛
• Verification contract و result semantics؛
• Release/Incident/Risk/PR links؛
• Closed gate و reopen rule.

روزهای ۲۱ تا ۲۵: Dashboard و Data quality

• Canonical counts، Age distribution و SLA clock؛
• Duplicate/invalid reason بدون target تنبیهی؛
• Missing link/field/audit checks؛
• Metric dictionary و access control.

روزهای ۲۶ تا ۳۰: Learning و Pilot review

• یک Defect cluster را تا RCA/action دنبال کنید.
• Queue/WIP/Verification bottleneck را اصلاح کنید.
• Policy و Tool automation را بر اساس Evidence Tailor کنید.
• Scale/Adjust/Stop decision و Owner چرخهٔ بعد را ثبت کنید.

ضدالگوهای مدیریت نقص

1. Ticket count = defect count: Duplicate cluster و Source identity حذف می‌شود.
2. Severity inflation: همه Critical می‌شوند تا دیده شوند.
3. Priority by loudest voice: Exposure و Hard constraint نادیده می‌رود.
4. FIFO only: Critical تازه پشت Low قدیمی می‌ماند.
5. Risk score only: Critical gate در میانگین حل می‌شود.
6. Zero duplicate target: Reporter از ثبت Signal تازه می‌ترسد.
7. Cannot reproduce = close: Unknown به False negative تبدیل می‌شود.
8. QA owns every bug: Product/Engineering/Risk authority مبهم می‌شود.
9. Triage as status meeting: تصمیم و Data آماده نیست.
10. SLA one clock: Queue، Fix، Vendor و Verification قابل‌تشخیص نیست.
11. Pause abuse: Waiting state Dashboard را سبز می‌کند.
12. Close on commit: Build و Verification evidence وجود ندارد.
13. Lower severity to defer: Risk history دستکاری می‌شود.
14. Permanent accepted risk: Expiry و Trigger ندارد.
15. RCA every ticket: Ceremony زیاد، یادگیری کم.
16. RCA no action: Root cause document با Owner/Outcome وصل نیست.
17. Public security issue: Disclosure و Evidence حساس نقض می‌شود.
18. AI auto-close: False negative و audit gap پنهان می‌شود.

چک‌لیست Go-live

• □ Report، Canonical defect، Incident و Change request جدا هستند.
• □ همهٔ Source reportها به Canonical identity وصل می‌شوند.
• □ Security/PII path محدود و Retention تعریف شده است.
• □ Core fieldها کم، تعریف‌شده و قابل‌اعتبارسنجی‌اند.
• □ Disposition و Resolution از Status جدا هستند.
• □ Duplicate source evidence حفظ می‌شود.
• □ Severity basis، Priority، Exposure و Confidence جدا هستند.
• □ Critical rule بیرون از score است.
• □ Triage quorum، Authority و خروجی مشخص دارد.
• □ Event-driven Critical path منتظر جلسه نمی‌ماند.
• □ Class of Service و چند Clock SLA تعریف شده‌اند.
• □ Pause reason/limit و breach escalation وجود دارد.
• □ WIP limit و Aged-capacity guardrail فعال‌اند.
• □ Defer/acceptance Owner و Expiry دارند.
• □ Fix به Commit/Build/Deploy وصل است.
• □ Verification contract، Oracle و limitation دارد.
• □ Closed gate و Reopen/Recurrence semantics روشن‌اند.
• □ Release/Incident/Risk/Customer links کامل‌اند.
• □ RCA trigger و Prevention action tracker وجود دارد.
• □ Dashboard مخرج، cohort، percentile و data quality نشان می‌دهد.

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

تفاوت مدیریت نقص و چرخه عمر باگ چیست؟

چرخه عمر باگ وضعیت‌ها و انتقال یک Ticket را توضیح می‌دهد. مدیریت نقص سیستم گسترده‌تری است که Intake چندمنبعی، Canonicalization، Triage، Portfolio capacity، SLA، Risk acceptance، Verification، Release linkage و Prevention را اداره می‌کند.

چه کسی Priority باگ را تعیین می‌کند؟

یک نفر به‌تنهایی نباید همهٔ Context را حدس بزند. Product، Engineering، QA، Operations و نقش‌های تخصصی Input می‌دهند؛ Authority نهایی طبق Policy و نوع Risk مشخص می‌شود. Product ordering نمی‌تواند Hard security/safety/legal constraint را نادیده بگیرد.

آیا Duplicate و Invalid defect باید صفر شوند؟

خیر. Spike می‌تواند نشان‌دهندهٔ Search، Template، Requirement یا Environment بد باشد و باید تحلیل شود؛ اما Target صفر ممکن است Reporter را از ثبت Signal واقعی منصرف و False negative را بیشتر کند. Duplicate را Link کنید و Source evidence را نگه دارید.

SLA رفع باگ را چگونه تعیین کنیم؟

بر اساس Class of Service، پیامد، Exposure، obligation، ساعت پشتیبانی، Supplier و توان Verification. Acknowledge، Triage، Contain، Resolve و Verify را جدا کنید. ابتدا Baseline بگیرید و اعداد را به‌عنوان Policy قابل‌بازبینی تعریف کنید، نه Benchmark جهانی.

چه زمانی یک نقص را Closed کنیم؟

وقتی Resolution و Fix/Build identity روشن، Verification evidence معتبر، Regression متناسب، Release/Incident link کامل و Residual limitation/acceptance ثبت شده باشد. Commit merged یا «روی سیستم من درست شد» به‌تنهایی شرط Closure نیست.

جمع‌بندی

فرایند مؤثر مدیریت نقص، Ticket را سریع‌تر جابه‌جا نمی‌کند؛ تصمیم را قابل‌اعتمادتر می‌کند. ابتدا Signalهای پراکنده را به Canonical defect تبدیل می‌کند، سپس Severity/Exposure/Confidence را از Priority جدا می‌سنجد، ظرفیت و SLA را شفاف می‌کند، Fix را با Evidence می‌بندد و Recurrence را به Prevention action بازمی‌گرداند.

از یک Value Stream و یک ماه داده شروع کنید. اگر فقط یک کار انجام می‌دهید، Raw report count را از Canonical defect inventory جدا کنید؛ همین تفکیک بسیاری از Dashboardها، Triageها و تصمیم‌های Capacity را از خطای دوباره‌شماری نجات می‌دهد.

منابع رسمی و مطالعهٔ بیشتر

• ISTQB — CTAL Test Management ۳.۰؛ Defect Management
• ISO/IEC/IEEE 29119-3:2021 — Test Documentation
• Scrum Guide ۲۰۲۰ — Product Backlog، Transparency و Adaptation
• CISA — Known Exploited Vulnerabilities Catalog
• OWASP — Vulnerability Management Guide
• NIST — Secure Software Development Framework 1.1
• Google SRE — Postmortem Culture and Action Items
• GitHub Docs — Issues، Metadata، Dependencies و PR linkage