جلسه تمام شده است: ۸۶ گزارش در کمتر از شش ساعت مرور شدهاند، برای همه Priority ثبت شده و میانهٔ زمان تصمیم فقط چهار دقیقه است. یک هفته بعد مشخص میشود گزارش «Cannot Reproduce» روی Build اشتباه بررسی شده، سه Duplicate بدون لینک به Canonical بسته شدهاند و یک نقص با Severity بالا صرفاً بهدلیل صدای بلندتر Stakeholder وارد Sprint شده است. سرعت بالا بود؛ اما آیا تریاژ واقعاً تصمیم معتبر تولید کرد؟
این راهنما Bug Triage را از یک جلسهٔ گفتوگو به Defect Triage Decision Protocol تبدیل میکند: Intake Query، Decision Packet، Classification و Severity/Priority Scheme، Authority، Disposition، SLA، Resume/Reopen، Evidence و Correction. هدف، حل نقص یا طراحی راهحل در جلسه نیست؛ هدف تولید یک تصمیم محدود، قابلردیابی و قابلاصلاح دربارهٔ گام بعدی هر Anomaly است.
خلاصه اجرایی: تریاژ خوب چه خروجی دارد؟
- ورودی تریاژ در آغاز «Anomaly report» است؛ تا پیش از تحلیل، الزاماً Product defect نیست.
- Severity، Priority، Classification، Disposition، Status، Resolution و Assignee مفاهیم جدا هستند.
- هر Decision باید Packet digest، Evidence، rationale، Unknown، Authority، Owner، dueAt و next state داشته باشد.
- Accepted الزاماً «حتماً Fix میشود» نیست؛ Fixed الزاماً Verified نیست؛ Closed نیز صحت محصول را اثبات نمیکند.
- DUPLICATE بدون Canonical link، NEEDS_INFO بدون Resume condition و DEFERRED بدون Review date تصمیم ناقصاند.
- تریاژ میتواند Async، Event-driven یا Meeting باشد. ریتم، Timebox و شرکتکنندهٔ ثابت نسخهٔ عمومی ندارند.
- سرعت تریاژ را کنار Reopen، Stale decision، Appeal، Decision reversal و Evidence completeness بسنجید.
هدف جستوجو و مرز این راهنما
Intent اصلی اطلاعاتی و اجرایی است: «جلسه تریاژ باگ چیست؟»، «Severity و Priority چه تفاوتی دارند؟»، «چه کسانی باید در Bug Triage باشند؟»، «چطور جلسه طولانی نشود؟» و «Disposition هر باگ چه باشد؟». این صفحه مالک پروتکل تصمیم تریاژ است.
برای چرخهٔ کامل Stateها به چرخه عمر باگ و مدیریت نقص، برای ساخت Report قابلبررسی به گزارش باگ قابل بازتولید، برای اجرای تست و ثبت Anomaly به فاز اجرای تست در STLC و برای Facilitation عمومی Review به راهنمای جلسه بازبینی تست مراجعه کنید. این مقاله نه Workflow عمومی را بازطراحی میکند و نه Root cause یا Fix design را در تریاژ حل میکند.
Bug Triage چیست؟
Bug Triage یک Capability تصمیمگیری روی گزارشهای Anomaly است: ورودیهای واجد شرایط را شناسایی، Packet را اعتبارسنجی، گزارش را classify، Impact/Risk را بررسی و Disposition/Owner/SLA/next state را ثبت میکند. ممکن است خروجی Fix، Investigate، Needs info، Duplicate، Defer، Accept risk، Route، Not applicable یا Close under policy باشد.
در ISTQB CTFL 4.0.1 نیز گزارش اولیه ممکن است بعداً Product defect، false positive یا change request تشخیص داده شود. فرایند حداقلی از ثبت تا تحلیل/طبقهبندی، انتخاب پاسخ مناسب و Closure را پوشش میدهد. بنابراین «Bug» در نام جلسه نباید نتیجهٔ بررسی را از قبل قطعی کند.
Anomaly، Failure، Defect و Change Request را یکی نکنید
| مفهوم | تعریف عملی در این پروتکل | خطای رایج |
|---|---|---|
| Observation | آنچه در Subject/Context مشخص دیده شده | تفسیر را جای Evidence نوشتن |
| Anomaly | اختلاف یا رویدادی که بررسی میخواهد | از ابتدا Defect نامیدن |
| Failure | رفتار مشاهدهشدهای که با Oracle معتبر ناسازگار است | هر Test fail را Product failure دانستن |
| Defect | نقص منتسب به Work product پس از تحلیل | بدون Cause evidence قطعیکردن |
| Testware issue | اشکال در Check، Data، Oracle یا Harness | به Product team تخصیص دادن |
| Environment issue | Observation نامعتبر یا Failure محیطی | Cannot reproduce و بستن |
| Change request | رفتار فعلی با Basis سازگار اما انتظار جدید مطرح است | Severity مصنوعی برای گرفتن Priority |
Triage Decision Protocol؛ قرارداد مرکزی
triageProtocol:
id: TRIAGE-CHECKOUT-26
version: 5
purpose: "تعیین گام بعدی Anomalyهای Checkout"
decisionScope: "classification, severity, priority inputs, disposition, owner, SLA"
intakeQuery: "status=READY_FOR_TRIAGE AND product=SYN-CHECKOUT"
cutoffAt: 2026-08-13T09:00:00Z
eligibilityRule: packet-ready-v4
dedupRule: observation-signature-plus-subject
serviceClasses: [EXPEDITE, DATE_FIXED, STANDARD, INTANGIBLE]
decisionVocabulary: [INVESTIGATE, ROUTE, FIX_CANDIDATE, NEEDS_INFO,
DUPLICATE, DEFER, ACCEPT_RISK, NOT_A_DEFECT, CLOSE]
claimLimit: "تصمیم گام بعد؛ نه Root cause، Fix، Quality یا Release"
owner: defect-governance-owner
unknowns: [real-provider-behavior]
status: READY_FOR_TRIAGE_DECISION_REVIEW
هویتها را پیش از تصمیم قفل کنید
- Defect program/policy و Workflow version
- Classification، Severity، Priority و Release policy version
- Product/Goal/Risk register و Cutoff
- Report ID/version و Observation ID
- Repository، Commit، Build، Deployment، Environment و Data Pack
- Expected reference، Actual evidence و Artifact digest
تصمیم دربارهٔ BUILD-R25 را نباید با Screenshot یا Log مربوط به BUILD-R24 توجیه کرد. تغییر Report پس از جلسه نیز باید Version جدید بسازد؛ وگرنه Decision record معلوم نمیکند بر اساس کدام اطلاعات گرفته شده است.
Intake Query؛ چه چیزی وارد تریاژ میشود؟
جلسه نباید با اسکرولکردن همهٔ Backlog شروع شود. Query نسخهدار باید Cutoff، Product/Service، State، Service class و eligibility را مشخص کند. Emergency incident، Security disclosure، Customer complaint، Test failure و static-analysis finding ممکن است مسیرهای متفاوت داشته باشند.
| Intake class | Route | چرا؟ |
|---|---|---|
| Active incident | Incident response؛ link به defect follow-up | Contain/Recover مقدم است |
| Security disclosure | Restricted security workflow | Need-to-know و coordinated response |
| Ready product anomaly | Standard/expedite triage | Packet برای تصمیم حاضر است |
| Missing evidence | Pre-triage enrichment | جلسه محل group reading نیست |
| Known duplicate candidate | Async canonical validation | نیاز به جلسهٔ کامل ندارد |
| Change request | Product discovery/backlog route | Defect scheme مناسب نیست |
Readiness Rule؛ Decision Packet باید چه داشته باشد؟
| بخش | فیلد حداقلی | کاربرد |
|---|---|---|
| Identity | Report/version، Observation، Subject/Build/Environment | نسبتدادن درست |
| Expectation | Basis/Oracle reference | تشخیص اختلاف |
| Actual | Evidence artifact و digest | بازبینی Observation |
| Reproduction | REPRODUCED/INTERMITTENT/NOT_ATTEMPTED/INCONCLUSIVE | نه شرط مطلق پذیرش |
| Impact | Affected scope و user/business impact | Severity/Priority input |
| Risk | Risk IDs، exposure و uncertainty | تصمیم Contextual |
| Relations | Duplicate candidates و related changes | Dedup/attribution |
| Decision need | Requested decision، readyAt و Unknown | تمرکز تریاژ |
قالب آماده Decision Packet
decisionPacket: id: PKT-26 version: 3 reportId: ANOM-SYN-26 reportVersion: 4 observationId: OBS-SYN-26 subjectId: checkout-api@C26 buildId: BUILD-SYN-26 environmentId: ENV-SYN-26 expectedRef: ORACLE-IDEMP-v7 actualEvidence: artifacts/RUN-26/callback.json reproductionStatus: INTERMITTENT affectedScope: duplicate-callback/ledger userOrBusinessImpact: "دو Entry جعلی در Ledger مصنوعی" riskIds: [RISK-IDEMP-8] severityProposal: S2 priorityInputs: [exposure-unknown, no-production-data] duplicateCandidates: [ANOM-SYN-18] relatedChanges: [CHANGE-26] workaround: replay-reconciliation-fixture unknowns: [real-provider-reordering] requestedDecision: INVESTIGATE_OR_DUPLICATE readyAt: 2026-08-13T09:00:00Z digest: sha256:packet-26 redaction: synthetic-only
Severity و Priority؛ دو سؤال متفاوت
Severity میزان Impact یا اختلالِ Anomaly را در Subject/Context مشخص میکند. Priority ترتیب نسبی رسیدگی را با توجه به Severity، Exposure، Goal، زمان، dependency، workaround، cost of delay و Risk appetite تعیین میکند. هیچکدام «واقعیت کاملاً عینی» نیستند؛ باید Scheme، Evidence، Authority و rationale داشته باشند.
| پرسش Severity | پرسش Priority |
|---|---|
| چه قابلیت/داده/کاربری مختل است؟ | نسبت به Workهای دیگر چه زمانی اقدام کنیم؟ |
| Blast radius و recoverability چیست؟ | Exposure و deadline چیست؟ |
| Workaround وجود دارد؟ | Cost of delay و dependency چیست؟ |
| Integrity، safety، privacy یا money impact چیست؟ | Decision authority و Risk appetite چه میگویند؟ |
| Evidence و Unknown چهاند؟ | با اطلاعات ناقص چه service class بدهیم؟ |
Severity Scheme را Contextual و نسخهدار کنید
| سطح نمونه | معیار محدود | نیازمند |
|---|---|---|
| S1 | Impact تعریفشدهٔ بحرانی با containment فوری | Evidence/Unknown و escalation |
| S2 | قابلیت اصلی یا integrity مختل با workaround محدود | scope و recoverability |
| S3 | Impact متوسط/محلی با workaround معتبر | affected population |
| S4 | Impact کوچک طبق Policy | عدم اختلاط با Priority |
| UNKNOWN | Evidence برای تعیین سطح کافی نیست | Investigation و dueAt |
نامها و تعداد Levelها استاندارد جهانی ثابت نیستند. «Crash همیشه S1» یا «غلط املایی همیشه Low» Context را حذف میکند. Crash در fixture داخلی و خطای کوچک نمایش مبلغ در نقطهٔ بسیار پرمواجهه میتوانند تصمیمهای متفاوتی بخواهند.
Priority را از Ranking مبهم به Service Class تبدیل کنید
| Service class | Trigger نمونه | Policy لازم |
|---|---|---|
| EXPEDITE | Impact فعال و مجوز محدود | WIP cap، escalation، exit |
| DATE_FIXED | تعهد/رویداد نسخهدار | date owner و consequence |
| STANDARD | مقایسهٔ عادی Risk/value/cost | ranking rule و review |
| INTANGIBLE | کاهش Risk/debt بدون deadline نزدیک | capacity policy تا گم نشود |
| INVESTIGATE | Unknown برای Priority زیاد است | Question، owner و dueAt |
Priority Matrix ابزار گفتگوست، نه ماشین حقیقت
ماتریس Severity×Exposure میتواند Baseline پیشنهاد دهد، اما dependency، deadline، recovery، workaround، compliance context و uncertainty را کامل نمیکند. Override باید مجاز اما شفاف باشد: چه کسی، چرا، بر اساس کدام Evidence و تا چه زمانی. برای ساخت مدل Risk و Exposure، راهنمای تست مبتنی بر ریسک مرجع تخصصی است.
priorityProposal = policy(severity, exposure, goalImpact, workaround, deadline, dependency, uncertainty) finalPriority = authorityDecision( proposal, evidence, rationale, guardrails, reviewDue) # نه رأیگیری، نه میانگین نظرها و نه بلندترین صدا
Disposition Vocabulary؛ هر خروجی دقیقاً چه تعهدی میسازد؟
| Disposition | معنا | فیلد اجباری |
|---|---|---|
| INVESTIGATE | Question هنوز پاسخ ندارد | owner، question، dueAt |
| ROUTE | Capability/Workflow دیگری مناسب است | destination و accept confirmation |
| FIX_CANDIDATE | کاندید بررسی/برنامهریزی Fix است | Priority و owner capability |
| NEEDS_INFO | Packet برای تصمیم کافی نیست | missing info و resume condition |
| DUPLICATE | Observation با Canonical واحد مدیریت میشود | canonical ID و merge evidence |
| DEFER | فعلاً اقدام نمیشود | rationale، owner، review/expiry |
| ACCEPT_RISK | Authority مجاز Risk را زماندار میپذیرد | impact، authority، expiry |
| NOT_A_DEFECT | Classification دیگری معتبر است | classification و Evidence |
| CLOSE | شرط Closure Policy برقرار است | resolution و closure evidence |
قالب آماده Triage Decision
triageDecision: id: TD-ANOM-SYN-26 version: 2 reportId: ANOM-SYN-26 packetDigest: sha256:packet-26 disposition: NEEDS_INFO classification: PRODUCT_ANOMALY_UNCONFIRMED severity: UNKNOWN priority: INVESTIGATE rationale: "Evidence از Ledger همان Run حاضر نیست" evidenceRefs: [OBS-SYN-26, RUN-SYN-26] unknowns: [commit-before-timeout] ownerCapability: stateful-investigation decisionAuthority: risk-product-owner decidedAt: 2026-08-13T09:10:00Z dueAt: 2026-08-13T12:00:00Z nextAction: collect-same-build-ledger-evidence nextState: WAITING_FOR_INFO resumeCondition: same-build-ledger-manifest-attached claimLimit: "گام بعد؛ نه نبود یا وجود قطعی Product defect"
Accepted، Fixed، Verified و Closed را جدا کنید
| State/Resolution | آنچه میگوید | آنچه نمیگوید |
|---|---|---|
| ACCEPTED | Report/Classification برای Workflow پذیرفته شده | Fix قطعی یا زمان آن |
| IN_PROGRESS | Task مالک فعال دارد | Root cause قطعی |
| FIXED | Producer ادعای Repair دارد | Verification یا نبود Regression |
| VERIFIED | Verification طبق Scope Pass شده | کل محصول درست است |
| CLOSED | Closure rule و Resolution ثبت شده | Issue هرگز برنمیگردد |
| REOPENED | Reopen trigger برقرار شده | مقصر بودن Fixer یا Tester |
Cannot Reproduce؛ نه رد Report و نه اثبات نبود Defect
Cannot reproduce باید تعداد Attempt، Config، Build، Data، زمان، method و Evidence را ثبت کند. ممکن است علت intermittent behavior، محیط، داده، missing observability، رفع ضمنی یا Report ناقص باشد. خروجی میتواند INVESTIGATE، NEEDS_INFO، DEFER با telemetry، یا Close under policy باشد؛ اما «وجود ندارد» استنتاج مجاز نیست.
Duplicate؛ Canonical Record را زنده نگه دارید
- Similarity کافی نیست؛ Observation، Subject، cause hypothesis و impact را مقایسه کنید.
- Duplicate به Canonical ID لینک شود و Evidence/affected scope جدید merge یا reference شود.
- Reporter notification و حق Reopen/Appeal باقی بماند.
- اگر Canonical بسته شد، Duplicateهای متاثر در Correction scope باشند.
- تعداد Duplicate را علیه Reporter یا تیم KPI نکنید.
Deferred و Accepted Risk باید منقضی شوند
Backlog گورستان تصمیم نیست. DEFER باید owner، rationale، trigger، reviewDue و stale policy داشته باشد. ACCEPT_RISK علاوه بر اینها به Authority مجاز، impact، alternatives، compensating control و expiry نیاز دارد. Priority پایین مجوز پذیرش دائمی Risk نیست.
Authority Matrix؛ چه کسی چه تصمیمی میگیرد؟
| تصمیم | Capability input | Authority نمونه |
|---|---|---|
| Technical classification | Dev/Test/Platform evidence | classification owner |
| Severity | Impact/Domain/Risk analysis | scheme-defined authority |
| Priority | Severity، exposure، goal، dependency | product/risk authority |
| Risk acceptance | alternatives/impact/expiry | authorized risk owner |
| Fix design | technical analysis | delivery capability خارج تریاژ |
| Closure verification | same-subject evidence | workflow-defined reviewer |
QA Lead، Product Owner یا Tech Lead بهصورت جهانی مالک همهٔ این تصمیمها نیستند. Assignee نیز صرفاً صاحب Task است، نه لزوماً Authority. مدل را بر اساس ساختار و Risk خودتان تعریف کنید.
چه کسانی باید در جلسه تریاژ شرکت کنند؟
تعداد یا عنوان ثابت وجود ندارد. Participant را از Packet و Decision need انتخاب کنید: Facilitator/Scribe، Evidence provider، Impact/Risk capability و Authority لازم. دیگران میتوانند Async comment بدهند یا On-call باشند. چهار نقش ثابت، ۷–۸ نفر سقف جهانی یا حضور همهٔ Reporterها قاعدهٔ معتبر نیست.
| نیاز | حضور/دسترسی | اگر حاضر نیست |
|---|---|---|
| Observation clarification | Reporter یا Evidence کافی | NEEDS_INFO با resume |
| Technical classification | capability مرتبط | Route/Investigate |
| Impact | Product/Support/Domain evidence | Severity UNKNOWN |
| Risk acceptance | Authority یا delegation معتبر | تصمیم متوقف/محدود |
| Conflict | independent reviewer | recusal و escalation |
Async، Meeting یا Event-driven؟
| Mode | مناسب برای | Guardrail |
|---|---|---|
| Async | Packet کامل، Decision کمابهام، timezone متفاوت | SLA، audit trail، escalation |
| Scheduled meeting | Batch محدود با چند Authority/تعارض | agenda query، cutoff، WIP |
| Event-driven | Expedite یا Risk trigger | trigger/authority/exit روشن |
| Hybrid | enrichment Async، تصمیم پیچیده synchronous | عدم تکرار group reading |
جلسه هدف نیست؛ Decision latency و validity هدفاند. اگر Async ظرف SLA تصمیم معتبر میدهد، دعوت جلسه اتلاف است. اگر تعارض Authority یا Unknown پرریسک است، comment thread ممکن است کافی نباشد.
Session Contract برای جلسههای لازم
triageSession: id: TS-26 version: 2 mode: HYBRID agendaQuery: TRIAGE-CHECKOUT-26@cutoff cutoffAt: 2026-08-13T09:00:00Z serviceClass: STANDARD participantCapabilities: [facilitation, evidence, impact, technical] decisionAuthorities: [risk-product-owner, classification-owner] conflictRule: evidence-first-plus-escalation recusalRule: declared-interest-or-authorship-bias timeboxPolicy: question-and-risk-based parkingRule: create-investigation-with-owner-dueAt queueId: Q-TRIAGE-SYN wipLimit: 12 startedAt: 2026-08-13T09:05:00Z finishedAt: 2026-08-13T09:42:00Z scribe: decision-recorder auditLog: artifacts/TS-26/decisions.json status: CLOSED_WITH_ALL_ITEMS_DISPOSITIONED
Timebox؛ ۳ یا ۵ یا ۱۵ دقیقه قانون عمومی نیست
Timebox باید مانع Solution design و Root-cause deep dive شود، نه اینکه Decision ناقص را تحمیل کند. برای Standard item میتوان limit کوتاه داشت؛ در Risk بالا یا Authority conflict، خروجی درست ممکن است INVESTIGATE با Owner باشد. اگر زمان تمام شد، Parking record باید Question، Evidence gap، Owner و dueAt بسازد.
آمادگی قبلی؛ ۲۴ ساعت نسخهٔ عمومی نیست
Lead time آمادگی به Service class، timezone، حجم Packet و Risk بستگی دارد. Expedited item نمیتواند ۲۴ ساعت صبر کند؛ Standard batch شاید بیشتر از یک روز نیاز داشته باشد. معیار درست این است که Packet در readyAt کامل باشد و Authority زمان کافی طبق SLA/Policy داشته باشد.
بحث Root Cause و طراحی Fix را کجا ببریم؟
تریاژ فقط بهاندازهای Cause/Complexity را بررسی میکند که Classification، Routing و Priority ممکن شود. Root-cause analysis، Architecture design و implementation planning Work item جدا با Capability و Evidence خود هستند. «این تابع را rewrite کنیم» اگر برای Disposition لازم نیست، Parking میشود.
Blameless با Accountability تناقض ندارد
جلسه نباید برای تحقیر Reporter، Author یا Tester استفاده شود. اما Blameless به معنی حذف Owner، Decision record یا بررسی Action نیست. زبان مناسب روی Observation، Context، Control و next action تمرکز دارد؛ رفتار نامناسب یا تخلف نیز باید از مسیر امن و دارای صلاحیت رسیدگی شود، نه دادگاه بداههٔ تریاژ. برای کنترل Anchoring، Authority bias و Confirmation bias نیز راهنمای سوگیری شناختی در تست نرمافزار را ببینید.
Conflict، Recusal و Appeal
- اختلاف Severity را با Scheme/Evidence حل کنید؛ نه رأیگیری عنوانها.
- کسی که تعارض منافع یا Bias مستقیم دارد آن را اعلام و در صورت Policy از Authority کنار برود.
- اگر Authority حاضر نیست، delegation نسخهدار یا Escalation لازم است.
- Reporter و affected stakeholder باید مسیر Appeal با Evidence جدید داشته باشند.
- Appeal علیه فرد KPI نشود و history تصمیم حفظ شود.
Reopen Policy؛ بازشدن مجدد شکست اخلاقی نیست
| Trigger | Action | حفظ شود |
|---|---|---|
| Failure روی corrected build | REOPEN و link به verification | Fix/Verify evidence |
| Scope جدید همان cause | Expand یا related report طبق Policy | affected scope history |
| Evidence جدید برای Cannot reproduce | Resume investigation | attempt history |
| Canonical duplicate نامعتبر | Unlink/reclassify | merge decisions |
| Decision policy تغییر کرده | Review stale decisions | effectiveFrom و supersedes |
SLA؛ زمان پاسخ را با Service Class ببندید
SLA تریاژ زمان Fix نیست. میتواند زمان تا initial disposition، زمان تا information request یا time-to-escalation باشد. Clock start/pause/stop، timezone، business calendar و overdue outcome را بنویسید. Median تنها Tail و Itemهای Stale را پنهان میکند؛ percentile و age distribution را هم ببینید.
Correction؛ اگر تصمیم بر Packet اشتباه گرفته شد
correction: id: CORR-TRIAGE-26 detectedAt: 2026-08-13T12:20:00Z cause: "Packet BUILD-SYN-25 به Decision BUILD-SYN-26 متصل بود" invalidPacket: PKT-25 affectedDecisions: [TD-ANOM-SYN-26] affectedWorkflowItems: [FIX-CANDIDATE-26] containment: "Decision INVALID و Work متوقف شد" revalidation: PKT-26R1 correctedDisposition: NEEDS_INFO republishStatus: COMPLETE notified: [reporter, owner, authority] prevention: packet-build-digest-rule status: CLOSED
ویرایش بیصدای Priority یا Resolution کافی نیست. Decision قبلی، downstream Work، Release evidence، Duplicate links و Dashboardهای متاثر باید پیدا و اصلاح شوند. History باید نشان دهد چه چیزی، چه زمانی و با کدام Authority تغییر کرده است.
آزمایشگاه مصنوعی Checkout فارسی
تمام مثالها به `SYN-CHECKOUT` جدا و جعلی تعلق دارند: Order، PaymentAttempt، PSP Stub، Callback، Ledger و Reconciliation مصنوعی؛ timeout قبل/بعد از fake commit، Callback تکراری/دیر/جابجا و Failureهای Testware/Environment. هیچ شبکه، Production، شرکت، تیم، کاربر، پرداخت، بانک یا PSP واقعی وجود ندارد.
| بعد | Fixture مصنوعی | Triage input |
|---|---|---|
| Money | IRR خیالی canonical؛ تومان فقط نمایش برچسبدار | Impact و Basis جدا |
| Digits | فارسی، عربی و لاتین | Config و affected scope |
| Unicode/RTL | NFC، RTL/LTR و stable ID | Actual evidence و Browser config |
| Time | UTC، Asia/Tehran و جلالی فقط نمایشی | ObservedAt/Cutoff روشن |
| State | duplicate/late/reordered callback | Reproduction/Unknown |
| Identity | Tenant/Order/Attempt/Event/Ledger/Run/Build/Evidence جدا | Packet به same-Build متصل |
هیچ نام، موبایل، ایمیل، IP، حساب، PAN، CVV2، OTP، Cookie، Token، Credential، Screenshot یا Log واقعی استفاده نشده و هیچ ادعای بانکی، مالی، حقوقی، مالیاتی، امنیتی، حریم خصوصی یا انطباق دربارهٔ ایران مطرح نیست.
آزمایش اجرایی SYN-DEFECT-TRIAGE-DECISION-۰۱
یک Validator مستقل، قطعی و بدون dependency با Node.js v26.۷.۰ اجرا شد. Dashboard سطحی ۸۶/۸۶ Report reviewed، ۸۶ Decision و میانهٔ چهار دقیقه را PASS نشان میداد. ممیزی قرارداد ۱۵۸ قاعده داشت.
| گروه | تعداد | نمونه کنترل |
|---|---|---|
| Identity | ۱۸ | Policy، Workflow، Schemes، Build، Environment، Cutoff |
| Protocol | ۱۸ | Purpose، Scope، Query، Eligibility، Dedup، Vocabulary، Limit |
| Packet | ۲۴ | Report/Observation/Subject، Expected/Actual، Impact، Risk، digest |
| Decision | ۲۰ | Disposition، classification، severity، priority، authority، resume |
| Session | ۲۰ | Mode، agenda، capability، conflict، recusal، WIP، audit |
| Governance | ۱۸ | SLA، Reopen، Appeal، expiry، guardrail، Correction |
| ادعاهای ممنوع | ۳۳ | Severity=Priority، role/time/frequency ثابت، guarantees، AI closure |
| روابط بینفیلدی | ۷ | Packet/Report/Build، SLA، Duplicate، Needs-info، Authority |
رکورد سطحی با ۱۵۳ Finding به HOLD رفت: همهٔ ۱۱۸ فیلد قرارداد و ۳۳ ادعای ممنوع Fail شدند و دو رابطهٔ SLA/Authority نیز نقض شد. پنج رابطهٔ دیگر بهدلیل نبود داده یا Disposition شرطی فعال نشدند؛ شمارش برای «همهچیز قرمز» شدن دستکاری نشد.
fixture: SYN-DEFECT-TRIAGE-DECISION-01 rules: 158 superficial dashboard: reviewed: 86/86 decisions: 86 medianMinutes: 4 dashboardVerdict: PASS contractStatus: HOLD findings: 153 corrected protocol: packet: PKT-26 / sha256:packet-26 report: ANOM-SYN-26 build: BUILD-SYN-26 disposition: NEEDS_INFO resumeCondition: same-build-ledger-evidence decisionAuthority: risk-product-owner structuralFindings: 0 status: READY_FOR_TRIAGE_DECISION_REVIEW
نسخهٔ اصلاحشده هویتها، Schemeها، Intake، Packet و digest، Decision Authority، SLA، NEEDS_INFO/Resume، Session و Correction را کامل کرد و با صفر Finding به `READY_FOR_TRIAGE_DECISION_REVIEW` رسید. این وضعیت فقط آمادگی ساختاری تصمیم برای Review است؛ نه صدق Evidence، وجود قطعی Defect، درستبودن Severity/Priority، کفایت Fix، Product quality یا Release readiness.
شاخصهای تریاژ؛ سرعت را با کیفیت تصمیم جفت کنید
| Measure | Countermeasure | خطر تفسیر |
|---|---|---|
| Time to initial disposition | Evidence completeness | تصمیم سریعِ ضعیف |
| Queue age percentile | Service-class mix | Expedite میانگین را تحریف میکند |
| Ready-first-time | Reporter burden/accessibility | Gate سخت گزارش را سرکوب میکند |
| Needs-info rate | resume success/age | کم بودن میتواند Approval سطحی باشد |
| Duplicate rate | canonical-link validity | Reporter ranking ممنوع |
| Decision reversal | new-evidence rate | تغییر همیشه خطا نیست |
| Reopen rate | verification scope | سرزنش Fixer/Tester |
| Stale deferred age | review/expiry coverage | Backlog کم با حذف صوری |
| Appeal outcome | equity/access review | اعتراض زیاد یا کم بهتنهایی خوب/بد نیست |
| Correction closure | affected-decision completeness | Close اداری کافی نیست |
Automation و AI در Defect Triage
Automation میتواند Packet readiness، duplicate candidate، SLA، stale decision و required field را بررسی کند. AI میتواند classification/Priority/route پیشنهاد دهد و مشابهها را نشان دهد؛ اما پیشنهاد با تصمیم فرق دارد. حتی راهنمای رسمی Jira Triage Agent پیشنهادها را برای Accept/Reject کاربر ارائه میکند. Context، Policy و Authority انسانی همچنان لازماند.
- AI بهتنهایی Report را Close، Risk را Accept یا Reporter را رتبهبندی نکند.
- Model/prompt/policy/source و confidence نسخهدار باشند.
- Reasoning proposal، Unknown و Human decision ثبت شوند.
- اطلاعات شخصی، امنیتی و Production فقط طبق access/redaction policy مصرف شوند.
- مسیر Appeal، correction و Manual fallback حفظ شود.
۳۴ ضدالگوی Bug Triage
| ضدالگو | خطر | اصلاح |
|---|---|---|
| هر Anomaly=Defect | Classification از پیش قطعی | anomaly-first |
| Severity=Priority | Impact و ordering مخلوط | Schemeهای جدا |
| High severity=High priority همیشه | Exposure/goal حذف | contextual policy |
| Low severity=Low priority همیشه | deadline/visibility حذف | priority inputs |
| Priority حقیقت عینی | Authority پنهان | rationale/version |
| بلندترین صدا | Bias/قدرت | evidence+authority |
| QA مالک هر دو Scheme | Role universal | decision rights |
| PO مالک همهٔ تصمیمها | technical/risk authority مبهم | authority matrix |
| Assignee=Authority | task/decision اختلاط | separate fields |
| Accepted=حتماً Fix | تعهد کاذب | disposition semantics |
| Rejected=Reporter اشتباه | سرزنش/سرکوب | classification+rationale |
| Cannot reproduce=نیست | Unknown پنهان | attempt/config/evidence |
| Duplicate بدون Canonical | Evidence گم | link/merge/reopen |
| Deferred بدون Review | گورستان Backlog | owner/expiry |
| Fixed=Verified | ادعای Producer | independent verification rule |
| Closed=Product correct | Claim گسترده | closure limit |
| Triage حتماً جلسه است | Ceremony | mode fit |
| روزانه برای همه | ریتم نامتناسب | demand/SLA |
| هفتگی برای همه | Risk delay | service class |
| ارسال دقیقاً ۲۴ ساعت قبل | قاعدهٔ Contextless | readyAt policy |
| Timebox ثابت پنج دقیقه | تصمیم ناقص | question/risk-based |
| چهار Role ثابت | عنوان بهجای Capability | decision need |
| افراد بیشتر=بهتر | هزینه/حاشیه | minimum capabilities |
| افراد کمتر=همیشه بهتر | Authority/Evidence غایب | on-call/delegation |
| Blameless=بدون Accountability | Action بیOwner | system focus+ownership |
| Root cause در Triage | جلسه عمیق | investigation work item |
| Solution design در Triage | WIP و delay | parking rule |
| رأیگیری Severity | Popularity | scheme/evidence/authority |
| صفر Backlog=کیفیت | Close صوری | outcome/guardrails |
| سرعت=کیفیت | Goodhart | decision validity |
| همهٔ Defectها Fix شوند | Risk/value نادیده | explicit disposition |
| AI auto-close | Authority واگذار | human review |
| Edit بیHistory | Audit قطع | versioned decision |
| Correction فقط Field | downstream آلوده | affected-decision analysis |
چکلیست ممیزی تریاژ نقص
- Program، Product، Goal، Risk و Defect Policy نسخهدارند؟
- Workflow و Classification/Severity/Priority Scheme مشخصاند؟
- Release Policy از Triage Decision جداست؟
- Repository، Commit، Build، Environment، Data و Cutoff قفلاند؟
- Protocol ID/version، Purpose و Decision scope دارد؟
- Intake Query و Eligibility rule قابلبازتولیدند؟
- Dedup rule پیش از دیدن نتیجه تعریف شده است؟
- Service class و Decision vocabulary روشناند؟
- Claim limit نوشته شده است؟
- Packet ID/version و Report/Observation identity دارد؟
- Expected ref و Actual Evidence همان Subjectاند؟
- Reproduction status تشخیصی و محدود است؟
- Affected scope، Impact و Risk IDs ثبت شدهاند؟
- Severity فقط Proposal و مبتنی بر Scheme است؟
- Priority inputs و Unknownها دیده میشوند؟
- Duplicate candidate و related change لینکاند؟
- Packet digest به Decision متصل است؟
- Disposition و Classification جدا هستند؟
- Severity و Priority rationale دارند؟
- Evidence refs و Unknown در Decision حفظاند؟
- Owner capability و Decision authority جدا هستند؟
- decidedAt، dueAt، next action و next state موجودند؟
- NEEDS_INFO دارای Resume condition است؟
- DUPLICATE دارای Canonical ID است؟
- DEFER/ACCEPT_RISK Owner و Expiry دارند؟
- Session Mode و participant capabilities متناسباند؟
- Conflict، Recusal، Parking و Audit rules تعریف شدهاند؟
- Queue/WIP و SLA clock policy مشخصاند؟
- Reopen و Appeal امن و Evidence-based هستند؟
- Correction affected decisions و republish را پوشش میدهد؟
- Measureها Guardrail دارند و افراد را رتبهبندی نمیکنند؟
- AI فقط پیشنهاد میدهد و Auto-close/Risk acceptance ندارد؟
برنامه ۳۰ روزه برای اصلاح Defect Triage
| بازه | کار | خروجی |
|---|---|---|
| روز ۱–۵ | یک Product/Queue را Baseline و Decisionها را نمونهبرداری کنید | Current state و Unknown |
| روز ۶–۱۰ | Schemeها، Intake، Packet و Vocabulary را نسخهدار کنید | Protocol v1 |
| روز ۱۱–۱۵ | Authority، SLA، Resume/Duplicate/Defer rules را فعال کنید | Decision contract |
| روز ۱۶–۲۰ | Async/Meeting routing و Audit log را Pilot کنید | Session/Queue evidence |
| روز ۲۱–۲۵ | Reopen، Appeal و Correction drill اجرا کنید | Affected-decision path |
| روز ۲۶–۳۰ | Measureها و Guardrailها را بازبینی کنید | Keep/Adapt/Stop و Backlog محدود |
Pilot با کاهش مدت جلسه موفق نمیشود. موفقیت یعنی Packetهای قابلتصمیم بیشتر، Decisionهای دارای Authority/Evidence، Duplicateهای متصل، Needs-infoهای Resumeشده، Deferredهای غیرکهنه و Correction قابلاجرای بهتر—بدون سرکوب Report یا افزایش بار نامرئی Reporter.
جمعبندی: جلسه را به Decision Protocol تبدیل کنید
ضدالگوی اصلی Bug Triage نه صرفاً سرزنش، جمعیت زیاد یا بحث طولانی است؛ نبود یک قرارداد تصمیم است. وقتی Intake، Packet، Scheme، Authority، Disposition، SLA، Resume/Reopen و Correction روشن باشند، بخشی از تریاژ Async میشود، جلسههای باقیمانده روی Unknown و تعارض واقعی تمرکز میکنند و هیچ تیک سبزی جای Evidence را نمیگیرد.
سوالات متداول درباره جلسه تریاژ نقص
جلسه تریاژ باگ چیست و چه خروجی باید داشته باشد؟
تریاژ Capability تحلیل و تصمیم روی Anomaly report است. خروجی حداقلی شامل Classification، Severity/Priority با rationale، Disposition، Owner capability، Authority، Evidence/Unknown، dueAt، next state و در موارد شرطی Resume/Canonical/Expiry است.
تفاوت Severity و Priority باگ چیست؟
Severity شدت Impact را در Context مشخص میکند؛ Priority ترتیب نسبی اقدام را با Severity، Exposure، Goal، deadline، dependency، workaround، uncertainty و Risk appetite میسازد. سطح بالا در یکی الزاماً سطح بالا در دیگری نیست.
چه کسانی باید در Bug Triage باشند؟
عنوان و تعداد ثابت وجود ندارد. فقط Capabilityهای لازم برای Evidence، Technical classification، Impact/Risk، Facilitation و Authority تصمیم را حاضر یا On-call کنید. Reporter میتواند با Packet کامل Async مشارکت کند؛ Authority نیز باید حاضر یا delegation معتبر داشته باشد.
هر چند وقت یکبار جلسه تریاژ برگزار شود؟
ریتم عمومی روزانه یا هفتگی وجود ندارد. Arrival rate، Risk، Service class، Queue age و SLA را ببینید. موارد کمابهام Async، Expediteها Event-driven و Batchهای دارای تعارض در جلسهٔ زمانبندیشده تصمیمگیری شوند.
چطور از طولانیشدن جلسه تریاژ جلوگیری کنیم؟
Intake Query و Decision Packet را پیش از جلسه آماده، group reading را حذف، فقط Capability/Authority لازم را دعوت و Root cause/Fix design را Park کنید. Timebox باید Risk-based باشد و هر Item با Decision یا Investigation دارای Owner و dueAt خارج شود.
