یک گزارش باگ ممکن است عنوان، Steps، Expected، Actual و Screenshot داشته باشد و باز هم برای نفر بعد قابل اجرا نباشد. مشکل معمولاً کمبود نثر نیست؛ زنجیرهٔ «کدام Build، با چه State و Data، در چه Attempt، با کدام Oracle و Evidence» گم شده است. این راهنما مالک Reproduction Contract و Evidence Packet است: قراردادی که یک مشاهده را بدون افشای دادهٔ حساس، به اجرای شاهد، Replay، Triage و Verification تحویل میدهد.
برای قالب عمومی یک تیکت از راهنمای گزارش باگ حرفهای استفاده کنید؛ برای رخداد واقعاً متناوب یا Cannot Reproduce به راهنمای بازتولید باگ متناوب بروید؛ و تصمیمهای Lifecycle، Disposition و Closure را در چرخه عمر باگ نگه دارید. این مقاله جای آنها را نمیگیرد.
پاسخ کوتاه: گزارش باگ قابل بازتولید چیست؟
گزارش قابل بازتولید یک «دستور قطعی برای تولید خطا» نیست. این گزارش یک قرارداد نسخهدار است که Observation، Oracle، Build/Config، State/Data، Trigger، Attempt، Outcome، Evidence، Correlation، محدودیت و مالک مرحلهٔ بعد را ثبت میکند. گیرنده باید بداند چه چیزی را Replay کند، چه تفاوتی را اندازه بگیرد، چه دادهای را نبیند و اگر نتیجه متفاوت بود چگونه پاسخ دهد.
| ادعا | شاهد لازم | ادعای ممنوع |
|---|---|---|
| Failure مشاهده شد | Actual + time/build/attempt | Root cause پیدا شد |
| در شرایط ثبتشده تکرار شد | Replay outcome + identity | همیشه رخ میدهد |
| Expected نقض شد | Oracle/source/version | طراحی قطعاً غلط است |
| Evidence همبسته است | run/request/trace IDs | تمام لاگها متعلق به همان رخدادند |
مرز مالکیت: Report، Reproduction Contract و Defect یکی نیستند
| Artifact | پرسش | مالک محتوایی |
|---|---|---|
| Bug Report | چه مشکلی گزارش شده؟ | Intake و قالب تکتیکت |
| Reproduction Contract | مشاهده در چه شرایطی قابل Replay/ردیابی است؟ | این راهنما |
| Canonical Defect | کدام Reportها یک نقص واحدند؟ | Defect management |
| Investigation | مکانیسم یا Root cause چیست؟ | Engineering/incident workflow |
| Verification Pack | Fix در Build هدف و دامنهٔ Regression چگونه سنجیده شد؟ | Verifier + release evidence |
بنابراین «قابل بازتولید» یک Disposition قطعی نیست. ممکن است Report آمادهٔ Handoff باشد ولی هنوز گیرنده Replay نکرده باشد؛ یا Failure تکرار شود اما Expected از Source معتبر پشتیبانی نشود. مدیریت چند منبع، Duplicate، Triage، SLA و Risk acceptance متعلق به سیستم مدیریت نقص نرمافزار است.
Observation، Interpretation، Hypothesis و Cause را جدا کنید
| نوع | نمونهٔ دقیق | نحوهٔ ثبت |
|---|---|---|
| Observation | API در ۲۰:۰۰:14Z status=Pending برگرداند | Fact + Evidence |
| Interpretation | وضعیت سفارش با انتظار ناسازگار است | Oracle comparison |
| Hypothesis | Callback دوم قبل از commit رسیده | آزمایشپذیر، نه Fact |
| Cause | مکانیسم تأییدشده با تغییر کنترلشده | Investigation record |
| Recommendation | Idempotency test افزوده شود | Option، نه اثبات Cause |
Oracle پیش از Steps میآید
Steps فقط مسیر رویداد را میگویند. بدون Oracle نمیدانیم چه چیزی نقض شده است. Oracle میتواند Requirement نسخهدار، API contract، invariant دامنه، Design approval، Accessibility requirement یا رفتار مقایسهای معتبر باشد. متن «به نظرم باید…» را Expected قطعی ننامید.
Oracle Contract oracle_id: claim: source + version/hash: applicable build/config/role/state: observable surface: comparison rule/tolerance: unknown/conflict: owner for clarification: captured_at:
عنوان یک Locator است، نه داستان کامل
عنوان باید Entity/Surface، Trigger یا Condition و Observable Failure را قابل جستوجو کند. Severity، علت حدسی، نام مقصر و عبارتهای «فوری/افتضاح» را داخل عنوان نگذارید. مثال: «[Checkout/API] پس از callback تکراری، Order در Pending میماند» از «پرداخت خراب است» قابل عملتر است؛ اما جزئیات Build و Data همچنان در Contract میآیند.
[Surface/Entity] + [Trigger/Condition] → [Observed outcome] [پنل سفارش] با callback تکراری → وضعیت Pending باقی میماند
Report Identity و تاریخچهٔ Correction را ثبت کنید
| فیلد | کارکرد |
|---|---|
| report_id/version | ارجاع بدون ابهام |
| created_by/observed_at | منشأ و Cutoff |
| status | Draft/Ready/Needs-info/Superseded |
| supersedes/corrects | حفظ تاریخچه |
| access/classification | کنترل مشاهدهٔ Evidence |
| next owner/due | Handoff قابل پیگیری |
Build Identity فقط «نسخه ۲» نیست
نسخهٔ بازاری ممکن است چند Artifact متفاوت داشته باشد. Commit/tag، package یا image digest، schema/migration، feature flags، dependency versions، config hash و deployment/branch را تا حد لازم ثبت کنید. هدف بازسازی هویت است، نه کپیکردن تمام Inventory.
Build Identity release_label: SYN-2.4 commit: 7f3-demo artifact_digest: sha256:demo88 schema: v3 config_hash: sha256:cfg-demo-21 flags: callback_v2=on dependencies: fake-psp=v4; fake-ledger=v2
Environment را به تفاوتهای مؤثر محدود کنید
«Chrome/Windows» برای باگ Backend کافی نیست و Dump کامل سیستم برای یک غلط متن لازم نیست. OS/browser/device/runtime/network/locale/timezone/cache/storage/topology/permissions را فقط وقتی ثبت کنید که به Claim یا فرضیه مرتبطاند. برای محیط قابل ساخت و عیبیابی، لَب Docker Compose تسترها مرجع جداگانه است.
State یک Snapshot است، نه جملهٔ «وارد حساب شدم»
| State dimension | نمونه |
|---|---|
| Actor/role | synthetic buyer / role-customer |
| Entity state | Order=Created، Attempt=Started |
| Session/auth | fresh session، scope محدود |
| Cache/storage | cold cache، empty local storage |
| Queue/event | outbox pending=0 |
| Clock | UTC instant + Asia/Tehran display |
| Feature/config | callback_v2=on |
Test Data باید Seed، Schema و Lineage داشته باشد
نام کاربری واقعی یا رکورد Production «دادهٔ بازتولید» نیست. Dataset مصنوعی/ماسکشده، seed، generator version، schema، reset rule، referential invariants و شناسههای خیالی را ثبت کنید. سیاست عمیقتر داده، حریم و Subsetting در راهنمای مدیریت داده تست آمده است.
Data Identity dataset: SYN-CHECKOUT-42 schema: v3 seed: 42 generator: checkout-fixture@1.2 reset: transaction rollback + queue purge entities: SYN-ORDER-42, SYN-ATTEMPT-42 real_person/payment/credential_data: none
Precondition، Trigger و Procedure را جدا کنید
| بخش | پرسش |
|---|---|
| Precondition | پیش از اجرا چه State/Data لازم است؟ |
| Setup | چگونه آن وضعیت ساخته/تأیید میشود؟ |
| Trigger | کدام Event پنجرهٔ مشاهده را آغاز میکند؟ |
| Procedure | چه Actionهایی با چه Input و ترتیب؟ |
| Observation point | کجا/چه زمانی Evidence گرفته میشود؟ |
| Cleanup | چه چیزی Reset یا حفظ میشود؟ |
Steps باید اتمیک، پارامتری و قابل مشاهده باشند
هر Step بهتر است Actor، Action/Input، Target و Observation اختیاری داشته باشد. «پرداخت کنید» چندین تصمیم و Event را پنهان میکند. در عین حال، ریزکردن هر کلیک بیاثر Noise میسازد. حداقلسازی یعنی حذف گام با آزمایش، نه حذف تصادفی جزئیات.
Step 3 actor: synthetic fake-PSP action: POST callback fixture CB-42 twice target: /sandbox/callback interval: 25 ms (fictional) expected acknowledgement: HTTP 200 for each request capture: request IDs + trace ID + Order/Ledger states
Minimal Reproduction را با Delta بسازید
ابتدا یک Witness run کامل را حفظ کنید؛ سپس یک متغیر را تغییر دهید: callback count، interval، flag، cache یا dataset. هر حذف/تغییر باید Outcome را ثبت کند. اگر با حذف Step هنوز Failure هست، آن Step برای Trigger لازم نیست؛ ممکن است برای State یا Evidence لازم باشد.
| Run | Delta | Outcome | استنباط محدود |
|---|---|---|---|
| W1 | دو callback/25ms | Observed | Witness |
| C1 | یک callback | Not observed | تعداد ممکن است مرتبط باشد |
| D1 | دو callback/500ms | Not observed | Timing ممکن است مرتبط باشد |
| D2 | flag off | Not observed | Flag association؛ نه Cause |
Witness Run و Control Run مکملاند
Witness همان Failure را با هویت کامل ثبت میکند. Control تا جای ممکن همان Build/Config/Data را دارد و فقط متغیر تعریفشده را عوض میکند. نتیجهٔ متفاوت قدرت فرضیه را بیشتر میکند، اما Cause را خودکار اثبات نمیکند؛ تفاوتهای پنهان و تصادف هنوز ممکناند.
Run Record run_id: contract_version: executor + timestamp: build/config/data/state identities: changed variable: attempt_id: actual observations: oracle comparison: artifact manifest: outcome: OBSERVED | NOT_OBSERVED | INCONCLUSIVE | INVALID limitations:
Attempt Identity از نرخ بازتولید مهمتر شروع میشود
«۳ بار از ۵ بار» بدون تعریف Attempt، reset، cutoff و Conditions مبهم است. Attempt ID، start/end، reset result، input/seed، outcome و invalid reason را ثبت کنید. Invalid را نه Success بشمارید نه Failure. نرخ کوچک و محلی احتمال Production یا شیوع کاربران را تخمین نمیزند.
| Outcome | معنا |
|---|---|
| Observed | Oracle violation در Conditions هدف دیده شد |
| Not observed | Run معتبر بود، نقض دیده نشد |
| Inconclusive | Evidence/Oracle برای حکم کافی نیست |
| Invalid | Setup/reset/build/run خراب بود |
| Aborted | به علت ایمنی/زمان/منبع متوقف شد |
Actual Result باید Observation قابل زمانبندی باشد
«کار نکرد» را به Surface، value، timestamp، duration، error/signature و state transition تبدیل کنید. UI screenshot فقط نمای Presentation است؛ برای ادعای Backend از API، database invariant، event/ledger یا log همبسته استفاده کنید. دسترسی مستقیم Production تنها با مجوز، حداقلسازی و مسیر ایمن.
Expected Result باید Source و Scope داشته باشد
Expected ممکن است برای Role، locale، flag یا state دیگری درست باشد. Source/version و شرط کاربرد را بنویسید. اگر Requirement متناقض است، Report را به «نیازمند تعیین Expected/Disposition» ببرید؛ اختلاف را با شدتدادن متن حل نکنید.
Evidence Packet یک Manifest دارد، نه انبوه Attachment
| Artifact | حداقل Metadata | خطر |
|---|---|---|
| Screenshot/video | run/time/surface/hash | PII/notification/background |
| HAR/request | filter/time/request ID/redaction | Cookie/Auth/body/query |
| Log | service/build/timezone/filter | secret/PII/tenant crossover |
| Trace | trace/span/sample/status | correlation/privacy |
| DB/query result | query version/snapshot/rows/hash | bulk data/change risk |
| Crash dump | build/device/symbols/time | memory/user data |
Artifact Manifest Item artifact_id/name/type: run_id + captured_at: source/tool/version/filter: content_hash: claim_supported: redaction_profile + review_status: access/retention/delete_at: known omissions: supersedes:
Screenshot شاهد است، ولی Steps یا Oracle نیست
تصویر میتواند State قابل مشاهده را ثبت کند، نه مسیر رسیدن، request order، دادهٔ پنهان یا Expected. Crop بیش از حد زمینه را حذف میکند؛ تصویر کامل نیز ممکن است نام، پیام، شماره یا Token نشان دهد. Annotation باید کپی اصلی را تخریب نکند و نسخهٔ Redacted از Original کنترلشده جدا باشد.
ویدئو Timeline را نشان میدهد، نه علت را
ویدئو برای gesture، focus، animation و sequence مفید است، اما Build، input دقیق و Backend state را تضمین نمیکند. زمانهای کلیدی را Bookmark کنید، متن Steps را نگه دارید، صوت/اعلان/حسابهای دیگر را حذف کنید و نرخ پخش/برش را ثبت کنید.
HAR را حتی پس از Sanitization بازبینی کنید
مستند رسمی Chrome DevTools Network میان HAR sanitized و HAR دارای دادهٔ حساس فرق میگذارد و میگوید حالت sanitized بهطور پیشفرض Cookie، Set-Cookie و Authorization را حذف میکند. این حذف به معنی «کاملاً امن» نیست؛ URL، query، body، response و شناسههای دامنه ممکن است حساس بمانند. Redaction profile و بازبینی محتوا لازم است.
Log و Trace را با Correlation متصل کنید
W3C Trace Context قالب HTTP برای انتشار Context و همبستگی درخواستها را تعریف میکند؛ traceparent و tracestate جایگزین Run/Order/Attempt identity یا تضمین ثبت Trace نیستند. W3C همچنین قرار دادن PII یا دادهٔ حساس در این فیلدها را منع میکند. در Report، trace ID را با time window، service و sampling status همراه کنید.
Evidence از موبایل باید Device و Build را حفظ کند
مستند رسمی Android bug report توضیح میدهد که گزارش دستگاه میتواند log، stack trace، screenshot و اطلاعات پیکربندی/Build داشته باشد. چنین Bundleهایی ممکن است بسیار گسترده باشند؛ Collection مجاز، انتخاب Device درست، Redaction، دسترسی و Retention را پیش از Attach تعیین کنید. Emulator evidence معادل همهٔ دستگاههای واقعی نیست.
Hash یکپارچگی Artifact را میسنجد، نه حقیقت آن را
Digest کمک میکند بفهمیم فایل پس از Capture تغییر کرده یا خیر. Hash ثابت نمیکند Capture از Build درست، ساعت درست، Scope درست یا منبع معتبر بوده است. Algorithm، مقدار، فایل و زمان را ثبت کنید؛ نسخهٔ Redacted طبیعتاً Hash دیگری دارد.
Redaction باید قابل آزمون و قابل رد باشد
| کلاس | کنترل | آزمون منفی |
|---|---|---|
| Credential/Token | حذف header/body/cookie | pattern + manual review |
| PII | synthetic/mask/minimize | search name/mobile/email |
| Financial | fake IDs/amounts/account | no PAN/CVV2/OTP/real transaction |
| Tenant | scope filter | no cross-tenant record |
| Internal secret | vault reference، نه value | secret scanner |
| Metadata | EXIF/path/filename cleanup | metadata inspection |
Evidence Access و Retention جزو Contract است
لینک منقضی، فایل بدون مجوز و Attachment عمومی، Handoff را میشکند. Classification، audience، least privilege، owner، retention/delete date، legal/security hold و route درخواست دسترسی را ثبت کنید. هیچ گزارش باگی مجوز دورزدن کنترلهای سازمانی نیست.
فرم ساختیافته Completeness را تقویت میکند، نه کفایت را
مستند رسمی GitHub Issue Forms ورودیهای مختلف، Validation، label و assignee پیشفرض را پشتیبانی میکند و نمونهٔ Bug form آن Current/Expected/Steps/Environment دارد. Required بودن یک Textarea ثابت نمیکند مقدار آن دقیق، امن یا قابل Replay است. Validation معنایی و Review همچنان لازماند.
Reproduction Readiness را با Gate قراردادی بسنجید
| Gate | Ready وقتی… | در غیر این صورت |
|---|---|---|
| Claim | Observation و Oracle جدا هستند | Needs clarification |
| Identity | Build/Config/Data/State کافی است | Needs identity |
| Run | Attempt/Trigger/Outcome ثبت است | Needs witness |
| Evidence | Manifest/correlation/hash وجود دارد | Needs evidence |
| Safety | Redaction/access/retention بازبینی شده | Quarantine |
| Handoff | owner/action/due/response contract روشن است | Unrouted |
Ready for Handoff با Reproduced فرق دارد
| State | تعریف |
|---|---|
| Draft | قرارداد در حال تکمیل |
| Ready for handoff | کنترل ساختاری/ایمنی عبور کرده، Replay نشده |
| Reproduced | گیرنده در Conditions ثبتشده Failure را دیده |
| Not reproduced | Run معتبر بود ولی Failure دیده نشد |
| Inconclusive | Oracle/Evidence/Run حکم نمیدهد |
| Needs information | شکاف مشخص و درخواستشده |
| Quarantined | Evidence مشکوک به دادهٔ حساس |
| Superseded | نسخهٔ جدید با تاریخچه جایگزین شده |
قرارداد پاسخ گیرنده، رفتوبرگشت مبهم را حذف میکند
Handoff Response receiver + received_at: contract/artifact versions accessed: replay run_id: same/different identities: outcome: new evidence: questions as exact missing fields: disposition authority needed: next action/owner/due: correction requested:
Severity، Priority و Reproducibility سه محور متفاوتاند
Failure شدید میتواند یکبار مشاهده شده باشد؛ Failure کماثر ممکن است صددرصد تکرار شود. Reproducibility دربارهٔ شرایط مشاهده و Replay است، Severity دربارهٔ Impact، و Priority/Class of Service دربارهٔ ترتیب اقدام. تصمیم آنها را به Authority Map تیم بسپارید، نه به Reporter تنها. اختلاف نقش و تصمیم را با پروتکل تعارض QA و Dev حل کنید.
یک باگ، یک Report قانون مطلق نیست
چند Failure ممکن است یک Cause/Defect مشترک یا برعکس یک Symptom مشترک با Causeهای متفاوت داشته باشند. Reporter باید Observationها و Attemptها را تفکیک کند؛ Canonicalization و Duplicate decision در Triage انجام میشود. شکستن کورکورانه یا ادغام زودهنگام، هر دو Traceability را آسیب میزنند.
پیش از ثبت، «دو یا سه بار» قانون عمومی نیست
تکرار میتواند State را نابود، تراکنش را دوبرابر، داده را افشا یا Incident را تشدید کند. برای Crash محلی کمخطر شاید Replay فوری مناسب باشد؛ برای Production، مالی، امنیتی یا Destructive ابتدا Evidence و Containment. بودجهٔ Attempt باید از Risk، هزینه، تغییرپذیری و ارزش اطلاعات بیاید، نه عدد ثابت.
Production و Security مسیرهای استثنا دارند
| شرط | اقدام مقدم |
|---|---|
| آسیب فعال کاربر/داده/مالی | Incident/containment |
| احتمال Vulnerability | Private security channel |
| دادهٔ واقعی در Artifact | Quarantine، نه upload عمومی |
| عملیات برگشتناپذیر | عدم Replay بدون مجوز/کنترل |
| Evidence قانونی/حسابرسی | Chain/retention policy |
| شخص ثالث | Contract/vendor escalation با حداقل داده |
قالب کامل Reproduction Contract
REPRODUCTION CONTRACT Identity: report_id/version/status/created/observed/supersedes Claim: observation + impact boundary Oracle: expected/source/version/scope/conflict Target: release/build/artifact/schema/config/flags/dependencies Context: environment/device/network/locale/timezone State: actor/entity/session/cache/queue/clock Data: dataset/schema/seed/generator/reset/invariants Run: witness/control/attempt/trigger/steps/observation window/outcome Evidence: manifest/correlation/hash/redaction/access/retention Limits: unknowns/omissions/nonrepresentative conditions Safety: production/security/privacy/destructive constraints Handoff: receiver/action/due/response states/correction path
مثال مصنوعی: callback تکراری در Checkout خیالی
سناریوی SYN-CHECKOUT-42 کاملاً ساختگی و محلی است. Fake PSP دو callback خیالی را با فاصلهٔ ۲۵ میلیثانیه میفرستد. UI وضعیت Pending نشان میدهد، API Order نیز Pending است، اما Ledger مصنوعی یک credit دارد. Oracle قرارداد میگوید پس از callback معتبر باید Order=Paid و دقیقاً یک credit وجود داشته باشد؛ UI بهتنهایی Oracle نیست.
| فیلد | مقدار مصنوعی |
|---|---|
| Build | commit.7f3 + image digest demo88 |
| Config/Data | cfg-demo-21 / schema-v3 / seed42 |
| Actor/Entity | SYN-BUYER-42 / SYN-ORDER-42 |
| Trace | syn-trace-0000000000000042 |
| Witness | duplicate callback → Pending |
| Control | single callback → Paid |
| Evidence | synthetic HAR/log/API/Ledger/screenshot |
| Decision | Ready for handoff؛ نه Root cause |
برای طراحی Sandbox و حالتهای پرداخت به راهنمای تست درگاه پرداخت مراجعه کنید. مثال حاضر هیچ بانک، PSP، فروشگاه، کاربر، تراکنش، پول یا ادعای بازار ایران را نمایندگی نمیکند.
آزمایش بازتولیدپذیر: Template PASS در برابر Contract HOLD
Fixture مستقل SYN-REPRO-CONTRACT-01 یک Report ساختگی با Title، Description، Steps، Expected، Actual، Environment، Screenshot و Severity میسازد. کنترل سادهٔ required-field آن را PASS میکند. Validator دوم روی هویت و Evidence همان Record کار میکند.
$ node .post-1829-experiment.js runtime: Node.js v26.7.0 fixture: SYN-REPRO-CONTRACT-01 naiveTemplate.requiredFields = 8 naiveTemplate.missing = [] naiveTemplate.decision = PASS draftContract findings: - missing-build-identity - missing-config-hash - missing-data-seed - presentation-only-oracle - missing-correlation-id - missing-comparable-control-run - missing-artifact-hash (2) - unverified-redaction (2) draftContract.decision = HOLD correctedContract.findings = [] correctedContract.decision = READY_FOR_HANDOFF
نتیجه فقط میگوید Required fields با Handoff readiness یکی نیست. نسخهٔ اصلاحشده از قواعد ساختاری ازپیشنوشتهشده عبور میکند؛ اسکریپت هیچ برنامه، شبکه، PSP، API، Ledger، Screenshot یا HAR واقعی را اجرا/بازبینی/Replay نکرده و وجود Defect، Cause یا Fix را ثابت نمیکند.
حدود اعتبار آزمایش مصنوعی
- تمام Report، Build، State، Data، Trace، Artifact، Hash، Rule و Decision ساختگیاند.
- تعداد هشت فیلد، هشت Check و ده Finding Benchmark یا استاندارد نیست.
- Validator فقط Presence و چند رشتهٔ قراردادی را بررسی میکند، نه صحت معنایی یا امنیت واقعی.
- READY_FOR_HANDOFF معادل Reproduced، Valid defect، Root cause، Severity یا Release decision نیست.
- هیچ نرخ بهرهوری، زمان رفع، کیفیت، هزینه یا احتمال Production اندازهگیری نشده است.
- مقادیر ۲۵ms، seed42 و شناسهها صرفاً Fixture هستند.
آزمایشگاه فارسی کاملاً جدا و بدون شبکه
یک سرویس محلی Fake Checkout با API و Ledger درونحافظهای بسازید. Seed ثابت، clock مصنوعی، callback تکراری، callback دیررس، ارقام فارسی/عربی/لاتین، Unicode normalization، نمایش ریال و تومان با واحد صریح و UTC/Asia-Tehran را Fault کنید. تمام endpointها fake و شبکه خاموش باشد.
| Fault | Contract field | Evidence |
|---|---|---|
| Build اشتباه | artifact digest | identity mismatch |
| Seed فراموششده | data identity | fixture manifest |
| Callback duplicate | attempt/trigger | request IDs |
| UI-only claim | oracle | API/Ledger comparison |
| Trace قطع | correlation | service gap |
| HAR دارای token fake | redaction | negative scan |
| Artifact تغییرکرده | hash | digest mismatch |
| Contract اصلاحشده | supersedes | immutable history |
نام، موبایل، ایمیل، IP، حساب، Order، PAN، CVV2، OTP، Cookie، Token، Secret، فایل، Screenshot، تراکنش یا پول واقعی وارد نکنید. این Lab توصیهٔ بانکی، مالی، حقوقی، امنیتی یا حریم خصوصی برای ایران نیست.
Verification بعد از Fix قرارداد تازه میخواهد
اجرای قبل از Fix را بازنویسی نکنید. Fix commit، Build جدید، همان یا نسخهٔ تازهٔ Contract، witness replay، control، mechanism-led regression، before/after evidence و Limit را ثبت کنید. Not observed در یک Run مساوی «برای همیشه رفع شد» نیست.
Verification Addendum defect/report links: fix commit + target build: contract version replayed: before evidence: after run/outcome/evidence: regression scope/rationale: environment/data differences: limitations/residual risk: verifier + verified_at: closure authority:
Correction بهتر از ویرایش بیردپا است
اگر Build، Expected، Artifact یا Redaction اشتباه بود، نسخهٔ جدید با reason و supersedes بسازید؛ Artifact ناامن را Quarantine/replace کنید و ارجاعهای تصمیم را به نسخهٔ درست ببرید. ویرایش خاموش Evidence audit را میشکند و ممکن است نتیجهٔ قبلی را نامعتبر کند.
اتوماسیون چه چیزهایی را میتواند بررسی کند؟
| کنترل | ماشینی | انسانی |
|---|---|---|
| Required/format/enum | قوی | Tailoring |
| Build/config existence | قابل بررسی | relevance |
| Artifact hash/link/access | قوی | claim fit |
| Secret/PII patterns | کمکی | context/privacy review |
| Oracle version | drift check | meaning/authority |
| Reproduction/Cause | runner evidence | interpretation |
AI میتواند خلاصه کند، اما شاهد نسازد
AI ممکن است Title پیشنهاد دهد، Field مفقود را Flag کند، Timeline استخراج کند یا مشابهت Reportها را رتبهبندی کند. نباید Step، Build، Log، Expected، Severity، Redaction یا Cause را حدس بزند. Source links، confidence، human confirmation، audit و ممنوعیت ارسال Evidence حساس به Provider کنترلنشده لازماند.
معیارهای فرایند را بدون بازیسازی تعریف کنید
| پرسش | Measure | Countermetric |
|---|---|---|
| Handoff روشن است؟ | درصد Ready با Population تعریفشده | زمان Reporter |
| رفتوبرگشت کم شد؟ | clarification cycles by class | silent wrong assumptions |
| Evidence قابل دسترسی است؟ | link/access failure | over-broad access |
| حریم رعایت شد؟ | quarantine/redaction escapes | missing useful evidence |
| Replay ممکن است؟ | first valid replay outcome | severity/risk mix |
| Correction سالم است؟ | superseded references repaired | history loss |
زمان رفع باگ را مستقیماً به کیفیت Reporter نسبت ندهید؛ پیچیدگی، Queue، مالکیت، Environment و Priority دخیلاند. «درصد Reproduced» نیز هدف خام خوبی نیست، چون تیم ممکن است Reportهای دشوار یا تکوقوع را رد کند.
برنامهٔ ۳۰روزهٔ استقرار
| روز | کار | خروجی |
|---|---|---|
| ۱–۵ | نمونهگیری امن از Reportها و رفتوبرگشتها | taxonomy شکاف |
| ۶–۱۰ | تعریف Identity/Oracle/Run/Evidence/Safety | Contract v0.1 |
| ۱۱–۱۵ | ساخت Fixture/Lab و Redaction tests | synthetic pack |
| ۱۶–۲۰ | Pilot روی یک تیم/سطح Risk | response evidence |
| ۲۱–۲۵ | تنظیم فرم، Gate، exception و Access | v0.2 |
| ۲۶–۳۰ | Review metric/countermetric و تصمیم | Adopt/Adapt/Stop |
نقشها و حقوق تصمیم
| نقش | مسئولیت | تصمیم مستقل نیست |
|---|---|---|
| Reporter | Observation/Contract/Evidence provenance | Root cause/priority/release |
| Domain/Product | Oracle/impact clarification | technical cause |
| Engineer/Investigator | Replay/hypothesis/cause evidence | risk acceptance |
| QA/Verifier | before/after/regression evidence | all business priority |
| Security/Privacy | channel/redaction/access/retention | product expected behavior |
| Triage/Defect owner | canonical/disposition/routing | inventing evidence |
| Release/Risk owner | accept/hold/conditional decision | rewriting facts |
۳۰ ضدالگوی گزارش قابل بازتولید
- عنوان «کار نمیکند»
- علت حدسی در Actual
- Expected بدون Source
- Version بازاری بدون Artifact
- Environment «test»
- حساب واقعی در Steps
- Seed/Reset نامشخص
- State ضمنی
- چند Action در یک Step
- حذف Witness اولیه
- نرخ بدون Attempt definition
- Invalid بهعنوان Not observed
- Screenshot بهجای Oracle
- ویدئو بهجای Steps
- انبوه Log بدون time/filter
- HAR sanitized بهعنوان کاملاً امن
- Trace ID بدون sampling/time
- Artifact بدون hash/provenance
- لینک Evidence بدون Access test
- Retention نامحدود
- PII در trace context
- Replay مخرب در Production
- Severity=Reproducibility
- Priority توسط Template
- هر Symptom یک Defect قطعی
- Required field=quality
- AI-generated fact
- Ready=Reproduced
- Not observed=Fixed
- ویرایش بیردپای Evidence
چکلیست ۴۸نقطهای Handoff
- Report ID
- نسخه
- Status
- Observed at
- Reporter
- Supersedes
- Observation
- Impact boundary
- Interpretation جدا
- Hypothesis جدا
- Expected
- Oracle source
- Oracle version
- Oracle scope
- Release label
- Commit
- Artifact digest
- Schema
- Config hash
- Flags
- Dependencies
- Platform/device
- Network/locale/time
- Actor/role
- State before
- State after
- Dataset
- Seed/generator
- Reset rule
- Trigger
- Atomic steps
- Input values
- Observation window
- Attempt IDs
- Outcome vocabulary
- Witness run
- Control/delta
- Correlation IDs
- Artifact manifest
- Hashes
- Redaction profile
- Redaction review
- Access/classification
- Retention/delete
- Limitations
- Safety exception
- Receiver/action/due
- Response/correction contract
جمعبندی: بازتولیدپذیری یک زنجیرهٔ هویت و شاهد است
گزارش خوب فقط کوتاه یا پرجزئیات نیست؛ متناسب با Claim، دقیق و امن است. Observation را از Cause جدا کنید، Oracle را نسخهدار کنید، Build/State/Data/Attempt را هویت بدهید، Witness و Control را ثبت کنید، Evidence را با Manifest/Correlation/Hash/Redaction تحویل دهید و Ready، Reproduced و Verified را یکی نگیرید. این Contract اصطکاک اطلاعاتی را قابل مشاهده میکند؛ کیفیت محصول یا سرعت Fix را تضمین نمیکند.
سؤالات متداول گزارش باگ قابل بازتولید
مهمترین بخش گزارش باگ قابل بازتولید چیست؟
یک فیلد واحد نیست؛ زنجیرهٔ Observation→Oracle→Build/State/Data→Attempt→Evidence اهمیت دارد. Steps بدون Oracle یا Build دقیق میتواند اجرا شود ولی ادعای دیگری را بسنجد. Contract باید متناسب با Risk و Surface Tailor شود.
اگر باگ فقط یکبار رخ داد، گزارش را ثبت کنیم؟
اگر Observation معتبر یا اثر مهم است، بله؛ آن را One-time observed بنامید و Evidence اولین وقوع، identity، unknownها و خطر Replay را حفظ کنید. یک وقوع را «همیشه» یا Root cause ننامید. مسیر عمیقتر باگ متناوب/Cannot Reproduce را جدا دنبال کنید.
آیا Screenshot یا Video برای بازتولید کافی است؟
معمولاً نه. آنها Presentation و Timeline را نشان میدهند، اما Build، State، Input، Backend outcome، Oracle و Correlation را لزوماً ثبت نمیکنند. آنها را به Run و Claim مشخص متصل و از نظر دادهٔ حساس بازبینی کنید.
چند بار باید باگ را پیش از ثبت تکرار کنیم؟
عدد عمومی وجود ندارد. Risk، تخریبپذیری، Production/Security/Financial context، هزینه، State mutation و ارزش اطلاعات تعیین میکنند. گاهی یک Witness امن کافی است؛ گاهی ماتریس Attempt لازم است؛ و گاهی Containment بر Replay مقدم است.
آیا فرم اجباری یا AI گزارش را خودکار قابل بازتولید میکند؟
فرم میتواند Completeness و فرمت را تقویت کند و AI میتواند Field مفقود یا Timeline را پیشنهاد دهد؛ هیچکدام صدق Observation، کفایت Oracle، امنیت Evidence، Reproduction یا Cause را تضمین نمیکنند. Human review، Replay evidence و تاریخچهٔ Correction لازم میمانند.
