گردش کار نقص، تصویر چند ستون در ابزار نیست؛ یک قرارداد State machine برای تصمیم و تحویل مسئولیت است. اگر «Fixed» هم Status باشد هم ادعای فنی، اگر «Rejected» دلیل نداشته باشد، اگر هرکس بتواند Severity را عوض کند یا اگر بستن تیکت تاریخچه را پاک کند، Board مرتب هم شواهد قابلاعتماد تولید نمیکند. از طرف دیگر، افزودن دهها وضعیت برای نمایش هر فعالیت، صف و گزارش را پیچیده میکند.
این راهنما یک Defect Workflow State Machine قابلممیزی میسازد: Object و Scope را هویت میدهد؛ State را از Resolution، Field، Label و Queue جدا میکند؛ Transition، Guard، Actor و Authority را تعریف میکند؛ Evidence و Clockها را حفظ میکند؛ Duplicate/Not-a-defect/Deferred/Accepted-risk/Reopen را بدون تحریف تاریخ پوشش میدهد؛ و پیش از مهاجرت ابزار، Conformance test اجرا میکند. هدف «بهترین Workflow» یا تضمین کیفیت نیست؛ هدف جلوگیری از State ناممکن و تصمیم بیردپا است.
پاسخ کوتاه: بهترین گردش کار ردیابی نقص چیست؟
یک نسخهٔ جهانی وجود ندارد. Workflow خوب کمترین Stateهایی را دارد که تفاوت معنیدار در مالکیت، کار مجاز، Evidence لازم، Clock یا تصمیم ایجاد میکنند. هر Transition مبدأ/مقصد، Trigger، Guard، Actor، Authority، Side effect و audit event دارد. Outcomeهایی مانند Duplicate، Not-a-defect، Won’t-do یا Fixed در Resolution/Reason نگهداری میشوند، نه اینکه بیقاعده با State مخلوط شوند.
| چیزی که میخواهیم بدانیم | مدل مناسب | نمونه |
|---|---|---|
| الان در چرخه کجاست؟ | State | TRIAGED، IN_PROGRESS، READY_FOR_VERIFICATION |
| چرا کار پایان یافت؟ | Resolution + reason | FIXED، DUPLICATE، NOT_A_DEFECT |
| چقدر مهم/فوری است؟ | Severity/Priority field | S2 / P1 با rubric |
| کدام دامنه است؟ | Type/component/label | API، accessibility، payment |
| چه کسی کار میکند؟ | Owner/assignee/team | Team Checkout |
| منتظر چیست؟ | Blocker/dependency relation | Build B17، Vendor case V4 |
مرز این مقاله با مدیریت نقص
راهنمای مدیریت نقص از Triage تا SLA و یادگیری مالک Intake، Severity/Priority، جلسهٔ Triage، SLA، aging، escape و بهبود کل فرایند است. این صفحه به لایهٔ پایینتر میپردازد: چگونه همان سیاستها را به State/Transition/Guard قابلاجرا و قابلتست تبدیل کنیم، چگونه نسخه را عوض کنیم و از دادهٔ Workflow نتیجهٔ غلط نسازیم.
اول Object را تعریف کنید؛ هر مشاهده Defect نیست
Anomaly مشاهدهای است که نیاز به بررسی دارد. Failure رخدادی مشاهدهشده است؛ Defect یک نقص در Work product میتواند باشد؛ Defect report رکورد ارتباطی دربارهٔ آن است. Incident، support request، change، debt، testware issue و security vulnerability ممکن است Workflow و محرمانگی متفاوت بخواهند. واژهها را در Glossary محلی تعریف کنید و ادعای «Error علت انسانی و Defect معلول» را به قانون جهانی تبدیل نکنید.
| Object type | Trigger | مسیر | نباید خودکار فرض شود |
|---|---|---|---|
| Product defect report | رفتار/Work product مشکوک | Defect workflow | علت یا fix معلوم است |
| Testware issue | Oracle/data/script/config مشکل دارد | مالک Test asset | Product defect است |
| Production incident | اختلال فعال | Incident response + links | منتظر Triage عادی میماند |
| Security vulnerability | ضعف قابلسوءاستفاده/گزارش بیرونی | restricted coordination | Board عمومی امن است |
| Change/enhancement | رفتار مطابق Basis ولی نیاز نامناسب | Product/change backlog | گزارش نامعتبر است |
| Support question | نیاز راهنما/بررسی | Support workflow | Defect حتماً وجود دارد |
Workflow Contract را نسخهدار کنید
DefectWorkflowContract WorkflowID / version / effective-from / owner / approver Object types and Product/Service scope Entry channels and normalization rules States: purpose / entry / allowed work / exit / clock policy Transitions: source / target / trigger / guard / actor / authority Required fields and evidence by transition Resolution and reason-code dictionaries Severity/priority/risk vocabularies and owners Duplicate/block/dependency/link semantics SLA/OLA clocks, calendars, pause/resume rules Notifications/integrations/automation identities Terminal/reopen/archive/correction rules Migration mapping / conformance suite / review / retirement
WorkflowID باید داخل هر audit event یا در reference قابلدسترسی باشد. وقتی Definition تغییر میکند، گزارشهای قبل و بعد را بدون mapping و effective date مقایسه نکنید.
State را با Activity یا Role یکی نگیرید
«در دست توسعهدهنده»، «QA Testing»، «Waiting for PO» یا «Dev Done» نقش/فعالیت/انتظار را در نام State میدوزد و با تغییر تیم میشکند. State باید تفاوت عملیاتی پایدار بسازد. Owner، current activity، blocker و queue را Field یا Relation نگه دارید مگر واقعاً Guard/Clock/Decision متفاوتی ایجاد کنند.
- هر State یک تعریف Entry/Exit و کار مجاز دارد؛
- دو State با Guard و تصمیم یکسان ادغام میشوند؛
- هر State دستکم یک مسیر خروج معتبر دارد؛
- Terminal state کار باز یا Clock فعال ندارد؛
- State نامشخصی مانند Done بدون Resolution ممنوع است؛
- Blocked یک Relation/flag با علت و owner است، نه قبرستان؛
- Waiting باید منتظر چه کسی/چه artifact/تا چه زمان را ثبت کند؛
- UI column میتواند چند State را نمایش دهد؛ Board مدل دامنه نیست.
State machine مرجع کوچک
| State | معنا | Guard ورود | خروجهای اصلی |
|---|---|---|---|
| SUBMITTED | رکورد دریافت و هویت داده شده | حداقل ورودی/Reporter/زمان | NEEDS_INFO، TRIAGED |
| NEEDS_INFO | تصمیم Triage با Evidence فعلی ممکن نیست | سؤال/مالک/موعد | SUBMITTED، terminal resolution |
| TRIAGED | نوع/ریسک/مالک/Disposition تعیین شده | Triage record | PLANNED، DEFERRED، CLOSED |
| PLANNED | در Queue تعهدشده با مقصد/مالک | priority/target rationale | IN_PROGRESS، DEFERRED |
| IN_PROGRESS | Analysis/change/mitigation فعال است | owner + work reference | READY_FOR_VERIFICATION، TRIAGED |
| READY_FOR_VERIFICATION | Resolution candidate و Build/Evidence آماده | resolution/build/change evidence | VERIFIED، REOPENED، NEEDS_INFO |
| VERIFIED | Verification محدود پاس شده | oracle/result/evidence | CLOSED، REOPENED |
| REOPENED | Resolution قبلی در Scope مقرر نپذیرفته شد | attempt/reason/new evidence | TRIAGED، IN_PROGRESS |
| DEFERRED | تصمیم فعال برای بعد، نه پایان | authority/reason/review/expiry | TRIAGED، PLANNED، CLOSED |
| CLOSED | چرخه با Resolution ثبتشده پایان یافته | resolution/authority/evidence/links | REOPENED یا successor طبق policy |
این مدل Template است، نه استاندارد. تیم کوچک میتواند TRIAGED و PLANNED را ادغام کند؛ محیط پرریسک ممکن است APPROVED_FOR_FIX، MITIGATED یا RELEASED را اضافه کند. معیار افزودن State، تصمیم/Guard/Clock واقعی است.
Transition Contract؛ پیکان هم داده میخواهد
DefectTransition TransitionID / workflow version FromState → ToState Trigger and business meaning Actor roles allowed to request Authority required to approve Guards and mandatory fields Evidence references and freshness Resolution/reason effects Owner/assignee/queue effects Clock start/pause/resume/stop Notification/integration/idempotency effects Audit event: who/when/from/to/why/changed fields Failure behavior / override / exception expiry
Actor و Authority یکی نیستند: تستر میتواند درخواست Reopen کند، ولی تغییر Scope یا پذیرش ریسک ممکن است صاحب اختیار دیگری بخواهد. Automation هم Actor مستقل با service identity است؛ «System» یا Admin ناشناس audit را بیارزش میکند.
Guard؛ وضعیت فقط با متن دکمه عوض نمیشود
- SUBMITTED→TRIAGED: Object type، Scope، Observation و owner معلوم؛
- TRIAGED→PLANNED: Priority/target/rationale و capacity authority؛
- IN_PROGRESS→READY_FOR_VERIFICATION: Build/change/mitigation reference و Resolution candidate؛
- READY_FOR_VERIFICATION→VERIFIED: Confirmation attempt، Oracle، result و Evidence؛
- VERIFIED→CLOSED: Resolution نهایی، linked decision و open dependency check؛
- هر→DEFERRED: reason، Risk owner، review date، expiry و trigger؛
- هر→CLOSED با DUPLICATE: canonical record و رابطهٔ duplicate؛
- هر→CLOSED با ACCEPTED_RISK: decision authority، scope، condition و expiry؛
- CLOSED→REOPENED: policy، reason، Evidence و link به Build/incident تازه؛
- Override: justification، approver، expiry و review؛ نه bypass بیردپا.
Resolution نتیجهٔ چرخه است، نه تضمین حقیقت
| Resolution | معنا | Evidence/authority | نباید ادعا کند |
|---|---|---|---|
| FIXED | تغییر/mitigation در Subject مشخص verify شده | change/build + verification | هیچ regression یا defect دیگری نیست |
| DUPLICATE | همان concern در رکورد canonical اداره میشود | canonical link + equivalence rationale | گزارش بیارزش بود |
| NOT_A_DEFECT | رفتار در Scope با Basis معتبر سازگار است | basis/version + reviewer | نیاز کاربر مناسب است |
| NOT_REPRODUCED | در تلاشهای ثبتشده مشاهده نشد | attempt/environment/data/limits | رخ نداده یا Reporter اشتباه کرده |
| WONT_DO | تغییر انتخاب نشده | option/risk/cost authority | Risk صفر یا Finding نامعتبر است |
| ACCEPTED_RISK | Risk محدود پذیرفته شده | risk owner/scope/condition/expiry | امن یا compliant است |
| OBSOLETE | Subject دیگر در دامنه نیست | removal/version evidence | تاریخچه پاک میشود |
| CANNOT_FIX | در قید فعلی تغییر ممکن نیست | constraint/options/review | برای همیشه غیرممکن است |
نامها را محلی انتخاب کنید، ولی Reason dictionary را versioned و بدون Free-text-only نگه دارید. توضیح آزاد مکمل Reason code است. تغییر Resolution باید audit و در گزارش correction دیده شود.
CLOSED مساوی FIXED نیست
CLOSED State پایانی Workflow است؛ FIXED یکی از Resolutionهاست. اگر همهٔ بستهشدهها را «رفعشده» گزارش کنید، Duplicate، Not-reproduced، Accepted-risk و Obsolete را تحریف میکنید. داشبورد باید State و Resolution را جدا جمع کند و denominator را اعلام کند.
Severity، Priority و Risk را از State بیرون نگه دارید
Severity اثر مشاهدهشده در Scope است؛ Priority ترتیب تصمیم/کار در Context؛ Risk احتمال/پیامد آینده با عدمقطعیت. یک نقص Severity بالا ممکن است با workaround و exposure پایین Priority متفاوت بگیرد؛ Priority میتواند با Release تغییر کند. State «Critical bug» یا «Low priority» تاریخچهٔ تصمیم و حرکت را مخلوط میکند.
DefectDecisionFields Severity: rubric + affected population/data/operation + evidence Priority: decision horizon + target + dependencies + authority Risk: condition/event/impact + likelihood/uncertainty + owner Customer/contract urgency: source + due + applicability Change history: old/new/value/actor/reason/time Overrides: approver + expiry + review
جزئیات Triage و Risk در راهنمای تست مبتنی بر ریسک تکمیل میشود. Workflow نباید با Matrix عددی ساختگی تصمیم را خودکار کند.
Intake؛ گزارش را بدون تخریب صدای Reporter نرمال کنید
گزارش میتواند از تست، Production، Support، Monitoring، Security researcher یا کاربر برسد. متن اصلی، زمان و Channel را immutable نگه دارید؛ نسخهٔ نرمالشده را جدا بسازید. Reporter نباید برای نداشتن اصطلاح فنی یا reproduction قطعی سرزنش شود.
DefectReport ReportID / source / reporter or protected identity / received-at Product/service/artifact/build/commit/config Environment/device/browser/region/locale/timezone Observed behavior + expected basis/version + difference Preconditions/state/data class (minimized) Steps or event sequence + frequency/attempts Impact/population/workaround/safety signal Logs/screenshots/traces with digest/redaction/retention Related test/run/incident/change/support/security records Reproduction status: NOT_TRIED | REPRODUCED | INTERMITTENT | NOT_OBSERVED Unknowns / access sensitivity / disclosure restrictions Normalizer / changed fields / original preserved
«Expected» باید به Requirement، rule، design decision، standard یا authorized Product interpretation وصل شود. نبود Basis میتواند Question/Change باشد؛ بهخودیخود گزارش را Invalid نمیکند.
Duplicate؛ شباهت عنوان کافی نیست
دو گزارش با Symptom مشابه ممکن است Cause یا affected version متفاوت داشته باشند؛ دو Symptom متفاوت ممکن است یک Constraint مشترک داشته باشند. Deduplication باید canonical record، equivalence scope، affected builds/populations، Evidence و link دوطرفه داشته باشد. Reporter و Watcherهای رکورد فرعی باید Update مهم را دریافت کنند.
- جستوجوی candidate با text/component/signature فقط پیشنهاد است؛
- Human review یا rule معتبر equivalence را تعیین میکند؛
- Duplicate reason بدون canonical ID ممنوع؛
- Evidence منحصربهفرد به canonical منتقل/لینک میشود؛
- Scope mismatch رکورد را merge نمیکند؛
- بازشدن canonical اثر رکوردهای مرتبط را اعلام میکند؛
- اشتباه dedupe قابلUndo و audit است؛
- Duplicate rate برای تنبیه Reporter KPI نیست.
Needs Info و Not Reproduced قبرستان نیستند
NEEDS_INFO یک State فعال با سؤال دقیق، owner، کانال امن، due date و fallback است. NOT_REPRODUCED یک Resolution محدود به Attemptها و محیطهای ثبتشده است. Timeout خودکار میتواند بستهشدن اداری بسازد، اما نباید «مشکل وجود ندارد» گزارش شود؛ پیامد بالا ممکن است Exploration، telemetry یا monitoring بخواهد.
Deferred و Accepted Risk را جدا نگه دارید
| مفهوم | State/Resolution | نیاز | بازشدن |
|---|---|---|---|
| Deferred | State غیرپایانی یا disposition زماندار | reason/target/review/owner | date، dependency، risk change |
| Backlog | Queue/commitment policy | priority/target/capacity | planning/replenishment |
| Wont-do | Resolution پایانی تصمیم تغییر ندادن | options/rationale/authority | condition/new evidence |
| Accepted risk | Resolution/linked risk decision | scope/condition/expiry/owner | expiry/exposure/incident |
| Obsolete | Resolution پایانی | subject removal evidence | feature restored/reintroduced |
Deferred بدون review date فقط پنهانکردن Queue است. Accepted risk را تستر یا Developer بهطور پیشفرض تصویب نمیکند؛ صاحب اختیار باید در مدل مسئولیت و تصمیم نامگذاری شود.
Verification؛ تغییر کد با حل Concern یکی نیست
DefectVerification VerificationID / defect / resolution candidate Subject build/commit/config/environment Change/mitigation and claimed scope Test basis/oracle/version/tolerance/window Precondition/state/data/cleanup Confirmation attempts and actual result Focused regression scope + exclusion rationale Evidence artifacts/digests/redaction PASS | FAIL | ERROR | BLOCKED | INCONCLUSIVE Limitations/unknowns/expiry Verifier / independence need / reviewed-at Transition recommendation, not automatic release approval
PASS در Confirmation فقط Claim محدود را پشتیبانی میکند. Regression کامل، نبود defect، امنیت، کیفیت یا Release readiness را ثابت نمیکند. چرخهٔ Run/Attempt/Outcome در راهنمای مدیریت اجرای تست جزئیتر شده است.
Reopen؛ تاریخ را بازنویسی نکنید
Reopen باید نشان دهد Resolution قبلی در کدام Build/Scope پذیرفته نشد یا Evidence تازه چه چیزی را تغییر داد. Attempt قبلی پاک نمیشود. اگر Concern تازه فقط مشابه است یا نسخه/سبب متفاوت دارد، رکورد جدید با رابطهٔ regression/related-to بهتر از Reopen بیپایان است.
| وضعیت | Reopen همان رکورد | رکورد تازه |
|---|---|---|
| Confirmation در همان fix fail شد | بله | معمولاً خیر |
| همان Concern در Build بعد بازگشت | طبق policy؛ regression link | برای cycle/metrics جدا مفید |
| Symptom مشابه، cause/Scope متفاوت | خیر | بله با related link |
| Accepted-risk منقضی شد | بله یا successor طبق policy | اگر context کاملاً تازه است |
| Reporter Evidence تازه داد | اگر همان Claim | اگر Claim تازه |
Clock و SLA؛ Calendar و Pause باید قابلبازتولید باشند
Aging بر پایهٔ Created تا Closed اغلب Queue، کار، انتظار Reporter، deploy و verification را مخلوط میکند. Clockها را رویدادمحور و جدا کنید: time-to-acknowledge، time-to-triage، queue-to-start، active resolution، wait-for-build، wait-for-verification، decision age و total elapsed.
DefectClockPolicy ClockID / purpose / population Start event / stop event Pause states/reasons and who may pause Calendar/timezone/working-hours/holidays Severity/priority/service class mapping Target vs hard deadline Missing/out-of-order event behavior Reopen reset/continue/new-clock policy Exception/override/expiry Source query/version and correction rule
Pause در NEEDS_INFO میتواند رفتار بد بسازد اگر سؤال مبهم باشد یا تیم داخلی تأخیر را به Reporter منتقل کند. SLA سبز لزوماً Outcome خوب نیست؛ backlog age، reopen، resolution mix و harm را کنار آن ببینید.
Scrum Workflow و Kanban Workflow نامگذاری گمراهکنندهاند
راهنمای رسمی Scrum Guide 2020 Defect status یا Bug workflow تجویز نمیکند؛ تاکتیکهای Context-sensitive را بیرون تعریف Scrum میگذارد. Scrum میتواند Fix را در Product Backlog یا Sprint work اداره کند، اما State machine شما باید همچنان Evidence، authority و terminal semantics داشته باشد. Kanban visualization/WIP نیز ستونهای Board را به Lifecycle حقیقت تبدیل نمیکند.
| Context profile | تنظیم Workflow | ثابتهای لازم |
|---|---|---|
| تیم کوچک/کمریسک | State کمتر، Triage async | reason/evidence/audit |
| محصول چندتیمی | routing/ownership/dependency قوی | canonical ID/system of record |
| Release زمانبندیشده | target build/fix version/deploy verify | Build identity/decision authority |
| Continuous delivery | short queues/automation/rollout links | attempt/rollback/production evidence |
| Safety/regulatory | approval/independence/retention بیشتر | traceability/no bypass |
| Open source/external | public intake/privacy/moderation | reporter protection/communication |
| Security | restricted states/disclosure coordination | authorization/confidentiality/mitigation |
منبع ISTQB چه میگوید و چه نمیگوید؟
ISTQB CTAL Test Management v3.0 یک نمونهٔ سادهٔ OPEN→IN PROGRESS→RESOLVED→CLOSED همراه REJECTED نشان میدهد و تصریح میکند Stateها، Transition rules و Roleها با سازمان فرق میکنند و Workflow باید با Context سازگار شود؛ Duplicate و false positive نیز باید قابلتحلیل بمانند. این منبع Vocabulary آموزشی است، نه الزام Certification، ابزار، نام State یا معماری همین مقاله.
Tool primitive را با Policy اشتباه نگیرید
Issue tracker ممکن است Status، label، assignee، project field، milestone، automation و permission بدهد. مستندات GitHub Projects نیز Viewهای table/board/roadmap و Fieldهای سفارشی را ابزار انعطافپذیر معرفی میکند، نه یک Methodology اجباری. Jira، GitHub، GitLab، Azure DevOps، Redmine یا ابزار دیگر را پس از Contract و PoC انتخاب کنید؛ برند، State semantics را طراحی نمیکند.
- آیا Guard واقعاً enforce میشود یا فقط متن راهنماست؟
- Permission به Actor/Authority mapping میخورد؟
- History شامل from/to/actor/time/reason/field diff است؟
- API/Webhook eventها idempotent، versioned و قابل-reconcile هستند؟
- Reason code و canonical duplicate link اجباری است؟
- Clock calendar/pause/reopen قابلپیادهسازی است؟
- Restricted security item و field-level access ممکن است؟
- Export شامل history/attachment/link/schema است؟
- Automation نمیتواند Guard را bypass کند؟
- دسترسی/Region/پرداخت/Export از ایران آزمایش شده؟
امنیت؛ Vulnerability را در Board عمومی نریزید
جزئیات ضعف امنیتی، exploit، affected asset و Reporter identity ممکن است سوءاستفاده یا آسیب ایجاد کند. CERT/CC توضیح میدهد Vulnerability coordination میان چند ذینفع برای تحلیل، remediation و disclosure انجام میشود. این راهنما جای Policy حقوقی/امنیتی یا هماهنگکنندهٔ ذیصلاح نیست.
- کانال intake و دامنهٔ تست مجاز؛
- تأیید دریافت و ارتباط امن با Reporter؛
- least disclosure و role/field-level access؛
- Evidence encryption/redaction/retention؛
- asset/affected version/exploitability/risk؛
- vendor/subprocessor/dependency coordination؛
- mitigation، fix، backport و affected-user path؛
- disclosure decision، timeline و authority؛
- CVE/identifier در صورت کاربرد، نه بهعنوان Severity؛
- incident escalation اگر exploitation فعال است؛
- audit بدون افشای عمومی؛
- post-disclosure correction.
روابط بین رکوردها را نوعدار کنید
| Relation | معنا | Invariant |
|---|---|---|
| DUPLICATES | Concern در canonical اداره میشود | یک canonical فعال و بدون cycle |
| BLOCKS / BLOCKED_BY | پیشرفت وابسته است | جهت/owner/condition |
| CAUSED_BY | Cause با Evidence حمایت شده | فرضیه را Fact ننامد |
| REGRESSION_OF | رفتار قبلی بازگشته | version/fix lineage |
| FOUND_BY | Test/run/monitor/incident source | source immutable |
| FIXED_BY | Change candidate | merge به معنی verify نیست |
| VERIFIED_BY | Attempt/Evidence | subject/build/oracle |
| AFFECTS / SUPERSEDES | نسخه/رکورد اثرپذیر یا جایگزین | scope/effective time |
Free-text «مرتبط با #۱۲» برای Query و Integrity کافی نیست. Relationهای معکوس را atomic یا reconciliationپذیر نگه دارید.
Audit Event؛ تاریخچه برای پاسخگویی، نه نظارت فردی
DefectWorkflowEvent EventID / defectID / workflowVersion EventType / occurred-at UTC / recorded-at UTC Actor identity/type / delegated authority FromState / ToState Changed fields: old/new with sensitive-field policy Reason code / rationale / evidence references Source UI/API/import/automation + request/correlation ID Idempotency key / sequence scope Override/exception reference Digest/retention/redaction/correction link
Event log نباید برای رتبهبندی سرعت افراد، میزان «بستن باگ» یا ساعات کار استفاده شود. هدف بازسازی تصمیم، کشف Drift و اصلاح داده است. دادهٔ حساس Reporter یا Security نباید در Export عمومی بیاید.
Automation و Integration؛ Effect-once طراحی کنید
CI میتواند defect candidate بسازد، PR میتواند change link کند و Deploy میتواند Verification را قابلاجرا کند؛ هیچکدام نباید Closure را صرفاً از روی سبزی Pipeline انجام دهد. Webhook ممکن است تکراری، دیر یا خارج از ترتیب برسد. از event ID، idempotency، sequence scope، retry/backoff، DLQ و reconciliation استفاده کنید.
| Automation | عمل مجاز | Guard انسانی/سیستمی |
|---|---|---|
| Failed check | candidate/update evidence | dedupe + expected-failure policy |
| PR merged | change candidate linked | target build هنوز لازم |
| Build deployed | READY_FOR_VERIFICATION candidate | artifact/config mapping |
| Confirmation passed | verification evidence | oracle/attempt/scope/authority |
| Timeout | alert/escalate | نه auto-close/accepted risk |
| Duplicate webhook | no-op with audit | idempotency key |
| Reconciliation | repair drift | dry-run/approval/correction |
اگر Issue tracker با Test management/CI/Chat یکپارچه میشود، راهنمای Data Contract، Retry و Trace semantics تحویل و reconciliation را تکمیل میکند.
Invariantهای Workflow را قابلاجرا کنید
- State و Resolution از dictionary همان version هستند؛
- Transition در Contract مجاز است؛
- Guardهای مقصد کاملاند؛
- Actor مجاز و Authority معتبر است؛
- terminal بدون Resolution وجود ندارد؛
- non-terminal Resolution نهایی ندارد؛
- DUPLICATE canonical معتبر و non-cyclic دارد؛
- DEFERRED owner/review/expiry دارد؛
- ACCEPTED_RISK scope/authority/expiry دارد؛
- READY_FOR_VERIFICATION build/change candidate دارد؛
- VERIFIED attempt و Evidence معتبر دارد؛
- REOPENED به resolution/attempt قبلی اشاره میکند؛
- Clock eventها ordered یا explicitly corrected هستند؛
- هر mutation audit event دارد؛
- automation identity و idempotency key معلوم است؛
- restricted item در notification/export نشت نمیکند.
Conformance Scenarioهای ضروری
| Scenario | انتظار |
|---|---|
| Happy fix path | Submitted→Triaged→In progress→Ready→Verified→Closed/Fixed |
| Verification fail | Attempt حفظ و Reopened؛ بدون پاککردن Fixed candidate |
| Duplicate | canonical اجباری، relation بدون cycle، subscriber transfer |
| Not reproduced | attempt/environment/limits اجباری |
| Deferred expiry | بازگشت به triage یا escalation، نه ماندن خاموش |
| Accepted risk | authority/scope/condition/expiry و reopen trigger |
| Unauthorized transition | رد بدون mutation، audit security event |
| Missing guard | رد با field errors قابلفهم |
| Duplicate webhook | یک effect و چند delivery record |
| Out-of-order deploy | نسخهٔ کهنه State را عقب نبرد |
| Import legacy | mapping/confidence/quarantine برای ambiguous |
| Security export | restricted fields/attachments حذف یا مجازسازی شوند |
آزمایش مستقل: پنج Status در برابر ۵۲۸ کنترل
برای جلوگیری از اینکه مقاله فقط نمودار پیشنهادی باشد، یک Validator قطعی و بدون وابستگی روی Node.js ۲۴.۱۸.۰ اجرا شد. Fixture کاملاً ساختگی SYN-DEFECT-WORKFLOW-STATE-01 فقط پنج Status آشنا داشت: New، Assigned، Fixed، Retested و Closed. بررسی سطحی وجود آنها را کافی دانست و خروجی گمراهکننده داد:
STANDARD_DEFECT_LIFECYCLE_HIGH_QUALITY_READY
ممیزی مستقل دقیقاً ۵۲۸ کنترل یکتای group-qualified را در ۲۹ گروه identity، scope، terminology، intake، report، state، transition، guard، actor، authority، resolution، reason، duplicate، severity، priority، evidence، verification، reopen، defer، clock، queue، security، automation، migration، conformance، metric، governance، correction و limits مطالبه کرد. Fixture شعاری هیچکدام را نداشت:
HOLD-528 NO_REAL_TARGET_PASS
قانون مستقل دوم تأیید کرد هیچ Product، Organization، Reporter، System، Vulnerability، Payment یا Outcome واقعی در آزمایش نیست. پس از درج همهٔ کنترلهای ساختگی با کلید یکتا و assertion تعداد/uniqueness، نتیجهٔ ساختاری اصلاح شد:
READY_FOR_DEFECT_WORKFLOW_STATE_MACHINE_REVIEW-0
این نتیجه فقط کاملبودن ساختار Fixture را نشان میدهد؛ نه اینکه Observation واقعاً Defect است، Severity/Priority درستاند، Resolution/Verification معتبر است، Workflow برای Context کافی است، Security/Compliance برقرار است، defectها رفع شدهاند، کیفیت محصول بهتر شده یا Release آماده است.
آزمایشگاه آفلاین فارسی؛ Callback ساختگی
آزمایشگاه هیچ شبکه، Product، سازمان، Reporter، بانک، PSP، پرداخت یا پول واقعی ندارد. چهار Defect report ساختگی دربارهٔ Order، PaymentAttempt، PSP Stub، Callback، Ledger و Reconciliation ساخته میشوند؛ یک Duplicate، یک timeout-after-fake-commit، یک verification failure و یک Accepted-risk منقضیشونده دارند.
SYN-DEFECT-CALLBACK-LAB-01 Workflow: DWF-7 / fixture-only Builds: WEB-R12 / API-B44 / STUB-P3 Faults: timeout-before/after-fake-commit; duplicate/late/reordered Data: fictional Order/Attempt/Callback/Ledger/Reconciliation Money: fictional IRR; labelled display-only toman Locale: fa-IR/RTL; Persian/Arabic/Latin digits; ی/ي; ک/ك; ZWNJ Time: UTC events; Asia/Tehran views; Jalali presentation-only No network/Production/real person/org/system/vulnerability/payment/outcome
Runner transitionهای مجاز/غیرمجاز، Guard، canonical duplicate، audit event، idempotent webhook، out-of-order deploy، reopen و expiry را روی Eventهای ساختگی امتحان میکند. PASS این آزمایش فقط State machine fixture را میسنجد و Benchmark ابزار یا فرایند واقعی نیست.
مهاجرت Workflow؛ Board را یکشبه عوض نکنید
- Inventory State/Resolution/Field/Automation/Query/Dashboard/API؛
- مشاهدهٔ استفادهٔ واقعی و Stateهای مرده/ambiguous؛
- Contract و dictionary جدید با Decision owner؛
- Old→New mapping یکبهیک/چندبهیک/ambiguous؛
- Legacy snapshot، digest و recoverable backup؛
- Dry-run روی کپی کمینه و redacted؛
- Conformance suite و report reconciliation؛
- Shadow read/report پیش از write cutover؛
- Freeze window و idempotent migration؛
- Quarantine رکورد ambiguous، نه حدس؛
- Update integration/template/dashboard/training؛
- Canary team، rollback criteria و support؛
- Post-cutover count/link/history/clock checks؛
- Old workflow read-only retention و retirement date.
WorkflowMigrationRecord MigrationID / oldVersion → newVersion Scope/query/snapshot/digest/counts State-resolution-field mapping version Ambiguous records and quarantine owner History/link/attachment/comment preservation Automation/integration/dashboard consumers Dry-run/conformance/reconciliation evidence Cutover actor/time/idempotency Rollback checkpoint/criteria/result Post-check/correction/notification Legacy retention and deletion authority
Metricهای Workflow با denominator و Countermetric
| Measure | تصمیم | Countermetric/limit |
|---|---|---|
| Time in state/queue | کجا انتظار است؟ | work class/blocked reason |
| Transition rejection | Guard/UX مبهم است؟ | unsafe bypass/override |
| Resolution mix | چرا چرخهها پایان مییابند؟ | severity/source mix |
| Reopen by reason | verification/fix/Scope مشکل دارد؟ | new-versus-same concern |
| Deferred overdue | تصمیمهای زماندار رها شدهاند؟ | risk/owner/expiry |
| Needs-info age | ارتباط کجا میماند؟ | question quality/reporter burden |
| Audit completeness | تصمیم قابلبازسازی است؟ | capture/privacy cost |
| Migration mismatch | داده سالم منتقل شد؟ | quarantine/false correction |
Defect count، closure rate، developer fix speed یا tester reopen rate نباید KPI فردی یا کیفیت Product باشد. Trend ممکن است از Release mix، Detection، policy یا migration تغییر کند. گزارش Evidence تا تصمیم محدودیت Claim را برای ذینفعان حفظ میکند.
Governance و تغییر Workflow
WorkflowChangeProposal ProposalID / problem / evidence / affected decisions Current behavior and failure mode Proposed state/transition/guard/dictionary change Alternatives including no change Impact: roles, queues, clocks, integrations, reports, security Backward compatibility and migration need Conformance scenarios / Pilot / countermetrics Owner / approver / dissent / effective date Rollback / documentation / training / review / correction
تعداد Statusها را در Retrospective بر اساس سلیقه کموزیاد نکنید. Change باید مشکل، Evidence و مصرفکنندگان داده را نشان دهد. Admin ابزار بهطور خودکار صاحب اختیار Process نیست.
Correction؛ وقتی State یا Resolution اشتباه ثبت شد
DefectWorkflowCorrection CorrectionID / affected record/events/report Original value/transition/claim retained Error discovered-at / source / impact scope Corrected value or compensating event Authority / rationale / evidence Clock/metric/dashboard/release-decision effects Related records and stakeholder notification Reconciliation/revalidation result No silent edit / no invented historical timestamp
اگر State بهاشتباه Closed یا Severity تغییر کرده، timestamp تاریخی جعل نکنید. Event اصلاحی امروز را با effective meaning ثبت و گزارشهای متاثر را reissue کنید.
ضدالگوهای Workflow نقص
- یک «چرخه عمر استاندارد» برای همهٔ Contextها؛
- نامگذاری Simple/Standard/Scrum/Kanban بهعنوان چهار مدل کامل؛
- Board column مساوی State domain؛
- State برای Severity/Priority/Role/Component؛
- Done/Closed بدون Resolution؛
- Closed مساوی Fixed؛
- Resolved بدون Build/change candidate؛
- Fixed توسط merge شدن PR؛
- Verified بدون Oracle/Attempt/Evidence؛
- Rejected بدون Reason؛
- Duplicate بدون canonical link؛
- Not reproduced مساوی وجود ندارد؛
- Needs info بدون سؤال/owner/deadline؛
- Deferred بدون review/expiry؛
- Accepted risk توسط Assignee؛
- Blocked بهعنوان قبرستان State؛
- Reopen با پاککردن تاریخ Fixed؛
- هر regression در رکورد قدیمی بیانتها؛
- Admin ابزار صاحب Process/authority؛
- Automation ناشناس با bypass Guard؛
- Auto-close از روی CI green یا inactivity؛
- Webhook at-most-once فرضشده؛
- Security vulnerability در Board عمومی؛
- گزارش ناقص به معنی Reporter بد؛
- بستن زیاد بهعنوان Productivity؛
- SLA pause برای سبزکردن Dashboard؛
- مهاجرت با mapping حدسی و حذف history؛
- ویرایش خاموش State/Resolution/Metric.
چکلیست مالک Defect Workflow
- WorkflowID/version/effective date/owner مشخص است؟
- Object type و Scope از Incident/Change/Security جداست؟
- Glossary محلی Observation/Failure/Defect/Report دارد؟
- State از Resolution/Field/Label/Queue جداست؟
- هر State purpose/entry/work/exit/clock دارد؟
- State مرده یا دو State هممعنا حذف شده؟
- هر Transition source/target/trigger دارد؟
- Actor درخواستکننده از Authority جداست؟
- Guardها در UI/API/import/automation enforce میشوند؟
- Override reason/approver/expiry/audit دارد؟
- Terminal بدون Resolution ناممکن است؟
- Reason dictionary versioned و reportable است؟
- Duplicate canonical/equivalence/no-cycle دارد؟
- Severity/Priority/Risk rubric و history دارند؟
- اصل گزارش و نسخهٔ normalizeشده حفظ میشوند؟
- Basis/Build/Environment/Data/Evidence هویت دارند؟
- Needs-info سؤال/owner/due/fallback دارد؟
- Not-reproduced Attempt و limits دارد؟
- Deferred owner/review/expiry/trigger دارد؟
- Accepted-risk authority/scope/condition/expiry دارد؟
- Verification Oracle/attempt/result/evidence دارد؟
- Reopen به Resolution و Evidence قبلی وصل است؟
- Clock calendar/timezone/pause/reopen policy دارد؟
- Security item access/disclosure/incident branch دارد؟
- Relationها typed، directional و queryable هستند؟
- هر mutation audit event immutable دارد؟
- Automation identity/idempotency/order/reconciliation دارد؟
- Conformance happy/edge/negative/security tests اجرا شده؟
- Tool انتخابی export/history/guard نیاز را پاس میکند؟
- Iran access/region/payment/export/fallback آزمایش شده؟
- Migration snapshot/mapping/quarantine/rollback دارد؟
- Metric denominator/mix/countermetric/claim limit دارد؟
- Workflow change Pilot/impact/consumers/rollback دارد؟
- Correction بدون silent edit و report reissue تعریف شده؟
Pilot سیروزهٔ بدون سیستم واقعی
| بازه | کار | خروجی | Stop condition |
|---|---|---|---|
| روز ۱ تا ۵ | Object/glossary/current-state inventory | Workflow contract v0 | Security/incident مخلوط شود |
| روز ۶ تا ۱۰ | state/resolution/transition/guard | machine + dictionaries | authority یا terminal مبهم |
| روز ۱۱ تا ۱۵ | fixture reports/relations/clocks | synthetic event set | داده/Reporter واقعی لازم شود |
| روز ۱۶ تا ۲۰ | automation/conformance negative tests | pass/fail evidence | guard bypass یا secret leak |
| روز ۲۱ تا ۲۵ | migration dry-run/reconciliation | mapping/quarantine/rollback | history/link loss |
| روز ۲۶ تا ۳۰ | metric/governance/correction drill | reviewable operating pack | silent edit یا people KPI |
این Pilot فقط Contract و State machine را با Fixture میآزماید. برای استقرار واقعی باید سیاست محصول، حقوق دسترسی، داده، امنیت، قرارداد، ابزار و تصمیمگیران واقعی وارد شوند و rollout کوچک قابلبازگشت باشد.
جمعبندی؛ Workflow زبان تصمیم است
گردش کار مؤثر با تعداد Status یا نام ابزار سنجیده نمیشود. باید نشان دهد Record چه Objectی است، اکنون در چه Stateی قرار دارد، چرا و با چه Authority انتقال یافته، چه Evidence/Resolutionی دارد، کدام Clock فعال است و چگونه میتوان خطا را Reopen یا Correct کرد.
زنجیرهٔ حرفهای این است: Object/Scope → Intake/Report → State → Transition/Guard → Actor/Authority → Evidence → Resolution → Verification/Reopen → Clock/Relation → Audit → Migration/Conformance → Governance/Correction. کمینهبودن خوب است، اما فقط وقتی معنای تصمیم و تاریخچه حذف نشود.
سوالات متداول
حداقل Statusهای لازم برای گردش کار باگ چیست؟
عدد جهانی نیست. حداقل باید Intake/Triage، کار فعال، آمادهٔ Verification، پایان و در صورت نیاز Reopen/Deferred را بدون ابهام اداره کند. اگر دو State Guard/Owner/Clock/Decision یکسان دارند، ادغام؛ اگر یک State چند معنای عملیاتی دارد، تفکیک کنید. Resolution را جدا نگه دارید.
تفاوت Resolved، Verified و Closed چیست؟
در یک قرارداد رایج، Resolved/Ready یعنی Change یا Disposition candidate ارائه شده؛ Verified یعنی Oracle محدود روی Build مشخص آن را پشتیبانی کرده؛ Closed یعنی Workflow با Resolution نهایی پایان یافته. نامها میتوانند عوض شوند، اما Guard و Claim limit باید روشن باشند. Closed الزاماً Fixed نیست.
چه کسی باید باگ را ببندد یا Reopen کند؟
Title جهانی وجود ندارد. Actor میتواند Transition را درخواست کند، ولی Authority از Context/Risk میآید. معمولاً Producer تغییر نمیتواند Evidence خود را بهتنهایی تأیید کند وقتی استقلال لازم است؛ پذیرش ریسک هم با Assignee یا QA پیشفرض نیست. Role/Authority را در Contract ثبت کنید.
آیا در Scrum باگ باید User Story باشد؟
Scrum Guide نوع Issue یا Workflow باگ تجویز نمیکند. تیم میتواند Fix را در Product/Sprint Backlog اداره کند، اما نوع Work item نباید Evidence، Resolution، Severity/Risk یا تاریخچهٔ Defect را حذف کند. تصمیم برحسب Product، اندازه، Risk، reporting و tool integration است.
بهترین ابزار برای گردش کار ردیابی نقص کدام است؟
پس از تعریف Contract مشخص میشود. دو یا سه ابزار را با State/Guard/Permission/audit/API/idempotency/report/security/export/migration و دسترسی ایران روی Fixture آزمایش کنید. ابزار محبوب یا قابلسفارشیسازی ممکن است Guard را enforce نکند یا Exit پرهزینه داشته باشد؛ نام برند جای PoC را نمیگیرد.
